Laufzeitstatus vs. dauerhafter Status in Home Assistant: Was muss einen Neustart überstehen?

Der „Zustand“ von Home Assistant ist nicht nur eine einzige Sache. Der laufende Prozess verfügt über eine im Arbeitsspeicher befindliche Zustandsmaschine, die darstellt, was die Entitäten aktuell melden, während persistente Konfigurationen und Registries festlegen, was nach einem Neustart vorhanden sein sollte. Recorder speichert historische Beobachtungen, und ausgewählte Entitätsplattformen können Werte gezielt speichern, damit diese später wiederhergestellt werden können.

Eine zuverlässige Bereitstellung versucht daher nicht, jedes flüchtige Objekt im Arbeitsspeicher zu serialisieren. Stattdessen bewahrt sie die dauerhaften Quellen der Wahrheit und lässt den neuen Prozess den aktuellen Zustand aus Integrationen, Registries, wiederhergestellten Werten und neuen Gerätemeldungen erneut aufbauen.

Die Zustandsmaschine ist eine Laufzeitansicht der aktuellen Welt

Home Assistant Core verwaltet die aktuellen Entitätszustände in seiner Zustandsmaschine und löst Ereignisse aus, wenn sich diese Zustände ändern. Diese aktuelle Ansicht gehört zum laufenden Core-Prozess.

Die Dokumentation zur Core-Architektur beschreibt die Zustandsmaschine als Komponente, die aktuelle Zustände verfolgt und state_changed-Ereignisse auslöst. Der Event Bus, die Service Registry und der Timer sind Laufzeitkomponenten in ihrer Umgebung.

Nach einem Neustart wird die Zustandsmaschine erneut gefüllt. Ein Gerät, das noch keine Verbindung hergestellt hat, kann daher nicht verfügbar sein, obwohl seine alten Beobachtungen sicher im Recorder gespeichert bleiben.

Entitäts-Registries speichern Identität, nicht die aktuelle Wahrheit des Geräts

Home Assistant muss dieselbe Entität über Neustarts hinweg wiedererkennen, damit benutzerdefinierte Anpassungen, Entitäts-IDs, Namen, Bereiche und andere Einstellungen nicht bei jeder erneuten Verbindung einer Integration verloren gehen.

Die Entitäts-Registry existiert, weil Home Assistant eine dauerhafte Entitätsidentität über Neustarts hinweg benötigt, um Anpassungen beizubehalten und bekannte Entitäten zu verfolgen. Ein Eintrag in dieser Registry bedeutet nicht, dass der aktuelle Sensorwert nach dem Start automatisch aktuell ist.

Betrachten Sie Identität und aktuellen Wert als getrennte Datensätze: Die Registry beantwortet die Frage „Welche Entität ist das?“, während die Integration beantwortet: „Was meldet sie jetzt?“

Einige Entitätswerte werden gezielt zur Wiederherstellung gespeichert

Bestimmte Entitäten – insbesondere Helfer und zustandsbehaftete Software-Entitäten – profitieren davon, ihren vorherigen Wert wiederherzustellen, bevor eine neue externe Beobachtung vorliegt. Home Assistant verfügt für diese Entitäten über einen speziellen Prüfpunkt für persistente Zustände.

Die aktuelle Aktion zum Speichern persistenter Zustände erklärt, dass einige Entitäten ihren letzten Wert nach einem Neustart wiederherstellen und dass Home Assistant diese Werte normalerweise beim Start, alle 15 Minuten und beim Herunterfahren als Prüfpunkt speichert.

Hierbei handelt es sich um eine selektive Persistenz. Sie sollte nicht mit der Annahme verwechselt werden, dass jeder physische Gerätezustand dauerhaft autoritativ ist. Ein wiederhergestellter Wert kann während des Starts nützlich sein, doch eine Integration sollte weiterhin auf den aktuellen Gerätezustand zurückgehen, sobald dieser verfügbar ist.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recorder speichert Beobachtungen, nicht den laufenden Prozess

Recorder speichert Zustandsänderungen und Ereignisse für historische Ansichten, Analysen und Statistiken. Diese Datenbank kann zahlreiche Neustarts von Home Assistant überstehen, während die Laufzeit-Zustandsmaschine jedes Mal neu erstellt wird.

Eine Verlaufsabfrage, die beantwortet „Wie hoch war die Temperatur um 15 Uhr?“, gehört zur historischen Persistenz. Eine laufende Automatisierung, die fragt „Ist die Tür jetzt geöffnet?“, hängt vom aktuellen Laufzeitzustand und vom Integrationspfad ab.

Dieser Unterschied erklärt, warum das Löschen oder Beschädigen von Recorder den Verlauf entfernen kann, ohne zwangsläufig Automatisierungen, Benutzer und Integrationskonfigurationen zu löschen, während der Verlust des Konfigurationsverzeichnisses Identität und Einrichtung zerstören kann, selbst wenn noch eine alte Verlaufsdatenbank vorhanden ist.

Die Bereitstellung muss die Dateien speichern, aus denen diese Ebenen wiederhergestellt werden

Eine containerisierte Home-Assistant-Installation fügt eine weitere Grenze hinzu: Das Laufzeit-Image kann ersetzt werden, während das Konfigurations-Mount und externe Abhängigkeiten außerhalb des Containers erhalten bleiben müssen. Das Mount muss die Home-Assistant-Konfiguration, den Speicher der Registry, Verweise auf Geheimnisse und die Datenbank bewahren, sofern Recorder lokal betrieben wird.

Der ZimaSpace-Artikel über persistente Datenrollen in Home Assistant behandelt den Umfang der Wiederherstellung. Die Unterscheidung zwischen Laufzeit und Persistenz erklärt, warum diese Dateien wichtig sind: Sie sind die Eingaben, aus denen der nächste Prozess den Haushalt rekonstruiert.

Verwenden Sie die Persistenzebene, die zur jeweiligen Zustandsrolle passt

Die sichere Regel lautet: Speichern Sie die Identität, Konfiguration, Wiederherstellungsdaten und Zustände, die Home Assistant ausdrücklich als dauerhaft behandelt. Lassen Sie den flüchtigen Laufzeitzustand neu aufgebaut werden. So entsteht ein klareres Neustartmodell, als wenn man davon ausgeht, dass jeder Wert im Arbeitsspeicher unverändert erhalten bleiben muss.