Chronos: Come funziona e sicurezza

Chronos è un’integrazione custom per Home Assistant che sostituisce le decine di automazioni “a orario” con un unico scheduler visuale. Al posto di scrivere YAML per ogni fascia oraria, disegni la giornata a blocchi sulla card e Chronos li esegue, giorno per giorno.

Fa tre cose:

• Piani giornalieri per termostati, luci, tende, irrigazione, prese, ventole, scaldabagni, tosaerba, aspirapolveri, scene, automazioni e centrali allarme, con orari fissi o legati a sunset/sunrise.
• Regole meteo IF/THEN che modificano al volo un blocco: salta l’irrigazione se ha piovuto, chiudi le tende se il vento supera 30 km/h, allunga il ventilatore se caldo + umido.
• Chiamate a qualsiasi servizio Home Assistant (backup, mqtt.publish, script.run, notify.*, ecc.) programmate come qualsiasi altro blocco.

Per installazione, prima configurazione e diagnosi vedi Chronos - Installazione e problemi comuni.

Dove si colloca nell’architettura

Chronos vive interamente dentro Home Assistant: non è un servizio esterno, non parla con hardware direttamente, non apre porte di rete verso l’esterno (salvo quelle che apre il browser per il meteo e le mappe).

flowchart TD
    A[Chronos card - Lovelace] -->|WebSocket API| B[Integrazione Chronos]
    B --> C[Storage HA]
    B --> D[Weather entity]
    B --> E[Sensori override]
    B -->|call_service| F[Entità target]
    B -->|call_service| G[Qualsiasi servizio HA]
    B --> H[Entità pubblicate: switch, binary_sensor, sensor]

Conseguenze pratiche:

• Tutto lo stato è nello storage di HA. Schedule, blocchi, regole meteo, cronologia esecuzioni: niente file YAML da editare, niente database esterni. Un backup completo di Home Assistant contiene già tutto Chronos.
• La card è un frontend WebSocket, non modifica dati per conto suo: ogni salvataggio passa dall’integrazione, che valida e persiste. Chiudere il browser mentre stai editando non lascia buchi.
• Non c’è un demone separato: se Home Assistant si ferma, si ferma anche Chronos. Alla ripartenza riprende da dove era, con qualche garanzia in più su timer e retry (vedi sotto).

Il modello a schedule / blocchi / regole

Uno schedule è una giornata di 24 ore per uno o più dispositivi dello stesso tipo (o compatibili). Un secondo schedule può girare in parallelo su altri dispositivi. Le settimane sono viste sopra: sette copie dello stesso piano giornaliero, filtrabili per giorno.

Un blocco occupa una fascia oraria dello schedule. Ha inizio, fine, azione, valore e un sottoinsieme di dispositivi tra quelli dello schedule. I blocchi non possono sovrapporsi: trascinandone uno sopra il vicino, il vicino viene tagliato. Blocchi risultanti sotto i 15 minuti vengono scartati. È un vincolo di UI che elimina la classe di bug “due azioni contemporanee sullo stesso dispositivo”.

Una regola meteo è un oggetto indipendente dallo schedule (dalla v1.17). Ha un IF composto da una o più clausole in AND e un THEN che può: saltare il blocco, spostarne l’inizio, forzare un’azione specifica, cambiare la durata. Una singola regola può essere legata a più schedule, e uno schedule può usare più regole. Non c’è OR: se ti serve OR, spezzi in due regole con lo stesso THEN.

Le regole meteo possono essere agganciate anche a schedule senza blocchi, diventando così pure automazioni event-driven (“se batteria off-grid > 96% e sole per almeno due ore, accendi il secondo boiler”).

Le entità che Chronos pubblica in HA

Per ogni schedule Chronos crea tre entità collegate:

• switch.chronos_<schedule>: abilita/disabilita lo schedule; usabile in dashboard, automazioni, comandi vocali
• binary_sensor.chronos_<schedule>_running: on se un blocco è attualmente attivo
• sensor.chronos_<schedule>_next_change: orario del prossimo cambio programmato

Servono a due cose: pilotare Chronos da fuori (es. un’automazione HA che disabilita lo schedule “riscaldamento” se tutte le persone di casa sono via) e mostrare lo stato dello schedule su dashboard normali senza dover mettere la card intera.

Cosa succede quando un blocco parte

1. Chronos verifica che lo schedule sia attivo e che il blocco appartenga all’oggi (giorno della settimana, eventuali intervalli annuali).
2. Valuta le regole meteo legate: se una dice skip, il blocco non parte; se dice shift, viene rimandato di X minuti; se dice force con once_per_day, si controlla che non sia già scattata oggi.
3. Per ogni dispositivo target del blocco, chiama il servizio HA corrispondente (climate.set_temperature, light.turn_on, ecc.) coi parametri del blocco.
4. Se il dispositivo è offline al dispatch, l’evento viene marcato “warning” (giallo) in History invece che “ok”, e Chronos si arma per riprovare appena torna online, purché il blocco sia ancora attivo. Max tentativi configurabile.
5. Se il blocco ha un auto-off timer, Chronos memorizza “spegni fra N minuti”; se HA si riavvia nel frattempo, allo startup i dispositivi vengono spenti comunque (off-late è la direzione sicura).
6. Ogni evento, successo, warning, errore, finisce in History (ultimi 5000 eventi su disco), leggibile dalla card per capire retroattivamente cosa è successo.

Sicurezza: superficie interna, non esterna

A differenza di integrazioni che ricevono input da fuori (radio, MQTT esposto, webhook), Chronos non accetta comandi dall’esterno. Non c’è una whitelist di mittenti da mantenere, non c’è una chiave da ruotare. La superficie di attacco coincide con quella di Home Assistant stesso.

Detto questo, ci sono tre punti da tenere presente.

1. Chronos esegue come Home Assistant, senza distinzione di utente

Ogni azione parte via call_service dal Python dell’integrazione. Non c’è un “utente Chronos”: è HA che chiama HA. Conseguenze:

• Chiunque abbia un account admin di HA può aprire la card e modificare qualunque schedule, aggiungere blocchi, cambiare targets. Non esiste un ruolo “operatore Chronos” separato.
• Un utente HA non admin vede la card solo se hai dato accesso a quella dashboard; ma se la vede, la interagisce come admin (non c’è un permission model interno).
• La domanda pratica: chi ha un account admin di HA vuoi che possa modificare l’irrigazione, l’allarme, gli schedule del boiler? Se la risposta non è “tutti gli admin”, stringi la lista degli admin prima di preoccuparti di Chronos.

2. I service-call block sono un jolly

Un blocco di tipo Service invoca un qualsiasi domain.service di HA, con un payload JSON opzionale. Esempi legittimi: mqtt.publish per annunci, backup.create per backup notturni, script.run per routine complesse.

Ma il jolly vale anche per:

• hassio.addon_stop / addon_start, fermare/avviare add-on Supervisor
• notify.*: inviare messaggi verso qualsiasi destinazione configurata (Telegram, email, ecc.)
• homeassistant.restart: riavviare Home Assistant
• shell_command.*: se hai definito shell command, li esegue

Non è un bug, è la potenza dei service-call. Ma una regola meteo mal scritta legata a uno schedule di tipo Service può eseguire azioni molto invasive in loop se non usi un fire mode appropriato (once_per_day invece di every). Prima di legare regole meteo a schedule Service, verifica che il fire mode sia adatto.

3. Il weather source è fuori dal tuo controllo (a meno che tu lo scelga)

Le regole meteo dipendono da un weather.* entity. Se usi un provider cloud (Meteo.it, OpenWeatherMap, ecc.):

• Dati sbagliati → decisioni sbagliate. Un provider che sballa la previsione pioggia può far saltare l’irrigazione per giorni, con conseguenze concrete su prato o orto.
• Il provider può andare offline. Chronos in quel caso continua a girare sui blocchi statici, ma le regole meteo che referenziano attributi mancanti vengono skippate silenziosamente.
• La OpenWeatherMap API key (opzionale, per i layer mappa) sta in Settings in chiaro. Se un altro admin la copia, può consumare la tua quota.

Se hai una stazione meteo locale (Ecowitt, WeatherFlow, Davis), configurala in Settings → Weather source → sensor overrides: puntando ogni attributo (temperature, wind_speed, rain_rate, ecc.) sul sensore locale, elimini la dipendenza dal cloud provider per quelle regole. Il “Compare” nella live view mostra lo scarto fra locale e cloud, utile per accorgersi di derive.

4. Cosa NON è a rischio

Vale la pena esplicitarlo, perché il mio primo dubbio era stato “chi entra nella mesh entra nella casa” (che è vero per Hermes). Per Chronos non è così:

• Chronos non ha una superficie di rete propria. Nessuno può “colpire Chronos” senza prima entrare in HA.
• Non c’è un canale di comando esterno da proteggere con chiavi. Non c’è la classe “mittente non autenticato” da gestire.
• Il worst case realistico è “un admin HA fa danni con gli schedule”, non “un esterno prende il controllo attraverso Chronos”.

Quindi la buona pratica di sicurezza coincide con quella di Home Assistant in generale: no HA esposto direttamente su Internet, sempre dietro reverse proxy con 2FA; account admin ridotti al minimo; backup regolari (che coprono anche gli schedule).

Cosa succede quando qualcosa va storto

Chronos ha tre meccanismi di autoprotezione che vale la pena conoscere per non aggirarli inavvertitamente:

Offline device recall. Se al momento del dispatch il dispositivo è unavailable, l’esecuzione è marcata “warning” (non “ok” bugiardo) e Chronos si arma per riprovare quando l’entità torna disponibile, purché il blocco sia ancora attivo. È on di default, ha un numero massimo di tentativi, e si arma solo per dispositivi che erano offline al dispatch (non si mette in mezzo se cambi manualmente qualcosa a mano dopo).

Missed switch-off garantiti. Se un auto-off timer o una chiusura di valvola irrigazione scatta mentre il dispositivo è offline, Chronos spegne appena torna online, anche se il blocco è già finito. Off-late è la direzione sicura (rubinetti chiusi, luci spente). Si arrende dopo 12 ore con nota in History.

Restart-safe timer. Auto-off e chiusure irrigazione sopravvivono a un riavvio HA: al primo boot dopo il restart Chronos completa gli spegnimenti in coda, evitando la classica “valvola rimasta aperta perché HA è morto durante l’irrigazione”.

Nessuno di questi meccanismi difende contro un errore di configurazione (blocco irrigazione da 3h a mezzanotte, per dire). Difendono contro problemi tra Chronos e i dispositivi.

Un compromesso importante da capire

Chronos è pensato per giornate ripetitive: la stessa struttura di orari, con variazioni condizionali via meteo. Se il tuo caso è “il lunedì alle 8 fai X ma solo se martedì scorso è successo Y”, Chronos non è lo strumento giusto: hai bisogno di un’automazione HA classica con condizioni composte.

Al contrario, se il tuo caso è “riscaldamento a 21° dalle 5 alle 8 tutti i giorni, tranne quando c’è più di 25° fuori”, Chronos in tre click fa quello che un’automazione HA fa in trenta righe di YAML.

Il confine pratico: se il grafico settimanale in testa ti sembra pulito, Chronos è la scelta giusta. Se già mentre lo pensi sai che “aspetta, ma se il termostato camera dice 22 allora salto la fascia serale”, allora l’automazione va scritta come tale.

---

Collegamenti

• Chronos - Installazione e problemi comuni
• Repository: Pricesswg/Chronos-Scheduler
• Guida utente completa