Gli helper sono entità “virtuali” che HA mette a disposizione per contenere valori editabili dall’utente o dallo stato del sistema. Non corrispondono a nessun dispositivo fisico: vivono solo nella logica di HA, ma sono usati moltissimo perché risolvono un problema ricorrente, “mi serve un valore/interruttore che le automazioni possano leggere e scrivere”. In questo capitolo vediamo i tipi principali, il pattern “helper come flag” (che è di gran lunga il più usato), e quando invece un helper è una scorciatoia che si paga più tardi.
Cosa sono, esattamente
Un helper è un’entità che vive nel dominio input_* (e alcuni altri). Ha uno stato che puoi leggere come qualsiasi altra entità, ma puoi anche scriverlo, sia dalla UI (con un click) sia da un’automazione (con un call_service). Sono persistenti: se HA si riavvia, ritrovi il valore che avevano.
Si creano da Impostazioni → Helper → Aggiungi.
I tipi principali
| Helper | Dominio | Cosa contiene |
|---|---|---|
| Interruttore | input_boolean | on/off |
| Numero | input_number | Numero con min, max, step |
| Selezione | input_select | Una fra N opzioni testuali |
| Testo | input_text | Stringa libera (con lunghezza max opzionale) |
| Data/ora | input_datetime | Data, ora, o entrambi |
| Timer | timer | Countdown attivabile, con evento a scadenza |
| Contatore | counter | Numero intero incrementabile/decrementabile |
| Schedule | schedule | Fasce orarie ricorrenti (on/off), interpretato come binary_sensor |
Ce ne sono altri più specialistici (statistics, threshold, derivative, ecc.) che generano entità derivate da altre: non sono “helper editabili” in senso stretto, ma stanno nello stesso menu.
Il pattern più usato: helper come flag
Il 70% dell’uso reale degli helper è questo pattern:
Un
input_booleanche rappresenta uno “stato di sistema” che tu setti dalla dashboard e che le automazioni leggono come condition.
Esempi tipici:
input_boolean.modalita_vacanza: quando è on, tutte le automazioni giornaliere (irrigazione, luci a orario, notifiche, allarme svegliami) sono skippate. Attivi il flag prima di partire, disattivi quando torni. Non tocchi le automazioni una per una.input_boolean.ospiti_in_casa: quando è on, le automazioni “notte” restano meno aggressive (non spegnere subito le luci del bagno, non partire con la sveglia mattutina).input_boolean.riscaldamento_boost: un pulsante manuale per forzare il riscaldamento oltre lo schedule.
Ogni automazione che deve rispettare il flag mette una condition tipo “and if input_boolean.modalita_vacanza is off”. Un input_boolean in cima alla dashboard con un interruttore diventa il “master switch” della tua casa.
Chronos (che abbiamo visto in Chronos - Come funziona e sicurezza) usa proprio gli input_boolean come target di alcuni suoi schedule per pilotare i flag lette dalle automazioni esistenti, senza doverle riscrivere.
input_number: soglie configurabili senza toccare YAML
Il caso classico: hai un’automazione “se temperatura salotto sopra X, accendi ventilatore”. Se X è codificato nell’automazione, cambiare X vuol dire riaprire l’automazione, cambiare, salvare. Un input_number.soglia_ventilatore con min 20 e max 30 permette di mettere uno slider in dashboard e regolarlo in due secondi.
Le automazioni referenziano states('input_number.soglia_ventilatore') | float come soglia. Tu regoli lo slider, non tocchi mai l’automazione.
Utile ovunque ci siano parametri che vorresti tarare senza entrare nella configurazione: durate di irrigazione, orari di sveglia, brightness “notturno”, ecc.
input_select: state machine leggere
Utile per “modi” della casa: input_select.modalita_casa con opzioni {Casa, Uscito, Notte, Ospiti, Vacanza}. Diverse automazioni leggono la modalità e si comportano di conseguenza. Cambio la modalità dalla dashboard (o via automazione), tutto il resto si adatta.
Vantaggio rispetto a più input_boolean (uno per modo): sono mutuamente esclusivi per costruzione. Non puoi essere “Casa e Vacanza” contemporaneamente per errore.
Timer: attese resettabili
Il timer è un helper particolare: parte con timer.start per una durata, e a scadenza genera un evento timer.finished. Puoi ascoltare l’evento come trigger di un’automazione.
Il caso più tipico è illuminazione con auto-spegnimento resettabile:
- Trigger 1:
binary_sensor.movimento_corridoiopassa a on → azione:light.turn_on+timer.start(durata 3 min). - Trigger 2:
binary_sensor.movimento_corridoiopassa a on (di nuovo, mentre il timer gira) → azione:timer.start(che resetta il countdown). - Automazione 2 sull’evento
timer.finished→ azione:light.turn_off.
Ogni movimento resetta il timer. Se nessuno si muove per 3 minuti consecutivi, luce spenta. Con mode: restart sull’automazione principale ottieni un effetto simile senza timer esplicito, ma il timer è più leggibile.
counter: contatori persistenti
counter tiene un numero intero, incrementabile/decrementabile via servizio. Uso classico: “quante volte ho lanciato la lavatrice questa settimana”, “numero di ricariche completate”, “cicli di irrigazione fatti oggi”. Un’automazione lo incrementa, un’altra lo azzera (es. a mezzanotte, a domenica sera).
Piccolo trucco: la card Statistic in dashboard su un counter fa quella cifra grossa che ci mette una vita da fare a mano con template + custom card.
input_datetime: memorizzare “l’ultima volta che…”
Utile per tenere traccia di quando è successo qualcosa. Esempio: input_datetime.ultima_irrigazione. Un’automazione lo aggiorna a now() ogni volta che parte l’irrigazione. Un’altra automazione decide di skippare la prossima se sono passate meno di 12 ore.
In alternativa si può usare l’attributo last_triggered di un’automazione, ma un input_datetime è più esplicito e non dipende dalla history dell’automazione (che potrebbe essere epurata).
schedule: fasce orarie ricorrenti nativamente
Il helper schedule (dal 2024.4) sostituisce molti pattern “condition su ora”. Definisci fasce orarie settimanali: lunedì 6:00-9:00 e 18:00-23:00, sabato 8:00-24:00, ecc. Diventa una entità schedule.mio_orario di tipo binary_sensor (on quando dentro una fascia, off fuori).
Le automazioni leggono states('schedule.mio_orario') == 'on' come condition, invece di scrivere sette condition “if hour and weekday”.
Nota: rispetto a Chronos, schedule è più semplice e limitato: non ha azioni, non fa nulla da solo, è solo “sono dentro/fuori la fascia”. Per schedule con azioni concrete su device, Chronos è meglio.
Il pattern “helper as flag” con Chronos
Il modo più pulito di usare Chronos senza dover riscrivere le automazioni esistenti è:
- Le tue automazioni HA leggono già
input_boolean.riscaldamento_attivocome condition. - Crei uno schedule Chronos che pilota
input_boolean.riscaldamento_attivoon/off nelle fasce che vuoi. - Le automazioni continuano a girare come prima, ma è Chronos a decidere quando il flag è on.
Vantaggio: le automazioni restano centrali (piene di condition e logica), Chronos aggiunge la temporizzazione visuale. Nessuna riscrittura.
Quando NON creare un helper
Helper per un uso solo. Se un input_boolean esiste solo perché una singola automazione lo referenzia, e sei tu l’unico che lo tocca (da UI o da un’altra automazione della stessa famiglia), forse quel valore stava meglio come template o come variable dentro l’automazione.
Helper come workaround. Se stai creando input_number per “ricordare l’ultima temperatura vista dal sensore”, il template states('sensor.termostato_temperatura') fa già quello: non serve duplicare.
Helper come sostituti del registry. Il fatto che un’entità si possa nominare, categorizzare, mettere in un’area vale anche per gli helper: ma se stai creando venti helper solo per catalogare cose, forse hai bisogno delle label del registry.
Ricapitolando
- Gli helper sono entità virtuali per contenere valori editabili sia da UI sia da automazioni.
- Il pattern più comune è
input_booleancome flag di sistema (modalità vacanza, ospiti, boost, ecc.) letto dalle automazioni come condition. input_numbersposta le soglie dai file di configurazione alla dashboard.input_selectè una state machine leggera con opzioni mutuamente esclusive.timergestisce attese resettabili in modo leggibile.schedulecopre fasce orarie ricorrenti; per programmi complessi con azioni, meglio Chronos.- Non creare helper per un unico uso: spesso un template è più semplice e altrettanto potente.