MQTT – eine Einführung

Wer Daten von A nach B übermitteln möchte, hat unzählige Möglichkeiten dies zu tun. Je nach Anforderung und Anwendungsfall sieht die ideale Möglichkeit der Datenübermittlung anders aus. Für die Kommunikation zwischen Sensoren und im IoT-Bereich hat das Protokoll MQTT den Standard gesetzt. Immer dort wo verteilte Systeme miteinander kommunizieren müssen, eignet sich MQTT. MQTT steht für Message Queue Telemetry Transport und ist architektonisch relativ einfach aufgebaut. MQTT ist Nachrichten-orientiert und zentralisiert.

Die MQTT-Architektur

Für MQTT wird ein Broker benötigt, die zentrale Instanz an welche alle Clients ihre Nachrichten senden und sie von diesem Broker empfangen. Im Umkehrschluss bedeutet dies, das sich die Clients untereinander nicht kennen. Die gesamte Kommunikation läuft über dem Broker ab. Die Nachrichten werden nicht einfach wahllos an den Broker geschickt, sondern an ein sogenanntes Topic, ein Thema z.B. bad/lichtsensor1. Diese Topics sind hierarchisch aufgebaut und werden wie ein Pfad, mit einem Slash als Trennzeichen, definiert. Die Topics können von anderen Clients abonniert werden, so das diese bei einer neuen Nachricht betreffend des Topics informiert werden. Durch den hierarchischen Aufbau ist es möglich alle Topics einer bestimmten Hierarchieebene zu abonnieren. So würde der Topic:

bad/#

alle Untertopics von bad abonnieren. Eine weitere Möglichkeit ist es an einer bestimmten Stelle im Pfad das Sonderzeichen Plus zu benutzen:

+/lautsprecher/

In diesem Beispiel würden alle Lautsprecher aller Zimmer abonniert, so wären bad/lautsprecher als auch wohnzimmer/lautsprecher abgedeckt.

Nach der Verbindung mit einer CONNECT-Nachricht antwortet der Broker mit einer CONNACK-Nachricht. Damit ist die Verbindung etabliert. Der Client abonniert in dem Beispiel (siehe Bild) den Topic bad/lichtsensor1. Nun kann der Broker den Client über Nachrichten dieses Topic betreffend informieren. Wenn eine solche Nachricht eingeht, reagiert der Client, indem er auf dem Topic bad/lautsprecher die Nachricht bzw. den Wert on hinterlässt. Soll die Verbindung später wieder beendet werden, so wird eine DISCONNECT-Nachricht gesendet.

Die Kommunikation zwischen Client und Broker

Wenn ein Client keine aktive Verbindung zum Broker hat und eine neue Nachricht auf einem Topic aufläuft, auf welches der Client ein Abonnement hält, so verpasst er diese Nachricht. Anders sieht es aus, wenn der Sender beim Senden der Nachricht das sogenannte Retain-Flag für die Nachricht gesetzt hat. In diesem Fall stellt der Broker die Nachricht später noch zu.

Für den Fall, das die Verbindung vom Client nicht beendet wird bzw. beendet werden kann, existiert in MQTT ein sogenanntes Testament. So kann es bei Sensoren, die über Batterien gespeist sind durchaus vorkommen, dass die Verbindung plötzlich abbricht. Deshalb kann ein Client ein Testament, eine Nachricht auf ein Topic, hinterlegen, welche im Falle des Verbindungsabbruches vom Broker über das Topic versendet wird.

In der Praxis existieren zwei Versionen von MQTT: MQTT 3 welches die größte Basis besitzt und MQTT 5, welches mit einigen Neuerungen aufwarten kann, um das Protokoll fit für die Zukunft zu machen. Spezifiziert wird MQTT von OASIS, der Organization for the Advancement of Structured Information Standards. Die größten Unterschiede zwischen der letzten 3er-Version 3.1.1 und 5 sind Shared Subscriptions, welche Load Balancing auf Clientseite erlauben, Negative Acks eine Art Statuscodes ähnlich den HTTP-Statuscodes und User Properties, bei denen es sich um die Entsprechung zu den HTTP-Headern handelt. Diese können unter anderem für Metadaten genutzt werden. Ergeben haben sich diese Neuerungen hauptsächlich durch die Rückmeldungen aus der Community über die letzten Jahre.

Das OSI-Modell

Technisch basiert das MQTT-Protokoll auf TCP/IP. Dabei werde die Ports 1883 und 8883 genutzt. Der erste Port ist für die unverschlüsselte, der zweite Port für die verschlüsselte Kommunikation reserviert. Im OSI-Schichtenmodell befindet sich MQTT, wie HTTP auf dem Application Layer (OSI Layer 7). Im Gegensatz zu HTTP ist MQTT bleibt die Verbindung bei MQTT auch bestehen, wenn keine Daten übertragen werden.

Gestartet wird die Kommunikation des Clients mit einer CONNECT-Nachricht, woraufhin der Broker das Ganze mit einer CONNACK-Nachricht bestätigt. Nun kann der Client Topics abonnieren und Informationen zu einem Topic senden (PUBLISH).

MQTT beherrscht drei verschiedene Stufen des Quality of Service (QoS). Stufe 0 ist vom Modell her Fire-and-Forgot; die Nachricht wird einmal versendet und danach vom Broker vergessen. Ob sie ankommt, ist auf dieser QoS-Stufe nicht relevant. Bei Stufe 1 garantiert der Broker das die Nachricht mindestens einmal zugestellt wird, sie kann aber durchaus auch mehrfach bei den Clients ankommen. Stufe 2 hingegen garantiert, dass die Nachricht exakt einmal ankommt. Offiziell sind die QoS-Stufen wie folgt benannt:

At most once (0)
At least once (1)
Exactly once (2)

Je nach gewählter QoS-Stufe kommt es zu vermehrter Kommunikation über das MQTT-Protokoll. Bei Stufe 1 würde die Gegenstelle nach einer PUBLISH-Nachricht mit einer PUBACK-Nachricht antworten. Ohne eine solche Nachricht wird bei Stufe 1 der Sendevorgang so lange wiederholt, bis er von der Gegenseite bestätigt wurde. Deshalb ist nicht sichergestellt das die Nachricht nur einmal ankommt.

Wenn dies nicht gewünscht ist, kann stattdessen die QoS-Stufe 2 genutzt werden. Hier wird in der PUBLISH-Nachricht vom Sender eine ID mitgegeben. Nach dem Empfang wird die Nachricht gespeichert, aber noch nicht verarbeitet. Der Empfänger sendet eine PUBREC-Nachricht mit der ID an den Sender. Erhält der Sender diese Nachricht, sendet er eine Release-Nachricht (PUBREL), an den Empfänger. Als letzte Aktion sendet Empfänger ein PUBCOMP-Nachricht an den Sender und verarbeitet anschließend die Nachricht. Der Sender löscht beim Empfang der PUBCOMP-Nachricht die Nachricht.

Hintergrund für die unterschiedlichen Qualitätsstufen ist der Ressourcenverbrauch; je niedriger die QoS-Stufe um so weniger Ressourcen wie Zeit, Speicher und CPU, werden benötigt, um die Nachricht zu verarbeiten.

An Brokern und Client-Bibliotheken mangelt es MQTT nicht. Zu den bekanntesten Brokern gehören Mosquitto, HiveMQ und VerneMQ. Im Produktivbetrieb muss auf eine Absicherung der Topics geachtet werden. So ist es je nach Broker möglich das diese eine Authentifizierung der Clients verlangen und erst dann den Zugriff auf die Topics erlauben. Client-Bibliotheken für MQTT gibt es wie Sand am Meer, für unterschiedlichste Systeme wie Arduino, C, Java, .NET, Go und viele weitere Sprachen und Frameworks.

MQTTBox unter macOS

Daneben existieren grafische Client, welche die Nachrichten auf dem Broker anzeigen und die Interaktion mit einem Broker ermöglichen. Zu diesen Clients gehören unter anderem MQTT.fx, mqtt-spy und MQTTBox.

Arduino für den Industrieeinsatz

Die Arduino-Familie ist im Grundsatz für das schnelle Prototyping gedacht. Der Einsatz in Industrieumgebungen ist also nicht allzu empfehlenswert. Das haben sich die Macher des Controllino ebenfalls gedacht. Finanziert über Kickstarter, entwickelten sie eine speicherprogrammierbare Steuerung, welche Arduino-kompatibel ist und sich für den Industrieeinsatz eignet.

controllino.biz

Der Controllino verfügt, je nach Modell, über bis zu 21 Eingänge, 24 Ausgänge, 16-Relay-Ausgänge und unterschiedlichste Interfaces zur Ansteuerung, wie I2C oder SPI. Daneben verfügt er über einen USB- und einen Ethernet-Anschluss. Ebenfalls integriert ist eine Real time clock. Bezogen werden kann der Controllino über die offizielle Seite unter controllino.biz. Preislich bewegen sich die Controller in einem Bereich von ein- bis dreihundert Euro, je nachdem welches Modell gewählt wird.

Testprogramm für den ESP8266

Beim Setup, zur Nutzung des Mikrocontrollers ESP8266, wird ab und an ein Programm benötigt um die Funktionsweise des Controllers bzw. des Flashvorgangs zu testen. Der einfachste Weg dies zu testen ist es die integrierte LED des Controllers zu nutzen. Dazu wird folgendes Programm benötigt:

void setup() {
  pinMode(2, OUTPUT);
}

void loop() {
  digitalWrite(2, LOW);   
  delay(250);            
  digitalWrite(2, HIGH);  
  delay(250);
}

Das Programm definiert PIN 2 des Controllers als Ausgang und sendet anschließend alle 250 Millisekunden ein Signal an diesem PIN. Dies führt dazu, dass die eingebaute LED des Controllers in kurzen Abständen blinkt und somit das Setup und der Controller getestet werden kann.

Größe des Flashspeichers beim NodeMCU ermitteln

Das auf dem ESP8266 basierendem Entwicklungsboard NodeMCU gibt es unterschiedlichen Varianten, die sich unter anderem durch die Größe des Flashspeichers unterscheiden. Möchte man nun ermitteln welche Größe der Speicher beim eigenen NodeMCU-Board hat kann man dies mit einem Programm aus einem der ESP8266-Repositories sehr unkompliziert ermittelt.

Die Größe des Flashspeichers wird über die serielle Schnittstelle ausgegeben

Nachdem die Arduino IDE mit dem Programm geöffnet wurde und das Programm auf das NodeMCU-Board geflasht wurde, kann die Ausgabe über die serielle Schnittstelle ausgelesen werden. Dazu muss der serielle Monitor, im Menü unter Werkzeuge -> Serieller Monitor zu finden, aktiviert werden. Wichtig ist es, dass hier die korrekte Baudrate eingestellt wird.

ESP8266 auf einem Developer-Board unter macOS in Betrieb nehmen

Der ESP8266 ist ein Mikrocontroller welcher vor allem aufgrund seines Preises und seiner Fähigkeiten sehr beliebt in der Bastlerszene ist. Während er ursprünglich als WLAN-Shield für den Arduino und Konsorten gedacht war, wird er immer öfter direkt genutzt. Das sollte auch nicht verwundern, schließlich sind viele Leistungswerte des ESP8266 einem gewöhnlichen Arduino überlegen. Mittlerweile gibt es vom ESP8266 14 Varianten die von ESP-1 bis ESP-14 durchnummeriert sind.

Das NodeMCU-Board

Der einfache Einstieg gelingt mit gelingt am besten mit einem ESP8266-Entwicklerboard. Diese verfügen meist über NodeMCU. Das NodeMCU-Modul basiert dabei auf einem ESP-12. Da der ESP8266 3,3 Volt benötigt, USB allerdings 5 Volt liefert, löst das Entwicklerboard viele Probleme, da es bereits einen Spannungsteiler an Bord hat. Für die Anbindung per seriellem Interface wird unter macOS ein Treiber benötigt. Dieser kann unter anderem auf GitHub gefunden werden. Nach der Installation des Treibers muss der Entwicklungsrechner neu gestartet werden.

Nach der Treiberinstallation kann die Schnittstelle angesprochen werden

Nach dem Neustart kann die Arduino IDE geöffnet werden. Da das Board nicht von Haus aus unterstützt wird, muss eine weitere Konfiguration für den Board Manager hinzugefügt werden. Dazu öffnet man die Einstellungen der Arduino IDE und wählt dort den Punkt Zusätzliche Boardverwalter-URLs aus. Dort fügt man nun die URL:

http://arduino.esp8266.com/stable/package_esp8266com_index.json

hinzu. Anschließend können die Einstellungen geschlossen werden und der Board Manager geöffnet werden. Im Board Manager wird nun nach ESP8266 gesucht und die entsprechende Unterstützung installiert.

Die Unterstützung für die ESP8266-Boards wird installiert

Nachdem die Unterstützung für das Board installiert wurde, muss das ganze noch korrekt konfiguriert werden. In diesem Beispiel wurden folgende Einstellungen genutzt:

Board: "NodeMCU 1.0 (ESP-12E Module)"
CPU Frequency: "80 MHz"
Flash Size: "4M (3M SPIFFS)"
Upload Speed: "9600"
Port: "/dev/cu.wchusbserial1410"

Als Beispiel-Programm bietet sich das Webserver-Beispiel an. Nachdem das Beispielprogramm in der Arduino IDE gelandet ist, kompiliert und hochgeladen wurde kann der erste Test des ESP8266 durchgeführt werden. Dazu muss im Browser die IP-Adresse des Gerätes oder alternativ die URL: http://esp8266.local aufgerufen werden.