MQTT, RS485, Modbus: quale protocollo scegliere per i vostri sensori sul campo?

· 13 minuti di lettura
13 min read
Team Eziwan
Team Eziwan
Infrastruttura IoT

Collegare i sensori industriali al cloud significa spesso far dialogare due mondi: l’OT, con i suoi bus seriali robusti, i suoi controllori logici programmabili e le sue apparecchiature esistenti; l’IT, con le sue reti IP, i suoi broker, i suoi database in tempo reale e i suoi dashboard cloud.

L'approccio corretto non consiste necessariamente nel sostituire l'infrastruttura sul campo. In molti progetti IIoT, la soluzione più efficace è quella di mantenere RS485/Modbus sul campo e utilizzare MQTT sul cloud, con un gateway in grado di tradurre, filtrare e pubblicare i dati in modo corretto.

RS485, Modbus, MQTT: tre concetti da non confondere​

Prima di scegliere un protocollo, è necessario distinguere tre livelli che spesso vengono confusi:

TermineFunzioneEsempio d'uso
RS485Livello fisico serialeCollegare più dispositivi su un bus a due fili
Modbus RTUProtocollo applicativo su collegamento serialeLeggere i registri di un contatore o di un sensore
MQTTProtocollo publish/subscribe su IPPubblicare le misurazioni su un broker cloud

Da ricordare RS485 trasporta il segnale, Modbus RTU struttura gli scambi con il campo, MQTT invia i dati ai sistemi IT o al cloud.

RS485 / Modbus: lo standard OT per le apparecchiature industriali​

RS485: un collegamento seriale robusto per l'ambiente di campo​

Il RS485 è un collegamento seriale differenziale utilizzato da tempo nel settore industriale. Continua ad essere molto diffuso perché è robusto, economico e adatto ad ambienti in cui le apparecchiature sono distribuite all’interno di un armadio, di un’officina o di un sito remoto.

Si usa spesso per collegare:

  • controllori automatici industriali;
  • contatori di energia;
  • inverter;
  • convertitori di frequenza;
  • sensori di temperatura, pressione, portata o umidità;
  • analizzatori di aria, acqua o energia.

La distanza massima teorica di un bus RS485 può raggiungere circa 1.200 metri in condizioni ottimali, ma dipende fortemente dalla velocità di trasmissione, dalla qualità del cavo, dalla topologia, dalla terminazione e dal livello di rumore elettromagnetico.

Modbus RTU: lettura e scrittura dei registri​

Sulla RS485, il protocollo più diffuso è Modbus RTU. Esso definisce un metodo standardizzato per interrogare i dispositivi slave da un master: indirizzo slave, funzione di lettura o scrittura, indirizzo del registro, valore, controllo degli errori.

Vantaggi e limiti di Modbus RTU​

PuntoLettura sul terreno
RobustezzaAdatto ad ambienti industriali e a lunghe distanze controllate
InteroperabilitàMolto diffuso su sensori, contatori, variatori e controllori logici
SemplicitàLettura chiara dei registri, facile da diagnosticare con gli strumenti giusti
Limite principaleNon nativo IP: è necessario un gateway per integrarlo nel cloud
Punto di attenzioneUna terminazione errata, un cablaggio a stella o parametri seriali incoerenti possono compromettere gravemente la comunicazione

MQTT: il protocollo ideale per la pubblicazione nel cloud​

MQTT è un protocollo di tipo "publish/subscribe" progettato per il trasporto di messaggi leggeri su TCP/IP. È ampiamente utilizzato nelle architetture IoT e IIoT, poiché separa i produttori di dati dai consumatori.

Il principio è semplice:

  • un client MQTT pubblica i messaggi;
  • i messaggi vengono inviati su topics;
  • un broker MQTT riceve, distribuisce e garantisce la sicurezza degli scambi;
  • le applicazioni iscritte utilizzano i dati: monitoraggio, database di serie temporali, avvisi, data lake, strumenti aziendali.

Perché MQTT è un'ottima integrazione per Modbus​

Modbus è molto efficace per interrogare le apparecchiature sul campo. MQTT è più adatto per pubblicare dati verso applicazioni remote.

EsigenzaProtocollo più adatto
Leggere i registri di un sensore RS485Modbus RTU
Interrogare un PLC su EthernetModbus TCP
Inviare i dati di misura al cloudMQTT
Separare la raccolta dati sul campo dall’elaborazione ITMQTT
Mantenere le apparecchiature industriali esistentiRS485 / Modbus

MQTT non è quindi un sostituto diretto dell'RS485. Funge piuttosto da livello di trasporto applicativo verso l'IT, una volta che i dati sul campo sono stati raccolti, normalizzati e contestualizzati.

Il ruolo del gateway Eziwan: fare da ponte tra OT e cloud​

Il gateway Eziwan consente di collegare le apparecchiature sul campo e di trasmettere i relativi dati a servizi remoti. In un’architettura tipica, svolge tre funzioni:

  1. Raccolta OT: interrogazione di dispositivi Modbus RTU su RS485 o Modbus TCP su rete locale.
  2. Normalizzazione: conversione dei registri in valori utilizzabili con tag, unità di misura, data e ora e qualità.
  3. Pubblicazione IT: invio dei dati a un broker MQTT, a una piattaforma cloud o a un sistema di supervisione.

Configurazione Modbus su MQTT: i parametri da conoscere​

1. Definizione del polling Modbus​

Il primo passo consiste nel descrivere le apparecchiature da interrogare:

  • indirizzo Modbus di ciascun slave;
  • tipo di registro: registro di memoria, registro di ingresso, bobina, ingresso discreto;
  • indirizzo del registro;
  • formato dei dati: intero a 16 bit, intero a 32 bit, float a 32 bit, booleano;
  • ordine delle parole e degli byte, se necessario;
  • unità fisica;
  • intervallo di lettura;
  • nome del tag pubblicato sul lato MQTT.

Nota di attenzione Due dispositivi possono rappresentare la stessa misura utilizzando formati diversi. È quindi necessario verificare sempre la documentazione del produttore: indirizzo esatto, base di indicizzazione, tipo di registro, fattore di scala ed endianness.

2. Esempio di configurazione JSON​

{
  "modbus": {
    "baud_rate": 9600,
    "parity": "none",
    "stop_bits": 1,
    "slaves": [
      {
        "slave_id": 1,
        "registers": [
          {
            "address": "0x0001",
            "type": "holding",
            "format": "float32",
            "tag": "temperature",
            "unit": "°C"
          },
          {
            "address": "0x0003",
            "type": "holding",
            "format": "float32",
            "tag": "humidity",
            "unit": "%"
          }
        ]
      },
      {
        "slave_id": 2,
        "registers": [
          {
            "address": "0x0010",
            "type": "input",
            "format": "int16",
            "tag": "pressure",
            "unit": "mbar"
          }
        ]
      }
    ]
  },
  "mqtt": {
    "broker": "mqtt.example.com",
    "port": 8883,
    "tls": true,
    "base_topic": "site/{site_id}/gateway/{device_id}/sensors"
  }
}

3. Pubblicare dati strutturati​

Una volta letto il valore, il gateway può pubblicare un messaggio MQTT strutturato:

Argomento: sito/parigi/gateway/eziwan-01/sensori/temperatura
Payload: {"value":23.4,"unit":"°C","timestamp":"2025-02-20T14:32:01Z","quality":"good"}

Un payload in chiaro facilita poi l'integrazione con:

  • un database di serie temporali;
  • un dashboard Grafana;
  • un flusso Node-RED;
  • un sistema SCADA cloud;
  • un'applicazione aziendale;
  • una piattaforma di monitoraggio centralizzata.

Modbus RTU vs Modbus TCP: qual è la differenza?​

Modbus è presente principalmente in due forme nei progetti industriali: Modbus RTU e Modbus TCP.

CriterioModbus RTUModbus TCP
SupportoRS485 / RS232Ethernet o rete IP
Modalità di indirizzamentoIndirizzo slaveIndirizzo IP + porta
FrameCompatto, con CRCIncapsulato in TCP
Utilizzo tipicoSensori, contatori, apparecchiature da campoPLC, azionamenti, apparecchiature Ethernet
DiagnosticaAnalizzatore seriale, tester Modbus RTUPing, scansione di rete, client Modbus TCP
Punti di attenzioneCablaggio, terminazione, velocità, paritàRouting, firewall, VLAN, latenza di rete

In un'architettura Eziwan, i due approcci possono coesistere: il bus RS485 per le apparecchiature di campo esistenti e la rete IP locale per le apparecchiature Ethernet.

Esempio di architettura: stabilimento con attrezzature miste​

Un sito industriale può combinare diverse generazioni di impianti:

  • un contatore di energia con protocollo Modbus RTU;
  • un PLC collegato tramite bus seriale;
  • un variatore accessibile tramite Modbus TCP;
  • un sistema di supervisione cloud che acquisisce i dati tramite MQTT.

Questa architettura evita di sostituire le apparecchiature già in funzione. Il gateway diventa il punto di raccolta, conversione e pubblicazione.

Come scegliere il protocollo giusto in base al proprio contesto​

Situazione sul campoScelta consigliataPerché
Apparecchiature esistenti con porta RS485Modbus RTUCompatibile con numerosi sensori, contatori e controllori
Apparecchiature industriali con porta EthernetModbus TCPPiù semplice da integrare in una rete IP locale
Nuovi sensori connessiMQTT nativo, se disponibilePubblicazione diretta su un broker o una piattaforma cloud
Sistema SCADA esistente da mantenereAccesso remoto sicuro o VPNContinuità con l’architettura già in atto
Dati verso Grafana, InfluxDB o Node-REDMQTTNetta separazione tra raccolta e analisi
Sito isolato o mobileGateway con connettività cellulareRaccolta dati sul campo senza dipendere da una rete cablata locale

Sicurezza: aspetti fondamentali per un gateway di campo​

Il collegamento dell'OT al cloud richiede un approccio prudente. L'obiettivo non è solo quello di trasmettere dati, ma di farlo con un livello di controllo adeguato al contesto industriale.

Buone pratiche raccomandate​

  • Segmentare le reti IT e OT per evitare accessi troppo ampi dal cloud verso il campo.
  • Limitare i flussi in uscita ai servizi necessari: broker MQTT, monitoraggio, aggiornamenti o amministrazione.
  • Applicare il principio del privilegio minimo: un dispositivo o un utente deve accedere solo alle risorse necessarie.
  • Registrare le connessioni e gli eventi per facilitare l’audit e la diagnostica.
  • Prevedere la revoca degli accessi in caso di cambio di fornitore, smarrimento di apparecchiature o incidenti.
  • Crittografare le comunicazioni MQTT quando i dati escono dalla rete locale.
  • Monitorare lo stato della connettività: latenza, riconnessioni, perdite di segnale, code locali.

Da non trascurare Una connessione 4G o LTE può risultare intermittente a seconda della copertura, dell’antenna, dell’ambiente radio e del carico di rete. È quindi necessario prevedere una strategia di riconnessione, di buffer locale e di marcatura temporale dei dati quando la continuità della misurazione è importante.

Errori comuni durante un progetto Modbus-MQTT​

Confondere l'indirizzo di registro con l'indirizzo documentale​

Alcuni produttori documentano i registri in base 1, altri in base 0. Una misura prevista su 40001 può quindi corrispondere a un indirizzo effettivo diverso a seconda dello strumento utilizzato.

Ignorare l'ordine delle parole​

I valori a 32 bit, in particolare quelli in virgola mobile, possono essere codificati con diversi ordini delle parole. Una configurazione errata può generare valori incoerenti senza che la comunicazione Modbus risulti errata.

Andare al poller troppo spesso​

Un bus RS485 condiviso non deve essere interrogato come un'API HTTP. Un polling troppo aggressivo può saturare il bus, aumentare gli errori CRC o oscurare i dispositivi più lenti.

Pubblicare argomenti MQTT troppo generici​

Un argomento come data/value1 diventa presto inutilizzabile. È meglio strutturare gli argomenti indicando il sito, il gateway, l'apparecchiatura e il tag.

site/{site_id}/gateway/{gateway_id}/equipment/{asset_id}/metric/{tag}

Trascurare la qualità dei dati​

Un valore privo di indicatori di qualità può essere interpretato in modo errato. L'aggiunta di un campo quality, di un timestamp ed eventualmente di un codice di errore facilita l'elaborazione da parte del sistema di supervisione.

Architettura standard consigliata​

LivelloRuoloEsempio
CampoMisurazione e automazioneSensori, contatori, PLC, variatori
Raccolta edgeLettura Modbus, filtraggio, marcatura temporaleGateway Eziwan
TrasportoPubblicazione MQTT sicuraBroker MQTT
ElaborazioneArchiviazione storica, avvisi, trasformazioneInfluxDB, Node-RED, piattaforma cloud
VisualizzazioneSupervisione e decisioneGrafana, SCADA cloud, applicazione aziendale

Questa separazione rende l'architettura più chiara: l'infrastruttura rimane stabile, il gateway traduce i dati e il cloud li elabora.

Domande frequenti — MQTT, RS485 e Modbus​

È possibile far coesistere Modbus RTU e MQTT sullo stesso gateway?​

Sì. È addirittura uno degli scenari classici di un gateway IIoT: raccogliere i dati dal campo in Modbus RTU tramite RS485, per poi pubblicarli in MQTT verso un broker o una piattaforma cloud. I due protocolli non hanno lo stesso ruolo: Modbus serve a interrogare le apparecchiature, mentre MQTT serve a trasmettere i dati alle applicazioni.

Qual è la differenza tra RS485 e Modbus RTU?​

RS485 è il livello fisico: cablaggio, segnali elettrici, topologia del bus. Modbus RTU è il protocollo applicativo: struttura dei frame, indirizzamento degli slave, funzioni di lettura o scrittura, controllo degli errori. È possibile utilizzare RS485 con altri protocolli, ma la combinazione RS485 + Modbus RTU rimane molto diffusa in ambito industriale.

Quanti dispositivi è possibile collegare a un bus RS485?​

La risposta dipende dai ricetrasmettitori, dal carico elettrico del bus, dalla lunghezza del cavo, dalla velocità di trasmissione e dalla qualità dell’installazione. Il limite spesso citato per un segmento RS485 classico è di 32 carichi unitari, ma le moderne apparecchiature a basso carico e i ripetitori possono consentire architetture più estese. In pratica, è necessario verificare la topologia in base alle specifiche delle apparecchiature e ai vincoli del sito.

MQTT è adatto se la connettività 4G è intermittente?​

MQTT può essere adattato alle connessioni intermittenti se l’architettura è progettata correttamente: qualità del servizio adeguata, riconnnessione corretta, marcatura temporale locale, coda sul lato gateway e monitoraggio dello stato della rete. Non bisogna tuttavia confondere la robustezza del protocollo con la disponibilità del segnale radio: la qualità della copertura mobile rimane un fattore determinante.

È meglio scegliere MQTT o OPC UA?​

I due protocolli non rispondono esattamente alla stessa esigenza. MQTT è leggero e molto efficiente per la pubblicazione di messaggi verso un broker. OPC UA offre maggiori funzionalità per la modellazione delle apparecchiature, l’esposizione di una semantica industriale e l’integrazione di alcuni sistemi di automazione. In molti progetti, MQTT viene scelto per la pubblicazione nel cloud, mentre OPC UA rimane la scelta più indicata per la supervisione industriale o l’integrazione delle macchine.

Come garantire la sicurezza di una pubblicazione MQTT industriale?​

È necessario, come minimo, crittografare le connessioni quando i dati escono dalla rete locale, autenticare i client, limitare i diritti per argomento, registrare le connessioni e prevedere la revoca degli accessi. La sicurezza deve inoltre estendersi al gateway stesso: amministrazione protetta, aggiornamenti controllati, segmentazione della rete e monitoraggio degli eventi.

Approfondimenti con Eziwan​

Avete dispositivi RS485, Modbus RTU, Modbus TCP o MQTT da integrare in un'architettura cloud? L'approccio corretto consiste nel mappare i protocolli esistenti, identificare i vincoli sul campo e quindi definire un gateway adeguato tra OT e IT.

Risorse aggiuntive​