What happens to your “turn off the lights” command if your Wi-Fi hiccups for half a second? In most smart homes, the answer depends on one small setting buried in your broker configuration: the MQTT QoS level. Get it right, and your home feels instant and reliable. Get it wrong, and you get either missed commands or a broker that grinds under load. (MQTT: The Standard for IoT Messaging)
This guide breaks down how MQTT quality of service actually works, where each level belongs in a home setup, and the mistakes that trip up even experienced tinkerers.
What MQTT QoS Actually Means
MQTT is a lightweight publish-subscribe protocol. Devices publish messages to a broker, and other devices subscribe to topics. QoS (quality of service) is the delivery guarantee attached to those messages.
There are exactly three levels, and they have been stable across both major versions of the specification: MQTT 3.1.1, published as an OASIS Standard in 2014, and MQTT 5.0, published in 2019. Version 5.0 added useful features like reason codes and shared subscriptions, but it did not change the three levels. (MQTT)
| Level | Name | Guarantee | Handshake | Typical Use |
|---|---|---|---|---|
| 0 | At most once | Fire and forget | None | High-rate sensor data |
| 1 | At least once | Delivery confirmed, duplicates possible | PUBLISH → PUBACK | Most control and state messages |
| 2 | Exactly once | No duplicates, no loss | Four-part exchange | Billing, locks, irreversible actions |
Here is the part that surprises people. QoS is negotiated per subscription, and the effective level is the minimum of the publish QoS and the subscriber’s maximum QoS. If a sensor publishes at QoS 2 but the dashboard subscribes at QoS 0, the message is delivered at QoS 0. Both ends have to agree before the stronger guarantee applies.
QoS 0: At Most Once, and Often Good Enough
At QoS 0, the publisher fires a message at the broker and moves on. No acknowledgment, no retransmission. If the connection drops or the broker is overloaded, the message simply vanishes.
For smart homes, that sounds alarming until you think about what is actually being sent. A temperature sensor reporting every five seconds does not need a guaranteed delivery. If one reading is lost, the next arrives in five seconds anyway. The same logic applies to power metering, motion sensors that re-trigger constantly, and dashboard telemetry.
The practical benefit is real. QoS 0 generates the least network traffic and the least broker state, which matters on the modest hardware many people run at home, like a Raspberry Pi. When hobbyists complain that their broker becomes sluggish after adding a dozen sensors, the fix is often downgrading chatty telemetry topics to QoS 0 rather than buying new hardware.
The mistake to avoid: using QoS 0 for anything a person expects to happen. A light that fails to turn on once every few hundred commands will feel broken, and the failure will be nearly impossible to reproduce.
QoS 1: At Least Once, the Workhorse of Home Automation
QoS 1 adds a PUBACK acknowledgment from the broker. The publisher resends if no acknowledgment arrives, which means delivery is confirmed but duplicates are possible.
This is the level most home automation messages belong at. Light commands, thermostat setpoints, scene activations, and device state reports all fit comfortably here. The traffic overhead is modest, and the reliability gain over QoS 0 is substantial.
Duplicates are the catch. A retransmitted message can arrive twice, so subscribers should be idempotent, meaning processing the same message twice produces the same result. Turning a light “on” twice is harmless. Toggling a light twice is not, which is why well-designed smart home integrations send explicit on and off commands rather than toggle commands.
There is a second catch that causes endless confusion: “QoS 1 guarantees delivery” is misleading on its own. Delivery to an offline subscriber depends on broker settings, specifically persistent sessions (clean session in 3.1.1, clean start and session expiry in 5.0). If a device subscribes with a clean session, messages sent while it was offline are discarded no matter what QoS was used. Brokers also apply their own queue limits and message expiry, so a QoS 1 message can still be dropped silently once a queue fills up.
If you are building out a home automation stack and want the surrounding hardware to cooperate, it helps to start with a solid foundation of best smart home devices for beginners before tuning protocol settings.
QoS 2: Exactly Once, Rarely Needed at Home
QoS 2 uses a four-part handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP) to guarantee that a message is delivered exactly once. It costs more round trips and more broker state per message.
In home automation, the honest answer is that QoS 2 is rarely warranted. The cases where duplicate actuation is genuinely harmful are narrow: unlocking a door, disarming an alarm, or triggering a billing event. Even then, many practitioners argue that idempotent message design solves the problem more cheaply than the protocol handshake does. Sources disagree on this point, so treat it as a design opinion rather than a rule.
What QoS 2 does not do is make anything secure. It provides no encryption and no authentication. TLS and broker access control lists are separate concerns, and a lock command sent at QoS 2 over plain TCP is still exposed. Anyone tightening up a home network should pair QoS choices with proper transport security and, for the physical side, the guidance on best smart locks for home security.
Mapping QoS to Real Smart Home Devices
Abstract levels become clearer with concrete assignments. A sensible starting configuration looks like this:
- Environmental sensors (temperature, humidity, air quality): QoS 0. High frequency, low consequence.
- Presence and motion sensors: QoS 0 for continuous reporting, QoS 1 for the initial trigger if automations depend on it.
- Lighting and switches: QoS 1. Users notice missed commands.
- Climate control and covers: QoS 1. State changes should be confirmed.
- Door locks and alarm panels: QoS 1 with idempotent commands, or QoS 2 if the implementation supports it cleanly.
- Energy and utility meters: QoS 1, and QoS 2 only if readings feed billing.
A useful mental model: the higher the level, the more the system behaves like a careful clerk who confirms every instruction. For a lamp, a quick nod is enough. For a front door, you want the signature.
The Broker Settings That Undo Your QoS
This is where most home setups quietly fail. QoS is only half the reliability story. The other half lives in broker configuration.
Persistent sessions determine whether a subscriber that goes offline keeps receiving queued messages when it returns. Without them, a QoS 1 message published while a device was rebooting is gone. With them, the broker holds messages, but only up to its queue limits.
Queue limits and message expiry vary by broker implementation. Eclipse Mosquitto, HiveMQ, and EMQX all handle offline queuing differently, and default limits can be surprisingly small. A sensor that publishes every second while a subscriber is offline for an hour can easily overflow a queue.
Retained messages are a separate feature that many people confuse with QoS. A retained message gives a new subscriber the last known value on a topic immediately. It is excellent for device state and does not require QoS 1 or 2 to work.
The practical takeaway: if commands go missing, check session persistence and queue limits before raising QoS. Raising QoS on a broker with a clean-session subscriber changes nothing.
Common Mistakes and What Actually Works
A few patterns show up again and again in home automation projects.
Setting everything to QoS 2 “for safety.” This is the most common error. It multiplies broker state, slows throughput on small hardware, and provides no benefit for messages that are already safe to repeat. The result is a system that feels heavier without feeling more reliable.
Forgetting that QoS is negotiated. Publishing at QoS 2 to a subscriber capped at QoS 0 gives QoS 0 delivery. Both ends need alignment, and mismatches are invisible unless you check.
Using toggle commands with QoS 1. Duplicates turn a toggle into a double-toggle. Explicit on and off payloads fix this permanently.
Ignoring what happens during a broker restart. If the broker itself reboots, in-flight QoS 1 and 2 messages may be lost unless persistence is configured. Many home brokers run with persistence disabled by default.
Assuming QoS covers security. It does not. TLS, unique credentials per device, and topic-level ACLs are the actual security layer. A hub with sensible defaults helps, and options like the Home Center Lite smart home hub show how much of this configuration can be handled for you.
For anyone running voice control or media routines on top of MQTT, the same logic applies to the endpoints: choosing smart speakers for home automation that integrate cleanly matters more than pushing QoS to its maximum.
A Simple Decision Rule
When in doubt, ask one question: what happens if this message arrives twice, or not at all?
If neither outcome matters much, use QoS 0. If a duplicate is harmless but a miss is annoying, use QoS 1. If a duplicate is genuinely harmful, design the command to be idempotent first, then consider QoS 2. That single question resolves the vast majority of smart home topics, and it scales from a two-device starter setup to a house with dozens of sensors.
Conclusion
MQTT QoS levels are less mysterious than they look. Three levels, one negotiation rule, and a handful of broker settings account for nearly every reliability question in a home setup. QoS 0 suits high-rate telemetry, QoS 1 carries the messages people actually notice, and QoS 2 earns its overhead only in narrow cases where duplication causes real harm.
The deeper lesson is that reliability is a system property, not a setting. Persistent sessions, queue limits, idempotent commands, and sensible topic design matter as much as the number attached to a publish call. Choose the lowest level that satisfies the consequence of failure, verify how your broker handles offline subscribers, and the rest follows naturally.
Frequently Asked Questions
What is the default MQTT QoS level?
The default is QoS 0. If a publisher or subscriber does not specify a level, the message is sent at most once with no acknowledgment. Many client libraries let you set a default per connection, but the protocol itself assumes 0 unless told otherwise.
Does higher QoS make my smart home more reliable?
Not by itself. QoS only governs message delivery between client and broker. Reliability also depends on persistent sessions, broker queue limits, network stability, and whether commands are safe to repeat. Raising QoS on a broker with clean sessions can add overhead without fixing the actual failure.
Should I use QoS 2 for smart locks?
It depends on the implementation. QoS 2 prevents duplicate delivery, which matters for irreversible actions like unlocking a door. However, an idempotent command that sets a known state achieves much of the same safety at lower cost. Either way, QoS provides no encryption, so TLS and access control are essential.
Why are my QoS 1 messages still getting lost?
The most likely causes are clean sessions (messages to offline subscribers are discarded), broker queue limits being exceeded, message expiry settings, or the broker restarting without persistence enabled. Check those before assuming the QoS level is at fault.
Can publisher and subscriber use different QoS levels?
Yes, and this is common. The effective delivery level is the minimum of the publish QoS and the subscriber’s maximum requested QoS. A publisher sending at QoS 2 to a subscriber capped at QoS 0 results in QoS 0 delivery, which often explains unexpected message loss.
Is QoS 0 ever the right choice for a smart home?
Frequently, yes. High-frequency telemetry such as temperature, power, and motion reporting loses little from an occasional dropped message because the next reading arrives seconds later. Using QoS 0 for these topics keeps broker load low, which noticeably helps on Raspberry Pi class hardware.
