Pianificazione delle risorse di Home Assistant: perché le interruzioni di Internet cambiano il comportamento del controllo locale

Un’interruzione della connessione Internet non fa automaticamente fallire le automazioni locali di Home Assistant. Le integrazioni locali Zigbee, Z-Wave, Matter, ESPHome, MQTT e LAN possono continuare a funzionare mentre la WAN è inattiva. Ciò che cambia è il carico di lavoro circostante: le richieste cloud scadono, le integrazioni effettuano nuovi tentativi, le ricerche DNS falliscono, le connessioni remote scompaiono e, quando la connettività ritorna, le attività di ripristino possono arrivare a raffica.

Per questo la pianificazione delle risorse è importante durante un’interruzione anche quando il percorso di controllo locale è integro. La domanda non è “Home Assistant ha bisogno di Internet?”. È se il lavoro remoto fallito rimane isolato o inizia a consumare tempo dell’event loop, thread dell’executor, capacità DNS, I/O di registrazione o ricaricamenti delle integrazioni che si sovrappongono al controllo locale.

Le richieste cloud fallite trasformano percorsi rapidi e riusciti in percorsi soggetti a timeout

Quando la WAN funziona, una richiesta cloud può completarsi rapidamente. Durante un’interruzione, la stessa chiamata può occupare l’intera finestra di timeout, essere ritentata e registrare un errore prima di restituire il controllo. Alcune chiamate sono innocue; molte integrazioni che fanno lo stesso contemporaneamente creano un profilo di pianificazione diverso dal normale funzionamento.

Il ciclo di vita delle voci di configurazione di Home Assistant include uno stato esplicito di setup retry per le dipendenze non ancora pronte, con un intervallo tra i tentativi automatici che aumenta nel tempo. La modalità esatta di errore dipende comunque da ciascuna integrazione, ma il lavoro di ripetizione dei tentativi è una parte definita del funzionamento degradato, non un caso limite eccezionale.

Evita che le automazioni critiche attendano un’API remota prima di eseguire l’azione locale. Invia la notifica, l’aggiornamento cloud o il webhook esterno dopo l’azione fisica quando il risultato remoto non è necessario per decidere cosa deve fare la casa.

I timeout di rete possono trattenere risorse anche senza un utilizzo elevato della CPU

Un’operazione di rete bloccata può mostrare un utilizzo ridotto della CPU pur occupando un’attività, una connessione, un thread o una parte del budget di timeout. Per questo “la CPU è solo al 10%” non dimostra che un’interruzione sia priva di costi.

Un caso di Home Assistant del 2026 ha ricondotto timeout ripetuti delle integrazioni e ricaricamenti a cascata a un percorso IPv6 non funzionante che lasciava le connessioni in attesa invece di farle fallire rapidamente. Il sintomo era un ritardo nella pianificazione attorno alle chiamate di rete, non l’esaurimento della capacità di calcolo.

Monitora le attività di rete in sospeso, gli avvisi delle integrazioni, gli errori DNS e il tempo tra l’attivazione e la chiamata al servizio locale. Se le azioni locali rimangono rapide mentre le entità cloud diventano non disponibili, l’interruzione è isolata correttamente. Se la latenza locale aumenta insieme alle chiamate remote fallite, individua l’integrazione o il codice personalizzato che sta occupando il runtime condiviso.

Il lavoro bloccante è più pericoloso dell’attesa asincrona

Il core di Home Assistant è asincrono, quindi le integrazioni ben progettate possono sospendersi durante l’attesa dell’I/O e consentire l’esecuzione di altre attività. Il caso pericoloso è il lavoro bloccante che occupa direttamente l’event loop o il codice personalizzato che esegue operazioni di rete sincrone nel posto sbagliato.

La documentazione per sviluppatori di Home Assistant spiega che un’operazione bloccante nell’event loop impedisce l’esecuzione di altro lavoro finché non termina. Un’interruzione Internet può mettere in luce questa debolezza perché una chiamata che normalmente restituisce subito il controllo può improvvisamente attendere un timeout prolungato.

Per questo un’integrazione personalizzata può far sembrare che l’intera piattaforma sia rallentata durante un’interruzione, anche se le integrazioni locali native sono ben progettate. Confronta il comportamento con i componenti personalizzati disabilitati prima di incolpare l’hardware.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Il ripristino può creare un secondo picco di carico

Quando la connettività Internet ritorna, diverse integrazioni possono riconnettersi, aggiornare lo stato, riautenticarsi, aggiornare le entità e scrivere nuova cronologia quasi contemporaneamente. La fase di ripristino può quindi essere più intensa della parte centrale dell’interruzione.

Non considerare un picco di CPU, rete o scritture del Recorder subito dopo il ritorno della WAN come una prova che la capacità normale a regime sia insufficiente. Misura quanto dura il picco e verifica se la latenza del controllo locale torna ai valori normali in seguito.

L’articolo di ZimaSpace sui messaggi retained, in coda, di discovery e di disponibilità dopo la riconnessione mostra lo stesso principio di ripristino: la riconnessione di componenti distribuiti può riprodurre lo stato e creare lavoro che non esisteva mentre la connessione era stabile.

Pianifica la modalità degradata, non solo quella normale

Durante la perdita della WAN, i percorsi locali da movimento a illuminazione dovrebbero continuare a funzionare senza prerequisiti remoti. Il polling cloud può passare a tentativi limitati, le notifiche remote possono fallire o accodarsi, i servizi che dipendono dal DNS dovrebbero fallire in modo prevedibile e il ritorno della connettività può creare un breve picco di aggiornamenti.

L’obiettivo progettuale è un degrado selettivo: il lavoro remoto opzionale diventa più lento o scompare, mentre il controllo locale rimane entro il normale intervallo di risposta. Il test più efficace per un’interruzione consiste nel disconnettere la WAN durante un normale carico domestico, misurare alcune automazioni locali critiche, quindi riconnetterla e misurare sia il picco di ripristino sia il tempo necessario per tornare ai valori normali.

Domande frequenti

Un’interruzione Internet rende più lente le automazioni locali di Home Assistant?

Non necessariamente. Un’automazione completamente locale può continuare a funzionare alla velocità normale. Diventa più lenta quando il lavoro cloud, DNS, delle integrazioni personalizzate o della rete condivisa consuma risorse sullo stesso percorso critico.

Dovrei aggiungere tentativi aggressivi per fare in modo che le integrazioni cloud si ripristinino più rapidamente?

No. I tentativi aggressivi possono amplificare un’interruzione e creare lavoro inutile. Preferisci un comportamento di ripetizione dei tentativi limitato e mantieni il ripristino cloud fuori dal percorso temporale delle automazioni locali critiche.