Filosofia e architettura di una domotica costruita per durare

Qualche giorno fa ho aggiunto al mio sistema domotico il controllo automatico dell’irrigazione dei balconi. È una funzione semplice: dei sensori misurano l’umidità del terreno, un software decide quando intervenire e una pompa si attiva. Nulla di particolarmente interessante, almeno in apparenza.

Eppure, proprio mentre la completavo, mi sono reso conto che continuare a descriverla come “una funzione di irrigazione” significa perdere completamente il punto. L’irrigazione non è il progetto: è soltanto l’ultima applicazione costruita sopra un’infrastruttura che negli anni ha assunto una propria identità.

Come è cominciato: il riscaldamento

Il progetto è nato per necessità, unita alla passione tecnologica. Potenza è una città di montagna; il riscaldamento non è un dettaglio, è una voce di spesa rilevante. E l’approccio classico – un termostato in una stanza che controlla l’intero impianto – è fondamentalmente inefficiente.

Il problema è strutturale. Il termostato misura la temperatura in un punto solo e decide per tutto l’appartamento. Le teste termostatiche sui caloriferi, una aggiunta relativamente recente, anche quando regolate con cura, risentono inevitabilmente del calore irradiato dal corpo scaldante stesso: tendono a chiudere prima che la stanza abbia raggiunto la temperatura effettiva dell’aria. Il risultato è che alcune stanze sono sovrariscaldate, altre restano fredde, e il consumo reale non corrisponde al comfort percepito.

La soluzione che ho adottato è stata radicale: leggere temperatura e umidità ambientale in ogni singola stanza – non sul calorifero, ma in aria – e comandare una elettrovalvola sul calorifero, singolarmente per stanza. Il calorifero scalda solo quando serve, si ferma quando la temperatura target è raggiunta, indipendentemente da quello che fanno le altre stanze. La caldaia si accende se una delle stanza deve essere riscaldata. Il miglioramento del comfort è stato immediato, mentre il risparmio è stato concreto e misurabile fin dai primi mesi.

Quella prima automazione ha reso evidente una cosa che già sapevo ma che fino ad allora avevo applicato solo alla meteorologia: per capire il comportamento di un ambiente fisico serve una serie storica. Come si scalda una stanza esposta a sud in una giornata soleggiata rispetto a una nuvolosa? Quanto cambia il tempo di riscaldamento al variare della temperatura esterna? Queste domande non hanno risposta senza dati raccolti nel tempo. Il database che usavo già da anni per la stazione meteo ha cominciato ad accogliere anche le misure dell’abitazione, e da lì il sistema ha iniziato a crescere in modo coerente.

Il principio che guida tutto è rimasto invariato dall’inizio: i dati devono appartenere a chi li produce, devono essere conservati nel tempo e devono restare utilizzabili indipendentemente dall’hardware o dal software del momento.

L’architettura

Il sistema è organizzato in livelli con responsabilità distinte. Alla base ci sono i dispositivi di campo: sensori e attuatori che comunicano attraverso due reti separate. Una rete Wi-Fi, dedicata esclusivamente alla domotica, ospita i dispositivi sempre alimentati – alcuni sensori commerciali, altri autocostruiti su ESP8266, attuatori (es: caldaia, pompe) – che pubblicano dati via MQTT. Una rete Zigbee copre invece la sensoristica distribuita. Ho iniziato con Z-Wave, che funziona bene, ma la varietà e soprattutto il costo dei dispositivi Zigbee mi hanno convinto a migrare quasi subito.

Sopra lo strato di comunicazione c’è Home Assistant, che integra tecnologie diverse in un’interfaccia uniforme. Ma Home Assistant non contiene la logica decisionale: quella è in un software di supervisione che ho sviluppato io. È questo componente che interroga le API di Home Assistant, legge i sensori, consulta il database storico, applica le regole e invia i comandi agli attuatori via MQTT. Home Assistant gestisce l’integrazione hardware, ma il cervello del sistema è indipendente dalla piattaforma.

Il database è il vero patrimonio

Da ventitré anni raccolgo in modo continuo i dati della mia stazione meteorologica. Da oltre sette anni archivio anche le misure provenienti dalla rete di sensori dell’abitazione. Tutto confluisce in un database MySQL con uno schema progettato intorno ai fenomeni fisici – temperatura, umidità, consumo energetico, precipitazioni – non intorno ai dispositivi che li misurano.

La differenza non è sottile. Se domani sostituisco un sensore Zigbee con uno Wi-Fi, la serie storica continua senza interruzioni perché il significato del dato non cambia. L’hardware è intercambiabile; ventitré anni di misurazioni non lo sono.

Costruire quando serve

Quando non trovo un prodotto che soddisfi le mie esigenze, lo realizzo, in genere attorno ad un ESP8266 con Tasmota, che considero uno dei firmware più maturi per queste applicazioni. In un paio di casi ho sviluppato il firmware direttamente, quando avevo bisogno di funzionalità particolari.

Il punto non è l’autocostruzione in sé: è poter progettare partendo dal problema, invece di adattare il problema ai limiti di un prodotto commerciale.

Correlare i dati

Nel corso del tempo il sistema si è esteso al monitoraggio energetico. Misuro i parametri elettrici principali dell’intero appartamento, mentre alcune utenze vengono misurate singolarmente. Ma la parte interessante non è la visualizzazione dei consumi: è la possibilità di correlare sorgenti completamente diverse. Le decisioni sul riscaldamento tengono conto della temperatura esterna rilevata dalla stazione meteorologica. L’irrigazione considera umidità del terreno, condizioni meteo e previsioni locali. I consumi energetici vengono analizzati insieme alle condizioni climatiche e al funzionamento degli impianti. Tutto questo è possibile perché ogni dato confluisce nello stesso archivio, descritto con lo stesso schema.

La casa funziona anche senza Internet

Nessun componente del sistema dipende da un servizio esterno (cloud) per funzionare. I dispositivi non inviano informazioni ai produttori, non richiedono connessioni permanenti e non smettono di operare se un servizio remoto cambia API o viene dismesso. Internet serve per gli aggiornamenti, per l’accesso remoto, per pubblicare i dati della stazione meteo. Se la connessione cade (e la mia è ridondata), la casa continua a funzionare esattamente come prima.

La scelta nasce da considerazioni di riservatezza e sicurezza, ma soprattutto da un principio di indipendenza tecnologica: un impianto domestico deve avere una vita utile di decenni, mentre un servizio cloud si misura spesso in pochi anni.

La parte che nessuno racconta

Un sistema di questo tipo non è un insieme di dispositivi installati una volta e poi dimenticati. È un’infrastruttura distribuita: sensori, attuatori, reti radio, una rete IP dedicata, un broker MQTT, Home Assistant, un database, il software di supervisione. Ognuno di questi componenti può avere un problema – una batteria che si esaurisce, un processo che si arresta, un collegamento radio degradato.

Per questo il sistema non si limita a controllare la casa: controlla continuamente anche se stesso. Nel corso degli anni ho sviluppato un livello di supervisione che svolge il ruolo di watchdog: verifica periodicamente lo stato dei servizi, controlla che i sensori continuino a trasmettere, segnala batterie in esaurimento, evidenzia anomalie nelle comunicazioni. Se un sensore smette di inviare dati e nessuno se ne accorge, l’automazione continua apparentemente a funzionare – ma prende decisioni sulla base di informazioni non aggiornate.

Paradossalmente, una parte significativa del software non serve a gestire il riscaldamento o l’irrigazione, ma a verificare che il sistema incaricato di farlo sia ancora in salute.

Il costo reale

Sarebbe disonesto descrivere questo approccio senza parlarne dei limiti. Richiede competenze di reti, sistemi operativi, database, protocolli di comunicazione, hardware e sviluppo software. Richiede disponibilità a fare manutenzione. Non è una soluzione plug-and-play e non pretende di esserlo.

In cambio offre qualcosa di difficile da ottenere con un sistema commerciale: il pieno controllo dell’infrastruttura, dei dati e della sua evoluzione nel tempo.

Più che domotica

Se dovessi descrivere questo progetto oggi, probabilmente eviterei la parola domotica. La domotica è quello che si vede: un termosifone che si regola, una pompa che irriga, un grafico dei consumi. Quello che mi interessa davvero è l’infrastruttura che rende possibili queste applicazioni – un sistema distribuito, costruito con componenti sostituibili, in cui il valore non risiede nei dispositivi installati oggi, ma nella continuità dei dati raccolti negli anni e nella libertà di usarli come riterrò opportuno anche in futuro.

In sintesi

L’irrigazione è l’ultima funzione aggiunta, ma non cambia la natura del sistema. È solo l’ennesima applicazione di un’infrastruttura che non è nata solo per automatizzare una casa, ma per rendere persistente, utilizzabile e indipendente il valore dei dati nel tempo.