12. Automazioni on-device e deep sleep

Questo capitolo parla di autonomia del chip, che è una cosa sola vista da due lati. Da un lato c’è l’autonomia logica: un ESP32 può eseguire automazioni da solo, senza chiedere niente a Home Assistant, e questo cambia radicalmente cosa succede quando il server è in aggiornamento o il Wi-Fi cade. Dall’altro c’è l’autonomia energetica: un ESP32 può dormire consumando microampere e svegliarsi solo quando serve, il che rende possibili i sensori a batteria che durano mesi.

Sono due argomenti diversi ma hanno lo stesso baricentro, cioè decidere cosa deve stare sul chip e cosa può stare sul server. In questo capitolo vediamo come si scrive un’automazione in ESPHome, quali automazioni conviene spostare sul chip, come funziona il deep sleep e la trappola dell’OTA sui device che dormono.

Le automazioni ESPHome

Ogni componente ESPHome espone dei trigger su cui appendere delle azioni. Un pulsante ha on_press e on_release, un sensore ha on_value e on_value_range, esiste un interval per le cose periodiche e un on_boot per l’avvio.

L’esempio minimo è il pulsante che accende la luce collegata allo stesso chip:

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO9
      mode: INPUT_PULLUP
      inverted: true
    name: "Pulsante bagno"
    on_press:
      - light.toggle: luce_bagno
 
light:
  - platform: monochromatic
    output: uscita_led
    id: luce_bagno
    name: "Luce bagno"

La luce si accende nel momento in cui premi, perché il segnale non esce dal chip. Se la stessa cosa fosse un’automazione di Home Assistant, il percorso sarebbe pulsante → Wi-Fi → server → decisione → Wi-Fi → chip → luce: nel migliore dei casi 100-200 ms di ritardo percepibile, e nel peggiore (server in riavvio, Wi-Fi congestionato) niente del tutto.

Le condizioni si scrivono con if, e i valori si leggono con id(...):

sensor:
  - platform: bme280_i2c
    address: 0x76
    temperature:
      id: temp_serra
      name: "Temperatura serra"
      on_value_range:
        - above: 30.0
          then:
            - switch.turn_on: ventola
        - below: 27.0
          then:
            - switch.turn_off: ventola

Questo è un termostato completo che vive dentro un chip da 4 €, con isteresi (accende a 30, spegne a 27, così non oscilla) e nessuna dipendenza dal server. Se Home Assistant si spegne per una settimana, la serra continua a essere ventilata.

Script, globals e timer

Per le cose più articolate ci sono gli script (blocchi di azioni richiamabili) e i globals (variabili che sopravvivono fra un evento e l’altro).

script:
  - id: luce_temporizzata
    mode: restart
    then:
      - light.turn_on: luce_bagno
      - delay: 3min
      - light.turn_off: luce_bagno

Il mode: restart è la parte importante: se lo script è già in esecuzione e viene richiamato, riparte da capo invece di accodarsi. È esattamente il comportamento che vuoi per una luce a timer, dove ogni nuovo movimento deve azzerare il conto alla rovescia. È lo stesso concetto del mode delle automazioni di Home Assistant, già visto in 9 Script e scene.

Cosa mettere sul chip e cosa lasciare al server

La regola che uso è questa: sul chip va tutto quello che deve funzionare anche se il server non c’è, sul server va tutto quello che ha bisogno di sapere cose che il chip non sa.

Sul chip:

• I pulsanti fisici che comandano un carico collegato allo stesso chip.
• Le sicurezze: timeout sui carichi pericolosi, interlock fra relè, soglie di emergenza.
• I termostati semplici a soglia, come quello della serra qui sopra.
• Le temporizzazioni locali (luce che si spegne dopo tre minuti).

Sul server:

• Tutto quello che coinvolge più device: “se il sensore della cucina vede movimento, accendi la luce del corridoio”.
• Tutto quello che dipende da dati esterni: meteo, calendario, prezzo dell’energia, presenza delle persone.
• Le notifiche (vedi 12 Notifiche).
• Le logiche che cambiano spesso, perché modificarle in Home Assistant è istantaneo mentre sul chip richiede una ricompilazione.

Quell’ultimo punto è il vero costo delle automazioni on-device: ogni modifica costa un build e un OTA. Un’automazione che stai ancora mettendo a punto è molto più comoda in Home Assistant; quando è stabile e ti accorgi che deve funzionare anche a server spento, la sposti sul chip.

POSSO FARE ENTRAMBE LE COSE SULLO STESSO PULSANTE?

Sì, ed è il pattern migliore. Metti sul chip l’azione essenziale (on_press che fa il toggle della luce locale) ed esponi comunque il pulsante come entità in Home Assistant. Il server vede la pressione e può fare cose in più (accendere anche altre luci, avviare una scena), ma se il server non c’è la luce si accende lo stesso. La funzione base è garantita, quella evoluta è un bonus.

Resilienza: cosa fa il chip quando la rete sparisce

Tre parametri che vale la pena conoscere.

Il fallback hotspot già visto in 6 Il primo device: se il Wi-Fi non risponde, il chip crea una rete propria da cui puoi riconfigurarlo. È l’assicurazione contro un device montato nel muro con le credenziali sbagliate.

Il reboot_timeout dell’API: se Home Assistant non si connette per un certo tempo, il chip si riavvia. È utile perché risolve certi blocchi della connessione, ma ha un effetto collaterale sgradevole: se spegni Home Assistant per manutenzione, tutti i tuoi device si riavviano in loop. Su un device che deve funzionare in autonomia (il termostato della serra) vale la pena allungarlo o disattivarlo:

api:
  encryption:
    key: !secret api_key
  reboot_timeout: 0s

Con 0s il riavvio automatico è disattivato. Fallo solo dove serve davvero, perché il comportamento predefinito risolve più problemi di quanti ne crei.

Il wifi: fast_connect, utile se il chip è lontano dal router: salta la scansione dei canali e si aggancia direttamente all’ultimo access point noto, riducendo il tempo di riconnessione.

Deep sleep: i sensori a batteria

Un ESP32 sveglio con la radio accesa consuma 80-160 mA. Con una batteria da 2000 mAh sono meno di venti ore. In deep sleep lo stesso chip consuma 10-20 microampere, cioè diecimila volte meno, e la stessa batteria dura anni di sonno.

Il modello è quindi: dormire quasi sempre, svegliarsi per pochi secondi, misurare, trasmettere, tornare a dormire.

deep_sleep:
  id: sonno
  run_duration: 15s
  sleep_duration: 30min

Con questi valori il chip sta sveglio quindici secondi ogni mezz’ora. Il calcolo dell’autonomia è approssimativamente questo: 15 secondi a 100 mA sono 0,42 mAh, moltiplicati per 48 risvegli al giorno fanno 20 mAh al giorno, più il consumo di sonno che è trascurabile. Con una LiPo da 1000 mAh sono circa cinquanta giorni; con una da 2000 mAh, tre mesi e mezzo.

I quindici secondi di run_duration sembrano tanti e servono: il chip deve accendere la radio, agganciare il Wi-Fi (2-5 secondi se va bene), connettersi all’API, leggere il sensore e trasmettere. Ridurli sotto i dieci significa che a volte non fa in tempo e il dato si perde.

La trappola dell’OTA

Questo è il problema che fa impazzire tutti la prima volta. Un chip che dorme non è raggiungibile, e i quindici secondi in cui è sveglio non bastano per beccarlo con un aggiornamento. Risultato: hai caricato una configurazione con deep sleep, il device funziona, e non riesci più ad aggiornarlo se non riprendendo il cavo USB.

La soluzione è un interruttore che impedisce il sonno, esposto in Home Assistant:

switch:
  - platform: template
    name: "Blocca sonno per OTA"
    id: blocca_sonno
    optimistic: true
    turn_on_action:
      - deep_sleep.prevent: sonno
    turn_off_action:
      - deep_sleep.enter: sonno

Il flusso diventa: accendi l’interruttore da Home Assistant, aspetti il prossimo risveglio (il chip legge il comando e resta sveglio), fai l’OTA con calma, poi spegni l’interruttore e il chip torna a dormire. Va messo fin dalla prima configurazione con deep sleep, non aggiunto dopo, perché aggiungerlo dopo richiede il cavo.

L’alternativa, se il device è accessibile fisicamente, è un pulsante fisico collegato a un pin che blocca il sonno finché è premuto.

Cosa toglie autonomia

Se l’autonomia reale è molto inferiore ai calcoli, i sospetti sono nell’ordine:

• Il Wi-Fi lento ad agganciare. Ogni secondo in più a 100 mA conta. Un segnale debole può raddoppiare il tempo di risveglio: avvicinare un access point è l’intervento con più effetto.
• I regolatori e i LED della board. Molte DevKit hanno un LED di alimentazione sempre acceso che da solo consuma 2-5 mA, cioè più di tutto il resto durante il sonno. Su una board destinata alla batteria, quel LED va dissaldato. Anche il regolatore di tensione della board ha una corrente di riposo che può essere superiore al consumo del chip dormiente.
• I sensori alimentati durante il sonno. Se il sensore resta alimentato mentre il chip dorme, consuma lui. Si risolve alimentandolo da un pin GPIO che si spegne prima del sonno.
• La cifratura dell’API. Ha un costo in tempo di CPU al risveglio. Su device a batteria molto tirati, MQTT senza TLS può essere più economico.

Quando l’ESP32 a batteria non è la risposta

Va detto con chiarezza: il Wi-Fi non è la tecnologia giusta per i sensori a batteria. È nato per la banda, non per il basso consumo. Un sensore porta/finestra Zigbee commerciale costa 10 € e dura due anni con una pila a bottone, perché Zigbee è progettato esattamente per quello. Un ESP32 in Wi-Fi con deep sleep, nello stesso ruolo, dura mesi e vuole una LiPo che va ricaricata.

Quindi: se il sensore è a batteria e il dato serve raramente, guarda prima se esiste già il dispositivo Zigbee commerciale (il tema è in Zigbee e nel capitolo 15 Zigbee Matter setup). L’ESP32 a batteria ha senso quando il sensore che ti serve non esiste in commercio, o quando serve elaborazione locale che un sensore Zigbee non può fare.

C’è anche la terza via: usare un ESP32-C6 o H2 in Zigbee invece che in Wi-Fi, che unisce la flessibilità dell’ESP32 ai consumi del 802.15.4. Ne parliamo in 13 Bluetooth proxy Assist Zigbee e Thread.

E la quarta, la più sottovalutata: evitare la batteria. Se c’è una presa a due metri, un ESP32 alimentato non ha nessuno di questi problemi, è sempre raggiungibile, aggiorna in OTA quando vuoi e non chiede manutenzione. La batteria è un vincolo, non una feature.

Ricapitolando

• Le automazioni ESPHome girano sul chip: nessun ritardo di rete, nessuna dipendenza dal server.
• Sul chip: pulsanti fisici, sicurezze, interlock, termostati a soglia, timer locali. Sul server: logiche multi-device, dati esterni, notifiche.
• Ogni modifica a un’automazione on-device costa un build e un OTA: mettici solo le cose stabili.
• Il pattern migliore è entrambi: azione essenziale sul chip, azioni evolute sul server.
• reboot_timeout: 0s sui device che devono lavorare in autonomia, così non si riavviano quando spegni Home Assistant.
• Il deep sleep porta il consumo da 100 mA a ~15 µA: mesi di autonomia invece di ore.
• Metti l’interruttore deep_sleep.prevent dalla prima configurazione: aggiungerlo dopo richiede il cavo USB.
• L’autonomia reale la mangiano il Wi-Fi lento, i LED della board, i sensori alimentati nel sonno.
• Il Wi-Fi non è la tecnologia giusta per i sensori a batteria: valuta Zigbee commerciale, o un C6/H2 in 802.15.4.
• Se c’è una presa a due metri, usala: la batteria è un vincolo, non un obiettivo.