Messaging-Protokoll für das IoT Einstieg in die IoT-Kommunikation mit MQTT

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

QUNIS GmbH

Confluent Germany GmbH

HiveMQ GmbH

MQTT hat sich in den vergangenen Jahren zum Standardprotokoll für die IoT-Kommunikation von Geräten und Applikationen entwickelt. Doch was hat es mit dem Protokoll auf sich und wie setzt man es ein?

Wer sich in den vergangenen Jahren mit der Implementierung von über das Internet vernetzter Software und Hardware beschäftigt hat, dem wird sehr wahrscheinlich der Name „MQTT“ (Message Queue Telemetry Transport) über den Weg gelaufen sein. Das aus heutiger Sicht mit Abstand populärste Kommunikationsprotokoll für das Internet of Things (siehe Bild 1) bietet viele Funktionen, die das Leben von Anwendungsentwicklern sehr einfach gestalten um eine verlässliche, sichere, wartbare und performante Kommunikation der eigenen Applikation mit anderen Geräten, Cloud-Backenddiensten oder mobilen Applikationen zu implementieren.

Bildergalerie

MQTT ist in erster Linie ein Messaging Protokoll für das IoT. Anders als Request/Response-Protokolle wie HTTP oder CoAP entkoppelt es alle Kommunikationsteilnehmer und der Datenaustausch wird über das Senden von Nachrichten über einen zentralen Verteiler an interessierte Teilnehmer implementiert, weshalb kein intrinsisches Wissen über andere Applikationen und Endpunkte vorhanden sein muss. Das MQTT-Protokoll ist extrem schlank und wurde ursprünglich für sehr ressourcenarme Geräte entwickelt die über sehr schlechte Connectivity verfügen. Daher ist MQTT ideal geeignet für den Einsatz mit Mikroprozessoren oder die Embedded-Entwicklung im Allgemeinen. Die perfekte Eignung von MQTT für IoT Anwendungsfälle ist nicht verwunderlich, da das Protokoll 1999 für SCADA-Systeme entwickelt wurde, welche über Satellitenkommunikation Daten senden und empfangen sollten. Ein minimales und extrem schlankes Protokoll war deshalb das erklärte Designziel.

Natürlich hat sich MQTT seit 1999 weiterentwickelt, mittlerweile ist MQTT Version 3.1.1 ein offizieller OASIS- und ISO-Standard (ISO/IEC 20922:2016) und der Nachfolger, MQTT 5, wurde 2018 final spezifiziert. Heute ist das Protokoll der Standard wenn es um die Vernetzung für das Internet of Things, Heimautomatisierung oder aber auch Vernetzung im Kontext Industrie 4.0 geht.

Grundlegende Funktionsweise: Publish/Subscribe-Architektur

MQTT implementiert das Publish/Subscribe-Pattern (Bild 2). Jede Kommunikation findet über einen zentralen Verteiler, den so genannten MQTT Message Broker, statt. Eine jede Nachricht, die ein Client sendet, enthält neben dem so genanntem „Topic“ die tatsächlichen Nutzdaten.

Ein Topic ist ein Metadatum in jeder zu sendenden MQTT-Nachricht. Das Topic ist ein Text, welcher Trennzeichen enthalten kann, und er kann, ähnlich dem POSIX-Dateisystempfad, eine Hierarchie abbilden (siehe Bild 3). Jeder MQTT-Client, der Nachrichten für dieses Topic empfangen möchte, abonniert es beim Message Broker. Dabei kann ein Abonnement direkt auf ein konkretes Topic erfolgen oder es können durch sog. Wildcards ganze Teilbäume der Topic-Hierarchie abonniert werden. Da die interessierten Clients beim Eintreffen neuer Nachrichten durch den Broker benachrichtigt werden, anstatt selbst beim Server nach Änderungen zu fragen, wird eine hocheffiziente Kommunikation zwischen den Teilnehmern gewährleistet. Somit ist eine echte Push-Kommunikation zwischen allen Kommunikationsteilnehmern möglich. Entscheidend ist, dass die Geräte und Applikation komplett entkoppelt sind, da jeder Client nur den Message Broker kennt, nicht jedoch die anderen Teilnehmer. Mit MQTT ist eine 1:N-Kommunikation abbildbar, es ist also möglich, dass eine einzelne Nachricht von einem Teilnehmer an einen Topic versendet wird, jedoch mehr Abonnenten die Nachricht vom Broker zugestellt bekommen können. Natürlich kann ein einzelnes Gerät bzw. eine einzelne Applikation sowohl Daten senden als auch empfangen.

Eine echte Push-Kommunikation ist dadurch möglich, dass ein Client zu Beginn der MQTT-Kommunikation sich beim Broker anmeldet und eine TCP-Verbindung aufbaut. Diese TCP-Verbindung wird (im Idealfall) konstant offen gehalten. Durch die Bidirektionalitätseigenschaften von TCP kann der Broker somit an verbundene MQTT Clients Nachrichten sofort ausliefern. Für nicht verbundene Clients werden die verpassten Nachrichten bei Bedarf vom Broker gepuffert und ausgeliefert sobald diese Clients wieder verbunden sind. Ein MQTT Broker selbst baut selbst niemals eine TCP-Verbindung zu einem Client auf, es ist zwingend erforderlich, dass ein Client die Verbindung selbst aufbaut, weshalb Geräte nicht von außen adressierbar sein müssen um an einer MQTT-Kommunikation teilzunehmen.

MQTT – Topics und Features

MQTT besitzt neben dem reinen Push-Messaging durch die Publish/Subscribe-Architektur eine Reihe von bemerkenswerten Protokollfeatures, die im Kontext von IoT, Mobile Applications und Embedded Applications optimal sind:

• Unterschiedliche Quality of Service Level: Um sicherzustellen, dass eine gesendete Nachricht beim Empfänger ankommt, definiert MQTT drei verschiedene Quality-of-Service-Levels (QoS), mit denen eine Nachricht gesendet werden kann: at most once (0), at least once (1) und exactly once (2). Das Protokoll stellt die Nachrichtengarantien auch sicher wenn zwischendurch die Verbindung getrennt und neu aufgebaut wurde.

• Retained Messages: Die letzte gesendete Nachricht eines Topics kann wahlweise am Broker hinterlegt werden. Jeder neue Subscriber auf diesem Topic erhält automatisch die zuletzt gesendete Nachricht für den Topic. Damit kann ein neuer Subscriber gleich mit dem letzten Wert arbeiten und muss nicht warten bis eine neue Nachricht für einen Topic eintrifft um initial Daten zu erhalten.

• Last Will and Testament: Ein Client kann eine MQTT-Nachricht als „Letzten Willen“ beim Verbindungsaufbau am Broker hinterlegen. Wenn der Broker feststellt, dass dieser Client nicht mehr verbunden ist und der Client sich vorher nicht ordentlich abgemeldet hat, wird dieser Letzte Wille an alle Subscriber versendet. Der Broker ist also verantwortlich dafür, den letzten Willen des Clients auszuführen. Somit ist es sehr einfach möglich Benachrichtigungen zu implementieren für den Fall, dass ein Gerät unerwartet die Verbindung verliert.

• Persistent Sessions: In Anwendungsfällen, bei denen mit häufigen Verbindungsabbrüchen von Clients zu rechnen ist, kann der Broker eine persistente Session vorhalten. Wenn ein Client sich erneut verbindet, sendet der Broker alle für ihn verpassten Nachrichten an den Client. Natürlich muss der Client sich nicht neu auf vorher abonnierte Topics subscriben, da der Broker die vorherige Session einfach fortführt. Für den Applikationsentwickler bedeutet das, dass dieser einfach davon ausgehen kann, dass nach einem Verbindungsabbruch und einem Neuverbinden die Applikation so fortfahren kann wie wenn es den Verbindungsabbruch nicht gegeben hätte.

Neben den Standardprotokollfeatures bieten viele MQTT Broker, wie etwa der für den professionellen Einsatz konzipierte HiveMQ, etliche Funktionalitäten die den Einsatz von MQTT noch einfacher machen und bringen ein Plug-in-System mit, mit welchem Applikationslogik am MQTT Broker nachgerüstet werden kann, wie etwas das Speichern von Nachrichten in Datenbanken oder anderen externen Systemen.

MQTT 5 – Ein neuer Standard

MQTT 5, der offizielle Nachfolger von MQTT 3.1.1, wurde 2018 von OASIS veröffentlicht. Neben der vorgestellten Funktionalität bietet die neue Version des Protokolls zahlreiche Verbesserungen und Neuerungen die speziell in großen IoT Szenarios das Leben der Applikationsentwickler vereinfachen. Unter anderem wurden Custom Header, Verbessertes Fehlerhandling, Message & Session Expiry, Shared Subscriptions, Flow Control und Vieles mehr eingeführt. Manche der neuen Features wie etwa Shared Subscriptions – eine Lastverteilung für Subscriber – und Session Expiry sind bereits für MQTT 3.1.1 mit Brokern wie HiveMQ verfügbar.

Direkter Einstieg in MQTT

Um als Entwickler direkt starten zu können benötigt man einen MQTT Broker und eine MQTT-Client-Bibliothek. Zum Start empfiehlt sich der MQTT Broker Mosquitto, der in C geschrieben ist und ideal geeignet ist um auf ressourcenarmer Hardware betrieben zu werden. Für Cloud Deployments eignet sich der in Deutschland entwickelte MQTT Broker HiveMQ, der speziell für Hochverfügbarkeit und professionelle Umgebungen ausgelegt ist.

Um auf der Applikationsseite direkt starten zu können eignet sich das Eclipse-Paho-Projekt. Hier findet man MQTT-Implementierungen sowohl für C, C++, Java und exotischeren Programmiersprachen wie etwa Go oder Rust. Für Cloud-Backend-Dienste eignet sich die MQTT Bibliothek MQTT Bee.

Als zusätzliche Lektüre für Leser, die technisch tiefer einsteigen wollen, empfiehlt sich „MQTT Essentials“. Wer mehr über MQTT 5 erfahren möchte, kann dies auf mqtt5.com tun.

MQTT ist mittlerweile das Standardprotokoll für die Internet-of-Things-Kommunikation. Durch die Entkopplung aller Kommunikationsteilnehmer, die Einfachheit in der Benutzung und die ressourcenschonenden Eigenschaften eignet es perfekt für die Entwicklung von Applikationen für das IoT. Zusätzliche Features wie Retained Messages, Last-Will-and-Testament, Persistent Sessions und QoS Level machen es Entwicklern leicht, Applikationen zu entwickeln die resilient und wartbar sind. Von der Heimautomatisierung bis zu komplexen Deployments mit mehreren Millionen von gleichzeitig verbundenen Fahrzeugen oder anderen Geräten, MQTT ist der Standard für die Vernetzung von Maschinen und Applikationen und sollte in keiner Toolbox von Entwicklern im IoT fehlen.

Dieser Artikel stammt von unserem Partnerportal Elektronikpraxis . Verantwortlicher Redakteur: Sebastian Gerstl

* Dominik Obermaier ist Geschäftsführer bei der dc-square Gmbh

(ID:45362641)