OpenClaw Home Assistant sicher einrichten: Gateway, Token und Smart-Home-Grenzen

Ein Smart Home wird für Agenten erst interessant, wenn sie nicht nur Antworten geben, sondern Zustände lesen und begrenzte Aktionen ausführen können. OpenClaw Home Assistant setzt an dieser Schwelle an: Das GitHub-Projekt ddrayne/openclaw-homeassistant bindet OpenClaw als Conversation Agent in Home Assistant ein, die Playbooks-Seite beschreibt zusätzlich einen Skill zur Steuerung von Home-Assistant-Geräten aus dem Chat.

Der praktische Nutzen ist einfach: Wer Home Assistant ohnehin als Smart-Home-Zentrale nutzt, kann OpenClaw als zusätzliche Gesprächs- und Agentenschicht davor setzen. Statt nur „Licht an“ zu sagen, kann man denselben Agenten fragen, was im Kalender steht, ob wichtige Nachrichten da sind, welche Geräte aktiv sind oder welche Szene zu einer Situation passt. Die Integration ist damit weniger Ersatz für Home Assistant als eine Brücke zwischen Agenten-Workflow und Haussteuerung.

Wo du anfängst

Der Einstieg läuft über das öffentliche Repository ddrayne/openclaw-homeassistant. Die empfohlene Installation erfolgt über HACS: In Home Assistant wird das Repository als Custom Repository vom Typ „Integration“ hinzugefügt, danach sucht man nach „OpenClaw Voice Assistant“, lädt die Integration herunter und startet Home Assistant neu. Alternativ kann der Ordner custom_components/openclaw manuell in die Home-Assistant-Installation kopiert werden.

Die Integration braucht Home Assistant 2024.1.0 oder neuer und ein laufendes OpenClaw mit aktivem Gateway. Der Gateway-Token ist seit OpenClaw 2026.2.13 Pflicht; erzeugt wird er über die Gateway-CLI. Wenn Home Assistant nicht auf derselben Maschine läuft, muss das Gateway im lokalen Netz erreichbar sein. Für entfernte Setups gehört TLS oder ein SSH-Tunnel dazu, weil der Token Zugriff auf den Agenten eröffnet.

Nach der Installation wird die Integration in Home Assistant unter „Devices & Services“ hinzugefügt. Dort trägt man Host, Port, Gateway-Token, Agent-Timeout und bei Bedarf SSL ein. Anschließend wählt man in Home Assistants Voice-Assistant-Einstellungen OpenClaw als Conversation Agent. Ab diesem Punkt kann Home Assistant gesprochene oder getippte Assist-Anfragen an den OpenClaw-Agenten weiterreichen.

Der wichtigste Unterschied zu einer normalen Sprachintegration: Home Assistant spricht nicht nur mit einer Lampensteuerung, sondern mit dem konfigurierten OpenClaw-Agenten. Wenn dieser Agent Mail, Kalender, Dateien, Browser oder eigene Skills bedienen darf, hängen diese Fähigkeiten grundsätzlich auch am Voice-Pfad. Genau deshalb ist das Setup weniger eine Komfortfrage als eine Berechtigungsfrage.

Diagnose: wenn Assist nicht antwortet

Eine häufige Fehlerklasse ist schlicht Verbindung. Dafür zählen vier Checks: Gateway läuft, Host und Port stimmen, Firewall blockiert nicht, und bei Remote-Verbindungen passt SSL. Praktisch heißt das: Wenn Assist hängen bleibt oder Home Assistant keine Verbindung bekommt, prüfst du zuerst den Gateway-Status, dann die eingetragene Zieladresse und erst danach den Agenten selbst.

Die zweite Fehlerklasse ist Authentifizierung. Bei „invalid token“ ist der Gateway-Token zu prüfen oder neu zu erzeugen. Wichtig: Der Token ist kein harmloser Schalter. Er authentifiziert Home Assistant am Gateway und sollte wie ein Zugriffsschlüssel behandelt werden. Wer ihn in Screenshots, Logs oder gemeinsam genutzten Notizen ablegt, macht aus einem Smart-Home-Problem schnell ein Agenten-Sicherheitsproblem.

Die dritte Fehlerklasse ist Pairing. Remote-Geräte können beim ersten Verbindungsaufbau eine Gerätefreigabe verlangen. Das Projekt beschreibt dafür eine einmalige Approval-Stufe: Gerät in OpenClaw freigeben, danach die Home-Assistant-Konfiguration fortsetzen. Wenn ein früher freigegebenes Gerät nach einem Reset oder Datenverlust wieder als Reparaturfall auftaucht, ist kein neues Setup nötig, sondern eine erneute Freigabe plus Reload der Integration.

Die vierte Fehlerklasse ist Laufzeit. Typische Antworten liegen bei 5 bis 10 Sekunden, komplexere Agentenaufgaben können 15 bis 30 Sekunden oder länger brauchen. Wenn Home Assistant also „zu langsam“ wirkt, ist nicht automatisch die Integration defekt. Der bessere Test ist Expected vs. Actual:

• Expected: einfache Status- oder Kalenderfragen antworten innerhalb des konfigurierten Timeouts.
• Actual: Assist bricht wiederholt ab, obwohl das Gateway erreichbar ist und der Token stimmt.
• Nächster Check: Timeout der Integration erhöhen, Gateway-Logs prüfen und lange Agentenaktionen von einfachen Sprachfragen trennen.

Home Assistant bietet zusätzlich eine Diagnoseansicht für die Integration. Sie enthält Verbindungsstatus, Health-Informationen und redigierte Konfiguration. Für tieferes Debugging kann der Logger custom_components.openclaw aktiviert werden. Mehr sollte man nicht öffentlich posten: Tokens, interne Hostnamen und persönliche Geräte- oder Raumdaten gehören nicht in Support-Threads.

Vom Chat zur Geräteebene

Nach Angaben von Playbooks ist OpenClaw Home Assistant als Plugin für die Home-Assistant-Integration gedacht. Die Kurzbeschreibung läuft darauf hinaus, Smart-Home-Geräte direkt aus dem Chat zu kontrollieren. Das klingt unspektakulär, markiert für Agenten aber eine wichtige Grenze: Ohne Zugriff auf Zustände und Services bleibt ein Assistent ein sprechendes Dashboard. Mit sauber begrenzten Tools kann er Licht, Temperatur, Medien und Szenen in denselben Arbeitsfluss einbauen, in dem Nutzer ohnehin Fragen stellen oder Aufgaben formulieren.

Die Playbooks-Seite nennt 34 Tools und beschreibt mehrere Funktionsbereiche. Dazu gehören Statusabfragen, Entitätslisten, einzelne Zustände, Entitätssuche und verfügbare Services nach Domain. Für Lichter listet Playbooks Aktionen wie Einschalten, Ausschalten, Umschalten und eine Lichtliste mit aktuellem Zustand. Bei Klima-Geräten geht es laut derselben Quelle um Temperatur, HVAC-Modus, Presets und eine Übersicht aller Klima-Entitäten.

Wichtig ist dabei nicht nur die Aktionsseite, sondern auch das Lesen von Zuständen. Ein Agent, der den Zustand eines Raums nicht kennt, muss raten oder zurückfragen. Mit Entitätssuche und Zustandsabfrage kann er erst prüfen, ob das Küchenlicht an ist, welche Temperatur ein Thermostat meldet oder ob ein Mediengerät läuft. Erst danach ergibt eine Aktion Sinn.

Was du damit konkret machst

Der wichtigste Punkt: Über Home Assistant kommt nicht nur eine weitere Sprachsteuerung hinzu, sondern der komplette konfigurierte OpenClaw-Agent. Was OpenClaw in Telegram, Discord oder WhatsApp kann, kann dann grundsätzlich auch über Home Assistants Assist-Oberfläche erreichbar werden. Das umfasst je nach Setup E-Mail, Kalender, Dateien, Web-Recherche, eigene Skills und angebundene Dienste.

Sinnvolle Einstiegs-Use-Cases sind deshalb nicht die riskantesten, sondern die nützlichsten Alltagsfälle:

• „Was steht heute im Kalender, bevor ich das Haus verlasse?“
• „Gibt es wichtige Nachrichten, während ich in der Küche bin?“
• „Fasse mir den neuesten Artikel zu einem Thema zusammen.“
• „Welche Geräte sind im Wohnzimmer noch aktiv?“
• „Starte die Abendroutine, aber prüfe vorher, ob noch ein Fenster offen ist.“

Playbooks beschreibt den Skill zusätzlich nicht als Spezialwerkzeug für eine einzelne Gerätegruppe, sondern als breitere Home-Assistant-Schicht. Neben Lichtern und Klima nennt die Quelle Medienplayer, Covers, Szenen, Sensoren und Automationen. Für Mediengeräte werden Abspielen, Pause, Stop, Lautstärke und das Abspielen bestimmter Medien genannt. Für Schalter gibt es Ein-, Aus- und Toggle-Aktionen.

Diese Breite ist der praktische Kern. Viele Smart-Home-Abläufe laufen quer über Domains: Ein Abendmodus kann Licht, Heizung, Rollos und Mediengerät gleichzeitig betreffen. Wenn ein Agent diese Bereiche über ein konsistentes Werkzeugset erreicht, kann er komplexere Absichten in mehrere kleine, nachvollziehbare Aktionen zerlegen.

Für OpenClaw ist der Skill auch deshalb interessant, weil er agentische Produktlogik sichtbar macht. Der Agent bekommt keine unbegrenzte Kontrolle über das Haus, sondern eine Werkzeugoberfläche mit benannten Fähigkeiten. Der Nutzer formuliert eine Absicht, der Agent wählt passende Tools, und die Integration übersetzt das in Home-Assistant-Aktionen.

Sicherheit entsteht an den Werkzeuggrenzen

Die Playbooks-Beschreibung nennt ausdrücklich „readOnly“ und „domain-level safety guards“. Bei Smart-Home-Agenten ist das kein Nebensatz, sondern ein Architekturpunkt. Wer einem Agenten Zugriff auf Lampen gibt, will nicht automatisch denselben Freiraum für Türen, Alarme, Heizpläne oder Medienwiedergabe in jedem Raum. Domain-Grenzen sind deshalb eine naheliegende Stelle, an der Betreiber festlegen, welche Gerätetypen agentisch bedient werden dürfen.

Auch die Trennung zwischen lesenden und schreibenden Fähigkeiten zählt. Statusabfragen sind deutlich weniger riskant als Aktionen. Ein Agent darf oft problemlos feststellen, welche Lichter aktiv sind oder welche Sensoren einen Zustand melden. Einschalten, Ausschalten oder das Verändern von Temperatur und Medienwiedergabe sind eine andere Klasse. Gute Smart-Home-Agenten brauchen deshalb nicht nur Tools, sondern ein bewusstes Berechtigungsmodell rund um diese Tools.

Für einen sicheren Start reicht eine kleine Freigabematrix:

• Lesen zuerst: Entitäten suchen, Zustände prüfen, Sensorwerte zusammenfassen.
• Niedriges Risiko: Licht, Medienpause, einfache Szenen ohne Sicherheitsfolge.
• Mittleres Risiko: Klima, Lautstärke, Rollos, Szenen mit mehreren Domains.
• Hoher Ausschluss zu Beginn: Türschlösser, Alarmanlagen, Garagentore, Heizpläne, alles mit physischem Schadenpotenzial.

Remote-Zugriff braucht eine eigene Grenze. Bei direkter Verbindung gehört SSL dazu, alternativ bietet sich ein SSH-Tunnel an. Für Agentenbetrieb ist das die richtige Reihenfolge: lieber Gateway nicht offen ins Netz stellen, Token geheim halten, Gerät explizit freigeben und später über zusätzliche Domains nachdenken. Wer ohnehin mit entfernten Agenten arbeitet, sollte OpenClaw Home Assistant zusammen mit den Grundregeln aus dem Artikel zu Remote Nodes und Tailscale lesen.

Die Quellenlage bleibt dabei schmal. Belastbar sind vor allem die Playbooks-Listung und die Projektbeschreibung auf GitHub; eine Reddit-Spur verweist zwar auf eine HACS-Integration mit OpenClaw als Voice Provider, war beim Abruf aber nicht direkt zugänglich. Deshalb sollte man die Integration als vorhandenes Projekt lesen, nicht als Beleg für breite Nutzung, belastbare Nutzerzahlen oder Community-Erfolg.

Für wen das nützlich ist

OpenClaw Home Assistant passt vor allem zu Setups, in denen Home Assistant bereits die zentrale Smart-Home-Schicht ist. Dann muss der Agent nicht jedes Gerät einzeln kennen, sondern spricht mit einer vorhandenen Steuerzentrale. Für Bastler und Agenten-Builder ist das attraktiv, weil Home Assistant die Gerätewelt bündelt und OpenClaw die Dialog- und Tool-Schicht liefern kann.

Der Nutzen liegt weniger in der einzelnen Sprachaktion „Licht an“. Das können viele Systeme. Relevanter ist die Kombination aus Kontext, Zustand und mehrstufiger Aufgabe. Ein Agent kann erst prüfen, welche Geräte verfügbar sind, dann eine passende Aktion wählen und danach wieder den Zustand kontrollieren. Wenn diese Schleife verlässlich funktioniert, wird aus Sprachsteuerung eine kleine operative Schicht für das Zuhause.

Meine Empfehlung wäre: nicht mit Türschlössern, Alarmen oder Heizplänen starten. Besser sind lesende Abfragen, Kalender- und Nachrichtenfragen, Licht- und Medienaktionen sowie klar begrenzte Szenen. Erst wenn Gateway, Token, Gerätefreigaben und Antwortzeiten stabil laufen, lohnt es sich, mehr Domains freizuschalten.

Die Grenze bleibt klar: Smart-Home-Agenten sollten nicht als unbeaufsichtigte Universalbedienung starten. Besonders sensible Domains brauchen explizite Freigaben, robuste Defaults und idealerweise Bestätigungsschritte. OpenClaw Home Assistant zeigt, wie der Werkzeugansatz dafür aussehen kann. Ob daraus ein belastbarer Alltagsassistent wird, entscheidet sich weniger an der Anzahl der Tools als daran, wie sauber Betreiber ihre Geräte, Rechte und Risiken schneiden.

Reality Check

• Getestet ist hier die Quellenlage, nicht ein produktives Smart-Home-Deployment mit realen Geräten.
• Belegt sind HACS-Installation, manuelle Installation, Gateway-Token, Remote-Setup, Device Approval, Diagnoseansicht, Loggername und die vom Projekt genannten Timeout- und Reconnect-Hinweise.
• Nicht belegt sind reale Ausfallraten, breite Community-Nutzung, Langzeitstabilität und das Verhalten mit besonders sensiblen Domains wie Schlössern oder Alarmen.
• Für den Betrieb zählt die gleiche Grundregel wie bei OpenClaw-Security-Audits: erst Berechtigungen begrenzen, dann Komfort erhöhen.

Kurze Antworten

Warum antwortet OpenClaw in Home Assistant nicht?
Meist liegt es an Gateway-Erreichbarkeit, falschem Host oder Port, einem ungültigen Gateway-Token, fehlender Gerätefreigabe oder einem zu knappen Agent-Timeout.

Muss das Gateway öffentlich erreichbar sein?
Nein. Für Remote-Setups beschreibt das Projekt direkte Verbindung mit SSL oder einen SSH-Tunnel. Ein offen erreichbares Gateway ohne saubere Authentifizierung und Transportabsicherung ist für Smart-Home-Agenten keine gute Startbasis.

Welche Domains sollte ich zuerst freigeben?
Lesende Zustände, Licht, Medien und einfache Szenen. Kritische Domains wie Schlösser, Alarme, Garagentore oder Heizpläne gehören erst in ein Setup, wenn Token, Pairing, Logs, Timeouts und Bestätigungsschritte verstanden sind.