Tillstånd under körning kontra beständigt tillstånd i Home Assistant: Vad måste överleva en omstart?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Runtime State vs Persistent State in Home Assistant: What Must Survive Restart?

Home Assistants ”state” är inte en enda sak. Den körande processen har en State Machine i minnet som representerar vad entiteter rapporterar just nu, medan beständig konfiguration och register identifierar vad som ska finnas efter en omstart. Recorder sparar historiska observationer, och utvalda entitetsplattformar kan spara värden specifikt så att de kan återställas senare.

En tillförlitlig driftsättning försöker därför inte serialisera alla tillfälliga objekt i minnet. Den bevarar de beständiga källorna till sanning och låter den nya processen återskapa det aktiva tillståndet från integrationer, register, återställda värden och färska rapporter från enheter.

State Machine är en körningsvy av den aktuella världen

Home Assistant Core lagrar aktuella entitetstillstånd i sin State Machine och skickar händelser när dessa tillstånd ändras. Den aktuella vyn tillhör den körande Core-processen.

Core-arkitekturdokumentationen beskriver State Machine som den komponent som spårar aktuella tillstånd och utlöser state_changed-händelser. Event Bus, Service Registry och Timer är körningskomponenter runt den.

Efter en omstart fylls State Machine i igen. En enhet som ännu inte har återanslutit kan därför vara otillgänglig, även om dess gamla observationer fortfarande är säkert lagrade i Recorder.

Entitetsregister sparar identitet, inte enhetens aktuella sanning

Home Assistant måste känna igen samma entitet efter omstarter så att användaranpassningar, entitets-ID:n, namn, områden och andra inställningar inte försvinner varje gång en integration återansluter.

Entitetsregistret finns eftersom Home Assistant behöver beständig entitetsidentitet över omstarter för att behålla anpassningar och spåra kända entiteter. Registerposten innebär inte att den aktuella sensoravläsningen automatiskt är aktuell efter uppstart.

Tänk på identitet och aktuellt värde som separata poster: registret svarar på frågan ”vilken entitet är detta?”, medan integrationen svarar på ”vad rapporterar den just nu?”.

Vissa entitetsvärden sparas avsiktligt för återställning

Vissa entiteter – särskilt helpers och tillståndsbevarande mjukvaruentiteter – har nytta av att återställa sitt tidigare värde innan en ny extern observation finns tillgänglig. Home Assistant har en särskild beständig tillståndskontrollpunkt för dessa entiteter.

Den aktuella åtgärden för att spara beständiga tillstånd förklarar att vissa entiteter återställer sitt senaste värde efter en omstart och att Home Assistant normalt sparar dessa värden vid uppstart, var 15:e minut och vid avstängning.

Detta är selektiv beständighet. Det ska inte förväxlas med att behandla varje fysisk enhets tillstånd som auktoritativt för all framtid. Ett återställt värde kan vara användbart under uppstart, men en integration bör ändå konvergera mot färsk sanning från enheten när den blir tillgänglig.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Recorder sparar historiska observationer, inte den körande processen

Recorder lagrar tillståndsändringar och händelser för historiska vyer, analys och statistik. Databasen kan överleva många omstarter av Home Assistant, medan den aktiva State Machine återskapas varje gång.

En historikfråga som ”vilken temperatur var det klockan 15?” hör till historisk beständighet. En aktiv automatisering som frågar ”är dörren öppen nu?” är beroende av det aktuella körtillståndet och integrationsvägen.

Skillnaden förklarar varför en raderad eller skadad Recorder kan ta bort historik utan att automatiseringar, användare och integrationskonfiguration nödvändigtvis raderas, medan en förlorad konfigurationskatalog kan förstöra identitet och konfiguration även om en gammal historikdatabas fortfarande finns kvar.

Driftsättningen måste spara filerna som återskapar dessa lager

Containerbaserad Home Assistant lägger till ytterligare en gräns: körningsavbilden kan ersättas, medan konfigurationsmonteringen och externa beroenden måste överleva utanför den. Monteringen behöver bevara Home Assistants konfiguration, registerlagring, referenser till hemligheter och databasen om Recorder körs lokalt.

ZimaSpace-artikeln om Home Assistants beständiga dataroller beskriver återställningens omfattning. Skillnaden mellan körning och beständighet förklarar varför dessa filer är viktiga: de är indata som nästa process använder för att återskapa hemmet.

Använd det beständighetslager som motsvarar tillståndets roll

Tillståndsroll	Var det finns	Vad som händer efter en omstart
Aktuellt entitetstillstånd	Körningens State Machine	Återskapas från integrationer/återställning
Entitetsidentitet/anpassning	Beständigt register/konfiguration	Läses in igen
Utvalda återställningsbara värden	Beständig tillståndskontrollpunkt	Återställs tills de uppdateras
Historik/statistik	Recorder-databas	Förblir historiska data
Integrationsanslutningar/körningsobjekt	Processminne	Återskapas och ansluts igen
Containeravbildning/körning	Ersättningsbart driftsättningslager	Kan återskapas runt beständiga data

Den säkra regeln är att spara identitet, konfiguration, återställningsdata och det tillstånd som Home Assistant avsiktligt behandlar som beständigt. Låt det tillfälliga körningstillståndet återskapas. Det ger en renare omstartsmodell än att anta att varje värde i minnet ska överleva oförändrat.