MQTT QoS Levels: Choosing Reliability for Industrial Data
MQTT QoS Levels: Choosing Reliability for Industrial Data
Key Highlights
- MQTT QoS gives you delivery guarantees for industrial message delivery.
- QoS 0 is the fastest option, but message delivery is not confirmed.
- QoS 1 improves reliability and can resend data, though duplicate messages can happen.
- QoS 2 provides the highest reliability with exactly-once delivery.
- Higher qos levels increase network overhead and slow data transmission somewhat.
- The right quality of service depends on your data, your network conditions, and your risk tolerance.
Introduction
If you use the mqtt protocol for plant data, mqtt qos is one of the most important settings you can choose. It decides how hard the system works to protect message delivery between devices, the broker, and subscribers. That matters on the plant floor, where some values can be missed but others should not. In this guide, you will see what QoS 0, 1, and 2 mean, how they differ, and where each one fits in industrial communication.
Understanding MQTT and Its Role in Industrial Data Communication
The mqtt protocol is a lightweight way to move industrial data between systems. A publishing device sends information to an mqtt broker, and the broker forwards it to the right subscribers. That simple model works well for plant-floor data transmission.
In an industrial iot solution, MQTT can carry sensor values, events, and even some control commands. Because plant networks do not always behave the same way, you need a practical way to match message handling to actual operating needs. That is where QoS becomes useful, and the next sections explain why.
Why Controls Engineers and Plant Managers Use MQTT
Controls engineers and plant managers use MQTT because it gives structure without adding a lot of complexity. Devices act as mqtt clients, publish data once, and let the broker route it by mqtt topics. That makes it easier to organize line status, alarms, utility data, and machine conditions across many systems.
Another reason is flexibility under changing network conditions. Some use cases need fast updates and can tolerate occasional gaps. Others need stronger confirmation because missing data or repeating an action can cause real trouble. MQTT lets you set that balance by message type.
Think about three simple iot applications. A live dashboard showing motor current may use QoS 0. A production count sent to a reporting system may use QoS 1. A critical recipe change command, where repeats are unacceptable, may use QoS 2. Same protocol, different needs.
Introduction to Quality of Service (QoS) Levels in MQTT
Quality of service in MQTT is the formal level of service for how message delivery should be handled. In plain English, it tells the sender and receiver how much effort the system should make to get a message through and confirm it.
There are three mqtt qos options. QoS 0 means at most once. QoS 1 means at least once. QoS 2 means exactly once. Those are the core differences between MQTT QoS levels 0, 1, and 2, and each one changes the amount of checking and retry activity.
So what does that mean for you? A lower qos gives less protection and less overhead. A higher qos gives stronger message delivery handling, but it adds more traffic and more time. Choosing the right qos level is really about matching the level of service to the importance of the data.
MQTT QoS Levels Overview: Definitions and Delivery Guarantees
MQTT quality of service gives you three delivery guarantees for each mqtt message. The different qos levels are designed so you can choose how much protection a message needs without treating every data point the same way.
At one end, QoS 0 offers minimal checking. In the middle, QoS 1 improves the guarantee of message delivery through acknowledgment and retry. At the top, QoS 2 delivers the highest reliability with extra packet exchanges to prevent duplicates. To use them well, it helps to understand what QoS really means in operation.
What Does QoS Mean in MQTT?
In MQTT, each qos level defines a specific promise about delivery guarantees. It is not a vague setting. It is a clear rule for how the sender and receiver handle a message, whether they acknowledge it, and whether it may be resent.
Here are the delivery guarantees for each MQTT QoS level. QoS 0 is at most once, which means no acknowledgment and no retry. QoS 1 is at least once, which means the sender keeps trying until it receives a PUBACK. QoS 2 is exactly once, using a longer exchange to make sure the message is processed one time.
That makes mqtt qos a practical design tool, not just a protocol checkbox. When you set the level of service, you are deciding how much effort the system should spend to protect each message under normal and unstable conditions.
How MQTT QoS Levels Impact Industrial Data Reliability
On the plant floor, quality of service directly affects reliability. If your industrial data is sent with too little protection, you may accept more data loss than the process can handle. If you apply too much protection everywhere, you may add overhead where it is not needed.
That is why message delivery should match the job. Fast-changing values sent every second may survive occasional loss because fresh data arrives soon after. A command, event, or transaction that should not be missed may need stronger handling. The correct choice depends on what happens if the message disappears or repeats.
A practical way to choose is simple. Ask yourself three questions. Can this data be lost? Can it be duplicated? How much delay can you tolerate? Your answers point you toward QoS 0, 1, or 2 without overcomplicating the design.
QoS 0 – "At Most Once" Explained with Plant-Floor Examples
QoS 0 is the lowest level in the mqtt protocol. It sends an mqtt message once and does not ask for proof that it arrived. That is why the delivery guarantees are called at most once. If the network is stable and the data updates often, this lower qos can be a smart choice. It keeps traffic light and avoids extra acknowledgments.
On a plant floor, use qos 0 when occasional message loss is acceptable. Think of non-critical iot applications such as a dashboard showing conveyor speed, room temperature, or compressor load every few seconds. If one update is missed, the next one usually arrives soon. In that kind of use case, speed and simplicity matter more than confirmation.
How Messages Are Delivered at QoS 0
With qos 0, the sender transmits the initial publish packet and moves on. There is no follow-up handshake, no retry logic, and no delivery confirmation. The system treats the message transmission as best effort.
That keeps things simple. Because there is no acknowledgment step, qos 0 uses very little bandwidth and processing. It is often described as fire and forget. The sender does not store the message for resend, and the receiver does not send anything back to confirm receipt.
So what happens if a message is lost at QoS 0 in MQTT? It is simply gone. The sender has no way to know it was missed and will not retransmit it. That is why QoS 0 only fits cases where the delivery guarantees can be minimal and the next update can replace the last one.
When Should QoS 0 Be Used in Industrial Applications?
QoS 0 works best when your specific requirements are simple. You want low overhead, fast updates, and you can live with occasional data loss. Since it is the lowest level, it is usually a fit for stable connections and non-critical information.
A good rule is to use qos 0 when messages arrive at short intervals or when missing one value will not affect operations. You should not use it for items that must be queued for disconnected devices, because message queuing is tied to higher levels.
- Live machine status values that refresh every few seconds
- Temporary test client data on a stable wired connection
- Visual-only dashboard trends where one missed point is acceptable
If your process needs confirmation or recovery after a drop, move up from QoS 0.
QoS 1 – "At Least Once" for Reliable Message Delivery
QoS 1 is often the practical middle ground for reliable message delivery. When a device sends a publish message at qos 1, it keeps a copy until it receives a PUBACK packet from the receiver. If that acknowledgment does not come back, the sender transmits again. That retry behavior is how MQTT QoS 1 improves confidence that important data gets through.
There is a trade-off. Because the sender may resend, duplicate messages are possible. That means your application should tolerate repeats or use identifiers to handle them. Even so, QoS 1 is a common choice because it gives better protection than QoS 0 without the higher qos complexity and network overhead of QoS 2.
How MQTT QoS 1 Ensures Message Arrival
Here is how qos 1 works in plain terms. The sender publishes a message and waits for a PUBACK packet. Until that acknowledgment comes back, the sender keeps the message in memory so it can try again if needed.
Each exchange uses a packet id between a specific client and broker. That helps track which message is being acknowledged. If the sender does not get the PUBACK packet within a reasonable time, it retransmits the message. This gives you at least once message delivery.
That does not mean exactly once. If the original message arrived but the acknowledgment did not, the receiver may see the same data again. For industrial control commands, you need to think about whether a duplicate would cause trouble. If repeats are acceptable or can be managed, QoS 1 is a strong option.
Common Use Cases for QoS 1 on the Plant Floor
Many plant-floor use cases fit qos 1 because the data matters, but the application can handle occasional repeats. This level is useful when network conditions are not perfect and you still want confidence that important updates will arrive.
It works well for data transmission to reporting, historian, or monitoring layers. It can also fit some control commands, as long as your logic can safely detect or ignore duplicates. That is why qos 1 is common in industrial iot applications that need stronger delivery without the full overhead of QoS 2.
- Production counts or downtime events sent to a central system
- Alarm notifications where missing one is worse than seeing one twice
- Equipment status changes that should reach upstream software reliably
If a duplicated message would create a harmful action, you should look at QoS 2 instead.
QoS 2 – "Exactly Once" for Maximum Reliability
QoS 2 is the most protective MQTT option. It is designed for the highest reliability and the highest level of reliability in message handling. Instead of a simple acknowledgment, it uses a longer exchange with packets such as PUBREC and PUBCOMP. That extra work makes sure the same message is not processed more than once.
Still, QoS 2 is not automatically the best choice everywhere. It reduces the risk of duplicate messages, but it adds more traffic and more delay. Think of it like financial transactions in software systems: exact handling matters, so extra steps are worth it. On the plant floor, use QoS 2 only where exactly-once behavior truly matters.
How QoS 2 Prevents Duplicate Messages
QoS 2 uses four mqtt control packets to prevent message duplication. The flow includes PUBLISH, PUBREC, PUBREL, and PUBCOMP. This longer exchange is what gives QoS 2 its stronger guarantee of delivery.
First, the receiver gets the publish message and replies with a PUBREC packet. Then the sender responds with PUBREL. Finally, the receiver completes the process and sends a PUBCOMP packet. During this sequence, both sides keep state information so the same message is not processed twice.
If one packet is lost, the sender can retransmit until the exchange finishes. That is how qos 2 guarantees exactly once delivery. The receiver stores enough information about the original message to avoid processing it again, which is the key difference between QoS 2 and levels that allow repeats.
Typical Scenarios for Using QoS 2 in Industrial Settings
QoS 2 fits rare cases where one missed message is bad and one repeated message is also bad. It is the highest level of service in MQTT, so it should be reserved for data that truly needs exact handling.
In industrial systems, that often means command or event flows where duplicate execution would cause problems. Best practices are simple: use this mqtt qos level only when the business or process consequence justifies the extra overhead. If offline delivery matters, remember that persistent sessions are required for queued QoS 2 traffic.
- Critical command messages where a repeated action is unacceptable
- High-value event records that must be handled exactly once
- Transaction-like plant workflows, similar in importance to financial transactions
If QoS 1 already meets your need, QoS 2 may be more than you need.
Choosing the Right MQTT QoS Level for Your Application
The right qos choice starts with your application, not with the protocol feature list. A qos level should reflect your specific requirements, how much loss or duplication you can accept, and how stable your network conditions are.
Different mqtt clients may need different levels of reliability for different message types. A fast status stream, an alarm event, and a command should not always use the same setting. To pick the right qos level, compare speed, protection, and overhead in a practical way.
Factors to Consider: Speed, Reliability, and Network Performance
Yes, higher QoS in MQTT impacts network performance. As mqtt quality of service increases, the protocol exchanges more packets and stores more state. That improves reliability, but it also increases network overhead and can raise latency.
So how do you choose the right qos level? Start with the process impact. If speed matters most and the data refreshes often, choose lower overhead. If the message must arrive, accept more checking. If it must arrive once and only once, accept the extra steps.
| Factor | QoS 0 | QoS 1 | QoS 2 |
|---|---|---|---|
| Service level | At most once | At least once | Exactly once |
| Speed | Fastest | Moderate | Slowest |
| Reliability | Lowest | Higher | Highest |
| Best fit | Non-critical updates | Important data with duplicate tolerance | Critical exact handling |
Practical Tips for Selecting QoS in Industrial Environments
A good selection process is simple. Review the effect of loss, the effect of duplication, and your real network conditions. Then assign a qos level by message type, not by system. That gives you better data transmission design and avoids unnecessary overhead.
Also remember that the subscribing client can affect the final delivery behavior. The broker delivers using the lower of the published QoS and the subscriber’s requested level. So if one application subscribes at a lower setting, it may receive less protection than the publishing side intended.
- Use QoS 0 for fast, non-critical values updated at short intervals
- Use QoS 1 when every message matters and duplicates can be handled
- Use QoS 2 only for rare cases that require exact handling for offline clients or active systems
These best practices keep the design practical and efficient.
Conclusion
In summary, understanding MQTT QoS levels is essential for controls engineers and plant managers aiming to enhance data reliability in industrial environments. By recognizing the differences between QoS 0, QoS 1, and QoS 2, you can make informed decisions that suit your operational needs. Each level offers distinct delivery guarantees that can significantly impact your plant floor's communication effectiveness. Consider factors such as speed, reliability, and network performance when choosing the appropriate QoS level for your application. Empowered Automation is here to assist you with MQTT solutions tailored for your specific requirements. For further insights, explore our article on OPC UA vs MQTT for plant data collection to guide your decision-making process.
Frequently Asked Questions
Is MQTT QoS 2 always necessary for industrial systems?
No. MQTT QoS 2 gives the highest level of reliability, but many industrial use cases do not need it. If duplicates are acceptable or can be managed, QoS 1 is often enough. Choose the qos level based on real delivery guarantees your application actually requires.
Does higher QoS impact network speed or resource usage?
Yes. A higher qos level adds more network overhead, more delivery confirmation traffic, and more processing. That can slow data transmission compared with lower levels. MQTT quality of service is always a trade-off between stronger protection and faster, lighter communication.
What happens if a message is lost at QoS 0?
If a message is lost at qos 0, it is not resent. There are no acknowledgment steps or recovery actions at that mqtt qos setting. That means data loss is possible, which is why QoS 0 fits message transmission where the next update can replace the missed one.
Empowered Automation: Your Chicago-Area Partner for MQTT Solutions
Empowered Automation can help you apply the mqtt protocol in practical ways, from topic structure to message queuing behavior for iot applications. If you are weighing levels of reliability across plant systems, they can help define the right qos for each workflow without overbuilding the solution.
Linking OPC UA vs MQTT for Plant Data Collection (with reference to https://www.empoweredautomation.com/opc-ua-vs-mqtt-for-plant-data-collection-how-to-choose/)
If you are also comparing MQTT with OPC UA for moving sensor data, this guide can help: OPC UA vs MQTT for plant data collection. It gives useful context on when an mqtt broker and mqtt message flow fit better than opc ua, especially when delivery guarantees matter.
You might also like
