Home Assistant visar inaktuella data efter en ändring av lagringssökvägen

Inaktuella Home Assistant-data efter en ändring av lagringssökvägen betyder vanligtvis att den körande instansen läser en annan /config eller databas än den du förväntar dig, inte att Home Assistant har återskapat gammalt tillstånd från minnet.

Sluta göra sökvägsändringar och bevara både de gamla och nya datalokationerna. Från den körande containern ska du verifiera den monterade källan, identifiera den aktiva databasen och instansen, jämföra tidsstämplar och unika tillstånd och först därefter korrigera en mappning. Om historik eller register kan komma att skrivas över ska du stoppa Home Assistant innan du kopierar eller byter namn på något.

Verifiera vilken sökväg den körande containern faktiskt ser

Inspektera den aktiva containern i stället för enbart Compose-filen. Bekräfta värdkällan som är mappad till /config, om det är en bind-montering eller en namngiven volym, samt om den upplösta källan finns och innehåller de förväntade konfigurationsfilerna. En deklaration som ser korrekt ut kan skilja sig från den körande containern efter en ofullständig återskapning.

En genomgång av en löst migreringsfråga betonar att en containerflytt kräver en korrekt bind-mappad konfigurationsmapp med användbara behörigheter. Det stöder att du kontrollerar den aktiva mappningen först, men bevisar inte att alla fall med inaktuella data beror på ett behörighetsfel.

Skapa en ofarlig markörfil i den avsedda värdsökvägen medan Home Assistant är stoppat och bekräfta sedan att samma markör syns i /config i en tillfällig inspektionscontainer. Om den saknas ska du åtgärda mappningen. Om den finns fortsätter du med att kontrollera databasens och instansens identitet.

Skilj en äldre filkopia från en extern databas

Jämför ändringstider och några unika konfigurationsdetaljer mellan de gamla och nya sökvägarna: ett automationsnamn, en ändring av en instrumentpanel, en hjälpare eller en aktuell säkerhetskopia. Om den nya katalogen helt enkelt är en äldre kopia ska du inte slå ihop filer selektivt medan Home Assistant körs. Välj i stället den auktoritativa uppsättningen och kopiera den som en stoppad, konsekvent enhet.

Kontrollera Recorders databas-URL. Att flytta /config flyttar inte en extern MariaDB- eller PostgreSQL-databas, och en återställd konfiguration kan fortfarande peka på den tidigare databasen. Om aktuella entiteter ser korrekta ut men historiken är gammal är databasförklaringen starkare än en fullständig konfigurationsmismatch.

ZimaSpace-artikeln om beständiga data efter att stacken återskapats beskriver det närliggande felet: en tom montering kan se ut som dataförlust, medan en äldre montering kan se ut som att data har rullats tillbaka.

Uteslut en dubblettinstans och cache som bara finns på klienten

Bekräfta att webbläsarens URL, servernamn, IP-adress, instans-ID och certifikat tillhör den avsedda Home Assistant-värden. Under migreringar kan en gammal DNS-post, ett mål i en omvänd proxy, en serverpost i mobilappen eller en påslagen gammal värd skicka olika klienter till olika instanser.

Jämför samma entitet och historiktidsstämpel i en privat webbläsarsession och på en andra klient. Om bara en klient är inaktuell medan serverloggarna och en annan klient är aktuella ska du rensa klientens anslutning eller cachade frontenddata i stället för att ändra lagringen igen.

Om klienterna växlar mellan gammalt och nytt tillstånd ska du stoppa den gamla instansen och korrigera målen för DNS, proxy eller lastbalanserare. Låt inte två styrenheter köra automatiseringar mot samma enheter medan du utreder identiteten.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Korrigera en mappning och bevara en återställningskopia

Stoppa Home Assistant, ta en ögonblicksbild av eller kopiera båda kandidatvägarna och märk dem med värd, datum och känt tillstånd. Välj den auktoritativa /config-katalogen och databasen som ett matchat återställningsset. Korrigera endast den containermappning eller databas-URL som orsakar den verifierade avvikelsen.

Kontrollera ägarskap och skrivåtkomst innan du startar. Om containern kan läsa den valda sökvägen men inte skriva till den kan systemet verka korrekt inledningsvis och sedan misslyckas med att spara nya tillstånd. Använd inte breda rekursiva behörighetsändringar utan att först bekräfta tjänstens identitet och förväntade ägarskap.

Starta Home Assistant en gång och granska loggarna innan du gör fler ändringar. Om de förväntade entiteterna, instrumentpanelerna, historiken och de senaste ändringarna visas fortsätter du med att testa beständighet. Om inte ska du stoppa och återgå till den märkta kopian i stället för att kombinera de två dataträden.

Verifiera att rätt data överlever återskapning och omstart

Gör en reversibel teständring, till exempel genom att skapa en tillfällig hjälpare eller byta namn på en testautomation. Starta om Home Assistant och bekräfta att ändringen finns kvar. Återskapa sedan containern från den sparade distributionskonfigurationen och kontrollera igen.

Ett godkänt resultat visar samma instansidentitet, förväntad historik, aktuella register, korrekt monteringskälla, lyckade skrivningar och ingen dubblettstyrenhet. Bekräfta att en ny säkerhetskopia innehåller det valda tillståndet och lagra den åtskild från båda migreringsvägarna.

Eskalerа om data ändras beroende på klient, om historiken kommer från en annan databas än det aktiva tillståndet eller om den korrekta sökvägen blir skrivskyddad efter omstart. Bevara information om monteringsinspektionen, databas-URL:en, tidsstämplar, loggar och de två orörda återställningskopiorna så att nästa steg kan inriktas på den återstående grenen.