Ci sono progetti che nascono per curiosità, per il piacere di sperimentare una tecnologia nuova. E poi ci sono quelli che nascono perché devono funzionare, senza scuse. ElderAid appartiene a questa seconda categoria, ed è nato da un’esigenza molto concreta: garantire un canale di sicurezza a un parente anziano che vive da solo, a quasi mille chilometri di distanza. Una distanza che non puoi colmare passando a controllare, e che trasforma ogni telefonata fuori orario in un piccolo interrogativo. In un contesto del genere non servono soluzioni domotiche complesse, né telecamere, né infrastrutture elaborate. Serve una cosa sola: essere avvisati immediatamente se succede qualcosa.

Quando inizi a progettare qualcosa che deve funzionare davvero, le priorità cambiano. Non stai più ottimizzando prestazioni astratte, ma affidabilità operativa. E questo significa confrontarsi con vincoli molto concreti: il dispositivo deve essere leggero, portabile senza fastidio, con un’autonomia che si misura in mesi o anni, e deve essere utilizzabile senza alcuna curva di apprendimento. Da qui la scelta iniziale di un radiocomando a 433 MHz, minuscolo, alimentato da una CR2025 che dura anni, e con un ricevitore come l’RX480E che espone direttamente segnali digitali puliti, pronti per un microcontrollore.

La filosofia è stata chiara fin dall’inizio: ridurre al minimo la complessità. Ho iniziato con un ESP32 configurato nel modo più essenziale possibile: ingressi digitali, BLE integrato, nessun Wi‑Fi, nessun TLS, nessun cloud. La rinuncia al Wi‑Fi non è stata un vezzo tecnico, ma una scelta dettata dalla realtà: la persona che deve usare il sistema, come spesso accade con gli anziani, non ha una connessione Internet domestica. Ha però un cellulare con i dati attivi, ed è quello il canale più affidabile e costante su cui fare affidamento. In questo scenario, attivare il Wi‑Fi sull’ESP sarebbe stato inutile, oltre che una fonte di complessità e consumo energetico non necessari. Meglio concentrarsi su ciò che serve davvero: un evento che genera una notifica BLE, accompagnato da un heartbeat periodico per confermare che il dispositivo è vivo. Un firmware minimale è un firmware che si rompe meno, e questo era l’obiettivo.

La scelta successiva può sembrare controintuitiva, ma in realtà è perfettamente razionale: invece di collegare l’ESP32 direttamente a Internet, ho delegato tutto allo smartphone Android dell’anziano. È un dispositivo che ha già connettività LTE, una batteria capiente, un sistema operativo stabile, uno stack BLE nativo e un supporto TLS completo. In altre parole, tutto ciò che serviva era già lì, senza aggiungere hardware, configurazioni o manutenzione. Lo smartphone è diventato il ponte BLE‑Internet: riceve l’evento locale e lo inoltra a un piccolo server remoto. Il firmware resta semplice, mentre la logica più articolata si sposta dove è più facile aggiornarla e controllarla.

Anche il backend segue la stessa impostazione. Nessuna architettura distribuita, nessun microservizio, nessun database esotico. Solo un’applicazione FastAPI con pochi endpoint, un WebSocket sempre aperto per la parte realtime, uno stato persistito su file JSON e log rotanti. Una struttura volutamente “noiosa”, nel senso migliore del termine: prevedibile, trasparente, facile da mantenere e da ispezionare.

L’ultimo elemento è l’app remota, quella che porto in tasca. Un servizio in foreground mantiene aperta la connessione WebSocket e riceve gli eventi in tempo reale. Quando arriva un allarme, la notifica è immediata e la schermata si apre in full‑screen. La latenza reale è sotto il secondo, e questo fa la differenza: non c’è polling, non c’è attesa, c’è solo un flusso diretto di eventi.

A un certo punto mi sono reso conto che non stavo più costruendo semplicemente un “pulsante di emergenza”. Stavo assemblando un sistema completo: firmware embedded, gateway BLE, backend realtime, app always‑on, protocollo eventi, heartbeat, watchdog, architettura modulare. In pratica, un piccolo ecosistema IoT distribuito, nato da un’esigenza personale ma con caratteristiche abbastanza generali da diventare un proof‑of‑concept riutilizzabile.

In effetti ElderAid è una base solida per qualunque scenario che richieda allarmi remoti, panic button, telemetria leggera, monitoraggio ambientale, sistemi di sicurezza DIY o sperimentazione radio. La filosofia non è cambiata: componenti piccoli, responsabilità chiare, nessuna magia. Ogni parte fa una sola cosa, e la fa bene: la filosofia Kiss.

Il messaggio più importante, però, è un altro. Quando costruisci qualcosa per una persona a cui tieni davvero, non ottimizzi per la lista delle funzionalità. Ottimizzi per la semplicità, la prevedibilità, la robustezza. E spesso le soluzioni migliori sono quelle più sobrie: un ESP32, un telefono, un server essenziale, una notifica che arriva quando deve arrivare.

E basta.

Tutto il materiale, con licenza CC BY-NC-SA 4.0, è sul mio github su https://github.com/grutig