Why you keep hearing all three
On any real Industrial IoT project these three acronyms come up, and they're often presented as an either/or choice. They're not. They sit at different points in the journey data takes from a machine to your dashboard: reading the device, structuring the data, and transporting it. Understanding which does what makes integration decisions obvious instead of confusing.
The mental model: Modbus and OPC-UA are mainly about reading the equipment (south-bound, at the edge). MQTT is mainly about moving the data onward (north-bound, to the platform/cloud). Most deployments use one of the first two and MQTT together.
Modbus — the universal workhorse
Modbus is decades old, dead simple, and supported by almost everything — PLCs, meters, drives, sensors. It reads and writes numeric registers over serial (RTU) or Ethernet (TCP). Its strengths are exactly that ubiquity and simplicity: if a device is older or basic, it almost certainly speaks Modbus. Its limits are that it carries raw numbers with no description (you need to know register 40001 means "tank level"), and classic Modbus has no built-in security or modern data model (a TLS-secured Modbus/TCP variant exists but is rarely found on legacy equipment). For getting numbers off legacy and simple equipment, though, it's unbeatable — and a big reason you rarely need to replace old kit to connect it.
OPC-UA — the modern industrial standard
OPC-UA (Unified Architecture) is the modern, vendor-neutral standard for industrial interoperability. Unlike Modbus, its data is structured and self-describing — a value comes with its name, units, type and context — and it has security built in (authentication, encryption). It's the right choice for pulling rich, meaningful data out of modern PLCs and for system-to-system integration (e.g. into MES/SCADA). It's heavier than Modbus, so it suits capable modern equipment rather than the smallest sensors.
MQTT — built for moving data
MQTT is a lightweight publish/subscribe messaging protocol. Devices "publish" data to a broker and systems "subscribe" to what they need. It was designed for constrained, unreliable networks — exactly the remote-site, low-bandwidth, intermittent-connectivity reality of South African deployments — and it's very efficient on data and battery. It excels at transporting data from many edge devices to a platform or cloud, and it pairs naturally with edge buffering. It isn't how you read a PLC's registers; it's how you ship what you read.
Side by side
| Modbus | OPC-UA | MQTT | |
|---|---|---|---|
| Main job | Read registers off devices | Structured device/system data | Transport data to a platform |
| Data model | Raw numbers, no context | Self-describing, rich | Any payload (often JSON) |
| Security | None built in | Built in (auth, encryption) | TLS + auth (transport-level) |
| Best for | Legacy & simple equipment | Modern PLCs, system integration | Remote / low-bandwidth / many devices |
| Where it sits | Edge (south-bound) | Edge / system (south-bound) | Edge → platform (north-bound) |
How they work together
A typical deployment looks like this: an edge gateway reads your equipment using Modbus (for older meters and PLCs) and OPC-UA (for modern controllers), normalises and buffers the data locally, then publishes it onward over MQTT to the platform — surviving load shedding and flaky links because the edge holds data until the network returns. So the "vs" framing dissolves: you read with Modbus/OPC-UA and transport with MQTT. The job of a good platform is to speak all of them so it fits whatever you already own.
That's exactly what the in-house addaNet platform does — vendor- and PLC-agnostic, reading Modbus and OPC-UA at the edge and moving data over MQTT with edge buffering for South African connectivity. It's why connecting your plant rarely means replacing it. For the wider picture see our guide to Industrial IoT in South Africa, and on the control-vs-visibility question, SCADA vs IoT platform.