Quando Home Assistant si avvia ma una dipendenza non funziona, mantieni il servizio principale in esecuzione abbastanza a lungo da identificare la prima dipendenza non disponibile, invece di ricreare l'installazione.
Un processo in buone condizioni può comunque esporre un sistema incompleto: le entità MQTT potrebbero non essere disponibili, un database esterno potrebbe bloccare lo storico, un mount mancante potrebbe compromettere i backup oppure il DNS potrebbe impedire la risoluzione degli endpoint cloud e locali. Acquisisci il primo errore, testa l'endpoint indicato dall'ambiente di runtime di Home Assistant e ripristina i servizi partendo dalla dipendenza verso l'esterno.
Identifica il primo errore di dipendenza
Registra il primo errore dopo l'avvio per l'integrazione o il servizio interessato, includendo il nome della dipendenza, l'endpoint, la classe dell'eccezione, l'intervallo tra i tentativi e il timestamp. Gli avvisi successivi spesso descrivono la conseguenza — entità non disponibili o configurazione non riuscita — invece del primo errore di connessione, autenticazione, mount o schema.
Un caso MQTT di base mostra la differenza tra configurare un'integrazione e avere effettivamente un broker disponibile. La chiarita distinzione sulla disponibilità del broker è utile perché impedisce di modificare ripetutamente il client quando il servizio richiesto non esiste o non è in esecuzione.
Se un nome di dipendenza compare prima di tutti gli errori secondari, trasformalo nell'obiettivo del ripristino. Se più dipendenze non correlate falliscono simultaneamente, verifica prima DNS, rete, archiviazione o credenziali condivisi, invece di riparare ogni integrazione separatamente.
Verifica raggiungibilità, autenticazione e disponibilità nell'ordine corretto
Dallo stesso container, VM o namespace dell'host utilizzato da Home Assistant, risolvi il nome host della dipendenza, apri la porta richiesta, autentica l'identità configurata ed esegui il più piccolo controllo di disponibilità in sola lettura disponibile. La raggiungibilità dal lato host, da sola, non dimostra che il namespace dell'applicazione o le credenziali funzionino.
L'ordine di avvio dei container non equivale alla disponibilità dell'applicazione; una dipendenza vincolata a un controllo di salute può impedire l'avvio dei client contro un database o un broker non ancora pronto. La distinzione in ordine di avvio e disponibilità supporta l'aggiunta di un controllo di salute reale solo dopo aver compreso la condizione che ha causato il problema.
Se la risoluzione non riesce, ripara il DNS o il nome del servizio. Se la porta non risponde, ripristina il processo della dipendenza o il percorso di rete. Se l'autenticazione non riesce, confronta l'origine delle credenziali configurate senza stamparne il valore. Se il controllo di disponibilità non riesce dopo una connessione riuscita, esamina i log e lo stato dell'archiviazione della dipendenza.
Ripristina la dipendenza con la modifica meno invasiva
Correggi solo il guasto confermato: ripristina il mount mancante, avvia il broker, ripara il servizio del database, rinnova il riferimento alle credenziali oppure correggi l'alias di rete. Riavvia prima la dipendenza e attendi che il relativo controllo di disponibilità abbia esito positivo; riavvia Home Assistant una sola volta se il suo client non si riconnette automaticamente.
Quando i worker o le integrazioni restano offline dopo l'avvio del componente principale, usa il percorso di risoluzione dei problemi relativo alla disponibilità dei worker per distinguere un avvio ritardato da un confine di dipendenza persistente.
Esegui il rollback se la dipendenza non può tornare allo stato precedente di funzionamento o se la riparazione richiede l'eliminazione dello schema, la ricreazione del database o l'esposizione delle credenziali. Ripristina l'ultima configurazione nota come funzionante e conserva i log di entrambe le parti prima di tentare un ripristino più invasivo.
Riproduci la funzionalità originale e definisci il punto di arresto
Ripeti il test esatto della funzionalità che ha avuto problemi: pubblica e ricevi un valore MQTT usa e getta, carica un intervallo recente dello storico, crea un backup di prova nella destinazione prevista oppure esegui un'automazione interessata. Ripeti il test dopo un riavvio controllato della dipendenza per confermare la riconnessione, non solo la disponibilità immediata.
Il ripristino è valido quando il controllo di salute della dipendenza, lo stato dell'integrazione di Home Assistant e la funzionalità visibile all'utente concordano. Un container in esecuzione con entità non disponibili non rappresenta un ripristino; neppure una dashboard verde mentre le scritture falliscono rappresenta un ripristino.
Fermati quando la funzionalità originale supera il test due volte e non compaiono nuovi errori di dipendenza. Escalation con la prima eccezione, la classe dell'endpoint, il risultato del controllo di disponibilità, la versione della dipendenza e i passaggi di ripristino quando il servizio è raggiungibile ma la negoziazione del protocollo o dello schema continua a non riuscire.
Documenta il contratto di avvio ripristinato
Documenta quale componente possiede la dipendenza, il relativo segnale di disponibilità, il comportamento dei tentativi, l'origine delle credenziali, il nome di rete, il percorso di archiviazione e l'ordine di ripristino. L'operatore successivo deve poter distinguere l'avvio del processo da un servizio utilizzabile senza dover ricostruire l'incidente.
Esegui un riavvio pianificato della dipendenza durante una finestra di manutenzione e conferma che Home Assistant si riconnetta entro il limite registrato. Se è ancora richiesto un intervento manuale, indica questa limitazione invece di contrassegnare la dipendenza come completamente resiliente.
Chiudi l'incidente solo dopo che il monitoraggio è in grado di rilevare sia il guasto della dipendenza sia il ripristino della funzionalità. Se il monitoraggio rileva soltanto che il processo principale è in esecuzione, conserva lo stesso punto cieco che ha causato lo stato di avvio incompleto.
Supporto e consigli
Altro da leggere

Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...

Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...

Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...

