Home Assistant è una piattaforma potentissima, ma con il tempo e l’aggiunta di decine (o centinaia) di dispositivi, integrazioni, automazioni e dashboard personalizzate, può iniziare a rallentare visibilmente: interfaccia web che impiega secondi a caricare, automazioni che triggherano in ritardo, notifiche che arrivano con delay, CPU costantemente al 100%. Questi sintomi indicano che è ora di ottimizzare la configurazione per ristabilire fluidità e reattività.
Questa guida ti mostrerà tecniche concrete e testate per ridurre drasticamente carico sistema, tempi di risposta e consumo risorse, applicabili sia a installazioni Raspberry Pi (risorse limitate) che server dedicati (ottimizzazione preventiva).
Diagnostica iniziale: identificare i colli di bottiglia
System Monitor: dashboard risorse
Prima di ottimizzare, devi capire cosa sta causando il problema. Aggiungi il System Monitor per monitorare risorse:
Abilitazione System Monitor:
-
Impostazioni > Dispositivi e servizi > Aggiungi integrazione
-
Cerca “System Monitor”
-
Abilita sensori:
-
Processor use (% CPU)
-
Memory use percent (% RAM)
-
Disk use percent (% storage)
-
Load (1m, 5m, 15m)
-
Database size
-
Crea dashboard monitoraggio:
type: entities title: System Health entities: - sensor.processor_use_percent - sensor.memory_use_percent - sensor.disk_use_percent - sensor.home_assistant_v2_db - sensor.load_1m
Valori normali vs problematici:
-
CPU < 30%: normale | CPU > 70% costante: problema grave
-
RAM < 50%: normale | RAM > 80%: rischio crash imminente
-
Database < 2GB: normale | Database > 10GB: purge urgente necessario
-
Load 1m < 1.0 (Raspberry Pi 4): normale | Load > 3.0: sovraccarico
Identificare integrazioni pesanti
Strumento Developer Tools > Info:
Configurazione > Sistema > Log
Cerca warning tipo:
WARNING (MainThread) [homeassistant.components.recorder] Recorder queue is filling up WARNING (MainThread) [homeassistant.util.executor] Task took longer than 10 seconds
Questi indicano che alcune integrazioni stanno rallentando il database recorder.
Ottimizzazione database: il fattore più critico
Problema: database SQLite su SD card
Home Assistant di default usa database SQLite che salva tutto lo storico di ogni entità sul filesystem. Su Raspberry Pi con SD card, questo causa:
-
Scritture continue degradano SD card (life span ridotto)
-
Query lente su database giganti (>5GB)
-
Bottleneck I/O disk rallenta tutto il sistema
Soluzione 1: Configurare Recorder per ridurre dati salvati
Modifica configuration.yaml:
recorder:
# Mantieni solo 7 giorni storico (vs 10 default)
purge_keep_days: 7
# Commit database ogni 5 secondi (vs 1 default, riduce scritture)
commit_interval: 5
# Esclude domini non necessari in storico
exclude:
domains:
- automation # Non serve storico automazioni
- updater
- weather
- sun
entity_globs:
- sensor.uptime*
- sensor.last_boot*
- binary_sensor.*_updating
entities:
- sensor.time
- sensor.date
- sensor.time_utc
# Includi solo entità che vuoi tracciare (approccio whitelist)
# include:
# domains:
# - light
# - switch
# - climate
# - sensor
# entity_globs:
# - sensor.temperature_*
# - sensor.power_*
Riavvia Home Assistant dopo modifica.
Risultato atteso:
-
Database smette di crescere esponenzialmente
-
Riduzione scritture SD card del 60-80%
-
Query history più veloci (meno dati da scansionare)
Soluzione 2: Purge manuale database esistente
Se database è già enorme (>5GB), recorder configurato non basta. Serve purge manuale.
Purge tramite Developer Tools > Services:
service: recorder.purge data: keep_days: 3 # Elimina tutto più vecchio di 3 giorni repack: true # Ricompatta database dopo eliminazione
Attenzione: purge con repack: true può impiegare 10-30 minuti su database grandi. Durante questo tempo HA funziona ma è lento. Eseguilo di notte o quando non usi HA attivamente.
Automazione purge settimanale:
automation:
- alias: "Database Purge Settimanale"
trigger:
- platform: time
at: "03:00:00" # 3 di notte
condition:
- condition: time
weekday:
- sun # Solo domenica
action:
- service: recorder.purge
data:
keep_days: 7
repack: true
Soluzione 3: Migrare a MariaDB (avanzato, massime performance)
Per setup avanzati o se hai server dedicato, MariaDB offre performance superiori vs SQLite.
Vantaggi MariaDB:
-
Query 3-5x più veloci su database grandi
-
Gestione concorrenza migliore (più integrazioni che scrivono simultaneamente)
-
Backup incrementali più semplici
Svantaggi:
-
Setup complesso (richiede server MariaDB separato o addon)
-
Consumo RAM aggiuntivo (~200MB)
Installazione su Home Assistant OS (addon):
-
Aggiungi addon “MariaDB” da Supervisor
-
Configura password database
-
Avvia addon
-
Modifica
configuration.yaml:recorder: db_url: mysql://homeassistant:PASSWORD@core-mariadb/homeassistant?charset=utf8mb4 purge_keep_days: 7 # Resto configurazione come sopra
- Riavvia HA → database migra automaticamente a MariaDB
Migrazione database esistente:
HA migra automaticamente tutti i dati al primo avvio con MariaDB configurato (può richiedere 30-60 minuti per database grandi).
Ottimizzazione integrazioni: disabilita ciò che non usi
Audit integrazioni attive
Percorso: Impostazioni > Dispositivi e servizi
Scorri lista e chiediti per ogni integrazione:
-
“La uso ancora?”
-
“Ho dispositivi attivi collegati?”
-
“Genera valore o solo rumore nei log?”
Integrazioni tipicamente inutili da disabilitare:
1. Mobile App su dispositivi non più usati
-
Vecchio smartphone sostituito ma integrazione rimasta
-
Tablet che non usi più da mesi
-
Azione: Rimuovi integrazione, elimina dispositivo associato
2. Integrazioni meteo multiple
-
Hai 3 integrazioni meteo (OpenWeatherMap, Met.no, AccuWeather) ma usi solo una
-
Azione: Disabilita 2 su 3, mantieni solo quella più accurata per tua zona
3. Discovery/SSDP/Zeroconf se non necessari
-
Se non aggiungi dispositivi nuovi frequentemente, disabilita discovery automatico
-
Riduce scan di rete continui
-
Configurazione:
# configuration.yaml default_config: # Commenta questa riga e abilita solo necessari # Abilita manualmente solo questi discovery: ssdp: zeroconf: default_disable: true # Disabilita scan automatico
4. Integrazioni cloud polling frequente
-
Alcune integrazioni interrogano cloud ogni 30 secondi (es: alcuni termostati WiFi)
-
Se non serve aggiornamento così frequente, cerca configurazione
scan_interval:
# Esempio termostato cloud
climate:
- platform: generic_thermostat
scan_interval: 300 # 5 minuti invece di 30 secondi
Rimuovi entità orfane
Problema: Disinstalli integrazione ma entità rimangono nel database occupando spazio.
Soluzione:
-
Impostazioni > Dispositivi e servizi > Entità
-
Filtra per “Non disponibile” (unavailable)
-
Seleziona tutte → Elimina
Automazione pulizia automatica:
automation:
- alias: "Notifica entità non disponibili"
trigger:
- platform: time
at: "09:00:00"
action:
- service: notify.telegram
data:
message: >
Entità non disponibili da più di 7 giorni:
{{ states.sensor | selectattr('state', 'eq', 'unavailable') | list | length }}
Ottimizzazione automazioni: efficienza e trigger smart
Problema: automazioni che triggherano troppo frequentemente
Esempio cattivo:
automation:
- alias: "Luce bagno motion trigger"
trigger:
- platform: state
entity_id: sensor.bagno_illuminance
action:
- service: light.turn_on
entity_id: light.bagno
Problema: Sensore luminosità cambia continuamente (200 lux, 201, 199, 202…) → automazione triggera 100 volte/minuto → CPU al 100%.
Soluzione ottimizzata:
automation:
- alias: "Luce bagno motion trigger ottimizzato"
trigger:
- platform: numeric_state
entity_id: sensor.bagno_illuminance
below: 50
for:
seconds: 5 # Triggera solo se sotto 50 per 5 secondi
condition:
- condition: state
entity_id: binary_sensor.bagno_motion
state: "on"
action:
- service: light.turn_on
entity_id: light.bagno
Ottimizzazioni applicate:
-
numeric_stateinvece distate(triggera solo al crossing soglia) -
for: seconds: 5debounce (evita trigger su fluttuazioni rapide) -
conditionverifica movimento prima di accendere
Usare trigger multipli invece di automazioni duplicate
Esempio cattivo (3 automazioni separate):
# Automazione 1: spegni luci alle 23
- alias: "Spegni soggiorno 23"
trigger:
- platform: time
at: "23:00:00"
action:
- service: light.turn_off
entity_id: light.soggiorno
# Automazione 2: spegni cucina alle 23
- alias: "Spegni cucina 23"
trigger:
- platform: time
at: "23:00:00"
action:
- service: light.turn_off
entity_id: light.cucina
# ... altre 5 automazioni identiche per stanze diverse
Soluzione ottimizzata (1 sola automazione):
automation:
- alias: "Spegni tutte luci alle 23"
trigger:
- platform: time
at: "23:00:00"
action:
- service: light.turn_off
target:
area_id:
- soggiorno
- cucina
- camera
- studio
- bagno
Risultato: 5 automazioni → 1 automazione = 80% riduzione overhead.
Mode automation: evita loop e accumulo
automation:
- alias: "Notifica temperatura alta"
mode: single # Default: non triggera se già in esecuzione
trigger:
- platform: numeric_state
entity_id: sensor.temperatura_soggiorno
above: 28
action:
- service: notify.telegram
data:
message: "Temperatura alta: {{ states('sensor.temperatura_soggiorno') }}°C"
- delay: 00:05:00 # Aspetta 5 minuti prima di completare
Mode disponibili:
-
single: ignora trigger se automazione già running (default, consigliato) -
restart: interrompe run precedente e riavvia (utile per timer che si resettano) -
queued: accoda esecuzioni (attenzione: può causare accumulo se trigger frequenti) -
parallel: esegue istanze multiple simultanee (solo per casi specifici)
Consiglio: usa sempre mode: single a meno che non hai motivo specifico per altro mode.
Ottimizzazione MQTT: ridurre traffico broker
Problema: dispositivi MQTT con update frequenti
Alcuni dispositivi Zigbee/Tasmota inviano aggiornamenti ogni secondo anche quando nulla cambia.
Esempio: Temperatura sensore invia:
21.3°C 21.3°C 21.3°C (inutile, nessun cambio!) 21.4°C 21.4°C
Soluzione: configurare retain e update_interval
Per Zigbee2MQTT:
# zigbee2mqtt/configuration.yaml
devices:
'0x00158d0001234567': # Indirizzo sensore
friendly_name: 'Sensore Temperatura Soggiorno'
temperature_precision: 1 # Arrotonda a 1 decimale
debounce: 60 # Invia update max ogni 60 secondi
Per Tasmota (configurazione dispositivo):
TelePeriod 300 # Invia telemetria ogni 5 minuti (default 60 secondi)
Per ESPHome:
sensor:
- platform: dht
temperature:
name: "Temperatura Bagno"
filters:
- delta: 0.5 # Pubblica solo se cambio > 0.5°C
update_interval: 60s # Leggi ogni 60s invece di 5s default
MQTT Broker su hardware dedicato
Se hai molti dispositivi MQTT (>50), considera spostare Mosquitto Broker su:
-
Raspberry Pi dedicato separato da HA
-
Server sempre acceso (NAS, server casa)
Vantaggi:
-
HA non gestisce traffico MQTT (riduce carico CPU)
-
Broker può crashare/riavviare senza impattare HA
-
Scaling indipendente
Ottimizzazione frontend: dashboard lean
Problema: dashboard con 50+ entità in una pagina
Dashboard con centinaia di entità caricano lentamente, specialmente su smartphone.
Soluzione: dashboard modulari per area
Invece di:
# Dashboard unica con tutto
views:
- title: Casa Completa
cards:
- type: entities
entities: [100 entità...]
Crea dashboard separate:
# dashboard-soggiorno.yaml
views:
- title: Soggiorno
cards:
- type: entities
entities: [solo 15 entità soggiorno]
# dashboard-camera.yaml
views:
- title: Camera
cards:
- type: entities
entities: [solo 10 entità camera]
Risultato: Ogni dashboard carica 10x più veloce.
Usare conditional card per ridurre rendering
type: conditional
conditions:
- entity: binary_sensor.soggiorno_motion
state: "on"
card:
type: entities
entities:
- light.soggiorno
- climate.soggiorno
La card interna viene renderizzata solo se motion attivo, riducendo carico quando stanza vuota.
Ottimizzazione sistema operativo
Spostare database su SSD (Raspberry Pi)
Problema: SD card è lenta e si degrada con scritture continue.
Soluzione: USB SSD esterno
-
Collega SSD USB a Raspberry Pi
-
Supervisor > Sistema > Data Disk
-
Sposta
/datasu SSD USB -
Riavvia
Risultato:
-
10x velocità scrittura/lettura database
-
SD card dura anni in più (solo OS, non database)
Ottimizzare parametri Raspberry Pi
Overclocking moderato (solo Pi 4/5):
# /boot/config.txt over_voltage=2 arm_freq=1800 # Da 1500 default a 1800 MHz (+20%)
Attenzione: richiede dissipatore passivo o ventola attiva.
Disabilitare Bluetooth/WiFi se non usati
Se usi Ethernet cablato:
# /boot/config.txt dtoverlay=disable-bt # Disabilita Bluetooth dtoverlay=disable-wifi # Disabilita WiFi
Risparmio ~5-10% CPU idle.
Backup ottimizzati: escludere dati temporanei
Problema: backup da 10GB impiegano 30+ minuti
Soluzione: escludere cartelle non essenziali
# configuration.yaml
backup:
exclude:
- /config/.storage/lovelace* # Dashboard (ricostruibili)
- /config/deps # Dependencies (ri-scaricabili)
- /config/tts # Cache TTS (ricostruibile)
- /config/image # Cache immagini
Backup solo configurazione essenziale:
-
configuration.yaml -
automations.yaml -
scripts.yaml -
secrets.yaml -
Custom components
/config/custom_components
Resto ricostruibile dopo restore.
Monitoraggio continuo: dashboard performance
Crea dashboard dedicata prestazioni:
type: vertical-stack
cards:
- type: sensor
entity: sensor.processor_use_percent
graph: line
hours_to_show: 24
name: CPU Usage 24h
- type: sensor
entity: sensor.memory_use_percent
graph: line
hours_to_show: 24
- type: sensor
entity: sensor.home_assistant_v2_db
name: Database Size
- type: entities
entities:
- sensor.uptime
- sensor.current_version
Alert automatici sovraccarico:
automation:
- alias: "Alert CPU alta"
trigger:
- platform: numeric_state
entity_id: sensor.processor_use_percent
above: 80
for:
minutes: 10
action:
- service: notify.telegram
data:
message: "⚠️ CPU > 80% da 10 minuti! Controlla integrazioni pesanti."
Checklist ottimizzazione rapida (quick wins)
- Configura
recorderconpurge_keep_days: 7ed esclusioni - Esegui
recorder.purgemanuale per database esistente grande - Rimuovi integrazioni e dispositivi non più usati
- Elimina entità “unavailable” orfane
- Aggiungi
for:alle automazioni con trigger frequenti - Consolida automazioni duplicate in una sola
- Ridici
update_intervalsensori MQTT/ESPHome non critici - Crea dashboard modulari invece di una gigante
- Sposta database su SSD se su Raspberry Pi
- Abilita System Monitor e crea dashboard monitoraggio
Tempo stimato: 2-3 ore per applicare tutto.
Risultato atteso: 50-70% riduzione carico CPU, interfaccia 3-5x più reattiva.
Ottimizzare Home Assistant non è un’operazione una-tantum, ma manutenzione continua da fare ogni 3-6 mesi man mano che aggiungi dispositivi e automazioni. Le tecniche in questa guida ti permettono di mantenere HA fluido e reattivo anche con centinaia di entità, garantendo esperienza utente ottimale e longevità hardware (specialmente su Raspberry Pi con risorse limitate).
Inizia dalle quick wins (recorder, purge, rimozione inutilizzati) che richiedono 30 minuti e danno risultati immediati, poi procedi gradualmente con ottimizzazioni avanzate (MariaDB, MQTT tuning, SSD) se necessario.
Home Assistant ottimizzato = automazioni che rispondono istantaneamente, dashboard che caricano in <1 secondo, e sistema stabile che non crasha mai. Vale ogni minuto investito!
