Die Eignung für eine zuverlässige und effiziente Kommunikation auch über instabile Mobilfunk-Netze und die Vernetzung vieler Tausender Geräte ist in vielen Situation gefragt. Deshalb zählt MQTT (Message Queue Telemetry Transport) inzwischen zu einem der wichtigsten Protokolle im Internet der Dinge.

MQTT hat sich in den letzten Jahren zu einem wichtigen Nachrichtenprotokoll im Bereich IoT durchgesetzt. Mit ihm werden Informationen leichtgewichtig nach dem Publish-Subscribe Pattern übermittelt. Gerade bei einem hohen Nachrichtenaufkommen kann eine Broker-Architektur von Nutzen sein. Mit ihr werden periodische Abfragen von Nachrichten nach dem „Request-Reply“ Muster vermieden.

Das ist einer der Gründe, warum die IoT-Plattformen der großen Anbieter Oracle, Microsoft und Amazon dieses Protokoll unterstützen. Auch mit den Ansätzen im IoT-Umfeld passt es gut zusammen, Zustandsänderungen und damit Events/Ereignisse zu kommunizieren.

Im Zentrum der Kommunikation steht ein Server („Broker“), der Nachrichten sammelt und verteilt. Mit ihm verbinden sich „Clients“ und veröffentlichen Nachrichten bzw. abonnieren sie zu einem bestimmten Thema („Topic“). Der Broker nimmt die Nachrichten entgegen und verschickt sie automatisch („push“) an die Clients, die das Topic abonniert haben.

Topics werden hierarchisch aufgebaut und mit einem „/“ getrennt.

Beispiel: /Wohnung/Wohnzimmer/Heizung/Temperatur.

Um mehrere Topics zu einer Ebene zu abonnieren, gibt es Wildcards. Mittels „+“ wird eine Ebene abonniert, über „#“ können mehrere Ebenen abonniert werden.  /Wohnung/+/Heizung/Temperatur abonniert beispielsweise die Heizungstemperatur in allen Zimmern, /Wohnung/Badezimmer/# alle Badezimmerdaten.

Über die Quality of Service kann jeder Client festlegen, in welchem Umfang die Nachrichtenübertragung garantiert werden soll. Das reicht von maximal ein Mal (Level 0) über mindestens ein Mal (Level 1) zu genau ein Mal (Level 2). Je höher der Level ist, desto mehr Daten müssen für die Sicherstellung des Levels gesendet werden.

Die Verfügbarkeit IoT-fähiger Geräte kann stark schwanken. Beispielsweise können Straßenbahnen die Verbindung zur Zentrale verlieren, wenn sie in einen Tunnel fahren. In diesem Fall kann der Client beim Broker eine Nachricht hinterlegen, die bei einem Verbindungsabbruch gesendet wird. Dies wird als „Last Will and Testament“ bezeichnet. Im Fall der Straßenbahn könnte das die letzte ermittelte Position sein.

Damit Clients bei einem neu abonnierten Topic  nicht darauf warten müssen, bis ein neuer Wert gepusht wird, kann die zuletzt gesendete Nachricht standardmäßig an den neuen Abonnenten verschickt werden. Nachrichten, die vom Client dafür markiert wurden, werden „Retained Messages“ genannt.

https://mqtt.org

Open-Source-MQTT-Broker (beim CMatic-Automatisierungssystem vorinstalliert): https://mosquitto.org

Open-Source-Werkzeug zur Entwicklung, Integration und Visualisierung von MQTT Topic: https://mqttfx.jensd.de