TLDR
Modbus TCP is the old request/response protocol that talks to PLCs, drives, and meters. MQTT is the newer publish/subscribe transport that fans data out to brokers and cloud services. Most edge AI pipelines run both. Modbus pulls from field devices, MQTT pushes results north, and an edge PC sits in the middle running the bridge plus the inference. This guide covers what each protocol does, where each one falls over, and which Neteon edge computers handle the work in production.
Overview
A modern edge AI deployment rarely uses one protocol end to end. The cameras and PLCs at the bottom of the stack speak Modbus, EtherNet/IP, or vendor serial. The inference layer above them needs sub-second access to those tags. The cloud or SCADA layer above that wants a normalized event stream. MQTT vs Modbus TCP is not a choice between the two; it is a choice about where each one sits in the pipeline.
If you have not read our companion guide on OPC-UA, that protocol is a third option for the southbound link and complements both. For an end-to-end stack example, our remote monitoring stack walkthrough shows how MQTT lands on a broker and gets consumed downstream. Network-level layout is in the IT/OT convergence guide.
What each protocol actually is
Modbus TCP is the Ethernet version of the 1979 Modbus serial standard. A client (your edge PC) opens a TCP/502 connection to a server (a PLC, VFD, or smart meter) and asks for a register or coil value. The server answers. It is simple, deterministic, and supported by almost every industrial device shipping today.
MQTT is a lightweight publish/subscribe transport designed for unreliable networks. A publisher pushes a payload to a topic on a broker. Any number of subscribers receive it. Quality of service levels (0, 1, 2) tune the reliability/overhead tradeoff. MQTT 5 added shared subscriptions, message expiry, and richer error reporting.
The two protocols solve different problems. Modbus TCP is good at polling a known set of registers on a known device. MQTT is good at sending many small events to many consumers without coordinating them.
How each one works
| Stage | Modbus TCP | MQTT |
|---|---|---|
| Connection | TCP/502, client to server | TCP/1883 (8883 TLS), client to broker |
| Pattern | Request / response | Publish / subscribe |
| Discovery | None, client must know register map | Topic tree, wildcards (`+`, `#`) |
| QoS | Best-effort at TCP layer | Three levels (0/1/2) at app layer |
| Payload | 16-bit registers, raw binary | Arbitrary, often JSON or SparkplugB |
| Security | None in spec, relies on segmentation | TLS, username/password, client certs |
| Typical use | Polling a PLC at 100-500 ms | Pushing events to broker at 1-100 Hz |
The split is clean. Modbus on the south side, MQTT on the north. The edge PC is what bridges them.
Why edge AI pipelines end up running both
Putting inference at the edge changes the polling math.
The south-side rate goes up. A vibration model wants 1 kHz samples, not the 500 ms tick that a HMI is happy with. Modbus TCP can hit that rate against a single device, but it isn't a fan-out protocol. So the edge computer becomes the buffer.
The north-side schema gets richer. Inference output isn't a register value. It's a result plus a timestamp plus a confidence score, and sometimes a clipped tensor for review. JSON or SparkplugB over MQTT carries all of that cleanly. Modbus does not.
The network gets less reliable on purpose, too. Remote sites, cellular backhaul, an intermittent satellite link in the middle of nowhere. MQTT was designed with that in mind. Modbus TCP assumes a healthy LAN and complains loudly when it doesn't get one.
The result is a two-protocol pipeline. Modbus TCP southbound to PLCs and meters, MQTT northbound to brokers and cloud. The edge computer runs both stacks, plus the inference engine in between.
Which Neteon products run this pipeline
POC-700 is the compact data-acquisition node. Two GbE ports let you isolate the OT segment from the IT segment, run a Modbus client on one NIC, publish MQTT out the other. Fanless, MIL-STD-810H, -25 to 70 C operating range.
Nuvo-10000 steps up to expandable PCIe and 14th-gen Intel cores. The headroom matters when you are running an MQTT broker locally, plus the Modbus poller, plus an inference container, all on the same box. Four GbE ports give you room for redundant OT links.
For sites that need cellular backhaul or a dedicated RTU gateway in front of the edge PC, the PLANET IOG700-0T501 handles Modbus-to-MQTT bridging on the wire side so the IPC can focus on inference.
Picking between the two
The choice is really about layering. Modbus TCP belongs where you need register-level reads from existing industrial gear. MQTT belongs where results need to fan out to multiple consumers over networks you don't fully control. If a pipeline only has one of the two, there's almost certainly a gap somewhere, often patched over with custom serial scripts that nobody wants to maintain.
Conclusion
MQTT vs Modbus TCP is the wrong framing. The real question is where each protocol sits and what hardware can run both stacks alongside the inference workload. Follow Neteon on LinkedIn for more protocol deep dives, or reach us at [email protected] or www.neteon.net to talk through a Modbus-to-MQTT edge pilot.
Related Products
FAQs
Is MQTT replacing Modbus TCP in edge AI deployments?
No. Modbus TCP still owns the southbound link to PLCs, drives, and meters because almost every industrial device speaks it natively. MQTT sits on the northbound side, carrying inference results and events to brokers, dashboards, and cloud services. A well-designed edge pipeline runs both, with the edge computer doing the conversion in the middle.
Can I run a local MQTT broker on the edge computer itself?
Yes, and it's a common pattern on the Nuvo-10000 series. Running Mosquitto or EMQX locally lets you decouple inference latency from cloud availability. The edge PC publishes to localhost, downstream consumers (HMIs, historians, gateways) subscribe over the LAN, and a separate bridge connection pushes a filtered subset to the cloud broker.
What's the typical polling rate for Modbus TCP in a vibration-monitoring pipeline?
Polling 16-bit holding registers at 100-500 ms is comfortable for most PLCs. For higher rate vibration capture (1 kHz and above), you usually move off Modbus to a direct sensor protocol or PCIe DAQ card, then publish the windowed feature data over MQTT. The Nuvo-10000 PCIe slots are useful here.
Does MQTT 5 add anything material for industrial use?
Yes. Shared subscriptions allow load-balanced consumers, message expiry prevents stale commands from being acted on after a connection blip, and richer error reporting makes debugging cellular drops far easier. If you're standing up a new MQTT stack today, target MQTT 5 brokers and clients.
Where does OPC-UA fit alongside MQTT and Modbus TCP?
OPC-UA is a third option on the southbound side, with a strong type model and built-in security. It often coexists with Modbus rather than replacing it: legacy gear stays on Modbus, newer assets expose OPC-UA, and the edge PC normalizes both into MQTT topics northbound. Our OPC-UA explainer post covers the data model details.
