Was ist MQTT? Das leichtgewichtige IoT-Protokoll erklärt

Souveräne IoT-Plattform auf Basis von MQTT aufbauen? WZ-IT plant, betreibt und integriert Open-Source-IoT-Stacks auf Ihrer Infrastruktur - vom Broker bis zum Dashboard. Zur IoT-Plattform - Erstgespräch buchen

MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges Publish/Subscribe-Protokoll für das Internet of Things. Geräte senden Nachrichten nicht direkt aneinander, sondern an benannte Kanäle (Topics) auf einem zentralen Broker. Andere Clients abonnieren diese Topics und erhalten neue Nachrichten automatisch. Diese Entkopplung, ein minimaler Protokoll-Overhead und abgestufte Zustellgarantien machen MQTT zum De-facto-Standard für die Geräte-Kommunikation - effizient genug für tausende Sensoren über schmalbandige oder instabile Netze. MQTT läuft über TCP/IP, standardmäßig auf Port 1883 (unverschlüsselt) und 8883 (TLS), und ist als OASIS-Standard in den Versionen 3.1.1 und 5.0 spezifiziert.

Inhaltsverzeichnis

• Wie MQTT funktioniert: Broker und Publish/Subscribe
• Topics und Wildcards
• QoS 0, 1 und 2: Zustellgarantien
• Retained Messages und Last Will
• MQTT 3.1.1 vs. MQTT 5.0
• Sicherheit: TLS, Authentifizierung und ACLs
• Broker im Vergleich: Mosquitto und EMQX
• MQTT vs. HTTP vs. CoAP: wann was
• MQTT mit ThingsBoard und Node-RED
• MQTT souverän betreiben mit WZ-IT
• Weiterführende Guides

Wie MQTT funktioniert: Broker und Publish/Subscribe

Im Zentrum jeder MQTT-Architektur steht der Broker (Server). Clients verbinden sich mit ihm und übernehmen zwei Rollen, oft gleichzeitig: Ein Publisher sendet eine Nachricht an ein Topic, ein Subscriber abonniert ein oder mehrere Topics. Der Broker nimmt jede veröffentlichte Nachricht entgegen und leitet sie an alle passenden Abonnenten weiter. Sender und Empfänger kennen einander nicht und müssen nicht gleichzeitig online sein - das nennt man Entkopplung in Raum, Zeit und Synchronisation.

Statt vieler Punkt-zu-Punkt-Verbindungen entsteht ein Stern: Jeder Client hält genau eine dauerhafte TCP-Verbindung zum Broker. Die wird offen gehalten (Keep-Alive), sodass der Broker Daten jederzeit per Push zustellen kann, ohne dass der Client pollen muss. Ein einziger CONNECT-Handshake genügt, danach sind die Pakete sehr klein - der feste Header eines PUBLISH-Pakets ist nur zwei Byte groß. Genau diese Sparsamkeit ist der Grund, warum MQTT in der IoT-Architektur typischerweise die Transportschicht zwischen Geräten und Plattform bildet.

Topics und Wildcards

Topics sind hierarchische, durch Schrägstriche getrennte Zeichenketten, zum Beispiel gebaeude/etage1/raum2/temperatur. Sie werden nicht vorab angelegt - ein Topic existiert, sobald jemand dorthin publisht. Für Abonnements gibt es zwei Wildcards:

• + ersetzt genau eine Ebene: gebaeude/+/raum2/temperatur trifft alle Etagen.
• # ersetzt mehrere Ebenen am Ende: gebaeude/etage1/# trifft alles unterhalb von Etage 1.

Wildcards sind nur beim Subscriben erlaubt, nicht beim Publishen. Eine durchdachte Topic-Hierarchie ist entscheidend für saubere Berechtigungen und Filterung - sie ist faktisch das Adressschema Ihrer gesamten IoT-Datenflüsse.

QoS 0, 1 und 2: Zustellgarantien

MQTT bietet drei Quality-of-Service-Stufen, die pro Nachricht gewählt werden und Zuverlässigkeit gegen Overhead abwägen:

Höhere QoS bedeutet mehr Pakete und mehr Zustandshaltung. Für reine Messreihen, bei denen ein einzelner verlorener Wert egal ist, genügt meist QoS 0 oder 1. QoS 2 reserviert man für Fälle, in denen eine doppelte Verarbeitung schadet.

Retained Messages und Last Will

Zwei Mechanismen machen MQTT für reale Geräte robust:

• Retained Message: Wird eine Nachricht mit gesetztem Retain-Flag publisht, speichert der Broker sie als letzten bekannten Wert des Topics. Jeder neue Abonnent erhält sie sofort beim Subscriben - ideal für Statusinformationen wie "Pumpe an/aus", die ein frisch verbundener Client sonst erst beim nächsten Update erfahren würde.
• Last Will and Testament (LWT): Beim Verbinden hinterlegt ein Client eine Nachricht, die der Broker automatisch publisht, wenn die Verbindung unerwartet abreißt. So erfahren andere Teilnehmer zuverlässig, dass ein Gerät offline ist, ohne aktiv pollen zu müssen.

MQTT 3.1.1 vs. MQTT 5.0

MQTT 3.1.1 ist seit 2014 OASIS-Standard und nach wie vor extrem verbreitet. MQTT 5.0 wurde am 7. März 2019 als OASIS-Standard verabschiedet (oasis-open.org) und bringt vor allem für größere, produktive Systeme wichtige Erweiterungen:

• Reason Codes: aussagekräftige Rückmeldungen statt simpler Erfolg/Fehler-Codes.
• User Properties: beliebige Key-Value-Metadaten pro Nachricht, etwa für Routing oder Tracing.
• Topic Aliases: lange Topic-Namen werden durch kurze numerische Aliase ersetzt und sparen Bandbreite.
• Session Expiry und Message Expiry: explizite Lebensdauer für Sessions und Nachrichten.
• Shared Subscriptions: mehrere Consumer teilen sich ein Abonnement zur Lastverteilung.
• Flow Control und Request/Response: kontrollierter Nachrichtenfluss und ein sauberes Anfrage/Antwort-Muster.

MQTT 5.0 ist abwärtskompatibel - ein 5.0-Broker akzeptiert auch 3.1.1-Clients. Für neue Plattformen empfehlen wir MQTT 5.0, sofern Geräte-Firmware und Bibliotheken es unterstützen.

Sicherheit: TLS, Authentifizierung und ACLs

MQTT bringt selbst keine Verschlüsselung mit, lässt sich aber durchgängig absichern - drei Ebenen gehören immer dazu:

1. Transportverschlüsselung: TLS auf Port 8883 statt Klartext auf 1883. Damit sind Anmeldedaten und Nutzdaten gegen Mitlesen und Manipulation geschützt.
2. Authentifizierung: Benutzername und Passwort im CONNECT-Paket oder, stärker, Client-Zertifikate (mTLS). Größere Broker unterstützen zusätzlich JWT/OAuth.
3. Autorisierung: Access Control Lists (ACLs) regeln pro Identität, welche Topics ein Client publishen oder abonnieren darf - das verhindert, dass ein kompromittiertes Gerät fremde Datenströme mitliest oder fälscht.

Wer MQTT öffentlich erreichbar macht, sollte 1883 niemals offen ins Internet stellen, sondern ausschließlich TLS plus Authentifizierung nutzen.

Broker im Vergleich: Mosquitto und EMQX

Die Broker-Wahl bestimmt Betrieb, Skalierung und Lizenzfreiheit. Zwei Vertreter dominieren in self-hosted Setups:

Eclipse Mosquitto ist der pragmatische Standard für die meisten Projekte und Edge-Gateways; Version 2.1.2 erschien am 9. Februar 2026. EMQX zielt auf sehr große, verteilte Lasten - allerdings steht die Open-Source-Linie seit Version 5.9 unter der Business Source License (BSL 1.1), nicht mehr unter Apache 2.0; das gilt auch für die aktuelle Linie 6.x (Stand Oktober 2026: 6.3.1). Kostenlos produktiv nutzbar ist laut Lizenztext ein einzelner Knoten, sofern EMQX nicht als gehosteter Dienst oder eingebettet in ein Produkt für Dritte angeboten wird; Bildungseinrichtungen und gemeinnützige Organisationen dürfen EMQX ohne diese Einschränkung produktiv einsetzen, solange die Nutzung nicht gewinnorientiert ist. Alle anderen Cluster brauchen eine kommerzielle Lizenz. Die letzte Apache-Version 5.8 hat laut Hersteller am 28. Februar 2026 ihr End-of-Life erreicht. Wer echte OSI-Open-Source mit Clustering braucht, prüft etwa VerneMQ; für einzelne Knoten kommen auch HiveMQ Community Edition oder NanoMQ in Frage, Clustering bietet HiveMQ nur in den kommerziellen Editionen. Wir wählen den Broker bewusst nach Souveränität, Last und Betriebsaufwand - kein Cloud-Lock-in, keine Per-Device-Lizenzkosten.

MQTT vs. HTTP vs. CoAP: wann was

MQTT spielt seine Stärke aus, wenn viele Geräte dauerhaft verbunden bleiben und kontinuierlich Daten senden oder Befehle in Echtzeit empfangen. HTTP passt für seltene, request-basierte Aufrufe und einfache REST-Anbindung. CoAP ist die UDP-basierte Wahl für extrem eingeschränkte Geräte, etwa batteriebetriebene Sensoren ohne stabile Verbindung.

MQTT mit ThingsBoard und Node-RED

In der Praxis ist MQTT der Klebstoff zwischen Sensorik und Plattform. ThingsBoard bringt einen eigenen MQTT-Transport mit und verhält sich für Geräte wie ein Broker: Geräte verbinden sich auf 1883 oder 8883, authentifizieren sich meist über ein Access-Token als MQTT-Benutzername und publishen Telemetrie an v1/devices/me/telemetry. ThingsBoard akzeptiert MQTT v3.1, v3.1.1 und v5.0 (thingsboard.io). Unsere Umsetzung beschreibt die ThingsBoard-Expertise.

Für Vorverarbeitung, Protokollübersetzung und Routing setzen wir Node-RED ein: Mit den MQTT-In- und MQTT-Out-Nodes abonniert Node-RED Topics, transformiert oder filtert Nutzdaten und schreibt sie weiter - etwa in eine Zeitreihendatenbank, deren Auswertung Sie im Grafana-IoT-Dashboard sehen. So entsteht ein durchgängiger, offener Datenpfad vom Sensor bis zur Visualisierung.

MQTT souverän betreiben mit WZ-IT

MQTT ist offen, schlank und herstellerneutral - die ideale Basis für eine souveräne IoT-Plattform ohne Cloud-Lock-in und ohne Per-Device-Lizenzexplosion. Wir bei WZ-IT planen den Broker (meist Mosquitto, bei Bedarf skalierbare Cluster), härten ihn mit TLS, mTLS und ACLs, und integrieren ihn mit ThingsBoard, Node-RED und Grafana auf Ihrer eigenen Infrastruktur in der EU - Proxmox, Hetzner oder On-Premises. Sie behalten Daten, Schlüssel und Betrieb in der Hand.

MQTT-Broker und IoT-Stack self-hosted aufsetzen? Zur IoT-Plattform-Entwicklung - Erstgespräch buchen

Weiterführende Guides

• Was ist ThingsBoard? - die IoT-Plattform mit eigenem MQTT-Transport
• IoT-Architektur: die Schichten erklärt - wo MQTT im Gesamtbild sitzt
• Grafana-IoT-Dashboard mit InfluxDB - Telemetrie sichtbar machen
• Node-RED-Expertise - MQTT-Daten verarbeiten und routen