I only have basics. The sonoff group is a catch all for all sonoff. (It’s a published automation on the Tasmota Github)
My guess is you have retain: true specified for your MQTT Lights in configuration.yaml. Ensure it is set to retain: false (which happens to be the default).
Ideally, you only want state topics to be retained, not command topics. Generally speaking, that means your MQTT lights in Home Assistant ought to be configured retain: false and the physical lights (using Tasmota, ESPurna, ESPEasy, etc) configured retain: true.
Why? Because if a command topic is retained, you’re telling the MQTT broker to supply the topic’s message to every subscriber upon connection. That’s rarely desirable.
For example, let’s say home/garage_door_opener/command is retained.
- You command the door to open (command topic’s message is
on). - Then someone closes the door manually (command topic’s message is still
on). - The MQTT broker reboots and informs its subscribers of all its retained topics.
- The garage door opener receives the command
on. - Uh-oh, probably not the behavior you want!
Basically, all you retain are state topics. After the broker reboots (or a subscriber like Home Assistant reconnects) it reports to subscribers what’s currently on/off, opened/closed, etc (state topic) as opposed to instructing subscribers to turn on/off, open/close, etc (command topic).
3 Likes
Here’s the link
Not sure if this is possible in all settings, but this is the main reason I use MQTT only for state topics, and command via Api calls… Reporting a wrong state can be annoying but commanding a wrong command can be fatal…;-((
Also watch the video I linked to above. It’s well worth watching.
Yes I watched it when it came out and then again a few days ago. It is indeed very good but it also helps seeing it explained in writing.
1 Like
Agreed, it’s not always possible to be so ‘surgical’ and have retain=true used exclusively for state topics. Having said that, at the very least you are able to control the retain flag on a per device basis in Home Assistant. It would be far more encumbering if retain was a global setting for all of Home Assistant’s MQTT communications!
When determining who uses retain=true and who does not, the question is “Who is the controller and who is being controlled?”
- The controller publishes commands so it should use retain=false.
- The device being controlled publishes its state so it should use retain=true.
A sensor is a device that is not controlled but does publish its state. Most of the time it probably should publish it with retain=true. However, there may be some time-sensitive cases where you might not want the sensor’s value to be retained.
EDIT
FWIW, I had used an excellent product called Home Remote. It’s not a Home Automation system but a user-interface builder (whose client software runs on iOS, Android, and Windows) that can work with many, many different devices and protocols. I had created a UI that worked exclusively via MQTT. You quickly learn a lot about what things should/shouldn’t employ retain=true when using a phone app that you regularly connect and disconnect from the MQTT broker!
I guess if you are using MQTT discovery, the retain setting won’t be set in Home Assistant anyway as you remove the manual configuration of the switch and then the device controls it via the set options anyway.
I switched to discovery and removed all MQTT config from my configuration and everything seems to be ‘happy’ and working as I expect it to be.
Indeed, even in ‘non-discovery’ mode, where you explicitly define each MQTT entity, retain is false by default for all MQTT components.
Yes it is but almost everyone posting MQTT settings has that set to true I have noticed. (I used to as well before I saw that video and had a few chats when my switches were doing what I thought was weird stuff)
I have even seen people posting that retain should be true.
Perhaps they do it because of an incomplete understanding of how retain works. It’s the old ‘throw it against the wall and see if it sticks’ strategy! 
Turn retain on and if it seems to fix something then all must be well.
Here’s a scenario that shows why ‘if it sticks to the wall’ can be misleading:
- Use Home Assistant to turn on a light (publish command topic with retain=true).
- MQTT Broker retains a copy of the message and passes it on to the light.
- Light turns on.
- Power failure!
- Light and Home Assistant and MQTT Broker are off.
- Power is restored.
- Home Assistant and MQTT Broker come back to life.
- MQTT Broker forwards the retained message to the light.
- Light turns on.
Everything has been restored to its pre-power failure state so the user is lulled into believing all is well. Except, not really; we know this technique of retaining command topics is flawed (i.e. example above; garage door opener).
-
First, restoring a device’s state should, ideally, be the responsibility of the controller, namely Home Assistant, not the ‘middleman’ (the MQTT Broker). Alternately, it can be the responsibility of the device itself (which proceeds to report its state to the controller).
-
Second, it should be based on the device’s state prior to the power failure and not on, what is essentially, a cached command in the broker.
It’s almost a given that when someone complains that an MQTT device turned itself on/off “mysteriously”, they’re experiencing the anomaly outside of normal operating conditions. The “mystery” usually occurs when a link in the chain disconnects/reconnects, like after a restart of Home Assistant, or the MQTT Broker, or the device (or some combination of the above). That’s when the drawback of retaining command topics usually surfaces.
1 Like
Completely agree. In my case it was the switch reconnecting to the broker when the WiFi reconnected and getting a retained message - and even thought I had an automation that had turned the light off prior to the WiFi issue, when it reconnected it still turned it on. Setting retain: false and issuing the MQTT commands in the console and the automation fixed all that and now my switches function correctly.
This is excellent, thanks a lot. I had three old entries that kept bugging my HA log, but now they’re gone.
this has to be one of the best videos i’ve watched that explains HOW and WHY random switching issues occur as well as the best method for fixing this problem. i came searching here to find how to clear old retained messages in the broker, but learnt so much more.
to anyone reading the forums and randomly trying HASS and sonoff/tasmota settings like i was, stop now and watch this video.
Here is a utility to delete topics using wildcards… [warning it’s powerful]
and I put in a feature request for inclusion in the excellent MQTT Explorer… worth a + comment if you think it might be useful to you.
How i ca use it?
You’ll either need to create a package with it or put the automation in with your automations and input_text into your input_text.
Then you add the MQTT string into the input_text, hit enter and it’ll delete it.
Ok , sorry im nube , to risolve ghost swiching on my sonoff , what i need ti write ?
Whatever your MQTT String is for your Sonoff but if your Sonoff is changing states on its own, this isn’t the right thread. This is just to remove old messages.
I’d check your settings in the Sonoff itself and Home Assistant. Might need to make a new thread if you’re unable to diagnose it yourself.