Modbus vs MQTT - Your Industrial Setup Will Need Both

Why Knowing Importance of Modbus and MQTT is Important Before the Comparison

Your PLC has run Modbus since the machine was installed, and it still works. Now someone wants that same data in a cloud dashboard, and the team is split:

• Keep polling over Modbus and bridge it upstream, or

• Rip out the existing communication layer for MQTT

Pick the wrong side of that argument and you either drown your network in polling traffic, or build a publish-subscribe system around hardware that was never designed to push data on its own.

This post compares Modbus and MQTT on the points that actually decide which one belongs in your setup: how each one moves data, what hardware each one needs, and where the two are usually used together instead of as a replacement for one another.

The Real Question Isn't "Which Protocol Is Better"

Modbus and MQTT solve different problems, which is why framing this as a straight replacement gets teams stuck.

• Modbus is a request-response protocol built for one master device polling sensors and PLCs on a local network

• MQTT is a publish-subscribe protocol built for devices to push data upstream over the internet, often to a cloud broker, without anyone polling them directly

The decision that actually matters is where in your architecture each protocol sits:

• Modbus almost always stays at the field level, talking to PLCs, sensors, and drives that have supported it for decades

• MQTT almost always sits above that layer, moving aggregated data from the plant floor to a dashboard, a cloud platform, or another facility

• Most working industrial setups use both - the mistake is trying to make one protocol do the other's job

How Each Protocol Actually Moves Data

Modbus works on a strict master-slave model:

• One master device - usually a PLC or a gateway - sends a request to a specific device address

• That device responds with the requested register value

• Nothing on the network speaks unless asked, which makes the protocol simple to implement and predictable to debug

• Data only moves as fast as the master polls for it. Poll 50 sensors every 500 milliseconds, and you've built a hard ceiling on how current your data can ever be.

MQTT flips that model:

• A device publishes data to a named "topic" the moment something changes

• Any number of subscribers - a dashboard, a database, an alerting service — receive that update without asking for it

• A temperature sensor only sends data when the temperature actually moves, instead of answering a poll every cycle whether anything changed or not

• That event-driven design saves real bandwidth over a cellular or satellite uplink, where every byte costs money

What Each Protocol Costs You in Hardware and Integration Time

Modbus's biggest advantage on a retrofit: it's probably already there.

• Most PLCs, VFDs, and sensors built in the last 30 years speak Modbus RTU over RS-485 or Modbus TCP over Ethernet natively

• The protocol's simplicity made it the default for industrial equipment vendors long before anyone was thinking about cloud connectivity

• If your machine already exposes Modbus registers, you don't need new hardware - you need a master device polling at the right interval

MQTT is the opposite case.

• Almost no legacy industrial hardware speaks MQTT natively, because the protocol assumes a TCP/IP stack and enough processing headroom to manage a persistent broker connection

• Getting MQTT data out of a Modbus-only PLC means adding an edge gateway that polls the PLC over Modbus, then republishes that data as MQTT messages upstream

• That gateway does the protocol translation - adding one more point of failure to the architecture, but also meaning your cloud-side systems never have to know Modbus exists

This translation pattern works because it puts each protocol where it's strongest. The gateway absorbs the awkward parts: it polls the PLC at whatever interval the field network can handle, then only publishes upstream when there's something worth sending.

On one industrial automation project, a CNC machine's existing Modbus interface was left completely untouched. The retrofit added a gateway that polled the machine's registers locally and published state changes to an MQTT broker - so the plant's existing control logic never had to be modified to get the machine onto a cloud dashboard.

Where Latency and Network Reliability Change the Decision

Modbus over RS-485 is deterministic on a local network:

• You know exactly how long a poll-response cycle takes, because there's no broker, no internet hop, and no queuing

• That predictability matters for safety-critical interlocks and motion control, where a variable delay isn't acceptable

• MQTT's reliance on a broker and a TCP/IP connection introduces latency that's usually fine for monitoring and alerting, but not for anything needing a guaranteed response time measured in milliseconds

MQTT's advantage shows up the moment the network gets unreliable — common on cellular-connected remote sites:

• MQTT supports configurable quality-of-service levels, so a message can be guaranteed to arrive at least once even if the connection drops mid-transmission

• The broker queues messages until a disconnected client reconnects

• Modbus has no equivalent retry mechanism — if a poll fails, the master simply tries again on its own schedule, and no queue holds onto data generated during the outage

Where Each Protocol Sits in a Typical Plant Network

Most retrofit confusion comes from not having a clear picture of where each protocol actually runs. A working industrial network usually has three layers, and Modbus and MQTT belong to different ones:

• Field layer - PLCs, drives, and sensors talking Modbus RTU over RS-485 or Modbus TCP over a local Ethernet segment. This layer almost never touches the internet directly.

• Edge layer - a gateway or industrial PC that polls the field layer over Modbus, aggregates the readings, and republishes them as MQTT. This is the translation point, and it's also where local buffering and basic filtering should happen.

• Cloud/enterprise layer - an MQTT broker, a time-series database, and whatever dashboard or analytics platform consumes the data. Nothing here needs to know Modbus exists.

Keeping these three layers separate matters for more than tidiness. A Modbus network exposed directly to the internet, without an edge gateway acting as a buffer, has no authentication and no encryption built into the protocol itself - anyone who can reach the network segment can read or write any register. MQTT was designed with TLS and authentication in mind from the start. That's one more reason it belongs at the boundary between the plant and the outside world, not inside the field network.

This layered structure also makes troubleshooting faster. If a dashboard stops updating, you check the MQTT broker and the edge gateway first - the field-level Modbus network is usually still running exactly as it has for years, untouched by whatever broke upstream.

A Sizing Example: 40 Sensors Across Three Production Lines

Numbers make this decision more concrete than protocol theory alone. Picture a plant with three production lines, each with 12 to 15 Modbus-connected sensors and drives - 40 data points total.

Polling all 40 points every second over a single Modbus RTU line at standard 9600 baud isn't realistic; you'd start missing poll cycles well before reaching 40 devices [verify before publishing]. Splitting the load across three separate RS-485 segments, one per line, with a local master polling each at 1–2 second intervals, keeps every segment within a workable range.

From there, an edge gateway on each line polls its Modbus segment and republishes to MQTT only when a value changes meaningfully - a vibration reading crossing a threshold, a current draw shifting outside its normal band. That single choice usually decides whether the MQTT broker handles a manageable trickle of meaningful events, or drowns in redundant traffic nobody downstream needs.

Filtering at the edge instead of the cloud pays off here. Sending all 40 points' raw poll data upstream every second would work, technically, but it pushes the filtering cost onto your cloud platform and network bill instead of onto a gateway that's sitting idle most of the time anyway.

How to Choose an MQTT Broker for an Industrial Retrofit

Not every MQTT broker is built the same way, and the choice matters more on an industrial retrofit than it does on a typical web project.

• Self-hosted brokers (Eclipse Mosquitto, EMQX) give you full control over where data lives, which matters if a plant has data residency requirements or simply doesn't want production data leaving the building. They also mean your team owns patching, scaling, and uptime.

• Managed cloud brokers (AWS IoT Core, Azure IoT Hub) remove the operational burden of running a broker, and scale automatically as more machines come online. The tradeoff is recurring cost tied to message volume, which is one more reason filtering at the edge gateway matters - every redundant message has a price attached.

• Broker clustering becomes relevant once a single plant or multiple sites need shared visibility. A clustered broker setup avoids a single point of failure taking down monitoring across every connected line at once.

For a single-site retrofit with a moderate number of sensors, a self-hosted broker is usually the simpler starting point, because it avoids per-message cloud costs while the team is still tuning polling intervals and filtering rules. Once the architecture is stable and proven, migrating to a managed broker is a configuration change at the edge gateway, not a redesign of the field network.

• If you're reading from a PLC, sensor, or drive that already speaks Modbus → keep Modbus at that layer. Replacing working field-level communication with MQTT means convincing or replacing hardware that has no reason to change.

• If you need to move that data to a cloud dashboard or a remote site → add MQTT above the Modbus layer through an edge gateway, rather than trying to extend Modbus over the internet.

• If your connection to the outside world is cellular, satellite, or otherwise unreliable → MQTT's queuing and quality-of-service guarantees matter here. Modbus has no mechanism for this.

• If the control loop needs a guaranteed response time → keep it on Modbus or a dedicated field bus. MQTT's broker hop makes it unsuitable for anything safety-critical or motion-related.

• If you're deciding between MQTT and OPC-UA for the same upstream layer → MQTT is lighter and simpler to implement; OPC-UA carries richer semantic metadata about what the data actually represents, which matters more on larger multi-vendor sites.

If you're deciding how to bridge Modbus-based equipment to a cloud platform without breaking what already works, CoreFragment's firmware team can review your PLC setup and recommend a gateway architecture that fits your existing hardware.