MQTT – Message Queuing Telemetry Transport
MQTT (Message Queuing Telemetry Transport) ist ein Nachrichtenprotokoll für eingeschränkte Netzwerke mit geringer Bandbreite und IoT-Geräte mit extrem hoher Latenzzeit. Da Message Queuing Telemetry Transport auf Umgebungen mit niedriger Bandbreite und hoher Latenz spezialisiert ist, ist es ein ideales Protokoll für die Machine-to-Machine-Kommunikation (M2M).
MQTT funktioniert nach dem Publisher- / Subscriber-Prinzip und wird über einen zentralen Broker betrieben. Das bedeutet, dass Sender und Empfänger keine direkte Verbindung haben. Die Datenquellen melden ihre Daten über einen Publish und alle Empfänger mit Interesse an gewissen Nachrichten (“gekennzeichnet durch den Topic”) bekommen die Daten zugestellt, da sie sich als Subscriber angemeldet haben.
Im IoT und IIoT wird MQTT bis hin zu Anbindung von Cloud-Umgebungen eingesetzt. Erfahren Sie alles, was Sie über den Einsatz von MQTT wissen müssen in unserer praxisnahen Erklärung mit industriellem Fokus, sowie dem Praxiseinsatz von MQTT.
Ein detailliertes Video zu diesem Thema finden Sie hier in unserem Tutorial-Stream.
Inhaltsverzeichnis
1. Wofür steht MQTT?
MQTT steht für Message Queuing Telemetry Transport. Es ist ein extrem einfaches und leichtes Messaging-Protokoll (subscribe and publish), das für eingeschränkte Geräte und Netzwerke mit hoher Latenz, geringer Bandbreite oder unzuverlässigen Netzwerken entwickelt wurde. Die Konstruktionsprinzipien dienen dazu, die Anforderungen an die Netzwerkbandbreite und die Ressourcen von Geräten zu verringen und die Sicherheit der Versorgung gewährleisten zu können. Außerdem sind diese Prinzipien für M2M (Machine-to-Machine) oder IoT-Geräte von Vorteil, da die Akkuleistung und die Bandbreite sehr wichtig sind.
2. Was ist ein MQTT-Topic?
Mit MQ Telemetry Transport können ressourcenbeschränkte IoT-Geräte Informationen zu einem bestimmten Topic (Thema) an einen Server senden oder veröffentlichen, der als MQTT-Nachrichtenbroker fungiert. Der Broker überträgt die Informationen dann an diejenigen Clients, die das Topic des Clients zuvor abonniert haben. Für einen Menschen sieht ein Thema wie ein hierarchischer Dateipfad aus. Clients können eine bestimmte Hierarchieebene eines Topics abonnieren oder ein Platzhalterzeichen verwenden, um mehrere Stufen zu abonnieren.
Das MQTT-Protokoll ist eine gute Wahl für drahtlose Netzwerke, die aufgrund gelegentlicher Bandbreiteneinschränkungen oder unzuverlässiger Verbindungen unterschiedliche Latenzzeiten aufweisen. Sollte die Verbindung von einem abonnierenden Client zu einem Broker unterbrochen werden, puffert der Broker die Nachrichten und sendet sie an den Abonnenten, wenn dieser wieder online ist. Wenn die Verbindung vom Publishing-Client zum Broker ohne Benachrichtigung getrennt wird, kann der Broker die Verbindung trennen und den Abonnenten eine zwischengespeicherte Nachricht mit Anweisungen des Publishers senden.
3. Was ist ein MQTT-Broker?
Der MQTT-Broker steht im Mittelpunkt jedes Publish / Subscribe-Protokolls. Abhängig von der Implementierung kann ein Broker bis zu Tausende gleichzeitig verbundene MQTT Client verwalten. Der Broker ist dafür verantwortlich, alle Nachrichten zu empfangen, die Nachrichten zu filtern, zu bestimmen, wer die einzelnen Nachrichten abonniert hat, und die Nachricht an diese abonnierten Clients zu senden. Der Broker hält auch die Sitzungen aller persistenten Clients ab, einschließlich Abonnements und entgangenen Nachrichten. Eine weitere Aufgabe des Brokers ist die Authentifizierung und Autorisierung von Clients. Normalerweise ist der Broker erweiterbar, was die benutzerdefinierte Authentifizierung, Autorisierung und Integration in Backend-Systeme erleichtert. Die Integration ist besonders wichtig, da der Broker häufig die direkt im Internet offengelegte Komponente ist, viele Clients bedient und Nachrichten an nachgelagerte Analyse- und Verarbeitungssysteme weiterleiten muss. Kurz gesagt, der Broker ist der zentrale Knotenpunkt, durch den jede Nachricht geleitet werden muss. Daher ist es wichtig, dass Ihr Broker hochgradig skalierbar, in Backend-Systeme integrierbar, einfach zu überwachen und natürlich ausfallsicher ist. In der Industrie verwendete MQTT-Broker sind z.B. der HiveMQ MQTT Broker und EMQX. Auch Cloud-Anbieter wie Microsoft und Amazon stellen mit Azure IoT Hub und AWS IoT Core eigene MQTT-Broker zur Verfügung.
4. Was ist eine MQTT-Payload?
Mit MQTT werden Nachrichten über einen Broker mit anderen Geräten oder Software geteilt. Jede Nachricht verfügt über ein Topic, anhand dessen die Nachricht vom Broker weiterverarbeitet werden kann. Zusätzlich verfügt jede Nachricht über einen Nachrichteninhalt, die sogenannte Payload. Diese MQTT-Payload ist nicht an eine bestimme Struktur gebunden und kann frei gestaltet werden. Dennoch ist es sinnvoll den Nachrichteninhalt eine bestimmte Struktur vorzugeben, damit dieser von anderen Geräten oder Software gelesen werden kann. Mögliche Nachrichtenstrukturen sind Json, XML oder OPC UA. Eine festgelegte Struktur ermöglicht eine reibungslose interne Kommunikation, sobald alle Geräte und Software mit der gleichen Struktur kommunizieren.
5. Was ist ein MQTT-Client und wie funktioniert er?
Als MQTT-Client werden alle Geräte und auch Software, wie der OPC Router, bezeichnet, die in irgendeiner Art und Weise mit dem Broker verbunden sind. Ein Client kann dem Broker Nachrichten senden (publish) und Nachrichten vom Broker erhalten (subscribe). Beim Senden einer Nachricht an den Broker, muss ein MQTT-Topic angegeben werden, anhand dessen die Nachricht weiter verarbeitet werden kann. Nachrichten können mit einem unterschiedlichen Quality of Service (QoS) versendet werden:
- Quality of Service 0: Die Nachricht des Clients wird genau einmal versendet, unabhängig davon, ob sie bei dem Broker angekommen ist.
- Quality of Service 1: Die Nachricht des Clients wird immer und immer wieder versendet, bis der Broker mit einer Empfangsbestätigung antwortet. Das kann dazu führen, dass eine Nachricht mehrmals beim Broker ankommt.
- Quality of Service 2: Der Client sendet eine Nachricht einmalig und stellt gleichzeitig sicher, dass diese beim Broker angekommen ist. Die Kommunikation mit Quality of Service 2 benötigt mehr Bandbreite als die mit Quality of Service 0 oder 1.
Gleichzeitig kann ein Client bei dem Broker ein MQTT-Topic abonnieren, damit dieser automatisch alle Informationen erhält, die mit diesem MQTT-Topic bei dem Broker eingehen. Beispielsweise werk1 / halle1 / temperatur. Mit Hilfe von Wildcards kann ein Client mehrere Informationen vom Broker erhalten. So empfängt dieser mit dem MQTT-Topic werk1 / halle1 / # alle Einträge aus der Liste werk1 / halle1. Mit dem Topic werk1 / + / temperatur werden alle Temperatureinträge vom Werk1 gesendet.
Abschließend besitzt ein MQTT-Client die „Last Will“ Funktion. Sollte die Verbindung zu dem Broker verloren gehen, wird eine letzte Nachricht gesendet, damit der Verbindungsfehler vom Broker bemerkt wird und an den Anwender weitergegeben werden kann.
6. Wann sollte man MQ Telemetry Transport nutzen, und wann nicht?
Mit Message Queuing Telemetry Transport werden Daten von einer großen Anzahl von Maschinen an ein einziges Ziel – die Cloud – gesendet, wo die Daten analysiert, interpretiert und weitergeleitet werden können.
Die Cloud beherbergt einen MQTT-Broker – einen Vermittler zwischen Maschinen und anderen Maschinen und / oder Menschen. Und dies ist eine wichtige Unterscheidung, da die Maschinen nicht direkt miteinander kommunizieren, sondern über den Broker.
MQTT verwendet das Konzept der „Themen“, um seine Daten zu organisieren, und ein Publish / Subscribe-Modell, um die Themen über die Cloud an andere Parteien zu kommunizieren.
Zum Beispiel: Ein Klimasystem-System sendet (oder veröffentlicht) Daten zum Thema „Gesundheitszustand“ seiner Kompressoren an die Cloud. Alle interessierten Parteien mit genehmigten Anmeldeinformationen – Maschine oder Mensch – können dieses Thema abonnieren, um die Informationen zu erhalten.
Abonnenten können Wartungstechniker (Menschen), Teilebeschaffungssysteme (Software/Maschine) oder Wartungsplanungssysteme (Software/Maschine) sein.
Plötzlich steht jeder Aspekt des Lebenszyklus einer Maschine zur Prüfung zur Verfügung, und dies stellt eine aufregende und tiefgreifende Gelegenheit dar, mit diesen Informationen in Verbindung zu treten, um Fehler zu finden, Kosten einzusparen, die Effizienz zu steigern und die Planung für das Internet der Dinge zu machen.
7. Wofür wird MQ Telemetry Transport im IoT (Internet of Things) verwendet?
Das Wort Topic (Thema) bezieht sich auf eine UTF-8-Zeichenfolge, die der Broker zum Filtern von Nachrichten für jeden verbundenen Client verwendet. Das Topic besteht aus einer oder mehreren Themenebenen. Jede Themenebene ist durch einen Schrägstrich (Themenebenen-Trennzeichen) getrennt. Im Vergleich zu einer Nachrichtenwarteschlange sind MQTT-Topics sehr einfach. Der Client muss das gewünschte Thema nicht erstellen, bevor er es veröffentlicht oder abonniert. Der Broker akzeptiert jedes gültige Topic ohne vorherige Initialisierung. Beachten Sie, dass jedes Topic mindestens ein Zeichen enthalten muss und dass die Themenzeichenfolge Leerzeichen zulässt. Bei den Themen wird zwischen Groß- und Kleinschreibung unterschieden. Beispielsweise sind _werk1 / halle1 und _Werk1 / Halle1 zwei verschiedene Themen. Außerdem ist der Schrägstrich allein ein gültiges Thema.
Im Allgemeinen können Sie Ihre MQTT-Topics nach Belieben benennen. Es gibt jedoch eine Ausnahme: __ Topics, die mit einem $ -Symbol beginnen, haben einen anderen Zweck. __ Diese Themen sind nicht Teil des Abonnements, wenn Sie den mehrstufigen Platzhalter als Topic (#) abonnieren. Die $ -Symbol-Themen sind für interne Statistiken des MQTT-Brokers reserviert. Clients können keine Nachrichten zu diesen Themen veröffentlichen. Derzeit gibt es keine offizielle Standardisierung für solche Topics. Normalerweise wird $ SYS / für alle folgenden Informationen verwendet, die Implementierung von Brokern variiert jedoch. Ein Vorschlag für $ SYS-Themen ist das MQTT-GitHub-Wiki.
8. Wie kann man einfach starten mit MQ Telemetry Transport ?
Um einen einfachen Start gewährleisten zu können, empfiehlt sich HiveMQ als MQTT Broker. HiveMQ basiert auf offenen IoT Standards. Dies ermöglicht einen Zugang zu einer Vielzahl von MQTT-Clients. Er ist für eine schnelle, effiziente und zuverlässige Übertragung von Daten an und von angeschlossenen Geräten und Servern entwickelt wurden.
Das MQTT-Protokoll bietet eine einfache Methode zur Durchführung von Messaging mithilfe des Publish / Subscribe-Modells. Dadurch eignet es sich besonders für IoT- und Cloud Anwendungen, beispielsweise für Sensoren mit geringer Leistung oder für mobile Geräte wie Telefone, eingebettete Computer oder Mikrocontroller.
In Verbindung mit dem OPC Router lassen sich Verbindungen einfach abfragen. Laden Sie hier den HiveMQ Broker herunter und testen Sie selbst.
Einfache MQTT Kommunikation in der Praxis
Das Nachrichtenprotokoll MQTT ist gerade für Umgebungen mit niedriger Bandbreite und hoher Latenz und damit für die Machine-to-Machine-Kommunikation (M2M) geeignet. Das über einen zentralen Broker betriebene Publish-and-Subscribe-Prinzip ist daher im IoT sehr beliebt.
In der Praxis ist die Kommunikation über MQTT vorteilhaft, da es das interne Netzwerk entlasten und trotzdem mit beliebig vielen verschiedenen System kommunizieren kann. Über bestimmte Software, wie zum Beispiel den OPC Router, lassen sich Daten an andere Systeme publishen. Solche Systeme können beispielsweise SAP, OPC UA, SQL oder REST sein. Als Publisher lassen sich damit Daten aus nicht MQTT fähigen Quellen an andere Systeme zur Weiterverarbeitung übergeben. Das zuverlässige MQTT Nachrichtenprotokoll kann die interne Kommunikation beschleunigen und Kapazitäten in der Bandbreite schaffen.
Das könnte Sie auch interessieren
Das Architekturmodell von REST hat sich für die Systemintegration zu einem führenden Standard entwickelt. Eine Systemanbindung per REST ist effektiv und einfach. Durch die Zustandslosigkeit von REST ist eine einfache Skalierbarkeit möglich und so ist REST in der Industrie vielfältig im Einsatz. Wir versorgen Sie in unserer Knowledge Base mit notwendigen Basis-Wissen rund um REST und REST API.
Der Bedarf an Datenaustausch ist mit dem Internet und der allgemeinen Vernetzung von Computersystemen gestiegen. Für Web-Systeme ist hier eine Plattformunabhängigkeit sehr wichtig. Mit JSON hat sich dafür ein ressourcenschonendes, menschen- und maschinenlesbares Datenformat etabliert. Praxisnahes Basiswissen zu JSON und nützliche Hinweise für den Einsatz finden Sie auf unserer Was ist JSON Seite.
Mit OPC UA wird ein standardisierter Zugriff auf Maschinen, Geräte und andere Systeme in der Industrie 4.0 ermöglicht und so ein herstellerunabhängiger Datenaustausch gewährleistet. In unserer Knowledge Base finden Sie einen Überblick über Funktionalität und Begriffe des wichtigsten Kommunikationsprotokolls für die Industrie 4.0 und das Industrial Internet of Things (IIoT).
In unserer Knowledge Base finden Sie detaillierte Schritt für Schritt Anleitungen für Anbindungen mit unserem MQTT-Plug-in für folgende Bereiche: Amazon AWS IoT Cloud, Microsoft Azure IoT Hub, IBM Watson, Google IoT Core und Siemens MindSphere IoT.