blog.peterge.de

Der Anlass für dieses Projekt war ein Video vom YouTube-Kanal „Spiel und Zeug”, in dem der MCP-Server für Home Assistant vorgestellt wurde. MCP (Model Context Protocol) ist ein standardisierter Weg, um LLMs mit externen Tools, Systemen und Datenquellen zu verbinden.

Licht per Chat einzuschalten ist zwar nett, aber dafür brauche ich keine KI. Spannend wird es, wenn die KI Home Assistant verwalten kann, ohne immer wieder Sachen in einen KI‑Chat zu kopieren und wieder herauszukopieren: Automationen schreiben und debuggen, Logs auswerten, die Konfiguration aufräumen und das System warten. Darum geht es in diesem Artikel.

Voraussetzung: Home Assistant von außen erreichbar machen

Ein Custom Connector in Claude wird nicht von meinem Gerät aus angesprochen, sondern von den Servern von Anthropic. Ein VPN oder ein Zugriff nur im WLAN hilft hier also nicht. Der MCP-Endpunkt muss aus dem öffentlichen Internet per HTTPS mit einem gültigen Zertifikat erreichbar sein. Mein Aufbau sieht so aus:

Claude (Anthropic) ─ HTTPS ─> ha-ext.example.de (CNAME auf MyFRITZ-Name)
                                  │
                              FRITZ!Box: Portfreigabe TCP auf Port 443
                                  │
                              Home Assistant (terminiert TLS selbst)

1. Portfreigabe in der FRITZ!Box

In der FRITZ!Box habe ich eine Portfreigabe für TCP 443 auf die Home Assistant Instanz angelegt. Home Assistant terminiert TLS selbst, es sitzt also kein Reverse Proxy davor. Dafür muss HA direkt auf 443 lauschen und das Zertifikat kennen:

http:
  server_port: 443
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

2. Zertifikat über das Let’s Encrypt Add-on

Das Zertifikat kommt vom Let’s Encrypt Add-on. Es legt die Dateien standardmäßig unter /ssl/fullchain.pem und /ssl/privkey.pem ab, also genau dort, wo die http:⁣ Konfiguration sie erwartet. Der entscheidende Punkt ist, dass beide Namen im Zertifikat stehen, sowohl der interne als auch der externe.

Bei der HTTP-Challenge muss Port 80 für die Validierung erreichbar sein. Die DNS-Challenge braucht das nicht, setzt aber einen unterstützten DNS-Provider (in meinem Fall per API von Netcup) samt API-Zugang voraus. Die Erneuerung übernimmt das Add-on selbst, danach muss HA das neue Zertifikat laden (Neustart oder Reload).

3. Zwei DNS-Namen: intern und extern

Ich habe bewusst zwei Namen angelegt:

ha.example.de zeigt als A-Record auf die interne IP von Home Assistant
ha-ext.example.de zeigt als CNAME auf meinen MyFRITZ-Namen und folgt damit automatisch der wechselnden öffentlichen IP

Dadurch läuft der Verkehr zu Hause komplett im LAN. Ich betreibe dafür keinen eigenen internen DNS-Server, da die Companion App die Umschaltung unterstützt.

4. Companion App: Umschalten per WLAN-Name

In der Companion App habe ich beide URLs hinterlegt und die Überprüfung des WLAN-Namens (SSID) aktiviert. Zu Hause verbindet sie sich über ha.example.de, unterwegs automatisch über ha-ext.example.de.

TOTP und Ban-Schutz

Wenn die Smart-Home-Zentrale im Internet hängt und eine KI Schreibrechte darauf bekommen soll, reicht mir ein 20 stelliges Passwort nicht. Deshalb habe ich die Multi-Faktor-Authentifizierung vom Typ TOTP eingeschaltet:

homeassistant:
  auth_mfa_modules:
    - type: totp

Zusätzlich empfehle ich, in der http: Konfiguration den IP-Ban zu aktivieren, damit Brute-Force-Versuche auf die Loginseite nach einigen Fehlversuchen gesperrt werden:

http:
  ip_ban_enabled: true
  login_attempts_threshold: 5

Stufe 1: Die offizielle MCP-Server-Integration

Zuerst bin ich der Anleitung in der Home Assistant Dokumentation für Claude gefolgt. Das ist schnell erledigt, und danach kann Claude Entitäten abfragen und schalten. Claude fragt dabei vor jeder Aktion nach, ob es das Tool nutzen darf. Mein Test war eine Lampe, und die war in diesem Fall pink-lila :D

Aber das war es dann auch: Die offizielle Integration ist auf das Steuern und Abfragen von Geräten ausgelegt. Automationen anlegen oder andere administrative Dinge funktionieren damit nicht:

Stufe 2: ha-mcp, die KI als Administrator

Deshalb habe ich als Nächstes die Community-Variante ha-mcp eingerichtet. Der Unterschied ist enorm, denn sie bringt dutzende Werkzeuge für die Konfiguration mit, nicht nur für die Bedienung. Mein erster Test war, die Anzahl der Geräte und Entitäten abzufragen, was mit der offiziellen Integration nicht möglich war:

Hier ist, was meiner Meinung nach den echten Mehrwert ausmacht:

Automationen und Skripte schreiben, ändern und debuggen

Claude kann Automationen, Skripte und Szenen anlegen und bestehende auslesen und anpassen. Der eigentliche Gewinn kommt aber beim Debugging, denn es kann auch die Ausführungs-Traces einer Automation abrufen, die Logs durchsuchen und den Verlauf von Entitäten ansehen. So sieht es selbst, warum eine Automation nicht oder falsch ausgelöst hat, statt dass ich Screenshots und YAML-Schnipsel in den Chat kopieren muss.

Siehe Demo Video

Konfiguration aufräumen

Mit der Zeit sammelt sich in jeder Installation Chaos an: ungleiche Entitätsnamen, fehlende Bereiche, unsortierte Helfer. Claude kann Entitäten und Geräte umbenennen oder Bereichen zuordnen, Labels und Kategorien vergeben und Helfer anlegen. Das sind genau die Fleißaufgaben, die man selbst immer vor sich herschiebt.

Dashboards bauen

Dashboards lassen sich ebenfalls lesen und schreiben. Man kann also beschreiben, was man sehen möchte, und Claude erzeugt die Konfiguration dafür.

Wartung und Systemzustand

Es gibt außerdem Werkzeuge für den Systemzustand, anstehende Updates, Backups, Add-ons und HACS. Claude kann also einen Überblick geben, was gerade ansteht oder was in den Logs auffällig ist.

Es funktioniert unfassbar gut. (Der Grund für das Backup Problem auf fritznas ist natürlich SMB …). Das einzige Problem ist aber, dass man so natürlich schneller ans Limit vom Claude Free Plan stößt …

Schreibrechte für eine KI

Wer einer KI Schreibzugriff auf die Smart-Home-Zentrale gibt, sollte ein paar Regeln beachten:

Backup vor größeren Änderungen: Home Assistant sollte ein aktuelles Backup haben, bevor Claude Automationen, Dashboards oder Konfiguration umbaut. Noch besser sind automatische Backups. Bei mir in Home Assistant selbst, aber auch in Proxmox eingerichtet.
Bestätigung nicht abschalten: Claude fragt vor jeder Aktion nach. Diese Rückfrage ist das Sicherheitsnetz, und ich lese sie durch, bevor ich bestätige.
Ergebnis prüfen: Was Claude schreibt, sollte man sich ansehen, bevor man sich darauf verlässt, vor allem bei Automationen, die Heizung, Schlösser oder Alarmanlagen betreffen.
MCP-URL wie ein Passwort behandeln: Wer sie kennt, hat Zugriff auf eine Schnittstelle mit Administratorrechten.
TOTP und HTTPS sind bei externem Zugriff nicht optional, sondern meiner Meinung nach Pflicht.

Kosten & Lizenzen

Das alles ist ohne Kosten möglich, solange man genug Zeit und Know-How mitbringt:

Claude: Mit der kostenlosen Version kann man einen Connector (also eine MCP-URL) anlegen.
Home Assistant Link/Nabu Casa: Das Abo (bis vor Kurzem noch unter dem Namen Home Assistant Cloud bekannt) ist in meinem Setup nicht nötig. Es vereinfacht aber einiges, weil es den externen Zugriff gleich mitbringt und man sich nicht selbst um Portfreigabe, DNS und Zertifikate kümmern muss.

Fazit

Der externe Zugriff war die meiste Arbeit, der MCP-Teil danach schnell eingerichtet. Zum Ausprobieren also optimal.
Für reines Schalten reicht die offizielle Integration. Der wirkliche Gewinn liegt für mich aber darin, Home Assistant mit KI zu verwalten: Automationen debuggen, Konfiguration aufräumen und das System im Blick behalten.

Update: Reverse Proxy

Die Methode oben ist nur die Quick-and-Dirty-Variante: Die Portfreigabe zeigt direkt auf Home Assistant, und dessen eingebauter Webserver (Python) hängt damit unmittelbar im Internet. Sauber geht es mit einem Reverse Proxy davor.

Warum ein Reverse Proxy?

Zusätzliche Schutzschicht: Anfragen aus dem Internet landen zuerst bei nginx, nicht beim Webserver von Home Assistant. Fehlerhafte oder ungültige HTTP-Anfragen werden dort abgefangen, bevor sie HA erreichen. Das ist keine Garantie, aber ein Webserver, der extrem verbreitet ist und intensiv geprüft wird, ist die bessere erste Anlaufstelle als der eingebaute Python-Webserver.
Home Assistant ist nicht mehr direkt erreichbar: Die Portfreigabe am HA-Standort ist weg. Aus dem Internet erreichbar ist nur noch der Proxy.
Zertifikat und Private Key liegen nicht mehr auf dem HA-Host: TLS wird am Proxy terminiert und das Zertifikat dort zentral verwaltet und erneuert.
Zentrale Logs: Access- und Error-Logs liegen am Proxy, und wer worauf zugreift, sieht man an einer Stelle.
Patches unabhängig von HA-Releases: Der Proxy bekommt seine Sicherheitsupdates automatisch (mit Watchtower), ohne dass man Home Assistant anfassen muss.
Wiederverwendbar: Weitere Dienste lassen sich später genauso anbinden, ohne neue Portfreigaben.

Was dagegen spricht

Zusätzliche Abhängigkeit: Fällt der Proxy aus (oder der VPN-Tunnel an den Standort, wo der Proxy läuft), ist der MCP-Zugriff von Claude weg. Wer noch keinen Proxy hat, muss ihn erst aufsetzen, absichern und pflegen, und dann ist die Quick-and-Dirty-Variante um MCP zu testen, die schnellere Lösung.

In meinem Fall wiegt der Kontrapunkt wenig: Der Proxy ist nur für den Zugriff von Claude relevant. Ich selbst komme jederzeit per VPN an Home Assistant, ein Ausfall betrifft also nur den MCP-Zugriff.

Mein Setup

In Harperscheid läuft ohnehin schon ein Nginx Proxy Manager (NPM). Er wird automatisch aktuell gehalten, das Betriebssystem per Unattended Upgrades und der Container per Watchtower. Ich muss also nichts neu aufsetzen, sondern nur einen weiteren Proxy Host und ein Zertifikat anlegen.

Der Proxy erreicht Home Assistant über das Site-to-Site-WireGuard-VPN zwischen den beiden FRITZ!Boxen. Der Verkehr von Claude geht also über das Internet zum Proxy und von dort durch den Tunnel zu Home Assistant.

Umsetzung

Das ist, was ich gegenüber dem Quick-and-Dirty-Aufbau ändern musste:

FRITZ!Box am HA-Standort: Die Portfreigabe auf Home Assistant ist weg.
DNS: Der Record des externen Namens zeigt jetzt auf den Anschluss in Harperscheid, wo der Proxy steht. Der Name selbst bleibt gleich, deshalb ändern sich weder die externe URL in Home Assistant noch die URL im Claude-Connector.
NPM: Ein neues Zertifikat anlegen (per API von netcup) und dieses einem neuen Proxy Host zuordnen.
Home Assistant: Der Proxy muss als vertrauenswürdig eingetragen werden, sonst lehnt HA die weitergeleiteten Anfragen mit einem 400er ab:

Home Assistant mit KI verwalten: Claude per MCP Server anbinden