Angefangen hat die Sache aus meiner Sicht mit per Funk schaltbaren Zwischensteckern für Steckdosen. Vor wenigen Jahren war ich glücklich damit, als ich vom Bett aus mit einer ziemlich klobigen Fernbedienung das Licht im Zimmer ausschalten konnte. Und das mit einem Baumarkt-Set für einen Zehner. Der Spaß hielt aber nicht lange, da man von Woche zu Woche näher mit der Fernbedienung an den/die Empfänger gehen musste, damit diese reagieren.
 |
| IoT Version 0.0.0.1 ;) |
Als es schließlich unerträglich wurde, musste eine Lösung her. Während sich meine Eltern für ein fertiges System von Homematic entschieden, wollte ich etwas eigenes, über das ich die volle Kontrolle habe. Meine Idee war zu dem Zeitpunkt eigene Komponenten - Schalter, Zwischenstecker, etc. - zu bauen und diese über eine Server-Anwendung zu verbinden. Im Prinzip habe ich genau dies auch umgesetzt. Oder anders gesagt: Ich setzte immer noch um. Da habe ich mir wohl etwas zu viel vorgenommen. Aber ich habe ja Zeit ;)
Den Anfang habe ich mit der Auswahl eines RaspberryPi als Server gemacht. Dabei war es zufällig genau der Zeitpunkt, als der RaspberryPi 3 vorgestellt wurde. Da ich mich mit Linux wenig auskenne und am liebsten in C# programmiere, war ich sehr glücklich damit, dass ich genau das auf dem Raspberry mit WindowsIoT tun könnte. Das es dabei eine Reihe an Einschränkungen geben würde.. naja das würde ich noch rausfinden.
Zusätzlich zum Server habe ich mich zeitgleich mit der Konzeption eines ersten WLAN-Zwischensteckers befasst. Ich möchte an dieser Stelle garnicht so viel dazu sagen, dafür wird ein späterer Blogpost herhalten müssen. Nur soviel: Ich habe einen Zwischenstecker gebaut, welcher auch funktioniert. Da ich allerdings eine wesentlich günstigere Lösung gefunden habe, bin ich davon abgekommen weitere Schalter dieser Art zu bauen.
Also zurück zur System-Konzeption. Diese sieht vor, dass sich Komponenten "Devices" zu einem Server verbinden. Bei erstmaliger Verbindung registrieren sich diese dort und teilen dem Server mit, welche Ein- und Ausgänge sie besitzen. Der Server vergibt an das Device eine eindeutige Identifikationsnummer, mit welcher es sich bei folgenden Verbindungen ausweisen kann.
 |
| Meine persönlichen Notizen zum Aufbau und zum Kommunikationsprotokoll |
Die logische Verknüpfung von Ein- und Ausgängen erfolgt Server-Intern über Logiknetze. Diese liegen als Vorlage "Pattern" vor können beliebig oft instanziert werden. Jeder Instanz werden nun Verbindungen zwischen den Ein- und Ausgänge der Pattern mit den Ein- und Ausgängen von Devices zugeordnet.
Sendet nun ein Device eine Änderung eines Eingangs, so wird auf dem Server zunächst das entsprechende Device-Profil gesucht. Anhand dessen werden verknüpfte Logik-Instanzen gesucht. Deren Eingänge werden entsprechend der Verknüpfung aktiviert "getriggert". Die Instanz berechnet nun ihre eigenen Ausgänge anhand der hinterlegten Pattern neu. Gibt es eine Änderung eines Ausganges, so wird der neue Wert an verknüpfte Ausgänge von Devices übermittelt.
 |
| Schematischer Ablauf einer Trigger-Aktion |
Die Programmierung der Pattern erfolgt dabei in einer eigenen Sprache über eine externe Verwaltungsanwendung. Diese ist nicht nur für die Programmierung, sondern auch für die Verwaltung der Pattern, der Instanzen, der Device etc. zuständig. Im Prinzip also für die gesamte Serververwaltung.
In Zukunft werde ich auf einzelne Bereiche näher eingehen, aber für heute soll es das gewesen sein.
Ich wünsche noch einen schönes Wochenende!
Keine Kommentare:
Kommentar veröffentlichen