Modbus to MQTT at the Edge: Turning PLC Data into Cloud-Ready Industrial IoT Data

In many factories, valuable production data already exists on the shop floor. It may come from PLCs, meters, sensors, machine controllers, drives, or older equipment that still performs critical work every day. The challenge is that this data is not always easy to collect, interpret, or send to modern industrial IoT platforms.

This is especially true in brownfield factories. Older machines may not have a cloud connector. Some devices may only expose data through serial communication. Others may support Modbus TCP over Ethernet but still provide raw register values that need to be mapped before they become useful. A machine may have operating status, fault signals, production counts, or energy readings available, but those values still need to be turned into structured data that a cloud system, dashboard, or monitoring application can understand.

This is where a factory-floor data collection gateway can play a practical role. In a supported Modbus-to-MQTT edge workflow, the gateway can collect selected Modbus TCP or Modbus RTU data, organize it into meaningful tags or data groups, and publish selected values to an MQTT broker or cloud-connected application.

The goal is not simply to “connect older machines to the cloud.” A better goal is to collect the right data, understand what each value means, prepare it at the edge where needed, and forward it in a format that supports monitoring, reporting, maintenance, or production visibility.

Why Brownfield Factory Data Is Not Usually Cloud-Ready

Brownfield factories often contain a mix of new and older equipment. A single production area may include modern Ethernet-connected PLCs, serial-connected meters, stand-alone machine controllers, legacy equipment, and added sensors used for monitoring. These systems may continue to operate reliably, but they were not always designed with cloud analytics or remote monitoring in mind.

The first challenge is connectivity. Some equipment may communicate over RS-485 or RS-232. Some may use Ethernet. Some may provide only digital status signals. Others may not expose useful data directly unless an additional meter, I/O module, or sensor is added.

The second challenge is data meaning. A cloud system does not automatically know what a Modbus register means. A raw value such as 40001 = 1 may represent a machine status, a relay state, an alarm flag, or something else entirely. Without a register map or point list, that value has limited operational meaning.

The third challenge is data structure. Cloud and industrial IoT systems usually need data that is organized by equipment, tag name, unit, timestamp, status meaning, and sometimes site or production line context. Raw machine-side values often need mapping, scaling, filtering, or formatting before they become useful for dashboards, alerts, reports, or analytics.

For this reason, brownfield equipment data collection is not just about extracting values from older machines. It is about turning available field-side data into structured industrial IoT data that can be consumed by upper-layer systems.

What Data Can Be Captured from Brownfield Equipment?

The data available from brownfield equipment depends on the machine, controller, communication interface, protocol support, register map, and any additional sensors or meters installed. Some older machines may provide rich operational data through a controller or meter. Others may only expose basic running, stopped, fault, or count signals.

A practical machine data acquisition gateway project usually starts by identifying what data is available and what operational problem the data should support.

Brownfield Data Source	Possible Data Captured	Practical Use
PLCs or PLC-side devices	Equipment status, alarm states, counters, process values	Machine status monitoring, production visibility, maintenance review
Energy meters	Voltage, current, power, energy consumption	Energy monitoring, cost analysis, efficiency improvement
Legacy machines	Run/stop state, fault signal, cycle count, basic output signals	Equipment status monitoring and downtime visibility
Sensors	Temperature, pressure, vibration, level, flow	Condition monitoring or process monitoring
Drives or motor-related devices	Speed, operating status, fault codes, load-related values	Equipment health and process visibility
Utility equipment	Pump status, flow, pressure, runtime, alarm states	Remote monitoring and maintenance planning

The key point is that not every brownfield asset provides the same level of data. A machine with a Modbus-enabled controller may expose register-based values. A simpler machine may require digital input monitoring or added sensors. A good project starts from the available signal path, not from the assumption that every machine can provide the same data.

Why Modbus Is Still Common in Factory-Floor Data Collection

Modbus remains common in factory-floor data collection because it is widely used across industrial automation, metering, utility, and equipment monitoring environments. Many PLCs, meters, temperature controllers, VFDs, and other devices expose operational data through Modbus registers.

In brownfield environments, two Modbus patterns are especially common.

Modbus RTU is often used over serial communication, especially RS-485. It is common in meters, controllers, drives, and older field devices. In this type of setup, the gateway must be connected to the serial bus and configured with the correct serial parameters, such as baud rate, data bits, parity, stop bits, and slave address.

Modbus TCP is used over Ethernet networks. In this setup, the gateway communicates with Modbus TCP devices through IP address, port number, slave ID, function code, register address, and data type settings.

Modbus is useful because it gives a structured way to read values from industrial devices. However, Modbus does not automatically provide cloud-ready data. It tells the gateway where and how to read a value, but the project still needs to define what that value means, how often it should be collected, how it should be labeled, and where it should be sent.

That is why Modbus-to-MQTT workflows should not be understood as simple protocol conversion. The real work is often register-to-tag-to-payload preparation.

Why MQTT Is Often Used for Industrial IoT Data Forwarding

MQTT is commonly used in industrial IoT data forwarding because it provides a lightweight publish/subscribe model for sending selected data to a broker or cloud-connected platform. Instead of sending all device data continuously to every system, MQTT allows data to be published to defined topics and consumed by the applications that subscribe to those topics.

For factory-floor monitoring, MQTT can be useful when teams need to send selected values such as machine status, alarms, energy readings, production counts, or process values to cloud dashboards, private IoT platforms, or remote monitoring systems.

However, MQTT does not make industrial data meaningful by itself. A topic such as factory/line1/machine03/status is only useful if the payload is clear, the tag mapping is correct, and the receiving system understands what the value represents. A payload without context can be just as confusing as a raw Modbus register.

This is why edge-side preparation matters. Before data is published through MQTT, the system may need to define tag names, units, scaling, report intervals, topic structure, and data groups. A well-designed MQTT workflow should help the receiving platform understand the data, not just receive more values.

What Happens at the Edge in a Modbus-to-MQTT Workflow?

A Modbus-to-MQTT workflow at the edge usually includes several steps. The exact configuration depends on the gateway, field device, software environment, MQTT broker, and cloud platform, but the general logic often follows a similar pattern.

1. Connect to Modbus-enabled equipment

The gateway first connects to supported field-side equipment. For Modbus RTU, this may involve RS-485 wiring and serial parameter configuration. For Modbus TCP, this may involve Ethernet connectivity, IP address configuration, and network reachability.

At this stage, the basic question is: can the gateway communicate with the device through the available interface?

2. Read selected Modbus registers

Once the device is connected, the gateway or data collection application must be configured to read specific Modbus values. This usually requires the device address, function code, register address, data type, polling cycle, and byte order.

A register map or point list is especially important here. It tells the project team which register represents which value, such as temperature, current, machine status, alarm code, runtime, or production count.

3. Map registers into meaningful tags

Raw register values need to become readable data points. A value may need a tag name, unit, description, scaling rule, decimal setting, or status meaning. For example, a register value may need to be mapped as “Machine_03_Run_Status, Line_02_Energy_kWh, or Compressor_Alarm_Code.”

This step is where field-side data starts to become useful industrial IoT data.

4. Organize data into groups

Not every value needs to be uploaded in the same way. Some values may be reported periodically. Others may be sent only when they change. Some may be grouped by machine, line, system, or monitoring purpose.

Data grouping helps control which tags are uploaded together and how they are packaged for the receiving system. This is important for reducing unnecessary traffic, improving message organization, and making the MQTT payload easier to consume.

5. Publish selected data through MQTT

After the data is collected and organized, selected values can be published to an MQTT broker or cloud platform through configured MQTT settings. This may include server address, port, client ID, authentication settings, topic, and the selected data group.

At this stage, the gateway is not only passing traffic. It is helping transform field-side industrial data into structured messages that can be used by remote monitoring, dashboards, alerts, reporting tools, or other industrial IoT applications.

For readers who need implementation-level guidance, Robustel’s E2C Trinity Modbus Protocol (Southbound) User Guide provides step-by-step configuration details for collecting Modbus TCP or Modbus RTU data and forwarding selected data to northbound systems such as MQTT or OPC UA.

From Register Values to Cloud-Ready Industrial IoT Data

The phrase “cloud-ready” should be used carefully. It does not mean that every machine value should be pushed directly to a cloud platform. It means that selected data has been prepared with enough structure and context for upper-layer systems to use it.

For Modbus-to-MQTT workflows, cloud-ready data often requires several layers of context:

• A clear equipment or asset identifier
• A readable tag name
• The correct unit or scaling
• A timestamp or update time
• A meaningful topic structure
• A payload format that the receiving system can parse
• A reporting logic that matches the monitoring use case
• Security and access settings appropriate for the deployment

A simple example can show the difference.

Raw Modbus-Side Data	Edge-Side Context Added	Cloud-Ready Output Example
Register value = 1	Machine status mapping	machine_03/status = running
Register value = 85	Temperature tag and unit	oven_01/temperature = 85°C
Coil value = 1	Alarm meaning	pump_02/alarm = active
Counter value = 12560	Production count label	line_02/cycle_count = 12560
Energy register = 348.6	Meter tag and unit	meter_01/energy = 348.6 kWh

This mapping step is one of the main reasons an edge workflow is useful. It allows data to be prepared closer to the equipment before it is sent to cloud or enterprise systems.

For readers who want to see a practical application example, Robustel’s guide on reading S6000U data via EG5120 and sending it to Blynk Cloud by MQTT shows how field-side Modbus RTU data can be processed at the edge, formatted into a structured payload, and published to a cloud platform through an MQTT-based workflow.

Common Challenges in Brownfield Machine Data Acquisition

Brownfield data collection projects often look simple on paper, but field conditions can make them more complex. A machine may have a usable communication port, but the register map may be missing. A meter may support Modbus RTU, but the serial wiring or communication parameters may be incorrect. A PLC-side device may provide many values, but only a small portion of those values may be useful for remote monitoring.

Several challenges are common:

• Missing or outdated register maps: Without a reliable point list, teams may not know which register corresponds to which machine value.
• Mixed communication methods: One area may include both Modbus RTU and Modbus TCP devices.
• Serial wiring issues: RS-485 wiring, bus termination, baud rate, parity, and slave address settings must match the field device.
• Data interpretation problems: Raw values may need scaling, unit conversion, byte-order adjustment, or status mapping.
• Polling and reporting mismatch: If data is collected faster than it is uploaded, or if upload rules are not aligned with the monitoring use case, data may appear delayed or less useful.
• Unnecessary data volume: Sending every value continuously can create noise, bandwidth load, and storage burden.
• Security requirements: Moving data from OT environments to cloud or remote platforms requires careful network and access design.
• Long-term maintenance: Gateway configuration, credentials, applications, firmware, and tag mappings may need to be managed over time.

These issues are why brownfield equipment data collection should be treated as an engineering workflow, not just a connectivity task.

Where a Factory-Floor Data Collection Gateway Fits

A factory-floor data collection gateway sits between field-side equipment and upper-layer systems. In a Modbus-to-MQTT workflow, it may connect to supported Modbus RTU or Modbus TCP devices, collect selected values, organize them into tags or data groups, and publish structured messages to MQTT-based systems.

This type of gateway can be useful when factories want to collect data from older machines without replacing existing automation systems. Instead of changing the PLC program or rebuilding the machine control layer, teams may collect selected monitoring data through available interfaces and forward it to the systems that need visibility.

In this architecture, the gateway does not replace the PLC, SCADA, MES, or cloud platform. It provides a practical data path between them.

For example:

• A Modbus RTU energy meter may provide power and energy data for efficiency monitoring.
• A PLC-side device may expose alarm or status registers for remote maintenance review.
• A legacy machine may provide run/stop or fault signals through digital inputs.
• A Modbus TCP controller may provide process values for production monitoring.
• A local edge application may format selected values before they are published to MQTT.

The value of the gateway is that it brings together field-side access, edge-side data handling, upstream connectivity, and manageability in one deployment point.

Where Robustel EG5120 Fits in Modbus-to-MQTT Edge Data Workflows

In Modbus-to-MQTT edge workflows, the Robustel EG5120 can serve as a factory-floor data collection gateway for supported brownfield equipment, Modbus devices, PLC-side systems, meters, sensors, and selected I/O signals.

The EG5120 is relevant to this type of application because it combines field-side industrial interfaces, Modbus TCP/RTU support, MQTT-to-cloud bridging, edge computing resources, secure connectivity, and remote management features in one gateway platform.

Modbus-to-MQTT Workflow Need	Relevant EG5120 Capability	How It Supports the Application
Connecting serial-side brownfield equipment	2 x software-configurable RS-232/RS-485 serial ports	Supports integration with RS-232/RS-485 PLC-side equipment, Modbus RTU devices, meters, or legacy devices where interfaces and protocols match
Connecting Ethernet-based devices	2 x RJ45 Gigabit Ethernet ports, configurable as LAN or WAN	Supports Modbus TCP or factory network integration depending on the deployment design
Capturing simple status or event signals	2 x DI + 2 x DO wet contact interfaces	Can support selected discrete machine status or event monitoring where only basic signals are available
Collecting Modbus-side data	Native Modbus TCP/RTU support	Supports Modbus data acquisition in configured workflows
Forwarding selected data to MQTT/cloud systems	MQTT-to-cloud bridging	Supports configured MQTT-based forwarding of selected data to brokers, cloud platforms, or industrial IoT systems
Preparing data at the edge	Quad-core Cortex-A53 CPU, up to 4 GB RAM, 64 GB eMMC, RobustOS Pro, Docker support, Debian-based environment, and SDK options for C, C++, Python, Java, and Node.js	Supports local applications, parsing, formatting, and application-specific data handling where required
Supporting remote or backup connectivity	5G/4G/3G/2G cellular support, dual SIM, and Ethernet connectivity	Supports upstream communication for factory-floor, distributed, or remote deployments
Securing communication paths	VPN options, firewall functions, access control, and port mapping	Helps build controlled communication paths between field-side systems and upper-layer platforms
Managing deployed gateways	RCMS, Web, CLI, and SMS remote management	Supports configuration, monitoring, updates, and long-term gateway management
Deploying in industrial environments	Metal housing, 9–60 VDC input, DIN rail, wall, or desktop mounting, and -40 to +70°C operating temperature	Supports field-side installation in cabinets, equipment rooms, or industrial environments

These capabilities should be understood in the context of project design. The EG5120 is not a universal connector for every legacy machine, and it does not automatically make every PLC register cloud-ready. A successful workflow still depends on the field device interface, Modbus register map, data configuration, MQTT broker settings, network architecture, and security requirements.

However, when a factory needs to collect selected Modbus TCP or Modbus RTU data and forward structured information toward MQTT-based cloud or monitoring systems, the EG5120 provides a practical edge gateway platform for that workflow.

For readers who want a quick product-level overview of Robustel’s EG Series and how this type of industrial edge gateway supports edge connectivity, local applications, and remote management, this short quick pitch video provides additional context.

Video: Robustel EG5000 Series Quick Pitch

Planning Questions Before Collecting Data from Older Machines

Before starting a brownfield data collection project, it is useful to define the data path carefully. This helps prevent the project from becoming a broad “connect everything” effort without a clear monitoring objective.

A practical planning process may start with these questions:

• Which machines, PLC-side devices, meters, or sensors need to provide data?
• Does the equipment support Modbus RTU, Modbus TCP, digital I/O, or another interface?
• Is there a reliable register map or point list from the device manufacturer?
• Which values are useful for machine status monitoring, production data monitoring, maintenance, energy analysis, or reporting?
• Does each value need scaling, unit conversion, byte-order adjustment, or status mapping?
• How often should each value be collected?
• Should the data be reported periodically, only when it changes, or through a combination of both?
• Which tags should be grouped together before being sent upstream?
• How should MQTT topics and payloads be structured?
• What broker, cloud platform, or industrial IoT system will receive the data?
• What security controls are required between the OT environment and external or upper-layer systems?
• Who will maintain gateway configuration, firmware, credentials, applications, and tag mappings over time?
• How will the workflow scale if more machines, lines, or sites are added later?

These questions help shift the project from “How can we connect older machines?” to “How can we collect useful data from existing equipment and turn it into structured information for the systems that need it?”

Closing Perspective

Modbus-to-MQTT workflows are valuable because they help factories reuse existing industrial data in modern monitoring and industrial IoT systems. This is especially useful in brownfield environments, where replacing machines or redesigning automation systems may not be practical.

The real work is not only collecting data from Modbus devices. It is understanding what each value means, mapping raw registers into meaningful tags, deciding which data should be reported, preparing payloads that cloud systems can use, and maintaining a reliable data path over time.

An edge gateway can support this process by connecting to supported field-side equipment, preparing selected data closer to the source, and forwarding structured information through MQTT-based workflows where configured.

For factories working with PLCs, meters, legacy machines, or other Modbus-enabled equipment, the practical goal is not to send every available value upstream. It is to turn selected machine-side data into usable operational information for monitoring, reporting, maintenance planning, and production visibility.

FAQs

Q1. How can factories collect data from older machines that do not have cloud connectivity?

A1: Factories can collect data from older machines by using the interfaces and signals that are actually available. Some machines may provide data through Modbus RTU, Modbus TCP, serial ports, Ethernet, or connected meters. Others may only expose basic run, stop, fault, or count signals through digital I/O or added sensors. A factory-floor data collection gateway can help collect selected machine-side data and forward it to monitoring or cloud systems, but the exact method depends on the machine interface, protocol support, wiring, and available documentation.

Q2. What data can be captured from brownfield equipment?

A2: Brownfield equipment may provide machine status, alarms, production counts, runtime, cycle information, energy readings, process values, or condition-related data. The available data depends on the machine controller, connected meters or sensors, communication protocol, and register map. In some cases, a Modbus-enabled device can expose detailed values. In other cases, only basic status or event signals may be available. The practical goal is to collect data that supports monitoring, maintenance, reporting, or production visibility.

Q3. Do factories need to modify PLC programs to collect machine data?

A3: Not always. Some projects can collect selected data from PLC-side devices, meters, sensors, or existing Modbus registers without changing the core PLC control logic. However, this depends on how the machine is designed and what data is already exposed. If the required data is not available through an existing interface, register map, or signal path, additional configuration, sensors, I/O wiring, or PLC-side changes may be required. For brownfield projects, it is important to confirm data availability before assuming non-intrusive collection is possible.

Q4. How does a Modbus-to-MQTT gateway turn PLC data into cloud-ready data?

A4: A Modbus-to-MQTT gateway collects selected Modbus RTU or Modbus TCP data from supported devices, maps raw register values into meaningful tags, and publishes selected values to an MQTT broker or cloud-connected application. The process usually involves device addressing, register configuration, data type settings, tag naming, data grouping, topic design, and payload formatting. The gateway does not simply “translate” data automatically. The data must be configured and structured so that upper-layer systems can understand and use it.

Q5. Does MQTT automatically make Modbus or PLC data cloud-ready?

A5: No. MQTT is a useful transport mechanism for publishing data to brokers, cloud platforms, or industrial IoT applications, but it does not automatically make raw PLC or Modbus data meaningful. Cloud-ready data still needs context, such as tag names, units, scaling, timestamps, equipment IDs, and topic structure. A raw register value may be technically transmitted through MQTT, but it only becomes useful when the receiving system can understand what the value represents and how it should be used.

About the Author

Robert Liao | Technical Support Engineer

Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.