MQTT è un protocollo di messaggistica: i publisher inviano messaggi e i subscriber ricevono quelli dei topic pertinenti. Può collegare un acquisitore industriale alle applicazioni. Non definisce come misurare un sensore, quale unità usare o quando generare un allarme: sono responsabilità del contratto dati applicativo.
Broker e progettazione dei topic
Il broker instrada i messaggi ai subscriber. I publisher non devono conoscere ogni destinatario, ma accesso, capacità, permessi e stato del broker diventano responsabilità operative. Consentire a ogni dispositivo di pubblicare su qualsiasi topic non è una buona impostazione iniziale.
I nomi devono riflettere una gerarchia chiara. site-a/line-2/machine-7/state è un esempio, non un indirizzo reale. Separa l’identità stabile dal nome visualizzato: rinominare una macchina non deve frammentarne lo storico. Evita segreti e informazioni personali nei topic.
Il payload può contenere valore, unità, timestamp sorgente, qualità e versione dello schema. Documenta dimensioni massime e campi facoltativi. Consumatori diversi devono interpretarlo coerentemente, senza indovinare il significato dei registri.
Cosa copre davvero QoS
Lo standard OASIS MQTT 5.0 definisce tre livelli QoS. Le proprietà di consegna riguardano il relativo tratto di comunicazione del protocollo. Non garantiscono automaticamente una sola scrittura nel database o un’azione fisica eseguita una sola volta.
| Livello | Consegna nel protocollo | Domanda applicativa |
|---|---|---|
| QoS 0 | Al massimo una volta | Questa osservazione può andare persa? |
| QoS 1 | Almeno una volta | Come si riconoscono le ripetizioni? |
| QoS 2 | Esattamente una volta sul tratto del protocollo | Cosa succede nei servizi successivi? |
Un subscriber può elaborare il messaggio e perdere la conferma del database. Riprovare può ripetere l’operazione. Identità stabile, vincoli di unicità e confini delle transazioni contano oltre alla configurazione MQTT. QoS 2 non è una garanzia aziendale illimitata di esecuzione unica da un estremo all’altro.
Retained non significa aggiornato
Un messaggio retained può fornire al nuovo subscriber l’ultimo messaggio conservato del topic. Potrebbe essere vecchio. L’interfaccia deve verificarne tempo sorgente e politica di aggiornamento. Riceverlo subito dopo la connessione non dimostra che il dispositivo stia funzionando ora.
Last Will può segnalare la perdita di connessione, ma non diagnosticare ogni guasto di campo. Un acquisitore connesso può aver perso un sensore. Mantieni distinti disponibilità del dispositivo, stato dell’acquisitore e connettività applicativa.
Flusso illustrativo di temperatura
Supponiamo che l’acquisitore memorizzi misure datate mentre manca il collegamento a monte. Alla riconnessione le invia con identità originali. L’applicazione elimina duplicati, colloca le misure tardive nello storico e non sostituisce il valore attuale con un punto più vecchio reinviato.
La coda ha capacità finita. Definisci durata coperta, allarmi di spazio e comportamento ai guasti. Prova molte riconnessioni simultanee e limita il recupero per mantenere utilizzabili misure attuali e polling. Attese crescenti ma limitate fra tentativi evitano di aggravare una rete in recupero.
Domande iniziali
- Dove funzionerà il broker e chi lo gestirà?
- Come si gestiscono identità e permessi dei topic?
- Quali campi rendono valido un messaggio?
- Come si provano buffer, reinvio e duplicati?
- Cosa succede al rinnovo di credenziali o certificati?
MQTT non sostituisce modello dati e piano operativo. Valida un piccolo flusso in esercizio normale, disconnessione e consegna duplicata prima di estenderlo.
Un esempio di duplicato applicativo
Immagina l’osservazione observation-1042. L’applicazione la salva, ma la conferma di elaborazione non raggiunge l’acquisitore. Il nuovo tentativo usa lo stesso identificatore e timestamp originario. Il ricevitore riconosce il record già presente anziché aggiungere un campione. Creare una nuova identità cancellerebbe la prova che entrambe le consegne si riferiscono a una sola osservazione.
Un altro consumatore può valutare un allarme da quel record. Serve considerarne lo stato: impedire misure duplicate non impedisce automaticamente notifiche duplicate. Conserva il rapporto tra evento, transizione di allarme e lavoro di notifica. Se il fornitore va in timeout, mantieni un esito incerto invece di dichiarare che nulla è stato inviato. È un esempio di architettura applicativa, non una promessa aggiuntiva del protocollo.
Definisci anche i rifiuti. Schema sconosciuto, unità invalida o identità impossibile devono essere diagnosticabili. Riprovare ciecamente un messaggio permanentemente malformato consuma risorse senza dati utili. Prevedi un processo delimitato e una vista operativa della sorgente interessata. Non copiare credenziali o payload senza restrizioni nei log per comodità di debug.
Collauda permessi e recupero
Prova ogni identità sui topic ammessi in pubblicazione e sottoscrizione. Tenta accessi esterni al perimetro e verifica il rifiuto. Prova credenziali sostituite e dispositivi dismessi separatamente dalla normale riconnessione. Queste prove verificano i limiti previsti; una connessione riuscita dice poco sulle restrizioni.
Interrompi il collegamento a monte mentre la raccolta continua, poi riconnetti con dati storici e attuali. Verifica timestamp originari, identità e anzianità mostrata. Controlla cosa accade al limite dello spazio locale. Il buffer pieno deve restare visibile anche se il broker torna disponibile. Documenta versione MQTT, sessioni supportate e conferme applicative insieme alla configurazione reale di client e broker. Porta questi dati operativi, un payload e la gerarchia dei topic alla revisione: rendono valutabili i confini dell’affidabilità senza attribuire a una scelta QoS la soluzione di ogni problema di consegna.