Dieci ore senza acqua, e il guardiano taceva

Nella casa a Merano ci sono due valvole di intercettazione motorizzate, una per l’acqua fredda e una per la calda. Si chiudono quando si esce e si riaprono quando si arriva. Per questo esiste un guardiano: acqua chiusa con casa occupata deve essere segnalato.

Un martedì sono rimaste chiuse entrambe per dieci ore, con la casa occupata. Il guardiano non ha detto nulla.

Il motivo è abbastanza generale da riguardare ogni allarme della casa.

Cos’è successo

00:00:36   acqua calda chiusa
00:00:39   acqua fredda chiusa
10:27      domanda sul perché non arrivi acqua

Mezzanotte esatta, entrambe insieme. È l’orario della manovra antigrippaggio: secondo il manuale le valvole si aprono e si chiudono una volta ogni notte per non bloccarsi.

Questa volta si sono chiuse e non si sono più riaperte. Il contatore lo conferma: dalla sera prima nemmeno un litro.

Il riscontro: due entità, una verità

Ogni valvola compare in Home Assistant due volte — una come valvola, una come interruttore. Stesso apparecchio, stessa integrazione, stesso flusso di dati.

Non sono equivalenti:

interruttore   acceso -> spento            sempre interrogabile
valvola        aperta -> non disponibile   per dieci ore

L’interruttore ha riportato la verità correttamente tutta la notte. L’entità valvola è ammutolita.

È tornata solo quando è stato inviato un comando all’apparecchio. Evidentemente vive del fatto che l’apparecchio invii il suo dato di propria iniziativa — e dopo una manovra avviata da lui stesso non lo fa.

Ricaricare l’integrazione non è servito: dopo, temperatura, contatore e tutti gli interruttori fornivano di nuovo dati, le entità valvola restavano mute.

Perché il guardiano ha taciuto

L’automazione era così:

triggers:
  - trigger: state
    entity_id: [valve.acqua_fredda, valve.acqua_calda]
    to: "closed"
conditions:
  - condition: state
    entity_id: valve.acqua_fredda
    state: "closed"

Aspettava closed. È arrivato unavailable.

L’innesco non è mai scattato, e nemmeno la condizione avrebbe funzionato. Tecnicamente ha funzionato tutto. Era solo costruito sullo stato sbagliato.

Un guardiano che aspetta uno specifico stato di guasto è cieco verso ogni altro.

La domanda non è «dice closed» ma «non dice open». unavailable è altrettanto non-aperto quanto closed — e nel dubbio peggio, perché allora nessuno sa cosa stia facendo la valvola.

È la stessa classe di errore di una condizione che descrive bene il caso normale ed esclude in silenzio l’eccezione. Mentre la si scrive sembra del tutto corretta.

Cosa è cambiato

Il guardiano ora interroga gli interruttori, non le entità valvola, e verifica non aperto invece di chiuso:

conditions:
  - condition: template
    value_template: >-
      {{ not is_state('switch.acqua_fredda', 'on')
         or not is_state('switch.acqua_calda', 'on') }}

In più tre piccolezze, ognuna con un motivo:

Livello «avviso» invece di «informazione». Niente acqua in una casa abitata non è una nota a margine.

Una verifica ogni tre ore come innesco aggiuntivo. Uno stato che esisteva già prima di un riavvio non produce poi alcun cambio di stato — e va trovato lo stesso. È il caso che gli inneschi a evento mancano per costruzione.

Al massimo un messaggio ogni sei ore. Altrimenti la verifica tre volte al giorno segnala uno stato permanente, e dopo tre giorni lo si scaccia senza guardare.

L’acqua è stata riaperta tramite gli interruttori — tramite le entità che rispondevano. Entrambe le entità valvola sono tornate nello stesso istante.

E dopo non è stato convertito solo quel guardiano, ma l’intero pacchetto. Una conversione a metà avrebbe significato lo stesso errore vivo in altri undici punti.

Cosa ti consiglio

1. Chiedi «non va bene» invece di «va male». Ogni verifica che nomina uno stato di guasto concreto ha una lacuna grande quanto tutti gli altri stati.
2. Tratta unavailable come un allarme, non come un’eccezione. Un sensore che tace non è un sensore che dà il cessato allarme.
3. Affianca a ogni innesco a evento una verifica a tempo. Altrimenti ogni stato sopravvissuto a un riavvio è invisibile.
4. Verifica quale delle due entità dello stesso apparecchio sia affidabile. Stessa integrazione non significa stessa affidabilità. Qui il dato più semplice era il più robusto.
5. Limita la ripetizione. Un messaggio che dice la stessa cosa tre volte al giorno diventa rumore di fondo — ed è allora silenzioso quanto nessun messaggio.

E quindi?

Il danno vero è stato piccolo: dieci ore senza acqua, notate da una persona che ha aperto un rubinetto.

Il riscontro vero è più grande. Avevo costruito un guardiano, l’avevo considerato finito e non avevo mai simulato il caso in cui l’entità sorvegliata non segnala «sbagliato» ma niente del tutto.

È lo stesso meccanismo del monitoraggio che non si accorge del proprio silenzio. Ed è il motivo per cui ora, a ogni nuovo allarme, chiedo per prima cosa non come scatta ma che aspetto ha quando la fonte sparisce.

Un allarme che scatta solo su un guasto specifico copre esattamente un guasto. Il prossimo ha sempre un aspetto diverso.