Simple definition
With MQTT, a device publishes a message to a named topic. Other clients subscribe to topics they need. An intermediary server, the broker, distributes the messages. A sensor therefore does not need to know every recipient or open a separate connection to each monitoring application that uses its readings.
Technical definition
Clients communicate with the broker over persistent connections, usually using TCP. Conventional ports are 1883 and 8883 for TLS-protected connections, and can be changed. Publishing and subscription permissions should be defined by topic, including the consequences of wildcard subscriptions. A successful connection does not automatically authorize every topic.
QoS levels 0, 1 and 2 define delivery guarantees for an MQTT exchange. They do not prove that a business action occurs exactly once across all participating systems. A retained message can give a new subscriber the last stored value for a topic; that value is not necessarily a recent measurement or evidence of current connectivity.
What is it used for?
MQTT is useful for telemetry, home automation and workloads where lightweight clients matter. The application still defines the payload format. MQTT alone does not impose a universal temperature schema, unit or timestamp format, so producers and consumers must agree on how to interpret the information they exchange.
Practical example
A sensor publishes a temperature to building/floor1/temperature. A monitoring service subscribes and displays both the reading and its measurement time. If retained messages are used, the service distinguishes a last known state from a device that is currently online. An apparently normal reading can still be too old to support a decision.
Key points
| Element | Role |
|---|---|
| QoS 0 | At most once delivery for the exchange |
| QoS 1 | At least once delivery; duplicates are possible |
| QoS 2 | Exactly once delivery at the MQTT exchange level |
| Retained | Last message stored for a topic, according to its settings |
Common problems
- No messages: check broker connectivity, the exact topic, subscriptions and permissions.
- TLS disconnects: inspect the server name, certificate chain and the client’s clock.
- Repeated or stale values: review QoS, session recovery, timestamps and retained messages.
Operational checks and limitations
Choose the MQTT version, session handling and QoS level for the actual requirement. Test reconnection and broker failure. Monitor clients, access refusals and data freshness. An open connection is only one part of the service: it does not guarantee sensor availability or successful processing by the final application.