Listing 1
https://Host:Port/Thingworx/Entity-Collection/Entity/Characteristic-Collection/Characteristic?Parameter
Abbildung 2: Nach dem Aufruf des Zustands eines Clients erhalten Sie neben weiteren Beschreibungen des Parameters den Status »Closed«.
Die REST-API bietet den Vorteil einer simplen Implementation eines entsprechenden Clients. Alle gängigen Programmiersprachen stellen mittlerweile entsprechende Funktionen und Klassen bereit, um einen REST-Client in wenigen Zeilen Code zu realisieren.
Der Nachteil: Die REST-API bietet keinen direkten Rückkanal. Zwar lassen sich Änderungen auf dem Client der Plattform mitteilen, aber nicht Änderungen in der Plattform an die Things publizieren. Diese müssen also regelmäßig den Status abfragen, um auf einem aktuellen Stand zu bleiben (Polling).
Für Endgeräte, die über simple Skripte etwa lediglich Sensordaten in die Cloud schreiben, eignet sich REST gut. Wollen Sie hingegen den Client in der Cloud abbilden und soll er autonom mit der Plattform kommunizieren und sich synchronisieren, greifen Sie besser zu einem der mächtigeren SDKs. Hier finden Sie sämtliche Funktionen der Plattform in Quellcode abgebildet. Zusätzlich lassen sich Endgeräte teilweise oder komplett in der Plattform abbilden.
Aufrufe auf das Abbild in der Plattform reicht diese an das reale Endgerät weiter, die Ausführung geschieht lokal auf dem Endgerät und nicht in der Plattform. Hierfür benötigen Sie spezielle Anmerkungen im Quellcode. Listing 2 und Listing 3 zeigen Beispiele für ein Property (die Anzahl der verbundenen Clients) und einen Service (die Abfrage der verbundenen Clients) des Servers.
Listing 2
@ThingworxPropertyDefinitions(properties = {
@ThingworxPropertyDefinition(
name="ClientsConnected",
description="Number of connected Clients",
baseType="NUMBER",
aspects={"dataChangeType:VALUE",
"dataChangeThreshold:0",
"cacheTime:0",
"isPersistent:FALSE",
"isReadOnly:FALSE",
"pushType:ALWAYS",
"defaultValue:0"})
})
Listing 3
@ThingworxServiceDefinition(
name="getConnectedClients",
description="Returns a Infotable of all connected clients."
)
@ThingworxServiceResult(
name="result",
description="List of connected Clients.",
baseType="INFOTABLE"
)
public InfoTable getConnectedClients(){
return ConnectedClientsInfo;
}
Zusätzlich ermöglicht das SDK einen Datenabgleich über das komplette System. Änderungen von Werten in der Plattform oder auf einem der Endgeräte werden automatisch synchronisiert, über eben jenen Rückkanal, der der REST-API fehlt. Das ermöglicht eine umfangreiche Kommunikation mit dem Server und dadurch vielfältige Funktionen auf dem entsprechenden Client. Der Nachteil: Die Komplexität des SDKs verlangt, dass Sie die Vorgaben genau erfüllen. Thingworx bietet innerhalb einer Testphase eine 30-Tage-Probeversion des Entwicklerkits, für die Sie sich lediglich im Entwicklerbereich der Webseite registrieren müssen [4].
Architektur und Ablauf
Das System besteht aus einem Server und mindestens einem Client (Abbildung 3). Der in Java geschriebene Server verwendet zur Kommunikation das plattformeigene Java-SDK. Der Server verwaltet dabei allgemeine Informationen des Systems.
Abbildung 3: Die grundlegende Architektur des Systems enthält lediglich einen Client, weitere fügen Sie einfach hinzu. Diese teilen sich eigenständig dem Server mit und legen sich dynamisch in der Plattform an.
Der Client basiert auf einem Raspberry Pi und besteht aus zwei Teilen: Einerseits läuft auf dem Mini-Rechner wie auf dem Server eine Java-Software. Sie regelt die Verbindung und stellt Funktionen des Clients in der Plattform bereit. Durch ein OpenCV-Modul erkennt sie automatisch, dass sich eine Person vor dem System befindet, und teilt diese Information dann der Plattform mit, um die Rechte über das Regelwerk des Servers zu überprüfen.
In der Peripherie kommen Python-Skripte zum Einsatz, da das Ansteuern der GPIOs auf dem RasPi in Java Schwächen aufweist. Die Java-Software startet die Skripte, die wiederum über die Python-implementierte REST-API mit der Plattform kommunizieren. Die entsprechende Implementation finden Sie im Peripherie-Skript im Github-Projekt.
Das Python-Skript, das die Peripherie steuert, läuft in einem eigenen Thread und schreibt die Sensorwerte und sonstige wichtige Variablen selbstständig über die Schnittstelle in den Client, dort durch das SDK abgebildet. Sobald das Peripherie-Skript einmal läuft, lässt es sich nicht mehr direkt steuern, da es in einer Schleife regelmäßig die Peripherie abfragt und die Werte in die Plattform schreibt.
Um die Peripherie dennoch von außen zu steuern, etwa zum Öffnen der Tür, enthält das Peripherie-Skript Interrupt-Handler, die Sie über den Zugriff von außen triggern und so die Peripherie entsprechend steuern. Dafür existiert ein zweites Python-Skript, das der Java-Client bei Bedarf startet. Durch die Parameter des Skripts löst es entsprechende Trigger auf dem RasPi aus. Diese Mechanismen ermöglichen eine beidseitige Kommunikation der Teile des Clients.
Regelwerk
Die Plattform soll grundlegende Informationen jedes Clients enthalten. Dazu gehören Name, Ort, ID, Status des Schlosses, letzter Eintritt und eine Variable, in die das OpenCV-Modul nach der Gesichtserkennung einträgt, wen es vor dem Client erkannt hat. Zusätzlich soll der Client Funktionen bereitstellen, um ein Foto mit der angeschlossenen Kamera zu machen, falls es sich um eine unbekannte Person handelt, oder um sich ein Bild aus der Ferne zu verschaffen.
