Where is MQTT used? Real-world uses and tools

Auf dieser Seite

Why the same protocol fits so many jobs
Where MQTT is used
A topic and QoS example
Brokers, tools and data stores
References

MQTT is a publish-subscribe protocol for devices that have little memory, little bandwidth, or a flaky connection. Invented in 1999, it is now an OASIS standard, and the 3.1.1 version is also an ISO standard (ISO 20922). Most of what you read about it is a list of industries. This post goes through that list, then shows what a real deployment looks like at the topic level so you can try it yourself.

Why the same protocol fits so many jobs

The MQTT 5.0 specification describes the protocol as lightweight and aimed at machine-to-machine and IoT settings where code footprint is small or bandwidth is at a premium. Three features explain most of its reach.

Publishers and subscribers never talk to each other. They talk to a broker, so a sensor does not need to know who reads it.
Topic names are hierarchical, and subscribers can use the wildcards + (one level) and # (all remaining levels).
Each message carries a delivery guarantee, called quality of service (QoS), chosen by the sender and subscriber.

Where MQTT is used

Area	What typically moves over MQTT	Why MQTT fits
Smart homes	Sensor readings, switch states, commands	Many cheap devices, one local broker
Manufacturing	Machine and PLC data going up to cloud systems, commands coming back down	Low overhead, two-way messaging
Fleets and connected vehicles	Position and diagnostics	Small messages on weak mobile coverage
Utilities	Smart meter and turbine condition data	Large device counts, constrained links
Healthcare	Readings from patient-worn or hospital sensors	Alerts delivered as they happen
Oil and gas	Pipeline telemetry	The original use case

A few notes on the table.

Smart homes are where many makers first meet MQTT. Home Assistant, for example, connects to an MQTT broker and can discover devices automatically. Its documentation recommends the Mosquitto broker and uses a default discovery topic prefix of homeassistant, so a garden sensor's configuration lives at a topic like homeassistant/binary_sensor/garden/config.

In manufacturing, HiveMQ points out that common PLCs, such as Siemens S7 or Opto22 models, usually ship able to push MQTT data out of the box. That is a vendor claim from a broker vendor, but it matches how plants wire machines to cloud systems.

Oil and gas is the origin story. AWS describes the protocol as invented in 1999 for monitoring pipelines over satellite, where bandwidth and battery were scarce.

Fleets and connected vehicles appear as named verticals on HiveMQ's solutions pages, and InfluxData cites BMW's car-sharing service as built on MQTT. Utilities and healthcare examples, such as smart metering, wind turbine monitoring and hospital sensors, come from TechTarget's overview. Treat those as typical patterns, not proof that every provider in the sector uses MQTT. Agriculture, retail, logistics and smart cities are also commonly listed, though the evidence is mostly vendor marketing.

A topic and QoS example

Say a house has a temperature sensor in the living room. A reasonable topic layout puts the location first and the measurement last.

home/livingroom/temperature
home/livingroom/humidity
home/kitchen/temperature

A dashboard that wants every temperature can subscribe with a single-level wildcard.

mosquitto_sub -h localhost -t 'home/+/temperature' -v

The -v flag prints the topic with each payload. Publish from another terminal.

mosquitto_pub -h localhost -t 'home/livingroom/temperature' -m '21.5' -q 1 -r

Here -q 1 asks for QoS 1 and -r sets the retain flag. Retain keeps the last message as a last known good value on the broker, so a dashboard that connects later gets the current reading immediately instead of waiting for the next one. The Mosquitto man page also notes the downside. A retained value can be stale, since nobody knows when it was published, and mosquitto_sub -R skips retained messages.

Pick the QoS level by what a lost or repeated message costs.

QoS	Name	Behavior	Good for
0	At most once	Best effort, may be lost	Frequent readings where the next one replaces the last
1	At least once	Delivered, duplicates possible	Events and commands that must arrive and tolerate a repeat
2	Exactly once	Delivered once	Cases where a duplicate causes harm, such as double billing

Check the platform before relying on QoS 2. AWS IoT Core supports QoS 0 and 1 only, so a design that needs exactly-once delivery has to handle duplicates in the application there.

Brokers, tools and data stores

Eclipse Mosquitto is an open source broker implementing MQTT 5.0, 3.1.1 and 3.1, light enough for single-board computers. It also provides the mosquitto_pub and mosquitto_sub command-line clients used above.
HiveMQ is a commercial MQTT broker and platform aimed at enterprise and industrial IoT.
AWS IoT Core is a managed broker. It supports MQTT 3.1.1 and 5.0 with documented differences from the specifications, and supports retained messages.
Node-RED is a low-code tool for event-driven applications. Its cookbook has recipes for connecting to a broker and publishing messages, including retained ones.
Home Assistant is home automation software with an MQTT integration, covered above.
InfluxDB can store MQTT data through Telegraf's MQTT Consumer plugin, which subscribes to topics, accepts wildcard patterns, and parses data formats such as JSON and line protocol.

To experiment without installing anything, the public broker at test.mosquitto.org accepts plain connections on port 1883. Its operators warn that anyone could be listening and that it should not be relied on, so never publish anything sensitive there.

Why the same protocol fits so many jobs

Where MQTT is used

A topic and QoS example

Brokers, tools and data stores

References