Le automazioni sono il motore di HA. Sono le regole “quando succede X, fai Y (se Z)” che trasformano l’insieme di device connessi in una casa che si comporta da sola. In questo capitolo vediamo come sono strutturate, come si crea un’automazione dal nuovo editor visuale (senza scrivere una riga di YAML), quali sono i trigger e le azioni più utili nella pratica quotidiana e come sfruttare la funzione Trace per capire perché un’automazione non è partita.
La struttura di un’automazione
Ogni automazione ha tre sezioni:
When (Trigger): cosa fa scattare l’automazione. È l’evento che HA sta aspettando: “quando entra qualcuno in casa”, “alle 22:00”, “quando la temperatura scende sotto 18°”, “quando arriva un messaggio MQTT su un topic”. Un’automazione può avere più trigger: basta che uno di loro scatti perché l’automazione parta.
And if (Condition): le guardie. Sono controlli che devono essere veri al momento del trigger, altrimenti l’automazione non prosegue. “Se qualcuno è in casa”, “se sono le ore serali”, “se il termostato è in modalità auto”. Le condition sono opzionali: un’automazione senza condition parte ogni volta che scatta il trigger.
Then do (Action): cosa fare. Chiamare un servizio (light.turn_on), aspettare un tempo (delay), aspettare un evento (wait_template), inviare una notifica, eseguire uno script, forzare uno stato in un helper. Le action sono sequenziali di default: si eseguono una dopo l’altra.
L’editor grafico ti guida attraverso queste tre sezioni una alla volta. Non serve conoscere YAML.
Creare la prima automazione dall’editor
Impostazioni → Automazioni & scene → Crea automazione → Crea una nuova automazione.
L’editor si apre in modalità visuale. Un esempio classico per capire il flusso: “quando qualcuno entra in salotto la sera, accendi le luci al 40%“.
- When: aggiungi trigger → Occupancy (o
Numeric state/Statea seconda del sensore di presenza) → selezionibinary_sensor.salotto_presenza→ cambia stato daoffaon. - And if: aggiungi condizione → Sun → dopo il tramonto (oppure
Numeric statesull’entità sole con elevation < 0). - Then do: aggiungi azione → Call service →
light.turn_on→ targetlight.salotto→ data →brightness_pct: 40.
Salvi, dai un nome, l’automazione è attiva. Puoi testarla subito col pulsante Esegui in alto (che ignora i trigger e le condition, esegue solo le azioni, utile per vedere se le azioni fanno quello che vuoi).
I trigger più utili nella pratica
L’editor propone una ventina di tipi di trigger. Nella pratica il 90% delle automazioni ne usa cinque o sei.
| Trigger | Quando usarlo |
|---|---|
| State | Un’entità cambia stato (es. light.salotto passa da off a on). Il trigger più generico e più usato. |
| Numeric state | Il valore numerico di un sensore attraversa una soglia (temperatura sotto 18°, umidità sopra 70%) |
| Time | Un orario fisso (“alle 22:00”) o un pattern (“ogni 5 minuti”, “ogni domenica alle 9”) |
| Sun | Alba o tramonto, con offset opzionale (es. “30 minuti prima del tramonto”) |
| Zone | Una persona entra o esce da una zona (casa, ufficio, palestra) |
| Event | Un evento HA (es. mobile_app_notification_action per gestire il click su una notifica) |
| MQTT | Arriva un messaggio su un topic MQTT (per device custom) |
| Template | Un template Jinja restituisce true (per condizioni complesse, vedi 11 Template e Jinja) |
I trigger Numeric state e State hanno un campo opzionale for: “resta in questo stato per N minuti prima di scattare”. Fondamentale per evitare falsi trigger: un sensore di movimento che rimbalza off/on/off/on non ti manda notifiche a raffica se metti for: "00:00:30" come guardia.
Le condition: guardie contro i falsi positivi
Le condition sono la parte che i principianti dimenticano più spesso. Risultato: automazioni che si attivano in orari sbagliati, quando non serve, o in loop.
Casi tipici da coprire con condition:
- Ora del giorno: la maggior parte delle automazioni ha senso solo in una fascia oraria. “Accendi le luci quando qualcuno entra” ha senso solo dopo il tramonto, non alle 14:00.
- Presenza: “invia notifica cameriera in giardino” ha senso solo se qualcuno è in casa.
- Stato dell’automazione stessa: usa un
input_booleancome “modalità vacanza” e metti “solo seinput_boolean.vacanzaè off” come condition su tutte le automazioni giornaliere. - Duplicati recenti:
Templatecon{{ (now() - state_attr('automation.miaauto', 'last_triggered')).total_seconds() > 300 }}per evitare che la stessa automazione parta due volte in 5 minuti.
L’editor le presenta come And if (con “and”: tutte devono essere vere). Se ti serve un “or” (una condition OR l’altra), aggiungi una condizione di tipo Or e ci metti dentro le sotto-condizioni.
Le action: cosa si può fare
L’action più comune è Call service: chiama un qualsiasi servizio HA. Copre praticamente tutto quello che puoi fare in HA. Il selettore mostra i servizi disponibili, i target (entità, area, device) e i parametri obbligatori/opzionali.
Altri tipi di action utili:
- Delay: aspetta N secondi/minuti. Usa raramente, spesso è sintomo di una struttura sbagliata (meglio spezzare in due automazioni).
- Wait for trigger: metti in pausa l’automazione finché non succede un evento (es. “spegni le luci quando l’ultimo esce, altrimenti aspetta”).
- Wait for template: pausa finché un template diventa true (es. “aspetta che il termostato raggiunga la temperatura”).
- Repeat: loop, con
count,whileofor_each. Utile per fare la stessa azione su una lista di entità. - Choose: switch/case. Definisce una sequenza di “if… then…” con un default. Molto potente per automazioni con più esiti possibili.
- Parallel: esegue due o più azioni in parallelo invece che in sequenza.
- Stop: interrompe l’automazione (utile dentro un Choose per fermarsi presto).
Le mode: gestire cosa fa un trigger mentre già gira
Ogni automazione ha una mode che decide cosa succede se il trigger scatta mentre una precedente esecuzione è ancora in corso.
| Mode | Comportamento |
|---|---|
| single (default) | Ignora i nuovi trigger finché non finisce quello in corso. Il più prudente. |
| restart | Fa ripartire l’automazione da zero, cancellando quella in corso. Utile per timer resettabili (es. “spegni la luce dopo 5 min di inattività”, ma se torna qualcuno rifai il timer). |
| queued | Accoda i nuovi trigger; verranno eseguiti in ordine, uno dopo l’altro. Utile per non perdere eventi (es. notifiche). |
| parallel | Ogni trigger avvia un’esecuzione a sé, parallela. Va usato con attenzione: se le azioni sono su risorse condivise possono generare race condition. |
Cambia mode dalla sezione Automation settings dell’editor. Il default single va bene nel 90% dei casi, ma restart è spesso quello che vuoi per timer/ritardi.
Trace: la funzione che ti salva la vita
Quando un’automazione “non parte” o “parte quando non dovrebbe”, la prima cosa da guardare è la Trace. Ogni esecuzione dell’automazione salva un log dettagliato che puoi rileggere.
Da Impostazioni → Automazioni → apri l’automazione → tab “Traces” vedi le ultime 5 esecuzioni. Cliccando su una trace, l’editor visuale evidenzia:
- Quale trigger ha scattato (in verde)
- Quali condition sono passate (verdi) o hanno bloccato (rosso)
- Quali action sono state eseguite (verdi) e con quali parametri
- Se qualche action ha fallito (rosso, con messaggio d’errore)
È lo strumento più potente per capire perché un’automazione non fa quello che ti aspetti. Se una condition ti sta bloccando sempre, la trace te lo dice al colpo d’occhio.
Se una trace non compare, significa che il trigger non è mai scattato: il problema è a monte (entità nominata male, valore che non attraversa la soglia, tempo che non corrisponde).
Errori tipici che si fanno all’inizio
Trigger sullo stato “sconosciuto” all’avvio di HA. Un State trigger da off a on scatta anche quando un’entità passa da unknown a on al primo boot. Se non vuoi questo comportamento, aggiungi una condition sullo stato “from” o usa for: "00:00:01".
Automazioni che si attivano a vuoto. Se metti “quando la porta si apre, invia notifica” senza for, ricevi due notifiche quando qualcuno entra ed esce nel giro di secondi. for: "00:00:03" filtra i rimbalzi.
Loop infiniti. Automazione “quando luce accesa, se X, spegni luce”. Se X è vera, la luce si spegne, si riaccende, si rispegne. Prevenzione: aggiungi condition che referenziano lo stato di un helper o della propria last_triggered.
Azioni su entità non ancora disponibili. Al riavvio di HA molte entità sono unavailable per qualche secondo. Automazioni con trigger homeassistant.start devono aspettare (un delay: "00:00:30" all’inizio salva molti errori).
Delay lunghi + restart HA. Un delay di 2 ore muore se HA si riavvia. Per attese lunghe usa un’automazione separata con trigger time, non un delay.
Ricapitolando
- Ogni automazione ha trigger → condition → action. Le condition sono la parte che i principianti dimenticano di più.
- L’editor visuale copre tutto quello che serve nel 90% dei casi.
- I trigger più usati sono State, Numeric state, Time, Sun, Zone.
- Attenzione alla mode:
singleè prudente,restartè quello che vuoi per timer,queuedper non perdere eventi. - Se un’automazione non parte, apri Traces prima di modificare qualsiasi cosa.