--- title: MQTT slug: concepts/mqtt docTags: createdAt: 2025-09-10T14:27:28.274Z --- ## What is MQTT and How is it Used? **MQTT** (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe network protocol that transports messages between devices. It’s designed for minimal bandwidth usage and high reliability, making it ideal for **IIoT (Industrial Internet of Things)** applications. MQTT works especially well in scenarios where many devices need to communicate efficiently and consistently. Its simplicity, combined with robust message delivery options (QoS levels), makes it a go-to protocol for real-time, scalable IIoT solutions. ## Publisher Client, Subscriber Client, and Broker - **Broker** The broker is the core of the MQTT system. It acts as the central server that receives messages from publishers and routes them to appropriate subscribers. It ensures messages are delivered reliably and according to the specified Quality of Service (QoS) level. A broker hosts topics (see topic section below) where messages can be exchanged. Examples of commonly used MQTT brokers include: - **Mosquitto** – Lightweight and widely used for small to medium deployments - **EMQX** – High-performance broker for large-scale enterprise use - **HiveMQ** – Commercial-grade broker with advanced scalability and monitoring tools :::hint{type="info"} An MQTT broker is required to exchange messages over MQTT. This infrastructure is not provided nor managed out of the box by Factry. ::: - **Publisher Client** The publisher sends messages to a specific topic on the MQTT broker. It doesn’t need to know who receives the message; its job is simply to send data. For example, a temperature sensor may publish updates to the topic factory/line1/temperature. - **Subscriber Client** Receives messages from a topic it has subscribed to on the MQTT broker. It only receives messages relevant to that topic. For example, an MQTT collector can read messages from the topic factory/line1/temperature. ### Topic A **topic** is a string used by the broker to filter and route messages. It serves as a logical communication channel between publisher and subscriber clients. Topics are hierarchical, separated by forward slashes `/`, allowing granular control over message routing and subscription. **Examples**: - `factory/line1/temperature` – A message published here can represent the temperature reading from a sensor in a production line of a factory. - `factory/line1/power` – A message published here can represent the power reading from a sensor in a production line of a factory. Subscribers can use wildcards to listen to multiple topics at once: - `+ (single level wildcard)`: `factory/+/temperature` matches all items underneath `factory` where a subitem `temperature` exists, e.g. it matches all lines in the example - `# (multi-level wildcard)`: `factory/#` matches all items and subitems underneath `factory` on multiple levels, e.g. it matches all lines and sensors like temperature and power in the example Topics enable highly organized and flexible communication in MQTT systems. ### Quality of Service (QoS) MQTT offers three levels of **QoS (Quality of Service)** to control the guarantee of message delivery. QoS is agreed per connection leg, not end to end: once between the sensor (publisher) and the broker, and again between the broker and the MQTT collector (subscriber). The level a subscriber actually gets is the lower of the level the publisher published with and the level the subscriber asked for in its own subscription, so the MQTT collector's subscription QoS must also be 1 or 2 for a publisher's guarantee to survive the second leg: - **QoS 0 – At Most Once**: The message is sent once from the publisher to the broker, with no acknowledgment that it was received by the broker nor the subscriber. Hence there is no retry mechanism. This is the fastest and most efficient level, but delivery from the publisher to the subscriber is not guaranteed. **Example:** The temperature sensor (publisher client) only sends a message once to the broker, to be received by the MQTT collector (subscriber client). If there is a connection interruption between either the sensor and the MQTT broker or the MQTT broker and the MQTT collector, messages may be lost. - **QoS 1 – At Least Once** The message is guaranteed to arrive, but it may be delivered more than once if acknowledgments are lost. The subscriber must handle potential duplicates. Suitable for applications where occasional duplicates are acceptable. **Example**: The temperature sensor (publisher) sends a message to the broker and resends it until the broker acknowledges it. The broker then independently delivers the message to the MQTT collector (subscriber), and resends it until the collector acknowledges it. MQTT has no end-to-end acknowledgment, so the acknowledgment the sensor receives only proves the broker took the message, not that the collector got it. :::hint{type="info"} Often overlooked is that for QoS 1 to work properly, the publisher needs to have a memory/storage buffer implementation to keep track of the messages for which no acknowledgment was received yet. ::: :::hint{type="info"} If the message contains a timestamp, which is then used by the MQTT collector to assign timestamps to data points, duplicate messages will overwrite the same data point, causing no issues. If there is no timestamp in the message, the MQTT collector uses the time of receipt, which can result in inaccurate data points especially when acknowledgments fail and messages are buffered. ::: - **QoS 2 – Exactly Once**: Similar to QoS 1, but each leg uses a handshake (multiple messages back and forth) that guarantees the message arrives exactly once, with no duplicates. This is the most reliable but also the most resource-intensive QoS level. :::hint{type="warning"} It is advised to use QoS 1 or higher if no data points may be lost. Ensure the publisher has a buffer implementation to keep track of which messages were acknowledged to be received and which were not. ::: ### Persistent Sessions In MQTT, a **Persistent Session** (also called a non-clean session) allows a subscriber to retain its session state across disconnects. This means the MQTT broker keeps track of the client’s subscriptions and stores any unreceived QoS 1 or QoS 2 messages while the client is offline. QoS 0 messages are never queued, even with a persistent session. **Key Features**: - The broker stores the subscriber state (last message processed by the subscriber) and any messages that were published while the client was offline. - When the subscriber reconnects, the broker resumes the session by handing over the next message where the subscriber left off. :::hint{type="info"} A persistent session only works if all messages from the sensor (publisher) reach the broker and the broker is configured to persist messages for the corresponding QoS level (some brokers support persistent sessions on QoS 0, where officially it is supported for only QoS 1 and QoS 2). Persistent sessions can increase the load on the broker due to the size of the retained message queues. ::: ## MQTT Specifications MQTT itself does not define a strict message specification; it supports any payload format. Factry provides collectors for two commonly used payload formats: - **Generic JSON**: A flexible format designed for parsing structured JSON messages - **Sparkplug B**: A well-defined binary format optimized for efficiency and state management ### 1. Generic JSON Structure In MQTT communication, messages are often formatted using a **Generic JSON Structure** to maintain consistency, readability, and compatibility across various clients and platforms. This structure typically includes metadata like device ID, timestamp, and sensor readings. **Key features**: - Flexibility of message structure ### 2. Sparkplug B **Sparkplug B** is designed to provide a standardized message format that is efficient and highly performant. **Key features**: - Binary payload encoding ensures efficiency, though it complicates debugging as messages must be decoded. - State management – tracks client birth/death certificates to monitor online/offline status - Standardized message types for metrics, diagnostics, and commands ## More information - [MQTT Essentials](https://www.hivemq.com/mqtt/) - [MQTT Essentials - Publish & Subscribe Architecture](https://www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe/) - [MQTT Tutorials – Introduction to Publish/Subscribe Pattern](https://www.emqx.com/en/blog/mqtt-5-introduction-to-publish-subscribe-model) - [Configuring an MQTT (JSON) collector](docId\:bg5NS_Sh2NTOtC9u7J8Ln) - [Configuring an MQTT Sparkplug B collector](docId\:v5mXdXfLqPTl9f1jtRQee)