17. Pratiche di buon uso

Arrivato qui hai un’istanza HA che funziona, ha integrazioni, dashboard, automazioni. Il capitolo che segue non aggiunge feature: aggiunge disciplina. È il capitolo che distingue chi dopo sei mesi ha HA “ordinato, aggiornabile, ricordabile” da chi ha “un mostro che tocco meno possibile perché ho paura di rompere qualcosa”.

Il tema è unico: HA vive con te, e cresce con te. Ogni scelta di oggi si paga o si incassa fra sei mesi. Le pratiche qui sotto sono banali una per una, ma applicate assieme fanno una differenza enorme.

Naming: metti le regole all’inizio, non dopo

Il debito più costoso in HA è rinominare cose che sono già usate in trenta posti. Una regola di naming stabilita all’inizio ti risparmia settimane di fatica dopo.

Le tre convenzioni che uso e consiglio:

Entità: <dominio>.<stanza>_<oggetto>_<grandezza?>.

• light.salotto_lampada invece di light.living_room_lamp_x1a
• sensor.cucina_termostato_temperatura invece di sensor.zbdev07
• Tutto minuscolo, underscore come separatore.

Aree: nome della stanza in italiano, singolare, capitalizzato.

• Salotto, Cucina, Camera, Bagno principale, Giardino.

Automazioni: prefisso col dominio funzionale, poi descrittivo.

• [Sicurezza] Notifica allarme attivato
• [Riscaldamento] Boost bagno mattina
• [Luci] Spegni ingresso dopo 3 min

Il prefisso in [...] è oro: la lista delle automazioni ordinata alfabeticamente raggruppa per contesto, molto più leggibile della lista casuale.

Struttura file: packages quando la config cresce

Nell’installazione minima tutto sta in configuration.yaml. Quando i pezzi sono >200 righe, diventa illeggibile. HA supporta il pattern packages: distribuire la config in file separati per dominio.

In configuration.yaml:

homeassistant:
  packages: !include_dir_named packages

In <config>/packages/ crei un file per pacchetto:

packages/
├── riscaldamento.yaml
├── sicurezza.yaml
├── luci.yaml
├── irrigazione.yaml
└── monitoraggio_energia.yaml

Ogni file contiene automation:, script:, sensor:, template:, input_boolean:, ecc. Il pacchetto “riscaldamento” ha tutta la logica del riscaldamento in un posto solo, dalla creazione degli helper alle automazioni: refactorare o disabilitare tutto il dominio è una modifica in un file.

Utile quando l’istanza cresce oltre una decina di dominii tematici. Sotto quella soglia, la lista piatta delle automazioni via UI basta e avanza.

Documentare le automazioni

Ogni automazione ha un campo description (o “descrizione” in italiano). Compilalo. Sempre.

Non serve la Divina Commedia. Serve una frase che risponda a: “perché questa automazione esiste? Cosa dovrebbe evitare, o cosa dovrebbe garantire?”

Esempi:

• [Sicurezza] Notifica finestra bagno, con description: “Se la finestra del bagno resta aperta più di 30 minuti mentre la caldaia è accesa, avvisa. Evita bollette assurde in inverno quando ci si dimentica.”

• [Luci] Spegni ingresso dopo 3 min, con description: “Le luci dell’ingresso si spengono 3 minuti dopo l’ultimo movimento. Il timer si resetta ad ogni nuovo movimento (mode: restart).”

Sei mesi dopo, quando riapri l’automazione perché “non ricordo perché avevo messo questo delay”, la description ti risparmia mezz’ora di debug.

Lo stesso vale per script, scene, helper (usa il nome esteso per esplicitare l’uso).

Non over-automate

Il vero errore da principianti non è “automazione fatta male”, è automazioni che non servono.

Segnali che stai over-automatizzando:

• Devi scrivere istruzioni orali agli ospiti per usare la casa (“prima premi qui, poi aspetta il beep, poi…”).
• Passi più tempo a mantenere le automazioni che a beneficiarne.
• Le automazioni si intralciano fra loro (automazione A spegne quello che automazione B ha appena acceso).
• Il tuo partner ti dice “prima era meglio quando lo facevo a mano”.

Regola: automatizza solo quello che fai/faresti sempre alla stessa maniera in un dato contesto. Se una decisione richiede giudizio umano (una volta sì e una no), lasciala umana con un pulsante, non con logica invisibile.

Un esempio: “accendi la luce del bagno al 20% dopo le 23” è una buona automazione (sempre così, sempre a quell’ora). “Riscalda il salotto al setpoint giusto in base a chi è a casa e all’ora e al vento e alla previsione meteo” è overengineering: un termostato con 3-4 setpoint diversi via Chronos fa la stessa cosa in modo leggibile.

Aggiornamenti: settimana di monitoraggio, non aggiornamenti a occhi chiusi

HA rilascia una versione ogni mese. Le versioni minor (2026.x.1, 2026.x.2) sono bugfix, quasi sempre safe. Le major (2026.x → 2026.y) portano feature e talvolta breaking changes.

Regola:

1. Non aggiornare il giorno dell’uscita. Aspetta 5-10 giorni. In quel periodo emergono i bug seri e vengono discussi sul forum HA e su Reddit /r/homeassistant.
2. Leggi le breaking changes nel blog post ufficiale della release. Sono elencati sotto “Backward-incompatible changes”. Anche una lettura veloce ti evita sorprese.
3. Backup prima di aggiornare. Sempre.
4. Aggiorna dopo il backup, riavvia, verifica che le tue automazioni principali funzionino (fai un test rapido: accendi una luce, verifica un sensore).
5. Se qualcosa si rompe, restore del backup precedente.

Su HAOS/Supervised c’è anche l’opzione stable/beta channel. Beta è dove si testano le release prima del rilascio pubblico. Vale la pena se hai voglia di aiutare a trovare bug e hai una VM di test; per produzione, rimani su stable.

Recorder: la history che nessuno guarda mai

Il recorder è il componente HA che salva la history degli stati (per fare i grafici e le statistiche). Di default conserva 10 giorni. Molti pensano “meglio di più”, e lo spostano a 90 giorni. Risultato: il DB home-assistant_v2.db si gonfia a decine di GB, i backup diventano enormi, e la UI HA rallenta.

Il buon compromesso:

• Recorder retention: 7-14 giorni per la maggior parte delle entità. Chi guarda davvero la history di più di due settimane fa?
• Escludi le entità inutili dal recorder (exclude in configuration.yaml): entità di sistema, sensori diagnostici, media player che spammano stato ogni secondo.
• Per statistiche a lungo termine, il Long-term statistics di HA le tiene aggregate (min/max/mean orario/giornaliero) per anni, occupando pochissimo. È automatico per i sensori numeric con state_class corretto.

recorder:
  purge_keep_days: 10
  exclude:
    entities:
      - sensor.time
      - sensor.date
      - media_player.spotify_alessandro
    domains:
      - sun
      - weather

Un ambiente di test

Le installazioni serie hanno una seconda istanza HA dove provare le cose prima di applicarle a quella “produzione”.

Setup semplice:

• Una VM (Proxmox, VirtualBox, UTM) o un secondo Raspberry.
• Installa HAOS.
• Restore l’ultimo backup della produzione.
• Da lì provi nuove integrazioni, custom card, aggiornamenti.

Fondamentale prima di:

• Aggiornamenti major di HA.
• Installazione di custom integration che modificano il core (es. tema profondo, package manager alternativi).
• Refactoring grosso delle automazioni.

Non serve una VM sempre accesa: la accendi quando ne hai bisogno, la spegni. Il tempo speso a montarla si ripaga alla prima release che ti avrebbe rotto qualcosa in produzione.

La community: dove chiedere, dove leggere

Prima di ogni cosa complessa, la community ti fa risparmiare ore.

Dove chiedere:

• Forum ufficiale: community.home-assistant.io: la fonte primaria. Risposte lente ma di qualità.
• Discord ufficiale HA: chat in tempo reale, buono per domande “veloci”.
• Reddit /r/homeassistant: 400k+ utenti, molto attivo per casi d’uso e recensioni hardware.

Dove leggere:

• Docs ufficiali www.home-assistant.io/integrations, sempre la prima fonte.
• Blog release www.home-assistant.io/blog, obbligatorio prima di ogni major update.
• Blueprints exchange community.home-assistant.io/c/blueprints-exchange, automazioni pronte da altre persone, spesso ben pensate.

Regola: cerca prima, chiedi dopo. Il 90% dei “come faccio X in HA” ha già una risposta.

Il momento in cui riscrivere da zero

A volte un’automazione si rompe per motivi diversi in tempi diversi. Prima è troppo aggressiva, poi troppo lenta, poi non parte più. Ogni fix aggiunge un if in più, un helper in più, un delay in più.

Regola: se una cosa ha dato problemi due volte, indaga. Se dà problemi tre volte, buttala e riscrivi da zero.

Riscrivere è quasi sempre più veloce che debuggare un mostro che si è evoluto. E il risultato è più chiaro, più corto, più mantenibile.

Vale anche per pezzi più grossi: dashboard che sono cresciute per accumulazione, package YAML che nessuno tocca più. Ogni 12-18 mesi vale la pena una pulizia strutturale.

Il test finale

Se domani un tuo familiare/amico dovesse “amministrare” il tuo HA per una settimana perché tu sei via, quanto lo troverebbe usabile? Se la risposta è “gli mando 10 messaggi WhatsApp con istruzioni”, forse hai over-automatizzato o hai fatto scelte troppo personalizzate. Se la risposta è “apre la dashboard e le cose sono ovvie”, sei sulla buona strada.

Ricapitolando

• Naming coerente all’inizio, sempre. Renaming dopo è costoso.
• Packages per config grandi, altrimenti UI basta.
• Description sulle automazioni, obbligatoria. Il tuo io futuro ringrazia.
• Non over-automate. Se serve manuale d’uso per la famiglia, hai esagerato.
• Aggiornamenti in coda: mai il giorno dell’uscita. Leggi le breaking changes. Backup prima. Test dopo.
• Recorder retention 7-14 giorni, non 90. Long-term statistics fa il lungo periodo.
• Ambiente di test su VM per novità e major update.
• Community: forum, Discord, Reddit. Cerca prima, chiedi dopo.
• Riscrivere > debuggare quando qualcosa ha dato problemi tre volte.

E qui si chiude il corso. Da qui in poi, HA è tuo: sperimenta, sbaglia, sistema, mantieni. La differenza fra un principiante e un utente esperto non è “quante integrazioni hai”, è quanto la tua casa smart continua a funzionare quando ti dimentichi che c’è.