Warum erstellt Home Assistant nach einem Container-Neustart einen anderen Zustand?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Why Does Home Assistant Rebuild Different State After a Container Restart? - Zima Store Online

Ein Neustart des Home-Assistant-Containers kann dazu führen, dass das System kurzzeitig anders aussieht, selbst wenn die persistente Konfiguration vollständig intakt ist. Der Grund: Eine laufende Instanz enthält sowohl dauerhaften Zustand auf der Festplatte als auch flüchtigen Laufzeitzustand im Arbeitsspeicher. Beim Neustart des Containers wird Letzterer verworfen, und die Integrationen müssen ihn neu aufbauen.

Deshalb kann eine Entität vorübergehend den Status unknown oder unavailable anzeigen, ein MQTT-Gerät wieder auftauchen, sobald gespeicherte Nachrichten eintreffen, und ein externer Dienst so lange fehlen, bis ein Wiederholungsversuch erfolgreich ist. Der Neustart ist ein Ereignis zur Zustandsrekonstruktion – nicht einfach eine Unterbrechung mit anschließender Fortsetzung desselben In-Memory-Prozesses.

Die Container-Laufzeit ist austauschbar; /config bildet die dauerhafte Grenze

Home Assistant Container wird normalerweise betrieben, indem das Container-Image neu erstellt wird, während der Konfigurations-Mount erhalten bleibt. Das Aktualisieren des Images, das Ändern der Laufzeit oder der Neustart des Prozesses sollte keinen vollständigen Neuaufbau des Haushalts erfordern, solange der persistente Pfad korrekt eingebunden bleibt.

Der aktuelle Workflow für Home Assistant Container erstellt den Container beim Ändern von Versionen ausdrücklich neu. Dieses Modell funktioniert, weil erwartet wird, dass der Anwendungszustand außerhalb der kurzlebigen Laufzeit erhalten bleibt.

Alles, was nur im Prozessspeicher existiert, geht beim Neustart verloren. Der nächste Prozess muss Konfiguration, Registrierungen, Datenbanken und Integrationseingaben erneut einlesen, bevor er dieselbe aktive Ansicht wiederherstellen kann.

Core startet eine neue Laufzeit-Zustandsmaschine

Bei jedem Start erstellt Home Assistant einen neuen Core-Prozess mit einer neuen Ereignisschleife, Zustandsmaschine, Diensten, Timern und Laufzeitobjekten der Integrationen. Die Entitätsregistrierung kann bekannte Entitäten identifizieren, aber der aktuelle Wert eines physischen Geräts muss weiterhin wiederhergestellt, abgerufen oder gemeldet werden.

Recorder erstellt außerdem bei jedem Start von Home Assistant einen neuen Recorder-Lauf. Historische Datenbankeinträge bleiben erhalten, doch der aktuelle Prozess befindet sich in einem neuen Laufzeitintervall und setzt nicht das alte fort.

Dieser Unterschied ist wichtig, wenn Protokolle oder Datenbankzeitstempel rund um einen Neustart verglichen werden. Ein Verlaufseintrag belegt, was Home Assistant zuvor beobachtet hat; er beweist nicht automatisch, dass der neue Prozess die aktive Geräteverbindung bereits wiederhergestellt hat.

Integrationen bauen den Laufzeitzustand unterschiedlich schnell wieder auf

Manche Integrationen verbinden sich sofort wieder mit einem lokalen Gerät. Andere warten auf DNS, einen Broker, eine Cloud-API, eine Funkbrücke oder einen anderen Container. Deshalb werden ihre Entitäten zu unterschiedlichen Zeitpunkten verfügbar, obwohl Home Assistant Core bereits läuft.

Das aktuelle Modell von Home Assistant für fehlgeschlagene Einrichtungsvorgänge verlangt, dass vorübergehend nicht verfügbare Integrationen in einen Wiederholungspfad wechseln, damit sie sich erholen können, sobald das Gerät oder der Dienst erreichbar ist. Daher kann sich der sichtbare Zustand nach einem Neustart über mehrere Minuten hinweg verändern, ohne dass sich persistente Daten geändert haben.

Ein zweiter Neustart, nachdem alle Abhängigkeiten bereits aktiv sind, kann deutlich schneller wirken als ein Neustart des gesamten Stacks, weil Netzwerk, Broker, Datenbank und Geräte nicht gleichzeitig wieder verfügbar werden müssen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

MQTT macht die Zustandsrekonstruktion besonders sichtbar

MQTT ist ein anschauliches Beispiel, weil der Broker Erkennungs- oder Statusnachrichten unabhängig vom Home-Assistant-Prozess speichern kann. Wenn Home Assistant die Verbindung wiederherstellt, können gespeicherte Daten erneut übermittelt werden und Entitäten schnell wieder ihren zuletzt gemeldeten Wert erhalten.

Die MQTT-Integration dokumentiert, dass erkannte Entitäten nach einem Neustart nicht verfügbar sind, bis die Erkennung verarbeitet wurde, während gespeicherte Erkennungs- und Statusnachrichten beim Wiederaufbau der Abonnements erneut übermittelt werden können. Home Assistant sendet außerdem eine Birth-Nachricht, die Geräte dazu verwenden können, Erkennungsdaten und aktuelle Statusinformationen erneut zu veröffentlichen.

Ein gespeicherter Wert ist dennoch nur eine zuletzt bekannte Meldung und kein Beweis dafür, dass das physische Gerät aktuell erreichbar ist. Verfügbarkeitsthemen und aktuelle Telemetriedaten sollten getrennt bewertet werden.

Das Neustartverhalten hängt davon ab, wo die maßgebliche Datenquelle liegt

Persistente Konfiguration und Registrierungen: werden erneut aus dem dauerhaften Home-Assistant-Speicher eingelesen.
Aktueller Gerätezustand: wird häufig von einer Integration erneut abgerufen oder gemeldet.
MQTT-Zustand: kann aus gespeicherten Nachrichten oder neuen Veröffentlichungen rekonstruiert werden.
Cloud-basierter Zustand: hängt von der Verbindung zur Remote-API und den Zugangsdaten ab.
Historischer Zustand: bleibt im Recorder erhalten, entspricht aber nicht dem Live-Zustand.
Reine Laufzeitobjekte: werden vom neuen Home-Assistant-Prozess neu erstellt.

Die ZimaSpace-Erklärung zu MQTT-Zuständen nach einem Neustart zeigt einen konkreten Rekonstruktionsweg. Die übergeordnete Regel lautet: Das Neustartverhalten richtet sich danach, wo die maßgebliche Datenquelle der jeweiligen Komponente liegt.

FAQ

Löscht ein Neustart des Home-Assistant-Containers den Verlauf?

Nein, sofern die persistente Konfiguration und die Recorder-Datenbank korrekt eingebunden sind. Der Neustart ersetzt den Laufzeitprozess; historische Daten bleiben in der persistenten Datenbank erhalten.

Warum kann eine Entität direkt nach dem Neustart ihren alten Wert anzeigen?

Der Wert kann aus einem Wiederherstellungsmechanismus von Home Assistant, einem Integrations-Cache, einem gespeicherten MQTT-Status oder einer sofortigen Geräteabfrage stammen. Prüfe die Integration und den Verfügbarkeitsweg, bevor du den angezeigten Wert als aktuelle physische Messung interpretierst.