Home Assistant Automationen per KI

2.425 Entitäten, 1 Stunde Setup – und plötzlich schreibt die KI präziser Automationen als ich es tue.

Ab 1.000 Entitäten wird Home Assistant kein Bastelprojekt mehr. Sondern Architektur.

Wenn dein Home Assistant irgendwann vierstellig bei den Entitäten wird, dann kippt das System. Nicht technisch. Aber mental.

Bei mir sind es aktuell 2.425 Entitäten. Sensoren, Helfer, Template-Sensoren, Zigbee, MQTT, REST, alles drin. Und irgendwann habe ich gemerkt:

• neue Automationen kosten Zeit
• bestehende optimieren ist nervig
• YAML prüfen frisst Fokus
• Kontext behalten ist anstrengend

Ich persönlich will nie weniger Kontrolle. Aber ich will mehr Geschwindigkeit. Ich möchte Ideen umsetzen und nicht stundenlang planen. Dafür bin ich im Smart Home zu spontan. Also habe ich OpenCode mit einem lokalen MCP für Home Assistant getestet.

Ergebnis: Ich schreibe aktuell keine Automationen mehr. Ich prompte nur noch.

Und nein – das ist kein Cloud-Hype oder Marketingversprechen. Genau deshalb habe ich auch meinen ersten eigenen Deep Dive zum Thema Home Assistant + OpenCode geschrieben. Auf über 30 Seiten PDF bekommst du zu diesem Artikel noch mehr Know-How.

Schnellstart

Im gesamten Artikel habe ich dir viele Informationen, die einen genauen Blick auf die Architektur beziehungsweise den Stack werfen. Wenn du aber zur ungeduldigen Sorte Mensch gehörst (ich versteh dich ..), hier einmal kurz die Schnellstart-Anleitung:

1. Installiere dir OpenCode von der offiziellen Website
2. Verbinde ein LLM deiner Wahl (z. B. Codex) mit OpenCode
3. Richte den Home Assistant MCP-Server ein

Für die Verbindung zur LLM reicht in der Regel der OAuth2-Flow. Also du meldest dich wahrscheinlich über einen Link per Webbrowser an. Geht schnell und einfach.

Die Einrichtung des MCP für Home Assistant ist bisschen tricky am Anfang. Wichtig ist nur, dass du deinen Long Lived Access Token bereit hast. Den findest du in Home Assistant in deinem Benutzerprofil unter Sicherheit (Tab oben).

Danach quatschst du einfach schnell die LLM an und weist sie bei Bedarf darauf hin, dass sie Zugriff per MCP auf dein Smart Home hat.

Architektur: fast komplett lokal

Bevor du jetzt Schnappatmung bekommst: Es läuft fast lokal. Und auch der letzte Schritt wäre wahrscheinlich noch möglich. Mir persönlich fehlt dafür einfach nur eine lokale LLM, die mir entsprechend die Umsetzung macht. Das ist ein Gebiet, auf dem ich bislang noch nicht sonderlich weit gekommen bin um ehrlich zu sein.

Dennoch ist es nicht weniger beeindruckend. Mein Stack sieht aktuell wie folgt aus:

• OpenCode lokal auf meinem Rechner
• MCP als Docker-Container in Portainer (potenzielles Risiko)
• Zugriff via Home Assistant API (Long-Lived Token)
• Modell: Codex (austauschbar)

OpenCode ist hier für mich entweder als normale Desktop-Anwendung oder CLI die erste Anlaufstelle. Hier werden die Verbindungen zu den verschiedenen Systemen geschaffen.

Die MCPs dienen im Grunde nur dazu, um dann die Verbindung zu anderen Systemen aufzubauen. Genau dafür wurden sie ja auch mal geschaffen. Die Wahl fiel dabei für mich auf Portainer, weil es die Konfiguration so herrlich einfach macht. Aber es wäre auch vollständig auf meinem Rechner möglich.

Auch das Modell lässt sich austauschen. Aus Gründen der Einfachheit habe ich aber aktuell mal mit Codex gestartet. Hier ist kaum ein Aufwand für die Integration und Inbetriebnahme erforderlich. Stichwort: schnelles Ausprobieren.

Schauen wir mal im Detail auf die einzelnen Komponenten im Stack.

OpenCode

OpenCode ist ein Open-Source-Coding-Agent für die künstliche Intelligenz. Man bekommt es als terminalbasierte Schnittstelle, Desktop-App oder als IDE-Erweiterung. Letzteres ist wohl für die meisten nicht spannend, sofern sie nicht in der Softwareentwicklung aktiv sind. Am praktischsten ist die Desktop-App, wobei ich hin und wieder auch mal das Terminal bevorzuge. Das hat so einen herrlichen Nerd-Faktor aus meiner Sicht.

An die Software lassen sich verschiedene KI-Modelle anbinden. Schaut man sich die Liste in der offiziellen Dokumentation an, finden wir darin unter anderem Anthropic, Azure OpenAI, DeepSeek, Groq, GitHub Copilot, Llama, Ollama und OpenAI. Die Auswahl ist wirklich groß.

Dazu kommen noch die MCPs, die sich ebenfalls anbinden lassen. Im Grunde genommen sind hier keinerlei Grenzen gesetzt, weil sowohl lokale als auch remote gehostete MCPs unterstützt werden.

Meine Erfahrung bei über 2.000 Entitäten zeigt, dass OpenCode wirklich performant ist. Es gibt keine Aussetzer oder Probleme. Und bei meinem Waschmaschinen-Beispiel von unten wird inklusive Dokumentation als Markdown und Anpassung einer weiteren Automation auf rund 80.000 Tokens zurückgegriffen. Also tatsächlich überschaubar.

Den Download findest du entweder unter anomalyco/opencode auf GitHub oder direkt auf der offiziellen Website von OpenCode.

Home Assistant MCP

Der zweite wichtige Baustein in meinem Stack ist der MCP für Home Assistant. Den betreibe ich aktuell aus Gründen der Bequemlichkeit innerhalb eines Docker-Containers auf Portainer. Damit steht er allen Geräten im Heimnetzwerk zur Verfügung.

Obwohl das sehr praktisch ist, kann es auch gleichzeitig eine Sicherheitslücke sein. Denn über den MCP kann sich jeder im lokalen Netzwerk mit Home Assistant verbinden und so ziemlich alles tun, was deinem Benutzer erlaubt ist. Du musst nämlich einen Token hinterlegen, der entsprechende Berechtigungen hat. Optimaler wäre es, den MCP-Server lokal auf deinem Rechner zu betreiben.

Hier mal die vollständige Konfiguration, um einen eigenen MCP-Server in Docker in Betrieb zu nehmen:

services:
  ha-mcp:
    image: ghcr.io/homeassistant-ai/ha-mcp:latest
    command: ["ha-mcp-web"]
    environment:
      HOMEASSISTANT_URL: http://192.168.XXX.XXX:8123
      HOMEASSISTANT_TOKEN: ${HA_TOKEN}
    ports:
      - "8086:8086"
    restart: unless-stopped

Hier wird auch direkt ersichtlich, dass es sich bei dem MCP-Server um homeassistant-ai/ha-mcp handelt. Beschrieben wird das ganze Projekt übrigens auch sehr charmant wie ich finde mit folgendem Slogan:

The Unofficial and Awesome Home Assistant MCP Server

Und das trifft es sehr genau auf den Punkt. Denn darüber lässt sich eben nicht nur OpenCode anbinden, sondern auch n8n oder Claude Code. Im Grunde ist es das Eintrittstor für die KI in Home Assistant, um eben auch Automationen zu erstellen oder generell das System zu verwalten.

Übrigens musst du deinen Token für Home Assistant dann als Environment-Variable in Portainer unter dem Namen HA_TOKEN anlegen, wenn du den gleichen Weg gehen willst. Bitte nicht direkt in die Datei schreiben. Das ist definitiv kein sicherer Umgang mit Tokens.

Das KI-Modell

Die dritte wichtige Komponente habe ich ja nun schon oft erwähnt: Das KI-Modell.

Im Grunde kannst du hier andocken, was auch immer du willst. Viele Enthusiasten werden wahrscheinlich ein lokales Modell bevorzugen, um auch die Daten im eigenen Smart Home sicher zu halten. Das ist nicht nur clever, sondern im Grunde auch ein wichtiger Schachzug. Denn dein Smart Home speichert eben nun mal viele Informationen über dich, die sonst ungefiltert an die KI gehen können.

Ich persönlich habe mich im Grunde genommen nur aus dem Grund der Bequemlichkeit bislang dagegen entschieden. Für den Betrieb eines lokalen Sprachmodells fehlen mir ein paar Ressourcen und ich muss mich tiefer einarbeiten. Denn ob man es glaubt oder nicht … niemand kommt zu mir und denkt sich: Hier hast du mal nen ordentlichen Rechner für die KI. Mach was draus.

Sei es drum.

Im Moment nutze ich GPT-5.3 Codex von OpenAI für mein OpenCode und habe damit auch echt gute Erfahrungen gemacht. Das Ergebnis kann sich absolut sehen lassen und ist aus meiner Sicht mehr als faszinierend. Die Authentifizierung lief komplett über den Browser per OAuth2 und erfordert im Grunde nahezu keine Vorkenntnisse. Solange du eine Maus bedienen kannst, bekommst du das auf jeden Fall hin.

Wichtig zu wissen ist nur, dass du in diesem Fall besser ein Abo für ChatGPT Plus hast. Dann hast du ganz gute Limits mit denen sich auch arbeiten lässt. Ich bin in meinem Fall noch nicht an das Limit gestoßen und kann es daher bislang nur empfehlen.

Setup-Aufwand – ehrlich bewertet

Die nackte Wahrheit in Sachen OpenCode + MCP für Home Assistant ist, dass das Grundsetup mit allem drum und dran etwa 1 Stunde Zeit in Anspruch nimmt. Erst dann lief es bei mir wirklich fehlerfrei und ich konnte loslegen.

Mit dem Feinschliff von OpenCode und ersten Tests, wie sich das alles denn verhält, vergingen ein paar Tage. Aber ich habe natürlich auch keine 24 Stunden pro Tag damit verbracht. Oder viel mehr verbringen können. Denn meine Aufmerksamkeit hatte es ziemlich schnell.

Ein Vorwissen über die API von Home Assistant brauchst du dabei nicht. Es genügt wirklich, wenn du auf einem Windows-PC eine Software installieren kannst, etwas von Docker verstehst oder bereit dazu bist, mehr Zeit mit der Integration zu verbringen. Ich denke, dass jeder das hinbekommen kann, der auch die Installation von Home Assistant gemeistert hat. Viel schwerer wird es wohl kaum sein.

Ich habe zur Inbetriebnahme von meinem MCP die Datei opencode.json noch anlegen müssen. Die liegt jetzt bei mir unter C:\Users\Lukas\.config\opencode\opencode.json und hat den folgenden Aufbau:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "homeassistant": {
      "type": "remote",
      "url": "http://192.168.XXX.XXX:8086/mcp",
      "enabled": true
    }
  }
}

Der Port stammt dabei von der Konfiguration des Containers, welche du oben schon gesehen hast. Ebenso habe ich die IP-Adresse vom MCP-Server hinterlegt und nicht die von Home Assistant (ganz wichtig). Auch der Pfad /mcp ist wichtig. Sonst klappt die Verbindung zwischen OpenCode und MCP nicht, da nichts abgerufen werden kann.

Nachdem du die Datei aktualisiert oder angelegt hast, musst du OpenCode zudem neu starten. Erst dann werden die Änderungen wirksam.

Wenn alles klappt, siehst du nach kurzer Zeit oben unter Status einen verbundenen MCP. In meinem Fall heißt er homeassistant.

Der Praxistest: Wie gut ist das wirklich?

In den ersten Tagen habe ich viel damit herumgespielt. Ich selbst wusste auch noch nicht so ganz wohin die Reise gehen wird. Aber ich habe ziemlich schnell gemerkt, dass das gekommen ist um zu bleiben. Jedenfalls bei mir. Denn der Komfort und die Geschwindigkeit sind für mich atemberaubend.

Meine erste wirkliche Änderung an Home Assistant habe ich dann an einem regnerischen Samstag in Angriff genommen. Vor längerer Zeit habe ich die Idee aufgeschnappt, die Restlaufzeit der Waschmaschine in Home Assistant anzuzeigen. Ich meine das war bei Flotomation. Aber dieses Projekt habe ich immer wieder vor mir hergeschoben, weil es irgendwie nie die Priorität bekommen hat.

Ich habe also angefangen, die KI zu prompten. Nachfolgend mal ein verkürzter Einblick in unseren Dialog. Die Zwischenpassagen habe ich bewusst ausgelassen, weil die im Grunde genommen nur Verfeinerung waren und nicht besonders relevant erscheinen.

Starten wir mit meinem ersten Prompt:

Ich habe folgenden Gedanken: In meinem Home Assistant gibt es eine Entität, welche den Stromverbrauch der Waschmaschine ausliest. Basierend darauf wird dann eine Meldung ausgegeben, sobald sie fertig ist. Gibt es irgendeine Möglichkeit, um zum Beispiel auf Basis von historischen Daten zu berechnen, wie lange die Restlaufzeit noch sein wird? Das würde ich nämlich gerne dann in mein Dashboard einbauen

Finale Umsetzung durch die KI:

Ja — ist jetzt eingerichtet.  
Die Restlaufzeit startet bei jedem Waschmaschinen-Start neu und wird dann minütlich heruntergerechnet.
- Verwendete Lauf-Entität: binary_sensor.waschmaschine
- Angelegte Helfer:
  - input_datetime.waschmaschine_startzeit
  - input_number.waschmaschine_o_laufzeit (aktueller Lern-Durchschnitt, initial auf 175 min gesetzt)
  - input_number.waschmaschine_restlaufzeit (aktuelle Restlaufzeit in min)
- Angelegte Automationen:
  - automation.waschmaschine_restlaufzeit_start  
    - Trigger: off -> on  
    - setzt Startzeit + Restlaufzeit = Durchschnitt
  - automation.waschmaschine_restlaufzeit_aktualisierung  
    - Trigger: jede Minute  
    - solange Maschine läuft: Rest = max(Durchschnitt - verstrichene Zeit, 0)
  - automation.waschmaschine_restlaufzeit_lernen  
    - Trigger: on -> off  
    - lernt neue Ø-Laufzeit (gewichteter Mittelwert, alpha=0.2)  
    - ignoriert sehr kurze Läufe < 30 min als Fehltrigger  
    - setzt Restlaufzeit auf 0
Du kannst jetzt direkt input_number.waschmaschine_restlaufzeit ins Dashboard packen.  
Wenn du willst, baue ich dir als nächsten Schritt noch eine hübschere Anzeige (HH:MM + „voraussichtliches Ende um …“) als Template-Sensor dazu.

Erste KI-Automation

Wie du nun an diesem Beispiel sehen kannst, war die Umsetzung für die KI kein Problem. Aber es zeigt auch eine Sache, auf die man im Grunde immer etwas achten muss: Die Umsetzung.

Klingt paradox?

Die KI hat mir in meinem Fall drei Automationen und zwei Helfer erstellt. Mit den Helfern selbst bin ich soweit erstmal konform. Aber bei den Automationen stellte sich ziemlich schnell die Frage, warum es denn nun 3 Automationen sein müssen. Diese Frage habe ich auch der KI gestellt und sie hat es erläutert. Gemeinsam haben wir dann im Grunde festgelegt, dass auch zwei Automationen ausreichen würden.

Zu diesem Zeitpunkt waren alle Automationen und Helfer in Home Assistant schon angelegt.

Ich habe dann die KI angewiesen, dass sie doch bitte die Änderung übernehmen soll. Ich will runter auf zwei Automationen, da mir die dritte einfach nicht notwendig erscheint. Außerdem wollte ich keine Automation, welche jede Minute meine Waschmaschine prüft. Das kann man eleganter lösen.

Die KI hat dann die eine Automation gelöscht und die andere an meine Vorstellungen angepasst. Wir lauschen nun auf den Stromverbrauch und fragen nicht mehr jede Minute die Waschmaschine ab. Das ist auch an sich gar nicht notwendig, obwohl es durch die Leistung natürlich zu kleineren Ungenauigkeiten kommen kann. Die nehme ich aber bewusst in Kauf.

Hier mal die vollständige Automation für das Tracking der Restlaufzeit. Die komplette Automation wurde durch die KI erstellt. Ich habe nicht einen Buchstaben dafür getippt:

alias: Waschmaschine Restlaufzeit Tracking
description: >-
  Setzt beim Start die Startzeit und aktualisiert die Restlaufzeit bei jedem
  Leistungs-Update der Waschmaschine.
triggers:
  - id: start
    entity_id: binary_sensor.waschmaschine
    from: "off"
    to: "on"
    trigger: state
  - id: power_update
    entity_id: sensor.waschmaschine_leistung
    trigger: state
conditions: []
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ trigger.id == 'start' }}"
        sequence:
          - target:
              entity_id: input_datetime.waschmaschine_startzeit
            data:
              datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
            action: input_datetime.set_datetime
    default: []
  - condition: state
    entity_id: binary_sensor.waschmaschine
    state: "on"
  - variables:
      start_raw: "{{ states('input_datetime.waschmaschine_startzeit') }}"
      avg: "{{ states('input_number.waschmaschine_o_laufzeit') | float(175) }}"
      elapsed: >-
        {% if start_raw in ['unknown','unavailable',''] %}0{% else %}{{
        ((as_timestamp(now()) - as_timestamp(start_raw)) / 60) | float(0) }}{%
        endif %}
      remaining: "{{ [ (avg - elapsed) | round(0), 0 ] | max }}"
  - target:
      entity_id: input_number.waschmaschine_restlaufzeit
    data:
      value: "{{ remaining }}"
    action: input_number.set_value
mode: restart

Mein Learning aus der Automation

Klar, ich bin jetzt völlig fasziniert. Einerseits über den Kontext, den sich die KI behält und andererseits um die schnelle Umsetzung. Eine schnelle Umsetzung, die darüber hinaus auch noch sowas von präzise ist. Und das alles nur, weil die KI wiederum durch den MCP die Daten aus meinem Smart Home abfragen kann.

Der entscheidende Punkt für die nahezu perfekte Umsetzung war dann wohl folgender Prompt bevor ich das Endergebnis bekommen habe:

Kannst du mal für die Entität auslesen über deinen MCP, wie lange die Waschmaschine durchschnittlich braucht? Das müsste doch alles in den historischen Daten protokolliert sein

Mit der Antwort:

Ja — ich habe es direkt per MCP aus den Historien gezogen (binary_sensor.waschmaschine + sensor.waschmaschine_leistung).
- Zeitraum mit verfügbaren Daten: letzte ~30 Tage (in den Recorder-Daten sind nur wenige Läufe vorhanden)
- Erkannte on-Phasen von binary_sensor.waschmaschine:
  - 15.02. 10:10–13:24 (lokal): 3h 14m
  - 15.02. 13:28–16:02 (lokal): 2h 34m
  - 18.02. 21:50–21:52: 2m 08s (sehr wahrscheinlich Messrauschen/False Positive)
  - 21.02. 05:20–05:22: 2m 08s (sehr wahrscheinlich Messrauschen/False Positive)
Damit ergibt sich:
- Durchschnitt ohne Filter (alle 4): ~88 min
- Durchschnitt nur echte Läufe (>= 30 min): ~174 min = 2h 54m
Für deine Restlaufzeit im Dashboard würde ich daher aktuell mit ca. 175 min starten (und kurze Läufe < 10/20/30 min beim Lernen ignorieren).
Wenn du willst, setze ich dir als Nächstes die Logik so auf, dass dieser Durchschnitt automatisch nach jedem validen Waschgang aktualisiert wird.

Ein weiteres Learning war definitiv wieder, dass die Umsetzung der KI zwar an sich funktionieren sollte. Aber ich muss als der Verantwortliche trotzdem einen Blick darauf haben. Denn einerseits arbeitet die KI direkt in meinem System, das mir so wichtig ist. Und sie wählt möglicherweise auch nicht immer den perfekten Weg. Sehen konnte man das daran, dass sie ursprünglich 3 Automationen vorgesehen hat.

Es geht also inzwischen nicht mehr wirklich darum, dass man selbst Automationen erstellt. Man braucht ein Verständnis und vielleicht auch Gespür für die Architektur, die dahinter steckt. Denn warum braucht es am Ende 3 Automationen, wenn auch 2 ausreichen?

Genau hier trennen sich dann die Wege von jenen, die KI einfach nur einsetzen, und den anderen, die eine Architektur verstehen und überblicken. Ich persönlich bevorzuge es bei der zweiten Gruppe zu sein.

Sicherheit: Nicht ignorieren

Der wohl wichtigste Punkt in diesem ganzen Stack ist nun nicht, dass die KI so vieles weiß und eigentlich auch bald alle Menschen bei der Arbeit ablösen soll. Es geht viel mehr um Sicherheit und die Kontrolle über deine Daten.

In meinem Setup zum Beispiel gibt es drei ganz gezielte Faktoren, welche die Sicherheit in meinem Smart Home maßgeblich beeinflussen können:

• Vollzugriff auf Home Assistant
• externe KI
• MCP auf Portainer

Auch hier zeigt sich nun wieder, dass man die Architektur verstehen muss und nicht einfach nur blind einem Ratgeber vertrauen sollte. Genau das solltest auch du nicht tun. Obwohl ich es mit dir wirklich nicht böse meine. Andernfalls würde ich dich ja nicht noch auf die Gefahren aufmerksam machen … denke ich 😉

Schauen wir nun also noch die einzelnen Gefahrenstellen an, die sich in diesem Setup bei mir ergeben. Ich versuche es dir so nahe wie möglich zu bringen, damit du auch meine Sichtweise gut nachvollziehen kannst.

Vollzugriff auf Home Assistant

Mitunter eine der größten Gefahren lauert direkt in der Einbindung mit dem MCP-Server. Über ihn bekommt die KI einen Vollzugriff auf all das, was auch dein Benutzer im System machen kann. Das bedeutet konkret:

• sie kann alle Daten auslesen
• sie kann Daten verändern
• sie kann dein System verwalten (inklusive Installationen)
• sie könnte schädliche Dinge injizieren

Dir muss einfach klar sein: Die KI kann all das tun, was du auch kannst. Im Zweifel eben auch dein System beschädigen, Daten löschen oder Automationen einfach aus dem Verkehr ziehen.

Auch wenn ich dazu aktuell nicht die passende Lösung habe, hilft es beim Prompten aufmerksam zu sein. Vor allem hilfreich ist es, wenn du der KI direkt klar machst (nicht wie ich), dass sie Änderungen erst durch dich bestätigen lassen soll, bevor sie umgesetzt werden. Das ist zwar keine absolute Sicherheit, nimmt aber schon einen Teil des Drucks raus.

Zudem solltest du natürlich in deinem Home Assistant auch im Nachgang checken, was sie genau verändert hat. Im Zweifel lässt sich ein Home Assistant Backup einspielen und damit auch wieder alles retten.

Eine weitere Möglichkeit wäre es, wenn du den MCP einschränkst. Also praktisch eine Implementierung zu nutzen, welche nicht alle Möglichkeiten weitergibt. Meines Wissens kannst du das sogar in der Konfiguration von OpenCode machen und dort nur das erlauben, was die KI wirklich können soll. Mit diesen Mechanismen lohnt es sich auf jeden Fall zu experimentieren.

Faktor externe KI

Ein weiteres Risiko besteht darin, dass ich in meinem Setup eine externe KI nutze. Das bedeutet konkret, dass alle Daten nicht auf meinen Geräten verarbeitet werden, sobald die KI zum Einsatz kommt. Es ist weniger ein Risiko in Sachen „was tut sie da“, sondern eher eine Frage des Datenschutzes.

Dir muss an dieser Stelle einfach klar sein, dass Daten von Sensoren und Geräten komplett in die Hände eines Anbieters gegeben werden. Ob sie damit viel anfangen wollen, ist eine andere Frage. Aber das liegt eben auch nicht mehr in unserem Machtbereich.

Die logische Konsequenz wäre an dieser Stelle demnach, dass man ein lokales Modell nutzt. Ein Modell, welches nicht auf fremden Servern läuft, sondern auf deiner eigenen Infrastruktur. Hier lohnt sich ein Blick auf Ollama, womit das möglich wird.

Gleichzeitig ist ein lokales Modell aber vielleicht nicht so leistungsstark oder präzise wie ein namhafter Anbieter. Da muss man sich ein wenig ausprobieren und für sich selbst die beste Lösung finden. Ich bin aber fest davon überzeugt, dass auch hier noch wesentlich größere Sprünge zu erwarten sind. Der heutige Stand muss einfach nicht der Stand von nächster Woche sein.

MCP auf Portainer

Mein dritter Faktor ist der MCP-Server auf Portainer im Homelab. Das ist an sich erstmal kein großes Problem, kann aber auch zu ungewollten Effekten führen. Denn der MCP-Server ist nicht mit einer Authentifizierung gesichert und kann von jeder Person genutzt werden, die Zugriff auf dein Heimnetzwerk hat.

Da im MCP-Server auch gleichzeitig der Token von Home Assistant liegt, muss man sich nicht mal gegenüber diesem System authentifizieren, sondern kann direkt loslegen. Es ist also absolut wichtig, dass dein Heimnetzwerk abgesichert ist und du nur den Personen und Geräten Zugang gewährst, die auch wirklich einen Zugriff darauf brauchen.

Die bessere Alternative wäre ein MCP-Server, welcher nur auf dem jeweiligen Computer läuft, wo auch OpenCode verwendet wird. Das gibt dir zwar auch nie eine absolute Sicherheit, schließt aber schon einen Teil der potenziellen Gefahren aus.

Ich selbst habe – wie schon gesagt – diesen Weg bisher nur aus Bequemlichkeit gewählt. Das bedeutet aber nicht, dass ich es nicht noch ändern werde. Es war bislang einfach der wesentlich schnellere Weg, um an Ergebnisse zu kommen. Und schlussendlich hätte es auch sein können, dass die Lösung für mich nicht funktioniert und ich dieses Projekt wieder sein lasse.

Aber Pustekuchen. Mein Workflow bleibt so bestehen. Also muss ich da nochmal ran, um mehr Sicherheit zu schaffen.

Fazit: Hype oder Fortschritt?

Stellen wir uns nun zuletzt noch die Frage, ob wir hier einem Hype folgen oder doch eher wahren Fortschritt betrachten. Ich glaube, es ist ein Mix aus beidem.

Einerseits ist die KI gerade voll angesagt und das geht auch an mir nicht spurlos vorbei. Mich faszinieren die Möglichkeiten und ich tauche gerade durch die MCPs noch weiter ins Thema ein. Wahrer Fortschritt ist es aber auch, denn es verändert das Smart Home wie wir es bisher kennen.

Ich kenne all die Nachrichten in Foren und in Blogs, wo um Hilfe bei Automationen gebeten wird. Gerade YAML ist einfach nicht so easy, wie man es vielleicht denken mag. Und auch die Automationen selbst haben immer eine gewisse Komplexität, die notwendig ist und in der Natur der Sache liegt.

Mit dem Einsatz von KI – gerade in Home Assistant – kann man diesen Faktor aber ausgleichen. Denn es gibt nichts natürlicheres als in der Sprache die Dinge zu erklären, die man auch selbst jeden Tag spricht. Aber gleichzeitig gilt hier, dass man sehr präzise formulieren muss. Je präziser man eine Anforderung beschreibt, desto besser kann sie umgesetzt werden.

Wir bewegen uns also in meinen Augen ein Stück weit in die Richtung, dass es nicht mehr um 1:1 Umsetzung geht. Viel mehr müssen wir unsere sprachlichen Kenntnisse auf ein anderes Level bringen und unsere Synapsen in Logik schulen. Denn präzise formulieren, ohne Missverständnisse, ist gar nicht so einfach. Das merkt man schnell, wenn die ersten Missverständnisse mit der KI aufkommen.

Und wer weiß. Vielleicht werden wir schon in 2 Jahren ein Smart Home haben, welches nicht mehr durch uns mit Automationen gefüttert werden muss. Stattdessen sitzen wir mit unserem Smartphone auf dem Sofa und halten unsere Wünsche in einer Sprachnachricht fest, die direkt an unseren Agenten geht. Denn auch das ist möglich.

Als kleiner Spoiler zum Schluss: Ich habe mit in Kombination mit n8n einen Agenten gebaut. Ihm kann ich schreiben oder eine Sprachnachricht senden, dass er eine neue Automation in Home Assistant bauen soll. Zwar muss ich auch hier noch sehr präzise sein, aber die Ergebnisse sind spannend!

Stay tuned …