Home Assistant: Architektur, Datenmodell und Betrieb

Home Assistant ist eine zentrale Steuerungs- und Automationsplattform für Geräte, Funknetze, IP-Dienste und Benutzeroberflächen. Die Instanz sammelt Zustände über Integrationen, normalisiert sie zu Entitäten, verteilt Änderungen über einen Event Bus und führt daraus Aktionen aus. «Lokal» bezeichnet dabei eine Architekturpräferenz, keine pauschale Eigenschaft jeder Integration: Ein Zigbee-Leuchtmittel kann vollständig lokal erreichbar sein, während eine Herstellerintegration ihre Zustände ausschliesslich aus einer Cloud-API bezieht. Die offizielle Architekturübersicht trennt Betriebssystem, Supervisor und Core; die Integrationsarchitektur beschreibt die Erweiterung des Core durch Python-Komponenten.

Für Admins ist Home Assistant deshalb weder bloss ein Dashboard noch ein universeller Protokollkonverter. Es ist ein zustandsbehafteter Orchestrator mit mehreren möglichen Ausfallstellen: Python-Laufzeit, Integrationen, Registries, Datenbank, Authentisierung, lokale Netze, Funkcontroller, Broker, Hersteller-Clouds und gegebenenfalls Supervisor-Apps. Eine grüne Oberfläche beweist nur, dass der Frontendpfad funktioniert. Sie beweist nicht, dass Ereignisse rechtzeitig eintreffen, Geräte erreichbar sind, Automationen deterministisch laufen oder ein Backup einschliesslich externer Abhängigkeiten wiederherstellbar ist.

Die Erklärung folgt einem Geräteereignis über Integration, Event Bus und State Machine bis zu Automation und Aktion. Danach werden Persistenz, Add-ons, Sicherheit, Monitoring und Wiederherstellung eingeordnet.

Architekturansatz: zentraler Event- und Zustandsknoten

Home Assistant Core ist ereignisgetrieben. Vier dokumentierte Bausteine bilden den Kern (Core architecture):

1. Der Event Bus verteilt Ereignisse an registrierte Listener.
2. Die State Machine hält den letzten bekannten Zustand jeder geladenen Entität und publiziert state_changed.
3. Die Service Registry verwaltet aufrufbare Aktionen und verarbeitet Serviceaufrufe.
4. Der Timer erzeugt Zeitereignisse für zeitabhängige Verarbeitung.

Integrationen übersetzen Geräte- oder Dienstzustände in dieses Modell. Eine Integration kann pollen, Push-Ereignisse empfangen, lokale Bibliotheken verwenden oder eine entfernte API ansprechen. Home Assistant vereinheitlicht den resultierenden Zustand, nicht den Transport. Das ist die wichtigste Betriebsgrenze: Zwei Entitäten mit identischem Domänentyp, etwa light, können vollkommen unterschiedliche Latenz-, Authentisierungs- und Recoverypfade besitzen.

Laufzeitschichten und Installationsmodelle

Home Assistant bietet zwei unterstützte Installationsmodelle. Home Assistant OS ist eine verwaltete Appliance. Home Assistant Container führt Home Assistant Core als Container auf einem vom Betreiber verantworteten Host aus. Die offizielle Gegenüberstellung nennt HAOS als Empfehlung für fast alle Installationen und beschreibt Container als eigenständige Core-Installation ohne Supervisor-Apps (HAOS oder Container).

Home Assistant OS

HAOS wird mit Buildroot erzeugt und besteht aus Linux, GNU C Library, systemd und Docker. SquashFS trägt die schreibgeschützten Systembereiche, ZRAM temporäre Dateisysteme und Swap, AppArmor begrenzt Prozesse, und RAUC aktualisiert das Betriebssystem (Home Assistant Operating System). Darüber verwaltet der Supervisor Core, Apps, DNS, Audio, mDNS, Backups und Updates (Supervisor).

Das Appliance-Modell reduziert Varianten, überträgt dem Supervisor aber weitreichende Verantwortung. Ein Fehler kann auf mindestens fünf Ebenen liegen: Boot-/OS-Slot, Docker Engine, Supervisor, Core-Container oder einzelne App. Der Supervisor kann einen fehlgeschlagenen Core-Updatepfad zurückrollen; ein fachlich fehlerhaftes Geräte- oder Datenbankverhalten erkennt dieser Mechanismus nicht automatisch.

Home Assistant Container

Container stellt nur den Core bereit. Hostbetriebssystem, Container Engine, Netzwerk, Volumes, Datenbank, Broker, Radio-Server, Reverse Proxy, Sicherung und Updates gehören dem Betreiber. Apps des Supervisor sind separat paketierte Dienste. In einem Container-Design werden Mosquitto, Matter Server, Zigbee2MQTT, Z-Wave JS UI, PostgreSQL oder ein Reverse Proxy als eigene Workloads mit eigenen Volumes, Versionen und Healthchecks betrieben.

Der Vorteil ist eine explizite Plattformarchitektur; der Preis ist eine grössere Betriebsfläche. Ein Backup des Core-Volumes enthält beispielsweise weder die externe Recorder-Datenbank noch Brokerzustand, Radio-NVM oder Reverse-Proxy-Schlüssel, sofern diese ausserhalb liegen.

Historische Installationsformen

Die frühere Core-Installation in einer Python-Umgebung und die Supervised-Installation auf einem selbst verwalteten Linux wurden 2025 abgekündigt. Seit Release 2025.12 gelten sie als nicht unterstützt; 32-Bit-Architekturen i386, armhf und armv7 verloren gleichzeitig den Releasepfad. Die Projektankündigung nennt HAOS und Container als verbleibende Modelle (Abkündigung von Core und Supervised). Ein historischer Installationsname darf daher nicht mit der Softwarekomponente Home Assistant Core verwechselt werden, die auch innerhalb von HAOS und Container weiterläuft.

Technologiestack

Home Assistant Core ist eine Python-Anwendung unter Apache-2.0-Lizenz. Das offizielle Core-Repository zeigt Python, asyncio und die modulare Integrationsstruktur. I/O-lastige Integrationen sollen nicht blockieren: Die Qualitätsregeln bevorzugen asynchrone Abhängigkeiten, damit Netzwerk- und Geräteaufrufe den gemeinsamen Event Loop nicht aufhalten (async dependency). Blockierender Bibliothekscode wird in Executor-Threads ausgelagert; CPU-intensive oder schlecht begrenzte Arbeit bleibt dennoch eine Kapazitäts- und Latenzgefahr.

Der sichtbare Stack umfasst mehr als Python:

Die Integration Quality Scale bewertet Integrationen nach Konfigurationsfluss, Tests, Typisierung, Diagnose, effizienter Datennutzung und asynchronem Verhalten. Eine hohe Stufe verbessert die erwartbare Wartbarkeit, ist aber kein Verfügbarkeits-SLA für das dahinterliegende Gerät oder den Cloudanbieter.

Nach Installationsmodell und Laufzeit folgt das Datenmodell. Nur wenn Config Entry, Gerät, Entität und Zustand auseinandergehalten werden, lassen sich doppelte Entitäten, fehlende Geräte und fehlerhafte Automationen sauber erklären.

Objektmodell: Config Entry, Gerät, Entität und Zustand

Der betriebliche Inventarschlüssel ist nicht die sichtbare Kachel, sondern die Kette aus Konfiguration, Geräteidentität und Entität.

Config Entries

Ein Config Entry speichert die persistente Konfiguration einer Integrationsinstanz. Ein UI-Konfigurationsfluss erzeugt ihn; Optionen, Reconfigure, Reload, Unload, Removal und Migration sind definierte Lebenszyklusoperationen. Integrationen dürfen Entry-Daten nicht direkt mutieren, sondern müssen den Config-Entry-Manager verwenden (Config entries). Ein Authentisierungsfehler, ein nicht geladener Entry und eine unerreichbare Gegenstelle sind deshalb unterschiedliche Zustände.

Geräte und Registries

Die Device Registry gruppiert technische Endpunkte zu Geräten. Identifiers oder Connections, beispielsweise Seriennummer und MAC-Adresse, dienen dem Matching; via_device kann eine Bridge- oder Elternbeziehung abbilden (Device registry). Ein Zigbee-Sensor kann so über einen Coordinator als verbundenes Gerät erscheinen, ohne dass der Coordinator sein Anwendungszustand ist.

Die Entity Registry gibt Entitäten mit unique_id eine dauerhafte Identität und verhindert kollidierende Entity IDs. IP-Adresse, Hostname, URL, Benutzername oder E-Mail-Adresse gelten ausdrücklich nicht als stabile Unique IDs (Entity registry). Das erklärt, weshalb das manuelle Umbenennen eines Hosts die Geräteidentität nicht ersetzen darf und weshalb Integrationsmigrationen stabile Herstellerkennungen benötigen.

Entität und Zustand

Eine Entität repräsentiert eine Funktion oder Messgrösse: sensor, switch, light, climate, binary_sensor oder eine andere Domäne. Ihr Zustand besteht aus einem primären State, Attributen, Änderungszeiten und Context. Die State Machine hält nur den letzten bekannten Zustand. unavailable bedeutet, dass die Entität derzeit nicht durch ein aktives Entity-Objekt versorgt wird; unknown bedeutet, dass kein verwendbarer Wert vorliegt. «Letzter Wert» ist damit nicht automatisch «frischer Messwert».

Die dokumentierte Interaktion von Geräten und Services trennt Entity Integration, Entity Component, Entity Platform und herstellerspezifische Integration. Für die Diagnose wird daher immer gefragt:

• Welcher Config Entry besitzt die Entität?
• Über welche Integration und Plattform entsteht sie?
• Welche stabile Geräte- und Entity-ID verbindet Historie und Konfiguration?
• Wird gepollt oder gepusht?
• Welches Zeit- und Verfügbarkeitsmodell besitzt der Quellwert?
• Welche Bridge, Bibliothek, Cloud-API oder Funkstrecke liegt davor?

Integrationen und Fehlerisolation

Eine Integration definiert eine Domäne und kann Plattformen wie sensor, light oder switch bereitstellen. Die Plattform abstrahiert den Entitätstyp; die Geräteintegration spricht das konkrete Protokoll. Eingebaute Integrationen werden mit dem Core ausgeliefert und durch dessen Releaseprozess getestet. Custom Integrations laufen jedoch im selben Python-Prozess und können Imports, Event Loop, Startzeit oder Speicherverbrauch beeinflussen. Das Verzeichnis /config/custom_components ist deshalb Teil von Inventar, Change-Management und Recovery.

Die offizielle Integrationsübersicht unterscheidet unter anderem IoT-Klassen wie Local Push, Local Polling, Cloud Push und Cloud Polling. Diese Klassifikation ist für Betriebsmodelle nützlicher als eine lange Herstellerliste:

Die Integration ist kein Prozess-Isolator. Eine saubere Fehlereingrenzung deaktiviert oder reloadet gezielt den betroffenen Config Entry, bevor der gesamte Core neu gestartet wird. Ein Neustart vernichtet flüchtige Evidenz und kann zeitabhängige Automationstimer zurücksetzen.

Protokoll- und Netzmodell

Für Home Assistant ist ein Abhängigkeitsgraph hilfreicher als eine pauschale OSI-Tabelle. Die Plattform sitzt auf Anwendungsebene, aber ihre Datenpfade verzweigen:

• Frontend, REST und WebSocket laufen über HTTP auf TCP, standardmässig Port 8123.
• DNS löst Host- und Clouddienste auf; mDNS und SSDP entdecken Geräte im lokalen Netz.
• MQTT verwendet einen separaten Broker und ein Publish/Subscribe-Modell über TCP oder WebSocket.
• Zigbee, Z-Wave, Thread und Bluetooth benötigen Funkcontroller oder Netzwerk-Proxies.
• Matter verwendet IP-Kommunikation, benötigt für Provisionierung und Fabric-Betrieb aber einen Matter-Server und gegebenenfalls Thread Border Router.
• Herstellerintegrationen können HTTPS, proprietäre lokale Protokolle oder Cloudstreams verwenden.

Die eingebauten Discovery-Integrationen dokumentieren mDNS/Zeroconf und SSDP. Beide sind segment- und multicastabhängig. Ein Reverse Proxy für das Frontend repariert keine Discovery über VLAN-Grenzen. Multicast-Relay, IGMP-Snooping, WLAN-Client-Isolation, IPv6-RA, DNS-Suffixe und Firewallregeln werden pro tatsächlichem Gerätepfad geprüft.

MQTT als eigener Zustandsraum

MQTT ist nicht der interne Event Bus. Es ist ein externer Brokerdienst, mit dem eine Integration kommuniziert. Die offizielle MQTT-Integration beschreibt Discovery Topics, retained messages, Birth/Last Will, Availability, TLS und MQTT 5. Retained Discovery kann Geräte nach Neustart wieder erzeugen, kann aber auch veraltete Ghost Entities konservieren. Verfügbarkeit benötigt eine eigene Semantik; ein vorhandener retained State beweist nicht, dass der Publisher noch lebt.

Ein belastbarer MQTT-Betrieb inventarisiert Broker, Client IDs, Authentisierung, CA, Topics, QoS, Retain, Expiry, Birth/Will und Discovery-Origin. Brokerbackup und Corebackup sind getrennte Schutzobjekte.

Funk- und Bridgepfade

ZHA integriert einen Zigbee-Coordinator, Z-Wave JS verwendet einen separaten Z-Wave-JS-Server, und Matter bindet einen Matter-Server an. Thread verwaltet Border-Router- und Netzwerkbezüge, ist aber nicht identisch mit Matter. Funkgeräte, Controller-Firmware, Netzwerkdaten, Schlüsselmaterial und Gerätekonfiguration bilden jeweils einen Recoveryverbund. Das Verschieben eines USB-Sticks oder Ersetzen eines Coordinators ist keine gewöhnliche IP-Adressänderung.

Integrationen liefern Zustände und Ereignisse; Automationen reagieren darauf. Ihr Ablauf aus Trigger, Bedingungen und Aktionen muss deshalb getrennt von der Gerätekonfiguration diagnostiziert werden.

Automationslaufzeit: Trigger, Condition, Action

Eine Automation ist eine reaktive Ausführungsdefinition. Die Automationsgrundlagen trennen Trigger, optionale Conditions und Actions. Der Trigger erzeugt einen Lauf, Conditions prüfen den Eintrittszustand, Actions verwenden die Sequenzsemantik der Scripts (Actions).

Wichtig ist der Zeitpunkt: State, Attribute und Templatewerte können sich zwischen Trigger und späterer Action ändern. Ein Delay hält keine Transaktion offen. Mehrere Ausführungen derselben Automation benötigen deshalb einen Modus wie Single, Restart, Queued oder Parallel und ein bewusstes Konfliktmodell. Physische Aktoren sind selten transaktional; ein teilweise ausgeführter Lauf braucht gegebenenfalls Kompensationsaktionen.

Die Trigger-Dokumentation weist darauf hin, dass for-Wartezeiten einen Neustart oder Automation-Reload nicht überleben. Wer eine Frist über Neustarts erhalten muss, persistiert einen Zeitpunkt, beispielsweise in input_datetime, und löst gegen diesen aus. Conditions sind nur Prüfungen im aktuellen Lauf; die Condition-Semantik macht aus ihnen keine Sperre gegen parallele Änderungen.

Templates werden in Home Assistant mit Jinja-Ausdrücken ausgewertet. Eingangs- und Typfehler, unknown, unavailable, Zeitzonen und implizite Stringkonvertierung gehören in Tests. Die Templating-Dokumentation beschreibt triggerabhängige Variablen. Ein Admin testet nicht nur den Happy Path, sondern Neustart, fehlende Entität, verspätetes Event, doppelten Trigger und Aktorfehler.

Konfiguration, Registries und Source of Truth

Home Assistant kombiniert UI-geführte Config Entries, Registrydaten und YAML. configuration.yaml ist die Wurzel manueller Konfiguration, aber nicht die vollständige Source of Truth. Die offizielle Konfigurationsübersicht unterscheidet UI und YAML; Packages können zusammengehörige YAML-Blöcke strukturieren (Packages).

Für Git und Review eignet sich nur der textuelle, geheimnisbereinigte Anteil. secrets.yaml trennt Werte aus YAML, verschlüsselt sie aber nicht; darauf weist die Härtungsanleitung ausdrücklich hin. UI-Zustand, Registries, Tokens und Config Entries liegen im Konfigurationsspeicher und werden über unterstützte UI-/API-Wege verändert. Direktes Editieren interner Storage-Dateien bei laufendem Core umgeht Schema-, Lebenszyklus- und Konsistenzlogik.

Ein Konfigurationsinventar umfasst:

• YAML, Packages, Blueprints und Custom Components,
• Config Entries samt Herkunft, Owner und Authentisierung,
• Device-, Entity- und Area-Zuordnungen,
• Automationen, Scripts, Szenen und Dashboards,
• Benutzer, Tokens, MFA und externe Identity Provider,
• Supervisor-Apps oder externe Dienste,
• Funkcontroller, Broker, Datenbank und Proxy,
• Secrets, Zertifikate und Recoveryschlüssel.

Recorder, Historie und Langzeitstatistik

Die State Machine hält den aktuellen Zustand im Speicher. Historie entsteht erst durch den Recorder. Er schreibt Zustandsänderungen und ausgewählte Events per SQLAlchemy in eine Datenbank; History, Activity, Diagramme und Langzeitstatistiken lesen daraus. Die offizielle Recorder-Dokumentation nennt SQLite als Standard und Empfehlung sowie MariaDB, MySQL und PostgreSQL als unterstützte Alternativen.

Recorderdaten sind keine Ereignisquelle für die Echtzeitsteuerung. Eine ausgefallene Datenbank kann Historie und Statistik beeinträchtigen, während aktuelle Zustände und Automationen teilweise weiterlaufen. Umgekehrt beweist eine vollständige Historie nicht, dass eine Action am physischen Gerät erfolgreich war.

Die wichtigsten Betriebsparameter sind:

• purge_keep_days für Rohhistorie,
• Include-/Exclude-Filter für Entitäten und Events,
• commit_interval als Verhältnis von I/O zu Verlustfenster,
• Datenbankgrösse, freier Speicher und Schreiblatenz,
• Purge und Repack,
• Startreihenfolge und Erreichbarkeit externer Datenbanken,
• Langzeitstatistik und Metadatenkonsistenz.

Ein Wechsel der Recorder-Datenbank migriert die vorhandene Historie nicht unterstützt. Externe Datenbanken brauchen eigene konsistente Backups und Restoretests. Bei SQLite nennt die Dokumentation freien Platz von mindestens dem 2,5-Fachen der Datenbankgrösse für Korruptionsbehandlung. Damit sind Storage und Recorder ein eigener Kapazitäts- und Recoverypfad, nicht bloss ein optionaler Cache.

API, WebSocket und Authentisierung

Frontend und APIs teilen standardmässig denselben HTTP-Listener. Die REST API verwendet JSON und Bearer Tokens; der Basispfad ist /api/. Die WebSocket API liegt unter /api/websocket, durchläuft auth_required, auth und auth_ok und korreliert Befehle über numerische IDs. WebSocket liefert Ereignisströme und Registries effizienter als wiederholtes REST-Polling.

Langlebige Tokens sind Benutzer-Credentials. Die Authentication API beschreibt OAuth/IndieAuth, Refresh Tokens, Long-Lived Access Tokens und kurzlebige Signed Paths. Ein Token erbt den Kontext seines Benutzers; ein zehn Jahre gültiges Long-Lived Token gehört in einen Secretspeicher, nicht in YAML, Shell-History, URL oder Dashboard-JavaScript.

Ein API-Monitor prüft mindestens Authentisierung, /api/config, erwartete Entitäten, last_updated, WebSocket-Subscription und einen ungefährlichen Read-/Actionpfad. Ein HTTP-200 auf / prüft lediglich Frontend-Erreichbarkeit.

$headers = @{ Authorization = "Bearer $env:HA_TOKEN" }
Invoke-RestMethod -Headers $headers -Uri "https://ha.example.net/api/config"
Invoke-RestMethod -Headers $headers -Uri "https://ha.example.net/api/states/sensor.uptime" |
  ConvertTo-Json -Depth 8

curl --fail --silent --show-error \
  -H "Authorization: Bearer $HA_TOKEN" \
  https://ha.example.net/api/config | jq .
curl --fail --silent --show-error \
  -H "Authorization: Bearer $HA_TOKEN" \
  https://ha.example.net/api/states/sensor.uptime | jq .

Invoke-RestMethod und ConvertTo-Json verarbeiten die Windows-Abfrage; curl und jq tun dasselbe auf Unix. Der Token wird nur als Prozessumgebungsvariable gezeigt; produktiv stammt er aus einem kontrollierten Secretspeicher.

HTTP, TLS und Reverse Proxy

Der HTTP-Endpunkt lauscht standardmässig auf TCP 8123. Direktes TLS, Reverse Proxy und Home Assistant Cloud sind verschiedene Zugriffsmodelle. Bei einem traditionellen Reverse Proxy müssen use_x_forwarded_for und trusted_proxies passend gesetzt sein; andernfalls ist die Client-IP falsch oder die Anfrage wird abgewiesen (HTTP integration). Eine breite Proxy-Vertrauensliste erlaubt das Fälschen von Forwarded-For-Informationen.

Die Sicherheitsanleitung empfiehlt eindeutige Passwörter, MFA, minimale Administratorrechte und einen gesicherten Remotezugriff statt direkter Internetexposition. TLS beendet nur den Transport. Tokenrechte, Proxyheaders, WebSocket-Upgrades, Rate Limits, DNS, Zertifikatserneuerung und die Sicherheit des vorgelagerten IdP bleiben eigene Kontrollen.

Resolve-DnsName ha.example.net
Test-NetConnection ha.example.net -Port 443
curl.exe -sS -D - -o NUL https://ha.example.net/api/
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 443

dig +short ha.example.net A ha.example.net AAAA
curl -sS -D - -o /dev/null https://ha.example.net/api/
ss -ntp state established '( dport = :443 )'
openssl s_client -connect ha.example.net:443 -servername ha.example.net -brief

Resolve-DnsName, Test-NetConnection und Get-NetTCPConnection prüfen Windows; dig, ss und openssl s_client prüfen Unix. Der unauthentisierte /api/-Aufruf darf 401 liefern; entscheidend sind Namensauflösung, TLS-Identität, Proxyroute und erwartete Authentisierungsgrenze.

MQTT-Diagnose

Brokerzustand wird ausserhalb von Home Assistant geprüft. Ein Subscriber beobachtet Discovery, Availability und State, ohne die Topics zu verändern. Ein Publish-Test verwendet einen eigens reservierten Testpfad; produktive Command Topics werden nicht beiläufig beschrieben.

mosquitto_sub.exe -h mqtt.example.net -p 8883 --cafile .\ca.pem `
  -u ha-observer -P $env:MQTT_PASSWORD -v -t "homeassistant/#"
mosquitto_pub.exe -h mqtt.example.net -p 8883 --cafile .\ca.pem `
  -u ha-probe -P $env:MQTT_PASSWORD -t "ops/probe" -m "online" -q 1

mosquitto_sub -h mqtt.example.net -p 8883 --cafile ./ca.pem \
  -u ha-observer -P "$MQTT_PASSWORD" -v -t 'homeassistant/#'
mosquitto_pub -h mqtt.example.net -p 8883 --cafile ./ca.pem \
  -u ha-probe -P "$MQTT_PASSWORD" -t 'ops/probe' -m 'online' -q 1

mosquitto_sub und mosquitto_pub sind die offiziellen Broker-Clients. Passwörter auf der Kommandozeile können in Prozesslisten oder History sichtbar werden; die Beispiele illustrieren den Pfad, während der produktive Aufruf Passwortdatei, Betriebssystem-Secretspeicher oder kurzlebige Credentials verwendet.

Betrieb von HAOS und Container

HAOS stellt den Befehl ha über Terminal-/SSH-Zugriff bereit. Containerinstallationen werden mit den Werkzeugen der gewählten Runtime betrieben. Ein Diagnosepaket hält Systeminfo, Corelog, Integrationsdiagnose, Containerstatus, freien Speicher und Zeitpunkt zusammen.

docker inspect homeassistant | ConvertFrom-Json
docker logs --since 30m --timestamps homeassistant 2>&1 |
  Select-String -Pattern 'ERROR|WARNING|unavailable|timeout'
docker stats --no-stream homeassistant

docker inspect homeassistant | jq '.[0].State, .[0].Mounts, .[0].NetworkSettings.Networks'
docker logs --since 30m --timestamps homeassistant 2>&1 | grep -E 'ERROR|WARNING|unavailable|timeout'
docker stats --no-stream homeassistant
df -h /path/to/config && du -sh /path/to/config

docker inspect, docker logs und docker stats liefern Containerzustand. ConvertFrom-Json und Select-String verarbeiten Windows-Ausgaben; grep, df und du ergänzen Unix. Ein laufender Container ist nur der erste Check; danach folgen Integrations-, Registry-, Event- und Gerätepfad.

Für die Fehlersuche wird der Signalweg rückwärts gelesen: Aktion, Automation Trace, Zustandsänderung, Integration, Netzwerkprotokoll und physisches Gerät.

Observability und systematische Diagnose

System Health sammelt Installationstyp, Architektur, Python-, Core- und Frontendinformationen und stellt Diagnosefunktionen über Einstellungen > System > Reparaturen bereit (System Health). Die Logger-Integration steuert globale und komponentenspezifische Log-Level. Debuglogging wird zeitlich und auf betroffene Namespaces begrenzt; Funk- oder Eventstürme können sonst Speicher und I/O dominieren.

Eine belastbare Diagnosekette lautet:

1. Symptom und Sollzustand: Welche Entität, Action, Automation oder Oberfläche ist betroffen?
2. Zeit und Scope: Seit wann, für welche Geräte, Benutzer, Netze und Integrationsinstanzen?
3. Objektidentität: Config Entry, Device ID, Entity ID, Unique ID und Bridgebezug sichern.
4. Laufzeit: Core, Event Loop, Speicher, CPU, Dateisystem und Datenbank prüfen.
5. Integration: Entry-Zustand, Authentisierung, Coordinator-/Pollingstatus und Diagnosedownload prüfen.
6. Transport: Discovery, DNS, TCP, TLS, Broker, Funkcontroller oder Hersteller-API prüfen.
7. Automation: Trace, Triggerdaten, Conditions, Run Mode und Actionresultat prüfen.
8. Persistenz: Recorder-Lag und Historie getrennt vom Livezustand bewerten.
9. Kontrollierter Test: Read-only oder ungefährliche Testentität verwenden.
10. Recovery: Reload vor Restart, Restart vor Restore; Evidenz vorher sichern.

Eine Entität unavailable kann aus einem entladenen Config Entry, fehlender Bridge, Funkverlust oder Quell-Timeout stammen. Eine sichtbare alte Zahl ist gefährlicher, weil sie plausibel wirkt. Monitoring braucht daher Frischegrenzen, nicht nur Wertgrenzen.

Updates, Releases und Custom Integrations

Home Assistant veröffentlicht häufige Core-Releases und dokumentiert rückwärtsinkompatible Änderungen. Ein statischer Referenzartikel friert bewusst keinen momentanen Versionsstand ein. Der Rollout prüft stattdessen zum Wartungszeitpunkt Release Notes, Integrationsänderungen und Zielabhängigkeiten.

Ein kontrollierter Updatepfad umfasst:

1. Backup und unabhängigen Download beziehungsweise externen Speicherort bestätigen.
2. Freien Platz, Datenbankzustand und System Health prüfen.
3. Release Notes sowie betroffene Integrationen und Custom Components bewerten.
4. Funk-, Broker-, Datenbank- und Proxyabhängigkeiten inventarisieren.
5. Core beziehungsweise HAOS und Apps in definierter Reihenfolge aktualisieren.
6. Startlog, Reparaturen und Registrymigrationen prüfen.
7. Kritische Sensor-, Aktor-, Automation-, API- und Fernzugriffspfade testen.
8. Fehlergrenze bestimmen und erst danach Rollback oder Restore auslösen.

HAOS verwendet RAUC mit zwei Betriebssystem-Slots; ha os info und rauc status machen den Slotzustand sichtbar (HAOS update system). Dieser Mechanismus schützt den OS-Updatepfad, nicht automatisch Core-Konfiguration, Recorderdaten oder Funknetzwerkzustand.

Sind Laufzeit und Datenpfad bekannt, lässt sich der Sicherungsumfang bestimmen. Konfiguration, Registries, Secrets, Datenbank und Add-on-Zustände müssen gemeinsam zum gewählten Installationsmodell passen.

Backup und Recovery

Home Assistant kann automatische und manuelle, verschlüsselte Backups an lokale oder externe Ziele schreiben. Die offizielle Backup- und Restore-Anleitung beschreibt Backupstandorte, Emergency Kit, Download, Restore im Onboarding und Migration auf andere Hardware. Seit 2026 wurde das Kryptomodell der Backups modernisiert; die Ankündigung zur Backupverschlüsselung dokumentiert den Formatwechsel und die Kompatibilitätsgrenzen.

Ein Backup ist nur vollständig relativ zum Installationsmodell:

Ein Restoretest endet nicht am Login. Akzeptanzkriterien sind: Config Entries geladen, Registries konsistent, Benutzerzugriff möglich, Datenbank ohne Fehler, Broker und Bridges verbunden, Funkgeräte kontrollierbar, kritische Automationen getestet und Fernzugriff mit korrektem Zertifikat verfügbar. Batteriegräte können nach einer Migration zunächst schlafen; ein fehlender Sofortwert wird nicht vorschnell als Datenverlust bewertet.

Get-ChildItem .\ha-backups -File -Recurse |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv .\ha-backups-manifest.csv -NoTypeInformation
Get-Content .\ha-backups-manifest.csv -First 5

find ./ha-backups -type f -print0 | sort -z | xargs -0 sha256sum > ha-backups-manifest.sha256
head -n 5 ha-backups-manifest.sha256
tar -tf ./ha-backups/example-backup.tar | head

Get-FileHash, Export-Csv und Get-Content erstellen beziehungsweise lesen das Windows-Manifest. find, sort, xargs, sha256sum und tar übernehmen Unix. Eine Prüfsumme beweist Unverändertheit des Archivs; Entschlüsselbarkeit und fachliche Wiederherstellung beweist nur der Restoretest.

RPO, RTO und Hochverfügbarkeit

Home Assistant ist im üblichen Betrieb eine zustandsbehaftete Einzelinstanz. Zwei aktive Core-Instanzen gegen dieselben Geräte, Registries oder Broker-Commands erzeugen keine automatisch koordinierte Hochverfügbarkeit. Doppelte Automationen können Aktoren mehrfach schalten; Funkcontroller und lokale Geräte erlauben oft nur eine aktive Eigentümerschaft.

Ein realistisches Resilienzmodell kombiniert:

• zuverlässigen Einzelknoten oder VM mit überwachten Ressourcen,
• USV und geeignetes Storage statt empfindlicher Flashmedien,
• getrennte, automatische und verschlüsselte Backups,
• dokumentierte Ersatzhardware oder VM-Zielplattform,
• exportierbare Funkcontrollerzustände und Schlüssel,
• reproduzierbare externe Dienste,
• kontrollierten Restore mit eindeutiger Geräte- und Netzwerkübernahme.

Das RPO hängt von der letzten gesicherten Konfiguration, Registry, App- und externen Dienstkopie ab. Recorderhistorie kann ein anderes RPO besitzen als Automationskonfiguration. Das RTO umfasst nicht nur Corestart, sondern DNS, Proxy, Datenbank, Broker, Funkcontroller, Geräte-Reconnect, schlafende Sensoren und Abnahmetests.

Sicherheit und Vertrauensgrenzen

Home Assistant kann Türen, Heizung, Alarmanlagen und Energieflüsse steuern. Der Einflussbereich ist damit physisch. Sicherheitsdesign trennt:

• Benutzer und Administratoren,
• Browser-, Companion-App- und API-Sitzungen,
• Long-Lived Tokens und Webhooks,
• Core und Custom Integrations,
• Supervisor-Apps oder externe Container,
• IoT-, Management- und Benutzersegmente,
• lokale Geräte und Hersteller-Clouds,
• Funknetze und deren Schlüssel,
• Backupziele und Emergency Kit.

MFA schützt interaktive Konten, aber kein gestohlenes Long-Lived Token. Netzwerksegmentierung begrenzt laterale Bewegung, darf jedoch notwendige Discovery- und Rückkanäle nicht unkontrolliert blockieren. Custom Integrations erhalten Prozessnähe zum Core und werden wie Code-Deployments behandelt. Secrets erscheinen weder in Git noch in Diagnosedateien oder Supportposts. Allgemeine Kontrollen stehen unter Härtung, Transportgrundlagen unter TLS und API-Vertragsmodelle unter APIs.

Technische Geschichte

Home Assistant begann 2013 als Python-Projekt von Paulus Schoutsen. Der Rückblick zum zehnjährigen Bestehen beschreibt die Entwicklung von einer kleinen lokalen Automationsanwendung zu einem grossen Open-Source-Projekt (10 Jahre Home Assistant). Der Python-Core und das Integrationsmodell blieben die fachliche Mitte, während sich darum Frontend, mobile Clients, Supervisor, HAOS, Gerätehardware und Cloudoptionen entwickelten.

Mit Hass.io, später Home Assistant beziehungsweise Home Assistant OS und Supervisor, entstand ein Appliance-Stack aus Betriebssystem, Containerverwaltung, Core und Zusatzdiensten. Die Trennung wurde sprachlich mehrfach bereinigt: «Add-ons» heissen heute Apps, während «Integrationen» weiterhin Python-Erweiterungen des Core sind. Diese Begriffe bezeichnen unterschiedliche Ausführungs- und Sicherheitsgrenzen.

2024 ging Home Assistant in die gemeinnützige Open Home Foundation über; Nabu Casa blieb kommerzieller Partner. Die Projektankündigung zum Open-Home-Ökosystem beschreibt Eigentum und Governance. 2025 reduzierte das Projekt die unterstützten Installationsvarianten auf HAOS und Container. Der historische Trend geht damit nicht zu einem verteilten Cluster, sondern zu einem stabileren zentralen Core mit klarer unterstützten Laufzeitpaketen und eigenständigen Protokollservern.

Admin-Checkliste

Ein grünes Dashboard genügt nicht als Betriebsnachweis. Die Checkliste verbindet Installation, Gerätepfade, Automationen, Datenhaltung und Wiederherstellung zu einer prüfbaren Gesamtsicht.

• Installation: HAOS oder Container, Architektur, Host, Storage, Netzwerk und Ownership dokumentieren.
• Stack: Core, Supervisor, Apps/externe Container, Datenbank, Broker, Proxy und Funkserver trennen.
• Inventar: Config Entry, Device ID, Entity ID, Unique ID, Area und via_device erfassen.
• Datenherkunft: Local/Cloud sowie Push/Polling pro kritischer Integration markieren.
• Zustand: unknown, unavailable, veralteten Wert und bestätigten Geräteerfolg unterscheiden.
• Automation: Trigger, Context, Condition, Run Mode, Restartverhalten und Kompensation testen.
• APIs: Benutzerkontext, Tokenablage, WebSocket, Reverse Proxy und TLS kontrollieren.
• Recorder: Datenbank, Filter, Commitintervall, Purge, I/O, Wachstum und Backup überwachen.
• IoT-Netz: mDNS, SSDP, MQTT, VLAN, IPv6 und Funk-/Bridgepfade explizit prüfen.
• Updates: Release Notes, Custom Integrations, Backup, Rollout und Abnahme zusammenführen.
• Recovery: Core, externe Dienste, Funkzustand, Schlüssel und Emergency Kit gemeinsam testen.
• Nachweis: Nicht nur UI und Container, sondern mindestens einen Sensor-, Aktor-, Automation- und API-Pfad Ende zu Ende verifizieren.