Gå til indhold
← Alle indlæg

Home Assistant Recorder: Sådan reducerede jeg databasevæksten fra 160 MB/dag til under 50 MB

Min SQLite-database i HA nåede 963 MB på seks dage. Den præcise recorder-konfiguration, der skar den daglige vækst med over 70 %, med komplet YAML.

31. maj 2026 Verificeret på HA 2026.7
Home Assistant Recorder: Sådan reducerede jeg databasevæksten fra 160 MB/dag til under 50 MB

Min SQLite-database i Home Assistant nåede 963 MB på bare seks dage, omkring 160 MB om dagen med 5 dages opbevaring. Det er mere end tre gange så meget, som en veloptimeret opsætning bør give.

Der var ikke én stor synder. Det var et dusin integrationer, der i al stilhed gemte ændringer, som ingen nogensinde slår op i historikken. Her er den præcise konfiguration, der fik væksten ned under 50 MB om dagen, og begrundelsen for hver udeladelse.

Derfor vokser recorder-databasen, uden at du opdager det

Som udgangspunkt gemmer Home Assistants recorder alle ændringer for alle entiteter. Det er det rigtige for de sensorer, du faktisk interesserer dig for: temperatur, energiforbrug og hvem der er hjemme. Men de fleste installationer samler hundredvis af entiteter, der ikke er noget værd som historik:

  • Integrationernes egen diagnostik: Tado opretter 22 sensorer, der holder øje med sin egen API-kvote, hvor ofte den henter data og grænserne for antal kald. De ændrer sig hele tiden og er ubrugelige som historik.
  • Entiteter, der altid er unavailable: FlightRadar24-sensorer for lufthavne, der aldrig kom online, gemmer stadig ændringer.
  • Update-entiteter: 59 af dem, fordelt på firmware og HACS. Det er øjebliksbilleder, ikke tidsserier.
  • Statistik fra enheder: UniFi-adgangspunkter gemmer CPU- og hukommelsesforbrug hvert minut.

Den komplette recorder-konfiguration

Erstat recorder:-blokken i configuration.yaml. Rediger den med tilføjelsesprogrammet Studio Code Server:

recorder:
  purge_keep_days: 5
  exclude:
    domains:
      - update                          # 59 entiteter — øjebliksdata, ikke tidsserier
    entity_globs:
      - sensor.skoda_elroq_*           # EV-integrationsmetadata (se include-undtagelser)
      - sensor.tado_szimnau_*          # ~22 interne Tado polling-diagnostiksensorer
      - sensor.flightradar24_airport_* # 12 sensorer, alle permanent unavailable
      - sensor.u6_lite_*               # UniFi AP-stats — CPU/hukommelse ændres hvert minut
      - sensor.uap_ac_pro_*            # Samme for anden access point
      - sensor.air_conditioning_next_* # Tados schedule-fremskrivningssensorer
    entities:
      - sensor.energi_data_service
      - sensor.pixel_10_last_notification
      - sensor.pixel_10_active_notification_count
      - sensor.pixel_10_media_session
      - sensor.pixel_10_car_speed
      - sensor.pixel_10_car_battery
      - sensor.pixel_10_car_range_remaining
      - sensor.pixel_10_car_odometer
      - sensor.pixel_10_car_charging_status
      - sensor.pixel_10_car_ev_connector_type
      - sensor.pixel_10_car_fuel
      - sensor.pixel_10_car_fuel_type
      - sensor.pixel_10_car_name
      - image.skoda_elroq_main_render_of_vehicle
      - sensor.skoda_elroq_last_operation
      - sensor.skoda_elroq_last_service_event
      - sensor.skoda_elroq_software_version
      - sensor.skoda_elroq_next_inspection_2
  include:
    entities:
      - sensor.skoda_elroq_battery_percentage
      - sensor.skoda_elroq_range
      - sensor.skoda_elroq_charging_state

include:-blokken laver en undtagelse fra mønsteret sensor.skoda_elroq_* for de tre entiteter, jeg faktisk bruger i historikken.

Begrundelsen for udeladelserne

domains: update er den nemmeste gevinst. Opdateringsentiteter for firmware og HACS hører ikke hjemme i en database til tidsserier.

sensor.tado_szimnau_* er det mønster, der gør størst forskel. Tado-integrationen opretter detaljerede sensorer om sig selv: API-kald tilbage i dag, hvor ofte den henter data, grænser for antal kald og hvornår kvoten blev nulstillet. De opdateres ved hvert API-kald, flere gange i timen for hver zone.

sensor.flightradar24_airport_* rammer 12 sensorer med lufthavnsstatistik, der var sat forkert op og hænger fast i unavailable. En entitet, der hele tiden er unavailable, skriver stadig til recorderen.

sensor.u6_lite_* og sensor.uap_ac_pro_* dækker diagnostik fra UniFi-adgangspunkterne. CPU- og hukommelsesforbrug ændrer sig hvert minut, og det giver tusindvis af målinger om ugen, som ingen bruger til noget.

Tag ændringerne i brug uden genstart

Når du har gemt configuration.yaml, så genindlæs recorderen og komprimer databasen i ét trin:

Developer Tools → Actions → recorder.purge
  keep_days: 5
  repack: true

repack: true kører SQLites VACUUM, som fysisk gør databasefilen mindre. Uden den bliver filen ved med at have sin største størrelse, også efter gamle rækker er slettet.

De nye udeladelser virker med det samme. Gamle data for de udeladte entiteter bliver ryddet væk af den normale daglige oprydning over de næste fem dage.

Det, der er værd at gemme

Klimasensorer, energisensorer, elbilens batteri og rækkevidde samt sikkerhedstilstande hører alle hjemme i historikken. Målet er ikke den mindst mulige database, men en database, hvor hver række har et formål.

Nye indlæg direkte i din RSS-læser: følg med via RSS I Google-søgning: vælg szimnau.dk som foretrukken kilde