What Is MQTT? The Lightweight, Reliable IoT Protocol

Every time a plant sensor sends a temperature, voltage, or pressure reading to a dashboard, a protocol carries it. One of the most widely used in IoT is MQTT (Message Queuing Telemetry Transport). It was designed for small devices and unreliable networks, and is now an open standard maintained by OASIS.

This article explains what MQTT is, how it works, the terms worth knowing, and when to choose MQTT over HTTP.

How it works: publish and subscribe

Unlike HTTP's request and response pattern, MQTT uses publish/subscribe through an intermediary called a broker:

• A publisher, such as a sensor, sends a message to a topic on the broker.
• A subscriber, such as a platform or application, subscribes to that topic.
• The broker forwards each message to every subscriber of that topic.

Sender and receiver do not need to know each other. The sensor only needs the broker address and topic name. This makes systems easy to extend: adding a new application that reads the data just means subscribing to the same topic, with no change to the device.

Topics and wildcards

MQTT topics are hierarchical paths separated by slashes, for example plant/line-1/machine-3/temperature. Subscribers can use wildcards: + for one level and # for all levels below. For instance, plant/+/+/temperature receives temperature from every machine on every line. A tidy topic structure from the start makes management much easier as the device count grows.

QoS: how sure delivery is

• QoS 0 (at most once). Sent with no acknowledgement. Lightest, suited to frequent data where an occasional loss is fine.
• QoS 1 (at least once). Delivery is guaranteed, but a message may arrive more than once. The common choice for telemetry.
• QoS 2 (exactly once). The most certain but the heaviest. Used when duplicates must never happen.

Features that help in the field

• Retained messages. The broker keeps the last message on a topic, so new subscribers get the current value immediately.
• Last Will and Testament. A device registers a "will" message the broker sends if the device disconnects without saying goodbye. Useful for flagging devices offline.
• Keep-alive. Device and broker check the connection periodically.
• A tiny header. Per-message overhead is very small, saving bandwidth and battery.

MQTT or HTTP?

Need	MQTT	HTTP
Frequent data, many devices	Excellent fit	Possible, but heavier
Receiving commands on the device	Natural via subscribe	Needs polling
Ease of testing	Needs an MQTT client	curl is enough
Unstable networks	Designed for it	Less efficient

The two are not mutually exclusive. Many platforms accept both, so simple devices can use HTTP while devices that need two-way communication use MQTT.

MQTT security

The standard unencrypted MQTT port is 1883, while MQTT over TLS usually uses port 8883. For industrial data crossing the internet, use encrypted connections and per-device authentication, not one password for everything. That way a problem device can have its access revoked without disturbing the rest. The wider topic is covered in OT and industrial IoT cybersecurity.

Designing the topic structure

The topic structure should follow how you will want to read the data later. A common pattern goes from general to specific: site, area or group, device, then message type. For example surabaya/warehouse-2/sensor-17/telemetry and surabaya/warehouse-2/sensor-17/status. With this pattern, one wildcard can pull all data from one warehouse, or every status from every site.

Avoid putting data values in topic names, spaces, or inconsistent capital letters. The topic is an address; the data belongs in the message body, usually as JSON.

Common mistakes when starting with MQTT

• One credential for every device. Convenient at first, but painful when one device must lose access.
• The same client ID on two devices. The broker keeps disconnecting one of them, and data looks intermittent for no clear reason.
• Sending data far too often without need, loading the network and storage.
• No reconnect handling in firmware, so the device goes silent after a brief network drop.

Frequently asked questions

Is MQTT only for IoT?

No, but IoT is its most common use because it is lightweight and suits unreliable networks.

What is an MQTT broker?

An intermediary server that receives messages from publishers and forwards them to subscribers by topic.

Which QoS should sensors use?

QoS 1 is the usual choice for telemetry: delivery is guaranteed with a load that stays light.

MQTT on the INCLUDE platform

The INCLUDE platform accepts data over both MQTT and HTTP. Each device uses its own credentials: the device ID as username and the device token as password. A command topic is used for actuator control and firmware updates. The full steps are in the documentation page send data from your own device, and an example of connecting business systems is in integrating IoT data with ERP.