MQTT, RS485, Modbus: Which Protocol Should You Use for Your Field Sensors?

· 13 min read
13 min read
Eziwan Team
Eziwan Team
IoT Infrastructure

Connecting industrial sensors to the cloud often involves bridging two worlds: OT, with its robust serial buses, PLCs, and existing equipment; and IT, with its IP networks, brokers, real-time databases, and cloud dashboards.

The right approach isn't necessarily to replace the field equipment. In many IIoT projects, the most effective strategy is to keep RS485/Modbus on the field side and use MQTT on the cloud side, with a gateway capable of translating, filtering, and publishing the data properly.

RS485, Modbus, MQTT: Three Concepts You Shouldn't Confuse​

Before choosing a protocol, it is important to distinguish between three levels that are often confused:

TermRoleExample of use
RS485Serial physical layerConnecting multiple devices on a two-wire bus
Modbus RTUApplication protocol over a serial linkRead registers from a meter or sensor
MQTTPublish/subscribe protocol over IPPublish measurements to a cloud broker

Key Takeaways RS485 transmits the signal, Modbus RTU structures field communications, and MQTT publishes data to IT or cloud systems.

RS485 / Modbus: The OT Foundation for Industrial Equipment​

RS485: A Rugged Serial Connection for Field Applications​

RS485 is a differential serial interface that has long been used in industry. It remains widely used because it is robust, cost-effective, and well-suited for environments where equipment is distributed throughout a cabinet, a workshop, or a remote site.

It is frequently used to connect:

  • industrial control systems;
  • energy meters;
  • inverters;
  • variable-frequency drives;
  • temperature, pressure, flow, and humidity sensors;
  • air, water, and energy analyzers.

The theoretical maximum distance for an RS485 bus can reach approximately 1,200 meters under ideal conditions, but it depends heavily on the data rate, cable quality, topology, termination, and the level of electromagnetic noise.

Modbus RTU: Reading and Writing Registers​

On RS485, the most common protocol is Modbus RTU. It defines a standardized method for a master to query slave devices: slave address, read or write function, register address, value, and error checking.

Advantages and Limitations of Modbus RTU​

ItemField Reading
RuggednessSuitable for industrial environments and controlled long-distance applications
InteroperabilityWidely used in sensors, meters, drives, and PLCs
SimplicityClear register reading; easy to diagnose with the right tools
Main limitationNot native IP: a gateway is required to integrate it with the cloud
Point of concernImproper termination, star-topology cabling, or inconsistent serial parameters can severely degrade communication

MQTT: The Ideal Protocol for Cloud Publishing​

MQTT is a publish/subscribe protocol designed to carry lightweight messages over TCP/IP. It is widely used in IoT and IIoT architectures because it separates data producers from consumers.

The principle is simple:

  • An MQTT client publishes messages;
  • Messages are sent to topics;
  • An MQTT broker receives, distributes, and secures the exchanges;
  • Subscribed applications consume the data: monitoring, time series database, alerting, data lake, business tools.

Why MQTT Complements Modbus Well​

Modbus is very effective for querying field devices. MQTT is better suited for publishing data to remote applications.

NeedMost suitable protocol
Read data from an RS485 sensorModbus RTU
Query a PLC over EthernetModbus TCP
Send measurements to the cloudMQTT
Separate field data collection from IT operationsMQTT
Retain existing industrial equipmentRS485 / Modbus

MQTT is therefore not a direct replacement for RS485. Rather, it acts as an application transport layer to IT once field data has been collected, standardized, and contextualized.

The Role of the Eziwan Gateway: Bridging the Gap Between OT and the Cloud​

The Eziwan gateway connects field devices and publishes their data to remote services. In a typical architecture, it serves three roles:

  1. OT Data Collection: Querying Modbus RTU devices over RS-485 or Modbus TCP over a local network.
  2. Standardization: Conversion of registers into usable values with tags, units, timestamps, and quality information.
  3. IT Publication: Sending data to an MQTT broker, a cloud platform, or a monitoring system.

Modbus-to-MQTT Configuration: Key Settings to Understand​

1. Configure Modbus Polling​

The first step is to describe the devices to be queried:

  • Modbus address of each slave;
  • register type: holding register, input register, coil, discrete input;
  • register address;
  • data format: 16-bit integer, 32-bit integer, 32-bit float, boolean;
  • word and byte order, if necessary;
  • physical unit;
  • read interval;
  • tag name published on the MQTT side.

Important Note Two devices may display the same measurement in different formats. Therefore, you should always check the manufacturer’s documentation for the exact address, index base, register type, scale factor, and endianness.

2. Example JSON Configuration​

{
  "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. Publish Structured Data​

Once the value has been read, the gateway can publish a structured MQTT message:

Topic: site/paris/gateway/eziwan-01/sensors/temperature
Payload: {"value":23.4,"unit":"°C","timestamp":"2025-02-20T14:32:01Z","quality":"good"}

A plaintext payload then makes it easier to integrate with:

  • a time-series database;
  • a Grafana dashboard;
  • a Node-RED flow;
  • a cloud-based SCADA system;
  • a business application;
  • a centralized monitoring platform.

Modbus RTU vs. Modbus TCP: What's the Difference?​

Modbus is primarily used in two forms in industrial projects: Modbus RTU and Modbus TCP.

CriterionModbus RTUModbus TCP
SupportRS485 / RS232Ethernet or IP network
Addressing ModeSlave AddressIP Address + Port
FrameCompact, with CRCEncapsulated in TCP
Typical UseSensors, meters, field devicesPLCs, drives, Ethernet devices
DiagnosticsSerial analyzer, Modbus RTU testerPing, network scan, Modbus TCP client
ConsiderationsCabling, termination, baud rate, parityRouting, firewall, VLAN, network latency

In an Eziwan architecture, both approaches can coexist: the RS485 bus for existing field devices, and the local IP network for Ethernet devices.

Architecture Example: Factory with Mixed Equipment​

An industrial site may combine several generations of equipment:

  • an energy meter using Modbus RTU;
  • a PLC connected via a serial bus;
  • a drive accessible via Modbus TCP;
  • a cloud-based monitoring system that retrieves data via MQTT.

This architecture eliminates the need to replace equipment that is already in operation. The gateway serves as the point for collecting, translating, and publishing data.

How to Choose the Right Protocol for Your Situation​

Field SituationRecommended ChoiceWhy
Existing equipment with an RS485 portModbus RTUCompatible with many sensors, meters, and PLCs
Industrial equipment with an Ethernet portModbus TCPEasier to integrate into a local IP network
New connected sensorsNative MQTT if availableDirect publication to a broker or cloud platform
Existing SCADA system to maintainSecure remote access or VPNContinuity with the existing architecture
Data to Grafana, InfluxDB, or Node-REDMQTTClean decoupling between data collection and analysis
Remote or mobile siteGateway with cellular connectivityField data collection without relying on a local wired network

Security: Key Considerations for a Field Gateway​

Connecting the OT to the cloud requires a cautious approach. The goal is not merely to transmit data, but to do so with a level of control appropriate for an industrial setting.

  • Segregate IT and OT networks to prevent overly broad access from the cloud to the field.
  • Limit outbound traffic to necessary services: MQTT broker, monitoring, updates, or administration.
  • Apply the principle of least privilege: a device or user should only have access to the resources it needs.
  • Log connections and events to facilitate auditing and troubleshooting.
  • Provide for the revocation of access in the event of a change in service provider, loss of equipment, or an incident.
  • Encrypt MQTT communications when data leaves the local network.
  • Monitor connectivity status: latency, reconnections, signal loss, and local queues.

Important Note A 4G or LTE connection may be intermittent depending on coverage, the antenna, the radio environment, and network load. Therefore, you should have a strategy in place for reconnection, local buffering, and data timestamping when measurement continuity is critical.

Common Errors in a Modbus-to-MQTT Project​

Confusing registry addresses with document addresses​

Some manufacturers document registers in base 1, while others use base 0. An expected measurement on 40001 may therefore correspond to a different actual address depending on the tool used.

Ignore word order​

32-bit values, including floating-point numbers, can be encoded using different word orders. An incorrect configuration can result in inconsistent values even though the Modbus communication is not in error.

Polling Too Frequently​

A shared RS485 bus should not be polled like an HTTP API. Excessive polling can overload the bus, increase CRC errors, or mask the slowest devices.

Posting MQTT topics that are too vague​

A topic like data/value1 quickly becomes unusable. It's better to structure topics by site, gateway, equipment, and tag.

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

Ignoring Data Quality​

A value without a quality indicator can be misinterpreted. Adding an quality field, a timestamp, and, if necessary, an error code makes it easier to analyze the data on the monitoring side.

LayerRoleExample
FieldMeasurement and automationSensors, meters, PLCs, drives
Edge data collectionModbus reading, filtering, timestampingEziwan gateway
TransportSecure MQTT publishingMQTT broker
ProcessingLogging, alerts, transformationInfluxDB, Node-RED, cloud platform
VisualizationMonitoring and decision-makingGrafana, cloud SCADA, business application

This separation makes the architecture easier to understand: the on-premises environment remains stable, the gateway translates the data, and the cloud processes it.

FAQ — MQTT, RS485, and Modbus​

Can Modbus RTU and MQTT coexist on the same gateway?​

Yes. In fact, this is one of the classic use cases for an IIoT gateway: collecting field data via Modbus RTU over RS-485, then publishing it via MQTT to a broker or a cloud platform. The two protocols serve different purposes: Modbus is used to query devices, while MQTT is used to transmit data to applications.

What is the difference between RS-485 and Modbus RTU?​

RS485 is the physical layer: cabling, electrical signals, and bus topology. Modbus RTU is the application layer: frame structure, slave addressing, read and write functions, and error checking. RS485 can be used with other protocols, but the combination of RS485 and Modbus RTU remains very common in industrial environments.

How many devices can be connected to an RS485 bus?​

The answer depends on the transceivers, the bus load, the cable length, the data rate, and the quality of the installation. The limit often cited for a standard RS485 segment is 32 single-unit loads, but modern low-load devices and repeaters can support larger network topologies. In practice, the topology must be validated against the equipment specifications and site constraints.

Is MQTT suitable if 4G connectivity is intermittent?​

MQTT can be adapted for intermittent connections if the architecture is designed correctly: appropriate quality of service, clean reconnection, local timestamping, gateway-side queuing, and network status monitoring. However, protocol robustness should not be confused with radio availability: the quality of mobile coverage remains a determining factor.

Should You Choose MQTT or OPC UA?​

The two protocols do not address exactly the same need. MQTT is lightweight and highly efficient for publishing messages to a broker. OPC UA offers richer capabilities for modeling equipment, exposing industrial semantics, and integrating certain automation systems. In many projects, MQTT is chosen for cloud publishing, while OPC UA remains relevant for industrial monitoring or machine integration.

How to Secure an Industrial MQTT Publication?​

At a minimum, connections must be encrypted when data leaves the local network, clients must be authenticated, access rights must be restricted by topic, connections must be logged, and access revocation must be provided for. Security must also cover the gateway itself: protected administration, controlled updates, network segmentation, and event monitoring.

Take It Further with Eziwan​

Do you have RS485, Modbus RTU, Modbus TCP, or MQTT devices that you need to integrate into a cloud architecture? The right approach is to map out the existing protocols, identify field constraints, and then define a suitable gateway between OT and IT.

Additional Resources​