Che cos'è MQTT e perché ogni lezione di IoT a scuola richiede improvvisamente un broker?
MQTT è un protocollo di messaggistica leggero che permette ai microcontrollori usati in classe di condividere dati senza connessioni dirette peer-to-peer. Instradando il traffico attraverso un broker centrale, aggira i firewall scolastici restrittivi ed evita che i dispositivi si blocchino sotto il carico di rete.
Se avete dato di recente un'occhiata a un programma di Coding e Robotica allineato al CAPS, o avete provato a progettare un'attività pratica di Internet of Things (IoT) per la vostra classe, molto probabilmente vi siete imbattuti nell'acronimo MQTT e nel requisito di un \"broker MQTT\". Per un insegnante di informatica o un coordinatore tecnologico oberato, tutto questo può sembrare complessità inutile. Perché un microcontrollore, come un ESP32 o un Raspberry Pi Pico W, non può semplicemente inviare i dati dei suoi sensori direttamente al portatile o al telefono di uno studente sulla rete Wi-Fi locale?
La risposta breve è che la comunicazione diretta fra dispositivi è fragile, pesante in termini di risorse e quasi del tutto incompatibile con la sicurezza delle reti scolastiche. MQTT (Message Queuing Telemetry Transport) risolve il problema separando chi invia i dati da chi li riceve, instradando tutti i messaggi attraverso un gestore centrale chiamato broker. È lo standard di settore per l'IoT industriale ed è sempre più indispensabile per il physical computing in classe.
La bacheca della classe: capire il pub/sub
Per capire perché MQTT funziona, immaginate una classe di 40 studenti. Se ogni studente che volesse sapere la temperatura esterna dovesse avvicinarsi all'unico studente seduto vicino alla finestra e chiedere \"quanto fa fuori?\", chi siede alla finestra passerebbe l'intera lezione a rispondere a domande ripetitive invece di fare il proprio lavoro. Se altri dieci studenti volessero sapere quando c'è il prossimo intervallo, dovrebbero interrompere direttamente l'insegnante.
Ora introducete una bacheca nel corridoio. Chi siede alla finestra scrive \"Temperatura: 22°C\" su un foglietto adesivo e lo appunta sotto l'intestazione \"Meteo\". L'insegnante appunta \"Prossimo intervallo: 10:30\" sotto \"Orario\". Chiunque voglia sapere la temperatura o l'orario dell'intervallo va semplicemente alla bacheca e legge. Chi siede alla finestra non sa né si preoccupa di chi legge la temperatura: si limita a pubblicare l'aggiornamento. Chi legge non ha bisogno di disturbare chi siede alla finestra.
Questo è il modello Publish/Subscribe (pub/sub) che MQTT utilizza:
- Il publisher: il microcontrollore con un sensore (chi siede alla finestra) che invia i dati al broker.
- Il subscriber: la dashboard, l'app sul telefono o il database (gli studenti che leggono la bacheca) che vuole ricevere quei dati.
- Il broker: il server centrale (la bacheca) che riceve i messaggi dai publisher e li instrada ai subscriber giusti.
Il nucleo tecnico: topic, messaggi ritenuti e testamenti
MQTT si basa su tre concetti fondamentali per mantenere la comunicazione efficiente e affidabile, anche su connessioni wireless scadenti.
1. I topic: i messaggi non vengono inviati a dispositivi specifici; vengono pubblicati su \"topic\". I topic sono strutturati con barre oblique, creando una gerarchia come school/lab1/temp oppure home/garden/moisture. Un dispositivo può sottoscrivere un topic molto specifico, oppure usare caratteri jolly per ascoltare più topic insieme. Per esempio, sottoscrivere school/+/temp permette a un'unica dashboard di mostrare le letture di temperatura di ogni laboratorio dell'istituto.
2. I messaggi ritenuti: normalmente, se un sensore pubblica una lettura e in quell'esatto millisecondo nessuno è in ascolto, il messaggio è perso per sempre. Se uno studente apre la sua app di dashboard cinque minuti dopo, vede una schermata vuota finché il sensore non trasmette di nuovo. Impostando il flag \"retained\" su un messaggio, il publisher dice al broker: \"tieni in archivio quest'ultimo valore. La prossima volta che qualcuno sottoscrive questo topic, daglielo subito\". È fondamentale per i dati che cambiano lentamente, come l'umidità del terreno o il livello di una cisterna.
3. Last Will and Testament (LWT): i microcontrollori nelle classi sudafricane subiscono disconnessioni frequenti e improvvise a causa del load-shedding, di batterie scariche o di studenti che staccano per sbaglio i cavi di alimentazione. Quando un dispositivo si connette per la prima volta al broker, registra un messaggio di \"ultima volontà\" (per esempio, topic: status/sensor1, messaggio: offline). Se il dispositivo perde all'improvviso l'alimentazione senza inviare un segnale di disconnessione pulita, il broker rileva la connessione interrotta e pubblica automaticamente il messaggio di \"ultima volontà\" per suo conto, avvisando il resto del sistema che quell'hardware è offline.
Tre cose che vanno storte su una rete scolastica
Per quanto MQTT sia robusto, implementarlo in un contesto scolastico richiede di fare i conti con la realtà dell'infrastruttura informatica della scuola. Tre modalità di guasto ricorrenti mandano regolarmente all'aria le lezioni.
Guasti tipici delle reti scolastiche
| Caratteristica di rete | Perché esiste | Come manda all'aria la lezione di IoT |
|---|---|---|
| Sicurezza WPA2-Enterprise | Protegge le reti scolastiche richiedendo nome utente e password individuali per ogni studente. | I microcontrollori standard (come i chip ESP8266 di base) non riescono a negoziare facilmente i protocolli di sicurezza Enterprise così come sono, e questo impedisce loro di entrare nel Wi-Fi. |
| Isolamento dell'access point (AP) | Impedisce agli studenti di violare o raggiungere i portatili degli altri sulla rete Wi-Fi locale. | Blocca il traffico peer-to-peer locale. Se fate girare un broker MQTT su un Raspberry Pi in classe, i dispositivi degli studenti sullo stesso Wi-Fi non riusciranno a raggiungerlo. |
| Rotazione dinamica degli IP (DHCP) | Riutilizza gli indirizzi IP per evitare che il router della scuola li esaurisca. | Se fate girare un broker locale su un portatile, il suo indirizzo IP cambierà regolarmente. Qualsiasi codice del microcontrollore con un indirizzo IP scritto nel codice non riuscirà a connettersi il giorno dopo. |
Per aggirare questi ostacoli della rete locale, i docenti devono in genere scegliere fra litigare con il proprio reparto IT per ottenere configurazioni personalizzate del router, oppure instradare il traffico attraverso un broker esterno ospitato nel cloud e raggiungibile sulle porte web standard. Per gli insegnanti che cercano una soluzione lineare e pronta per la classe, capace di evitare del tutto questi grattacapi di rete locale, la piattaforma Sheen IoT offre un ambiente MQTT preconfigurato e ospitato nel cloud, progettato appositamente per funzionare entro i vincoli dei firewall scolastici.
Spostando il carico della messaggistica dai microcontrollori a un broker dedicato, MQTT fa sì che, anche se il codice di uno studente non è ottimizzato o il Wi-Fi della scuola vacilla, i dispositivi IoT della classe possano comunicare in modo affidabile e sicuro.
