What is MQTT? A practical introduction to IoT messaging

A simple example

Imagine a temperature sensor connected to a gateway in a refrigerated store. The gateway sends a message containing the device identity, measurement time and temperature to a topic such as warehouse/store1/temperature. A monitoring application subscribes to that topic and receives updates. A second authorised application could subscribe too, without the gateway knowing how either application displays or stores the reading.

The broker handles routing, not the physical measurement. The sensor still needs appropriate placement and calibration, and the application still needs to interpret units and timestamps. The IoT sensors guide explains those measurement concerns. MQTT helps move information between systems; it does not decide whether a temperature reading is accurate or what an operator should do about it.

Publishers, subscribers and the broker

A publisher is a client that sends messages. A subscriber is a client that requests messages matching a topic filter. One client can perform both roles if authorised. The broker accepts connections and routes publications to subscribers. It may also manage retained messages, sessions and offline queues depending on configuration, but these capabilities have specific limits and operating requirements.

Our MQTT broker guide explains that central role in more detail. The useful separation is between who produces a message and who consumes it. This supports several applications using one observation stream, yet it also makes permissions important. A client should not gain access to every device simply because it has been allowed to connect.

What topics and payloads mean

A topic is the name used to route a message. Applications often organise topics using levels separated by slashes, but the naming convention is their own design. Topic names are case sensitive. Stable asset identifiers usually work better than labels that operators frequently rename. Subscribers can use supported wildcard filters to receive groups of related messages.

The payload is the message content. It might be JSON with measurements, a compact binary structure or another agreed format. MQTT does not require a standard sensor schema. Producers and consumers must therefore agree on field names, units, timestamps and version changes. A correctly routed message is not necessarily a valid reading until the receiving application checks that contract.

Why MQTT is useful for IoT

MQTT can support ongoing information exchange with relatively modest protocol overhead. A gateway can publish observations as they become available, and applications do not need to repeatedly request each value. Multiple consumers can receive the same publication through their own subscriptions. These properties suit many monitoring and integration tasks across buildings, utilities, farms and industrial sites.

However, suitability depends on the network and workload. A basic MQTT connection is not a low power radio network, and it does not provide coverage to a remote field by itself. What is LoRaWAN? explains a different part of the connectivity picture. A LoRaWAN network server might forward application events using MQTT, combining two technologies with distinct responsibilities.

How MQTT compares with HTTP

HTTP is often used for request and response interactions, including fetching a latest reading or posting an event to a webhook. MQTT uses a broker mediated messaging model with subscriptions. HTTP can be straightforward for occasional API access, while MQTT can be convenient for continuing telemetry and distributing events to several applications.

Do not select one solely because it is fashionable or described as lightweight. Consider existing infrastructure, security requirements, debugging tools and how information will be stored. Both approaches need an application contract and sensible retry behaviour. A system can also combine them, using MQTT for acquisition and an HTTP API to provide selected stored observations to external clients.

Delivery levels need careful interpretation

MQTT defines quality of service levels. QoS 0 has no acknowledgement exchange for delivery. QoS 1 supports at least once delivery, allowing duplicates. QoS 2 uses an additional exchange for exactly once delivery within the relevant protocol interaction. The MQTT protocol guide explains these behaviours alongside sessions and retained messages.

None of these labels proves that an application saved a business record exactly once. Storage and processing happen outside the transport guarantee. If a client retries or reconnects, duplicate observations may need to be recognised using stable event identities. Verify the whole path to persistence rather than treating a connection indicator or broker acknowledgement as proof of a complete historical record.

Retained state, outages and freshness

A retained message lets a broker provide a stored value to later subscribers. This helps an application learn the latest known state without waiting for another publication. It does not create an archive, and the retained value may be old. Always inspect its source timestamp before presenting it as current equipment information.

Session configuration can preserve some state across a disconnect, but queue limits, expiry and persistence policies matter. Test the actual client and broker settings during a realistic outage. For industrial IoT, distinguish a healthy messaging connection from fresh machine observations. A gateway can remain online while its local controller or instrument is unavailable.

Security and getting started

Use encrypted transport with certificate validation where required, individual identities where practical and restricted publish and subscribe permissions. Keep credentials out of source code and shared examples. Plan how access is revoked, how updates are applied and who investigates a failing connection. A password alone does not compensate for overly broad topic permissions.

Start with one meaningful observation and one consuming application. Confirm measurement identity, timestamps and units, then test disconnection, duplicates and forbidden access. Explore IoT devices and the ALLINLET connector catalogue to scope the broader acquisition path. MQTT is most useful when its messaging simplicity supports a clear operational purpose and a maintainable, secure data system.