n8n mit Home Assistant: Der erste Workflow liest nur mit

Was n8n und Home Assistant jeweils übernehmen

Home Assistant stellt Entitäten, Zustände und Aktionen für die angebundenen Integrationen bereit. n8n verbindet Daten mit weiteren Verarbeitungsschritten oder Diensten. Ein zusätzlicher Workflow lohnt sich, wenn du einen konkreten Übergang brauchst – etwa einen ausgewählten Status für eine eigene Auswertung. Eine einfache vorhandene Hausautomation muss dafür nicht neu gebaut werden.

Der n8n-Node bietet unter anderem State, Service und weitere Ressourcen. Darunter liegen unterschiedliche Operationen. Ein Zustand wird gelesen, ein Datensatz kann verändert oder ein Dienst aufgerufen werden. Diese Unterschiede sind entscheidend, sobald ein Workflow mehr tun soll als anzeigen.

Für diesen Artikel wurde keine Verbindung zu einem realen Zuhause hergestellt. Es wurde kein Token angelegt und kein Gerät bedient. Die Anleitung und Vorlage wurden mit dem aktuellen Nodecode und den Originalreferenzen abgeglichen; ein tatsächlicher Import- oder Verbindungstest steht für deine eigene Umgebung aus.

Verbindung und Zugangsdaten vorbereiten

Du brauchst eine funktionierende eigene Home-Assistant-Instanz, einen dafür vorgesehenen Nutzerzugang und eine n8n-Instanz, die sie erreichen kann. Prüfe die Adresse aus Sicht von n8n. Ein Container, ein anderer Rechner und ein Cloudworkflow haben nicht automatisch denselben Netzwerkzugriff wie dein Browser zu Hause.

Die offizielle n8n-Anleitung verwendet ein Long-Lived Access Token aus dem Home-Assistant-Nutzerprofil. Erzeuge es nur für einen bewusst freigegebenen Zugang und hinterlege es im passenden Home-Assistant-Credential. Ein lesender Node macht das Token selbst nicht automatisch zu einem ausschließlich lesenden Zugang; die tatsächlichen Berechtigungen musst du gesondert prüfen.

Übernimm keine Portnummer aus einer fremden Installation, wenn dein Zugang anders eingerichtet ist. Gib einen Heimdienst nicht nur für diese Probe ungeschützt im Internet frei. Die Anleitung Zugangsdaten in n8n hinterlegen erklärt Zuordnung und kontrollierten Test, ohne Token in einen Node-Text oder eine exportierte Vorlage zu schreiben.

Der erste Workflow liest nur einen Zustand

Die lesende JSON-Importvorlage herunterladen. Sie enthält genau zwei Nodes: einen manuellen Start und einen Home-Assistant-Node der dokumentierten Version 1. Es sind keine Credential-IDs, Token, privaten Adressen, Webhooks oder Zeitpläne enthalten. Der Workflow ist als inaktiv gespeichert.

1. Importiere die Datei in einen eigenen Übungsworkflow und sieh dir beide Nodes vor einem Start an.
2. Öffne „Zustand lesen“ und wähle dein zuvor eingerichtetes Home-Assistant-Credential.
3. Kontrolliere Resource: State und Operation: Get.
4. Die Vorlage nennt sun.sun als Beispiel. Verwende nur eine Entität, die es in deiner Instanz gibt und deren Status du bewusst lesen möchtest.
5. Starte die Probe manuell und öffne die Nodeausgabe. Es folgt kein weiterer Verarbeitungsschritt.

resource: state
operation: get
entityId: sun.sun

Start: ausschließlich manuell
Folgeschritt: keiner
Zugang: nach dem Import im eigenen Credential auswählen

Der aktuelle Nodecode verwendet für diese Operation einen GET-Aufruf auf den Zustandspfad der gewählten Entität. Fehlt die Beispielentität, ist ein 404 nicht gleich ein kaputter Token. Wechsle nicht zur Schreiboperation „Create or Update“, um eine fehlende Entität für die Leseprobe künstlich anzulegen.

Ausgabe, fehlende Werte und Fehler prüfen

Vergleiche entity_id und state mit der erwarteten Entität in deiner eigenen Oberfläche. Der folgende Ausschnitt ist konstruiert und wurde nicht aus einer realen Instanz abgerufen:

{
  "entity_id": "sun.sun",
  "state": "below_horizon",
  "attributes": {
    "friendly_name": "Sonne"
  }
}

Für eine spätere Werteauswahl kann {{ $json.state }} auf ein direkt auf der obersten Ebene liegendes Feld zeigen. Liegt die tatsächliche Ausgabe anders, muss der Datenpfad angepasst werden. Der Guide n8n-Expressions und Datenfelder prüfen zeigt, wie du von der echten Eingabe zum passenden Ausdruck kommst.

Ein erfolgreicher Credential-Test beweist nicht jede spätere Operation. Ebenso beweist eine Antwort im JSON-Format nicht, dass sie von der erwarteten Instanz stammt. Prüfe Inhalt und Zuordnung, bevor du weitere Schritte anhängst.

Zustand setzen ist nicht Gerät schalten

Die Home-Assistant-REST-Referenz trennt dies ausdrücklich: POST /api/states/<entity_id> verändert den angezeigten Zustand. Der Aufruf spricht das Gerät nicht direkt an; eine spätere Aktualisierung der Entität kann den Wert überschreiben. Ein Gerätebefehl läuft über die passende Aktion beziehungsweise den Servicepfad.

Im n8n-Node ist deshalb State → Create or Update nicht mit Service → Call gleichzusetzen. Benutze keinen Zustands-Upsert als vermeintlichen Ersatz für einen nicht funktionierenden Schaltbefehl. Du könntest sonst eine Anzeige verändern, ohne den erwarteten realen Zustand herzustellen.

Für einen späteren Aktionsworkflow brauchst du ein eigenes Konzept: erlaubte Entitäten und Aktionen, feste Parametergrenzen, verständliche Prüfung vor der Wirkung sowie Verhalten bei Fehlern und Wiederholungen. Das ist ein separater Aufbau. Die hier angebotene Vorlage bleibt beim lesenden Pfad.

Eine spätere, bewusst gestartete Lampenprobe

Wenn der lesende Aufbau funktioniert und du eine eigene Testlampe ausdrücklich schalten möchtest, lege dafür einen separaten Übungsworkflow an. Der dokumentierte Weg ist Resource: Service und Operation: Call. Wähle die Domain light, den Service turn_on und als Serviceattribut entity_id die tatsächliche ID dieser einen Testlampe. Prüfe Ziel und Attribute vor dem manuellen Start und kontrolliere anschließend die reale Lampe sowie ihren gemeldeten Zustand.

Home Assistants REST-Referenz zeigt diesen Aufruf unter /api/services/light/turn_on; der n8n-Node bildet Domain, Service und Attribute auf den passenden Anfragekörper ab. Die ID light.kitchen aus der Herstellerdokumentation ist ein Beispiel, keine automatisch vorhandene Entität. Lasse eine KI weder Zielentität noch Service frei aus einer Textantwort übernehmen. Ein weiterer Aufruf darf erst folgen, wenn sein konkreter Zweck und seine Wirkung verstanden sind.

Wo KI helfen kann – und wo feste Regeln genügen

Ein Sprachmodell kann ausgewählte Statusangaben in einen lesbaren Entwurf umformulieren. Berechnungen, feste Vergleiche und erlaubte Aktionen sollten dadurch nicht in eine offene sprachliche Entscheidung ausgelagert werden. Für den ersten Statusabruf wird keine KI benötigt. Für einen eigenen Textchat statt dieses Automationsabrufs zeigt Ollama in Home Assistant den Einstieg ohne sofortige Gerätesteuerung.

Wenn du später eine Zusammenfassung ergänzt, übergib nur die dafür nötigen Werte. Prüfe, ob der Text Entitäten, Zeitpunkte oder Zustände erfindet. Ein lokales Modell ändert den Ort der Berechnung, garantiert aber keine richtige Interpretation und keine zulässige Aktion. Eine zusätzliche Wahrscheinlichkeitsrechnung beseitigt dieses Problem nicht automatisch.

Die Lektion KI-Workflows mit Freigabepunkten aufbauen hilft, Entwurf und Außenwirkung voneinander zu trennen. Bei späteren Geräteeingriffen muss die technische Freigabe zu den konkret geprüften Parametern passen. Beginne bis dahin mit der nachvollziehbaren Leseprobe.