OpenClaw und Home Assistant: Assist-Anbindung und Gerätezugriff trennen

OpenClaw und Home Assistant lassen sich in zwei Richtungen verbinden. Das Projekt ddrayne/openclaw-homeassistant reicht Anfragen aus Home Assistants Assist-Oberfläche an einen OpenClaw-Agenten weiter. Ein separater Home-Assistant-Skill gibt OpenClaw dagegen Werkzeuge zum Lesen und Steuern von Geräten.

Diese Trennung zählt. Eine Sprachfrage an OpenClaw und eine Aktion am Türschloss sind technisch wie betrieblich zwei verschiedene Vorgänge.

Weg eins: OpenClaw als Conversation Agent

Die GitHub-Dokumentation führt die Anbindung als Custom Integration für Home Assistant. Installiert wird sie über HACS oder manuell unter custom_components/openclaw; anschließend lässt sie sich unter „Devices & Services“ einrichten und in Home Assistants Voice-Konfiguration als Conversation Agent auswählen.

Home Assistant braucht dafür eine Verbindung zu einem laufenden OpenClaw-Gateway. In der Integration werden Zieladresse, Gateway-Token und Timeout konfiguriert. Der Token ist ein Zugriffsschlüssel. Er gehört weder in Screenshots noch in Support-Threads.

Laufen beide Systeme auf verschiedenen Maschinen, muss Home Assistant das Gateway erreichen können. Offen im Internet sollte es deshalb noch lange nicht stehen. Für entfernte Verbindungen kommen eine abgesicherte TLS-Verbindung oder ein SSH-Tunnel infrage; zusätzlich braucht das Setup eine enge Netzfreigabe und eine explizite Gerätefreigabe.

Ob das Drittprojekt mit der konkret installierten OpenClaw- und Home-Assistant-Version zusammenspielt, muss ein lokaler Test zeigen. Die vorhandenen Belege liefern keine pauschale Kompatibilitätszusage für jede Stable- oder Beta-Version.

Wenn Assist stumm bleibt

Die Diagnose beginnt am Gateway. Bleibt Assist hängen, muss zuerst feststehen, ob Home Assistant die konfigurierte Adresse erreicht und der Token akzeptiert wird. Erst danach lohnt sich die Suche im Agentenlauf.

Drei Fehlerbilder decken den sinnvollen Einstieg ab:

• Keine Verbindung: Gateway-Status und Zieladresse prüfen, danach Firewall und Transportweg.
• „invalid token“: Tokenkonfiguration kontrollieren; bei möglicher Offenlegung den Schlüssel ersetzen.
• Erneutes Pairing: Gerät in OpenClaw wieder freigeben und die Integration neu laden.

Bei Abbrüchen zählt das konfigurierte Zeitfenster. Eine einfache Statusfrage sollte innerhalb des Timeouts enden; scheitert sie trotz erreichbarem Gateway und gültigem Token wiederholt, helfen die Diagnoseansicht der Integration und die Gateway-Logs bei der Eingrenzung.

Für einfache Anfragen nennt das Projekt mehrere Sekunden, komplexe Agentenläufe können deutlich länger dauern. Das ist kein allgemeiner Leistungswert, denn die tatsächliche Dauer hängt vom gewählten Modell und den ausgelösten Werkzeugen ebenso ab wie von Netzwerk und Timeout.

Für tieferes Debugging ist der Logger custom_components.openclaw vorgesehen. Vor dem Teilen der Ausgabe müssen Token und persönliche Smart-Home-Daten entfernt werden.

Weg zwei: Geräte über einen Skill bedienen

Playbooks listet für den separaten Home-Assistant-Skill 34 Werkzeuge rund um Zustände und Services. Diese Zahl gehört zum Skill. Sie beschreibt nicht automatisch die Conversation-Integration aus dem GitHub-Repository.

Der Unterschied wird an einer Abendroutine sichtbar: Der Agent prüft, ob im Wohnzimmer noch Licht brennt und ein Fenster offen ist, bevor er eine freigegebene Szene auslöst. Dafür benötigt er lesenden Zugriff auf Zustände und eine eng begrenzte Schreibberechtigung für die Aktion.

Eine Sensorabfrage ist eine niedrige Risikoklasse. Das Entriegeln einer Tür oder Ändern eines Heizplans hat unmittelbare physische Folgen. Ein Pilot sollte daher mit Zustandsabfragen und wenigen reversiblen Aktionen beginnen, etwa Licht oder Medienpause.

Der Skill sieht dafür readOnly und Schutzregeln auf Domain-Ebene vor. Ob diese Grenzen wirklich greifen, zeigt nur ein Versuch mit einer absichtlich gesperrten Aktion. Ein Schalter in der Konfiguration reicht als Sicherheitsnachweis nicht aus.

Voice-Zugriff ist keine Channel-Kopie

Die Assist-Oberfläche erbt nicht automatisch sämtliche Fähigkeiten, die ein OpenClaw-Agent in Telegram, Discord oder WhatsApp besitzt. Erreichbare Werkzeuge hängen von der Konfiguration des Agenten und den Regeln der jeweiligen Session ab.

Vor der Freigabe muss deshalb sichtbar sein, welche Aktion eine harmlose Kalenderfrage überhaupt auslösen könnte. Für den Voice-Pfad empfiehlt sich ein kleiner Werkzeugsatz; jede schreibende Smart-Home-Fähigkeit braucht eine bewusste Freigabe.

Ein belastbarer Test beantwortet drei Fragen: Liefert eine erlaubte Statusabfrage den richtigen Zustand? Wird eine gesperrte Domain nachvollziehbar abgewiesen? Stoppt eine mehrdeutige Anweisung oder verlangt sie eine Bestätigung?

Fehlt eine dieser Grenzen, bleibt der Agent im Lesemodus.

Fazit: Erst lesen, dann handeln

Meine Einschätzung: Die Verbindung ist für bestehende Home-Assistant-Installationen interessant, aber als universelle Sprachfernbedienung zu riskant. Ihr sinnvoller Einstiegspunkt ist ein begrenzter Voice-Pfad für Statusfragen, ergänzt um wenige reversible Geräteaktionen.

Ein produktives Smart Home mit realen Geräten ist hier nicht getestet. Offen bleiben damit Langzeitstabilität und das Verhalten bei sensiblen Domains oder echten Ausfällen.

Für den Betrieb gilt eine harte Reihenfolge: Gateway abschirmen und Token schützen. Danach Pairing und Leserechte prüfen. Schreibaktionen kommen erst hinzu, wenn Ablehnung, Bestätigung und Recovery unter realen Bedingungen funktionieren. Türschlösser, Alarmanlagen und Garagentore bleiben bis dahin außen vor.