elektor Wettbewerb zum Internet of Things

Die Zeitschrift elektor hat Anfang des Jahres 2014 einen Wettbewerb gestartet, um gemeinsam mit Industriepartnern ein einfaches Protokoll für das Internet der Dinge zu entwerfen. Wir werden versuchen, die Vorteile der appicals-Architektur und die Ansprüche der anderen Projektteilnehmer in ein effizientes, gemeinsames Protokoll zusammenzuführen.

www.iot-contest.com

Software-Gateway

Wie auch immer das finale Protokoll aussieht, es wird in regelmäßigen Abständen ein SW-Gateway für den Raspberry Pi zur Verfügung gestellt, welches Geräte simultan im appicals-Universum und in der Internet of Things Architektur sichtbar macht. Damit ist die einfache Interaktion für Geräte beider Welten sichergestellt und die Entscheidung, ob ein Gerät nativ appicals oder IoT als Protokoll verwendet, kann individuell nach Anwendungsfall getroffen werden.

Protokollvorschläge

Nachrichtenrepräsentation

Elektor möchte Daten in wohlbekannten Formaten wie XML oder JSON austauschen. Wir denken, dass auch Binärformate ihre Daseinsberechtigung haben, z.B. für ressourcenbeschränkte Geräte wie 8-Bit Mikrokontroller. Für diese kann auch ein Nachrichtenaustausch über TCP zu aufwendig sein, da hierbei viel RAM für Datenzwischenspeicherung benötigt wird.

Daher empfehlen wir die Auslieferung von Gerätedaten über REST (Representational State Transfer) und HTTP. Durch die Adressierung der benötigten Daten über URL-Pfade kann der Klient sehr einfach entscheiden, welche Form der Datenrepräsentation er gern haben möchte, z.B. http://192.168.1.10:2200/xml/device_description oder http://192.168.1.10:2200/json/device_description.

Für die Darstellung von Geräte- oder Diensteigenschaften sollten die Namen (also z.B. die XML- oder JSON-Tags) festgelegt werden, um ein automatisiertes Parsing zu vereinfachen. Gleichzeitig sollte eine Art Lookup-Tabelle existieren, die gleichwertige Bezeichnungen gegenüberstellt (z.B. "42 == DeviceID == GeräteID" oder "44 == DeviceName == Gerätename"). Damit ist eine einfache Konvertierung zwischen Binärformat, JSON und XML ohne weitere Metadaten möglich.

Aktivitätsmodell

Aus unserer Sicht sollte das Elektor-Protokoll ähnlich wie UPnP und appicals ein Aktivitätsmodell besitzen, welches aus den Phasen Entdeckung, Beschreibung, Kontrolle und Ereignisse besteht.

Entdeckung erlaubt das Erkennen neu gesteckter Geräte. Dies ist die einzige Phase, die nicht über TCP/IP und REST laufen kann, da die Geräteadressen und -ports initial nicht bekannt sind. Eine mögliche Lösung ist die Nutzung von UDP Broadcasts oder UDP Multicasts. Darüber hinaus könnten sich Geräte an einer wohlbekannten Adresse wie z.B. http://192.168.1.10:2200/bin/register oder http://192.168.1.10:2200/json/register anmelden.

Beschreibung enthält Daten zum Identifizieren einzelner Geräte über einen Klarnamen oder eine eindeutige ID. Sie enthält außerdem die verfügbaren Dienste sowie den aktuellen Ort.

Über Kontrollnachrichten werden aktuelle Zustände abgefragt oder Aktoren geschaltet. Dies geschieht in REST über GET und POST-Nachrichten, z.B. http://192.168.1.10:2200/xml/raspi1/temperature/service_value oder http://192.168.1.10:2200/xml/tablet/rgb/service_value

Event-Nachrichten informieren Klienten über Änderungen in Diensten. Mögliche Mechanismen sind Broadcast-Nachrichten (vergleichbar zur Entdeckungs-Aktivität), offen gehaltene TCP-Verbindungen (vergleichbar zu Ajax) oder Subscribe-Modelle (vergleichbar zu UPnP). Subscribe-Modelle haben sich in UPnP als Flaschenhals herausgestellt, so dass dieser Weg aus unserer Sicht nicht optimal ist.

Dienststandardisierung

Um die automatisierte Weiterverarbeitung von Daten zu vereinfachen, sollten die Geräte ihre Messwerte und Aktoren über vordefinierte Dienste zur Verfügung stellen. Anderenfalls ist es ein immenser Aufwand, auf die Messwerte verschiedener Geräte zuzugreifen, da jede App und jedes Programm wissen muss, wie verschiedene Geräte z.B. Temperaturwerte ausliefern (Gerät 1 nutzt dann z.B. das Tag "Temperatur", Gerät 2 "Kühlschrank innen" und Gerät 3 "OutdoorTemperature").

Wir empfehlen wie in appicals die Definition weniger Basisdienste, z.B. DigitalInput, RelativeInput und SensorInput. Damit ist sichergestellt, dass z.B. Temperaturwerte immer das gleiche Format benutzen und Apps auch Daten vorher unbekannter Geräte sinnvoll verarbeiten können.