MQTT ist ein schlankes Nachrichtenprotokoll, mit dem Geräte kleine Nachrichten über einen zentralen Server, den Broker, austauschen, statt direkt miteinander zu sprechen. Ein Gerät veröffentlicht eine Nachricht unter einer Bezeichnung, dem Topic. Jedes Programm, das dieses Topic abonniert hat, erhält eine Kopie. Dieses einfache Prinzip erklärt, warum MQTT in Sensoren, industriellen Gateways, Zigbee-Zentralen und Gebäudesystemen verbreitet ist.

Andy Stanford-Clark von IBM und Arlen Nipper, damals bei Arcom Control Systems, entwickelten es 1999 zur Überwachung von Ölpipelines über langsame, teure Satellitenverbindungen. Dieser Ursprung erklärt bis heute viele Eigenschaften: von kleinen Paketen bis zu der Möglichkeit, das unerwartete Verschwinden eines Geräts zu melden.

Kurz gesagt

  • MQTT arbeitet nach dem Publish/Subscribe-Prinzip: Geräte veröffentlichen Nachrichten in Topics eines Brokers, der sie an alle Abonnenten weiterleitet.
  • Sender und Empfänger müssen einander nicht kennen. Dashboards, Datenbanken und Alarmdienste lassen sich später ergänzen, ohne das Gerät zu ändern.
  • Drei QoS-Stufen wägen Bandbreitenbedarf gegen Zustellgarantien ab. Der Last Will meldet, wenn ein Gerät unerwartet ausfällt.
  • Sparkplug ergänzt MQTT für industrielle Systeme um ein gemeinsames Topic-Schema, ein Datenformat und eine Online-/Offline-Zustandsverwaltung.

Wofür wird MQTT verwendet?

MQTT wird eingesetzt, wenn viele Geräte häufig kleine Datenmengen melden und darauf reagiert werden soll. Typische Beispiele sind ein Kühlraumfühler, der jede Minute die Temperatur sendet, eine Pumpensteuerung, die ihren Betriebszustand meldet, oder eine Zigbee-Zentrale, die Tür- und Bewegungsereignisse weitergibt. Dieselbe Verbindung funktioniert auch in Gegenrichtung: Eine Anwendung kann einem Gerät einen Befehl senden, etwa ein Relais schalten oder einen Sollwert ändern.

Drei Eigenschaften machen MQTT dafür geeignet. Der Zusatzaufwand ist gering: Der feste Header eines MQTT-Pakets kann nur zwei Bytes groß sein, während eine HTTP-Anfrage vor dem eigentlichen Messwert typischerweise mehrere Hundert Bytes Header enthält. Sendet ein Gerät alle paar Sekunden eine Zahl, summiert sich der Unterschied.

Außerdem bleibt die Verbindung offen. Weil das Gerät sie von innen nach außen aufgebaut hat, kann der Broker Nachrichten zurücksenden, selbst wenn eine Firewall oder ein Mobilfunknetz eingehende Anfragen blockieren würde.

Sender und Empfänger sind zudem entkoppelt. Ein Sensor weiß beim Veröffentlichen nicht, ob ein Programm zuhört oder zwanzig. Ein Jahr später ein neues Dashboard oder einen Alarmdienst hinzuzufügen, erfordert deshalb keine Änderung seiner Firmware.

Viele interessante Geräte sprechen MQTT nicht von sich aus. Energiezähler und Antriebe nutzen häufig Modbus, Gebäudesteuerungen BACnet, Fabrikmaschinen OPC UA und viele Funksensoren in Gebäuden Zigbee. Meist übernimmt ein Edge-Gateway am Standort die Übersetzung: Es liest das ursprüngliche Protokoll und veröffentlicht die Werte als MQTT-Nachrichten. Das kann ein Industriegerät von Advantech oder Moxa sein, ein kleiner Rechner mit Node-RED oder eine Zigbee2MQTT-Zentrale, die Daten jedes Zigbee-Geräts als JSON veröffentlicht. Der Rest des Systems muss anschließend nur noch ein Protokoll verstehen.

MQTT passt nicht zu jeder Aufgabe. Für gelegentliche Anfragen und Antworten ist HTTP oft einfacher, etwa wenn ein Gerät täglich einen Bericht hochlädt oder eine Anwendung eine Konfigurationsdatei abruft. Ein Batteriesensor mit geplanter mehrjähriger Laufzeit kann meist keine TCP-Verbindung dauerhaft offen halten. Er verwendet deshalb eher stromsparenden Funk wie LoRaWAN und erreicht das übrige System über ein Gateway. Auch Videostreams und große Dateiübertragungen gehören auf andere Protokolle.

Was ist ein MQTT-Server?

Ein MQTT-Server ist das Programm, mit dem sich alle Geräte und Anwendungen verbinden. Meist heißt er Broker, weil er anders als ein Webserver keine Seiten ausliefert. Er empfängt Nachrichten, prüft deren Topic und gibt eine Kopie an jeden Client mit passendem Abonnement weiter. Bekannte Broker sind Eclipse Mosquitto als Open-Source-Projekt, EMQX und HiveMQ sowie Clouddienste wie AWS IoT Core.

Topics sind Textzeichenfolgen mit durch Schrägstriche getrennten Ebenen, ähnlich einem Dateipfad. Ein Kühlraumsensor könnte an plant1/coldroom3/temperature senden, ein Türkontakt an plant1/dock2/door. Ein Topic wird nicht vorher angelegt: Es existiert, sobald jemand darin veröffentlicht. Deshalb vereinbaren Teams das Schema früh. Der Broker akzeptiert jede Schreibweise, und ein Tippfehler wird einfach zu einem neuen Topic, das niemand abonniert hat.

Abonnenten können zwei Platzhalter verwenden. Ein Pluszeichen steht für genau eine Ebene: plant1/+/temperature empfängt Temperaturmeldungen aus allen Räumen in Werk 1. Eine Raute umfasst alles unterhalb einer Ebene: plant1/# empfängt jede Nachricht aus Werk 1. Platzhalter sind nur beim Abonnieren möglich; ein Sender gibt immer ein konkretes Topic an.

Der Broker untersucht den Nachrichteninhalt nicht. Die Nutzlast besteht nur aus Bytes: einer Zahl, einem JSON-Objekt wie {"temperature": 4.2, "battery": 87} oder einem Binärformat. Jeder Empfänger muss wissen, wie er sie liest. Genau dieses Problem löst Sparkplug für industrielle Systeme.

Zwei weitere Funktionen prägen das Verhalten. Wird eine Nachricht mit dem Retain-Flag veröffentlicht, speichert der Broker sie als zuletzt hinterlegte Nachricht für dieses Topic und liefert sie neuen Abonnenten sofort aus. Ein frisch geöffnetes Dashboard sieht dadurch die aktuelle Ventilstellung, ohne auf die nächste Meldung zu warten. Eine persistente Sitzung erlaubt dem Broker, die Abonnements eines offline gegangenen Clients zu behalten und dessen QoS-1- und QoS-2-Nachrichten bis zur Wiederverbindung zwischenzuspeichern. Ob auch QoS-0-Nachrichten gepuffert werden, hängt vom Broker ab.

Ein Broker lässt sich selbst betreiben oder als Dienst nutzen. Die Anbindung von MQTT-Geräten an Kilo unterstützt beide Wege. Bei Cloud MQTT stellt Kilo für jeden Connector einen Broker mit eigenem Endpunkt und eigenen Zugangsdaten bereit. Er akzeptiert ausschließlich verschlüsselte MQTTS-Verbindungen auf Port 1884. Bei External MQTT verbindet sich Kilo mit einem vorhandenen Broker, etwa Mosquitto, HiveMQ oder AWS IoT Core. In beiden Fällen legen Sie fest, wie die Nachricht ihrem Gerät zugeordnet wird: über ein Topic-Muster oder eine Geräte-ID in den JSON-Daten.

Was ist ein MQTT-Client?

Ein Client ist alles, was sich mit dem Broker verbindet: Sensor, Gateway, Smartphone-App, Datenbankprogramm oder Cloudplattform. Abgesehen vom Broker kennt das Protokoll keine getrennten Rollen. Jeder Client kann veröffentlichen, abonnieren oder beides.

Beim Verbindungsaufbau sendet der Client eine Client-ID, die auf diesem Broker eindeutig sein muss. Verbindet sich ein zweiter Client mit derselben ID, schließt der Broker die erste Verbindung. Das ist eine häufige Ursache dafür, dass zwei Geräte einander ständig aus dem Netz werfen. Der Client kann außerdem Benutzername und Passwort senden oder ein Zertifikat vorlegen. Er nennt ein Keep-Alive-Intervall, beispielsweise 60 Sekunden. Hat er in dieser Zeit nichts zu senden, überträgt er einen kleinen Ping, damit der Broker weiß, dass er noch erreichbar ist.

Clientbibliotheken wie Eclipse Paho gibt es für fast jede Programmiersprache und für kleine Mikrocontroller. Ein Python-Skript und ein ESP32-Board können deshalb denselben Broker verwenden. Zur Fehlersuche zeigt ein Desktop-MQTT-Client mit dem Abonnement # auf einem Testbroker jede eintreffende Nachricht.

Welche QoS-Stufen gibt es bei MQTT?

Quality of Service, kurz QoS, legt pro Nachricht fest, welchen Aufwand Sender und Empfänger für die Zustellung betreiben. MQTT hat drei Stufen.

  • QoS 0: höchstens einmal. Die Nachricht wird einmal ohne Bestätigung gesendet. Geht sie im Netz verloren, ist sie weg. Für häufige Messwerte ist das oft akzeptabel.
  • QoS 1: mindestens einmal. Der Empfänger bestätigt jede Nachricht. Bleibt die Bestätigung aus, sendet der Absender sie erneut, typischerweise nach einer Wiederverbindung. Die Zustellung soll damit erhalten bleiben, allerdings kann eine Nachricht doppelt ankommen. Der Empfänger muss Duplikate vertragen.
  • QoS 2: genau einmal. Ein vierstufiger Austausch stellt die einmalige Zustellung sicher. Er erfordert die meisten Nachrichtenwechsel und passt zu Fällen, in denen Duplikate schaden würden, etwa einer Abrechnung pro Ereignis.

QoS gilt für jeden Abschnitt getrennt: vom Sender zum Broker und vom Broker zu jedem Abonnenten. Der Abonnent erhält die Nachricht mit der niedrigeren der beiden Stufen.

Ein Tanksensor sendet beispielsweise alle 30 Sekunden seinen Füllstand über Mobilfunk. Bei QoS 0 fällt ein gelegentlich verlorener Wert kaum ins Gewicht, denn 30 Sekunden später kommt der nächste. Ein Ventil-Schließbefehl ist anders: Sein Verlust wäre relevant. Er wird deshalb mit QoS 1 gesendet, und die Ventilsteuerung behandelt einen zweiten Schließbefehl als unschädlich.

Was bedeutet Last Will and Testament bei MQTT?

Der Last Will and Testament, kurz LWT, ist eine Nachricht, die ein Client dem Broker beim Verbinden hinterlegt. Sie enthält Topic, Nutzlast und QoS-Stufe. Der Broker bewahrt sie auf und veröffentlicht sie nur, wenn der Client ohne ordentliche Abmeldung verschwindet: etwa bei Netz- oder Stromausfall oder wenn innerhalb der Keep-Alive-Frist keine Daten eintreffen. Trennt der Client die Verbindung regulär, verwirft der Broker den Last Will.

Ein typisches Muster: Beim Verbinden veröffentlicht ein Gateway online als Retain-Nachricht unter plant1/gateway7/status. Als Last Will hinterlegt es offline, ebenfalls mit Retain-Flag, im selben Topic. Jeder Abonnent kennt damit den aktuellen Zustand, auch nach einem Absturz.

Die Spezifikation gibt dem Broker das Eineinhalbfache des Keep-Alive-Intervalls, bevor er einen stillen Client als ausgefallen wertet. Bei 60 Sekunden kann die Offline-Meldung daher nach ungefähr 90 Sekunden erscheinen. MQTT 5, die aktuelle Protokollversion, erlaubt zusätzlich eine Verzögerung für den Last Will, sodass eine kurze Wiederverbindung nicht gleich als Ausfall gemeldet wird.

Was ist MQTT Sparkplug?

MQTT Sparkplug ergänzt Regeln, die MQTT selbst offenlässt. MQTT bestimmt weder Topic-Namen noch Datenformate oder die Erkennung, ob eine Maschine online ist. Zwei Hersteller können daher beide MQTT verwenden und trotzdem die Daten des anderen nicht verstehen. Sparkplug entstand bei Cirrus Link Solutions und ging 2019 an die Eclipse Foundation über, die es heute betreut.

Das Topic-Schema ist fest: spBv1.0/<group>/<message type>/<edge node>/<device>. Nutzdaten verwenden ein kompaktes Binärformat auf Basis von Protocol Buffers, mit benannten Metriken, Datentypen und Zeitstempeln. Der Zustand wird über Birth- und Death-Zertifikate verfolgt. Kommt ein Edge-Knoten online, veröffentlicht er eine Birth-Nachricht mit allen Metriken samt Namen und Typen, die er melden wird. Danach sendet er nur geänderte Werte. Das reduziert den Datenverkehr an großen Standorten. Sein Death-Zertifikat ist als MQTT-Last-Will hinterlegt. Fällt der Knoten aus, informiert der Broker alle Abonnenten, ohne dass sie nachfragen müssen.

Das „B“ in Sparkplug B bezeichnet die Version des Nutzdatenformats, die heute verwendet wird. Häufig begegnet man ihr in Fabriken und SCADA-Systemen, in denen Geräte verschiedener Hersteller einen Broker teilen.

Häufige Fragen zu MQTT

Welchen Port verwendet MQTT?

Unverschlüsseltes MQTT verwendet TCP-Port 1883, MQTT über TLS Port 8883. Beide sind bei der IANA für MQTT registriert. Ein Broker kann auch für jeden anderen Port konfiguriert werden.

Verwendet MQTT TCP oder UDP?

Standard-MQTT läuft über TCP, weil es eine geordnete, zuverlässige Verbindung in beide Richtungen benötigt. Es kann auch über WebSockets laufen, sodass eine Webseite im Browser als Client arbeitet. Die separate Variante MQTT-SN ist für UDP und Sensornetze vorgesehen, die kein TCP transportieren.

Ist MQTT sicher?

MQTT verschlüsselt selbst nichts. Die Sicherheit hängt von der Broker-Konfiguration ab. Übliche Maßnahmen sind TLS-Verschlüsselung, eigene Zugangsdaten oder Clientzertifikate je Gerät und Beschränkungen dafür, welche Topics ein Client veröffentlichen oder abonnieren darf. Ein Broker, der anonyme unverschlüsselte Internetverbindungen akzeptiert, erlaubt jedem mit Zugang, Nachrichten mitzulesen und Befehle zu veröffentlichen.

Was unterscheidet MQTT 3.1.1 von MQTT 5?

MQTT 3.1.1 wurde 2014 OASIS-Standard und später als ISO/IEC 20922 veröffentlicht. MQTT 5 folgte 2019 und ergänzt Begründungscodes in Bestätigungen, Ablaufzeiten für Nachrichten und Sitzungen, geteilte Abonnements zur Verteilung eines Topics auf mehrere Clients, Benutzereigenschaften und Topic-Aliasse. Viele Broker unterstützen beide Versionen. Jeder Client wählt seine Version beim Verbindungsaufbau.

Ein erster Versuch beginnt mit einem Cloud-MQTT-Connector in einem kostenlosen Kilo-Konto. Ein beliebiger MQTT-Client sendet über TLS einen JSON-Messwert an dessen Endpunkt, und für das Topic wird ein Gerät registriert. Im Reiter „Mapping“ erscheinen danach alle gesendeten Felder mit aktuellem Wert; verschachteltes JSON wird zu Schlüsseln wie sensor.temperature abgeflacht. Sie wählen, welche Felder zu Metriken werden. Ein Testgerät lässt im kostenlosen Tarif noch Platz für vier weitere, sobald die erste Verbindung zuverlässig meldet.