© prettyboy80/Shutterstock.com
Device Shadows/Device Twins

Amazon IoT für Java


Device Shadows bzw. Device Twins sind ein interessanter Weg, um IoT-Verbünde auch beim Verlust von Teilen der Internetverbindung am Leben zu erhalten. Wie das funktioniert, klärt der folgende Artikel.

Bevor wir in medias res gehen, wollen wir noch eine Runde Unterschiedsbingo spielen. In der heutigen Welt hört man nämlich immer wieder vom Thema des Digital Twin. Ein Digital Twin ist im Grunde genommen ein neuartiger Begriff für eine umfangreiche Softwaresimulation eines realen Systems, die einem Consulting- oder Beratungsunternehmen große Umsätze bringen soll.

Unsere hier verwendeten Device Shadows arbeiten auf einem wesentlich „niedrigeren“ Level. Sie fungieren als eine Art Cache zwischen Gerät und Logik, um bei kurzfristigen Verbindungsausfällen das Weiterfunktionieren des Systems zu garantieren.

Wie funktioniert ein Device Shadow?

Wie so oft in der Welt der Cloud-getriebenen Informatik gilt auch hier, dass 5 000 Wege nach Rom führen. Im Hause Amazon setzt man zur Realisierung der als Device Shadow bezeichneten Funktion auf eine Gruppe von MQTT-Kanälen, über die sowohl Server als auch Client Änderungswünsche miteinander austauschen.

Hinter dem unter [1] im Detail beschriebenen Verfahren steckt der Gedanke, dass das Serversystem beim Nichtbestehen einer Verbindung zum Endgerät mit den im Device Shadow vorliegenden Informationen arbeitet. Kommt das Gerät später wieder online, prüft es Änderungen am Server und aktualisiert den Shadow mit seinen aktuellen Messdaten. Zudem kann das Gerät auch nach Zustandsinformationen befragen, die es auf seine Umgebung anwendet.

Ein Klassiker sind alle Arten von langsam verändernden Zuständen wie beispielsweise eine Solltemperatur für einen Raum – dass Sie einen Device Shadow nicht zum Steuern einer latenzkritischen Aufgabe wie beispielsweise einer Turbinendrehzahl einsetzen sollten, nimmt der Autor als logisch an und führt es hier primär zur Vermeidung rechtlicher oder tödlicher Probleme durch Dummheit an.

Beschwörung eines Schattens

Im Artikel „AWS IoT Device SDK for Java“ [2] in der letzten Ausgabe haben wir festgestellt, dass das SDK vergleichsweise umfangreich ist. Als Lösung nutzten wir den Apache-Maven-Paketmanager, der die notwendigen .jar- und sonstigen Dateien für uns automatisch bereitstellte. Öffnen Sie die Eclipse IDE, und kehren Sie in das im letzten Artikel erzeugte Projektskelett zurück. Ersetzen Sie den im Einsprungpunkt befindlichen Code danach durch die in Listing 1 gezeigten Passagen.

Listing 1

public static void main(String[] args) { String clientEndpoint = "a3gw153wutrvel-ats.iot.eu-west-1.amazonaws.com"; String clientId = "TamsGeraetInEclipse"; AWSIotMqttClient client = new AWSIotMqttClient(clientEndpoint, clientId, "AaaaW", "iaaa5", null); try { client.connect(); ...

Auch diesmal müssen wir damit beginnen, eine Instanz der Klasse AWSIotDevice zu erzeugen und unter Verwendung der beiden im letzten Heft generierten IDs am AWS-Server auszuweisen. Die beiden Schlüsselstrings sollten sich nicht geändert haben, wenn Sie im AWS Backend zwischenzeitlich keine Änderungen vorgenommen haben.

Überzeugen Sie sich im ersten Schritt vom korrekten Funktionieren unseres Programms, um danach die folgenden Änderungen durchzuführen:

try { ... client.connect(); String state = "{\"state\":{\"reported\":{\"sensor\":3.0}}}"; device.update(state);

Die Klasse AWSIotDevice dient als Dreh- und Angelpunkt zwischen einzelnen im AWS IoT Backend angelegten Geräteinstanzen. Der übergebene String TamsSensorAktorDevice muss dabei nicht unbedingt sprechend sein – wichtig ist aus Sicht von Amazon nur, dass er ein weltweit einzigartiges Gerät beschreibt. Wer beispielsweise mit einem ESP32 arbeitet oder sein Gerät mit einem Sensorchip ausstattet, kann die im Sensor enthaltenen Seriennummerdaten auch als ID für das Gesamtgerät verwenden. Eine dankbare Quelle sind dafür alle per OneWire verbundenen Sensoren – Abbildung 1 zeigt den relevanten Ausschnitt aus dem Datenblatt des weitverbreiteten DS18B20-Temperatursensors.

hanna_amazon_2_1.tif_fmt1.jpgAbb. 1: OneWire-Peripheriegeräte bringen im Allgemeinen eine Seriennummer mit

Wer das Programm im vorliegenden Zustand ausführt, stellt fest, dass es durchläuft. Im Backend bemerkt man allerdings nichts vom neu angelegten Geräteprofil.

Zur Umgehung dieses Problems müssen wir unseren Code ein wenig weiter anpassen, um Informationen in den Device Shadow zu schreiben:

try { ... client.connect(); String state = "{\"state\":{\"reported\":{\"sensor\":3.0}}}"; device.update(state);

Die Amazon-Dokumentation ist an dieser Stelle übrigens veraltet – die Updatefunktion erwartet nicht mehr ein Date-Objekt, sondern stattdessen einen JSON-String. Diese Vorgehensweise ist vernünftig, da es in Java – je nach Konfiguration Ihrer Arbeitsumgebung – schon eine oder sogar mehrere Stackklassen gibt.

Dieser an sich vernünftig wirkende Code lässt sich in der Cloud ebenfalls pr...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang