Inhalt:
- Was ist MQTT?
- Eigenschaften des MQTT-Protokolls, Beschreibung von MQTT
- Semantik von Themen
- Aufbau von Nachrichten
- Dienstgüte (QoS) im MQTT-Protokoll
Neben der rasanten Entwicklung der Industrie wächst die Anzahl der Geräte, die für Datenmanagement und -erfassung benötigt werden. Um das Problem der Kommunikation zwischen zahlreichen Geräten sowie die Kombination von Geräten in einem einzigen Netzwerk zu lösen, wurde das Konzept des Internet of Things (IoT) geschaffen – die Kombination von Geräten in einem einzigen Netzwerk auf der Grundlage einer bestimmten Funktion oder Eigenschaft, wobei dieses Netzwerk weiter mit ähnlichen Netzwerken kombiniert wird, wodurch ein größeres Netzwerk entsteht und so weiter.
In solchen Netzwerken interagieren Geräte miteinander durch verschiedene Schnittstellen und Kommunikationsprotokolle. Da wir die industrielle Umsetzung des IoT-Konzepts betrachten, bei der industrielle Ausrüstung mit eigenen Protokollen und Hardware verwendet werden soll, gehen wir auf das Konzept des IIoT (Industrial Internet of Things) ein.
Für ihre Kommunikation können Geräte verschiedene industrielle Protokolle verwenden. Zu diesem Zweck gehört MQTT zu den beliebten.
Was ist MQTT?
MQTT oder Message Queue Telemetry Transport ist ein leichtgewichtiges, kompaktes, offenes Messaging-Protokoll für die Datenübertragung an entfernten Standorten, an denen ein "kleiner Code-Fußabdruck" erforderlich ist oder die Netzwerkbandbreite begrenzt ist. Diese Vorteile ermöglichen die Implementierung dieses Protokolls in M2M-Systemen (Machine-to-Machine) und IIoT-Systemen (Industrial Internet of Things).
Es gibt auch eine Protokollvariante MQTT-SN (MQTT for Sensor Networks), früher bekannt als MQTT-S, die für eingebettete drahtlose Geräte ohne Unterstützung von TCP/IP-Netzwerken konzipiert ist, zum Beispiel ZigBee.
Eigenschaften des MQTT-Protokolls
Hauptmerkmale des MQTT-Protokolls:
- Asynchrones Protokoll
- Komprimierte Nachrichten
- Betrieb unter Bedingungen instabiler Verbindungen der Datenübertragungsleitung
- Unterstützung mehrerer Dienstgüteebenen (QoS)
- Einfache Integration neuer Geräte
Auf der Anwendungsschicht arbeitet das MQTT-Protokoll auf der Grundlage des TCP/IP-Protokolls und verwendet standardmäßig den Port 1883 (8883 bei Verbindung über SSL).
Im MQTT-Protokoll erfolgt der Nachrichtenaustausch zwischen einem Client, der ein Nachrichten-Publisher oder ein Nachrichten-Subscriber sein kann, und einem Nachrichten-Broker (z.B. Mosquitto MQTT).
Der Publisher sendet Daten an den MQTT-Broker und gibt dabei ein bestimmtes Thema in einer Nachricht an. Die Subscriber können je nach Abonnement korrespondierender Themen verschiedene Daten von mehreren Publishern empfangen.
MQTT-Geräte verwenden bestimmte Nachrichtentypen für ihre Kommunikation mit dem Broker. Hier sind die Haupttypen:
- Connect – Verbindung zum Nachrichten-Broker herstellen
- Disconnect – Verbindung zum Nachrichten-Broker trennen
- Publish – Daten zu einem Thema innerhalb des Nachrichten-Brokers veröffentlichen
- Subscribe – Abonnement für ein Thema beim Nachrichten-Broker
- Unsubscribe – Abonnement für ein Thema aufheben
Schematische Darstellung der einfachen Kommunikation von Subscriber, Publisher und Broker
Semantik von Themen
Themen sind Zeichen mit UTF-8-Codierung. Die Themenhierarchie hat eine baumartige Struktur, wodurch ihre Organisation und der Datenzugriff erleichtert werden. Themen können aus einem oder mehreren Ebenen bestehen, die durch das Zeichen «/» getrennt sind.
Hier ist ein Beispiel für ein Thema, in dem ein Temperatursensor, der sich im Schlafzimmer befindet, Daten für den Broker veröffentlicht:
/home/living-space/living-room1/temperature
Ein Subscriber kann auch Daten von mehreren Themen gleichzeitig empfangen. Zu diesem Zweck wurden Wildcards entwickelt. Es gibt zwei Arten von Wildcards: Ein-Ebenen- und Mehr-Ebenen-Wildcards. Um sie besser zu verstehen, betrachten wir die Beispiele für jede Art:
-
Ein-Ebenen-Wildcard. Das Pluszeichen «+» wird verwendet, um
Zum Beispiel, wir müssen Daten zur Temperatur in allen Schlafzimmern erhalten:
/home/living-space/+/temperature
Dadurch erhalten wir Daten von den Themen:
/home/living-space/living-room1/temperature
/home/living-space/living-room2/temperature
/home/living-space/living-room3/temperature
-
• Mehr-Ebenen-Wildcard. Das Rautenzeichen «#» wird verwendet, um
Zum Beispiel, wir müssen Daten von verschiedenen Sensoren in allen Schlafzimmern des Hauses erhalten:
/home/living-space/#
Dadurch erhalten wir Daten von den Themen:
/home/living-space/living-room1/temperature
/home/living-space/living-room1/light1
/home/living-space/living-room1/light2
/home/living-space/living-room1/humidity
/home/living-space/living-room2/temperature
/home/living-space/living-room2/light1
…
Aufbau von Nachrichten
Eine MQTT-Nachricht besteht aus mehreren Teilen:
- Festkopf (in allen Nachrichten vorhanden)
- Variabler Kopf (in einigen Nachrichten vorhanden)
- Daten, Payload (in einigen Nachrichten vorhanden)
Festkopf
Nachrichtentyp – zum Beispiel: CONNECT, SUBSCRIBE, PUBLISH, etc.
Spezifische Flags für jedes MQTT-Paket – diese 4 Bits werden für Hilfsflags verwendet, deren Vorhandensein und Status vom Nachrichtentyp abhängen.
Verbleibende Länge – aktuelle Nachrichtengröße (variabler Kopf + Daten), die Größe liegt zwischen 1 und 4 Bytes.
Insgesamt gibt es 15 Nachrichtentypen im MQTT-Protokoll:
| Nachrichtentyp | Wert | Flussrichtung | Beschreibung |
|---|---|---|---|
| Reserved | 0000 (0) | verboten | Reserviert |
| CONNECT | 0001 (1) | C* -> S** | Client-Anfrage zur Verbindung mit dem Server |
| CONNACK | 0010 (2) | C <- S | Verbindungsbestätigung |
| PUBLISH | 0011 (3) | C <- S, C -> S | Nachricht veröffentlichen |
| PUBACK | 0100 (4) | C <- S, C -> S | Bestätigung der Veröffentlichung |
| PUBREC | 0101 (5) | C <- S, C -> S | Veröffentlichung empfangen |
| PUBREL | 0110 (6) | C <- S, C -> S | Veröffentlichung freigeben |
| PUBCOMP | 0111 (7) | C <- S, C -> S | Veröffentlichung abgeschlossen |
| SUBSCRIBE | 1000 (8) | C -> S | Client-Abonnement-Anfrage |
| SUBACK | 1001 (9) | C <- S | Abonnement-Bestätigung |
| UNSUBSCRIBE | 1010 (10) | C -> S | Abmeldeanfrage |
| UNSUBACK | 1011 (11) | C <- S | Abmeldebestätigung |
| PINGREQ | 1100 (12) | C -> S | PING-Anfrage |
| PINGRESP | 1101 (13) | C <- S | PING-Antwort |
| DISCONNECT | 1110 (14) | C -> S | Client trennt die Verbindung |
| Reserved | 1111 (15) | Verboten | Reserviert |
*C – Client, **S – Server
Flags
Die ersten 4 höchstwertigen Bits des festen Headers werden als spezifische Flags verwendet:
DUP – Das Duplikat wird gesetzt, wenn ein Client oder der MQTT-Broker ein Paket erneut sendet (verwendet in PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL). Wenn das Flag gesetzt ist, muss der variable Header die Nachrichten-ID (Message Identifier) enthalten.
QoS – Quality of Service (0,1,2)
RETAIN – Beim Veröffentlichen von Daten mit gesetztem Retain-Flag speichert der Broker diese. Wenn ein neues Abonnement für dieses Thema eingerichtet wird, sendet der Broker sofort eine Nachricht mit diesem Flag. Es wird nur in Nachrichten vom Typ PUBLISH verwendet.
Variabler Header
Der variable Header ist in einigen Headern vorhanden.
Er enthält die folgenden Daten:
- Paketidentifikator – vorhanden in allen Nachrichtentypen, außer in: CONNECT, CONNACK, PUBLISH (mit QoS <1), PINGREQ, PINGRESP, DISCONNECT
- Protokollname – nur im Nachrichtentyp CONNECT vorhanden
- Protokollversion – nur im Nachrichtentyp CONNECT vorhanden
- Verbindungsflags – Flags, die das Verhalten eines Clients während der Verbindung spezifizieren
Benutzername – wenn das Flag gesetzt ist, muss ein Benutzername im Payload vorhanden sein (wird für die Client-Authentifizierung verwendet)
Passwort – wenn das Flag gesetzt ist, muss ein Passwort im Payload vorhanden sein (wird für die Client-Authentifizierung verwendet)
Will Retain – wenn das Flag auf 1 gesetzt ist, speichert der Broker eine Will-Nachricht.
Will QoS – Quality of Service für die Will-Nachricht. Wenn das Will-Flag gesetzt ist, müssen Will QoS und Will Retain vorhanden sein.
Will Flag – wenn das Flag gesetzt ist, informiert der Broker alle verbundenen Clients über die sogenannte Will-Nachricht, nachdem ein Client die Verbindung zum Broker trennt, ohne den Befehl DISCONNECT zu senden (im Falle eines unvorhergesehenen Shutdowns, Fehlers usw.).
Clean Session – wenn das Flag auf 0 gesetzt ist, speichert der Broker eine Sitzung, alle Client-Abonnements, und bei der nächsten Verbindung des Clients sendet er alle Nachrichten von QoS1 und QoS2, die der Broker empfangen hat, während der Client getrennt war. Entsprechend muss der Client, wenn das Flag auf 1 gesetzt ist, bei der nächsten Verbindung alle Themen erneut abonnieren.
- Session Present – wird in Nachrichten vom Typ CONNACK verwendet. Wenn der Broker eine Verbindung mit Clean Session auf 1 akzeptiert, muss er Session Present (SP) auf 0 setzen. Wenn der Broker eine Verbindung mit Clean Session auf 0 akzeptiert, hängt der Wert von SP davon ab, ob der Broker bereits Sitzungsdaten für diesen Client gespeichert hat (wenn ja, muss SP auf 1 gesetzt werden, andernfalls auf 0). Das Session Present Flag ermöglicht es einem Client festzustellen, ob bereits Sitzungsdaten gespeichert sind.
-
Connect Return Code – wenn der Broker aus irgendeinem Grund kein korrekt formatiertes CONNACK-Paket von einem Client empfangen kann, muss er im zweiten Byte des CONNACK-Pakets den entsprechenden Wert aus der folgenden Tabelle setzen:
Wert Rückgabe-Code-Antwort Beschreibung 0 0x00 Verbindung akzeptiert Verbindung akzeptiert 1 0x01 Verbindung abgelehnt, unzulässige Protokollversion Der Broker unterstützt die vom Client angeforderte Protokollversion nicht 2 0x02 Verbindung abgelehnt, Identifikator abgelehnt Die Client-ID des Clients für die Verbindung steht nicht in der Liste der erlaubten IDs 3 0x03 Verbindung abgelehnt, Server nicht verfügbar Die Netzwerkverbindung wurde hergestellt, aber der MQTT-Dienst ist nicht verfügbar 4 0x04 Verbindung abgelehnt, ungültiger Benutzername oder Passwort Die Daten im Benutzernamen oder Passwort sind ungültig 5 0x05 Verbindung abgelehnt, nicht autorisiert Der Client ist nicht berechtigt, sich zu verbinden 6-255 Für zukünftige Verwendung reserviert - Themenname – Name eines Themas
Daten, Nutzlast
Inhalt und Format der über MQTT-Nachrichten übertragenen Daten werden im Gerät definiert. Die Datengröße kann berechnet werden, indem die Länge des variablen Headers von der verbleibenden Länge subtrahiert wird.
Dienstgüte im MQTT-Protokoll (QoS)
MQTT unterstützt drei Ebenen der Dienstgüte (QoS) beim Senden von Nachrichten.
QoS 0 Höchstens einmal. Auf dieser Ebene sendet der Publisher eine Nachricht einmal an den Broker und wartet nicht auf eine Antwort, d.h. er sendet und vergisst sie.
QoS 1 Mindestens einmal. Diese Ebene garantiert die Zustellung der Nachricht an den Broker, jedoch ist die Duplizierung von Nachrichten vom Publisher möglich. Sobald eine Duplikatkopie empfangen wird, sendet der Broker diese Nachricht erneut an die Subscriber und leitet die Empfangsbestätigung der Nachricht an den Publisher weiter. Wenn der Publisher keine PUBACK-Nachricht vom Broker erhält, versucht er, dieses Paket erneut zu senden und setzt DUP auf 1.
QoS 2 Genau einmal. Auf dieser Ebene ist die Zustellung der Nachricht an einen Client garantiert, ohne dass Duplikatkopien möglich sind.
Der Publisher sendet eine Nachricht an den Broker. Die Nachricht enthält die eindeutige Paket-ID, QoS=2 und DUP=0. Der Publisher speichert die Nachricht, bis er eine PUBREC-Antwort vom Broker erhält. Der Broker antwortet mit der PUBREC-Nachricht, die die gleiche Paket-ID enthält. Nach Erhalt dieser Nachricht sendet der Publisher PUBREL mit derselben Paket-ID. Der Broker muss die Nachricht kopieren, bis er PUBREL erhält. Sobald der Broker PUBREL erhält, löscht er die Kopie der Nachricht und sendet dem Publisher die PUBCOMP-Nachricht über den abgeschlossenen Vorgang.
Wenn Sie Fragen haben, senden Sie bitte eine E-Mail an: sales@ipc2u.com
