Webhooks und MQTT: Kommunikation im Smart Home verstehen

Im Smart Home kommunizieren Geräte miteinander. Aber wie genau? Wenn ein Bewegungsmelder Bewegung erkennt, muss diese Information irgendwie zum Licht gelangen. Wenn ein Temperatursensor einen Wert misst, muss Home Assistant davon erfahren. Hinter dieser Kommunikation stecken Muster und Protokolle, die grundlegend unterschiedlich funktionieren.

Zwei der wichtigsten Kommunikationsmuster im Smart Home sind Webhooks und MQTT. Beide lösen das gleiche Problem (Gerät A informiert System B über ein Ereignis), aber auf völlig verschiedene Weise.

Webhooks: Der direkte Anruf

Ein Webhook ist im Grunde ein HTTP-Request, der von einem System an ein anderes gesendet wird, wenn ein bestimmtes Ereignis eintritt. Stell dir einen Webhook als Telefonanruf vor: Ein System ruft ein anderes direkt an und sagt: Hey, es ist etwas passiert.

Technisch funktioniert das so:

1. Du registrierst eine URL (den Webhook-Endpoint) bei einem Dienst.
2. Wenn ein Ereignis eintritt, sendet der Dienst einen HTTP-POST-Request an diese URL.
3. Der Request enthält die relevanten Daten im Body (meist als JSON).
4. Der Empfänger verarbeitet die Daten und antwortet mit einem Status-Code.

Webhook-Beispiel im Smart Home

Du nutzt IFTTT oder n8n, um bei bestimmten Ereignissen eine Aktion in Home Assistant auszulösen. Zum Beispiel: Wenn du eine bestimmte Region auf deinem Handy verlässt, sendet die App einen Webhook an Home Assistant mit der Nachricht: Nutzer hat das Büro verlassen. Home Assistant kann dann die Heizung hochfahren.

Der Webhook-Endpoint in Home Assistant sieht so aus:

POST https://dein-ha.duckdns.org/api/webhook/buero-verlassen Content-Type: application/json { "event": "leave", "user": "thorsten", "timestamp": "2026-06-09T17:30:00Z" }

Vorteile von Webhooks

• Einfach zu verstehen: Ein HTTP-Request ist Webstandard. Jede Programmiersprache, jedes Tool kann HTTP.
• Kein Broker nötig: Sender und Empfänger kommunizieren direkt, ohne Zwischenstation.
• Gut für Cloud-Dienste: IFTTT, Zapier, n8n, GitHub, Stripe und hunderte andere Dienste unterstützen Webhooks nativ.

Nachteile von Webhooks

• Empfänger muss erreichbar sein: Wenn dein Home Assistant gerade offline ist, geht die Nachricht verloren. Es gibt kein erneut senden (es sei denn, der Sender implementiert Retry-Logik).
• 1-zu-1-Kommunikation: Ein Webhook sendet an genau eine URL. Wenn mehrere Systeme dieselbe Information brauchen, musst du mehrere Webhooks konfigurieren.
• Sicherheitsaufwand: Der Endpoint muss aus dem Internet erreichbar sein (oder über einen Tunnel). Das erzeugt eine Angriffsfläche, die abgesichert werden muss.

MQTT: Die Pinnwand

MQTT (Message Queuing Telemetry Transport) funktioniert fundamental anders als Webhooks. Statt direkter Kommunikation gibt es ein Publish/Subscribe-Muster mit einem zentralen Broker als Vermittler.

Technisch funktioniert MQTT so:

1. Ein Broker (z.B. Mosquitto) läuft als zentrale Vermittlungsstelle.
2. Geräte publishen Nachrichten zu einem bestimmten Topic (Thema), z.B. wohnzimmer/temperatur.
3. Andere Geräte subscriben Topics, an denen sie interessiert sind.
4. Der Broker leitet jede veröffentlichte Nachricht an alle Abonnenten des jeweiligen Topics weiter.

MQTT-Beispiel im Smart Home

Ein Zigbee-Temperatursensor sendet über Zigbee2MQTT seine Messwerte an den MQTT-Broker: Topic: zigbee2mqtt/wohnzimmer_sensor Payload: {"temperature": 21.5, "humidity": 48, "battery": 92}

Home Assistant hat dieses Topic abonniert und erhält den Wert automatisch. Gleichzeitig könnte ein Node-RED-Flow dasselbe Topic abonniert haben, um die Daten in eine InfluxDB zu schreiben. Und ein Display im Flur könnte es ebenfalls abonnieren, um die aktuelle Temperatur anzuzeigen. Keines dieser Systeme weiB vom anderen, alle erhalten die Daten parallel.

Vorteile von MQTT

• 1-zu-viele-Kommunikation: Ein Sensor publisht einmal, beliebig viele Empfänger erhalten die Nachricht.
• Lose Kopplung: Sender und Empfänger kennen sich nicht. Du kannst Empfänger hinzufügen oder entfernen, ohne den Sender zu ändern.
• Retained Messages: Der Broker kann die letzte Nachricht pro Topic speichern. Wenn ein neuer Empfänger sich verbindet, erhält er sofort den aktuellen Wert, ohne auf die nächste Veröffentlichung warten zu müssen.
• QoS-Level: MQTT bietet drei Zustellgarantien (0 = maximal einmal, 1 = mindestens einmal, 2 = genau einmal).
• Minimaler Overhead: MQTT-Pakete sind extrem klein. Das Protokoll wurde für eingeschränkte Geräte und langsame Netzwerke entwickelt.
• Lokal und schnell: Ein Mosquitto-Broker läuft auf jedem Raspberry Pi. Keine Cloud, keine Latenz.

Nachteile von MQTT

• Broker erforderlich: Du brauchst eine laufende Instanz von Mosquitto oder einem anderen MQTT-Broker.
• Cloud-Dienste unterstützen MQTT selten: IFTTT, Zapier, GitHub, etc. sprechen kein MQTT. Für Cloud-Anbindung brauchst du Webhooks oder Bridges.
• Topic-Struktur braucht Planung: Eine saubere Topic-Hierarchie ist wichtig, sonst wird es schnell unübersichtlich.

MQTT vs. Webhooks: Der Vergleich

Eigenschaft	Webhooks	MQTT
Muster	Push (HTTP-Request)	Publish/Subscribe
Vermittler	Keiner (direkt)	Broker (z.B. Mosquitto)
Empfänger	Genau einer pro Webhook	Beliebig viele Subscriber
Nachrichtenspeicherung	Nein (fire-and-forget)	Ja (Retained Messages)
Cloud-kompatibel	Ja, nativ	Nur mit Bridge
Lokal nutzbar	Ja, aber aufwendiger	Ja, ideal
Protokoll	HTTP/HTTPS	MQTT (TCP, Port 1883)
Overhead	Hoch (HTTP-Header)	Minimal (2 Byte Header)

Wann Webhooks, wann MQTT?

Nutze Webhooks, wenn:

• Du Cloud-Dienste anbinden willst (IFTTT, n8n, Zapier, GitHub Actions).
• Ein externer Dienst Home Assistant über ein Ereignis informieren soll (z.B. Geofencing, Kalender-Events).
• Du eine einmalige Integration brauchst, die schnell eingerichtet ist.
• Der Sender ausschlieBlich HTTP spricht und kein MQTT-Client verfügbar ist.

Nutze MQTT, wenn:

• Du viele Sensoren und Aktoren lokal vernetzt (Temperatursensoren, Schalter, Lichter).
• Mehrere Systeme dieselben Daten parallel verarbeiten sollen (Home Assistant + Node-RED + Grafana).
• Du Zigbee2MQTT oder Tasmota verwendest, die MQTT als Kommunikationsschicht nutzen.
• Du Offline-Fähigkeit brauchst, also alles lokal ohne Internetverbindung funktionieren soll.

MQTT Topics richtig strukturieren

Einer der häufigsten Fehler bei MQTT-Einsteigern: eine chaotische Topic-Struktur. Wenn du 30 Geräte hast und jedes ein willkürliches Topic nutzt, verlierst du schnell den Überblick. Eine saubere Hierarchie spart dir später Stunden an Debugging.

Die bewährte Struktur folgt dem Schema: bereich/raum/gerät/eigenschaft. Beispiele:

smarthome/wohnzimmer/temperatur_sensor/state smarthome/küche/licht_decke/set smarthome/schlafzimmer/thermostat/current_temperature smarthome/garten/bewegungsmelder/occupancy

Tools wie Zigbee2MQTT und Tasmota erzeugen ihre Topics automatisch. Zigbee2MQTT nutzt das Format zigbee2mqtt/gerätename, Tasmota verwendet tele/gerätename/SENSOR für Telemetrie-Daten. Du musst dich also nicht selbst um die Benennung kümmern, solange du den Gerätenamen in der jeweiligen Software sinnvoll vergibst.

Ein praktischer Tipp: Nutze den MQTT Explorer (kostenlos, Windows/Mac/Linux), um alle Topics deines Brokers in einer Baumansicht zu sehen. So erkennst du sofort, welche Geräte aktiv sind, welche Daten sie senden und ob es Inkonsistenzen in der Benennung gibt.

MQTT in Home Assistant einrichten

Home Assistant bringt eine native MQTT-Integration mit. Der einfachste Weg:

1. Mosquitto Add-on installieren: Unter Einstellungen → Add-ons → Mosquitto broker. Das Add-on läuft direkt auf deinem Home Assistant und braucht keine externe Hardware.
2. MQTT-Integration aktivieren: Unter Einstellungen → Geräte & Dienste → MQTT. Home Assistant erkennt den lokalen Broker automatisch.
3. Zigbee2MQTT nutzt MQTT automatisch: Wenn du Zigbee2MQTT installiert hast, sendet es alle Sensor-Daten über MQTT an Home Assistant. Du musst nichts manuell konfigurieren.

Mehr zu den Kommunikationsprotokollen im Smart Home erfährst du im Artikel Thread: Das Smart-Home-Protokoll erklärt.