Unternehmen stehen heute vor der Herausforderung, immer mehr Daten aus Maschinen, Sensoren und Systemen zuverlässig zu übertragen – oft über verteilte Standorte, Cloud-Plattformen und instabile Netzwerke hinweg. Entscheidend ist dabei nicht nur die Datenerfassung, sondern eine effiziente, skalierbare und robuste Kommunikation.
Genau für diese Anforderungen wurde MQTT entwickelt. Das Protokoll bildet die Grundlage vieler moderner IoT- und Industrie-4.0-Architekturen und hat sich als Standard etabliert, wenn es um zuverlässige Machine-to-Machine-Kommunikation geht.
Was ist MQTT und wofür wird es eingesetzt?
MQTT steht für Message Queuing Telemetry Transport und ist ein offenes Netzwerkprotokoll für die Machine-to-Machine-Kommunikation (M2M). Das Protokoll ermöglicht die Übertragung von Telemetriedaten zwischen Geräten – selbst bei hohen Verzögerungen oder eingeschränkter Netzwerkbandbreite. Damit hat sich MQTT als De-facto-Standard für das Internet der Dinge (IoT) etabliert.
Die Geschichte von MQTT beginnt 1999: Andy Stanford-Clark von IBM und Arlen Nipper entwickelten das Protokoll ursprünglich, um Ölpipelines über Satellitenverbindungen zu überwachen. Die Herausforderung damals: minimale Bandbreite, maximale Zuverlässigkeit. Genau diese Eigenschaften machen MQTT heute zum idealen Kommunikationsprotokoll für IoT-Geräte, Sensoren und Aktoren in der Industrie 4.0.
Seit 2013 wird MQTT von der OASIS (Organization for the Advancement of Structured Information Standards) als offener Standard weiterentwickelt. Mit Version 3.1.1 wurde übrigens festgelegt, dass MQTT kein Akronym mehr ist – der Name steht heute für sich selbst. Die aktuelle Version MQTT 5.0 bringt zusätzliche Funktionen für Enterprise-Anwendungen mit.
Warum ist MQTT für Unternehmen relevant?
MQTT ist kein technisches Selbstzweck-Protokoll, sondern eine Antwort auf sehr konkrete betriebliche Anforderungen. Überall dort, wo viele verteilte Systeme zuverlässig miteinander kommunizieren müssen, spielt MQTT seine Stärken aus. Unternehmen profitieren vor allem von der hohen Skalierbarkeit, dem geringen Ressourcenverbrauch und der Fähigkeit, auch über instabile Netzwerke hinweg stabil zu arbeiten. In der Praxis bedeutet das: geringere Betriebskosten, weniger Komplexität in der Systemarchitektur und eine zukunftssichere Basis für datengetriebene Geschäftsmodelle – von der vernetzten Produktion bis zur Cloud-Integration.
Wie funktioniert das Publish/Subscribe-Prinzip?
Das Herzstück von MQTT ist die Publish/Subscribe-Architektur – ein fundamentaler Unterschied zu klassischen Kommunikationsmodellen wie HTTP mit seinem Request/Response-Prinzip. Bei MQTT kommunizieren Sender und Empfänger niemals direkt miteinander. Stattdessen läuft die gesamte Kommunikation über einen zentralen Vermittler: den MQTT-Broker.
Das Prinzip ist dabei denkbar einfach: Ein Gerät, das Daten senden möchte (Publisher), veröffentlicht seine Nachricht bei einem bestimmten Thema (Topic) auf dem Broker. Alle Geräte, die sich für dieses Thema interessieren (Subscriber), haben das Topic zuvor abonniert und erhalten die Nachricht automatisch vom Broker zugestellt. Der Publisher weiß dabei nicht einmal, ob und wie viele Subscriber es gibt.
Diese Entkopplung bietet entscheidende Vorteile: Publisher und Subscriber müssen weder den Standort noch die Netzwerkadresse des jeweils anderen kennen. Sie müssen nicht einmal gleichzeitig online sein – der Broker puffert Nachrichten für offline Subscriber. Und die ereignisgesteuerte Kommunikation sorgt dafür, dass nur dann Daten übertragen werden, wenn tatsächlich etwas passiert. Das spart Bandbreite und Energie.
Für die Praxis bedeutet das: Ein Temperatursensor in einer Produktionshalle kann seine Messwerte publishen, ohne zu wissen, ob gerade ein Monitoring-System, eine Datenbank oder ein Alarmierungssystem mithört. Neue Subscriber können jederzeit hinzugefügt werden, ohne dass am Sensor etwas geändert werden muss. Diese Flexibilität macht MQTT so attraktiv für IoT-Szenarien mit vielen verteilten Geräten.

Welche Komponenten gehören zu MQTT?
Der MQTT-Broker: Das Herzstück der Kommunikation
Der MQTT-Broker ist der zentrale Server, über den sämtliche Kommunikation läuft. Er empfängt alle Nachrichten von Publishern, filtert sie nach Topics und leitet sie an die entsprechenden Subscriber weiter. Dabei übernimmt der Broker noch weitere wichtige Aufgaben: Er verwaltet alle Client-Verbindungen, speichert Sitzungsdaten für persistente Verbindungen und kümmert sich um Authentifizierung und Autorisierung.
Ein leistungsfähiger Broker kann problemlos tausende gleichzeitige Verbindungen verwalten. In der Praxis haben sich mehrere Broker-Implementierungen etabliert:
- Mosquitto – Open Source, schlank, ideal für Entwicklung und kleinere Installationen
- HiveMQ – Enterprise-Features wie Clustering und High Availability
- AWS IoT Core – Vollständig verwalteter Cloud-Dienst von Amazon
- Azure IoT Hub – Microsofts MQTT-Broker in der Cloud
MQTT-Clients: Vom Mikrocontroller bis zum Server
Als MQTT-Client gilt jedes Gerät, auf dem eine MQTT-Bibliothek läuft und das sich mit einem Broker verbinden kann. Das Spektrum reicht von einfachen Mikrocontrollern wie dem Raspberry Pi oder Arduino über Smartphones und eingebettete Systeme bis hin zu vollwertigen Servern. Ein Client kann dabei die Rolle des Publishers, des Subscribers oder beides gleichzeitig einnehmen.
Der Verbindungsaufbau zwischen Client und Broker erfolgt über TCP/IP. Der Client sendet eine CONNECT-Nachricht, der Broker antwortet mit CONNACK. Ab diesem Moment kann der Client Nachrichten publishen oder Topics abonnieren. Wichtig: Clients kommunizieren niemals direkt miteinander – die Verbindung besteht ausschließlich zwischen Client und Broker.
Topics und Payload: Die Struktur der Nachrichten
MQTT-Topics sind hierarchisch aufgebaut und verwenden den Schrägstrich als Trennzeichen – ähnlich wie Dateipfade. Ein typisches Topic könnte so aussehen: werk1/halle2/maschine3/temperatur. Diese Struktur ermöglicht eine logische Organisation der Daten und erleichtert das gezielte Abonnieren bestimmter Informationen.
Besonders praktisch sind Wildcards beim Subscriben: Das Plus-Zeichen (+) steht für genau eine Hierarchieebene, die Raute (#) für alle darunterliegenden Ebenen. Mit werk1/+/+/temperatur empfängt ein Subscriber alle Temperaturwerte aus allen Hallen und von allen Maschinen in Werk 1. Mit werk1/# erhält er sämtliche Nachrichten aus dem gesamten Werk.
Die Payload – also der eigentliche Nachrichteninhalt – ist bei MQTT bewusst flexibel gehalten. Das Protokoll schreibt kein bestimmtes Format vor. In der Praxis werden häufig JSON oder XML verwendet, aber auch binäre Daten sind möglich. Die maximale Größe einer Nachricht beträgt 256 MB, wobei der Fixed Header nur 2 Byte umfasst. Dieser minimale Overhead ist einer der Gründe, warum MQTT so effizient arbeitet.
Was bedeuten die Quality-of-Service-Level bei MQTT?
MQTT definiert drei Quality-of-Service-Stufen (QoS), die festlegen, mit welcher Zuverlässigkeit Nachrichten zugestellt werden. Die Wahl des richtigen QoS-Levels ist ein Abwägen zwischen Zuverlässigkeit und Ressourcenverbrauch. Die folgende Tabelle zeigt die Unterschiede auf einen Blick:
| QoS | Bezeichnung | Zustellung | Bestätigung | Einsatzbereich |
| 0 | At most once | Max. 1x | Keine | Unkritische Statusmeldungen |
| 1 | At least once | Mind. 1x | PUBACK | Standard für IoT-Anwendungen |
| 2 | Exactly once | Genau 1x | 4-Wege-Handshake | Kritische Daten, Finanztransaktionen |
QoS 0 wird auch „Fire and Forget“ genannt – die Nachricht wird einmal gesendet, ohne Bestätigung. QoS 1 garantiert die Zustellung, kann aber zu Duplikaten führen, wenn die Bestätigung verloren geht. QoS 2 ist der zuverlässigste Modus mit garantiert einmaliger Zustellung, verursacht aber auch den meisten Overhead.
Welche weiteren Funktionen bietet MQTT?
Retained Messages: Der Broker kann die letzte Nachricht eines Topics speichern. Neue Subscriber erhalten diese sofort nach dem Abonnieren – ohne auf die nächste Veröffentlichung warten zu müssen. Das ist praktisch für Statuswerte, die sich selten ändern.
Last Will and Testament: Clients können beim Verbindungsaufbau eine „letzte Nachricht“ hinterlegen. Bricht die Verbindung unerwartet ab, veröffentlicht der Broker diese automatisch. So können andere Teilnehmer sofort erfahren, dass ein Gerät offline gegangen ist – wichtig für Alarmsysteme und Zustandsüberwachung.
Persistente Sitzungen: Bei einer persistenten Sitzung speichert der Broker Abonnements und nicht zugestellte Nachrichten, wenn ein Client offline geht. Nach der Wiederverbindung erhält der Client alle verpassten Nachrichten. Das ist essentiell für mobile Geräte oder Sensoren mit instabiler Verbindung.
MQTT over WebSockets: Über WebSockets lässt sich MQTT direkt im Browser nutzen. Das ermöglicht Echtzeit-Dashboards und Web-Anwendungen, die MQTT-Daten ohne Umweg über Backend-Systeme visualisieren können.
Sicherheit: MQTT-Verbindungen können mit TLS verschlüsselt werden (Port 8883 statt 1883). Zusätzlich unterstützt das Protokoll Authentifizierung per Benutzername und Passwort sowie zertifikatsbasierte Authentifizierung. Moderne Broker bieten außerdem feingranulare Autorisierung auf Topic-Ebene.
Wie unterscheidet sich MQTT von anderen Protokollen?
Zuverlässigkeit ist keine technische Spielerei. In vielen Anwendungsfällen entscheidet nicht nur ob Daten übertragen werden, sondern wie zuverlässig. Ein verlorener Sensordatenpunkt ist oft unkritisch – ein verlorenes Alarmsignal kann es nicht sein. MQTT trägt diesem Unterschied Rechnung und erlaubt es, die Zuverlässigkeit der Datenübertragung je nach Anwendungs gezielt zu steuern.
Im IoT-Umfeld konkurriert MQTT mit mehreren anderen Protokollen. Die Wahl hängt vom konkreten Anwendungsfall ab. Die folgende Tabelle zeigt die wichtigsten Unterschiede:
| Kriterium | MQTT | HTTP/REST | CoAP | OPC UA |
| Kommunikationsmodell | Publish/Subscribe | Request/Response | Request/Response | Client/Server (+ Pub/Sub) |
| Transportprotokoll | TCP | TCP | UDP | TCP |
| Header-Größe | 2 Byte (min.) | 100+ Byte | 4 Byte | Variabel |
| Ideal für | IoT, M2M, Telemetrie | Web-APIs, Services | Ressourcenarme Geräte | Industrieautomation |
Der größte Unterschied zu HTTP liegt im Kommunikationsmodell: HTTP ist synchron und zustandslos – der Client fragt, der Server antwortet. MQTT dagegen hält dauerhafte Verbindungen und pusht Nachrichten ereignisgesteuert. CoAP nutzt UDP statt TCP und ist damit noch leichtgewichtiger, arbeitet aber mit einem anderen Zuverlässigkeitsmodell (Confirmable vs. Non-Confirmable Messages). OPC UA ist der Standard für industrielle Automatisierung mit umfassendem Informationsmodell – in der Praxis werden MQTT und OPC UA oft kombiniert, zumal OPC UA seit Part 14 ebenfalls Publish/Subscribe unterstützt.
Wo wird MQTT in der Praxis eingesetzt?
Industrie 4.0 und IIoT: In der vernetzten Produktion sammeln Sensoren kontinuierlich Daten über Maschinentemperaturen, Drücke, Füllstände oder Vibrationen. MQTT transportiert diese Telemetriedaten zuverlässig an übergeordnete Systeme – für Condition Monitoring, Predictive Maintenance oder die Anbindung an SCADA-Systeme. Die geringe Bandbreite macht MQTT auch für Brownfield-Szenarien attraktiv, wo bestehende Netzwerkinfrastruktur genutzt werden muss.
Smart Home und Gebäudeautomation: Licht, Heizung, Jalousien, Bewegungsmelder – im Smart Home kommunizieren dutzende Geräte miteinander. MQTT ist hier das Protokoll der Wahl für viele DIY-Lösungen und kommerzielle Systeme. Der Broker läuft oft auf einem lokalen Raspberry Pi, die Steuerung erfolgt über Apps oder Sprachassistenten.
Telemetrie und Flottenmanagement: Fahrzeuge übermitteln GPS-Positionen, Kraftstoffverbräuche und Diagnosedaten per MQTT an zentrale Plattformen. Die Fähigkeit, mit instabilen Mobilfunkverbindungen umzugehen und Nachrichten bei Verbindungsabbrüchen zu puffern, macht MQTT ideal für mobile Anwendungen.
Cloud-Integration: Alle großen Cloud-Plattformen unterstützen MQTT nativ. AWS IoT Core, Azure IoT Hub und Google Cloud IoT nutzen MQTT als primäres Protokoll für die Geräteanbindung. So lassen sich Edge-Geräte nahtlos mit Cloud-Diensten für Datenanalyse, Machine Learning oder Langzeitspeicherung verbinden.
Wie gelingt der Einstieg in MQTT?
Der praktische Einstieg in MQTT ist erfreulich unkompliziert. Für erste Experimente genügen ein Broker, ein Publisher und ein Subscriber – alle drei können zunächst auf demselben Rechner laufen.
Broker aufsetzen: Mosquitto ist der populärste Open-Source-Broker und in wenigen Minuten installiert. Unter Linux genügt ein einfaches „apt install mosquitto“. Für Windows und macOS stehen Installer bereit. Alternativ bietet HiveMQ eine kostenlose Cloud-Instanz zum Testen.
Clients nutzen: Zum Testen eignen sich grafische Tools wie MQTT Explorer oder MQTT.fx. Für die Entwicklung stehen Bibliotheken für praktisch jede Programmiersprache bereit: Paho für Python, Java und JavaScript, PubSubClient für Arduino, oder das umqtt-Modul für MicroPython auf dem Raspberry Pi Pico.
Erste Schritte: Nach der Installation verbindet sich ein Client mit dem Broker (Adresse und Port 1883), subscribt ein Topic wie „test/temperatur“ und wartet auf Nachrichten. Ein zweiter Client publisht einen Wert auf dasselbe Topic – und die Nachricht kommt an. Von diesem einfachen Setup aus lassen sich schrittweise komplexere Szenarien aufbauen.
Fazit: MQTT als Standard für IoT-Kommunikation
MQTT hat sich als das Kommunikationsprotokoll für das Internet der Dinge etabliert – und das aus guten Gründen. Das Publish/Subscribe-Prinzip entkoppelt Sender und Empfänger, der minimale Overhead spart Bandbreite und Energie, und die flexiblen QoS-Stufen ermöglichen eine zuverlässige Datenübertragung – auch bei instabilen Verbindungen.
Überall dort, wo viele Geräte effizient, skalierbar und standortübergreifend miteinander kommunizieren müssen – ob in der Industrie, im Smart Building oder in Cloud-nativen IoT-Plattformen – bietet MQTT eine robuste und wirtschaftlich sinnvolle Grundlage. Unternehmen schaffen damit eine zukunftssichere Architektur, die sowohl Edge- als auch Cloud-Szenarien unterstützt und mit wachsenden Anforderungen problemlos mitwächst.
Die breite Unterstützung durch Cloud-Plattformen, ausgereifte Broker-Implementierungen und die Weiterentwicklung mit MQTT 5.0 machen den Einstieg leicht – und eröffnen gleichzeitig Spielraum für anspruchsvolle Enterprise-Anwendungen.
FAQ: Häufige Fragen zu MQTT
Was bedeutet MQTT?
MQTT stand ursprünglich für Message Queuing Telemetry Transport. Seit Version 3.1.1 ist es offiziell kein Akronym mehr, sondern der eigenständige Name des Protokolls.
Welchen Port nutzt MQTT?
MQTT verwendet standardmäßig Port 1883 für unverschlüsselte Verbindungen und Port 8883 für TLS-verschlüsselte Verbindungen. MQTT over WebSockets (WSS) läuft typischerweise auf Port 443.
Ist MQTT sicher?
MQTT selbst bietet nur Basisauthentifizierung mit Benutzername und Passwort. Für sichere Kommunikation sollte MQTT über TLS verschlüsselt werden. Moderne Broker unterstützen zusätzlich zertifikatsbasierte Authentifizierung und feingranulare Zugriffskontrollen.
Was ist der Unterschied zwischen MQTT und HTTP?
HTTP ist ein Request/Response-Protokoll – der Client fragt aktiv an. MQTT arbeitet ereignisgesteuert nach dem Publish/Subscribe-Prinzip – Nachrichten werden gepusht. MQTT hat einen minimalen Overhead (2 Byte Fixed Header), hält dauerhafte Verbindungen und ist damit effizienter für IoT-Szenarien.