Was ist MQTT?

MQTT hilft Geräten und Systemen, Daten auszutauschen, ohne dass sie direkt miteinander verbunden sein müssen. Ein Sensor, eine Maschine oder ein Gateway sendet eine Nachricht an den MQTT Broker. Andere Systeme, zum Beispiel ein Dashboard oder MES, abonnieren die passenden Daten und erhalten sie automatisch.

Der wichtigste Unterschied zu vielen klassischen Schnittstellen ist, dass MQTT mit Ereignissen arbeitet. Ein System muss nicht ständig nachfragen, ob es neue Daten gibt. Es abonniert ein Topic und bekommt neue Nachrichten automatisch, sobald sie veröffentlicht werden.

Das macht MQTT besonders nützlich, wenn viele Geräte regelmäßig Daten liefern. Selbst bei instabilen Verbindungen können Nachrichten zuverlässig übertragen werden. So kommen Daten von Maschinen und Sensoren schnell in IT-Systeme.

Der Name MQTT steht heute einfach nur für das Protokoll. Früher bedeutete er „MQ Telemetry Transport“. Manche sagen auch „Message Queuing Telemetry Transport“ – das ist aber technisch nicht ganz korrekt.

MQTT besteht aus wenigen Rollen und einem klaren Ablauf. Jeder Teilnehmer ist ein Client. Der Client verbindet sich mit dem Broker, publiziert Nachrichten oder abonniert Topics. Der Broker ist die Drehscheibe.

• Connect: Der Client verbindet sich mit Host, Port, Client-ID, Keep Alive und optionalen Zugangsdaten.
• Subscribe: Ein empfangender Client abonniert ein Topic oder einen Topic Filter.
• Publish: Ein sendender Client publiziert eine Nachricht mit Topic, Payload, QoS und optional Retain-Flag.
• Forward: Der Broker leitet die Nachricht an alle passenden Subscriptions weiter.

MQTT läuft typischerweise über TCP. Standardports sind 1883 für unverschlüsseltes MQTT und 8883 für MQTT über TLS. In Browsern oder Web-Dashboards wird MQTT häufig über WebSockets transportiert.

Der MQTT Broker ist der zentrale Server im MQTT System. Ohne Broker sprechen MQTT Clients nicht direkt miteinander.

Bekannte Broker sind Mosquitto, HiveMQ, EMQX und Cloud-Angebote wie AWS IoT Core.

Wie MQTT mit SPS, Edge, MES und Cloud zusammenspielt, zeigt unser Praxisleitfaden zu Industrie 4.0.

MQTT Topics sind hierarchische Namen für Nachrichten. Ein Topic kann zum Beispiel so aussehen:

factory/line1/press7/temperature

Gute Topic-Strukturen sind entscheidend. Sie legen fest, wie Systeme Daten finden und filtern – und wie Zugriffsrechte pro Topic vergeben werden. Ein typisches industrielles Schema trennt Standort, Linie, Maschine und Signal.

• Plus-Wildcard: factory/+/press7/state steht für genau einen beliebigen Abschnitt im Topic-Pfad, zum Beispiel line1 oder line2.
• Hash-Wildcard: factory/line1/# umfasst alle Topics, die mit factory/line1 beginnen – unabhängig davon, wie viele weitere Abschnitte danach folgen.
• Systemtopics: Topics mit $ am Anfang enthalten interne Broker-Informationen wie Status, Statistiken oder Verbindungsdaten. Sie gehören nicht zu normalen Maschinendaten.

Topics sollten stabil, lesbar und nicht zu granular werden. Wer jedes einzelne Bit als eigenes Topic modelliert, erzeugt meist mehr Verwaltungsaufwand als Nutzen.

QoS steht für Quality of Service. MQTT unterscheidet drei Stufen für die Nachrichtenübertragung. Sie legen fest, wie zuverlässig eine Nachricht zugestellt wird. Eine höhere QoS-Stufe benötigt mehr Bestätigungen und erzeugt dadurch mehr Netzwerkverkehr.

• QoS 0 - at most once: Die Nachricht wird einmal gesendet. Es gibt keine Bestätigung. Geeignet für häufige Messwerte, bei denen ein einzelner Wert verloren gehen darf.
• QoS 1 - at least once: Die Zustellung wird bestätigt. Die Nachricht kommt an, kann aber bei Wiederholungen doppelt auftreten. Empfänger müssen damit umgehen können.
• QoS 2 - exactly once: Die Zustellung erfolgt mit vierstufigem Handshake genau einmal. Das ist die ressourcenaufwendigste Stufe und wird nur eingesetzt, wenn Duplikate problematisch sind.

In vielen Industrieprojekten ist QoS 1 der Standard. QoS 2 ist selten notwendig und sollte bewusst eingesetzt werden.

MQTT kann mehr als reine Live-Nachrichten. Mit retained messages, persistenten Sessions und Last Will lassen sich robuste Systeme bauen, die auch bei Verbindungsabbrüchen brauchbar bleiben.

• Retained Message: Der Broker speichert die letzte Nachricht auf einem Topic und sendet sie sofort an neue Subscriber. Gut für aktuelle Sollwerte, Status oder Konfiguration.
• Session: Der Broker kann Subscriptions und ausstehende QoS Nachrichten für einen Client behalten, wenn dieser offline geht.
• Last Will and Testament: Der Client hinterlegt eine Will-Nachricht. Der Broker publiziert sie, wenn der Client unerwartet abbricht.

MQTT 3.1.1 ist sehr verbreitet und für viele Anwendungen weiterhin völlig ausreichend. MQTT 5 erweitert das Protokoll um Funktionen, die große und professionell betriebene Systeme besser steuerbar machen.

• Reason Codes: Clients bekommen genauere Rückmeldungen, warum eine Verbindung oder Subscription abgelehnt wurde.
• User Properties: Nachrichten können Metadaten als Key-Value-Paare tragen.
• Message Expiry: Nachrichten können automatisch ungültig werden, wenn sie zu alt sind.
• Topic Alias: Wiederholte lange Topic-Namen können effizienter übertragen werden.
• Request/Response: Response Topic und Correlation Data erleichtern Anfrage-Antwort-Muster.

Neue Projekte sollten MQTT 5 in Betracht ziehen. Wenn bestehende Geräte nur MQTT 3.1.1 unterstützen, ist das kein Ausschlusskriterium. Entscheidend ist, dass Broker, Clients und das Security-Konzept zusammenpassen.

MQTT ist nicht automatisch sicher oder unsicher. Die Sicherheit hängt von Transport, Authentifizierung, Autorisierung und Betrieb ab. Ein offener Broker im Produktionsnetz ist ein Risiko. Ein sauber segmentierter Broker mit TLS und Topic-Rechten ist eine robuste Integrationskomponente.

• TLS: Verschlüsselt die Verbindung und verhindert, dass Payloads und Zugangsdaten im Klartext übertragen werden.
• Authentifizierung: Clients melden sich per Benutzer/Passwort, Zertifikat oder externem Identity-System an.
• Autorisierung: Nicht jeder Client darf jedes Topic lesen oder schreiben. Der Broker sollte klar regeln, welche Clients auf welche Topics zugreifen dürfen.
• Netzwerkdesign: Broker gehören in definierte Zonen. Direkte Verbindungen aus dem IT-Netzwerk in Steuerungsnetze sollten vermieden werden.

MQTT ersetzt nicht jedes Protokoll. Es ist stark, wenn viele Clients eventbasierte Telemetrie oder Statusmeldungen austauschen. Andere Protokolle haben andere Stärken.

• MQTT vs. HTTP: HTTP ist ideal für klassische Request/Response-APIs. MQTT ist effizienter für laufende Telemetrie und viele kleine Ereignisse.
• MQTT vs. WebSocket: WebSocket ist ein Transport für bidirektionale Verbindungen. MQTT kann über WebSocket laufen, bringt aber zusätzlich Topics, QoS und Broker-Semantik mit.
• MQTT vs. AMQP: AMQP ist umfangreicher und stark in Enterprise-Messaging mit Queues und Routing. MQTT ist einfacher und besser für kleine Clients geeignet.
• MQTT vs. Kafka: Kafka ist eine verteilte Event-Log- und Streaming-Plattform. MQTT ist die lightweight Edge- und Device-Kommunikation. In großen Architekturen werden beide oft kombiniert.

MQTT wird dort eingesetzt, wo viele Quellen kleine Datenpakete liefern oder Steuerinformationen empfangen sollen. In der Industrie ist MQTT oft die Brücke zwischen der Anlagenebene und der IT.

• Maschinendaten von Gateways an MES, ERP oder eine Zeitreihendatenbank.
• Statusmeldungen von Anlagen, Robotern und Fördertechnik.
• Energie-, Temperatur-, Druck- und Vibrationsdaten.
• Home Assistant, ESP32 und Raspberry Pi Projekte.
• Remote Monitoring für verteilte Maschinen und Standorte.
• Edge-to-Cloud Integration über AWS IoT, Azure IoT oder eigene Broker.

Das MQTT Ökosystem bietet Werkzeuge für unterschiedliche Aufgaben.