Wat veroorzaakt de groei van metagegevens en geschiedenis in Home Assistant bij volledige woningautomatisering?

De “metadatagroei” van Home Assistant is makkelijk verkeerd te diagnosticeren, omdat verschillende gegevensklassen rond dezelfde installatie bestaan. Apparaat- en entiteitsregisters bewaren identiteiten en configuratierelaties; de configuratiestructuur slaat door de UI beheerde status op; Recorder bewaart de veel grotere tijdreeks van statuswijzigingen en gebeurtenissen; langetermijnstatistieken bewaren geselecteerde aggregaties nadat de retentie van ruwe geschiedenis is verstreken.

Volledige huisbediening vergroot deze lagen op verschillende manieren. Het toevoegen van apparaten laat registers langzaam groeien, terwijl het toevoegen van sensoren met een hoge frequentie of entiteiten met veel attributen de database snel kan uitbreiden. Bepaal voordat je de retentie wijzigt of bestanden verwijdert welke laag daadwerkelijk groeit.

Entiteits- en apparaatregisters groeien mee met beheerde objecten

Home Assistant bewaart duurzame registergegevens zodat een entiteit na herstarts haar identiteit, gebruikersaanpassingen, apparaatrelatie, gebiedstoewijzing en integratie-eigenaarschap behoudt. Deze metadata is niet hetzelfde als elk historisch sensormonster.

Het huidige model van het apparaatregister beschrijft hoe apparaten relaties met configuratie-items en de entiteiten die hun functies vertegenwoordigen behouden. Naarmate het huis meer integraties, bridges, subapparaten en entiteiten krijgt, wordt dit register vanzelf complexer.

Registergroei is doorgaans bescheiden vergeleken met Recorder. Duizend entiteitsdefinities zijn operationeel belangrijk, maar duizend entiteiten die elk honderden of duizenden historische rijen produceren, kunnen de opslag domineren.

Recorder-groei wordt vooral bepaald door de wijzigingsfrequentie, niet alleen door het aantal apparaten

Recorder schrijft statuswijzigingen en geselecteerde gebeurtenissen weg. Een deurcontact dat twee keer per dag verandert, kan minder opslag kosten dan één vermogenssensor die elke paar seconden rapporteert, ook al tellen beide als één entiteit op het dashboard.

Uit een tuningcasus uit 2026 bleek dat een Home Assistant-database in zes dagen 963 MB bereikte, voordat het uitsluiten van luidruchtige entiteiten de dagelijkse groei verlaagde van ongeveer 160 MB naar minder dan 50 MB. De exacte cijfers zijn installatieafhankelijk; het mechanisme niet.

Meet de dagelijkse databasegroei en rangschik de entiteiten of domeinen die de meeste rijen creëren voordat je de globale retentie verkort. Bewaar de geschiedenis die het huishouden daadwerkelijk gebruikt.

Attributen kunnen meer opslag toevoegen dan de zichtbare status doet vermoeden

Een entiteit kan een korte status tonen, zoals on, 23.4 of home, terwijl ze een veel grotere set attributen bevat met apparaatgegevens, voorspellingen, lijsten, coördinaten of diagnostische metadata.

De huidige ontwikkelaarsrichtlijnen van Home Assistant waarschuwen expliciet dat entiteiten met frequente statuswijzigingen de database snel kunnen laten groeien wanneer extra_state_attributes ook vaak veranderen. De aanbevolen aanpak is om niet-kritieke attributen te beperken of in plaats daarvan afzonderlijke sensorentiteiten beschikbaar te maken.

Schat de opslag niet alleen op basis van de zichtbare entiteitsstatus. Controleer zowel de statusfrequentie als de wijzigingen in attributen, vooral bij integraties die grote JSON-achtige structuren beschikbaar maken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Statistieken zorgen voor een andere retentiecurve op lange termijn

Ruwe geschiedenis wordt normaal gesproken begrensd door retentie, maar langetermijnstatistieken kunnen aggregaties voor geselecteerde sensoren veel langer bewaren. Dat is nuttig voor energie-, temperatuur- en nutstrends, omdat het systeem niet elk ruw monster nodig heeft om een maandelijkse vraag te beantwoorden.

Dit betekent dat het verwijderen van oude ruwe statussen niet noodzakelijk alle historische gegevens verwijdert, en dat is bewust zo ontworpen. Behandel recente geschiedenis voor probleemoplossing en historische gegevens voor langetermijnanalyse als afzonderlijke retentieproducten.

Het sensorretentiemodel van ZimaSpace laat zien waarom monstergfrequentie, indexen, roll-ups en back-upgeneraties afzonderlijk moeten worden gemeten in plaats van te worden teruggebracht tot bytes per sensor.

Back-ups vermenigvuldigen alles wat het actieve systeem bewaart

Een grotere Recorder-database vergroot de back-upomvang en verlengt de hersteltijd. Meerdere bewaarde back-ups kunnen daardoor meer capaciteit innemen dan de huidige actieve database, vooral wanneer elk archief een volledige kopie bevat.

Een communityhandleiding voor Recorder vermeldt dat entiteiten met veel updates en grote attributen veelvoorkomende oorzaken zijn van een voortdurend groeiende Home Assistant-database.

Stel retentie in voor zowel de actieve geschiedenis als de back-ups. Het verkleinen van de actieve database maakt geen ruimte vrij van oude onveranderlijke back-uparchieven totdat die back-ups verlopen.

Voer een audit van gegevensrollen uit voordat je iets verwijdert

Stel vier afzonderlijke vragen: stapelen verouderde apparaat- of entiteitsrecords zich op; welke entiteiten veroorzaken de meeste wijzigingen in de onbewerkte Recorder-gegevens; welke sensoren hebben legitiem langetermijnstatistieken nodig; en hoeveel volledige back-upgeneraties vermenigvuldigen de opslagvoetafdruk van de actieve gegevens?

Groei is gezond wanneer die overeenkomt met nuttige apparaten, geschiedenis of analyses en binnen een geplande onderhouds- en herstelperiode blijft. Het wordt een probleem wanneer een klein aantal luidruchtige entiteiten, verouderde registers of onnodige back-upgeneraties het grootste deel van de capaciteit verbruikt.

Veelgestelde vragen

Is de metadata van Home Assistant hetzelfde als de Recorder-geschiedenis?

Nee. Register- en configuratiemetadata beschrijven apparaten, entiteiten, integraties en door de UI beheerde status. Recorder-geschiedenis is een tijdreeks van statuswijzigingen en gebeurtenissen en vormt doorgaans de veel grotere opslaglaag.

Zorgt het toevoegen van meer apparaten altijd voor snelle databasegroei?

Nee. De wijzigingsfrequentie is belangrijker dan alleen het aantal apparaten. Enkele entiteiten met een hoge frequentie of veel attributen kunnen meer geschiedenis genereren dan veel schakelaars en contactsensoren met weinig activiteit.