Sono tornati entrambi — e l'automazione ha taciuto

Alla porta dell’appartamento di Merano c’è una serratura Tedee, integrata attraverso il suo bridge locale. Ci è appesa un’automazione: chi apre fa scattare un’istantanea della telecamera, e la notifica parte.

Ha funzionato. La prima immagine è arrivata il 9 agosto alle 15:49:33, 65 kilobyte.

Il 13 agosto sono tornati a casa entrambi gli abitanti, alle 18:12 e alle 18:18. Nessuna immagine, nessuna notifica. In tutta la sua vita l’automazione aveva zero tracce — l’ultima voce veniva dalla prova manuale del giorno prima.

Prima era sbagliata la posizione dei file

Era la parte innocua, e conta lo stesso. Le immagini finivano all’inizio nella cartella dei file statici:

Posizione	recuperabile?
/config/www/… → /local/…	HTTP 404 — misurato
/media/schnappschuesse/…	subito visibile nel browser dei media

La cartella viene registrata all’avvio. I file aggiunti dopo Home Assistant non li serve — da qui il 404.

E anche dopo un riavvio resterebbe un secondo problema:

/local non è autenticato. Chiunque raggiunga l’istanza potrebbe scaricare le immagini della porta senza accedere.

Una foto della propria porta di casa non è un soprammobile. È stata cambiata una riga — il percorso di destinazione — e da allora le immagini stanno dietro l’accesso, visibili sotto Media → I miei media.

E poi il guasto silenzioso

L’automazione ascoltava il passaggio da chiuso a sbloccato. Suona come l’unica condizione sensata.

Lo storico registrato della serratura dice altro:

10:22:18  locked
18:12:45  unlocking        18:18:41  opening
18:12:52  opening          18:18:42  open
18:12:53  open             18:18:45  unlocked
18:12:55  unlocked

Il salto da locked a unlocked non esiste. Questa serratura passa per unlocking → opening → open e raggiunge unlocked solo a partire da open.

La condizione non poteva dunque mai scattare. E fallisce nel modo più sgradevole:

Nessun messaggio d’errore, nessuna traccia, nessun pallino rosso. Solo silenzio. Esattamente il tipo di guasto che non si nota per mesi — perché «non è successo niente» sembra «non c’era niente».

La prova è venuta dall’automazione gemella

È la parte che ha trasformato la diagnosi da supposizione in prova.

Alla stessa serratura è appesa una seconda automazione, che arma una telecamera quando la porta è chiusa. Stessa entità, stesso momento — con una differenza: ascolta to: unlocked senza indicare da dove.

Ha scattato pulita alle 18:18:45.348. Nello stesso millesimo in cui l’altra taceva.

Due automazioni, una entità, un evento, due esiti diversi. La differenza stava solo nell’indicazione dello stato di partenza.

Un from: in un innesco di stato non è una precisazione. È una supposizione silenziosa sugli stati intermedi di un apparecchio — e quelli non si conoscono finché non li si va a vedere.

Andarli a vedere richiede una riga: interrogare lo storico di quella singola entità attraverso l’interfaccia e leggere la sequenza degli stati.

La correzione, e due finezze al suo interno

L’innesco ha ora due casi e nessuna provenienza:

triggers:
  - trigger: state
    entity_id: lock.<porta>
    to: open        # qualcuno entra davvero
  - trigger: state
    entity_id: lock.<porta>
    to: unlocked    # sbloccata senza aprire, per esempio da remoto
mode: single
max_exceeded: silent

Due inneschi, perché gli eventi sono due. Qualcuno apre la porta — oppure qualcuno la sblocca senza aprirla, per un artigiano ad esempio.

E una sola notifica, benché scattino entrambi. Nella sequenza open → unlocked nel giro di due secondi partono tutti e due gli inneschi. Il secondo viene scartato perché il primo è ancora in corso — è a questo che serve mode: single. E max_exceeded: silent fa sì che quello scarto voluto non finisca nel registro come avviso.

Quest’ultima sembra cosmesi e non lo è: un registro pieno di avvisi che vanno tutti bene è un registro che nessuno legge più.

Una decisione sulla telecamera che trovo importante

La telecamera della porta va a batteria. Il primo tentativo di prendere l’immagine può fallire perché l’apparecchio si sta ancora svegliando.

Entrambi i passaggi dell’istantanea portano quindi un «prosegui in caso di errore»:

Meglio una notifica senza immagine che nessuna immagine e nessuna notifica.

Un passaggio che interrompe un’intera automazione perché è fallito un sottoprodotto è pesato male. La notifica è l’essenziale, l’immagine è l’aggiunta.

Cosa ti consiglio

1. Guarda lo storico reale degli stati prima di costruire un innesco con from:. Gli apparecchi hanno stati intermedi che non stanno in nessuna documentazione.
2. Misura se la tua automazione sia mai scattata. Il numero di scatti è la verifica più economica che esista — e qui avrebbe detto subito «zero».
3. Metti le immagini della porta dietro l’accesso. La cartella dei file statici è aperta e comunque non serve le aggiunte successive.
4. Usa due inneschi se gli eventi sono due — e trasforma consapevolmente il doppione in una sola notifica.
5. Non far fallire un’automazione sulla sua aggiunta. Un’istantanea mancata non deve impedire la notifica.
6. Tieni pulito il registro. Uno scarto voluto non ci va dentro come avviso.

E quindi?

Per quattro giorni la porta è rimasta non osservata, e nessuno se ne sarebbe accorto. La differenza rispetto a un guasto rumoroso è che un guasto rumoroso manda un messaggio. Qui non c’era nulla — il sistema riteneva tutto a posto, perché dal suo punto di vista non c’era mai stato nulla da fare.

È lo stesso schema della dieresi che ha ucciso il mio allarme antigelo e del guardiano che aspettava lo stato sbagliato. Tre volte la stessa costruzione: una condizione che contiene una supposizione sull’apparecchio, e un apparecchio che si comporta diversamente.

L’ho trovato solo perché alla stessa entità era appesa per caso una seconda automazione che ha scattato pulita. Senza quella controprova avrei sospettato la serratura, la telecamera, la via di notifica — tutto, tranne l’unico parametro che era il problema.