Zum Inhalt springen

HomeStackR
Zurück zur Übersicht

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.

Lesezeit: ~6 MinAktualisiert 16. August 2026

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.

1999Jahr der Erstveröffentlichung des MQTT-Protokolls
2 BytesMinimaler MQTT-3.1.1-Header (MQTT 5.0: 3+ Bytes mit Properties)
OASISStandardisierungsorganisation, die MQTT normt

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:2 startet den Broker im Detached-Modus mit Standard-MQTT-Port 1883 und WebSocket-Port 9001 (für Home-Assistant-Integration praktisch). Daten landen im benannten Volume mosquitto_data.
  • Manuell auf Linux: sudo apt install mosquitto mosquitto-clients installiert 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

MQTT ist ein leichtgewichtiges Publish/Subscribe-Protokoll; ein Broker (meist Mosquitto) vermittelt zwischen Geräten und Zentrale. Topics, QoS/Retain und MQTT-Sicherheit folgen darunter.

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.

Schema des MQTT Publish/Subscribe-Modells mit Publisher, Broker und SubscriberKI-generiert
Publisher und Subscriber kommunizieren über den Broker, ohne sich direkt zu kennen.

QoS-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).

QoS 0Feuer-und-vergessen: keine Garantie, schnellste Stufe
QoS 1Bestätigungspflichtig: mindestens einmal, empfohlen für Smart-Home
RetainBroker speichert letzten Wert für neue Abonnenten

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.com holt das Zertifikat; in mosquitto.conf werden cafile, certfile und keyfile auf 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?
HTTP ist Request/Response: ein Client fragt, ein Server antwortet. MQTT ist Event-basiert: ein Publisher sendet, der Broker verteilt an alle Subscriber. Für Smart-Home-Telemetrie (Temperaturen, Schaltzustände) ist effizienter, weil Geräte nicht pollen müssen. HTTP eignet sich für Konfiguration und einmalige API-Calls; MQTT für kontinuierliche Datenströme.
Welche QoS-Stufe sollte ich im Smart Home verwenden?
In den allermeisten Fällen QoS 1. Damit bekommst du eine Liefergarantie (mindestens einmal) mit moderatem Overhead. QoS 0 lohnt sich nur für unkritische, regelmäßig aktualisierte Daten (z. B. Temperatursensoren, die alle 30 s senden – eine verlorene Nachricht ist bei der nächsten schon überholt). QoS 2 ist teuer und nur für Szenarien sinnvoll, in denen Duplikate echte Probleme verursachen (z. B. Zählerstände, die summiert werden).
Wie viele Geräte verkraftet ein einzelner Mosquitto-Broker?
Ein Mosquitto-Broker auf einem Raspberry Pi 4 bedient problemlos 100–500 gleichzeitige Clients und mehrere Tausend Nachrichten pro Sekunde – mehr als genug für typische Smart-Home-Setups. Erst bei zehntausenden Geräten oder sehr hohen Publish-Frequenzen (Industrie-IoT) wird die Hardware zum Engpass. Für ein normales Einfamilienhaus mit 30–80 Geräten ist Mosquitto auf einem Pi oder Mini-PC überdimensioniert.
MQTT vs. WebSocket – wann ist der Unterschied relevant?
WebSocket ist ein Transport-Protokoll, kein Messaging-Protokoll. MQTT kann über WebSocket getunnelt werden (Port 9001), wenn du aus dem Browser heraus MQTT nutzen willst – etwa für ein eigenes Dashboard, das Topics in Echtzeit anzeigt. Für die übliche Broker-Kommunikation zwischen Geräten, Zentralen und Automatisierungs-Engines reicht normales MQTT über TCP (Port 1883).
MQTT 5.0 vs. 3.1.1 – welche Version sollte ich wählen?
Für neue Setups: MQTT 5.0. Es bietet Shared Subscriptions (Lastverteilung bei mehreren Consumern), Message-Expiry (kein unbegrenztes Warten auf Offline-Clients), Reason-Codes (bessere Fehlerdiagnose) und Properties (flexible Metadaten). Mosquitto 2.x unterstützt MQTT 5.0. Bleib nur bei MQTT 3.1.1, wenn du ältere Geräte oder Bibliotheken hast, die kein 5.0 sprechen – die Protokollversionen sind abwärtskompatibel.