Was ist MQTT? Das MQTT-Protokoll erklärt

MQTT ist ein schlankes Publish-Subscribe-Protokoll für Nachrichten. Geräte und Anwendungen verbinden sich mit einem Server, dem Broker, und senden Nachrichten an benannte Topics wie site/dub01/mdb1/main-incomer. Jeder Client, der dieses Topic abonniert hat, erhält die Nachricht vom Broker. Publisher und Subscriber adressieren einander nie; ein Zähler, ein Dashboard und eine Cloud-Plattform können also Daten teilen, ohne voneinander zu wissen. MQTT läuft über TCP auf Port 1883 oder über TLS auf Port 8883, und sein fester Header ist nur zwei Byte lang. Weil sich jedes Gerät ausgehend mit dem Broker verbindet und beliebig viele Systeme dieselben Daten abonnieren können, ist es zum gängigsten Protokoll geworden, um Sensor- und Zählerdaten über das Internet zu senden.

So funktioniert MQTT

Ein Client öffnet eine TCP-Verbindung zum Broker und sendet CONNECT mit seiner Client-ID, Zugangsdaten und einem Keep-Alive-Intervall. Der Broker antwortet mit CONNACK. Ein Publisher sendet dann PUBLISH-Pakete; ein Subscriber sendet SUBSCRIBE mit einem oder mehreren Topic-Filtern, und der Broker schickt ihm ab dann jedes passende PUBLISH. Läuft innerhalb des Keep-Alive-Intervalls kein Paket, sendet der Client PINGREQ, und der Broker schließt eine Verbindung, die anderthalb Intervalle lang still bleibt.

Weil jeder Client eine ausgehende Verbindung zum Broker aufbaut, braucht ein Gateway am Standort keinen offenen eingehenden Port. Das ist der wichtigste praktische Grund, warum MQTT die abgefragten Protokolle für den Datenversand vom Standort abgelöst hat.

Topics und Platzhalter

Topics sind Zeichenketten, bei denen Groß- und Kleinschreibung zählt. Ein Client legt kein Topic an; er veröffentlicht darauf, und der Broker leitet die Nachricht an jedes passende Abonnement weiter. Ein Abonnement kann zwei Platzhalter verwenden:

+ steht für genau eine Ebene und # für den ganzen Rest des Baums, deshalb muss es am Ende stehen. Topics, die mit $ beginnen, sind dem Broker vorbehalten, etwa $SYS/ für Broker-Statistiken, und ein Filter, der mit einem Platzhalter beginnt, passt nicht auf sie.

Planen Sie den Topic-Baum, bevor das erste Gerät veröffentlicht, denn jeder Subscriber und jede Zugriffsregel hängt davon ab. Ein guter Baum läuft vom weitesten zum engsten Bereich (Organisation, Standort, Verteilung, Gerät, dann die Art der Nachricht), führt jedes Gerät an genau einer Stelle und enthält keine veränderlichen Werte wie einen Messwert, einen Zeitstempel oder eine Sitzungsnummer. Trennen Sie Telemetrie-, Status- und Befehls-Topics, damit Schreibrechte nur dort vergeben werden, wo sie nötig sind.

QoS, Retain-Nachrichten und Last Will

MQTT kennt drei Zustellstufen. Sie gelten jeweils für einen Abschnitt: vom Publisher zum Broker und vom Broker zu jedem Subscriber.

Eine Retain-Nachricht behält der Broker als letzten Wert ihres Topics und sendet sie sofort an jeden neuen Subscriber. Das passt zu einem Gerätestatus, kann aber einen veralteten Messwert ausliefern. Ein Last Will ist eine Nachricht, die der Broker für einen Client veröffentlicht, wenn dessen Verbindung ohne sauberes DISCONNECT abreißt; so erfährt ein Subscriber, dass ein Gateway offline ist. Der Leitfaden zu MQTT-QoS und Retain-Nachrichten behandelt beides ausführlich, mit Ablaufzeiten von Nachrichten und dauerhaften Sitzungen.

MQTT-Ports und Sicherheit

MQTT selbst hat ein Feld für Benutzername und Passwort und sonst nichts. Verschlüsselung, Serveridentität und Client-Zertifikate kommen von TLS, die Zugriffskontrolle von den Regeln des Brokers, welcher Client auf welche Topics veröffentlichen oder sie abonnieren darf. Der MQTTS-Leitfaden erklärt Zertifikate, die Prüfung des Servernamens und wie man eine TLS-Verbindung auf der Kommandozeile testet.

MQTT 3.1.1 und MQTT 5 im Vergleich

MQTT wurde 1999 für die Telemetrie von Pipelines über Satellitenverbindungen entwickelt. OASIS hat MQTT 3.1.1 2014 als Standard veröffentlicht, der 2016 zu ISO/IEC 20922 wurde, und MQTT 5.0 im Jahr 2019. Die meisten Broker unterstützen beide, und viele Geräte sprechen nur 3.1.1.

Für Telemetrie sind die Reason Codes am nützlichsten, weil ein Client sieht, dass der Broker eine Nachricht abgelehnt hat, und die Ablaufzeit von Nachrichten, weil ein durch einen Ausfall verzögerter Befehl verworfen statt verspätet ausgeführt wird.

Payloads: JSON, Sparkplug B und der Datenvertrag

MQTT überträgt Bytes und sagt nichts über ihre Bedeutung. Die meisten Energieplattformen erwarten JSON, zum Beispiel:

{"ts":"2026-10-28T09:15:00Z","kW":184.2,"kWh":1532871.4,"V1":231.4,"PF":0.94,"q":"good"}

Das Topic sagt, welcher Zähler es ist; die Nutzdaten tragen die Messzeit, die Werte und ein Qualitätskennzeichen. Die Einheiten und die Bedeutung jedes Schlüssels müssen schriftlich festgehalten und mit jedem Subscriber vereinbart werden: kW oder W, Bezug oder Saldo, die Zeit des Zählers oder die Zeit, zu der das Gateway den Wert empfangen hat. Diese Vereinbarung, nicht die MQTT-Unterstützung, lässt zwei Systeme zusammenarbeiten. Der Leitfaden zur Interoperabilität listet, was ein Datenvertrag festlegen sollte, und der Leitfaden zu Messzeit und Ankunftszeit erklärt, warum die Messzeit in die Nutzdaten gehört.

Sparkplug B, eine in Industriesystemen verbreitete Spezifikation der Eclipse Foundation, legt den Vertrag stattdessen fest. Topics folgen dem Muster spBv1.0/<group>/<message type>/<edge node>/<device>, die Nutzdaten sind binäre Protocol Buffers, und jeder Edge-Knoten veröffentlicht ein Birth Certificate mit seinen Messgrößen und ein Death Certificate (über den Last Will), wenn er die Verbindung verliert. Ein Subscriber kann so Geräte erkennen und Daten ohne eigene Absprache als veraltet markieren, um den Preis eines binären Formats, das einen Sparkplug-fähigen Client zum Lesen braucht.

Rechenbeispiel: Wie viele Daten verbraucht MQTT-Telemetrie?

Fünfzig Zähler veröffentlichen alle 10 Sekunden die obige JSON-Nachricht mit QoS 1. Die Nutzdaten sind 88 Byte lang, das Topic 28 Byte, jedes PUBLISH-Paket also etwa 122 Byte. TLS fügt etwa 22 Byte pro Record hinzu, TCP und IP etwa 52 Byte pro Segment; jede Nachricht belegt auf der Leitung also rund 200 Byte.

Die Nachricht pro Standort trägt die 50 Messwerte als ein JSON-Array von etwa 3.650 Byte (etwa 73 Byte pro Zähler, mit einem Zeitstempel für die ganze Nachricht) plus Topic und Header, die TCP auf drei Segmente verteilt.

Die zurückkommenden PUBACKs kosten im ersten Fall noch einmal rund 30 MB am Tag. Über einen Festnetzanschluss spielt das keine Rolle; über eine Mobilfunk-SIM entscheidet es über den Datentarif. Die Messwerte eines Standorts in einer Nachricht zu bündeln oder nur Änderungen zu senden senkt den Overhead. Der Intervallleistungsrechner hilft, ein Intervall zu wählen, das die Frage, für die die Daten gedacht sind, noch beantwortet.

MQTT im Vergleich mit anderen Protokollen

MQTT ist meist die Verbindung vom Standort zur Plattform, während Modbus, BACnet und OPC UA die Geräte vor Ort lesen. Der Vergleich OPC UA, Modbus und MQTT stellt sie für Industrieprojekte gegenüber, und Was ist Modbus? erklärt die abgefragte Seite.

MQTT mit EpiSensor

Edge auf dem ZGW-20 Gateway liest Zigbee-, Modbus-, BACnet- und LoRaWAN-Geräte vor Ort, speichert jeden Messwert mit seiner Messzeit und veröffentlicht als MQTT-Client an den Broker einer Plattform, normalerweise über MQTTS auf Port 8883 mit einem Client-Zertifikat. Es veröffentlicht mit QoS 1 und hält fehlgeschlagene Zustellungen in einer lokalen Warteschlange, die es mit den ursprünglichen Zeitstempeln wiedergibt, sobald der Broker wieder erreichbar ist. Topics und Nutzdaten folgen dem Vertrag der Plattform, und Edge mit Ihrer Plattform verbinden zeigt, auf welchen Wegen Edge Daten weitergibt.