MQTT Zusammenfassung [Quelle: Wikipedia]
MQTT (Message Queuing Telemetry Transport) ist ein offenes Nachrichtenprotokoll für Machine-to-Machine-Kommunikation (M2M), das die Übertragung von Telemetriedaten in Form von Nachrichten zwischen Geräten z.B. Sensoren ermöglicht.
Die Internet Assigned Numbers Authority (IANA) reserviert für MQTT die Ports 1883 und 8883. MQTT-Nachrichten können mit dem TLS-Protokoll verschlüsselt werden.
Die MQTT-Spezifikation unterscheidet TCP/IP-basierte und Nicht-TCP/IP-Netzwerke.
MQTT ist ein Client-Server-Protokoll. Clients senden dem Server (“Broker”) nach Verbindungsaufbau Nachrichten mit einem Topic, welches die Nachricht hierarchisch einstuft; zum Beispiel Küche/Kühlschrank/Temperatur oder Auto/Rad/3/Luftdruck. Clients können diese Topics abonnieren, wobei der Server die empfangenen Nachrichten an die entsprechenden Abonnenten weiterleitet.
Interessant ist, dass ein MQTT-Server („Broker“) die gesamte Datenlage seiner Kommunikationspartner hält, und so als Zustands-Datenbank benutzt werden kann. So ist es möglich, kleine unperformante MQTT-Geräte mit einem MQTT-Broker zu verbinden, wobei die Geräte Daten einsammeln und/oder Befehle entgegennehmen, während ein komplexes Lagebild nur auf dem MQTT-Broker entsteht und hier oder durch einen leistungsfähigen Kommunikationspartner ausgewertet werden kann.
Nachrichten bestehen immer aus einem Topic und dem Nachrichteninhalt. Nachrichten werden mit einem definierbaren Quality of Service versendet:
- at most once: die Nachricht wird einmal gesendet und kommt bei Verbindungsunterbrechung möglicherweise nicht an
- at least once: die Nachricht wird so lange gesendet, bis der Empfang bestätigt wird, und kann beim Empfänger mehrfach ankommen
- exactly once: hierbei wird sichergestellt, dass die Nachricht auch bei Verbindungsunterbrechung genau einmal ankommt
Außerdem kann mit dem Retain-Flag der Server angewiesen werden, die Nachricht zu diesem Topic zwischenzuspeichern.
Beim Verbindungsaufbau können Clients einen „letzten Willen“ in Form einer Nachricht definieren. Falls die Verbindung zum Client verloren geht, wird diese Nachricht publiziert und dabei an die entsprechenden Abonnenten gesendet.
MQTT wird üblicherweise über TCP benutzt und hat einen 2-Byte-Header. Das erste Byte enthält den Nachrichtentyp (4 Bit), den Quality of Service (2 Bit) und ein Retain-Flag. Das zweite Byte enthält die Länge des restlichen MQTT-Pakets. Daran schließt sich ein variabler Teil an, der das MQTT-Topic, also das Thema enthält. Abschließend kommt der Payload, also der Dateninhalt, der unter dem Thema veröffentlicht wird.
Es gibt folgende Nachrichten-Typen:
- CONNECT
- CONNACK
- PUBLISH
- PUBACK
- PUBREC
- PUBREL
- PUBCOMP
- SUBSCRIBE
- SUBACK
- UNSUBSCRIBE
- UNSUBACK
- PINGREQ
- PINGRESP
- DISCONNECT
Die fett markierten Nachrichten-Typen sind innerhalb der folgenden Kommunikation wieder zu finden:
Topics können wildcards beinhalten:
- Single level wildcard (+): Haus/+/Kühlschrank/Temperatur
- Multi level wildcard am Ende (#): Küche/Kühlschrank/#
Installation von MQTTBox
MQTTBox ist ein MQTT Client der uns unter anderem die Möglichkeit gibt, neue Topics zu erstellen und/oder bestehende Topics zu abonnieren.
Konfiguration von MQTTBox zwecks Kommunikation mit der Cummulocity (C8Y) IoT-Plattform:
Anhand der MQTT Client Id können zukünftige Anfragen einem bestehenden Device mit der oben genannten ID zugeordnet werden. Ich greife etwas vor und zeige, wo sich diese Id nach der Erstellung eines Devices befindet:
Anschließend kann eine Verbindung zur C8Y hergestellt werden.
Device Erstellung innerhalb der C8Y IoT-Platform via MQTT
Ein Device kann mit Hilfe eines vordefinierten C8Y MQTT-Templates mit der Templatenummer ‚100‘ erstell werden.
100, deviceName, deviceType
Es besteht die Möglichkeit, weiter Templates innerhalb des Payloads innerhalb einer neuen Zeile mit anzugeben. Zum Beispiel kann mit dem Template 110 folgende Attribute mit angegeben werden: serialNumber, model, revision
Liste der Template IDs
Eine ausführliche Beschreibung der Templates und deren Parameter findet man unter der folgenden URL.
| 100 | Device creation |
| 101 | Child device creation |
| 105 | Get child devices |
| 106 | Get children of device |
| 110 | Configure Hardware |
| 111 | Configure Mobile |
| 112 | Configure Position |
| 113 | Set Configuration |
| 114 | Set supported operations |
| 115 | Set firmware |
| 116 | Set software list |
| 117 | Set required availability |
| 200 | Create custom measurement |
| 210 | Create signal strength measurement |
| 211 | Create temperature measurement |
| 212 | Create battery measurement |
| 301 | Create CRITICAL alarm |
| 302 | Create MAJOR alarm |
| 303 | Create MINOR alarm |
| 304 | Create WARNING alarm |
| 305 | Update severity of existing alarm |
| 306 | Clear existing alarm |
| 400 | Create basic event |
| 401 | Create location update event |
| 402 | Create location update event with device update |
| 500 | Get PENDING operations |
| 501 | Set operation to EXECUTING |
| 502 | Set operation to FAILED |
| 503 | Set operation to SUCCESSFUL |
| 510 | Restart |
| 511 | Command |
| 513 | Configuration |
| 515 | Firmware |
| 516 | Software list |
| 517 | Measurement request operation |
| 518 | Relay |
| 519 | RelayArray |
| 520 | Upload configuration file |
| 521 | Download configuration file |
| 522 | Logfile request |
| 523 | Communication mode |
Das folgende Bild zeigt die Erstellung eines MQTT Gerätes:
Das Gerät wird anschließend innerhalb von ‚Device Management‘ angezeigt:
Wie man oben aus den Template IDs erkennen kann, wurde mit der ID 100 ein neues Device erstellt. Mit der ID 117 wurde der ‚response intervall‘ festgelegt und die ID 212 repräsentiert den Akku Ladestatus. Dabei steht 97 für 97%. Durch Eingabe von z.B. 212,95 & 212,85 & 212,65 & 212,57 können wir eine Batterie-Entladung simulieren.
Ich habe zuvor Topic ’s/e‘ abonniert, um den Batterie-Status auszulesen.
Innerhalb der Plattform sieht die Batterie-Entladung wie folgt aus:
