Vad orsakar tillväxt av metadata och historik i Home Assistant vid styrning av hela hemmet?

Home Assistants ”metadataökning” är lätt att feldiagnostisera eftersom flera olika dataklasser finns runt samma installation. Enhets- och entitetsregister bevarar identiteter och konfigurationsrelationer; konfigurationsträdet lagrar UI-hanterat tillstånd; Recorder lagrar den betydligt större tidsserien av tillståndsändringar och händelser; långtidsstatistik bevarar utvalda aggregat längre än den råa historiken.

Styrning av hela hemmet ökar dessa lager på olika sätt. När du lägger till enheter växer registren långsamt, medan nya högfrekventa sensorer eller entiteter med många attribut kan få databasen att växa snabbt. Innan du ändrar lagringstiden eller raderar filer bör du identifiera vilket lager som faktiskt ökar.

Entitets- och enhetsregister växer med hanterade objekt

Home Assistant sparar beständiga registerposter så att en entitet kan behålla sin identitet, användaranpassningar, enhetsrelation, områdestilldelning och integrationsägarskap efter omstarter. Dessa metadata är inte samma sak som alla historiska sensorvärden.

Den aktuella modellen för enhetsregistret beskriver hur enheter bevarar relationer till konfigurationsposter och de entiteter som representerar deras funktioner. När hemmet får fler integrationer, bryggor, underordnade enheter och entiteter blir registret naturligt mer komplext.

Registertillväxten är vanligtvis måttlig jämfört med Recorder. Tusen entitetsdefinitioner är viktiga ur driftssynpunkt, men tusen entiteter som var och en producerar hundratals eller tusentals historikrader kan dominera lagringsutrymmet.

Recorder växer utifrån ändringsfrekvens, inte bara antalet enheter

Recorder skriver tillståndsändringar och utvalda händelser. En dörrkontakt som ändras två gånger om dagen kan kräva mindre lagringsutrymme än en effektsensor som rapporterar med några sekunders mellanrum, trots att båda räknas som en entitet i översikten.

Ett optimeringsfall från 2026 visade att en Home Assistant-databas nådde 963 MB på sex dagar innan undantag för brusiga entiteter minskade den dagliga tillväxten från cirka 160 MB till under 50 MB. De exakta siffrorna varierar mellan installationer; mekanismen gör det inte.

Mät databasens dagliga tillväxt och rangordna entiteterna eller domänerna som skapar flest rader innan du tillämpar en generell minskning av lagringstiden. Bevara den historik som hushållet faktiskt använder.

Attribut kan kräva mer lagringsutrymme än det synliga tillståndet antyder

En entitet kan visa ett kort tillstånd som on, 23.4 eller home, samtidigt som den innehåller en mycket större uppsättning attribut med enhetsdetaljer, prognoser, listor, koordinater eller diagnostiska metadata.

Aktuella utvecklarriktlinjer för Home Assistant varnar uttryckligen för att entiteter med frekventa tillståndsändringar kan få databasen att växa snabbt när extra_state_attributes också ändras ofta. Den rekommenderade inriktningen är att minimera icke-kritiska attribut eller i stället exponera fristående sensorer.

Uppskatta inte lagringsbehovet enbart utifrån entitetens synliga tillstånd. Undersök både tillståndsfrekvens och attributförändringar, särskilt för integrationer som exponerar stora JSON-liknande strukturer.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Statistik skapar en annan kurva för långtidslagring

Rå historik begränsas normalt av lagringstiden, men långtidsstatistik kan bevara aggregat för utvalda sensorer betydligt längre. Det är användbart för energi-, temperatur- och förbrukningstrender eftersom systemet inte behöver varje råvärde för att besvara en fråga om månaden.

Det innebär att radering av gamla råa tillstånd inte nödvändigtvis tar bort all historisk data, och det är avsiktligt. Behandla historik för aktuell felsökning och långsiktig analys som separata lagringsprodukter.

ZimaSpaces modell för sensorlagring visar varför samplingsfrekvens, index, sammanställningar och säkerhetskopieringsgenerationer måste mätas separat i stället för att reduceras till byte per sensor.

Säkerhetskopior mångfaldigar allt som live-systemet bevarar

En större Recorder-databas ökar storleken på säkerhetskopiorna och återställningstiden. Flera bevarade säkerhetskopior kan därför ta mer utrymme än den aktuella live-databasen, särskilt när varje arkiv innehåller en fullständig kopia.

En Recorder-guide från communityn noterar att entiteter med frekventa uppdateringar och stora attribut är vanliga orsaker till en Home Assistant-databas som ständigt växer.

Ställ in lagringstiden för både live-historik och säkerhetskopior. En minskning av den aktiva databasen frigör inte utrymme från gamla oföränderliga säkerhetskopior förrän dessa löper ut.

Gör en granskning av dataroller innan du raderar något

Ställ fyra separata frågor: samlas föråldrade enhets- eller entitetsposter på; vilka entiteter står för flest råa Recorder-ändringar; vilka sensorer behöver legitimt långtidsstatistik; och hur många fullständiga säkerhetskopieringsgenerationer mångfaldigar live-datans lagringsavtryck?

Tillväxt är hälsosam när den motsvarar användbara enheter, historik eller analyser och håller sig inom ett planerat underhålls- och återställningsfönster. Den blir ett problem när ett litet antal brusiga entiteter, inaktuella register eller onödiga säkerhetskopieringsgenerationer förbrukar större delen av kapaciteten.

Vanliga frågor

Är Home Assistants metadata samma sak som Recorder-historik?

Nej. Register- och konfigurationsmetadata beskriver enheter, entiteter, integrationer och UI-hanterat tillstånd. Recorder-historik är en tidsserie av tillståndsändringar och händelser och är vanligtvis det betydligt större lagringslagret.

Gör fler enheter alltid att databasen växer snabbt?

Nej. Ändringsfrekvensen är viktigare än antalet enheter i sig. Några få högfrekventa entiteter eller entiteter med många attribut kan generera mer historik än många lågaktiva brytare och kontakt sensorer.