La fontanella funziona. In Home Assistant non c’è.

Bruno ha una fontanella. Funziona, l’acqua si muove, Bruno ci beve. È quello che si vede nel reel e non ha bisogno di altre spiegazioni.

La domanda di questa serie è un’altra: la sua ciotola ha bisogno del Wi-Fi?

Dopo mezzo pomeriggio la risposta è chiara, e si divide in due metà che vanno tenute separate.

Che cosa sa fare la ciotola senza niente attaccato

Una pompa, un filtro, una vaschetta. Acqua in movimento, perché cani e gatti preferiscono bere quella all’acqua ferma.

Funziona dalla presa e non serve rete. Chi vuole solo questo ha finito qui e può smettere di leggere.

Perché volevo comunque collegarla

Due cose, e nessuna delle due è un vezzo:

	perché un sistema lo sa meglio di una persona
Livello dell’acqua	Una fontanella che resta a secco è peggio di nessuna — la pompa continua a girare e la ciotola è vuota.
Durata del filtro	Nessuno si ricorda quando è stato cambiato l’ultima volta. Un contatore sì.

Sono entrambi valori che l’apparecchio già conosce. Non si tratta di misurare qualcosa di nuovo, ma di arrivare a qualcosa che c’è già.

Per come stanno le cose oggi, perché qui non resti scritto qualcosa di falso: non c’è nessun avviso di livello nel mio sistema. La ciotola non è in Home Assistant. Questo articolo spiega perché.

La via facile era chiusa

Home Assistant porta con sé un’integrazione Xiaomi. Copre certe categorie di apparecchi — una fontanella per animali non è tra queste.

Quindi il solito secondo passo: un’integrazione generica della comunità da HACS, capace di parlare con tutto ciò che usa il protocollo di Xiaomi. Recupera il token del dispositivo una volta sola dall’account del produttore e poi parla in locale. Uno scambio onesto, ed è esattamente così che dovrebbe essere.

Lì si è bloccato tutto, per un motivo che con la tecnica non c’entra: il mio account Xiaomi è un vecchio account cinese con un numero di telefono che non esiste più. La conferma a due fattori non arriva né via SMS né via e-mail.

Xiaomi serviceLoginAuth2: … → need_verify

Un account in cui non si entra non è un account.

La via locale, e perché su questo modello non porta a nulla

Senza account resta una seconda strada, ed è quella interessante: il token si può leggere direttamente dall’apparecchio. In modalità di associazione un dispositivo del genere lo rivela nell’handshake — nel punto altrimenti occupato da byte di riempimento.

Per questo ho ricostruito il protocollo a mano. Non è stato inutile, perché ha funzionato:

modalità di associazione, token letto
    → dati completi: modello, firmware, rete …

impostazione del Wi-Fi
    → {"result": ["ok"]}

rete di casa, stesso token
    → nessuna risposta, cinque tentativi

handshake sulla rete di casa
    → ffffffff…ffffffff
       └─ token taciuto ─┘

Il dato, ed è misurato

L’apparecchio assegna un nuovo token quando esce dalla modalità di associazione.

Non è un’ipotesi. Lo dimostrano due osservazioni indipendenti:

1. Prima e dopo nella stessa sessione. L’interrogazione funziona in modalità di associazione e, con esattamente lo stesso token, non funziona più sulla rete di casa.
2. Due esecuzioni consecutive hanno dato token diversi per lo stesso apparecchio.

E un dettaglio che completa il quadro: tace il token anche quando non è collegato ad alcun account. Il collegamento all’account non è quindi la condizione. Il cambio avviene all’uscita dalla modalità di associazione, punto.

Così la via senza cloud per questo modello è chiusa. Non per un difetto, ma per come è costruito.

Il messaggio di errore che dice il contrario di quel che sembra

Ecco la parte in cui ho sbagliato strada, ed è più istruttiva del resto.

Se l’apparecchio non risponde a un comando, l’integrazione restituisce internamente un dizionario vuoto invece di un errore. La sua procedura di configurazione non lo intercetta e va in crash all’accesso successivo:

AttributeError: 'dict' object has no attribute 'model'

Dall’esterno compare come HTTP 500, «Server got itself in trouble».

Chi lo vede pensa a un difetto dell’integrazione. In realtà il messaggio dice solo: l’apparecchio non ha risposto. Il che, di norma, significa: token sbagliato.

Io ne ho concluso il contrario. Dal crash proprio su quella riga ho letto che l’integrazione aveva ricevuto dati e che quindi il token andava bene. Sbagliato — il dizionario vuoto significa che non è arrivato nulla.

Un errore nelle profondità del codice altrui dice raramente quello che la sua prima riga suggerisce.

E perché serviva la prova prima-e-dopo

Qui due implementazioni indipendenti hanno fallito allo stesso modo: la mia, fatta a mano, e quella dell’integrazione.

Un fallimento da solo non dimostra nulla sul token. Può altrettanto bene significare che è rotto il tuo strumento — e con due strumenti che realizzano lo stesso protocollo, lo stesso errore di ragionamento può stare in entrambi.

Solo il tentativo in modalità di associazione ha separato «strumento rotto» da «token cambiato». Senza quel passaggio avrei continuato a cercare nel mio codice, qualcosa che lì dentro non c’è.

Quel che resta: un secondo account

La via d’uscita non è spettacolare e funziona. Dopo un ripristino l’apparecchio sta sul Wi-Fi e non è collegato ad alcun account — ed è proprio questo stato a risolvere il problema:

1. Un nuovo account con un indirizzo e-mail raggiungibile, regione Europa.
2. Accedere con quello nell’app del produttore e aggiungere la ciotola.
3. Solo dopo accedere da Home Assistant.

L’ordine è tutto il trucco. Chi accede prima da Home Assistant trova un account vuoto e cerca l’errore nel posto sbagliato.

Dopo di che è il caso normale: il token arriva dal cloud una volta sola, poi gira tutto in locale, e l’app resta utilizzabile.

Non l’ho fatto — e non lo farò.

Creare un secondo account, mantenerlo e tenerlo d’occhio perché una ciotola per cani consegni una chiave una volta sola: lo sforzo non è proporzionato a quello che ne esce alla fine. Sono due numeri, livello dell’acqua e durata del filtro, e per entrambi esiste un’alternativa che funziona da sempre — guardare.

La ciotola resta fuori. Non è un fallimento, è una decisione, e merita di essere documentata quanto un successo. Un sistema non cresce perché ci entra tutto, ma perché ci entra la cosa giusta.

Il verdetto

La serie si chiama «smart o inutile», e la risposta ha due metà:

	verdetto
Come fontanella	Ne vale la pena. Bruno ci beve, l’acqua si muove, il filtro fa il suo lavoro. Per questo non servono né rete né app.
Come apparecchio smart	Inutile — non perché sia scadente, ma perché l’unica via senza cloud è chiusa per costruzione e la scorciatoia non valeva lo sforzo.

La ricomprerei? Per il cane sì. Per il sistema no — almeno non senza prima farmi una domanda che allora non mi sono fatto.

L’unica domanda prima di comprare

Non «è compatibile». A quella ogni confezione risponde di sì.

Ma: come esce la chiave dall’apparecchio, e che cosa mi serve per averla?

Per questa classe di dispositivi la risposta è: tramite un account del produttore in cui devi riuscire a entrare. Chi ha un account funzionante non ha problemi. Chi ne ha uno vecchio ha un pomeriggio.

Non è scritto su nessuna confezione, ed è l’unico punto che qui ha deciso.

Che cosa ti consiglio

1. Separa l’apparecchio dal suo collegamento. Una buona fontanella resta una buona fontanella anche se non compare mai nel tuo sistema.
2. Verifica prima dell’acquisto la via verso la chiave, non l’elenco di compatibilità. Con Xiaomi è la questione dell’account; altri produttori la chiamano in altro modo.
3. Metti in ordine l’account del produttore prima di averne bisogno. Un numero di telefono morto nel secondo fattore lo si nota una volta sola — quando si ha fretta.
4. Leggi con sospetto i messaggi di errore del codice altrui. Un crash su una certa riga ti dice dove è saltato, non perché.
5. Separa «il mio strumento è rotto» da «l’apparecchio fa un’altra cosa». Serve un esperimento che forzi la differenza — per me è stata la prova prima-e-dopo in modalità di associazione.
6. Scrivi quello che non funziona. Gli strumenti di quel pomeriggio funzionano, è dimostrato. Sul prossimo apparecchio dello stesso produttore la stessa strada può benissimo riuscire.

E questo che cosa significa?

La frase più onesta su questo apparecchio è anche la più noiosa: fa quello per cui è stato comprato. Bruno beve, e lo scopo era quello.

Quello che non fa è una cosa che ci ho aggiunto io con la testa — e il fallimento non è dell’apparecchio, ma di una decisione del produttore che prima dell’acquisto non si vede: la chiave esce dal dispositivo solo passando da un account.

È questa la vera lezione di quel pomeriggio, e va ben oltre una ciotola per cani. Per molti apparecchi «controllabile in locale» significa: controllabile in locale dopo che il cloud ha dato il permesso una volta. La differenza non si nota finché l’account funziona.

A Bruno tutto questo non interessa affatto. Per lui la fontanella era abbastanza smart dal primo giorno.