Cos’è MQTT e come viaggia un messaggio dal sensore al software
MQTT è un protocollo di messaggistica leggero in cui chi produce dati li pubblica su un server centrale, il broker, e chi li usa si iscrive agli argomenti che gli interessano. Chi pubblica non sa chi legge, e viceversa: aggiungere un nuovo utilizzatore dei dati non richiede di toccare i dispositivi.
Come funziona
MQTT funziona per argomenti, i topic: stringhe a livelli separate da una barra, come stagionatura/cella3/umidita. Un dispositivo pubblica un messaggio su un topic, il broker lo consegna a tutti i client iscritti a quel topic. Ogni messaggio porta un livello di QoS: 0 lo invia una volta senza conferma, 1 garantisce che arrivi almeno una volta (a volte due), 2 garantisce che arrivi esattamente una volta, con più scambi di rete.
Il protocollo è stato scritto nel 1999 da Andy Stanford-Clark di IBM e Arlen Nipper di Arcom per controllare oleodotti attraverso collegamenti satellitari lenti e pagati a byte. Da lì vengono l’intestazione minima e la tolleranza alle connessioni che cadono. Oggi è uno standard OASIS e, dal 2016, la norma ISO/IEC 20922.
Un esempio: sei celle di stagionatura
Un salumificio ha sei celle di stagionatura, ciascuna con una sonda di temperatura e umidità che pubblica ogni 30 secondi. Sul broker passano messaggi come questi.
| Topic | Contenuto del messaggio | QoS | Chi lo legge |
|---|---|---|---|
| stagionatura/cella3/umidita | {"v": 78.4, "u": "%", "ts": "2026-10-30T06:00:00Z"} | 1 | Dashboard, storico, allarmi |
| stagionatura/cella3/temperatura | {"v": 13.2, "u": "°C", "ts": "2026-10-30T06:00:00Z"} | 1 | Dashboard, storico, allarmi |
| stagionatura/cella3/stato | {"porta": "chiusa"}, messaggio conservato | 1 | Dashboard |
Esempio illustrativo: nomi dei topic e formato dei messaggi si decidono a inizio progetto.
Cosa succede ai messaggi
Tre programmi sono iscritti: la dashboard del reparto, un servizio che scrive i valori in un database storico e uno che manda un avviso se l’umidità esce dalla fascia impostata. Quando il responsabile qualità chiede un report settimanale per lotto, si aggiunge un quarto iscritto e le sonde non se ne accorgono.
Il messaggio di stato è pubblicato come retained: il broker conserva l’ultimo valore, e una dashboard aperta alle 7 di mattina sa subito che la porta è chiusa, senza aspettare il prossimo cambio.
Errori comuni
- Considerare il broker un archivio. Conserva al massimo l’ultimo messaggio retained per topic; lo storico lo deve scrivere qualcuno in un database.
- Dare lo stesso client ID a due sonde, magari clonando la configurazione. Il broker accetta una sola connessione per ID: quando si collega la seconda chiude la prima, e le due si scollegano a vicenda in continuazione.
- Mandare valori senza unità di misura e senza ora di lettura. Se il messaggio arriva in ritardo dopo un’interruzione, l’ora di arrivo non è l’ora della misura.
- Iscrivere i servizi in produzione al topic jolly #, che riceve tutto. Ogni servizio si iscrive solo ai rami che usa.
Domande frequenti
Parliamone in 30 minuti
Raccontateci il processo e cosa non funziona: vi diciamo se e come lo risolveremmo, con tempi e costi indicativi.
Matteo Budriesi
CEO e co-founder di Webion, la software house di Modena che sviluppa software su misura e agenti AI per le aziende.
Aggiornato il 30/10/2026