Many factories already have valuable data on the shop floor.
It may come from PLCs, energy meters, sensors, drives, machine controllers, or older equipment that still runs every day. The problem is that this data is not always ready for a cloud platform or MQTT-based monitoring system.
A Modbus register value by itself is not very useful to a dashboard.
40001 = 1 might mean a machine is running.
Or it might mean an alarm is active.
Or it might mean something completely different.That is why Modbus-to-MQTT is not just protocol conversion. In real industrial IoT projects, the harder part is turning raw field-side values into structured data that a cloud system can understand.
A gateway such as Robustel EG5120 can be used as a practical reference for this kind of edge workflow, where selected Modbus RTU or Modbus TCP data is collected, mapped, prepared locally, and forwarded through MQTT toward cloud or monitoring systems.
Why brownfield factory data is rarely cloud-ready
Brownfield factories often include a mix of old and new equipment.
One production area may have Ethernet-connected PLCs, RS-485 meters, stand-alone controllers, digital signals, added sensors, and legacy machines that were never designed with cloud analytics in mind.
The first challenge is connectivity.
Some devices use Modbus RTU over serial communication. Others use Modbus TCP over Ethernet. Some machines may only expose basic run, stop, fault, or count signals. In some cases, an extra meter, sensor, or I/O module may be needed before useful data can be collected.
The second challenge is meaning.
A cloud system does not automatically know what a Modbus register represents. Without a register map or point list, a raw value has very limited operational value.
The third challenge is structure.
Cloud and industrial IoT systems usually need data with clear context:
●equipment ID
●tag name
●unit
●timestamp
●status meaning
●topic structure
●payload format
●reporting logic
This is why edge-side data preparation matters. The gateway is not only pulling values from equipment. It is helping turn machine-side data into something that can support monitoring, maintenance, reporting, or production visibility.
Why Modbus is still common
Modbus is still widely used because it is simple, established, and supported by many industrial devices.
You can still find it in:
●PLC-side devices
●energy meters
●temperature controllers
●drives and VFDs
●utility equipment
●sensors and monitoring devices
●older machine-side systems
Two patterns are especially common.
Modbus RTU usually runs over serial communication, often RS-485. The project needs the correct wiring, baud rate, parity, stop bits, slave address, and register information.
Modbus TCP runs over Ethernet. The project needs IP address, port, unit ID or slave ID, function code, register address, and data type settings.
Modbus can tell the gateway where to read a value.
But it does not explain what the value means.
That part still has to be configured through tag mapping, scaling, units, naming, and reporting rules.
Why MQTT is useful, but not enough by itself
MQTT is commonly used in industrial IoT because it is lightweight and works well for publishing selected data to a broker or cloud-connected application.
Instead of pushing every value everywhere, MQTT allows data to be published to defined topics and consumed by systems that subscribe to those topics.
For example:
factory/line1/machine03/status
factory/line1/meter02/energy
factory/line2/compressor01/alarm
That topic structure already makes the data easier to understand.
But MQTT does not magically make raw PLC or Modbus data cloud-ready.
If the payload is unclear, the tag mapping is wrong, or the receiving system does not understand the value, the data is still not very useful.
A good Modbus-to-MQTT workflow should define:
●which registers to read
●what each register means
●how values should be scaled
●what tags should be created
●how often values should be reported
●which MQTT topics should be used
●what payload format the cloud system expects
This is where the edge gateway becomes more than a connector.
It becomes the place where field-side data starts to become usable industrial IoT data.
A simple Modbus-to-MQTT edge workflow
A practical workflow may look like this:
Modbus device or PLC-side equipment
↓
Modbus RTU or Modbus TCP connection
↓
edge gateway reads selected registers
↓
raw values are mapped into tags
↓
data is scaled, filtered, grouped, or formatted
↓
selected values are published to MQTT
↓
cloud, dashboard, or monitoring system uses the data
Each step matters.
The gateway first needs to communicate with the device. Then it needs the correct register map or point list. After that, the raw values need to be turned into named data points.
For example:
●Register value 1 becomes machine_03/status = running
●Register value 85 becomes oven_01/temperature = 85°C
●Coil value 1 becomes pump_02/alarm = active
●Counter value 12560 becomes line_02/cycle_count = 12560
●Energy value 348.6 becomes meter_01/energy = 348.6 kWh
This mapping step is small, but it is important. It is the difference between sending data and sending useful data.
Common problems in brownfield data collection
Brownfield data projects often look simple in planning documents.
Then the field details appear.
Where Robustel EG5120 fits
In this kind of Modbus-to-MQTT edge workflow, Robustel EG5120 fits into the factory-floor data collection gateway layer.
It can be used where teams need to collect selected data from supported Modbus RTU or Modbus TCP devices, prepare that data locally, and forward structured values toward MQTT brokers, cloud platforms, or industrial IoT applications.
Relevant use cases may include:
●collecting selected PLC-side or machine-side Modbus data
●reading energy meter or utility equipment values
●mapping raw registers into meaningful tags
●publishing selected data through MQTT-based workflows
●supporting local applications for parsing or formatting data
●using cellular connectivity where wired backhaul is limited or backup communication is needed
●managing deployed gateways over time
This does not mean EG5120 automatically makes every legacy machine cloud-ready. The final result still depends on the machine interface, Modbus register map, MQTT broker settings, data model, network design, and security requirements.
The gateway provides the edge platform.
Closing thought
Modbus-to-MQTT workflows are useful because they let factories reuse existing industrial data in modern monitoring and cloud-connected systems.
But the real work is not only reading Modbus registers or publishing MQTT messages. The real work is understanding what each value means, mapping raw data into useful tags, deciding what should be reported, and maintaining a reliable data path over time.
For factories working with PLCs, meters, legacy machines, or other Modbus-enabled equipment, a gateway such as Robustel EG5120 can support the site-side layer for collecting selected Modbus data, preparing it locally, and forwarding useful information toward MQTT brokers, cloud platforms, or industrial IoT applications.
For readers who want a concrete product reference, Robustel EG5120 page gives more detail on its gateway capabilities and deployment options.
If you have worked on Modbus data collection, MQTT forwarding, or brownfield factory monitoring, I’d be curious to hear where things usually get complicated first in your projects: the register map, serial wiring, tag mapping, MQTT topic design, cloud integration, or long-term maintenance?
FAQs
Q1: Does MQTT automatically make Modbus or PLC data cloud-ready?
No. MQTT is useful for publishing data to brokers, cloud platforms, or industrial IoT applications, but it does not make raw Modbus or PLC data meaningful by itself. Cloud-ready data still needs context such as tag names, units, scaling, timestamps, equipment IDs, topic structure, and payload formatting.
Q2: How does a Modbus-to-MQTT gateway turn PLC data into cloud-ready data?
A Modbus-to-MQTT gateway collects selected Modbus RTU or Modbus TCP data, maps raw register values into meaningful tags, and publishes selected values to an MQTT broker or cloud-connected application. The process usually involves register configuration, data type settings, scaling, tag naming, data grouping, topic design, and payload formatting.
Q3: Where does Robustel EG5120 fit in a Modbus-to-MQTT edge workflow?
Robustel EG5120 fits into the factory-floor edge gateway layer. It can support workflows where selected Modbus RTU or Modbus TCP data from PLC-side equipment, meters, sensors, or machines needs to be collected, prepared locally, and forwarded through MQTT toward cloud or industrial IoT systems. The final workflow still depends on the field device, register map, gateway configuration, MQTT broker, cloud platform, and security design.
Top comments (0)