MQTT

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 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 between the sensor (publisher) and the mqtt collector (subscriber) 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 in between either the sensor and the mqtt broker or either 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, to be received by the mqtt collector (subscriber) when the mqtt collector receives the message, it sends an acknowledgment back to the broker, which is also forwarded to the temperature sensor (notifies both the mqtt broker and the temperature sensor that the message was received by the mqtt collector) if the acknowledgment message is not received by the temperature sensor e g because of a connection interruption, it resends the corresponding message until it is received successfully 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 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 the message sent by the publisher is guaranteed to arrive only once at the subscriber, through a handshake process (multiple messages back and forth) this is the most reliable but also the most resource intensive qos level 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 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 according 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 specifically to have a standardized message format that is efficient and highly performant in use 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 extra information for a better understanding of mqtt, check out the following articles mqtt essentials mqtt essentials publish & subscribe architecture mqtt tutorials – introduction to publish/subscribe pattern next steps configuring an mqtt (json) collector docid\ bg5ns sh2ntotc9u7j8ln configuring an mqtt sparkplug b collector docid\ v5mxdxflqptl9f1jtrqee