Come verificare se Home Assistant sta utilizzando il file di configurazione previsto

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.

How to Tell Whether Home Assistant Is Using the Expected Configuration File

Home Assistant utilizza il file di configurazione previsto solo quando la directory di configurazione riportata dal runtime, il percorso dell’host montato e un test di convalida controllato indicano tutti lo stesso file.

Questa confusione è comune quando /config esiste all’interno di un container ma corrisponde a una directory diversa sull’host, oppure quando un vecchio bind mount e una copia modificata di recente contengono entrambi configuration.yaml. Innanzitutto registra il percorso di runtime, traccia il relativo mount senza modificarlo, confronta l’identità e i timestamp dei file, quindi usa un indicatore innocuo e reversibile per dimostrare quale albero viene letto dall’istanza in esecuzione.

Registra la directory di configurazione riportata dall’istanza in esecuzione

Apri Informazioni di sistema dall’istanza Home Assistant in esecuzione e registra esattamente la directory di configurazione mostrata. Registra anche il tipo di installazione, la versione Core, il nome del container o della macchina virtuale e l’ora dell’ultimo riavvio completato correttamente. In questo modo stabilisci la visualizzazione del runtime prima che i percorsi dell’host complichino la situazione.

Le spiegazioni della community mostrano perché /config può riferirsi a un percorso interno mentre la directory host corrispondente può variare in base all’installazione. La distinzione utile è dentro o fuori dal container, non un’unica posizione universale nel filesystem.

Se la directory riportata contiene il file che hai modificato nello stesso namespace di runtime, procedi con la verifica del file. In caso contrario, interrompi la modifica di quella copia. Se l’interfaccia non è disponibile, controlla il processo in esecuzione oppure gli argomenti e i mount del container, invece di basarti sulle supposizioni di un vecchio tutorial.

Traccia il percorso dell’host attraverso il mount attivo

Ispeziona il container o il servizio Compose in esecuzione e individua la sorgente mappata sulla directory di configurazione del runtime. Risolvi i percorsi relativi partendo dalla directory effettiva del progetto Compose. Per un’installazione su macchina virtuale o HAOS, distingui il percorso guest dai dati visibili all’hypervisor.

Un problema del progetto Home Assistant ha documentato una situazione in cui l’interfaccia mostrava il percorso interno al container mentre i dati effettivi dell’host HAOS si trovavano altrove. Questo caso di percorso host rispetto al container conferma l’importanza di tracciare il mount, non di copiare il percorso esatto in un’altra installazione.

Confronta la sorgente del mount attivo con la directory utilizzata dal tuo editor o dalla condivisione di file. Se differiscono, non unirle ancora. Conserva entrambi gli alberi, annota le rispettive date di modifica e dimensioni e identifica quello che contiene il registro delle entità corrente, le automazioni e l’attività recente nei log.

Dimostra l’identità del file con una modifica controllata e sicura

Prima del test, esegui il controllo della configurazione nello stesso runtime ed effettua un backup dell’albero attivo. Aggiungi al file sospetto un commento innocuo con un nome univoco, o un altro indicatore reversibile, salvalo e verifica che il timestamp cambi nel percorso a cui punta il mount del runtime.

Utilizza il normale percorso di convalida della configurazione, quindi ricarica solo il dominio ricaricabile pertinente, quando possibile. Se è necessario un riavvio completo, riavvia una sola volta dopo la convalida e controlla nei log il file o l’integrazione modificata. Un riavvio senza aver verificato il percorso può semplicemente caricare di nuovo il file sbagliato.

L’articolo correlato di ZimaSpace sul percorso dei dati di Home Assistant aiuta a distinguere lo stato visibile del frontend dai file persistenti di configurazione e del registro che lo hanno generato.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Correggi il mount e verifica la persistenza

Se è montata la sorgente sbagliata, arresta Home Assistant, conserva entrambe le directory e correggi solo la definizione del mount che ricrea il container. Verifica proprietario e autorizzazioni prima dell’avvio. Non sovrascrivere un albero più recente con uno precedente, a meno che tu non abbia scelto esplicitamente quali dati debbano prevalere.

Dopo l’avvio, ripeti la verifica del percorso di runtime, del mount, del timestamp, della configurazione e dell’indicatore. Un risultato positivo dimostra che viene letto il file previsto, che i registri correnti rimangono presenti e che la stessa mappatura persiste dopo la ricreazione del container o il riavvio dell’host.

Ripristina il mount precedente se Home Assistant si avvia senza dati, perde le integrazioni o segnala errori di autorizzazione. Se la mappatura rimane ambigua, fornisci il tipo di installazione, la directory di runtime, la sorgente e la destinazione del mount e un elenco sanificato delle directory; elimina gli alberi duplicati solo dopo aver verificato il ripristino in modo indipendente.