IoT Guide

Modbus RTU to Industrial Cloud — RS485/RS232 Gateway

Connect your Modbus RTU devices to the cloud via RS485/RS232, 4G, and MQTT. Register polling, security, latency, and PLC compatibility. The Complete Eziwan Guide.

Quick answer
A Modbus RTU gateway to the cloud checks your equipment RS485/RS232 by polling Modbus registers, converts the values into messages MQTT/JSON and transmits them to the cloud via 4G or Ethernet. It allows for remote monitoring of drives, PLCs, meters, and sensors without modifying the existing installation.

Why Connect Modbus RTU to the Cloud?

Modbus RTU remains the most widely used field protocol in global industry, found in tens of millions of devices: variable-frequency drives, programmable logic controllers, energy meters, power quality analyzers, temperature and pressure sensors, and photovoltaic inverters. However, this serial protocol from the 1970s was not designed for the Internet.

Connecting this equipment to the cloud provides immediate benefits:

  • 24/7 remote monitoring without the need for on-site visits
  • Real-time alerts for threshold exceedances or anomalies
  • Historical data and trends for preventive maintenance
  • Automated reporting for compliance and energy audits
  • ERP/CMMS integration via REST API or webhooks

Architecture of a Modbus RTU Gateway to the Cloud

The gateway physically connects to the RS485 bus as a Modbus master. It cyclically polls the slaves according to a configurable setup (list of registers, addresses, polling frequency), converts the values into JSON/MQTT messages, and transmits them to the cloud.

RS485 Devices Eziwan Cloud Gateway
──────────────── ───────────────── ──────────────
Drive ──┐ ┌─ Modbus RTU master MQTT broker
Compteur ──┤── RS485 ──┤ Polling registres → Dashboard
PLC ──┘ └─ 4G / Ethernet Alerts / API

Key architectural features:

ParameterTypical Value
Physical Interface2-wire RS485 (A/B) or RS232
Baud Rate9,600 / 19,200 / 38,400 bps
ParityNone (8N1) or Even (8E1)
Cloud connectionMQTT TLS over 4G LTE
Polling interval1 s to 15 min (configurable)
Local buffer72 h of data

Configuring Modbus Registers to Be Read

The gateway allows you to precisely configure which registers to read on which slaves. Each measurement point is defined by:

  • Slave address (1 to 247)
  • Register type: Holding (FC03), Input (FC04), Coil (FC01), Discrete Input (FC02)
  • Register address (0 to 65535)
  • Data type: INT16, UINT16, INT32, FLOAT32, BOOLEAN
  • Scale factor and offset for conversion to physical units
  • Label / tag for the dashboard (e.g., "active_power_kW")

This configuration is performed through the Eziwan cloud interface, without physical access to the installation—ideal for remote or hard-to-reach sites.

MQTT Transmission: QoS, TLS, and Retention

Once the logs have been read, the gateway publishes the values to an MQTT broker (Eziwan Cloud, AWS IoT Core, Azure IoT Hub, or self-hosted Mosquitto). Best practices:

  • QoS 1 (at-least-once) to ensure delivery despite network outages
  • TLS 1.3 required to encrypt the connection
  • Client certificate authentication (x509) for gateway identity
  • Hierarchical topic: site/zone/equipement/tag to facilitate filtering
  • JSON payload with ISO 8601 timestamp, value, and unit

Typical Industrial Use Cases

Modbus RTU → cloud connectivity has applications across many industries:

Energy and Utilities

  • Remote meter reading for electric meters (Eastron SDM, SOCOMEC, Carlo Gavazzi)
  • Generator and inverter monitoring
  • Low-voltage distribution panel monitoring

Industrial Production

  • Monitoring of variable-frequency drives (Schneider ATV, Danfoss, ABB)
  • Control of compressors and pumps
  • Monitoring of industrial furnaces and ovens

Water and Sanitation

  • Remote monitoring of pumping stations
  • Measurement of flow, pressure, and level
  • Remote fault detection

OT/IT Security: The Zero-Trust Approach

Connecting OT (Operational Technology) networks to the Internet introduces cybersecurity risks. The Eziwan approach applies zero-trust principles:

  1. Outbound connection only — the gateway initiates the tunnel; no inbound ports are opened
  2. Network segmentation — the OT network (RS485) remains isolated from the IT network
  3. Certificates per device — each gateway has a unique cryptographic identity
  4. Signed OTA updates — it is impossible to install unauthenticated firmware
  5. Logging — all connections and anomalies are logged

Frequently Asked Questions

You might also like