UK How an MQTT gateway works
An MQTT gateway sits between field devices and an MQTT broker. Most industrial equipment does not speak MQTT: an energy meter answers Modbus requests, a weighing scale sends serial strings and a vehicle reports over CAN. The gateway talks to each device in its own protocol, turns the readings into MQTT messages and publishes them to topics on the broker, where any subscribed application can use them.
MQTT itself is a lightweight publish and subscribe messaging protocol maintained by OASIS. Clients do not talk to each other directly. They publish messages to named topics on a broker, such as site1/line2/press4/temperature, and other clients subscribe to the topics they need. That model suits slow or unreliable links and large numbers of devices, which is why it is widely used in IIoT and by cloud IoT services.
A typical MQTT gateway does four things in a loop:
-
//
Collects. Polls Modbus registers, reads serial ports, listens to CAN frames, samples digital and analogue inputs or receives data from wireless sensors.
-
//
Converts. Scales raw register values into real measurements, adds names and timestamps and formats each message, usually as JSON or as Sparkplug B payloads.
-
//
Publishes. Sends messages to topics on the broker, using a quality of service level that suits the data, and subscribes to command topics to write values back to devices.
-
//
Buffers. Stores messages locally when the connection drops and forwards them when it returns, so no readings are lost on a cellular or remote link.
MQTT gateway vs MQTT broker
The two are often confused because both sit in the middle of an MQTT system. A broker receives every published message and delivers it to the subscribers of that topic; it does not read field devices. A gateway is normally an MQTT client that publishes on behalf of devices that cannot. Some gateways also run a small local broker, such as Eclipse Mosquitto, and bridge it to a central or cloud broker, which lets local applications share data even when the uplink is down.
| Component | What it does | Speaks | Typical location |
|---|---|---|---|
| MQTT gateway | Reads field devices and publishes their data | Modbus, serial, CAN or I/O on one side, MQTT on the other | In or near the machine or cabinet |
| MQTT broker | Routes messages from publishers to subscribers | MQTT only | On-site server, data centre or cloud |
| Modbus gateway | Converts Modbus RTU to Modbus TCP | Modbus on both sides | In the panel |
| MQTT-SN gateway | Translates MQTT-SN from small sensor networks into MQTT | MQTT-SN and MQTT | Edge of a wireless sensor network |
If all you need is to put serial Modbus devices on Ethernet, a Modbus gateway is enough. An MQTT gateway is the better fit when the data has to reach dashboards, historians or cloud services that expect MQTT.
A common pattern on larger sites is a gateway per machine or cabinet, each publishing to a broker on an on-site server. Plant applications such as SCADA, historians and maintenance dashboards subscribe locally, and a bridge forwards selected topics to a cloud broker for reporting across sites. On a single remote asset, such as a pumping station or a wind turbine, the gateway usually publishes straight to a central or cloud broker over a cellular link instead.
MQTT features that matter at the edge
MQTT 3.1.1, published by OASIS in 2014 and later as ISO/IEC 20922, is still the most widely supported version. MQTT 5.0, from 2019, adds reason codes, message expiry, shared subscriptions and user properties. Gateways and brokers should agree on the version in use. A few protocol features shape how a gateway behaves on site:
Quality of service. QoS 0 sends a message once with no acknowledgement, QoS 1 guarantees delivery at least once and QoS 2 exactly once. Higher levels cost more traffic, so many gateways use QoS 1 for measurements.
Retained messages and last will. A retained message gives new subscribers the latest value at once, and a last will message tells the system when a gateway has dropped off unexpectedly.
Security. Unencrypted MQTT runs on TCP port 1883. Production systems should use MQTT over TLS, normally on port 8883, with a certificate or credentials for each gateway.
Choosing hardware for an MQTT edge gateway
MQTT is software, so it is not a hardware specification. An MQTT edge gateway is an industrial computer running MQTT client software, such as Node-RED, Eclipse Mosquitto, Telegraf or a vendor’s gateway application, on Linux or Windows. What you choose is the hardware that suits the devices and the site:
Field ports. Count the RS-232 and RS-485 ports, CAN channels and digital or analogue inputs you need, and whether they should be isolated.
Uplink. Ethernet for plant networks, or 4G or 5G and Wi-Fi modules for remote sites.
Storage and security. Enough flash for store and forward, and a TPM where device certificates must be protected.
Our industrial IoT gateways cover both Arm and x86. Some of the Arm gateways we list run Debian and support Python, Node.js and the Node-RED flow editor, which includes MQTT nodes as standard, and some Neousys and Winmate gateways are listed by their manufacturers as certified for Microsoft Azure IoT and AWS IoT Greengrass. Our white paper on OPC UA vs MQTT compares MQTT with the main alternative for plant data.
Quick answers on MQTT gateways
MQTT gateways: common questions
Can an MQTT gateway read Modbus?
Yes. Modbus RTU and Modbus TCP to MQTT is one of the most common gateway jobs in industry.
Is an MQTT gateway the same as a broker?
No. The gateway publishes data from devices; the broker routes messages between clients. Some gateways run a local broker as well.
What port does MQTT use?
TCP 1883, or 8883 for MQTT over TLS. MQTT over WebSockets often uses other ports set by the broker.
Does an MQTT gateway need the internet?
No. The broker can be on the local network, and many plants keep MQTT traffic entirely on site.
Is OPC UA better than MQTT?
They solve different problems. OPC UA models machine data in detail, while MQTT moves messages efficiently, and many systems use both.
We supply each gateway with its operating system, storage and wireless modules installed and configured as part of the standard build.