Dacă folosiți Home Assistant de ceva vreme și ați adăugat, la fel ca mine, zeci de dispozitive, este foarte probabil să fi observat o senzație de încetinire. Interfața nu mai răspunde la fel de rapid, graficele istorice se încarcă greu, iar uneori chiar și automatizările par să aibă o mică întârziere.
În 99% din cazuri, vinovatul nu este hardware-ul, ci componenta recorder și baza de date implicită, SQLite. Implicit, Home Assistant salvează absolut totul – fiecare schimbare de atribut, fiecare actualizare de senzor, fiecare trigger de automatizare. Într-o instalație matură, asta înseamnă mii sau zeci de mii de scrieri în baza de date în fiecare oră. Baza de date SQLite, deși excelentă pentru a începe, pur și simplu nu este concepută pentru acest nivel de încărcare.
Curios să văd cât de „vorbăreață” e instalația, la câteva minute după conectarea la MySQL am mișcat câțiva senzori și am verificat numărul de înregistrări:
Recent, m-am confruntat cu această problemă și am decis să fac două optimizări majore care au transformat complet performanța instanței mele de Hassio: migrarea bazei de date pe un server MySQL (MariaDB) și filtrarea agresivă a datelor salvate în istoric.
Iată configurația mea finală și explicația detaliată a fiecărei linii, în caz că doriți să faceți același lucru.
1. SQLite vs. MySQL
Configurația implicită a Home Assistant folosește o bază de date SQLite. Aceasta este un singur fișier (home-assistant_v2.db) stocat pe același disc cu restul sistemului.
Problemele cu SQLite (mai ales într-un VM):
- Blocarea la Scriere: SQLite nu este optimizat pentru scrieri concurente. Fiecare actualizare de senzor blochează temporar baza de date pentru a scrie direct pe disc. Când sute de entități raportează constant, aceste micro-blocări se adună și încetinesc întregul Home Assistant.
- I/O Intensiv pe Disc: Toate aceste scrieri pun presiune inutilă pe discul VM-ului vostru, accelerându-i degradarea.
Soluția este să mutați baza de date pe un server de baze de date specializat (MySQL, MariaDB, PostgreSQL). Eu am ales MySQL (MariaDB, mai exact). Deși rulează pe același server Proxmox (într-un container docker, instalat într-un container LXC Debian 12), avantajul este major.
recorder: db_url: mysql://uhassio:phassio@10.20.30.106:3306/homeassistant?charset=utf8mb4
Notă: În exemplul de mai sus, uhassio este utilizatorul bazei de date, iar phassio este parola. Asigurați-vă că le înlocuiți cu propriile voastre credențiale.
Făcând asta, am obținut:
- Performanță Superioară: MySQL este un SGBD robust, conceput să gestioneze mii de tranzacții simultane.
- Optimizarea Scrierilor (I/O): Punctul cheie. Spre deosebire de SQLite, care blochează baza de date pentru a scrie pe disc la fiecare mic eveniment, MySQL/MariaDB este conceput să gestioneze mii de tranzacții. Acumulează schimbările în memorie și le scrie pe disc eficient, în „calupuri” (proces optimizat și de setarea
commit_intervalde mai jos). Chiar dacă rulează pe același server fizic, VM-ul Home Assistant nu mai este blocat de I/O și se poate concentra pe automatizări. - Fiabilitate: O bază de date de acest tip (SGBD) este mult mai rezistentă la corupere.
2. Optimizarea Scrierilor și Mentenanța
Chiar și cu MySQL, putem optimiza cât de des și cât de mult scriem.
recorder: purge_keep_days: 30 commit_interval: 5 auto_purge: true auto_repack: true
- purge_keep_days: 30: Instruiește Home Assistant să șteargă automat orice dată istorică mai veche de 30 de zile. Acest lucru este crucial pentru a menține dimensiunea bazei de date sub control. Pentru majoritatea analizelor, 30 de zile sunt mai mult decât suficiente.
- commit_interval: 5: Aceasta este o optimizare majoră, care completează perfect mutarea pe MySQL. În loc ca Home Assistant să scrie în baza de date instantaneu la fiecare mică schimbare de stare, acum grupează (face „batch”) schimbările. Aceste date stau în RAM timp de 5 secunde, după care sunt scrise simultan în baza de date. Acest lucru reduce dramatic numărul total de tranzacții pe secundă.
- auto_purge: true: Activează purjarea automată menționată mai sus.
- auto_repack: true: (Notă: Această opțiune este specifică pentru SQLite și este ignorată de MySQL, dar nu strică să fie acolo dacă vă întoarceți vreodată la SQLite pentru teste).
3. Filtrarea Agresivă: Cheia Performanței
Aceasta este cea mai importantă parte a optimizării. După cum spuneam, implicit recorder salvează absolut totul. Noi îi vom spune să ignore entitățile „zgomotoase” care generează date inutile, dar păstrează spațiu și încetinesc interogările.
Pentru a afla care sunt acestea, lăsăm Home Assistant să funcționeze 2-3 zile, apoi verificăm care au fost dispozitivele cele mai vorbărețe (adaptând comanda la serverul vostru MariaDB/MySQL):
docker exec -it mariadb mariadb -uuhassio -p'phassio' homeassistant -e "SELECT sm.entity_id, COUNT(*) as last_24h_records FROM states s JOIN states_meta sm ON s.metadata_id = sm.metadata_id WHERE s.last_updated_ts > UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 24 HOUR)) GROUP BY sm.entity_id ORDER BY last_24h_records DESC LIMIT 5;"
Filtrarea pe Domenii (domains)
Aici excludem categorii întregi de entități care nu ne interesează în istoric.
exclude:
domains:
- automation
- updater
- sun
- automation: Exclud stările automatizărilor (ex. „ultima rulare”). Ocupă spațiu inutil și pot fi văzute oricum în Logbook dacă e nevoie.
- updater: Informații despre actualizări. Total inutile în istoric.
- sun: O excludere clasică și esențială. Entitatea
sun.sunîși schimbă atributele (azimut, elevație) în fiecare minut. Salvarea acestor date este o risipă uriașă de resurse.
Filtrarea „Zgomotoșilor” (entity_globs)
entity_globs ne permite să folosim caractere „wildcard” (*) pentru a exclude grupuri de senzori care urmează un tipar.
entity_globs:
# Uptime & system sensors
- sensor.uptime*
- sensor.*_uptime*
# Signal strength (WiFi/BLE/Zigbee)
- sensor.*_signal_strength
- sensor.*_rssi
- sensor.*_linkquality
- Senzori de Uptime și Semnal: Aceștia sunt, de departe, cei mai mari vinovați. Se actualizează constant (la fiecare câteva secunde sau minute) și fluctuează des. Istoricul lor pe 30 de zile este aproape inutil (când v-ați uitat ultima oară pe un grafic de 30 de zile al semnalului WiFi al unui bec?). Excluzându-i, am redus probabil cu 50-70% totalul scrierilor în baza de date.
Un compromis conștient
Aici am făcut un compromis conștient. Am decis că performanța generală a sistemului este mai importantă decât istoricul detaliat al acestor senzori pe care-i folosesc exclusiv pentru a controla luminile și încălzirea, nefiindu-mi utili la altceva.
# Location tracking
- sensor.*_distance
- sensor.bermuda*
- sensor.*_visible_device_count
- sensor.*_total_device_count
# Motion sensors (ocupare + iluminare)
- binary_sensor.motion*_occupancy
- sensor.motion*_illuminance
- Location & Motion: Senzorii de prezență (distanță, BLE) și cei de mișcare/lumină sunt, de asemenea, foarte „zgomotoși” (lumina fluctuează, mișcarea se activează/dezactivează des).
- Dezavantajul: Prin excluderea lor, sacrific abilitatea de a vedea grafice istorice pentru ocupație sau nivelul de iluminare. Deoarece folosesc acești senzori doar pentru automatizări (care rulează în timp real), și nu pentru analiză istorică, excluderea lor este un câștig net de performanță.
Entități Specifice
În final, adăugăm câteva entități specifice pe care nu le-am prins cu filtrele glob.
entities:
- sensor.iphone_16_distance
- sensor.esp32_bluetooth_proxy_birou_uptime_sensor
- sensor.temperature_humidity_sensor_8e27_signal_strength
Ce se întâmplă cu entitățile excluse?
Este important de înțeles că excluderea unei entități din recorder nu o șterge și nu o oprește din funcționare. Entitatea va fi în continuare vizibilă în Home Assistant și, cel mai important, va putea fi folosită în automatizări care depind de starea ei în timp real (de exemplu, un senzor de mișcare va aprinde lumina).
Singurul lucru care se întâmplă este că Home Assistant nu mai salva istoricul stărilor sale în baza de date. Prin urmare, nu veți mai putea vedea grafice istorice pentru acea entitate (cum ar fi graficul semnalului Wi-Fi din ultimele 30 de zile), dar sistemul general va deveni mult mai rapid deoarece baza de date va fi mai mică și mai eficientă.
Configurația Finală
Iată fișierul meu complet recorder.yaml (sau secțiunea din configuration.yaml):
recorder:
db_url: mysql://uhassio:phassio@10.20.30.106:3306/homeassistant?charset=utf8mb4
db_retry_wait: 30
db_max_retries: 20
purge_keep_days: 30
commit_interval: 5
auto_purge: true
auto_repack: true
exclude:
domains:
- automation
- updater
- sun
entity_globs:
# Uptime & system sensors
- sensor.uptime*
- sensor.*_uptime*
# Signal strength (WiFi/BLE/Zigbee)
- sensor.*_signal_strength
- sensor.*_rssi
- sensor.*_linkquality
# Location tracking
- sensor.*_distance
- sensor.bermuda*
- sensor.*_visible_device_count
- sensor.*_total_device_count
# Motion sensors (ocupare + iluminare)
- binary_sensor.motion*_occupancy
- sensor.motion*_illuminance
entities:
- sensor.iphone_16_distance
- sensor.esp32_bluetooth_proxy_birou_uptime_sensor
- sensor.temperature_humidity_sensor_8e27_signal_strength
Concluzia: Rezultatele
După implementarea acestei configurații și repornirea Home Assistant, rezultatele au fost imediate și impresionante:
- Latență Redusă: Interfața este vizibil mai rapidă. Nu mai există acea secundă de „gândire” la deschiderea panourilor.
- Bază de Date Mult Mai Mică: Baza de date crește acum mult mai încet și stochează doar datele pe care le consider cu adevărat utile (ex. temperatură, consum de energie).
- Interfață Istoric Rapidă: Încărcarea graficelor și a paginii de Istoric este exponențial mai rapidă, deoarece Home Assistant nu mai trebuie să proceseze milioane de înregistrări inutile (cum ar fi
sensor.uptimede acum 3 săptămâni). - Backup-uri Mai Mici și Rapide: O bază de date mai mică înseamnă backup-uri mai rapide și mai ușor de gestionat.
Pe scurt, am transformat componenta recorder dintr-o „frână” care înregistra totul orbește, într-un instrument de logging suplu și eficient. Dacă instalația voastră de Home Assistant dă semne de oboseală, recomand cu tărie să urmați acești pași.




