Så konfigurerar du cache och temporär lagring i Home Assistant

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Konfigurera Home Assistants cache genom att först identifiera vilka data som kan tas bort; flytta aldrig hela sökvägen för den beständiga konfigurationen till tillfällig lagring.

”Cache” kan betyda webbläsarens frontendresurser, TTS-utdata, tillfälliga filer som är specifika för en integration, en containers /tmp, operativsystemets sidcache eller databasens arbetsutrymme. Dessa lager har olika ägare och återställningsbeteenden. Behåll användare, register, konfiguration, Recorder-tillstånd och andra auktoritativa filer på beständig lagring. Använd tmpfs eller RAM-baserad lagring endast för en dokumenterad, tillfällig sökväg vars dataförlust och minnesanvändning du har testat genom omstart.

Klassificera cachen innan du flyttar någon sökväg

Börja med att ange ägare, sökväg, förväntad maximal storlek, återskapandemetod och vad som händer om data försvinner. Webbläsarens cache finns på klienten; Home Assistants beständiga applikationstillstånd finns under den konfigurerade datasökvägen; integrationscache varierar; tillfälliga containerfiler kan försvinna vid omstart. De bör inte hanteras med en enda global inställning för ”cachekatalog”.

Ett Home Assistant TTS-fall visar ett avgränsat exempel där genererat ljud under en specifik cachesökväg avsiktligt omdirigerades till en RAM-baserad plats. Den viktiga gränsen vid flytt av en tillfällig TTS-cache är att användaren riktade in sig på en enda återskapningsbar katalog, inte hela konfigurationsträdet.

Om du inte kan bevisa att en fil kan försvinna utan att identitet, historik, inställningar, instrumentpaneler eller integrationsregistrering går förlorade, ska den klassificeras som beständig. Det säkraste standardvalet är beständig lagring. Optimera först när det är klarlagt vem som ansvarar för återställningen.

Behåll Home Assistants beständiga tillstånd och Recorder på beständig lagring

Konfigurationsmonteringen är inte en cache bara för att den innehåller vissa genererade filer. Den kan innehålla autentisering, register över entiteter och enheter, automationstillstånd, konfiguration, anpassade komponenter och standarddatabasen för Recorder. Om hela sökvägen placeras på tmpfs leder en omstart till dataförlust och säkerhetskopiorna blir beroende av minnesinnehåll som aldrig var avsett att vara auktoritativt.

ZimaSpaces förklaring av Home Assistants roller för beständiga data är det rätta första filtret: skilj auktoritativt tillstånd från återskapningsbar cache och tillfälliga arbetsdata innan du tilldelar lagringsnivåer.

Använd SSD eller ett annat tillförlitligt beständigt filsystem för applikationens tillstånd och reservera tillräckligt med ledigt utrymme för databasens tillväxt, uppgraderingar och underhåll. Att flytta en liten tillfällig cache till RAM kan inte kompensera för en underdimensionerad eller felande beständig volym.

Använd tmpfs endast för uttryckligen tillfälliga sökvägar med en minnesgräns

Tmpfs kan minska antalet skrivningar och ge mycket låg fördröjning, men det förbrukar värdmaskinens RAM och försvinner när containern eller värden stoppas. Därför passar det för begränsade skrapdata, inte för något som krävs efter en omstart. Monteringen måste också dimensioneras så att en tillfällig arbetsbelastning inte kan förbruka det minne som behövs av Home Assistant Core och närliggande tjänster.

En aktuell Docker Compose-guide förklarar att tmpfs-användning räknas av från minneskapaciteten och kan leda till slut på utrymme eller OOM-fel när den är överdimensionerad eller obegränsad i förhållande till containerns budget.

Ange ett storlekstak, övervaka toppanvändningen och starta medvetet om containern. Sökvägen ska fyllas på automatiskt igen medan användare, inställningar, historik och integrationer förblir oförändrade. Om applikationen inte kan återskapa katalogen eller behandlar frånvaron som korruption ska den flyttas tillbaka till beständig lagring.

Behandla frontendcache som ett klientproblem, inte som serverlagring

En inaktuell Home Assistant-sida i en webbläsare kan finnas kvar även när servern fungerar, eftersom frontendresurser cachas av webbläsaren eller appen. Att rensa tillfälliga filer på serversidan löser inte detta klienttillstånd. Omvänt minskar rensning av webbläsarens cache inte Recorder-diskens I/O och gör inte Home Assistant-databasen mindre.

Home Assistant-användare skiljer uttryckligen på frontendcache som webbläsarens cache, vilket är anledningen till att felsökning av cache bör börja med att fastställa om symptomet finns på en enda klient eller på hela servern.

Använd en ren webbläsare eller en privat profil som kontroll. Om den nya klienten fungerar ska åtgärden ligga på frontendnivå. Om alla klienter visar samma saknade data eller serverfel ska du inte fortsätta rensa lokala cacher; återgå i stället till felsökning av Home Assistants loggar, lagring, integrationer eller databas.

Validera tillfällig lagring genom tester av omstart, belastning och ledigt utrymme

Efter att du har ändrat en cache- eller tmpfs-sökväg ska du mäta normal och maximal storlek, tillgängligt minne på värden, minnesbelastning för containern, ledigt utrymme på den beständiga volymen och beteendet vid omstart. Kör sedan arbetsbelastningen som skapar cachen – TTS, media, bearbetning i en anpassad integration eller en annan känd producent – och bekräfta att rensningen sker som förväntat.

Se till att beständig lagring har marginal för åtgärder som behöver tillfälligt arbetsutrymme, även om databasen ryms bekvämt i vardagen. Fyll inte den beständiga volymen bara för att en RAM-cache fick normala skrivningar att se mindre ut; uppgraderingar, databasmaintenance, säkerhetskopior och loggtoppar kan ha helt andra krav på tillfälligt utrymme.

Testet är godkänt när alla tillfälliga sökvägar kan försvinna och återskapas, beständigt tillstånd överlever omstart av både container och värd, tmpfs toppanvändning håller sig inom minnesbudgeten och Home Assistant fortfarande har tillräckligt med ledigt beständigt utrymme. Om någon nödvändig inställning eller historik försvinner efter testet var sökvägen felklassificerad och måste återföras till beständig lagring innan ytterligare optimering.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.