Livello tecnico · Avanzato
Baseline tecnica verificata: MQTT Version 5.0 OASIS Standard (7 marzo 2019); MQTT 3.1.1 come ISO/IEC 20922:2016, confermato nel 2025
Verifica delle fonti: 10 ottobre 2026
Version-sensitive: sìMQTT standardizza il trasporto publish/subscribe dei messaggi, non il significato del payload né il modello funzionale dell’edificio.
MQTT in breve
MQTT è un protocollo di messaggistica client/server basato sul paradigma publish/subscribe. È progettato per essere leggero, semplice da implementare e adatto anche a contesti con risorse o banda limitate.
Il suo compito principale è trasportare messaggi tra client attraverso un server MQTT, comunemente chiamato broker. Non definisce da solo il modello dati di un edificio, la semantica dei punti, le sequence of operation o il comportamento di un BMS.
Client, broker, publisher e subscriber
Un client MQTT può pubblicare messaggi, sottoscrivere topic o svolgere entrambe le funzioni. Il broker riceve i messaggi pubblicati e li distribuisce ai client che hanno sottoscritto topic compatibili.
Publisher e subscriber non devono conoscersi direttamente. Questo disaccoppiamento è uno dei vantaggi principali di MQTT, ma sposta sul broker e sulla struttura dei topic una parte importante della governance del sistema.
Topic e topic filter
I messaggi MQTT vengono pubblicati su Topic Name. I subscriber usano Topic Filter per stabilire quali messaggi ricevere.
I wildcard + e # possono ampliare la sottoscrizione, ma una gerarchia dei topic non documentata può creare ambiguità, conflitti e accessi troppo ampi.
La struttura dei topic è una decisione applicativa. MQTT non impone una tassonomia universale per edificio, impianto, piano, locale, device, funzione o misura.
Il payload è application-defined
MQTT è agnostico rispetto al contenuto applicativo del messaggio. Il payload può contenere JSON, testo, dati binari, Protobuf o altri formati definiti dall’applicazione.
Due sistemi possono quindi comunicare correttamente via MQTT senza comprendere allo stesso modo il significato dei dati.
Per ottenere interoperabilità reale servono convenzioni o specifiche aggiuntive su topic, schema dei dati, unità, timestamp, qualità, naming, versioni e semantica.
QoS 0, 1 e 2
MQTT definisce tre livelli di Quality of Service per la consegna dei messaggi:
- QoS 0: at most once;
- QoS 1: at least once;
- QoS 2: exactly once a livello del protocollo MQTT.
La scelta del QoS influenza traffico, latenza, stato e affidabilità della consegna. QoS 2 non rende automaticamente idempotente o sicura una funzione applicativa: il comportamento finale dipende anche da come il destinatario gestisce il messaggio.
Retained Message
Un publisher può marcare un messaggio come retained. Il broker conserva il retained message per il relativo topic e può consegnarlo a nuovi subscriber compatibili.
Questo è utile per rappresentare l’ultimo stato noto, ma non equivale a una misura in tempo reale né garantisce che il dato sia ancora valido. Il progetto deve quindi gestire timestamp, freschezza e qualità del dato.
Sessioni e continuità
MQTT mantiene uno stato di sessione tra client e server secondo le regole della versione implementata. MQTT 5.0 introduce proprietà dedicate, tra cui Session Expiry Interval, per controllare la persistenza dello stato della sessione.
Persistenza della sessione, code dei messaggi, QoS e riconnessione devono essere progettati insieme. La presenza di una sessione persistente non sostituisce una strategia di recovery applicativo.
Last Will and Testament
MQTT permette a un client di definire un Will Message che il server può pubblicare quando la connessione termina in determinate condizioni anomale.
Questa funzione può essere utile per segnalare disponibilità o stato operativo, ma non sostituisce un sistema completo di health monitoring. La semantica del Will resta definita dall’applicazione.
Shared Subscriptions
MQTT 5.0 formalizza le shared subscriptions, che consentono di distribuire i messaggi di una sottoscrizione tra più subscriber appartenenti allo stesso gruppo.
Sono utili per scalabilità e bilanciamento del carico, ma cambiano il modello di consegna: ogni messaggio destinato al gruppo viene assegnato a uno dei subscriber compatibili, non necessariamente a tutti.
MQTT 5.0: proprietà e controllo del flusso
MQTT 5.0 amplia significativamente il protocollo rispetto a 3.1.1. Tra gli obiettivi dichiarati da OASIS rientrano scalabilità, migliore error reporting, capability discovery, request/response, estensibilità e supporto a client piccoli.
La versione 5.0 introduce proprietà come User Property, Message Expiry Interval, Response Topic, Correlation Data, Topic Alias e Subscription Identifier. Queste funzioni migliorano il controllo del comportamento, ma richiedono supporto effettivo di client e broker.
MQTT separa trasporto e significato
PUBLISHER → TOPIC → MQTT BROKER → SUBSCRIBER
PAYLOAD / SCHEMA / SEMANTICA restano definiti dall’applicazione o da un profilo aggiuntivo.
La consegna del messaggio non dimostra che mittente e destinatario condividano lo stesso modello informativo.
MQTT non è un protocollo di building automation completo
MQTT non definisce oggetti HVAC, datapoint luce, priorità di comando, gruppi, scene, allarmi di building automation o sequence of operation.
Per questo non è equivalente a BACnet, DALI, KNX o Matter. Può però trasportare dati provenienti da questi sistemi attraverso gateway, edge platform o applicazioni.
MQTT e BMS/BACS
Un BMS o BACS può utilizzare MQTT per scambiare telemetria, eventi, comandi o dati con piattaforme esterne, edge server, analytics o servizi cloud.
L’uso di MQTT non definisce automaticamente quale sistema mantiene l’autorità sulla funzione. Per ogni integrazione bisogna chiarire almeno read, write, command, acknowledgement, ownership e fallback.
MQTT e BACnet
BACnet definisce un modello informativo e servizi specifici per building automation. MQTT definisce invece un trasporto publish/subscribe agnostico rispetto al payload.
Un gateway può trasformare oggetti BACnet in messaggi MQTT, ma il mapping tra oggetti, proprietà, topic e payload è una responsabilità aggiuntiva del progetto.
MQTT e Sparkplug
Sparkplug è una specifica distinta, sviluppata in ambito Eclipse, che definisce convenzioni e strutture per usare MQTT in architetture industriali real-time.
Sparkplug non modifica MQTT. Aggiunge un modello applicativo, namespace, payload e regole operative che riducono l’ambiguità di implementazioni MQTT puramente ad hoc.
La baseline corrente considerata è Sparkplug 3.0, ratificata nel 2022.
Sicurezza
MQTT non impone un unico profilo di cybersecurity. La specifica lascia agli implementatori la scelta di rete, privacy, autenticazione e autorizzazione appropriate al contesto.
Le implementazioni possono usare TLS, autenticazione del client e controlli di autorizzazione sui topic. MQTT 5.0 introduce anche un meccanismo di enhanced authentication.
La sicurezza reale dipende quindi da broker, certificati, credenziali, ACL, segmentazione, logging, aggiornamenti e gestione del lifecycle.
Broker come failure domain
Il broker è un elemento centrale dell’architettura MQTT. Una sua indisponibilità può interrompere la distribuzione dei messaggi anche se publisher e subscriber sono ancora operativi.
Cluster, ridondanza o broker multipli possono aumentare la disponibilità, ma introducono dipendenze aggiuntive su sessioni, stato, routing, bridge e consistenza.
Dalla connessione alla funzione verificata
CLIENT → BROKER → TOPIC → PAYLOAD → SCHEMA → SEMANTICA → LOGICA APPLICATIVA → FUNZIONE VERIFICATA
Il corretto recapito MQTT copre solo una parte della catena necessaria per ottenere interoperabilità funzionale.
Vendor lock-in
MQTT è uno standard aperto, ma questo non elimina automaticamente il lock-in.
Broker gestiti, servizi cloud, topic taxonomy, payload proprietari, regole di autorizzazione, bridge, dashboard, storage e analytics possono creare dipendenze difficili da sostituire.
La portabilità deve quindi essere verificata a livello di protocollo, dati, configurazione e gestione operativa.
Commissioning e verifica
Il commissioning dovrebbe verificare connessione, autenticazione, autorizzazione, topic, wildcard, QoS, retained message, sessioni, Will, gestione degli errori, riconnessione e comportamento del broker.
La verifica funzionale deve poi controllare il significato del payload, la gestione dei timestamp, le unità, il mapping verso i sistemi sorgente e destinazione e il comportamento durante perdita e ripristino della comunicazione.
Lifecycle e handover
- versione MQTT implementata;
- broker e relativa configurazione;
- client identifier;
- topic namespace;
- ACL e autorizzazioni;
- QoS;
- retained message;
- session policy;
- Will Message;
- schema del payload;
- unità e timestamp;
- certificati e credenziali;
- bridge e integrazioni;
- backup e restore;
- dipendenze cloud;
- responsabilità operative.
Questi elementi devono essere mantenuti nel ciclo di vita del sistema.
Checklist professionale
- quale versione MQTT è richiesta;
- quale broker viene utilizzato;
- dove è ospitato il broker;
- come sono strutturati i topic;
- quali wildcard sono consentiti;
- quale formato payload viene usato;
- come sono definiti schema e semantica;
- quali QoS sono richiesti;
- quando usare retained message;
- come gestire sessioni e riconnessione;
- come è configurato il Will Message;
- come sono gestite autenticazione e autorizzazione;
- se è richiesto TLS;
- come sono gestiti certificati e credenziali;
- quali topic sono scrivibili;
- come vengono gestiti timestamp e qualità del dato;
- come funziona il sistema senza broker o Internet;
- quali bridge o gateway sono presenti;
- come avvengono backup e restore;
- chi mantiene ownership e responsabilità operative.
Versioni e baseline
La baseline principale di questa pagina è MQTT Version 5.0 OASIS Standard, approvato il 7 marzo 2019.
MQTT 3.1.1 rimane inoltre standardizzato come ISO/IEC 20922:2016; ISO ha confermato questa edizione nel 2025. MQTT 5.0 non va quindi descritto come coincidente con ISO/IEC 20922:2016.
La pagina è version-sensitive: versioni del protocollo, implementazioni dei broker, profili applicativi e pratiche di sicurezza possono evolvere.
Per il quadro generale vedi anche Integrazione e interoperabilità e Progettazione e requisiti dei sistemi.