Home Assistant mostra dati obsoleti dopo una modifica del percorso di archiviazione

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.

Home Assistant Shows Stale Data After a Storage Path Change - Zima Store Online

I dati obsoleti di Home Assistant dopo una modifica al percorso di archiviazione di solito indicano che l'istanza in esecuzione sta leggendo un percorso /config o un database diverso da quello previsto, non che Home Assistant abbia ricreato lo stato precedente dalla memoria.

Interrompi le modifiche ai percorsi e conserva entrambe le posizioni, quella vecchia e quella nuova. Dal container in esecuzione, verifica la sorgente montata, identifica il database e l'istanza attivi, confronta i timestamp e alcuni dati di stato univoci, quindi correggi una sola mappatura. Se la cronologia o i registri potrebbero essere sovrascritti, arresta Home Assistant prima di copiare o rinominare qualsiasi elemento.

Verifica quale percorso vede realmente il container in esecuzione

Ispeziona il container attivo anziché affidarti solo al file Compose. Conferma quale sorgente host è mappata su /config, se si tratta di un bind mount o di un volume denominato e se la sorgente risolta esiste e contiene i file di configurazione previsti. Una dichiarazione apparentemente corretta può differire dal container in esecuzione dopo una ricreazione incompleta.

Una discussione su una migrazione risolta sottolinea che lo spostamento di un container dipende da una cartella di configurazione montata tramite bind mount con autorizzazioni utilizzabili. Questo supporta il controllo iniziale della mappatura attiva, ma non dimostra che ogni caso di dati obsoleti sia dovuto a un problema di autorizzazioni.

Crea un file indicatore innocuo nel percorso host previsto mentre Home Assistant è arrestato, quindi verifica che lo stesso indicatore sia visibile in /config all'interno di un container temporaneo di ispezione. Se è assente, correggi la mappatura. Se è presente, passa a verificare il database e l'identità dell'istanza.

Distingui una copia di file più vecchia da un database esterno

Confronta gli orari di modifica e alcuni dati di configurazione univoci nei percorsi vecchio e nuovo: il nome di un'automazione, una modifica al pannello, un helper o un backup recente. Se la nuova directory è semplicemente una copia più vecchia, non unire selettivamente i file mentre Home Assistant è in esecuzione; scegli l'insieme autorevole e copialo come unità coerente a Home Assistant arrestato.

Controlla l'URL del database del Recorder. Lo spostamento di /config non sposta un database MariaDB o PostgreSQL esterno e una configurazione ripristinata potrebbe continuare a puntare al database precedente. Se le entità attuali sono corrette ma la cronologia è vecchia, l'ipotesi del database è più probabile di una discrepanza completa della configurazione.

L'articolo di ZimaSpace sui dati persistenti dopo la ricreazione dello stack spiega il problema correlato: un mount vuoto può sembrare una perdita di dati, mentre un mount più vecchio può far sembrare che i dati siano tornati indietro nel tempo.

Escludi un'istanza duplicata e una cache limitata al client

Conferma che l'URL del browser, il nome del server, l'indirizzo IP, l'ID dell'istanza e il certificato appartengano all'host Home Assistant previsto. Durante le migrazioni, un vecchio record DNS, una destinazione del reverse proxy, una voce del server nell'app mobile o un vecchio host ancora acceso possono indirizzare client diversi verso istanze diverse.

Confronta la stessa entità e lo stesso timestamp della cronologia in una sessione privata del browser e su un secondo client. Se solo un client è obsoleto mentre i log del server e un altro client sono aggiornati, cancella la connessione del client o i dati della cache del frontend invece di modificare nuovamente l'archiviazione.

Se i client alternano lo stato vecchio e quello nuovo, arresta la vecchia istanza e correggi le destinazioni DNS, del proxy o del bilanciatore del carico. Non consentire a due controller di eseguire automazioni sugli stessi dispositivi mentre verifichi l'identità.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Correggi una sola mappatura e conserva una copia per il ripristino

Arresta Home Assistant, crea uno snapshot o una copia di entrambi i percorsi candidati e identifica ciascuno con host, data e stato noto. Seleziona /config e il database autorevoli come insieme coerente per il ripristino. Correggi solo la mappatura del container o l'URL del database responsabile della discrepanza verificata.

Controlla la proprietà e l'accesso in scrittura prima dell'avvio. Se il container può leggere il percorso scelto ma non può scrivervi, il sistema potrebbe sembrare corretto inizialmente e poi non riuscire a salvare il nuovo stato. Non applicare modifiche ricorsive generiche alle autorizzazioni senza aver verificato l'identità del servizio e la proprietà prevista.

Avvia Home Assistant una sola volta e controlla i log prima di apportare ulteriori modifiche. Se compaiono le entità, i pannelli, la cronologia e le modifiche recenti previste, continua con i test di persistenza. In caso contrario, arresta il sistema e torna alla copia identificata invece di combinare i due alberi di dati.

Verifica che i dati corretti sopravvivano alla ricreazione e al riavvio

Apporta una modifica di test reversibile, ad esempio crea un helper temporaneo o rinomina un'automazione di prova. Riavvia Home Assistant e verifica che la modifica rimanga. Quindi ricrea il container dalla configurazione di distribuzione salvata e controlla nuovamente.

Un risultato positivo mostra la stessa identità dell'istanza, la cronologia prevista, i registri aggiornati, la sorgente di mount corretta, scritture riuscite e l'assenza di un controller duplicato. Verifica che un nuovo backup includa lo stato selezionato e conservalo lontano da entrambi i percorsi di migrazione.

Richiedi assistenza se i dati cambiano a seconda del client, se la cronologia proviene da un database diverso da quello dello stato attivo o se il percorso corretto diventa di sola lettura dopo il riavvio. Conserva i dati dell'ispezione dei mount, l'URL del database, i timestamp, i log e le due copie di ripristino intatte, così il passaggio successivo potrà concentrarsi sul ramo ancora da verificare.