Perché Home Assistant perde il controllo locale affidabile dopo un riavvio?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does Home Assistant Lose Reliable Local Control After a Restart? - Zima Store Online

Home Assistant può apparire “attivo” dopo un riavvio mentre il controllo locale affidabile non è ancora completamente disponibile. L’interfaccia web può caricarsi prima che ogni integrazione, radio, automazione, helper, percorso del database e connessione al dispositivo siano tornati a uno stato utilizzabile.

Diagnostica il riavvio come una sequenza, non come un unico evento. Verifica che Home Assistant abbia raggiunto lo stato operativo, individua eventuali integrazioni ancora in caricamento o non disponibili, controlla che lo stato persistente sia stato ripristinato correttamente, quindi testa un percorso locale da sensore ad azione. Se la stessa automazione funziona dopo un ricaricamento manuale o un secondo riavvio, il problema è più probabilmente dovuto all’ordine di avvio o alla disponibilità delle dipendenze che a un errore permanente di configurazione.

Conferma che l’avvio sia realmente terminato

Inizia dai log e dallo stato delle integrazioni invece di attivare e disattivare immediatamente ogni automazione. Un processo container può essere in esecuzione mentre Home Assistant sta ancora ripristinando entità, collegando integrazioni, aprendo Recorder o attendendo un coordinatore radio.

Un recente problema di avvio di Home Assistant ha mostrato che un’integrazione ZHA può ritardare il bootstrap abbastanza a lungo da lasciare le entità delle automazioni YAML non disponibili dopo il riavvio. Ciò non significa che ZHA sia generalmente inaffidabile; dimostra perché “l’interfaccia si è aperta” non prova che l’intero runtime delle automazioni sia pronto.

Registra il primo momento in cui Home Assistant segnala il normale funzionamento, quindi confrontalo con l’istante in cui le entità critiche diventano disponibili. Se un’integrazione è sistematicamente l’ultima dipendenza a ripristinarsi, concentra lì l’indagine prima di modificare la logica di automazioni non correlate.

Attendi le dipendenze effettivamente necessarie all’automazione

Un’automazione per accendere una luce al rilevamento di un movimento può richiedere l’integrazione del sensore di movimento, l’integrazione della luce interessata, la rete locale o il coordinatore radio e qualsiasi entità helper usata dalle condizioni. Una sola dipendenza non disponibile può far sembrare inaffidabile l’automazione anche quando Home Assistant Core è in buone condizioni.

Questo limite temporale è visibile anche nelle integrazioni reali esterne al motore nativo delle automazioni. Una discussione nella community di Home Assistant segnala che un client WebSocket può connettersi prima che Home Assistant sia completamente operativo, quindi attendere lo stato operativo evita di inviare comandi mentre le entità sono ancora in caricamento.

Non risolvere il problema aggiungendo ritardi arbitrari di 30 o 60 secondi ovunque. Prima dimostra quale dipendenza arriva in ritardo, quindi vincola solo il flusso di avvio che ha realmente bisogno che sia pronta.

Separa lo stato dell’automazione da quello del dispositivo

Home Assistant ripristina molti stati dopo un riavvio, ma il valore ripristinato di un’entità non corrisponde sempre a una nuova conferma da parte del dispositivo fisico. Un interruttore può mostrare temporaneamente il valore precedente mentre l’integrazione si sta ancora riconnettendo.

Quando le entità tornano unavailable dopo un riavvio, evita di eliminarle o associarle nuovamente prima di aver individuato il percorso non funzionante. Una guida aggiornata alla risoluzione dei problemi consiglia di controllare raggiungibilità, indirizzamento, rilevamento, broker, radio e log dell’integrazione prima di reimpostare i dispositivi. In questo modo eviti che un problema di riavvio si trasformi in un problema di riconfigurazione più complesso.

Per ogni automazione critica, annota se l’entità di attivazione è stata ripristinata, è sconosciuta, non è disponibile oppure è stata aggiornata di recente dopo il riavvio. Questa distinzione indica se l’errore si verifica durante il ripristino dello stato, la riconnessione dell’integrazione o nell’automazione stessa.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Testa il percorso di controllo locale senza WAN

I problemi di riavvio possono essere confusi con problemi di internet quando anche il DNS locale, MQTT, il Wi-Fi, un reverse proxy o un’integrazione cloud del fornitore cambiano stato durante l’avvio. Mantieni un semplice test di controllo locale che non dipenda da internet.

Usa un percorso rappresentativo, ad esempio un sensore di movimento Zigbee che accende una luce locale oppure un pulsante locale che cambia lo stato di un relè. Se quel percorso funziona mentre un dispositivo basato sul cloud non funziona, il controllo locale di Home Assistant è operativo e il problema rimanente appartiene alla dipendenza remota.

La guida di ZimaSpace per creare un hub locale per l’automazione con limiti espliciti per il controllo locale e il ripristino è un utile riferimento per mantenere il percorso domestico critico indipendente dai servizi internet opzionali.

Usa un test di accettazione del riavvio invece di procedere per tentativi ripetuti

Controllo	Condizione di superamento	Probabile responsabile dell’errore
Avvio del core	Il sistema raggiunge lo stato operativo senza errori persistenti di configurazione	Core, configurazione, integrazione personalizzata
Integrazione critica	Le entità necessarie diventano disponibili	Radio, dispositivo, LAN, integrazione
Ripristino dello stato	Gli helper e gli stati persistenti previsti tornano correttamente	Ripristino dello stato, archiviazione, qualità dell’arresto
Automazione locale	Un’attivazione nota produce l’azione locale prevista	Percorso dell’automazione o dipendenza
Secondo riavvio	Lo stesso test viene superato nuovamente senza attivazioni manuali	Ordine di avvio, se il risultato è incoerente

Risolvi il livello più piccolo che non supera il test. Ricarica o ripara una singola integrazione quando mancano le sue entità; correggi lo stato o l’archiviazione quando i valori ripristinati sono errati; modifica la sequenza di avvio solo quando una dipendenza risulta effettivamente in ritardo. Ricostruire Home Assistant non è necessario finché la configurazione persistente rimane affidabile e l’errore è riproducibile in un unico ramo di avvio.