KI Agent für Home Assistant: OpenClaw, MCP und die nächste Stufe der Smart-Home-Automation

Ein Freitagabend, eine Automation und ein kleiner Schwindel

Es ist kurz nach zehn, die Kinder schlafen, der Abwasch steht noch, und Miriam hat eigentlich keine Lust mehr auf Technik. Trotzdem sitzt sie mit dem Laptop auf dem Sofa, weil sie sich seit Wochen über eine Kleinigkeit ärgert: Wenn sie nachts in den Flur geht, springt das Licht auf volle Helligkeit an und blendet sie wach. Sie will eine Automation, die das Licht nachts nur gedimmt einschaltet. Also tippt sie ihr Anliegen in ein KI-Chatfenster, so wie sie es schon oft getan hat.

Was zurückkommt, sieht beeindruckend aus. Sauber eingerückter Code, Kommentare, eine plausible Struktur. Miriam kopiert alles in ihr Smart-Home-System, speichert – und nichts passiert. Der Bewegungsmelder, den die KI angesprochen hat, existiert bei ihr gar nicht. Die Lampe, die sie steuern soll, kann die vorgeschlagene Helligkeitsstufe nicht. Die KI hatte keine Ahnung, wie Miriams Zuhause tatsächlich aussieht. Sie hat es sich zusammengereimt. Höflich, selbstbewusst – und falsch.

Diesen Moment kennt fast jeder, der schon einmal versucht hat, eine KI beim Smart Home helfen zu lassen. Das Ergebnis sieht richtig aus und funktioniert trotzdem nicht. Der Grund dafür ist kein böser Wille und oft nicht einmal ein schlechtes KI-Modell. Der Grund ist viel simpler: Die KI kennt dein Zuhause nicht. Sie rät.

Genau an dieser Stelle beginnt eine der spannendsten Entwicklungen im smarten Zuhause der letzten Monate. Denn es gibt inzwischen einen Weg, wie eine KI aufhört zu raten und anfängt, dein System wirklich zu befragen. Dieser Weg heißt MCP – und wenn man ihn mit einem autonomen KI-Agenten kombiniert, entsteht etwas, das noch vor Kurzem nach Science-Fiction klang: ein digitaler Mitbewohner, der Zugriff auf dein Smart Home hat, Automationen baut und im Zweifel sogar nachts Wache hält.

Dieser Artikel nimmt dich mit auf diese Reise. Von Miriams gescheiterter Automation bis zu einem KI-Wächter, der dir per Chat meldet, wenn mit deinem Zuhause etwas nicht stimmt. Und weil echte Macht immer eine Kehrseite hat, reden wir am Ende auch offen über die Risiken – ohne Alarmismus, aber auch ohne die unbequemen Wahrheiten wegzulassen.

Eines vorweg, damit die Erwartungen stimmen: Dies ist keine Klick-für-Klick-Anleitung, sondern eine Architektur- und Sicherheitsentscheidungshilfe für Home-Assistant-Nutzer, die KI-Agenten ernsthaft einsetzen wollen. Du bekommst hier das Verständnis, um die richtigen Weichen zu stellen – welche Bausteine es gibt, wie sie zusammenspielen und wo die Fallstricke liegen. Die exakten Klicks und Befehle ändern sich in diesem Feld ohnehin so schnell, dass eine Schritt-für-Schritt-Anleitung schon beim Erscheinen veraltet wäre.

Warum das jetzt relevant ist

Home Assistant – die Open-Source-Zentrale, mit der viele Menschen ihr Smart Home selbst in die Hand nehmen, statt sich auf Google, Amazon oder Apple zu verlassen – ist mächtig. Genau deshalb ist es aber auch kompliziert. Wer eine gute Automation schreiben will, braucht Wissen über Entitäten, Geräte, Trigger und eine Konfigurationssprache namens YAML (ein textbasiertes Format, in dem Home Assistant Einstellungen speichert – einrückungssensibel und gnadenlos bei Tippfehlern). Bisher war klar: Home Assistant ist die Plattform, aber du bist das Gehirn dahinter. Ob du willst oder nicht.

Die Idee, KI dabei helfen zu lassen, liegt auf der Hand. Und viele tun es längst. Nur eben auf einer Stufe, die noch nicht besonders gut funktioniert. Was die meisten nicht wissen: Es gibt inzwischen deutlich bessere Stufen. Man muss sie nur kennen. Sehen wir uns also an, wie sich die Zusammenarbeit zwischen Mensch, KI und Smart Home Schritt für Schritt weiterentwickelt hat – von „die KI rät“ bis „die KI baut“.

Die vier Stufen: vom Raten zum Verstehen

Stufe 1 – Einfaches Prompten

Das ist Miriams Ausgangspunkt und der Alltag der meisten Menschen: Man beschreibt der KI, was man will, und bekommt Code zurück. Das Problem haben wir schon gesehen. Ohne Kenntnis deines Systems erfindet die KI Entity-IDs (die eindeutigen technischen Namen deiner Geräte, etwa light.flur_decke), Räume, Dienste oder nutzt veraltete Syntax. Es kann sogar sein, dass ein besonders „nachdenklicher“ KI-Modus eine simple Aufgabe überkompliziert und in eine völlig falsche Richtung abbiegt – in einem dokumentierten Test hielt die KI eine Home-Assistant-Anfrage kurzerhand für eine Google-Smart-Home-Routine.

Für erste Ideen ist das okay. Für dein konkretes Zuhause ist es unzuverlässig.

Stufe 2 – Der KI Kontext geben

Die naheliegende Verbesserung: Man füttert die KI mit Informationen. Man kopiert die echten Entity-IDs hinein, schickt Screenshots, exportiert Verlaufsdaten als Tabelle, fügt Ausschnitte bestehender Automationen ein. Jetzt muss die KI weniger raten und liefert deutlich bessere Ergebnisse.

Der Haken: Es bleibt Handarbeit. Man kopiert Daten hin und her, entscheidet selbst, was relevant sein könnte, und übersieht dabei leicht wichtige Zusammenhänge. Man ist quasi der Übersetzer zwischen seinem Haus und der KI – und Übersetzer machen Fehler.

Stufe 3 – Skills: der KI Fachwissen beibringen

Jetzt wird es interessant. Ein Skill ist ein strukturiertes Wissenspaket, das einer KI beibringt, wie sie in einem bestimmten Fachgebiet arbeiten soll. Man kann sich das vorstellen wie einen Spickzettel voller Best Practices, den die KI liest, bevor sie loslegt.

Für Home Assistant gibt es genau so etwas: ein Paket namens Home Assistant Agent Skills, das der KI die guten Gewohnheiten beibringt. Keine unnötig komplizierten Vorlagen, wenn es auch einfach geht. Den richtigen Automation-Modus wählen. Nicht vorschnell in Konfigurationsdateien herumschreiben, wenn sich etwas bequemer über die Oberfläche lösen lässt. In den Tests, aus denen dieser Artikel schöpft, war der Unterschied verblüffend: Dieselbe Anfrage, dieselbe KI – aber mit geladenem Skill berücksichtigte sie plötzlich, das Licht nach einer Weile auch wieder auszuschalten, und lieferte sogar eine Begründung, warum der Modus „Restart“ passt. Ohne Skill ließen andere KIs genau das schlicht weg.

Der Grund ist wichtig zu verstehen: Eine KI ist nicht speziell auf Home Assistant trainiert. Sie rät aus ihren allgemeinen Trainingsdaten, wann welcher Trigger sinnvoll ist. Ein Skill nimmt ihr dieses Raten ab und sagt ihr klipp und klar: In dieser Situation macht man das so.

Stufe 4 – MCP: die KI darf endlich selbst nachsehen

Und hier kommt der eigentliche Sprung. Bisher hat die KI entweder geraten (Stufe 1), sich von uns füttern lassen (Stufe 2) oder Fachwissen mitbekommen (Stufe 3). Aber sie konnte nie selbst in dein System schauen. MCP ändert das.

MCP steht für Model Context Protocol – ein offener Standard, der festlegt, wie eine KI mit externen Werkzeugen und Datenquellen sprechen kann. Ein sperriger Name für eine elegante Idee. Der Smart-Home-YouTuber simon42, dessen Videos einen guten Teil der Grundlage für diesen Artikel bilden, nennt es bildhaft einen „USB-C-Anschluss für KI-Tools“. Und das trifft es ziemlich genau: So wie USB-C ein einheitlicher Stecker für viele Geräte ist, ist MCP eine einheitliche Schnittstelle, über die eine KI viele verschiedene Systeme ansprechen kann.

Wie funktioniert das? Zwischen die KI und Home Assistant setzt man einen MCP-Server (ein kleines Vermittlungsprogramm). Dieser Server stellt der KI fertige Werkzeuge bereit – „Entität suchen“, „Zustand abfragen“, „Automation erstellen“, „Dashboard lesen“ – jeweils in natürlicher Sprache beschrieben, sodass die KI sofort versteht, was sie damit tun kann. Auf der anderen Seite spricht der Server die technische Sprache von Home Assistant, die API (Application Programming Interface – die programmierbare Schnittstelle eines Systems). Die KI muss diese komplizierte Schnittstelle also gar nicht auswendig können. Sie sagt dem MCP-Server „such mir den Bewegungsmelder im Flur“, und der Server erledigt die Übersetzung.

Das Ergebnis: Die KI rät nicht mehr. Sie fragt nach. Sie findet die echten Geräte, die echten Personen im Haushalt, die bereits existierenden Automationen – und kann darauf aufbauen, statt etwas Generisches zu erfinden.

Kurz innehalten – wohin fließen eigentlich deine Daten?
Genau an dieser Stelle lohnt ein ehrlicher Blick, gerade weil viele Menschen Home Assistant wegen des Datenschutzes nutzen. Wenn du eine Cloud-KI wie Claude, ChatGPT oder Gemini als Gehirn einsetzt, können über MCP Entity-Namen, Gerätezustände, Protokolle, Personen, Räume, Anwesenheitsinformationen und Fehlermeldungen an diesen Anbieter übermittelt werden. Das ist der Preis für die hohe Qualität dieser Modelle. Wer das nicht möchte, hat zwei Hebel: entweder lokale Modelle (die auf eigener Hardware laufen, etwa über Ollama oder LM Studio – langsamer und meist weniger fähig, aber datensparsam) oder einen stark begrenzten MCP-Zugriff, bei dem die KI nur das Nötigste zu sehen bekommt. Diese Grundsatzentscheidung sollte man treffen, bevor man loslegt, nicht danach.

Ein Server, drei Varianten – und ein wichtiger Unterschied

Bevor wir irgendetwas installieren, müssen wir eine Verwirrung auflösen, an der viele scheitern. Im Home-Assistant-Universum gibt es nämlich drei verschiedene MCP-Bausteine, die leicht durcheinandergehen.

Erstens die offizielle Integration namens „MCP Server“. Sie macht Home Assistant zum Server, an den sich eine externe KI anhängen kann. Der Haken: Sie zeigt der KI nur die Geräte, die man ausdrücklich für den Sprachassistenten freigegeben hat. Das ist sicher und gut für Sprachsteuerung – aber viel zu eng, wenn die KI Automationen bauen oder Fehler suchen soll.

Zweitens eine offizielle Integration, die genau andersherum funktioniert: Sie lässt den in Home Assistant eingebauten Assistenten nach außen greifen, um dort fremde Werkzeuge zu nutzen. Für unser Vorhaben nicht relevant.

Drittens – und das ist der Star dieser Geschichte – der inoffizielle Server namens ha-mcp, dessen Entwickler ihn selbstironisch „The Unofficial and Awesome Home Assistant MCP Server“ nennen. Er ist architektonisch grundlegend anders gebaut: Statt über den engen Sprachassistenten-Kanal spricht er direkt mit dem Kern von Home Assistant. Dadurch kann er Dinge, die dem offiziellen Server schlicht fehlen – Konfiguration lesen und schreiben, Automationen erstellen und bearbeiten, Dashboards verwalten, Fehlerprotokolle analysieren, Backups anstoßen, Energie- und Verlaufsdaten abrufen. Zum Zeitpunkt der Recherche listete das Projekt knapp neunzig einzelne Werkzeuge in rund zwei Dutzend Kategorien (eine Zahl, die sich laufend ändert – wer es genau wissen will, schaut ins aktuelle Projekt-Repository).

Die Faustregel, die man sich merken sollte: Den offiziellen Server nimmt man für sichere Sprachsteuerung bereits freigegebener Geräte. Den inoffiziellen ha-mcp nimmt man, wenn man eine KI will, die das Smart Home nicht nur bedient, sondern es mitbaut und wartet. Mehr Macht, mehr Möglichkeiten – und, das sei schon hier gesagt, mehr Verantwortung.

Wer schnell die passende Variante finden will, orientiert sich an dieser Übersicht:

Ziel	Besser geeignet
Nur freigegebene Geräte per KI steuern	offizieller Home-Assistant-MCP-Server
Automationen, Dashboards, Logs, Helfer analysieren	ha-mcp
KI innerhalb von Home Assistant mit externen Tools erweitern	offizielle MCP-Client-Integration
Produktivsystem mit möglichst wenig Risiko	offizieller Server oder ha-mcp im Lesemodus
Power-User-Testsystem	ha-mcp mit Schreibwerkzeugen

Der autonome Agent: OpenClaw betritt die Bühne

MCP macht die KI schlau. Aber MCP allein sitzt noch im Chatfenster und wartet darauf, dass du etwas eintippst. Der nächste Schritt ist ein KI-Agent, der dauerhaft läuft, über deine gewohnten Chat-Apps erreichbar ist und selbstständig handelt. Der bekannteste Vertreter dieser neuen Gattung heißt OpenClaw – ein Projekt des österreichischen Entwicklers Peter Steinberger, das im November 2025 startete und innerhalb weniger Tage über hunderttausend Sterne auf der Entwicklerplattform GitHub sammelte, eines der am schnellsten wachsenden Open-Source-Projekte überhaupt.

Der Name selbst erzählt viel über das Tempo dieser jungen Branche: Erst hieß das Tool Clawdbot (ein Wortspiel auf Anthropics KI-Modell „Claude“), nach einem Trademark-Hinweis von Anthropic wurde es zu Moltbot und schließlich zu OpenClaw – drei Namen in wenigen Wochen, begleitet von Krypto-Betrügern, die kaperte Konten für Fake-Coins missbrauchten. 2026 wechselte Steinberger zu OpenAI; OpenClaw soll als Open-Source-Projekt in einer von OpenAI unterstützten Stiftung weitergeführt werden, Details wurden nicht vollständig offengelegt. Kurz: Dies ist ein Feld im Umbruch – manche Details in diesem Text können zum Zeitpunkt deiner Lektüre schon wieder anders sein.

Was OpenClaw eigentlich ist – und warum das aufregend und beunruhigend zugleich ist

Technisch ist OpenClaw ein selbst gehosteter Gateway – ein Torwächter-Programm, das auf deiner eigenen Hardware oder einem Server läuft, nicht in irgendeiner fremden Cloud. Es verbindet deine gewohnten Chat-Dienste – Telegram, WhatsApp, Signal, Discord und viele mehr – mit einem KI-Modell deiner Wahl. Du schreibst dem Bot also eine Nachricht wie einem Kontakt, und er antwortet nicht nur, sondern handelt.

Das ist der entscheidende Unterschied zu einem gewöhnlichen Chatbot. OpenClaw kann Befehle im Terminal ausführen, Software installieren, einen Browser bedienen, Dateien lesen und schreiben, E-Mails verschicken, Kalender verwalten. Es hat außerdem ein Langzeitgedächtnis, das als einfache Textdateien auf der Festplatte liegt – man kann sie in jedem Editor öffnen, mit einem Backup sichern oder löschen. Und es hat einen sogenannten Heartbeat (Herzschlag): In einem einstellbaren Rhythmus, standardmäßig alle dreißig Minuten, wacht der Agent von selbst auf, sieht in einer Checkliste nach, ob etwas zu tun ist, und handelt gegebenenfalls – ganz ohne dass du ihn anstößt.

Genau diese Fähigkeit, autonom und dauerhaft zu handeln, macht OpenClaw so mächtig. Und exakt dieselbe Fähigkeit macht es potenziell gefährlich. Merke dir dieses Spannungsverhältnis, es zieht sich durch den Rest des Artikels.

Die wichtigste Regel zuerst: nicht auf dem Hauptrechner

Bevor wir zur Installation kommen, eine Warnung, die in den Quellvideos ganz oben steht und die auch hier ganz oben stehen muss.

Installiere einen autonomen KI-Agenten niemals einfach auf deinem persönlichen Hauptrechner.

Der Grund ist bestechend logisch. Ein Agent auf deinem Alltags-PC hätte potenziell Zugriff auf alles, worauf auch du Zugriff hast: deine SSH-Schlüssel (die digitalen Schlüssel für Serverzugänge), deinen Passwortmanager, die Schlüsselbund-Verwaltung deines Betriebssystems, die gesamte Festplatte, deine Cloud-Dienste, deinen Browser mit allen eingeloggten Konten. Das ist schlicht zu viel Macht für ein System, das eigenständig handelt.

Und die zentrale Bedrohung heißt Prompt Injection. Das ist der Fachbegriff dafür, dass jemand einer KI heimlich Anweisungen unterjubelt, indem er sie in Inhalte versteckt, die die KI ohnehin verarbeitet. Ein Beispiel, das die Sache greifbar macht: Stell dir vor, dein Agent fasst morgens deine E-Mails zusammen. Darunter ist eine gefälschte Nachricht, angeblich von einem Paketdienst, mit der Bitte, sich zur Zahlung von Zollgebühren über einen Link ins Online-Banking einzuloggen. Ein Mensch würde stutzig. Ein Agent könnte das als Handlungsauftrag verstehen, die Seite ansteuern und sich einloggen – mit deinen Zugangsdaten, falls er sie hat. Und du bekommst davon womöglich nichts mit.

Das ist kein Schreckgespenst. Sicherheitsforscher haben genau solche Szenarien 2026 praktisch durchgespielt. Das Sicherheitsunternehmen HiddenLayer demonstrierte, wie eine harmlos aussehende Webseite einen Agenten beim bloßen Zusammenfassen dazu brachte, im Hintergrund einen Befehl auszuführen – ohne Rückfrage. Der Anbieter Palo Alto Networks zeigte, wie eine als „Guten Morgen“-Nachricht getarnte Weiterleitung einen Angriff auslösen konnte, dessen versteckte Anweisung dank des Langzeitgedächtnisses noch Wochen später im Kontext des Agenten schlummerte.

Sicherheitsforscher fassen dieses strukturelle Problem in einem einprägsamen Begriff zusammen: der Lethal Trifecta (die „tödliche Dreifaltigkeit“). Ein Agent wird brandgefährlich, sobald er drei Dinge gleichzeitig kann: auf private Daten zugreifen, nicht vertrauenswürdige Inhalte von außen verarbeiten und nach außen kommunizieren. Genau diese drei Zutaten bringt ein voll ausgestatteter Agent von Haus aus mit. Und – das ist die unbequeme Wahrheit – kein einziger KI-Anbieter hat Prompt Injection bislang zuverlässig gelöst. Auch OpenClaw sagt das in seiner eigenen Sicherheitsdokumentation offen: Ein starker System-Prompt ist nur eine weiche Empfehlung, keine harte Absicherung.

Die Lösung ist deshalb keine Zauberformel, sondern eine bauliche Entscheidung: Man gibt dem Agenten von vornherein einen abgeschlossenen, ungefährlichen Ort zum Arbeiten. Man behandelt ihn, um im Bild zu bleiben, wie einen Praktikanten, dem man nicht blind vertraut – man gibt ihm einen eigenen Schreibtisch und schließt die Türen ab, hinter denen er nichts verloren hat.

Dieser eigene Schreibtisch ist eine virtuelle Maschine oder ein VPS (Virtual Private Server – ein gemieteter virtueller Server im Rechenzentrum). Also ein isolierter Computer, auf dem keine sensiblen Daten liegen und von dem aus der Agent keinen Schaden in deinem echten digitalen Leben anrichten kann.

Runbook: OpenClaw sicher aufsetzen

Genug Theorie. Hier die groben Schritte, wie man einen solchen Agenten in Betrieb nimmt – bewusst als Landkarte, nicht als Klick-für-Klick-Anleitung, weil sich Details laufend ändern.

Schritt 1 – Den isolierten Ort besorgen. Entweder mietet man einen VPS (Anbieter wie Hostinger bewerben eigene „Managed OpenClaw“-Pakete, bei denen Wartung, Updates und Backups übernommen werden), oder man richtet sich eine virtuelle Maschine ein. Als Betriebssystem empfiehlt sich eine aktuelle Linux-Version wie Ubuntu. Als Ausstattung reichen für den Anfang bescheidene Ressourcen, komfortabler sind zwei Prozessorkerne und einige Gigabyte Arbeitsspeicher.

Schritt 2 – OpenClaw installieren. Auf dem frischen Server legt man zunächst einen eigenen Benutzer an (nicht als allmächtiger Administrator arbeiten). Dann installiert man OpenClaw – üblicherweise über einen einzeiligen Installationsbefehl. Das Programm braucht eine aktuelle Version von Node.js (eine Laufzeitumgebung, die JavaScript-Programme außerhalb des Browsers ausführt) und einen API-Key (einen geheimen Zugangsschlüssel) für das KI-Modell, das man nutzen will.

Schritt 3 – Das Gehirn wählen. Im Einrichtungsassistenten legt man fest, welches KI-Modell den Agenten antreibt. Hier gilt ein wichtiger Praxis-Hinweis: Ein zu schwaches Modell führt zu Frust, weil es die Werkzeuge nicht richtig bedient oder sich im Kreis dreht. Für ernsthafte Nutzung greift man zu einem leistungsfähigen Modell – das kostet zwar pro Anfrage etwas, spart aber Nerven.

Schritt 4 – Telegram anbinden. Damit man den Agenten bequem vom Handy aus erreicht, verbindet man einen Chat-Kanal. Telegram ist der einfachste. Man erstellt im Telegram-eigenen BotFather (einem offiziellen Bot zum Anlegen neuer Bots) mit dem Befehl /newbot einen neuen Bot, vergibt Name und Benutzername und bekommt einen Token – eine Art Passwort für den Bot. Diesen trägt man in OpenClaw ein. Ganz wichtig: Die erste eingehende Nachricht muss über einen Pairing-Code (einen einmaligen Bestätigungscode) freigegeben werden. Das ist kein lästiger Umweg, sondern eine Schutzfunktion – sie verhindert, dass Fremde mit deinem Agenten reden.

Danach läuft der Agent im Hintergrund weiter, auch wenn du die Verbindung zum Server schließt. Du schreibst ihm von nun an einfach per Telegram, wie einem Kontakt.

Der eigentliche Clou: Ein KI-Wächter namens Bernd

Jetzt fügen wir die beiden Puzzleteile zusammen. Wir haben einen dauerhaft laufenden Agenten (OpenClaw). Und wir haben eine Technik, mit der eine KI strukturierten Zugriff auf Home Assistant erhält (MCP). Was passiert, wenn man beides verbindet?

Man bekommt einen 24/7-Wächter für sein Smart Home. In den Quellvideos trägt er einen Namen: Bernd.

Die Idee ist so einfach wie bestechend. Bernd prüft regelmäßig, ob mit deinem Home Assistant etwas nicht stimmt – und meldet es dir per Telegram, bevor du es selbst merkst. Oder, wie es im Video augenzwinkernd heißt, bevor die Partnerin es merkt. Sensoren, die plötzlich keine Werte mehr liefern. Add-ons, die abgestürzt sind. Geräte, deren Batterie zur Neige geht. Fehler in den Protokollen, die sich häufen. Ausstehende Updates, die man sonst monatelang verschleppt, bis irgendwann nichts mehr geht.

So setzt man ihn konzeptionell auf:

Bernd läuft getrennt von Home Assistant. Das ist kein Zufall, sondern Absicht. Würde der Wächter auf demselben System laufen wie das, was er überwacht, wäre er bei einem Ausfall selbst blind. Ein Wächter, der zusammen mit dem Bewachten ausfällt, ist kein Wächter.

Bernd bekommt Zugriff auf Home Assistant über den MCP-Server. Hier verbindet man OpenClaw mit dem ha-mcp-Server. Läuft der Agent auf einem entfernten VPS und Home Assistant zu Hause, braucht es einen sicheren Tunnel dazwischen – dazu gleich mehr.

Bernd bekommt eine Identität. Man gibt dem Agenten einen ausführlichen Auftrag: wer er ist, welche Sprache er spricht, worauf er achten soll, was ihm wichtig ist. Faszinierend: Der Agent schreibt sich daraufhin selbst kleine Merk-Dateien mit Namen wie Identity.md und User.md und speichert so laufend Kontext über das System. In einem Test verknüpfte Bernd binnen Minuten selbstständig zwei Informationen, die für ihn getrennt vorlagen: dass ein bestimmter smarter Stecker im Energie-Dashboard eingetragen war und dass genau dieser Stecker gerade Verbindungsfehler warf.

So ein Auftrag muss nicht kompliziert sein. Ein brauchbarer Start-Prompt für Bernd könnte so aussehen:

Du bist Bernd, mein Home-Assistant-Wächter. Sprich Deutsch.
Prüfe täglich um 18:00 Uhr den Zustand meines Systems.
Melde nur relevante Auffälligkeiten: unavailable Entities,
kritische Logs, gestoppte Add-ons, fehlgeschlagene Automationen,
schwache Batterien, Backup-Status und ausstehende Updates.
Nimm keine Änderungen ohne ausdrückliche Bestätigung vor.
Bewerte jedes Problem als: beobachten, prüfen, dringend.

Bernd bekommt einen Zeitplan. Über einen Cron-Job (einen zeitgesteuerten Automatik-Auftrag, benannt nach dem klassischen Unix-Werkzeug) schickt er zum Beispiel jeden Abend um 18 Uhr einen Bericht. Wichtig dabei ist die Anweisung, nicht bloß eine starre Liste abzuhaken, sondern proaktiv zu schauen, was auffällt – auch Dinge, die man selbst gar nicht auf dem Schirm hatte.

Ein guter Wächter-Bericht deckt viele Bereiche ab: Systemgesundheit und ausstehende Updates, nicht mehr erreichbare Geräte, kritische Fehler in den Protokollen, gestoppte Add-ons, deaktivierte Automationen, schwächelnde Batterien, den Zustand der Backups, das Wachstum der Datenbank. Am Ende steht idealerweise keine nackte Fehlerliste, sondern eine Einordnung: nur beobachten, manuell prüfen, oder Handlungsbedarf. In der Praxis landet dann abends eine Telegram-Nachricht auf dem Handy, die etwa so aussieht:

Bernd-Report, 18:00 Uhr:
1. Zwei Zigbee-Sensoren sind seit 6 Stunden unavailable.
2. Letztes vollständiges Backup: vor 9 Tagen.
3. Add-on "Mosquitto broker" läuft, aber hatte 3 Neustarts.
Empfehlung: Backup heute anstoßen, Zigbee-Sensoren prüfen.

Genau diese Mischung aus konkretem Befund und knapper Empfehlung ist der eigentliche Mehrwert – nicht eine Datenflut, sondern ein kurzer, handlungsfähiger Lagebericht.

Und die vielleicht wichtigste Regel für den Anfang: Bernd soll berichten, nicht ungefragt reparieren. Ein Wächter, der eigenmächtig an deinem System herumschraubt, ist ein Risiko. Ein Wächter, der dir sagt, was los ist, und dich entscheiden lässt, ist ein Gewinn.

Wenn die KI selbst zum Handwerker wird

Der Wächter ist der vorsichtige Einstieg. Aber MCP kann mehr, als nur Bericht zu erstatten. Mit dem inoffiziellen ha-mcp-Server darf die KI auch selbst bauen – Automationen, Sensoren, Szenen, ganze Dashboards.

Ein Beispiel aus der Praxis macht das lebendig. Ein Nutzer diktierte seiner KI beiläufig den Wunsch, für seine Wetterstation einen Sensor zu bauen, der die Regenmenge pro Tag anzeigt, statt nur die Gesamtmenge. Ein technisch keineswegs triviales Vorhaben mit mehreren Zwischenschritten. Die KI las zunächst den Best-Practice-Skill, suchte dann über MCP nach den passenden Wetter-Entitäten, korrigierte sich sogar selbst, als sie zunächst die falsche Quelle erwischt hatte, und legte schließlich einen sauber konfigurierten Helfer an. Der Mensch schrieb keine einzige Zeile Code.

Noch eindrücklicher: In einem anderen Fall baute die KI ein komplettes Dashboard für ein Baby, samt Auswertung einer smarten Socke und einem Anzeige-Element für die tägliche Trinkmenge – Aufgaben, für die der Nutzer nach eigener Aussage niemals selbst die Zeit und das Wissen gehabt hätte. Und die Partnerin desselben Nutzers, ohne Vorkenntnisse in Home Assistant, passte per Sprachbefehl selbstständig eine Automation im Kinderzimmer an. Das ist die eigentliche Pointe dieser Technik: Sie öffnet ein mächtiges, sonst nur Experten zugängliches Werkzeug für Menschen, die davon bisher ausgeschlossen waren. Ein Stück Demokratisierung von Technik, wie es im Buche steht.

Damit das gut geht, empfiehlt sich ein Stufenmodell des Vertrauens. Ganz am Anfang darf die KI nur lesen – analysieren, aber nichts ändern. Auf der nächsten Stufe darf sie vorschlagen – einen Plan machen, den der Mensch dann selbst umsetzt. Erst danach kommt Schreiben mit Freigabe, bei dem die KI zwar handeln darf, aber jede kritische Aktion einzeln bestätigt werden muss. Vollautonomes Schreiben ohne Rückfrage gehört nur auf ein Testsystem oder hinter ein sehr eng begrenztes Werkzeug-Set.

Welche Aktion wie riskant ist und wie man damit umgehen sollte, fasst diese Matrix zusammen – sie ist eine gute Orientierung, wenn man entscheidet, welche Werkzeuge man dem Agenten überhaupt in die Hand gibt:

Aktion	Risiko	Empfehlung
Entitäten lesen	niedrig	guter Start
Logs analysieren	mittel	Datenschutz beachten
Automation vorschlagen	niedrig–mittel	gut fürs Produktivsystem
Automation direkt anlegen	mittel	nur mit Freigabe
Add-ons verwalten	hoch	meistens deaktivieren
YAML-Dateien bearbeiten	sehr hoch	nur Testsystem / mit Backup
Schlösser, Alarm, Wallbox steuern	sehr hoch	grundsätzlich blockieren

Das gefährliche Kapitel: Wenn die KI an die Konfigurationsdateien darf

Es gibt eine Funktion, vor der selbst die Enthusiasten ausdrücklich warnen – und die trotzdem verlockend ist: die direkte Bearbeitung der YAML-Konfigurationsdateien durch die KI.

Warum verlockend? Weil manche Dinge in Home Assistant sich schlicht nicht über die schöne Oberfläche erledigen lassen, sondern nur direkt in den Konfigurationsdateien. Bestimmte spezielle Sensoren zum Beispiel. Wenn die KI diese Dateien selbst anfassen darf, kann sie also mehr für dich erledigen.

Warum gefährlich? Weil ein einziger falsch gesetzter Einzug oder ein vergessenes Zeichen genügt, um Home Assistant am Starten zu hindern oder bestehende Integrationen zu beschädigen. Und KIs neigen dazu, beim Bearbeiten einer großen Datei versehentlich Teile zu „vergessen“ und beim Zurückschreiben zu verwerfen. Stell dir vor, die KI überarbeitet deine zentrale Konfigurationsdatei, lässt aus Versehen die Hälfte weg – und beim nächsten Neustart bootet dein Smart Home nicht mehr.

Die Entwickler des ha-mcp-Servers haben deshalb genau diese Werkzeuge in einen abgesperrten Beta-Bereich verschoben. Man muss sie bewusst und mit Zusatzkomponenten aktivieren; von Haus aus sind sie aus. Das ist eine kluge Vorsichtsmaßnahme, kein Zufall.

Die Regel, die man sich einprägen sollte, lautet sinngemäß: Kein Backup, kein Mitleid. Die KI darf an die YAML-Dateien nur, wenn erstens ein frisches Backup existiert, zweitens die Änderung klein und nachvollziehbar ist, drittens vor dem Neustart eine Konfigurationsprüfung läuft, viertens ein Rückweg klar ist – und fünftens die KI nicht gleichzeitig noch breite Schreibrechte auf den Rest des Systems hat. Auf dem produktiv genutzten Zuhause-System lässt man diese Werkzeuge am besten ganz weg.

Der sichere Weg nach draußen

Noch ein technisches Puzzleteil, das oft Kopfzerbrechen bereitet. Wenn Bernd auf einem VPS im Rechenzentrum wohnt und dein Home Assistant zu Hause im Wohnzimmerschrank, müssen die beiden ja irgendwie miteinander reden. Der Agent braucht einen Weg zum MCP-Server – und dieser Weg soll sicher sein.

Man sollte dafür auf keinen Fall einfach einen Port in seinem Router aufreißen und den MCP-Server offen ins Internet stellen. Die bessere Wahl sind geschützte Tunnel: Nabu Casa (der offizielle Cloud-Dienst der Home-Assistant-Macher), Tailscale (ein Dienst, der private, verschlüsselte Netze zwischen deinen Geräten aufspannt) oder ein Cloudflare Tunnel (eine Art abgesicherter Durchgang durch Cloudflares Infrastruktur). Welche Variante die richtige ist, hängt vom eigenen Setup ab – gemeinsam ist ihnen, dass sie den Zugang absichern, statt ihn offen ins Netz zu legen.

Und hier die Warnung, die man sich rot anstreichen sollte: Die Adresse, unter der der MCP-Server erreichbar ist, enthält einen geheimen Teil, der faktisch ein Passwort ist. Wer diese Adresse besitzt, kann – je nach Konfiguration – sehr weitreichend auf dein Home Assistant zugreifen. Diese URL gehört niemals in einen öffentlichen Chat, in ein Forum oder versehentlich in ein KI-Fenster kopiert. Behandle sie wie den Schlüssel zu deinem Haus. Denn ungefähr das ist sie.

Ein häufiges Missverständnis noch zum Schluss dieses Abschnitts: Bei den bequemen Verbindungen über den Claude-Account laufen die Anfragen technisch über die Cloud-Server des Anbieters, nicht über dein lokales Netzwerk – selbst dann, wenn die Anwendung auf deinem Rechner läuft. Ein rein im Heimnetz erreichbarer MCP-Server lässt sich deshalb nicht ohne Weiteres direkt anbinden. Auch das ist ein Grund, warum die Tunnel-Lösungen oben ins Spiel kommen.

So würde ich anfangen: eine Checkliste für den ersten Tag

Weil dieser Artikel praktisch sein soll, hier die konzentrierte Startkonfiguration – acht Punkte, die man abhaken kann, bevor man dem Agenten mehr zutraut:

1. Nur lesen, keine Schreibrechte. Starte im reinen Lesemodus. Erlaube der KI zunächst ausschließlich Abfragen. Erst nach Tagen des Vertrauens einzelne Schreibrechte freischalten.
2. Riskante Werkzeuge abschalten. Deaktiviere von Anfang an die Werkzeuge mit großem Schadenspotenzial: Backup-Wiederherstellung, Add-on-Verwaltung, Neustart des Systems, Löschen von Geräten oder Dashboards – und ganz besonders die YAML-Werkzeuge.
3. Ein eigener Benutzer – aber verlass dich nicht allein darauf. Lege in Home Assistant einen dedizierten Nutzer beziehungsweise Token für den Agenten an, kein Administrator-Konto. Aber prüfe genau, ob dein gewählter MCP-Server diesen eingeschränkten Scope technisch tatsächlich erzwingt. Beim offiziellen Server greift die Assist-Freigabe als echte Grenze; beim inoffiziellen ha-mcp kann der tatsächliche Zugriff je nach Setup deutlich breiter sein, sodass „nicht Admin“ allein nicht automatisch als Sicherheitsgrenze taugt.
4. Backup vor jeder neuen Schreibfreigabe. Bevor die KI zum ersten Mal etwas ändern darf: Backup anstoßen und Erfolg prüfen. Jedes Mal.
5. Erst auf einer Testinstanz üben. Neues zuerst auf einem separaten Testsystem bauen lassen, dann geprüft ins echte System übernehmen.
6. Keine YAML-Werkzeuge im Produktivsystem. Wenn überhaupt, nur zeitlich begrenzt, mit frischem Backup und einem Menschen, der jede Zeile liest.
7. Chat-Kanäle nur mit Freigabe. Telegram und Co. ausschließlich über Pairing-Codes und Positivlisten öffnen. Keine offenen Bots in öffentlichen Gruppen.
8. Ausgabenlimit setzen. Ein tägliches oder monatliches Budget beim KI-Anbieter schützt vor Kostenexplosionen durch den Dauerbetrieb – und begrenzt den Schaden, falls der Schlüssel doch einmal abhandenkommt.

Zwischen Praktikant und Vertrauensperson

Kehren wir zum Schluss noch einmal zu Miriam zurück. Hätte sie MCP eingerichtet, hätte ihre KI nicht den erfundenen Bewegungsmelder angesprochen, sondern den echten gefunden. Sie hätte die richtige Lampe erkannt, die passende nächtliche Helligkeit gewählt und vielleicht sogar vorgeschlagen, das Licht nach ein paar Minuten wieder auszuschalten. Aus einem frustrierenden „sieht richtig aus, funktioniert aber nicht“ wäre ein „läuft“ geworden.

Das ist der reale, greifbare Fortschritt hinter all den fremden Begriffen. MCP macht aus einer KI, die dein Zuhause nur errät, eine KI, die dein Zuhause tatsächlich befragen kann. Ein Agent wie OpenClaw macht daraus einen dauerhaft erreichbaren Mitbewohner. Diese Kombination ist mächtig genug, um Automationen zu bauen, Dashboards zu entwerfen und nachts Wache zu halten. Und sie ist mächtig genug, um bei falsch vergebenen Rechten echten Schaden anzurichten. Beides ist wahr, und beides sollte man wissen.

Vielleicht ist das treffendste Bild wirklich das des Praktikanten. Ein guter Praktikant ist ein Geschenk: klug, fleißig, entlastend, oft überraschend fähig. Aber man gibt ihm nicht am ersten Tag den Generalschlüssel, den Zugang zum Tresor und die Vollmacht fürs Firmenkonto. Man lässt ihn erst zeigen, dass er versteht, was er tut. Man schaut ihm über die Schulter. Und man gibt ihm nach und nach mehr Verantwortung, wenn er sie verdient hat.

Die eigentliche Frage, die diese Technik aufwirft, ist deshalb keine technische. Sie lautet: Wie viel Autonomie wollen wir einem System geben, das erstaunlich klug wirken kann, aber im Kern nicht wirklich versteht, was auf dem Spiel steht – und das sich, anders als ein Mensch, nicht schämt, wenn es einen Fehler macht? Wo ziehst du die Grenze zwischen dem bequemen Helfer, der dir Arbeit abnimmt, und dem autonomen Akteur, dem du Schlüssel zu deinem digitalen Leben in die Hand drückst?

Die Werkzeuge dafür stehen bereit. Die Entscheidung, wie weit man gehen will, bleibt – noch – bei uns.