
Fortgeschritten · Kapitel 9 von 20
MQTT verstehen und einsetzen
MQTT ist das Standard-Protokoll im Smart-Home-IoT – Broker, Topics, QoS, Sicherheit. Wer MQTT versteht, versteht Zigbee2MQTT, ESPHome und Node-RED.
Affiliate-Links: Als Amazon-Partner verdiene ich an qualifizierten Verkäufen – für dich bleibt der Preis gleich.
Das Wichtigste in Kürze
3 Kernaussagen für Schnellleser
MQTT ist das Kommunikations-Rückgrat fast jeder lokalen Smart-Home-Zentrale – von Shelly und ESPHome bis Node-RED. Das Publish-Subscribe-Prinzip entkoppelt Geräte vom Empfänger über einen zentralen Broker (meist Mosquitto): Geräte können jederzeit hinzukommen oder wegfallen, ohne dass Abhängigkeiten neu verdrahtet werden müssen.
- MQTT nutzt das Publish/Subscribe-Prinzip: Geräte (Publisher) senden Nachrichten an einen Broker, andere Geräte oder deine Smart-Home-Zentrale (Subscriber) abonnieren Topics.
- Der Broker – meist Mosquitto – vermittelt und entkoppelt Sender und Empfänger.
- MQTT-Pakete sind mit einem 2-Byte-Header extrem schlank und funktionieren auch in unzuverlässigen Netzwerken.
Was ist MQTT und warum ist es so wichtig?
MQTT wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Eurotech) entwickelt, um Sensordaten von Pipelines über Satellitenverbindungen zu übertragen. Das Protokoll ist bewusst minimalistisch: ein Header besteht aus nur 2 Bytes, und die Verbindung hält auch bei schlechten Netzwerkkonditionen. Heute ist MQTT ein OASIS-Standard und eines der meistverwendeten Protokolle im Internet der Dinge. MQTT 5.0 erweitert den Header um Properties-Variablen (3+ Bytes) und bringt Features wie Shared Subscriptions, Message-Expiry und Reason-Codes mit. Für neue Setups ist MQTT 5.0 empfohlen; MQTT 3.1.1 bleibt abwärtskompatibel.
Im Smart-Home-Kontext ist MQTT der universelle Klebstoff: Ein Zigbee-Coordinator mit Zigbee2MQTT publiziert Gerätedaten per MQTT, ESP32-Boards mit ESPHome senden Sensordaten über MQTT, Node-RED verarbeitet MQTT-Nachrichten, und Home Assistant abonniert MQTT-Topics, um Entitäten zu erstellen. Wer MQTT versteht, versteht, wie diese Systeme zusammenarbeiten.
Der Broker: Mosquitto als zentraler Verteiler
Der Broker ist das Herzstück jedes MQTT-Systems. Er nimmt Nachrichten von Publishern entgegen und verteilt sie an alle Subscriber, die das entsprechende Topic abonniert haben. Publisher und Subscriber können auf demselben Rechner laufen oder auf verschiedenen Geräten im Netzwerk – der Broker vermittelt.
Der verbreitetste Broker im Smart-Home-Umfeld ist Eclipse Mosquitto. Er ist leichtgewichtig (unter 1 MB Speicherbedarf), Open Source und läuft auf einem Raspberry Pi(öffnet in neuem Tab) mit High-Endurance-microSD(öffnet in neuem Tab), einem Mini-PC(öffnet in neuem Tab) oder als Home-Assistant-Add-on – mit grafischer Konfiguration und automatischem Start.
- Als Home Assistant Add-on: Einstellungen > Add-ons > "Mosquitto broker" > Installieren. Konfiguriere Benutzer und Passwörter im Add-on-Dialog.
- Als Docker-Container:
docker run -d --name mosquitto -p 1883:1883 -p 9001:9001 eclipse-mosquitto:2startet den Broker im Detached-Modus mit Standard-MQTT-Port 1883 und WebSocket-Port 9001 (für Home-Assistant-Integration praktisch). Daten landen im benannten Volumemosquitto_data. - Manuell auf Linux:
sudo apt install mosquitto mosquitto-clientsinstalliert Broker und Kommandozeilen-Tools.
Pro-Tipp
Installiere das Mosquitto-Add-on zusammen mit dem "File editor"-Add-on in Home Assistant. So kannst du die Mosquitto-Konfigurationsdatei bequem über die Weboberfläche bearbeiten, ohne SSH-Zugriff zu benötigen.
Das Wesentliche in Kürze
Topics und das Publish/Subscribe-Prinzip
Topics sind die Adressen im MQTT-System – ähnlich wie Verzeichnispfade in einem Dateisystem. Sie sind hierarchisch aufgebaut und durch Schrägstriche getrennt.
Topic-Hierarchie
Ein typisches Smart-Home-Topic könnte so aussehen: zigbee2mqtt/wohnzimmer/temperatur. Die Ebenen von links nach rechts: System (zigbee2mqtt), Raum (wohnzimmer), Geräteeigenschaft (temperatur). Du kannst beliebig viele Ebenen verwenden. Eine gute Namenskonvention von Anfang an spart später viel Suchzeit.
Publish: Nachrichten senden
Ein Publisher sendet (publiziert) eine Nachricht an ein Topic. Die Nachricht besteht aus dem Topic (Adresse) und der Payload (Inhalt). Beispiel: ein Temperatursensor veröffentlicht die Nachricht "21.5" an das Topic "wohnzimmer/temperatur". Der Broker speichert die Nachricht und leitet sie an alle Abonnenten weiter.
Subscribe: Nachrichten empfangen
Ein Subscriber meldet Interesse an einem Topic an. Sobald eine Nachricht auf diesem Topic erscheint, liefert der Broker sie aus. Du kannst mit Wildcards mehrere Topics gleichzeitig abonnieren: "+" ersetzt eine einzelne Ebene (z. B. "wohnzimmer/+/temperatur" passt auf "wohnzimmer/sensor1/temperatur" und "wohnzimmer/sensor2/temperatur"). "#" ersetzt alle weiteren Ebenen (z. B. "wohnzimmer/#" passt auf alles unterhalb von "wohnzimmer").
Ein konkretes Beispiel aus dem Smart-Home-Alltag: zigbee2mqtt/wohnzimmer/+/temperature matched alle Temperatursensoren im Wohnzimmer – egal in welchem Stockwerk oder Raumabschnitt. So kannst du mit einer einzigen Subscription die Temperaturen aller Zigbee-Geräte eines Raums einsammeln.
Wusstest du schon?
Publisher und Subscriber kennen einander nicht. Ein Publisher weiß nicht, ob jemand seine Nachricht liest. Ein Subscriber weiß nicht, wer die Nachricht geschrieben hat. Diese Entkopplung macht MQTT außerordentlich flexibel: du kannst Geräte hinzufügen oder entfernen, ohne andere Geräte umkonfigurieren zu müssen.
KI-generiertQoS-Level und Retain: Zuverlässigkeit verstehen
MQTT bietet drei Quality-of-Service-Stufen (QoS), die bestimmen, wie zuverlässig eine Nachricht zugestellt wird:
QoS 0 – At most once (höchstens einmal)
Der Publisher sendet die Nachricht und vergisst sie. Keine Bestätigung, kein Wiederholungsversuch. Die Nachricht kommt an – oder auch nicht. Geeignet für Daten, die ohnehin regelmäßig aktualisiert werden (z. B. Temperatur alle 30 Sekunden). Wenn eine Nachricht verloren geht, liefert die nächste Nachricht aktuelle Werte.
QoS 1 – At least once (mindestens einmal)
Der Publisher sendet die Nachricht und wartet auf eine Bestätigung (PUBACK). Erhält er keine, sendet er erneut. Die Nachricht wird mindestens einmal zugestellt – möglicherweise doppelt. Geeignet für Kommandos wie "Licht einschalten", bei denen eine Duplikierung nicht schadet.
QoS 2 – Exactly once (genau einmal)
Ein Zweiphasen-Handshake garantiert, dass die Nachricht genau einmal zugestellt wird – nicht mehr und nicht weniger. Der Overhead ist deutlich größer als bei QoS 0 und 1. Verwende QoS 2 nur für kritische Daten, bei denen Duplikate zu Problemen führen würden (z. B. Zählerstände, die summiert werden).
Retain: Den letzten Wert speichern
Normalerweise erhält ein Subscriber nur Nachrichten, die veröffentlicht werden, nachdem er sein Abonnement gestartet hat. Was ist mit dem letzten Zustand eines Geräts – schaltet jemand die Lampe an, bevor das Dashboard verbunden ist? Hier kommt Retain ins Spiel: wenn ein Publisher eine Nachricht mit dem Retain-Flag sendet, speichert der Broker diese Nachricht und liefert sie sofort an jeden neuen Subscriber aus. So erfährt der Subscriber sofort den aktuellen Zustand, ohne auf die nächste Aktualisierung warten zu müssen.
Pro-Tipp
Verwende QoS 1 als Standard für Smart-Home-Anwendungen. QoS 0 riskiert Nachrichtenverlust, QoS 2 kostet Performance ohne spürbaren Mehrwert für typische Hausautomatisierungen. Aktiviere Retain für alle Topics, die einen aktuellen Gerätezustand repräsentieren (z. B. Ein/Aus-Status, Temperatur).
Sicherheit: Absicherung und Best Practices
MQTT ist ein Netzwerkprotokoll – und wie jedes Netzwerkprotokoll muss es abgesichert werden. Die wichtigsten Maßnahmen:
- Authentifizierung: Konfiguriere Mosquitto mit Benutzername und Passwort. Jeder Client muss sich authentifizieren, bevor er verbinden darf. Erstelle separate Konten für Zigbee2MQTT, Home Assistant, Node-RED und Test-Clients.
- TLS-Verschlüsselung: Aktiviere TLS für die Verbindung zwischen Clients und Broker. So können Passwörter und Sensordaten nicht im Klartext im Netzwerk mitgelesen werden. Mosquitto unterstützt Zertifikate von Let's Encrypt oder selbstsignierte Zertifikate. Für produktive Setups:
certbot certonly --standalone -d mqtt.example.comholt das Zertifikat; inmosquitto.confwerdencafile,certfileundkeyfileauf die Let's-Encrypt-Pfade unter/etc/letsencrypt/live/mqtt.example.com/gesetzt. - Nicht ins Internet exponieren: Mosquitto sollte nur im lokalen Netzwerk erreichbar sein. Verwende niemals Port-Forwarding im Router. Für den Fernzugriff nutze ein VPN (WireGuard, Tailscale) – z. B. über einen GL.iNet VPN-Router(öffnet in neuem Tab) – oder Nabu Casa.
- ACLs (Access Control Lists): Mosquitto erlaubt es, Lese- und Schreibrechte pro Benutzer und Topic zu definieren. Ein Zigbee2MQTT-Client braucht Schreibzugriff auf "zigbee2mqtt/#", ein Test-Client sollte nur lesen dürfen.
Mosquitto-ACL in der Praxis: Lege die Datei /etc/mosquitto/acl an und verweise in mosquitto.conf darauf:
acl_file /etc/mosquitto/acl
Ein Eintrag pro Benutzer mit Topic-Rechten:
user zigbee2mqtt
topic readwrite zigbee2mqtt/#
user testclient
topic read zigbee2mqtt/#
Wusstest du schon?
MQTT überträgt standardmäßig unverschlüsselt. Ohne TLS kann jeder im selben Netzwerk die Nachrichten (inklusive Passwörter) mit einem einfachen Tool wie "mosquitto_sub" mitlesen. Die Verschlüsselung per TLS ist keine Option – sie ist ein Muss.
Häufige Fragen zu MQTT
Häufig gestellte Fragen
MQTT vs. HTTP – was ist der Unterschied fürs Smart Home?
Welche QoS-Stufe sollte ich im Smart Home verwenden?
Wie viele Geräte verkraftet ein einzelner Mosquitto-Broker?
MQTT vs. WebSocket – wann ist der Unterschied relevant?
MQTT 5.0 vs. 3.1.1 – welche Version sollte ich wählen?
Passende Tools