Stato di runtime vs stato persistente in Home Assistant: cosa deve sopravvivere al riavvio?

Lo “stato” di Home Assistant non è una cosa sola. Il processo in esecuzione dispone di una State Machine in memoria che rappresenta ciò che le entità riportano in questo momento, mentre la configurazione persistente e i registri identificano ciò che dovrebbe esistere dopo un riavvio. Recorder conserva le osservazioni storiche e alcune piattaforme di entità possono salvare i valori appositamente per ripristinarli in seguito.

Una distribuzione affidabile, quindi, non cerca di serializzare ogni oggetto temporaneo presente in memoria. Conserva le fonti di verità durature e lascia che il nuovo processo ricostruisca lo stato attivo a partire dalle integrazioni, dai registri, dai valori ripristinati e dai nuovi dati riportati dai dispositivi.

La State Machine è una vista di runtime del mondo attuale

Home Assistant Core mantiene gli stati correnti delle entità nella propria State Machine ed emette eventi quando tali stati cambiano. Questa vista corrente appartiene al processo Core in esecuzione.

La documentazione dell’architettura di Core descrive la State Machine come il componente che tiene traccia degli stati correnti e genera eventi state_changed. Event Bus, Service Registry e Timer sono componenti di runtime che operano attorno a essa.

Dopo un riavvio, la State Machine viene popolata nuovamente. Di conseguenza, un dispositivo che non si è ancora riconnesso può risultare non disponibile, anche se le sue vecchie osservazioni sono conservate al sicuro in Recorder.

I registri delle entità conservano l’identità, non la verità attuale del dispositivo

Home Assistant deve riconoscere la stessa entità tra un riavvio e l’altro, così le personalizzazioni dell’utente, gli ID delle entità, i nomi, le aree e altre impostazioni non scompaiono ogni volta che un’integrazione si riconnette.

Il registro delle entità esiste perché Home Assistant deve conservare l’identità duratura delle entità tra i riavvii, mantenere le personalizzazioni e tenere traccia delle entità note. La presenza di una voce nel registro non significa che la lettura corrente del sensore sia automaticamente aggiornata dopo l’avvio.

Pensa all’identità e al valore attuale come a due record separati: il registro risponde alla domanda “quale entità è questa?”, mentre l’integrazione risponde a “che cosa sta segnalando adesso?”.

Alcuni valori delle entità vengono salvati intenzionalmente per il ripristino

Alcune entità, in particolare helper ed entità software con stato, traggono vantaggio dal ripristino del valore precedente prima che sia disponibile una nuova osservazione esterna. Home Assistant dispone di un checkpoint persistente dedicato per queste entità.

L’attuale azione per salvare gli stati persistenti spiega che alcune entità ripristinano l’ultimo valore dopo un riavvio e che Home Assistant normalmente crea un checkpoint di tali valori all’avvio, ogni 15 minuti e allo spegnimento.

Si tratta di persistenza selettiva. Non va confusa con l’idea di considerare per sempre autorevole lo stato di ogni dispositivo fisico. Un valore ripristinato può essere utile durante l’avvio, ma un’integrazione dovrebbe comunque convergere sullo stato reale aggiornato del dispositivo quando questo è disponibile.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La cronologia di Recorder conserva le osservazioni, non il processo in esecuzione

Recorder conserva cambiamenti di stato ed eventi per visualizzazioni storiche, analisi e statistiche. Il database può sopravvivere a numerosi riavvii di Home Assistant, mentre la State Machine di runtime viene ricreata ogni volta.

Una query della cronologia che risponde alla domanda “qual era la temperatura alle 15:00?” appartiene alla persistenza storica. Un’automazione attiva che chiede “la porta è aperta adesso?” dipende dallo stato corrente di runtime e dal percorso dell’integrazione.

Questa distinzione spiega perché l’eliminazione o la corruzione di Recorder possa rimuovere la cronologia senza necessariamente cancellare automazioni, utenti e configurazione delle integrazioni, mentre la perdita della directory di configurazione può distruggere identità e configurazione anche se esiste ancora un vecchio database della cronologia.

La distribuzione deve conservare i file che ricreano questi livelli

Home Assistant containerizzato aggiunge un ulteriore confine: l’immagine di runtime può essere sostituita, mentre il mount della configurazione e le dipendenze esterne devono sopravvivere al di fuori di essa. Il mount deve conservare la configurazione di Home Assistant, l’archiviazione dei registri, i riferimenti ai segreti e il database se Recorder è locale.

L’articolo di ZimaSpace sui ruoli dei dati persistenti di Home Assistant illustra l’ambito del ripristino. La distinzione tra runtime e dati persistenti spiega perché questi file siano importanti: sono gli input dai quali il processo successivo ricostruisce l’ambiente domestico.

Usa il livello di persistenza adatto al ruolo dello stato

La regola sicura è conservare l’identità, la configurazione, i dati di ripristino e lo stato che Home Assistant considera intenzionalmente duraturi. Lascia che lo stato temporaneo di runtime venga ricostruito. In questo modo si ottiene un modello di riavvio più chiaro rispetto all’idea che ogni valore presente in memoria debba sopravvivere invariato.