Einen KI-Assistenten an mein Smart Home lassen
Home Assistant spricht MCP. Wie ich einen KI-Agenten mit rund fünfzig Geräten verbunden habe, und warum er am Ende deutlich weniger Werkzeuge bekam, als er wollte.
Einen KI-Assistenten an mein Smart Home lassen
Meine Home-Assistant-Installation läuft schon eine Weile lokal. Über
fünfzig Geräte: Lampen, Thermometer, Fenstersensoren, ein Saugroboter,
ein paar selbstgebaute Präsenzmelder. Die einfache Hälfte davon
erledigen Sprachassistenten problemlos. „Schalte das Küchenlicht aus“ ist
seit Jahren ein gelöstes Problem.
Die andere Hälfte war nie gelöst. Fragen wie warum hat die Heizung um
drei Uhr nachts gelaufen brauchen etwas, das viel Zustand auf einmal
lesen, miteinander in Beziehung setzen und dann eine YAML-Datei
bearbeiten kann. Das ist eine andere Art von Werkzeug.
Home Assistant bringt eine Integration mit, die das möglich macht, und
fast niemand redet darüber.
Was MCP hier eigentlich ist
MCP ist ein Protokoll, um einem KI-Client eine Liste von Tools zu geben,
die er aufrufen darf. Der Client fragt den Server „was kannst du“,
bekommt eine Liste von Funktionen mit typisierten Argumenten zurück und
kann sie dann aufrufen.
Home Assistant implementiert die Serverseite. Es nimmt die vorhandenen
Intents des Sprachassistenten, dieselben, die auch die eingebaute
Assist-Pipeline nutzt, und stellt sie per HTTP bereit. So bekommt der
Agent HassTurnOn, HassLightSet, HassClimateSetTemperature,
GetLiveContext und weitere.
Neu erfunden wird nichts. Es ist die Assist-Schicht, nur mit einer
anderen Tür.
Einrichtung
1. Zuerst festlegen, was er sehen darf
Das kommt vor allem anderen. Es ist die eigentliche Sicherheitsgrenze, und
man überspringt es leicht, weil die Integration auch ohne diesen Schritt
funktioniert.
Unter Settings → Voice assistants → Expose steht alles, was jeder
MCP-Client lesen und steuern kann. Alles, was dort nicht steht, ist
unsichtbar.
Ich habe mit einer leeren Liste angefangen und gezielt Dinge
hinzugefügt. Lampen, Klima, den Saugroboter, Sensoren, nach denen ich
wirklich frage. Nicht die Türschlösser. Nichts, was Geld kostet, wenn es
versehentlich ausgelöst wird.
2. Die Integration hinzufügen
Settings → Devices & services → Add Integration → Model Context
Protocol Server. Es gibt nichts auszufüllen, denn die Freigabe der
Entitäten aus Schritt eins ist die Konfiguration.
3. Ein Token erzeugen
Profile → Security → Long-lived access tokens → Create token.
Es wird nur einmal angezeigt, also direkt kopieren. Wichtig zu wissen: Ein
Long-lived Token erbt die Rechte des Benutzers, der es erstellt hat. Wer
es mit dem Admin-Account erzeugt, hat ein Admin-Token. Ich habe dafür
einen eigenen Home-Assistant-Benutzer ohne Adminrechte angelegt und das
Token von dort aus generiert.
4. Den Client darauf zeigen lassen
Der Endpunkt ist /api/mcp. Für Claude Code:
Oder als JSON, wenn man die Konfiguration lieber direkt bearbeitet:
--scope user macht es in jedem Projekt verfügbar. --scope project
schreibt es in eine .mcp.json, die eingecheckt wird. Das sollte man mit
einem Token darin nicht tun.
Das ist das ganze Setup. Unter fünf Minuten, wenn man schon entschieden
hat, was freigegeben wird.
Was mich überrascht hat: Tools sind nicht gratis
Jedes Tool, das der Server anbietet, wird dem Modell bei jeder einzelnen
Anfrage beschrieben. Name, Beschreibung, vollständiges Argumentschema.
Dieser Text belegt Kontextfenster, noch bevor man irgendetwas getippt hat.
Bei einer großzügigen Freigabeliste hatte ich allein durch Tool-Definitionen
einen spürbaren Teil des Kontexts belegt, bei jeder Nachricht, in jedem
Projekt, auch in denen, die mit meiner Wohnung nichts zu tun hatten.
Zwei Dinge haben es gelöst:
Die Freigabeliste zusammenstreichen. Das ist der Hebel, der wirklich
funktioniert, weil er serverseitig sitzt. Weniger freigegebene Entitäten
bedeuten kleinere Tool-Beschreibungen und weniger irrelevante Optionen,
die das Modell bedenken muss. Der Agent wurde dadurch auch spürbar
treffsicherer. Bei sechs Lampen wählt er die richtige. Bei sechzig rät er.
Es dort nicht laden, wo man es nicht braucht. Ein
Smart-Home-Connector in einem Webprojekt ist reiner Overhead. Den Geltungsbereich
bewusst festlegen.
Wo es richtig gut ist
Drei Dinge rechtfertigen sich wirklich:
Das ganze Bild auf einmal lesen. GetLiveContext liefert den
aktuellen Zustand aller freigegebenen Entitäten. Die Frage „welche Fenster
sind offen und was macht die Heizung“ bekommt eine echte Antwort statt
dreier einzelner Sprachabfragen.
Automationen schreiben. Das ist das Große. Eine Automation in einem
Satz zu beschreiben und gültiges YAML zurückzubekommen, mit den richtigen
Entity-IDs, weil er sie nachschlagen kann, nimmt den größten Teil der
Reibung aus der Arbeit, die ich hasse. Jede Zeile lese ich trotzdem, bevor
sie übernommen wird.
Nachträgliches Debuggen. Eine Sensorspur mit einem Automations-Trigger
abzugleichen ist von Hand mühsam und geht schnell, wenn etwas beides
lesen kann.
Wo es schlecht ist
Es ist kein Sprachassistent. Die Rundläufe dauern Sekunden, das ist in
Ordnung für „schreib mir eine Automation“ und nutzlos für „mach das Licht
aus“, wenn man gerade am Schalter vorbeigeht. Dafür ist die eingebaute
Assist-Pipeline weiterhin das richtige Werkzeug, und beide vertragen sich
gut.
Außerdem ist es strukturell etwas mit einem Token, das bei mir zu Hause
Dinge einschalten kann. Die Freigabeliste ist die Grenze, die sie
tatsächlich ist: das Token von jeder Maschine fernhalten, die ich nicht
kontrolliere, und nicht in ein Repo packen.
Würde ich es wieder tun
Ja, aber von Anfang an mit der Freigabeliste, statt sie später zu
kürzen. Das Setup ist trivial. Die Überlegung, was er anfassen darf, ist
die eigentliche Arbeit, und die lohnt sich vor dem Erzeugen des Tokens,
nicht danach.