MQTT: the messaging protocol behind cloud-bound machine telemetry
MQTT is a publish-subscribe protocol built almost three decades ago for a problem that looks a lot like modern shop-floor telemetry: many small, low-power devices, thin bandwidth, and connections that drop. ThingConnect's own RS485-to-WiFi converter speaks it natively.
How MQTT actually works
MQTT has three roles, not two. A publisher sends a message once, to a named topic — a string like plant1/press3/cycle-count — without knowing or caring who, if anyone, is listening. A broker receives that message and forwards it to every client currently subscribed to that topic. A subscriber declares interest in a topic (or a wildcard pattern of topics) and receives whatever gets published to it. Publisher and subscriber never open a connection to each other — every message passes through the broker, which is the whole point: devices can come and go, publish at their own pace, and never need to know the network topology of who's consuming their data.
Delivery reliability is tunable per message via Quality of Service (QoS) levels: QoS 0 is fire-and-forget (fastest, no guarantee), QoS 1 guarantees delivery but may duplicate a message, and QoS 2 guarantees exactly-once delivery at the cost of more round trips. Choosing QoS is a real bandwidth-vs-certainty trade-off, not a formality — exactly the kind of decision MQTT was designed to put in the protocol itself rather than leave to each application to reinvent.
The real origin: 1999, oil pipelines, satellite links
MQTT wasn't designed for the cloud — the cloud didn't exist yet. It was designed in 1999 by Andy Stanford-Clark at IBM and Arlen Nipper at Arcom (now Cirrus Link) to solve an oil-and-gas telemetry problem: monitoring remote pipeline equipment over satellite links with severe bandwidth caps, high latency, unreliable connections, and sensor hardware too weak to run a heavyweight protocol stack.
Those constraints shaped MQTT's three founding design principles — minimize network bandwidth, minimize the resources demanded of the device, and keep delivering reliably even when the network itself is flaky — and none of that changed as the protocol spread. IBM used it internally for roughly a decade before releasing MQTT 3.1 as a royalty-free specification in 2010; the open-source Mosquitto broker (2008) was the adoption tipping point, and the protocol became an OASIS standard in 2014 and an ISO standard in 2016.
Why the same design fits machine telemetry today
A modern plant floor sending data to the cloud has almost the exact shape of that original oil-pipeline problem: many devices, each publishing small amounts of data, on connections that aren't always reliable, where the device itself shouldn't need much compute or memory to participate. That's why MQTT — rather than a heavier request/response web protocol — is the common choice for IoT and industrial telemetry today: the broker absorbs the many-devices-to-one-destination fan-in, QoS covers for a connection that drops mid-shift, and a publish-only device never needs to expose a listening port or accept an inbound connection.
| Original 1999 constraint | Modern telemetry equivalent |
|---|---|
| Satellite link, thin bandwidth | Cellular/Wi-Fi links on a plant floor, or a metered cloud connection. |
| Weak, low-power field sensors | RS485 sensors, drives, and meters with no network stack of their own. |
| Connections that drop unpredictably | Plant Wi-Fi and internet uplinks that aren't always up. |
| One-way telemetry, not remote control | Read-only monitoring, never a command channel back to equipment. |
Where ThingConnect uses MQTT
Most of ThingConnect's CNC connections don't need MQTT at all — controls speaking FOCAS, MTConnect, or OPC UA already have a native, structured interface to read. MQTT earns its place at the other end of the fleet: devices with no network stack of their own — RS485 sensors, VFDs, energy meters, older PLCs speaking only serial.
ThingConnect's RS485-to-WiFi converter speaks MQTT natively — it bridges an RS485/Modbus RTU device onto Wi-Fi and publishes its readings outward over MQTT, so a device that was never built to talk to a network gets an outbound-only path to one anyway. See the RS485-to-WiFi converter for the device itself.
Questions
Frequently asked questions
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol built for constrained devices and unreliable networks. A device publishes a message once, to a broker; the broker forwards it to every client subscribed to that topic. Publishers and subscribers never connect to each other directly.
It was designed in 1999 by Andy Stanford-Clark at IBM and Arlen Nipper at Arcom (now Cirrus Link) for a genuinely industrial problem: monitoring oil pipelines over satellite links with severe bandwidth limits, high latency, and devices too weak to run anything heavier. IBM used it internally for a decade before releasing MQTT 3.1 royalty-free in 2010; it became an OASIS standard in 2014 and an ISO standard in 2016.
MQTT itself is a thin messaging layer — security comes from how it's deployed: TLS-encrypted broker connections, per-client authentication, and topic-level access control are all standard practice, and that's the configuration ThingConnect's gateway and converters use. The protocol's minimal footprint is also why it fits an outbound-only architecture well — a device only ever pushes to a broker it initiates the connection to.
No — most CNC connections on this site (FOCAS, MTConnect, OPC UA) don't use MQTT at all. MQTT matters specifically for devices with no native network stack of their own, like RS485 sensors and drives, where ThingConnect's own RS485-to-WiFi converter bridges the gap by speaking MQTT outward on the device's behalf.