INDUSTRIAL
Modbus vs MQTT: why factories run both
These solve different problems at different layers of the same system. Asking which one to use is usually the wrong question.
Modbus talks to the hardware
Modbus is an industrial protocol Modicon developed in 1979 for programmable logic controllers. It's a request-response protocol: a master device polls a sensor or controller for a register value and gets a direct reply. No broker, no subscription model, just a direct conversation between two devices, usually over a wired serial connection or, in newer installs, Modbus TCP over Ethernet.
Modbus has stayed standard for a straightforward reason: the hardware that speaks it is still on factory floors decades after installation, and replacing a working PLC to gain a newer protocol rarely pencils out. It's simple enough that a small microcontroller can implement it, which keeps sensor hardware cheap.
MQTT carries that data upstream
MQTT was created in 1999 by Andy Stanford-Clark at IBM and Arlen Nipper, originally for monitoring oil pipelines. It's a publish-subscribe protocol: devices publish messages to a named topic, and a broker routes those messages to whatever else has subscribed to that topic. Nobody has to know who else is listening.
That model fits a different job than Modbus does. Where Modbus is one master asking one device a question, MQTT is built for one sensor's readings reaching a dashboard, a logging system, and an alerting service at once, without the sensor knowing any of them exist. It also copes better with unreliable connections: a client can drop offline and reconnect without the broker losing its place.
How they usually fit together
A common industrial setup reads Modbus registers from PLCs and sensors on the floor, then a gateway device translates those readings into MQTT messages published upstream to a cloud dashboard or historian database. Modbus stays local and direct; MQTT handles the fan-out once the data needs to reach more than one place.