Dies ermöglicht das Öffnen (hier das Umschalten des LED-Zustands) eines Clients, ohne dass Sie vor dem System stehen. Diese Informationen und Funktionen legen Sie in einer Vorlage an, innerhalb der Plattform Template genannt, aus der Sie später beliebig viele Clients erzeugen.
Abbildung 4 zeigt das Template in einem Ausschnitt aus der Weboberfläche. Neben Properties dürfen Sie hier Services, Events und Subscriptions anlegen, die jeder Client erbt, den Sie aus dieser Vorlage erstellen. Da in diesem System alle Clients dieselben Funktionen haben, stellt das eine optimale Lösung dar. Sie finden alle Things und Entitäten im Ordner Entities im Github-Projekt und importieren diese bei Bedarf wieder.
Abbildung 4: Ein Ausschnitt der Thingworx-Weboberfläche mit dem Client-Template und seinen Properties.
Der Server soll die Clients verwalten. Die IoT-Plattform enthält daher ein Server-Thing, das Sie im Gegensatz zu den Client-Things nicht dynamisch generieren, sondern das stets als Ansprechpartner für neue Clients bereitsteht. Hierzu offeriert der Server entsprechende Funktionen, über die Sie einen Client mit all seinen Informationen in der Plattform erstellen. Der Client verbindet sich mit der Plattform und erstellt durch die Funktionen des Servers ein Client-Thing, mit dem er sich dann bei Bedarf koppelt. Beim Erzeugen eines Things in der Plattform verwendet er das bereits erwähnte Template für die Clients.
Der Server stellt in der Plattform einen Service bereit, mit dem Sie das auf dem Server implementierte Regelsystem abfragen können. Das Regelwerk stammt aus einer externen Quelle [6] und ist bereits im Github-Projekt für den Client hinterlegt, wo Sie auch Informationen zur Konfiguration finden.
Zusätzlich gibt es eine Funktion, um neue Regeln anzulegen. Die Funktion erwartet als Parameter einen Namen für die Regel sowie die Regel selbst, die Sie in Programmsyntax übergeben. In der Klasse für das Regelwerk entsteht auf diese Weise eine Subklasse, die vorgibt, worum es sich bei dem Objekt handelt, das der Server durch das Regelwerk überprüft. In unserem Fall existiert eine Klasse Person, die Attribute für Vor- und Nachnamen enthält:
PersonName=="Max" && PersonSurname=="Mustermann"
Diese Regel erlaubt den Zutritt für eine Person, die Max Mustermann heißt. Möchten Sie mehr Attribute überprüfen, legen Sie diese entsprechend an. Zu den weiteren Funktionen des Servers zählen das Löschen eines Clients in der Plattform sowie das Bereitstellen von Informationen, etwa einer Liste der verbundenen Clients mit Name, Ort und ID sowie der Anzahl der verbundenen Clients.
Zum Schluss implementieren Sie die eigentliche Logik in die Plattform in Form von Subscriptions. Diese führen beim Eintritt von bestimmten Aktionen Javascript-Code aus. Abbildung 5 zeigt ein kleines Beispiel im Editor, das abläuft, wenn sich der Verbindungsstatus eines Clients ändert.
Abbildung 5: Im Editor für die Subscriptions gibt es zahlreiche Hilfsmittel, die Sie beim Erstellen unterstützen.
Zuerst ermitteln Sie die Parameter für das Skript, in diesem Fall den Namen und die ID des Clients, der das Skript ausführt. Im Anschluss prüft das Skript, ob der Client verbunden ist. Falls nicht, ruft es mit den Parametern des Clients die entsprechende Funktion zum Löschen auf dem Server auf. Diese benötigt der Server, damit er den richtigen Client löscht.
Wie in Abbildung 5 zu sehen, stellt der Editor verschiedene Tabs bereit, die beim Erstellen eines Skripts helfen. Es gibt vorgefertigte Snippets für verschiedene Aktionen, hinzu kommen Reiter mit allen abrufbaren Werten und Aktionen für das aktuelle Objekt (Me) sowie alle anderen Entitäten. Bevor Sie das Skript speichern, überprüfen Sie direkt in der Plattform die Code-Syntax, indem Sie einfach den Daumen-hoch-Button anklicken.
“Smartes” System
Erst das ereignisgetriebene Steuern macht letztlich das System smart, das dann komplett autonom arbeitet und entscheidet. Da die Daten, auf die das System reagiert, von den einzelnen Clients stammen, implementieren Sie dementsprechend die Subscriptions in der Vorlage der Clients. So kann die Plattform auf die Änderungen jedes einzelnen Clients reagieren und Aktionen im System auslösen. Ein Beispiel liefert die Unterscheidung, ob das System eine bekannte oder eine unbekannte Person erfasst hat.
Wurde die Person vor der Tür erkannt und dies der Plattform mitgeteilt, leitet diese die Information durch das System an das Regelwerk des Servers weiter. Der wiederum übermittelt das Ergebnis der Prüfung an die Plattform. Ist der Eintritt erlaubt, teilt sie das dem jeweiligen Client mit, der daraufhin das Schloss öffnet – unser Prototyp würde stellvertretend seine LED auf Grün schalten.
Der zweite Fall ist eine unbekannte Person. Der Client teilt dies der Plattform mit, die wiederum dem Client sagt, dass er den Status Pending anzeigen soll. In diesem Fall leuchtet die LED des Systems blau, und das Display zeigt Pending an, damit der Nutzer weiß, dass das System die Anfrage verarbeitet. Danach löst die Plattform beim Client über den entsprechenden Service die Kamera aus. Der Client lädt das Foto anschließend in die Plattform hoch, sodass Sie nachverfolgen können, wer Zutritt zu dem System haben wollte.
Es wäre möglich, dieses Bild in einer entsprechenden App anzuzeigen, etwa durch eine Notification. So würde sich die Möglichkeit eröffnen, in Echtzeit aus der Ferne doch Zutritt zu gewähren. Ein weiteres Skript aktiviert sich durch eine Änderung des Verbindungsstatus des Clients. Stellt es fest, dass die Verbindung unterbrochen wurde, ruft es die Services des Servers auf, um den Client zu löschen.
Der letzte Schritt, um das System smart zu machen, ist die Gesichtserkennung, bei deren konkreter Implementierung es sehr auf die verwendete Raspbian-Version und den Stand der Bibliotheken ankommt. Eine mögliche Variante findet sich auf der Seite von Adafruit [7]. Sie zeigt Schritt für Schritt, wie Sie das in Python geschriebene Modul in Betrieb nehmen.
Haben Sie das Modul fertig angelernt, bleibt die Aufgabe, zusätzlich im Quellcode ein REST-Interface zu implementieren. Ein Beispiel dafür findet sich im Code zu diesem Projekt [2] im Peripherie-Skript. Es schreibt das erkannte Gesicht in das entsprechende Property (NewEntryRequest) des Clients in der Plattform.
