Una dieresi ha ucciso il mio allarme antigelo

La casa a Merano d’inverno resta vuota. L’allarme più importante lì è l’avviso di freddo: se le stanze si raffreddano troppo devo saperlo prima che qualcosa geli.

Quell’avviso era morto da quando è stato costruito in agosto. Per due mesi e mezzo.

Il motivo è una dieresi.

Cos’è successo

Passando in rassegna le entità dopo un aggiornamento è emerso che mancava un sensore. Il template si genera correttamente, tutte le altre entità del pacchetto ci sono.

Ma nel registro risultava così:

sensor.kalteste_raumtemperatur     unique_id: kaelteste_raumtemperatur

Home Assistant elimina le dieresi nel formare l’entity_id. Non le traslittera.

"Kälteste Raumtemperatur"           -> sensor.kalteste_raumtemperatur
"Kältewarnung Schwelle Entwarnung"  -> sensor.kaltewarnung_schwelle_entwarnung

ä diventa a, non ae. Nel mio pacchetto c’era ovunque la forma ae. Gli inneschi puntavano quindi a entità che non erano mai esistite.

Ed era nel registro ogni volta

È questa la parte che brucia. Home Assistant scriveva a ogni singolo avvio:

Error initializing 'Kältewarnung: Wohnung kühlt zu stark aus' trigger:
   In 'numeric_state' condition: unknown entity sensor.kaelteste_raumtemperatur

Da agosto. A ogni riavvio. Nessuno l’ha letto.

Un errore nel registro di avvio che nessuno legge è silenzioso quanto nessun errore. E una funzione di protezione che fallisce all’avvio si comporta in esercizio esattamente come una che non scatta perché non succede nulla.

È la differenza tra «funziona» e «non ha mai segnalato niente». Con un allarme i due stati sembrano identici per mesi.

La correzione è stata una riga. Dopo la distribuzione e un riavvio il sensore segna 20,5 °C, la soglia di cessato allarme sta a 13,0, ed entrambe le automazioni sono attive.

L’insidia ora è un commento dentro il pacchetto. E un dettaglio: l’unique_id può mantenere la forma ae — non determina l’entity_id.

Secondo ritrovamento: una copia dimenticata

Il pacchetto che allega il meteo a ogni misura di velocità ha una copia propria dell’interrogazione alla stazione meteo. Costruita così di proposito, per lasciare intatto il pacchetto meteo.

Nel passaggio a una nuova fonte quella copia è stata dimenticata. Da allora produceva un errore ogni cinque minuti.

È il rovescio di una separazione pulita: due copie significano due punti da modificare, e il secondo si dimentica.

Nel convertirla sono emerse due particolarità della nuova fonte, entrambe discrete ed entrambe insidiose:

• La marca temporale ha uno spazio al posto del separatore e un fuso senza due punti. La validazione li rifiuta entrambi.
• La risposta contiene più record per ogni grandezza, compresi alcuni vecchi del 2021 e del 2022. Bisogna ordinare e prendere l’ultimo: chi prende il primo si porta a casa il meteo di cinque anni fa.

Di passaggio il nuovo sensore risponde a una domanda che non avevo posto: i dati della stazione arrivano con circa due ore di ritardo. Conta, quando si scrive il meteo accanto a una misura: non si sta affiancando il meteo di adesso.

Terzo ritrovamento: un comando senza shell

Un pacchetto appena distribuito falliva subito. Lo stesso comando girava senza errori nel terminale dell’apparecchio: non erano quindi né i permessi né i percorsi.

Se in un comando c’è un template, Home Assistant lo avvia senza shell.

Pipe e redirezioni finiscono allora come stringhe letterali al primo programma. Un > non è più una redirezione ma un argomento.

La soluzione è invocare la shell esplicitamente e passare la parte variabile in modo che non entri mai nella scomposizione della riga di comando.

Nel farlo è emersa una seconda mancanza che sarebbe stata peggiore: l’intestazione del file non conosceva due nuovi sensori. L’apparecchio avrebbe quindi scritto uno schema di colonne diverso da quello dello script di analisi — e le due serie non sarebbero più state unibili.

Un errore che sarebbe emerso solo al momento dell’unione, settimane dopo, con una perdita di dati non più riparabile.

E due riscontri che ho dovuto ritirare

Appartengono alla stessa sera, e appartengono qui.

«Le chiavi YAML duplicate si sovrascrivono in silenzio.» Così diceva la mia documentazione su un certo file. Troppo allarmistico. Il file usa un meccanismo regolare per sovrascrivere di proposito due campi — è standard e funziona in modo pulito. Verificato dal vivo: ogni interrogazione fornisce i propri parametri e i numeri tornano. L’avviso nel registro è cosmetico, non un difetto.

«L’ultimo backup è di sei giorni fa.» Anche questo sbagliato. Avevo preso l’ultimo elemento di un elenco non ordinato. Esiste un backup automatico del giorno prima.

Entrambi i ritiri contano per me più dei tre ritrovamenti. Un riscontro che non regge va ritirato con la stessa visibilità con cui è stato scritto — altrimenti tra sei mesi è lì come un fatto e qualcuno ci agisce sopra.

Cosa ti consiglio

1. Leggi il registro di avvio. Una volta dopo ogni distribuzione. Un errore nell’inizializzare un’automazione è invisibile finché nessuno guarda.
2. Verifica come il tuo sistema tratta le dieresi. Non indovinare. Crea un’entità e guarda come si chiama davvero.
3. Prova gli allarmi facendoli scattare. Un allarme che non ha mai segnalato non è un allarme che funziona. Per un avviso di freddo significa: alza la soglia, aspetta, rimettila.
4. Conta le tue copie. Una configurazione duplicata di proposito va bene — ma annota in entrambi i punti che l’altro esiste.
5. Ritira ciò che non regge. E fallo dove era scritto.

E quindi?

Tre errori, tutti e tre silenziosi. Nessuno ha prodotto un messaggio che raggiungesse qualcuno. Due sarebbero costati solo dati — il terzo avrebbe significato una tubatura gelata a gennaio.

Lo schema dietro è sempre lo stesso: il sistema lo aveva detto, solo non abbastanza forte. La dieresi era nel registro, l’endpoint morto era nel registro, il comando senza shell restituiva un codice di errore.

Un impianto che scrive i propri errori solo in un registro è un impianto che tace.