ESP32, Wi-Fi e Web UI: IoT locale (ESP-IDF)

L’ESP32 permette di costruire nodi IoT affidabili che espongono API REST e una Web UI moderna direttamente dal microcontrollore, senza cloud e senza app dedicate.

ESP32, Wi‑Fi e Web UI: una guida tecnica all’IoT locale

L’Internet of Things non è soltanto una costellazione di gadget connessi: è una strategia per portare misurazioni e controllo là dove servono, con tempi di risposta stretti e indipendenza dal cloud quando necessario. Una sonda ambientale che espone una pagina web direttamente dal microcontrollore è un esempio perfetto di IoT “locale”: si accende il dispositivo, ci si collega via Wi‑Fi, si apre il browser e i dati compaiono, senza app, senza account, senza dipendenze. In questo articolo descrivo in modo tecnico, ma non legato a un singolo progetto, come strutturare un sistema del genere con ESP32, ESP‑IDF in C e una Web UI moderna.

Perché proprio ESP32

ESP32 unisce due core a 32 bit, Wi‑Fi 2,4 GHz e periferiche come I²C, SPI e UART in un SoC dal costo contenuto. La presenza del Wi‑Fi integrato evita moduli esterni, mentre la toolchain ESP‑IDF consente di lavorare in C con controllo diretto su task, heap e driver. Questo equilibrio tra potenza e semplicità è ideale per trasformare un sensore economico in un nodo intelligente che misura, elabora, pubblica API e presenta un’interfaccia grafica fruibile da qualsiasi dispositivo.

Dal sensore al browser

Il flusso parte da una routine di misura — per esempio un sensore di temperatura e umidità su bus I²C — che legge a intervalli regolari e calcola eventuali grandezze derivate, come punto di rugiada o indici di comfort. I campioni più recenti vengono tenuti in memoria in un buffer circolare; l’ultimo è esposto da un endpoint leggero, mentre la serie storica permette all’interfaccia di disegnare grafici fluidi. La scelta di un ring buffer evita allocazioni imprevedibili e rende il sistema reattivo anche su MCU con RAM limitata.

Rete e indirizzabilità

Un dispositivo può funzionare come Access Point creando la propria rete locale, oppure come Station collegandosi al router dell’utente; in alcuni casi conviene mantenere entrambe le modalità. L’AP è comodo per il primo avvio e per scenari offline; la STA offre NTP, integrazione in LAN e comunicazioni server‑side. Per rendere l’accesso intuitivo è utile pubblicare un nome mDNS — ad esempio slx.local — così l’utente può aprire la pagina senza ricordare l’indirizzo IP. Quando si sceglie l’indirizzo dell’AP, conviene evitare sottoreti comuni alla rete domestica, privilegiando spazi come 192.168.50.1 o 10.10.10.1 per ridurre le collisioni di routing sui client.

Un web server a bordo

Servire una pagina dall’ESP32 significa fornire asset statici e poche API JSON. Con ESP‑IDF si può incorporare l’HTML nel firmware durante la build e restituirlo con un handler del server HTTP. Questa soluzione elimina la necessità di un filesystem a bordo quando la UI è composta da uno o due file e, se abbinata alla compressione gzip, riduce la banda e i tempi di caricamento. Gli endpoint più utili sono in genere un /api con l’ultimo campione e un /history con la serie temporale compatta; per la diagnostica si può aggiungere un /info che descrive dispositivo, versione del firmware e hostname.

Modello dati e tempi

I dati di misura viaggiano in JSON con campi espliciti e unità chiare. Per i timestamp, se il dispositivo è in STA e ha sincronizzato l’orologio via SNTP è naturale inviare l’epoch in millisecondi; in modalità AP pura, dove l’accesso a Internet potrebbe mancare, è altrettanto valido inviare l’uptime e lasciare all’interfaccia la conversione in etichette relative. Questa strategia rende la UI indipendente dalla presenza del tempo assoluto.

L’interfaccia utente

Un’unica pagina HTML con stile moderno, reattiva e leggera, può mostrare il logo, il nome del dispositivo, il tipo di sensore e quattro riquadri per le grandezze principali. Un grafico Canvas — senza librerie esterne — rende il sistema snello e facilmente portabile; con un leggero smoothing e un tooltip contestuale l’esperienza è piacevole anche su smartphone. Lato rete è utile un indicatore di stato, mentre nel footer è naturale ospitare il brand e i riferimenti aziendali. Poiché tutto è servito dal dispositivo, non ci sono problemi di CORS e l’utente vede i dati in tempo reale.

Task, memoria e affidabilità

Separare i compiti in task distinti semplifica la stabilità: una routine di misura non deve bloccare l’HTTP, e le risposte API non devono dipendere dall’aggiornamento del grafico. L’inizializzazione di NVS va resa robusta con una gestione dei casi di pagina piena o cambio di versione, mentre l’avvio del Wi‑Fi merita uno stack di dimensioni adeguate per evitare overflow in fase di setup. Per aumentare la resilienza, soprattutto durante lo sviluppo via USB, è utile ridurre la potenza di trasmissione e abilitare modalità di risparmio energetico, così da evitare brownout o disconnessioni della seriale quando parte l’AP.

Sicurezza ragionata

In un contesto locale l’autenticazione può essere minimale, ma vale la pena impostare WPA2 sull’AP quando i dati non sono banali e prevedere limiti di frequenza alle API per evitare abusi involontari dai browser. In ambiente di produzione, con dispositivi in STA, l’uso di TLS richiede una valutazione attenta dei costi in RAM e latenza: l’ESP32 lo supporta, ma conviene pianificarlo insieme alla politica di aggiornamento over‑the‑air e alla gestione dei certificati.

Provisioning e aggiornamenti

La transizione da AP a STA può essere guidata da una pagina di provisioning con captive portal: l’utente si connette all’AP del dispositivo, sceglie la rete di casa, inserisce la password e il dispositivo salva le credenziali in NVS. Per il ciclo di vita del firmware è comodo adottare partizioni a doppio slot e un endpoint HTTP dedicato agli aggiornamenti, con verifica della versione nell’endpoint informativo; in questo modo è possibile distribuire miglioramenti all’interfaccia e ai driver senza toccare l’hardware sul campo.

IoT, casi d’uso e potenzialità con ESP32

L’IoT locale abilita scenari che spaziano dalla domotica all’industria leggera. Un nodo che misura temperatura e umidità diventa la base per la regolazione del clima in piccoli impianti, per la protezione di archivi e musei o per la sorveglianza di quadri elettrici e locali tecnici. Con lo stesso paradigma, cambiando sensore, si possono monitorare qualità dell’aria, luminosità, vibrazioni o energia consumata; si possono generare avvisi in LAN, collegarsi a sistemi esistenti via MQTT o esportare metriche verso dashboard di reparto. ESP32 è particolarmente adatto perché unisce connettività affidabile, risorse sufficienti per una UI gradevole e una piattaforma di sviluppo matura. La possibilità di servire tutto in locale semplifica la privacy, riduce i costi ricorrenti e migliora la latenza.

Conclusione

Un ESP32, un sensore economico e una pagina web ben progettata sono sufficienti per dare forma a una sonda IoT professionale. La scelta di restare vicini all’hardware con ESP‑IDF, di servire una UI leggera e di esporre API locali produce sistemi che si capiscono, si mantengono e crescono. È una base solida per sperimentare oggi e industrializzare domani, tenendo insieme esperienza utente, sicurezza e affidabilità.