Madonnina — irrigazione di precisione

Un'azienda agricola con 35 settori irrigui e tre pompe da gestire, su un impianto reale: rete cellulare al limite della copertura, alimentazione non sempre continua, sensori a basso costo, manutenzione scomoda. Una centralina installata in campo deve restare in piedi per mesi senza che qualcuno ci passi sopra.

Prima del sistema attuale c'era una dashboard Node-RED legacy con ventinove schede e oltre duemilatrecento nodi: funzionava, ma era diventata fragile e leggibile solo da chi l'aveva costruita.

A usarla sono tre persone, ognuna per cose diverse: chi pianifica i turni e regola le pressioni, chi fa debug e calibrazione sul campo, chi cura i filtri e la fertirrigazione. Una sola interfaccia che serviva male tre lavori distinti.

Il progetto si chiama S.A.I.A. ed è cofinanziato da Unione Europea e Regione Sicilia. Oggi sul campo ci sono dieci centraline che pilotano l'impianto in modo continuo: sulla scheda gira il firmware Arduino v5, in mano alle persone c'è una webapp in React.

Sul mercato non c'era un sistema pronto con queste caratteristiche — letture di pressione in tempo reale, gestione controllata delle pompe, affidabilità in campo per mesi senza intervento. Costruito su misura per quest'azienda, ma pensato fin dall'inizio come sistema replicabile e personalizzabile per altre realtà agricole simili.

Niente di quello che c'era già è stato buttato via. Tre stazioni meteo in campo (una Ecowitt, due SenseCAP) e i diciannove sensori di umidità del suolo della rete Weenat — componenti commerciali che l'azienda aveva già acquistato — sono integrati attraverso le loro API aperte. Alimentano un consiglio irriguo che suggerisce all'operatore quando e dove irrigare.

L'app è una PWA pensata prima per il telefono: una mappa che mostra in un attimo lo stato dell'impianto, una dashboard di diagnostica per ogni centralina, uno storico per indagare un'anomalia. Tre viste per i tre lavori distinti — turni e pressioni, debug, fertirrigazione.

Oltre alle viste, la webapp porta in tasca strumenti che prima non c'erano: una chat per dialogare col sistema in linguaggio naturale, un comando vocale per dare istruzioni senza tastiera quando si è in campo con le mani sporche, suggerimenti dell'AI che osservano lo stato dell'impianto e propongono cosa fare — fino a due alla volta, non invadenti.

Il sistema è raccontato anche in un video sul canale InCampagna Sicilia (link in fondo alla pagina).

Il metodo viene prima dell'IA. Una specifica chiara di cosa serve, una scelta architettonica spiegata in poche righe, poi Claude Code fa il lavoro di scrittura. Senza il metodo l'IA avrebbe prodotto un sistema bello ma fragile; senza l'IA, da solo, non sarebbe stato fattibile in tempi accettabili.

Le abitudini sono scritte nel repo, non in slide. Ogni decisione importante — perché Arduino Edge Control, perché dual publish MQTT, perché la mediana invece della media — sta in un Architectural Decision Record di poche righe; ogni sessione lascia un log. Tornare sopra al codice dopo un mese significa ritrovare esattamente il ragionamento dell'epoca.

Un esempio. L'algoritmo che legge la pressione è stato iterato tre volte sul feedback di chi lo usa in campo: prima un clone della versione storica (*«è la v4.2 problematica»*), poi un downgrade alla v3 pulita (*«è solo un downgrade, dobbiamo migliorare»*), infine la versione che è finita in produzione — mediana di ventuno campioni. L'IA propone, l'operatore reagisce, si itera.

Quando un fix veloce non funziona, si ferma tutto. La regola è semplice: dopo due tentativi falliti sullo stesso bug si smette di indovinare e si leggono per intero i datasheet, le librerie, il codice. Il tempo speso a leggere è sempre minore di quello speso a tirare a indovinare.

Controllo totale dello stack, dal server al telefono — invece di servizi managed sul backend e di un'app nativa sul frontend.

Sul backend, l'intero sistema vive su un server Hetzner gestito in casa: Docker orchestra cinque container — Mosquitto come broker MQTT, Node-RED come cervello dell'irrigazione, InfluxDB per la telemetria, Grafana per il monitoraggio, un bridge per la stazione meteo Ecowitt. L'alternativa era comprare AWS IoT Core, InfluxDB Cloud, Grafana Cloud: più costo mensile, meno controllo, meno capacità di mettere le mani su quello che succede sotto. Quella stessa capacità — leggere i log del broker, riavviare un container in dieci secondi — su un altro progetto ha permesso di trovare cinque bug strutturali in una libreria di terze parti.

Sul frontend, la webapp è una PWA — React, costruita con Vite. Per pubblicare app native vere sugli store servirebbe l'iscrizione all'Apple Developer Program (99 dollari l'anno per restare attivi) e il passaggio dal Google Play Store con account sviluppatore e review: settimane di onboarding e un costo ricorrente per servire tre utenti che vivono sul telefono ogni giorno. Una PWA si installa dalla home del telefono con un tap, si aggiorna istantaneamente senza passare da nessuno store, e in più funziona anche da desktop quando l'operatore è davanti al computer in ufficio. Capacitor resta come carta di riserva: se un giorno servirà una versione store, la stessa codebase la produce.

Il compromesso è onesto: la responsabilità delle operations — backup, sicurezza, aggiornamenti — resta in casa, e alcune API hanno limiti rispetto al nativo puro. In cambio, un sistema che si capisce fino in fondo, costi predicibili, zero dipendenze da fornitori cloud.

Dieci centraline lavorano in campo ventiquattr'ore su ventiquattro dal 2024. La dashboard operatore, che prima era costruita su una Node-RED legacy da oltre duemilatrecento nodi, oggi è una webapp React per il telefono; Node-RED resta in produzione come cervello del backend.

L'operatore gestisce turni di irrigazione, pressioni e settori dal telefono. Le tre persone che usano il sistema lo fanno ognuna dalla propria vista, senza pestarsi i piedi.

Il sistema continua a evolversi — sensori aggiunti, nuove versioni del firmware, nuove funzioni della webapp. È un sistema in esercizio.