MQTT für Dummies

23.03.2016

In unseren Projekten beschäftigen wir uns aktuell mit verschiedenen Kommunikationsprotokollen wie beispielsweise Http, MQTT oder Coap. Gerade im Bereich IoT ist MQTT ein Protokoll, das sich in den letzten Jahren etabliert hat. MQTT wird unter anderem zur Anbindung von IoT-Devices an Backend-Plattformen wie ThingWorx verwendet. Auch im Bereich Connected Car findet MQTT Einsatz. Ein Beispiel hierfür ist das Joynr-Framework der BMW CarIT.

Da wir in unserem Tagesgeschäft mit MQTT konfrontiert werden, haben wir eine Zusammenfassung mit den wichtigsten Punkten zum Protokoll erstellt, welche wir im Rahmen dieses Artikels vorstellen möchten.

Das MQTT-Protokoll folgt den Regeln einer Publish-Subscribe-Kommunikation. Es gibt zwei verschiedene Teilnehmer: Einen Broker, und „n“ Clients, wobei die Clients als Publisher und Subscriber nicht direkt miteinander kommunizieren, sondern Nachrichen „publishen“ (veröffentlichen) und „subscriben“ (abonnieren). Die Aufgabe des Brokers ist hier die Nachrichtenverwaltung und -verteilung.

MQTT Kommunikationsparadigma
MQTT Kommunikationsparadigma (Quelle)

Vorteil dieses Kommunikationsparadigmas: Entkopplung von Publisher und Subscriber (in Anlehnung an HiveMQ)

  • Space decoupling: Publisher und Subscriber müssen sich nicht kennen (IP-Adresse o.Ä.)
  • Time decoupling: Publisher und Subscriber müssen nicht zeitgleich ausgeführt werden
  • Synchronization decoupling: Operationen auf den ausführenden Computern blockieren nicht für die Zeit der Nachrichtenübermittlung (Asynchrones Messaging)

 

Nachfolgend werden die einzelnen Komponenten von MQTT sowie deren technische Details erläutert.

MQTT Clients

Der Client ist, wie man sich ganz typisch vorstellt, der „Endnutzer“ der Kommunikation und derjenige, der Nachrichten aktiv sendet. Ein Client kann zu einem Zeitpunkt Nachrichten eines Topics empfangen (Subscriber) als auch Nachrichten in dem gleichen Topic veröffentlichen (Publisher). Jeder Client identifiziert sich durch eine Client ID, die auch seine Session komplett identifiziert, denn MQTT ist für die Client-Seite komplett stateless.

MQTT Topics

Die Kommunikation von MQTT stützt sich auf ein sogenanntes „Topic“-Prinzip:

  • Jede Nachricht wir einem Topic zugeordnet. Das heißt, jede valide MQTT-Nachricht enthält eine Payload mit einem zugehörigen Topic.
  • Topics sind von der Funktions- und Schreibsyntax Ordnern in einem Filesystem sehr ähnlich. So hieße ein valides topic z.Bsp „5OG/Zimmer5/Temperatursensor/Temperatur“
  • Topics müssen von den Clients abboniert werden, um Nachrichten zu empfangen. Schließt sich nun ein neuer Client dem Netz an und schickt dem Broker eine Subscription zum Topic „5OG/Zimmer5/Temperatursensor/Temperatur“, wird der Broker alle Nachrichten mit diesem Topic an den Subscriber weiterleiten – doch Vorsicht – nur zu exakt diesem Topic, und nicht zu „5OG/Zimmer5/Temperatursensor“. Es gibt auch die Möglichkeit, gewählte Topics wieder zu „unsubscriben“ und deren entsprechende Nachrichten nicht mehr zu erhalten.

 

Es existiert auch ein Mechanismus, mit dem sich das Ordnersystem der Topics gruppieren lässt: sogenannte Single-Level-Wildcards(+) und Multi-Level-Wildcards(#)

  • Die Single-level-Wildcard ersetzt ein Element eines Topics durch eine Wildcard, sprich: Ein Subscriber zum topic „5OG/+/Temperatursensor/Temperatur“ würde alle Nachrichten erhalten, die den drei angegebenen Leveln entsprechen, ungeachtet der Wildcard. Nachrichten zu beispielsweise „5OG/Zimmer2/Temperatursensor/Temperatur“ oder „5OG/Flur/Temperatursensor/Temperatur“ würden jetzt empfangen werden.
  • Die Multi-level-Wildcard ersetzt die ganze folgende Baumstruktur. Eine Subscription zum Topic „5OG/#“ würde absolut alle Nachrichten empfangen, die mit „5OG/“ beginnen, auch z.Bsp „5OG/Flur/Tischkicker/Schummelmodul/Status“
  • Wildcards lassen sich beliebig kombinieren, beispielsweise „+/+/Temperatursensor/#“ für alle Temperatursensor-Daten aus allen Stöcken und Zimmern.

 

MQTT QoS

Nachrichten werden mit einer „Quality of Service“ verschickt, die drei Werte anbietet:

  • 0: „Fire-and-forget“ – das Paket wird genau einmal verschickt. Kommt an, unter Umständen auch vielleicht mal nicht, analog dem UDP-Protokoll. Enorm schnell.
  • 1: „Acknowledgement“ – der Empfänger bestätigt dem Sender, das Paket erhalten zu haben. Es ist möglich dass ein Paket mehrmals ankommt. Immer noch schnell.
  • 2: „Synchronisiert“ – das Paket erreicht garantiert das Ziel, und zwar garantiert nur ein mal, jedoch erzeugt diese Variante etwas mehr Verkehr.

 

MQTT Broker

Das „Backend“ für MQTT, genannt Broker, verwaltet und administriert jeglichen Datenverkehr. Zu seinen Aufgaben zählen die Speicherung, Verwaltung und Verteilung aller Informationen zu Topics, deren Abonnenten, Clients und deren IDs, Retained Messages, etc.  Die Bandbreite des Brokers sollte trotz des sehr schmalen Protokolls bei einer sehr hohen Anzahl an Clients entsprechend dimensioniert sein. Dennoch ist die Netzwerkauslastung von MQTT-Kommunikation generell gering.

Der Broker stellt die zentrale Vermittlungsplattform des MQTT Nachrichtenaustauschs dar. Das heißt bei einem Ausfall des Brokers bricht die ganze Kommunikation zusammen, da Clients untereinander nicht kommunizieren können. Glücklicherweise gibt es die Möglichkeit verschiedene Broker zu „bridgen“, sprich miteinander zu verbinden, um ein redundantes System aufzubauen, sofern fail-safety notwendig ist. Die meisten öffentlichen Broker-Implementationen wie z.Bsp. Mosquitto verfügen bereits über fertige Implementationen zur Überbrückung. Diese Brückenmechanik kann auch eingesetzt werden, um „Brokernetze“ zu bauen – die konfigurierbar Informationen und Nachrichten zu verschiedenen Topics austauschen und an ihre entsprechenden Clients weiterreichen.

MQTT Architektur (Quelle)
MQTT Architektur (Quelle)

Extras

Es werden generell alle Nachrichten direkt empfangen und verteilt, mit der Ausnahme von eigens gekennzeichneten „Retained Messages“. Diese werden auf dem Broker gespeichert und mit dem Topic verknüpft. Jedem neuen Abonnent des Topics wird diese Nachricht nach erfolgreichem Verbingungsaufbau automatisch zugestellt. Zu jedem Topic kann nur eine Retained Message gespeichert werden. Bereits gespeicherte Retained Messages werden von Neuen überschrieben. Das ermöglicht beispielsweise das Persistieren und zeitversetzte Empfangen von Nachrichten, auch wenn sie nicht regelmäßig gesendet werden.

Zu guter Letzt bietet MQTT noch eine Art Ausfallsicherung an – der „Last-Will“ – ein konfigurierbares Paket, das vom Broker gesendet wird, sobald ein Client eine Verbindung unsauber abbricht, durch Netzwerkfehler oder ähnliches. Eine Will-Nachricht kann z.Bsp. an „5OG/Zimmer5/Temperatursensor/Status“ mit der Payload „unreachable“ oder „0“ gesendet werden – damit werden Abonnenten benachrichtigt, dass der Client unerwartet nicht mehr erreichbar ist.

So entsteht eine verschachtelte Kommunikation mit sehr gezieltem Datenverkehr, und der Network-Code für Clients ist sehr schlank und simpel zu implementieren.

 

Zurück zur Übersicht

9 Kommentare zu “MQTT für Dummies

  1. Hallo Stefan,

    danke für dein Feedback.
    Ein Message Broker ist eine eigenständige Anwendung, die separat zu deinem Client betrieben werden muss.
    Sollte es frei verfügbare Broker im Internet geben, könntest du einen solchen verwenden – wir raten aber davon ab, da der Betreiber und ggf. weitere Nutzer des Brokers dann deine darüber ausgetauschten Nachrichten lesen könnte.
    Am besten du schaust mal unter https://mqtt.org/software/ ob du da eine Broker-Software findest, welche du selber betreiben möchtest.

    Viele Grüße,
    doubleSlash

  2. Hi,

    ich verstehe noch immer nicht wie das mit dem Broker funktioniert.
    Ich brauch nur zB MQTTfx runterladen, stelle da was ein und alles läuft, oder muss man ein Konto o.ä. für einen MQTT-Broker erstellen, wenn ja wie/wo?

    Danke für deine Hilfe. Der Rest der Erklärung ist wirklich super und verständlich.

  3. Hallo, mit der Anwendung kommt das Verständnis, leider aber auch die Probleme.

    void callback(char* topic, byte* payload, unsigned int length) {

    Serial.println();

    // Switch on the LED if an 1 was received as first character
    if ((char)payload[0] == ‚0‘) {
    digitalWrite(Relay,HIGH );
    Serial.print(“ Taster 1 nicht gedrückt „);
    }

    Einige Taster kann ich so abfragen.
    Übertrage ich einen Bereich z.B zwischen 0-100
    spielt alles verrückt.
    Wie ist der Payload aufgebaut und wie kann man eindeutiger abfragen. An einem ESP8266 z.B hängt ja nicht immer nur ein Taster , oft sind es ja mehrere Sensoren. Wenn jetzt ein Client , sagen wir ne APP 4 Taster hat die T1 auf 0 u. 1 schalten T2 auf 2 und 3 usw. Dann kommen aber Werte Slider oder freie Eingabe zw. 0 – 100 , alles an die Adresse des ESP gesendet. Wie kann ich den Payload so abfragen dass meine App nicht verrückt spielt.

  4. Hey Marc, danke für deinen Beitrag. Alles ist sehr verständlich, einfach geschrieben und anschaulich präsentiert. Danke!

  5. Hallo Lutz,
    die grünen Pfeile zeigen den Kontrollfluss und die Anmeldung der Subscriber beim MQTT-Broker an. Da die Aktion von den Endgeräten (Laptop, Mobiles Endgerät) ausgeht, zeigen die Pfeile von ihnen zum MQTT-Broker.
    Der Kontrollfluss der Datenweiterleitung geht vom MQTT-Broker zu den Endgeräten. Daher die Richtung der roten Pfeile.
    Viele Grüße,
    Marc

  6. Im ersten Bild empfangen Laptop und Mobiles Endgerät die Daten also müsste an den roten Pfeilen „subscribe 21°“ und an den grünen publish stehen, oder? Sonst ist das sehr gut.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*