Ho un mini PC Windows dedicato che fa da server per la domotica e la rete. Su Docker girano Home Assistant, il controller Omada di TP-Link (la versione 3.2, quella che gestisce i vecchi access point EAP115) e un gateway WhatsApp. Home Assistant interroga il controller una volta al minuto tramite la sua API web, e da lì ricava quali access point sono accesi, quanti dispositivi ci sono collegati e quanto traffico passa. Se un access point smette di rispondere, arriva un avviso su WhatsApp, per email o sul telefono, a seconda di come l'ho impostato.
Funzionava. Poi, senza che me ne accorgessi, ha smesso.
Un guasto che sembrava un altro
La scheda Wi-Fi della dashboard era ferma. L'ultima lettura buona risaliva a due settimane prima, e mostrava i due access point «in attesa», con un indirizzo MAC al posto del nome e indirizzi IP diversi da quelli soliti. È il quadro tipico di un apparato tornato alle impostazioni di fabbrica, che il controller deve adottare di nuovo.
La conclusione sembrava ovvia: rifare l'adozione degli access point. Era sbagliata.
Aprendo la console di Omada la situazione era un'altra: due access point connessi, con i loro nomi e i loro indirizzi di sempre, diciassette dispositivi collegati, nessun apparato in attesa. Il problema degli access point c'era stato davvero, ed era già stato risolto. Ma Home Assistant non l'aveva mai saputo, perché da quel giorno non era più riuscito a entrare nel controller. Si teneva in pancia l'ultima fotografia riuscita e continuava a mostrarla.
Una lettura ferma all'ultimo dato buono mente in buona fede. Per questo, prima di toccare qualunque cosa, conviene guardare la fonte e non il riassunto.
La causa vera
Lanciando a mano lo script che legge il controller, la risposta era una sola riga: autenticazione rifiutata. L'account con cui Home Assistant si presentava al controller non era più quello in uso. Il resto della catena funzionava.
Durante la verifica è venuto fuori un secondo problema, meno visibile e più fastidioso. Indirizzo, utente e password del controller erano passati allo script come argomenti sulla riga di comando. Ogni volta che il comando falliva, cioè una volta al minuto, Home Assistant lo scriveva per intero nel suo log, password compresa.
C'era poi un terzo aspetto, di progetto più che di guasto. Gli indirizzi degli access point erano scritti a mano in almeno quattro posti: la configurazione del sensore, il monitor di rete, lo script dell'inventario e la dashboard. Cambiarne uno voleva dire ricordarsi di tutti gli altri.
La soluzione: una vista di setup
Invece di correggere la password nel file e chiudere lì, ho fatto in modo che la prossima volta non servisse aprire nessun file. In Home Assistant adesso c'è una vista «Setup Omada» con pochi campi:
- l'indirizzo del controller, l'utente e la password;
- l'IP del router;
- fino a quattro access point, ciascuno con nome, IP e MAC.
Un pulsante, «Applica e prova», salva tutto in un unico file di configurazione, fa subito un login al controller e scrive l'esito sotto i campi: login riuscito oppure il motivo per cui non lo è, e per ogni access point se il controller lo vede e in che stato. Accanto c'è una tabella con quello che il controller conosce davvero, così si nota subito un apparato presente in rete ma non configurato.
Da quel file leggono sia il sensore di Omada sia il monitor di rete, che ogni venti secondi controlla router, connessione Internet, DNS e access point. L'indirizzo di un access point vive in un posto solo.
Due scelte hanno fatto la differenza.
Gli access point si riconoscono per MAC. Il sensore abbina ogni apparato del controller a una delle quattro posizioni configurate guardando prima il MAC, poi l'IP, poi il nome. Se domani un access point prende un indirizzo nuovo dal DHCP, o qualcuno lo rinomina nella console, le sue statistiche restano al loro posto. I sensori in Home Assistant non hanno più il nome dell'apparato scritto dentro: sono «AP1», «AP2» e così via, e il nome visualizzato segue quello impostato nella vista.
La password non torna mai indietro. Il campo si usa solo per scriverla. Lasciarlo vuoto significa «tieni quella già salvata», e dopo ogni applicazione il campo viene svuotato. I dati passano allo script codificati, così nel log finisce solo il comando generico e non il contenuto. Il campo è escluso dal database della cronologia e il file di configurazione è leggibile solo dal sistema. La password resta salvata in chiaro sul server, come prima, ma non si sparge più tra log e cronologia.
Cosa mi porto a casa
Il guasto in sé era banale: un account cambiato. Ci ho messo più tempo a non crederci che a risolverlo, perché i dati vecchi raccontavano una storia plausibile e diversa.
Tre regole che da allora applico a questo server:
- Prima di decidere la causa, guardo la console e non la dashboard. La dashboard dice cosa ha letto l'ultima volta, non cosa succede adesso.
- Gli indirizzi stanno in un posto solo, e tutto il resto li legge da lì.
- Le credenziali non passano dalla riga di comando, perché prima o poi una riga di comando finisce in un log.