In der letzten Folge habe ich über TCP berichtet, ein klassisches Protokoll, mit dem sich IP-Pakete zwischen zwei Sockets (Netzteilnehmer mit jeweils IP-Adresse und Port) austauschen lassen. TCP kümmert sich darum, dass die Pakete auch ankommen. Da viele Programmiersprachen Funktionen zur Socket-Programmierung mitbringen, lässt sich mit einem einfachen (selbst erfundenen) Anwendungsprotokoll schon eine kleine, recht verlässliche Steuerung programmieren. Es reicht, etwa die Bytes „ON“, „RED“ oder „3“ als TCP/IP-Nutzlast zu verschicken.

Bei typischen IoT-Aufgaben wie der Erfassung von Umweltmesswerten oder der Hausautomatisierung hat man es aber mit vielen Teilnehmern zu tun. Es gibt Knoten, die Daten produzieren und welche, die Daten konsumieren, etwa zur Weiterverarbeitung und Anzeige. Man muss auch damit rechnen, dass Knoten nicht immer online sind. Glücklicherweise gibt es hier bereits ein effizientes Protokoll, das auf TCP/IP aufsetzt und für solche Aufgaben prädestiniert ist: MQTT. Statt auf direkte Verbindungen zwischen Datenproduzenten und Datenkonsumenten setzt das bereits um die Jahrtausendwende entwickelte Protokoll auf einen Message-Broker, der Nachrichten weiterverteilt. Bei diesem Broker können sich Datenproduzenten (wie zum Beispiel Sensorknoten) und Konsumenten (wie zum Beispiel Smartphone-Apps) anmelden. Der Message-Broker verwaltet dann auch die Liste der IP-Adressen, der Entwickler/Nutzer muss sich die kryptischen Zahlenfolgen nicht mehr merken. Datenproduzenten wie Sensorknoten teilen dem Broker bei der Anmeldung mit, dass Messwerte unter einem bestimmten „Thema“ oder Topic veröffentlicht werden (publish). Solche Topics sind einfach zu merkende Zeichenketten wie zum Beispiel:

Gebäude/Büro/Temperatur
Gebäude/Küche/Temperatur

Um solche Daten etwa mit einer Smartphone-App zu empfangen, kann diese bestimmte Topics abonnieren (subscribe), wobei auch Wildcards zulässig sind, etwa:

Gebäude/+/Temperatur

Doch MQTT kann noch mehr: Es stellt bei Bedarf (zusätzlich zur Sicherung durch TCP) sicher, dass Daten auch ankommen. Wobei es hier gleich drei Servicequalitäten gibt (0 = egal, 1 = kommt mindestens 1x an, 2 = kommt genau 1x an). Sehr nützlich ist auch der „letzte Wille“ (last will). Alle Knoten (Clients) können beim Message-Broker eine Nachricht pro Topic hinterlegen, die beim Unterbrechen der Verbindung an alle verschickt wird, die das Topic abonniert haben. Pro Topic kann der Broker auch eine „gehaltene Nachricht“ (retained message) speichern; diese bekommen immer alle neu angemeldeten Abonnenten. Sinnvoll ist das etwa für Sensoren, die nur ab und zu Daten übermitteln: So steht der letzte Messwert immer allen zur Verfügung.

Es lohnt sich auf jeden Fall, sich mit dem Protokoll näher zu beschäftigen, denn das ganze Protokoll ist erstens in Händen der Open-Source-Community und zweitens wird es von einigen bekannten Playern auf dem IoT-Markt genutzt.
Wir machen weiter in der nächsten Folge!

Offizielle MQTT-Seiten:
http://mqtt.org/

Lesetipp (deutsch):
www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html

Lesetipp (englisch):
www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt