Un'attesa stimata non è una verifica

La porta dell’appartamento di Merano si chiude da sola quando, uscendo, si tiene premuto il pulsante. Per farlo doveva prima sapere se è davvero chiusa.

Il contatto porta è montato. E non è un apparecchio Zigbee — sta nella serratura come accessorio e arriva attraverso l’integrazione della serratura stessa.

Avevo già aperto la finestra di associazione Zigbee prima che arrivasse l’indicazione. È bastato ricaricare l’integrazione esistente, e l’entità c’era.

Prima di associare un apparecchio, conviene chiedersi se non ci sia già.

Due piccolezze prima di poter cominciare

Il nome. Home Assistant ha messo davanti l’area, trasformando il contatto in un nome con dentro corridoio e disimpegno. Riportato a qualcosa di leggibile — perché in un contatto porta «acceso» significa aperto, e il nome deve leggersi nel verso giusto, altrimenti si costruisce la condizione al contrario.

Misurare prima di fidarsi. Un contatto bloccato su «aperto» impedirebbe la chiusura in modo permanente e silenzioso. Per questo è stato mosso prima di entrare nella logica:

15:17:32  chiusa
15:21:32  aperta
15:22:02  chiusa      — 30 secondi aperta

Entrambi gli stati documentati, non supposti.

Ritrovamento laterale: entrambi i cambi cadono su :32 e :02. La serratura viene interrogata circa ogni 30 secondi — la misura può quindi avere mezzo minuto. Irrilevante per un ritardo di tre minuti, ma va saputo.

Cosa ottiene il contatto

pulsante tenuto → 3 min → porta chiusa?  sì       → chiudere
                          porta aperta   → attendere fino a 10 min
                                           ora chiusa?  sì → chiudere
                                                        no → AVVISO, non chiudere

I dieci minuti non sono un lusso: chi uscendo torna a prendere un’altra borsa tiene la porta aperta per più di tre minuti. È il caso normale, non un guasto — quindi aspettare invece di interrompere.

Se dopo dieci minuti è ancora aperta, il chiavistello non esce. Andrebbe a vuoto e sbatterebbe contro il telaio quando la porta viene accostata.

La prova — e l’errore dentro di essa

15:39:05  pulsante tenuto
15:39:12  assente
15:39:34  porta aperta, riscaldamento bagno → 12 °C
15:42:11  automazione porta scattata — e NON ha chiuso   ← il punto di verifica
15:42:14  acqua chiusa
15:46:33  porta chiusa
15:46:42  in chiusura
15:47:20  chiusa
15:47:36  pulsante breve → presente, acqua aperta, riscaldamento 21 °C

La chiusura ha tenuto, la logica era giusta. Da fuori sembrava tutto corretto.

Nel registro c’era comunque un errore — e il motivo è un numero:

La serratura ci mette 38 secondi e per tutto quel tempo risulta «in chiusura». La mia prima versione aspettava ostinatamente 20 secondi, trovava «in chiusura» invece di «chiusa», lo prendeva per un comando ingoiato e ne mandava un secondo — in mezzo alla corsa del motore.

La serratura l’ha respinto. Home Assistant ha contato il rifiuto come errore, e l’automazione si è interrotta.

La porta si è chiusa. La conferma non è mai arrivata.

È lo stesso guasto silenzioso contro cui è costruito tutto questo pacchetto — stavolta nel mio stesso codice. L’ho trovato solo perché dopo la prova ho guardato il registro.

Due volte in un giorno, due apparecchi

Il ritrovamento vero non è l’errore ma lo schema:

Apparecchio	verificato dopo	il motore impiega	conseguenza
valvola dell’acqua	15 s	40 s	il ripiego scattava sempre
serratura	20 s	38 s	il secondo tentativo si è portato via la notifica

Entrambi i numeri erano stimati. Entrambi plausibili. Entrambi troppo corti.

Un’attesa stimata non è una verifica. È un’affermazione su quanto impieghi un motore — e vale per esattamente un apparecchio, quello su cui l’hai stimata.

La via giusta è aspettare il risultato, non l’orologio:

- action: lock.lock
  target: { entity_id: lock.<porta> }
  continue_on_error: true
- wait_for_trigger:
    - trigger: state
      entity_id: lock.<porta>
      to: "locked"
  timeout: "00:01:30"
  continue_on_timeout: true

Tre cose lì dentro sono volute:

L’attesa dello stato invece di una pausa fissa. È finita quando ha finito l’apparecchio, non quando è scaduto l’orologio.

Il limite di tempo con «prosegui allo scadere». Se la conferma non arriva, la notifica deve partire lo stesso — dicendo che non è arrivata.

E «prosegui in caso di errore» sul comando stesso, perché un comando respinto non ingoi mai più la notifica.

Un errore nel comandare può fare di tutto. Tranne far sì che nessuno ne venga a sapere.

Cosa ti consiglio

1. Chiedi se l’apparecchio non ci sia già prima di aprire una finestra di associazione. Gli accessori arrivano spesso dall’integrazione del principale.
2. Muovi un contatto prima di credergli. Un sensore bloccato su uno stato blocca in silenzio tutto ciò che dipende da lui.
3. Misura quanto impiega davvero il tuo apparecchio — e poi non usare quel numero, ma aspetta il risultato.
4. Metti un limite di tempo e lascia uscire comunque la notifica. «Nessuna conferma» è un’informazione, non un motivo per tacere.
5. Non far interrompere l’automazione da un comando respinto.
6. Leggi il registro dopo una prova, anche quando ha funzionato tutto. Qui da fuori non c’era niente da vedere.

E quindi?

La porta era chiusa, il riscaldamento abbassato, l’acqua chiusa. Tutto quello che questo pacchetto deve fare, l’ha fatto.

Eppure era rotto — nell’unico punto che da fuori non si vede: non avrebbe più potuto dirmi di aver fatto quello che deve fare. La prossima volta, quando la porta davvero non si chiude, il silenzio sarebbe stato identico.

Due numeri stimati in un giorno, entrambi troppo corti, entrambi plausibili. Non è un caso, è una proprietà dei numeri stimati: li si stima su quello che ci si immagina — e un motore che corre per 38 secondi non compare in nessuna immaginazione.