Wenn das WLAN mal ausfällt oder der Cloud‑Dienst plötzlich keine Verbindung mehr hat, ist der Moment gekommen, in dem ich merke, wie abhängig mein Smart‑Home von externen Diensten geworden ist. Ich zeige dir in diesem Beitrag, wie du mit IFTTT und MQTT deine smarten Lampen so einrichtest, dass sie auch offline zuverlässig steuerbar sind — ideal für mehr Privatsphäre, Stabilität und geringe Latenz.
Warum IFTTT und MQTT kombinieren?
IFTTT ist praktisch für Automationen und Verknüpfungen zwischen Services, aber viele Applets sind cloudbasiert. MQTT ist ein leichtgewichtiges Protokoll für die lokale Kommunikation zwischen Geräten. In Kombination nutze ich IFTTT für externe Trigger (z. B. Google Assistant, Webhooks oder Zeitpläne) und MQTT als lokale Schicht, die die Lampen auch ohne Internet steuert. Dadurch bleiben Sprachbefehle und Automationen funktionsfähig, selbst wenn die Cloud temporär nicht erreichbar ist.
Was du brauchst
Bevor du loslegst, bereite ich diese Komponenten vor:
Ein lokaler MQTT‑Broker (z. B. Mosquitto) auf einem Raspberry Pi, NAS oder Home‑Server.Smart‑Lampen oder Zwischenstecker, die MQTT unterstützen oder über eine Bridge angebunden werden können (z. B. deCONZ, Zigbee2MQTT, Tasmota‑flashed Sonoff-Geräte).Ein Gerät/Service für IFTTT‑Trigger (Smartphone, Google Assistant, Webhooks in IFTTT).Optional: Home‑Assistant als lokales Smart‑Home‑Hub (vereinfacht Integration und Automatisierung).Architektur in Kurzform
So sieht mein Setup konzeptionell aus:
IFTTT empfängt Trigger aus der Cloud (z. B. Sprachbefehl).IFTTT schickt einen Webhook an einen lokalen Endpunkt oder an einen Dienst, der den MQTT‑Broker anspricht.MQTT‑Broker verteilt die Nachricht an die Geräte (Lampenthemen).Die Lampen reagieren lokal ohne weitere Cloud‑Abhängigkeit.Schritt für Schritt: MQTT‑Broker aufsetzen
Ich installiere Mosquitto auf einem Raspberry Pi:
Raspbian updaten: apt update && apt upgradeMosquitto installieren: apt install mosquitto mosquitto-clientsBroker sichern: In /etc/mosquitto/mosquitto.conf ein Passwortfile einrichten und SSL/TLS, falls gewünscht.Wichtig: Standardmäßig lauscht Mosquitto auf Port 1883 (unverschlüsselt). Wenn dein Netzwerk sicher ist, reicht das oft; sonst TLS auf Port 8883 aktivieren.
Geräte anbinden: Beispiele
1) Tasmota‑Geräte
Ich flash Tasmota auf Sonoff‑Module, konfiguriere das WLAN und setze MQTT‑Daten (Broker‑IP, Topic).Beispiel‑Topic: home/lights/wohnzimmer/set und Status‑Topic home/lights/wohnzimmer/state.2) Zigbee‑Geräte via Zigbee2MQTT oder deCONZ
Zigbee‑Stick (z. B. CC2531, ConBee) an den Pi oder Host anschließen.Zigbee2MQTT verbindet Zigbee‑Geräte mit dem MQTT‑Broker; jedes Gerät erhält Topics zum Steuern und Status.IFTTT so nutzen, dass es lokal wirkt
Standard‑IFTTT‑Applet: Trigger → Webhooks → Cloud. Das reicht, aber bei Ausfall der Internetverbindung hilft das nicht. Deshalb verwende ich zwei Ansätze:
IFTTT Webhooks → lokaler Webhook‑Empfänger: Ich betreibe einen kleinen Webserver (z. B. Node‑RED, Flask oder ein kleines Express‑App) im LAN, der auf Anfragen von IFTTT reagiert und den MQTT‑Broker anspricht. In IFTTT konfiguriere ich Webhooks als Aktion und verweise auf meine öffentliche IP oder DynDNS‑Adresse mit Port‑Forwarding zum lokalen Webhook. Nach Empfang translated mein Webhook die Anfrage in einen MQTT‑Publish.IFTTT → Cloud Functions / Webhooks → MQTT Bridge: Wenn du kein Port‑Forwarding magst, setze ich eine kleine Cloud‑Bridge (z. B. ein günstiges VPS oder eine Function as a Service), die Webhooks von IFTTT annimmt und dann per MQTT über einen verschlüsselten Tunnel (TLS oder VPN) den lokalen Broker erreicht.Beispiel: Node‑RED als Mittler
Node‑RED ist mein Favorit: visuell, leicht zu konfigurieren und hat MQTT‑Nodes.
Installiere Node‑RED auf dem gleichen Rechner wie Mosquitto.Erstelle einen HTTP‑in Node, der Webhook‑Anfragen von IFTTT annimmt.Füge einen Function‑Node hinzu, um Nutzdaten in ein MQTT‑Payload zu übersetzen (z. B. {"state":"ON"}).Verbinde einen MQTT‑out Node mit Topic home/lights/wohnzimmer/set.In IFTTT legst du ein Applet mit Aktion „Make a web request“ an, Ziel = https://deine‑öffentliche‑adresse/webhook/lampe, Methode POST, Body tokenisiert oder als JSON.
Sicherheitsaspekte
Lokale Infrastruktur bedeutet Verantwortung. Diese Punkte beachte ich immer:
MQTT mit Benutzername/Passwort schützen (mosquitto_passwd).TLS nutzen, wenn Broker über das Internet erreichbar ist.API‑Keys und Webhook‑URLs niemals öffentlich posten.Port‑Forwarding nur mit Firewall‑Regeln und ggf. VPN.Praktische Automationen und Tipps
Ein paar meiner Lieblingsszenarien:
Geofencing: IFTTT erkennt, wenn ich heimkomme, sendet Webhook → Node‑RED → MQTT → Lampe an.Sprachsteuerung hybrid: Google Assistant über IFTTT; bei Ausfall benutze ich Home‑Assistant lokal als Fallback.Fallback‑Logic: Status‑Topics abonnieren und lokale Automationen in Node‑RED so gestalten, dass sie unabhängig von IFTTT Timer/Trigger nutzen.Typische Probleme und ihre Lösungen
| Problem | Lösung |
| IFTTT erreicht Webhook nicht | Prüfe öffentliche Erreichbarkeit, Port‑Forwarding und SSL‑Zertifikat; Logs in Node‑RED ansehen. |
| MQTT‑Nachrichten kommen nicht an | Broker‑Logs prüfen, Verbindungsdaten in Geräten kontrollieren, QoS und Retained Flags beachten. |
| Geräte verlieren Zigbee‑Verbindung | Signalstärke prüfen, Repeater (z. B. Zigbee‑Steckdosen) einbauen, Firmware‑Updates. |
Wenn du magst, kann ich dir ein konkretes Node‑RED‑Flow‑Beispiel oder eine Schritt‑für‑Schritt‑Anleitung für Mosquitto/Node‑RED/IFTTT mit den genauen JSON‑Payloads und IFTTT‑Einstellungen schreiben. Sag mir kurz, welche Lampen/Bridges du nutzt (z. B. Philips Hue, IKEA TRÅDFRI, Sonoff Tasmota) — dann passe ich die Anleitung auf dein Setup an.
