MQTT QoS 0, 1, and 2 Explained Using Real Plant Examples
4th July, 2026.
In this post, we will see the concept of MQTT QoS 0,1 and 2 using real plant examples.
In modern industrial automation, thousands of devices continuously exchange data between PLCs, SCADA systems, HMIs, historians, cloud platforms, and Manufacturing Execution Systems (MES). MQTT (Message Queuing Telemetry Transport) has become one of the most widely used communication protocols for these applications because it is lightweight, efficient, and performs reliably even over low-bandwidth or unstable networks. However, not every message transmitted in a plant requires the same level of reliability. For example, a temperature transmitter may publish a new process value every second. If one reading is lost due to a temporary network interruption, the next update arrives almost immediately, making the missed value insignificant. In contrast, an operator's command to start a pump must reach the PLC, as a lost command could prevent the equipment from operating. Similarly, when a PLC sends a "Batch Completed" message to a Manufacturing Execution System (MES), the message must neither be lost nor processed more than once. Losing the message results in missing production records, while processing it twice can create duplicate batch entries.
This is where MQTT Quality of Service (QoS) plays a vital role. Quality of Service determines how reliably an MQTT message is delivered from the publisher to the subscriber. Rather than applying the same communication strategy to every message, MQTT allows engineers to choose the most appropriate level of reliability based on the importance of the data being transmitted.
MQTT provides three Quality of Service levels: QoS 0 (At Most Once), QoS 1 (At Least Once), and QoS 2 (Exactly Once). Each level offers a different balance between communication reliability, network bandwidth, and processing overhead. While QoS 0 prioritizes speed with minimal overhead, QoS 2 provides the highest level of reliability through additional message exchanges. QoS 1 strikes a balance between these two by ensuring message delivery while accepting the possibility of duplicate messages.
In this article, we will explore each QoS level using real plant examples, understand how MQTT behaves during network failures, and compare the advantages and limitations of each level. By the end, you'll have a clear understanding of which QoS level is best suited for different industrial automation applications.
Why do we need different QoS levels?
In an industrial automation system, thousands of messages are exchanged every minute between field devices, PLCs, SCADA systems, HMIs, historians, cloud platforms, and Manufacturing Execution Systems (MES). While all these messages are important, they do not all require the same level of delivery reliability. Using the highest reliability for every message would unnecessarily increase network traffic and communication overhead, whereas using the lowest reliability for critical messages could lead to operational issues.
Consider a temperature transmitter that publishes the process temperature every second. If one reading is lost because of a temporary network interruption, the next reading arrives almost immediately. Since the control system continues to receive updated values, losing a single measurement has little or no impact on plant operation. For such continuously changing process values, maximum reliability is generally unnecessary.
Now consider an operator issuing a Start Pump command from the SCADA system. Unlike temperature data, this command is sent only once. If the message is lost, the PLC never receives the instruction, and the pump remains stopped until the operator retries the command. In this case, reliable message delivery is essential.
An even more critical example is when a PLC informs the MES that Batch #101 has been completed. This message represents a production transaction rather than a continuously changing process value. If the message is lost, the production record is missing. If the same message is processed twice, the MES may create duplicate production records, leading to inaccurate reports, inventory mismatches, and traceability issues. Therefore, the message must be delivered and processed exactly once.
These examples clearly show that different types of plant data require different communication guarantees. Continuously updated sensor values prioritize communication speed, operator commands require reliable delivery, and production transactions demand both reliable delivery and protection against duplicate processing. To address these varying requirements, MQTT provides three Quality of Service (QoS) levels. Each level is designed to offer a different balance between reliability, communication overhead, and network performance, allowing engineers to choose the most appropriate option for each application rather than applying the same delivery mechanism to every message.
QoS 0 - At Most Once
QoS 0 is the simplest and fastest message delivery level in MQTT. It follows the "fire and forget" principle, where the publisher sends a message to the broker only once and does not wait for any acknowledgment. Once the message is transmitted, the publisher assumes the delivery is complete. If the message is lost due to a network interruption or communication failure, MQTT does not attempt to retransmit it. Since QoS 0 does not require acknowledgments or retries, it introduces the least communication overhead and offers the highest throughput. This makes it ideal for applications where data is updated frequently and occasional message loss does not affect the overall operation of the plant.
Consider a temperature transmitter connected to a PLC that publishes the process temperature to a SCADA system every second using MQTT. Under normal conditions, the SCADA system continuously receives updated temperature values as shown below:
Temperature Updates:45.2°C → 45.3°C → 45.4°C → 45.5°C → 45.6°C45.2°C → 45.3°C → X → 45.5°C → 45.6°C
Now assume the network experiences a brief interruption while the 45.4°C value is being transmitted.
The SCADA system misses one reading, but the very next update arrives one second later. Since the process value is continuously changing, losing a single measurement has little impact on monitoring or control. MQTT does not retransmit the lost message because a newer value is already available. This is exactly why QoS 0 is well suited for continuously updated process data. Retransmitting an older temperature value would provide little benefit when a newer and more accurate measurement is already on its way. Whenever missing an occasional update is acceptable because the next value quickly replaces it, QoS 0 is usually the most efficient choice.
The primary advantage of QoS 0 is its speed and efficiency. Since no acknowledgments are exchanged between the publisher and the receiver, communication overhead is minimal, resulting in lower network bandwidth usage and reduced processing requirements. This makes QoS 0 ideal for applications that continuously transmit large volumes of data at high frequency.
The main limitation of QoS 0 is that it provides no guarantee of message delivery. If a message is lost due to network congestion or a communication failure, MQTT does not retransmit it, and the subscriber never receives that particular update. Therefore, QoS 0 should not be used for messages where every transmission is critical to plant operation.
QoS 0 is best suited for continuously changing process values such as temperature, pressure, flow, tank level, humidity, and energy measurements. Since these parameters are updated frequently, missing an occasional reading has little impact because a newer value is transmitted shortly afterward. For such applications, the speed and efficiency of QoS 0 outweigh the need for guaranteed delivery.
QoS 1 - At Least Once
Unlike QoS 0, QoS 1 ensures that a message reaches the receiver at least once. After publishing a message, the sender waits for an acknowledgment (PUBACK) from the receiver. If the acknowledgment is received, the communication is considered successful. However, if the acknowledgment does not arrive within the specified timeout period, the sender assumes that the message or acknowledgment was lost and retransmits the same message. This acknowledgment mechanism significantly improves communication reliability compared to QoS 0. Even if temporary network interruptions occur, the sender continues retransmitting the message until it receives a PUBACK. As a result, the message is guaranteed to reach the receiver at least once.
However, this reliability introduces an important characteristic of QoS 1. If the receiver successfully processes the message but the PUBACK is lost during transmission, the sender has no way of knowing that the receiver already received it. Consequently, the sender retransmits the same message, and the receiver may receive it more than once. For this reason, QoS 1 guarantees message delivery, but it does not guarantee that the message will be processed only once.
Consider an operator issuing a Start Pump P-101 command from the SCADA system. Since this command is sent only once, it is important that the PLC receives it. Using QoS 1, the SCADA system sends the command and waits for a PUBACK from the PLC. Once the PLC receives the command, it sends the acknowledgment, confirming successful delivery. Now assume the PLC receives the Start Pump command and immediately sends a PUBACK. Unfortunately, the PUBACK is lost due to a temporary network interruption. Since the SCADA system never receives the acknowledgment, it assumes the original message was not delivered and retransmits the same Start Pump command. As a result, the PLC receives the command a second time. In this particular example, receiving the command twice usually has no adverse effect because the pump is already running after the first command. The second command simply instructs the PLC to start a pump that is already in the running state. This is why QoS 1 is commonly used for commands such as motor start/stop operations, valve open/close commands, setpoint changes, and alarm notifications, where duplicate messages can either be safely ignored or handled by the application logic.
QoS 1 provides a good balance between reliability and communication overhead. By using acknowledgments and automatic retransmissions, it ensures that important messages are successfully delivered even if temporary communication failures occur. This makes it suitable for industrial applications where reliable delivery is more important than communication speed.
Although QoS 1 guarantees message delivery, duplicate messages are possible whenever acknowledgments are lost. Therefore, applications using QoS 1 should be designed to safely handle repeated messages whenever duplicate processing could cause operational issues.
QoS 1 is widely used for operator commands, equipment start and stop commands, valve operations, setpoint changes, recipe downloads, and alarm notifications. These messages must reliably reach their destination, while occasional duplicate deliveries can usually be tolerated or managed through application logic.
QoS 2 - Exactly Once
While QoS 1 guarantees that a message is delivered, it does not prevent duplicate deliveries if acknowledgments are lost. For many industrial applications, this is acceptable because repeated commands such as Start Pump or Open Valve generally do not cause problems. However, some messages represent critical business or production transactions where processing the same message twice can lead to incorrect records or duplicate operations. To address this requirement, MQTT provides QoS 2, which guarantees that a message is delivered and processed exactly once. Unlike QoS 1, QoS 2 uses a four-step handshake consisting of PUBLISH, PUBREC, PUBREL, and PUBCOMP. Instead of relying on a single acknowledgment, both the sender and the receiver maintain the state of the communication until the entire transaction is completed. This additional tracking ensures that even if packets are retransmitted because of network failures, the receiver recognizes that they belong to the same transaction and does not process the application message more than once.
Consider a PLC that sends a "Batch #101 Completed" message to the Manufacturing Execution System (MES) after a production batch finishes. This message creates an official production record that may be used for inventory updates, production reporting, product traceability, or regulatory compliance. If this message is lost, the MES has no record that the batch was completed. On the other hand, if the same message is processed twice, the MES may generate duplicate production records, resulting in incorrect production counts and reporting errors. In such cases, neither losing the message nor processing it twice is acceptable. This is exactly the type of application for which QoS 2 is designed.
One of the biggest advantages of QoS 2 is that it continues to operate correctly even when communication packets are lost.
Case 1 - PUBLISH is lost
If the initial PUBLISH message never reaches the MES, the PLC does not receive a PUBREC acknowledgment. After waiting for the timeout period, it retransmits the PUBLISH message. Since the MES never received the original message, it processes the retransmitted message normally and continues with the QoS 2 handshake.
Case 2 - PUBREC is lost
Suppose the MES successfully receives the PUBLISH message and stores it temporarily before sending PUBREC. If the PUBREC packet is lost, the PLC assumes the original message was not received and retransmits the PUBLISH message. However, the MES recognizes that this message has the same MQTT Packet Identifier as the one it has already stored. Instead of creating another production record, it simply sends PUBREC again and waits for the next step in the handshake.
Case 3 - PUBREL is lost
After receiving PUBREC, the PLC sends PUBREL, indicating that the transaction can now be completed. If this packet is lost, the MES continues waiting for PUBREL and does not process the transaction. Since the PLC never receives PUBCOMP, it retransmits PUBREL. Once the MES receives it, the production record is created only once, and PUBCOMP is returned to complete the transaction.
Case 4 - PUBCOMP is lost
Finally, suppose the MES successfully completes the transaction and sends PUBCOMP, but this packet is lost before reaching the PLC. Since the PLC does not receive the final acknowledgment, it retransmits PUBREL. The MES recognizes that this transaction has already been completed and simply sends PUBCOMP again without creating another production record. This ensures that the application processes the message exactly once, even though protocol packets may be retransmitted multiple times.
QoS 2 provides the highest level of communication reliability offered by MQTT. It guarantees that important messages are delivered exactly once, eliminating the risk of duplicate processing even when acknowledgments or communication packets are lost. This makes it the preferred choice for applications involving production records, financial transactions, audit logs, and other critical industrial events.
The additional message exchanges required for the four-step handshake increase communication overhead, network bandwidth usage, and processing time compared to QoS 0 and QoS 1. For this reason, QoS 2 should be reserved for messages that genuinely require exactly-once processing rather than being used for all plant communications.
QoS 2 is commonly used for batch completion events, production transactions, audit records, inventory updates, product traceability information, billing data, and other business-critical messages where duplicate processing or message loss cannot be tolerated.
Difference between QoS 0, QoS 1 and QoS 2
The primary difference between the three MQTT Quality of Service (QoS) levels lies in the reliability they provide for message delivery. QoS 0 offers the fastest communication by sending the message only once without waiting for any acknowledgment. If the message is lost during transmission, MQTT does not attempt to resend it. This makes QoS 0 ideal for continuously updating process values, such as temperature, pressure, and flow, where an occasional missed reading has little impact because a newer value is transmitted shortly afterward.
QoS 1 improves reliability by requiring the receiver to acknowledge each message using a PUBACK packet. If the sender does not receive this acknowledgment within the specified timeout period, it retransmits the same message until the acknowledgment is received. As a result, the message is guaranteed to reach the receiver at least once. However, if the receiver successfully processes the message but the acknowledgment is lost, the sender retransmits the message, which means the receiver may receive and process the same message more than once. Therefore, QoS 1 guarantees message delivery but does not eliminate the possibility of duplicate processing.
QoS 2 provides the highest level of reliability by ensuring that every message is delivered and processed exactly once. Instead of relying on a single acknowledgment, MQTT uses a four-step handshake consisting of PUBLISH, PUBREC, PUBREL, and PUBCOMP. During this process, both the sender and the receiver keep track of the transaction using the MQTT Packet Identifier. Even if any communication packet is lost and needs to be retransmitted, the receiver recognizes that it belongs to an existing transaction and avoids processing the application message again. This makes QoS 2 the preferred choice for production transactions, batch completion records, audit logs, and other critical events where duplicate processing cannot be tolerated.
Another important difference is the communication overhead associated with each QoS level. Since QoS 0 does not exchange acknowledgments, it has the lowest network overhead and the highest communication speed. QoS 1 introduces a small amount of additional traffic because acknowledgments are exchanged, providing a balance between reliability and performance. QoS 2 generates the highest network traffic due to its four-step handshake, making it slower than the other two levels. Consequently, QoS 2 should be used only when the application truly requires exactly-once processing.
In practice, selecting the appropriate QoS level depends on the importance of the message rather than using the highest reliability for every application. Continuously changing process values are best transmitted using QoS 0, operator commands and alarm notifications are typically suited for QoS 1, while production transactions and business-critical events should use QoS 2 to ensure that every message is processed exactly once.
Common mistakes when selecting MQTT QoS levels
One of the most common mistakes is assuming that QoS 2 should be used for every MQTT message because it offers the highest reliability. In reality, QoS 2 introduces additional communication overhead due to its four-step handshake, which increases network traffic and processing time. Using QoS 2 for continuously changing process values such as temperature, pressure, or flow provides little benefit, as newer measurements quickly replace older ones.
Another frequent misconception is believing that QoS 1 prevents duplicate messages. While QoS 1 guarantees that a message reaches the receiver at least once, duplicate deliveries are still possible if the acknowledgment (PUBACK) is lost. Applications using QoS 1 should therefore be designed to safely handle duplicate messages whenever repeated processing could cause problems.
Many engineers also assume that QoS guarantees successful execution of a command. In reality, MQTT QoS only guarantees message delivery according to the selected QoS level. For example, receiving a Start Pump command does not necessarily mean the pump has started successfully. The PLC or receiving application must still verify the command execution and report the actual equipment status.
Another mistake is selecting a QoS level based solely on the importance of the equipment instead of the importance of the message. For example, a temperature value from a critical reactor can still use QoS 0 because updated readings are published continuously. On the other hand, a Batch Completed message from the same reactor should use QoS 2 because duplicate or missing production records are unacceptable.
Finally, avoid using a single QoS level across the entire system for the sake of simplicity. Industrial automation systems typically exchange different types of data, each with its own reliability requirements. Choosing the appropriate QoS for each message type helps optimize network performance while ensuring that critical information is delivered with the required level of reliability.
I have covered the general theory on MQTT QoS 0,1 and 2 using real plant examples. I have also not attempted to cover all the topics related to it, as it can vary from case to case. Once you are familiar with this type of technology, you can easily troubleshoot any issues related to it.
Thank you for reading the post. I hope you liked it and will find a new way in this type of technology.
Comments
Post a Comment
If you have any queries, please let me know