Che cos'è MQTT? Il protocollo MQTT spiegato

MQTT è un protocollo di messaggistica leggero basato su publish/subscribe. Dispositivi e applicazioni si collegano a un unico server, il broker, e pubblicano messaggi su topic con un nome come site/dub01/mdb1/main-incomer. Ogni client iscritto a quel topic riceve il messaggio dal broker. Publisher e subscriber non si indirizzano mai a vicenda, quindi un contatore, una dashboard e una piattaforma cloud possono condividere dati senza conoscersi. MQTT funziona su TCP sulla porta 1883, o su TLS sulla porta 8883, e la sua intestazione fissa è di soli due byte. Poiché ogni dispositivo si collega in uscita al broker e un numero qualsiasi di sistemi può iscriversi agli stessi dati, è diventato il protocollo più diffuso per inviare via Internet la telemetria di sensori e contatori.

Come funziona MQTT

Un client apre una connessione TCP verso il broker e invia CONNECT con il proprio identificativo, le credenziali e un intervallo di keep-alive. Il broker risponde CONNACK. Un publisher invia poi pacchetti PUBLISH; un subscriber invia SUBSCRIBE con uno o più filtri di topic, e da quel momento il broker gli invia ogni PUBLISH corrispondente. Se nell'intervallo di keep-alive non passa alcun pacchetto, il client invia PINGREQ, e il broker chiude una connessione che resta muta per una volta e mezza l'intervallo.

Poiché ogni client apre una connessione in uscita verso il broker, il gateway di un sito non ha bisogno di porte aperte in ingresso. È il principale motivo pratico per cui MQTT ha sostituito i protocolli a polling per inviare i dati fuori dal sito.

Topic e caratteri jolly

I topic sono stringhe che distinguono maiuscole e minuscole. Un client non crea un topic: ci pubblica, e il broker instrada il messaggio verso ogni sottoscrizione corrispondente. Una sottoscrizione può usare due caratteri jolly:

+ sostituisce un livello e # tutto il resto dell'albero, quindi deve stare in fondo. I topic che iniziano con $ sono riservati al broker, come $SYS/ per le sue statistiche, e un filtro che inizia con un carattere jolly non li include.

Progetta l'albero dei topic prima che il primo dispositivo pubblichi, perché ogni subscriber e ogni regola di accesso dipende da esso. Un buon albero va dall'ambito più ampio al più stretto (organizzazione, sito, quadro, dispositivo, poi il tipo di messaggio), mette ogni dispositivo in un solo punto ed esclude i valori che cambiano, come una lettura, un timestamp o un numero di sessione. Separa i topic di telemetria, stato e comando, così da concedere il permesso di scrittura solo dove serve.

QoS, messaggi retained e last will

MQTT ha tre livelli di consegna. Valgono per una tratta alla volta: dal publisher al broker e dal broker a ogni subscriber.

Un messaggio retained viene conservato dal broker come ultimo valore del suo topic e inviato subito a ogni nuovo subscriber: è adatto allo stato di un dispositivo, ma può consegnare una lettura obsoleta. Il last will è un messaggio che il broker pubblica per un client la cui connessione cade senza un DISCONNECT regolare: è così che un subscriber scopre che un gateway è offline. La guida a QoS e messaggi retained MQTT tratta entrambi nel dettaglio, insieme alla scadenza dei messaggi e alle sessioni persistenti.

Porte e sicurezza di MQTT

MQTT di per sé ha solo un campo per nome utente e password. Cifratura, identità del server e certificati client vengono da TLS, e il controllo degli accessi dalle regole del broker su quale client può pubblicare o iscriversi a quali topic. La guida a MQTTS spiega i certificati, la verifica del nome del server e come provare una connessione TLS dalla riga di comando.

MQTT 3.1.1 e MQTT 5 a confronto

MQTT è nato nel 1999 per la telemetria degli oleodotti via satellite. OASIS ha pubblicato MQTT 3.1.1 come standard nel 2014, diventato ISO/IEC 20922 nel 2016, e MQTT 5.0 nel 2019. La maggior parte dei broker supporta entrambe le versioni, e molti dispositivi parlano ancora solo la 3.1.1.

Per la telemetria, le funzioni più utili di MQTT 5 sono i codici di motivo, perché il client vede che il broker ha rifiutato un messaggio, e la scadenza dei messaggi, perché un comando ritardato da un'interruzione viene scartato invece di essere eseguito in ritardo.

Payload: JSON, Sparkplug B e il contratto dei dati

MQTT trasporta byte e non dice nulla del loro significato. La maggior parte delle piattaforme energetiche si aspetta JSON, per esempio:

{"ts":"2026-10-28T09:15:00Z","kW":184.2,"kWh":1532871.4,"V1":231.4,"PF":0.94,"q":"good"}

Il topic dice di quale contatore si tratta; il payload porta l'ora della misura, i valori e un indicatore di qualità. Le unità e il significato di ogni chiave devono essere scritti e concordati con ogni subscriber: kW o W, energia prelevata o netta, l'ora del contatore o l'ora in cui il gateway ha ricevuto il valore. È questo accordo, non il supporto di MQTT, a far lavorare insieme due sistemi. La guida all'interoperabilità elenca che cosa deve fissare un contratto dei dati, e la guida a ora della misura e ora di arrivo spiega perché l'ora della misura va nel payload.

Sparkplug B, specifica della Eclipse Foundation diffusa nei sistemi industriali, fissa invece il contratto. I topic seguono spBv1.0/<group>/<message type>/<edge node>/<device>, il payload è binario in Protocol Buffers e ogni nodo edge pubblica un certificato di nascita con le sue metriche e un certificato di morte (tramite il last will) quando si disconnette. Un subscriber può così scoprire i dispositivi e segnare i dati come obsoleti senza alcun accordo specifico, al prezzo di un formato binario che richiede un client compatibile con Sparkplug per essere letto.

Esempio pratico: quanti dati consuma la telemetria MQTT?

Cinquanta contatori pubblicano ogni 10 secondi il messaggio JSON qui sopra con QoS 1. Il payload è di 88 byte e il topic di 28 byte, quindi ogni pacchetto PUBLISH è di circa 122 byte. TLS aggiunge circa 22 byte per record e TCP e IP circa 52 byte per segmento: ogni messaggio occupa sulla linea circa 200 byte.

Il messaggio per sito porta le 50 letture in un array JSON di circa 3.650 byte (circa 73 byte per contatore, con un solo timestamp per tutto il messaggio), più topic e intestazioni, che TCP suddivide in tre segmenti.

Nel primo caso i PUBACK di ritorno aggiungono circa altri 30 MB al giorno. Su una linea fissa nulla di tutto questo conta; su una SIM cellulare decide il piano dati. Raggruppare le letture di un sito in un solo messaggio, o inviare solo le variazioni, riduce l'overhead. Il calcolatore della domanda per intervallo aiuta a scegliere un intervallo che risponda ancora alla domanda a cui servono i dati.

MQTT a confronto con altri protocolli

MQTT è di solito il collegamento tra un sito e una piattaforma, mentre Modbus, BACnet e OPC UA leggono i dispositivi in sito. Il confronto tra OPC UA, Modbus e MQTT li mette a confronto per i progetti industriali, e Che cos'è Modbus? spiega il lato a polling.

MQTT con EpiSensor

Edge sul Gateway ZGW-20 legge i dispositivi Zigbee, Modbus, BACnet e LoRaWAN del sito, registra ogni lettura con l'ora della misura e pubblica verso il broker di una piattaforma come client MQTT, di norma via MQTTS sulla porta 8883 con un certificato client. Pubblica con QoS 1 e conserva le consegne fallite in una coda locale, che ripropone con i timestamp originali quando il broker torna disponibile. Topic e payload seguono il contratto della piattaforma, e Collegare Edge alla propria piattaforma mostra i modi in cui Edge invia i dati.