English is currently available.
Home Automation DISCUSSION
I run a Mosquitto broker on a Raspberry Pi with about a dozen ESP8266 and ESP32 nodes: relays, temperature sensors and a garage door controller. My topics grew without a plan, and I have seen odd behaviour: a relay that switches by itself when its node reboots, and sensors that show stale values on the dashboard after the node has died.
What is a sound way to organise topics, and when should I use retained messages and the different QoS levels?
Use a hierarchy that goes from general to specific and separates what a device reports from what it is told, for example home/garage/door/state, home/garage/door/set and home/garage/door/availability. Only the device publishes to state; only controllers publish to set. That separation stops the feedback loops you get when a device both listens and reports on one topic.
The hierarchy pays off with wildcards: + matches exactly one level and # matches everything below, so home/+/+/state collects every state and home/garage/# everything in the garage. Keep topics lowercase, without spaces and without a leading slash, since a leading slash creates an empty first level.
Your self-switching relay is a retained command. When a message is published with the retain flag, the broker stores it and delivers it to every client that subscribes later, including your node each time it reboots and resubscribes. A retained ON or OPEN on a set topic is therefore replayed after every restart. For a garage door that is a safety problem, not just an annoyance.
The rule that follows: retain state, never commands. Retained state lets a dashboard show the right value immediately after it connects. To remove a stale retained message, publish an empty payload with the retain flag to the same topic.
The stale sensor values are solved with the Last Will and Testament. When connecting, the node registers a will message, for example offline on its availability topic, retained. Immediately after connecting it publishes online to the same topic, also retained. If the node dies without disconnecting cleanly, the broker publishes the will on its behalf.
Detection time is set by the keep-alive interval: the broker declares the client dead when it has heard nothing for one and a half times the keep-alive. With a 60 s keep-alive, the dashboard learns of the failure within about 90 s. Shorter values detect faster but cost a little traffic and, on battery nodes, energy.
On QoS: level 0 sends once with no acknowledgement, level 1 repeats until acknowledged, so the message arrives at least once and may arrive twice, and level 2 adds a four-step handshake so that it arrives exactly once. On a home LAN, QoS 0 is fine for periodic sensor readings, because the next reading replaces a lost one. Use QoS 1 for commands and events that matter, and make commands idempotent (ON and OFF rather than TOGGLE) so that a duplicate does no harm.
Check what your client library supports. The widely used PubSubClient for Arduino publishes at QoS 0 only and has a small default packet buffer, so long topics with JSON payloads can be dropped silently until you enlarge it.
Two frequent causes of mysterious reconnects are worth ruling out. Every client must have a unique client ID; if two nodes flashed from the same sketch share one, the broker disconnects the first when the second connects, and they keep kicking each other off. Derive the ID from the chip's MAC address. And make the node resubscribe after every reconnect, because a clean session forgets subscriptions.
For security, turn off anonymous access, give devices user names and passwords with topic access rules, and do not forward the broker's port 1883 to the internet. If anything outside the house needs access, use TLS on port 8883 or, better, reach the broker through a VPN.
Back to Home Automation community
