Tasmota Switches – Random On/Off? Incorrect state reported?.
Today on the hookup we’re going to take a detailed look at the MQTT retain settings in Tasmota and figure out why your tasmota device may not be acting the way you want it to.
Whether you’ve got sonoffs, or shelly’s or some other type of tasmotized device, you’ve probably had at least one experience where they didn’t quite act the way you expected them to. I’ve read dozens of posts on reddit and facebook groups about people experiencing “ghost switching” where their tasmota device turns on or off unexpectedly. DrZzs made a video about hardware ghost switching, and while electrical interference is certainly a possibility, I’m willing to bet that the vast majority of these random switching events are caused by a much more dark and sinister problem….
User Configuration Error!
Errors in MQTT configuration can cause very mysterious and annoying things to happen with your tasmota devices, but today we’re going to pull back the curtains on those mysteries and get your tasmota devices set up correctly.
The first thing we need to take a look are the three different MQTT topics used by tasmota. These topics are tele, which stands for telemetry data messages, which is where every 5 minutes by default, your sonoff will report all kinds of statistics statistics about uptime, vcc voltage, and relay state. Most people never pay attention to their tele messages since they are sent at an interval of 5 minutes instead of on demand.
The state topic channel is stat, which is where your sonoff will publish any changes in attached devices. If the relay changes from off to on, it will immediately publish “ON” to its state topic. The state topic is used by your home automation system to know the current state of your tasmota devices.
The last topic is cmnd, which stands for command messages. This is the topic that your tasmota device actually responds to. If you want to turn your tasmota device on or off you’ll need to send the correct payload to the cmnd topic.
Each of these topics has the option to publish messages using a retain flag using commands in the tasmota console.
If you’re interested in learning about MQTT retain and QoS, I made a whole video talking about the basics of MQTT, but this video will cover the quick and dirty of retained messages as they pertain to tasmota.
Your MQTT broker keeps a file called a “persistence file”, in this simple file it keeps the last retained message for each MQTT topic that has ever been published to it. When a device like a node-mcu or a sonoff reboots and reconnects to the MQTT server all it needs to do is subscribe to the topics that are relevant and the MQTT server will send it the last retained message on each of those topics, updating the device on what’s been happening while it was disconnected.
Retain is really useful, but if not configured correctly it can be the root of the most common problem I’ve seen on forums and facebook groups: “My tasmota device is randomly turning on in the middle of the night and scaring us to death”.
The underlying problem in these cases is most likely poor wifi connection, or a power surge, either of which can cause a tasmota device to reboot, and with rebooting comes resubscription to MQTT topics. If a retained message is not available on the cmnd topic, your sonoff will use an option called “powerOnState”, which can be set to always turn the relay on after reboot, turn off after reboot, or use the last saved power state. That power state is stored in the non-volatile memory of the ESP8266 chip so it will persist through a reboot.
However, if you’ve ever configured any of your devices to publish a retained message to that cmnd topic, your experience will be different because your device is going to receive a new command the second it connects to your MQTT broker. Even if you removed that setting long ago, the retained messages are still on your broker, and will be resent any time a device connects.
Lets look at a common way this issue plays out. I’ve configured my home assistant MQTT switch to publish with a retain flag, but I haven’t turned on any of the retain settings in tasmota. I’ll turn my light on with home assistant, which populates the command topic with an ON retained message. Next I’ll turn off my light using the push button, you can see in the tasmota console that this publishes a message of “OFF” to the command topic. But since it isn’t a retained message it doesn’t overwrite the previous “ON” message that was sent by home assistant.
If I unplug my sonoff and plug it back in, bam, it turns on, even though my powerOnState is set to “last saved state”, even though the last message published to that topic was “OFF”, and even though the light was off when I unplugged it. All because of that pesky retained message, it could have been published a year ago, and it will still come back to haunt you every time your device reboots until you overwrite it with another retained message.
There are theoretically two ways to fix this issue: Either enable retained messages on all devices that are capable of controlling your tasmota device, or disable retained messages on all devices and clear the retained messages on your MQTT broker. I’m going to suggest the later.
I’m going to be using Tasmota 18.104.22.168 in this video, but your experience should be pretty much the same if you’re using a version of Tasmota released in the last 6 months or so.
Lets start out by fixing your home assistant configuration, you’ll need to make sure that your MQTT switches either have the entry, retain: false, or don’t have a retain value at all (since the default retain value is false).
Next you need to go into the tasmota console. Navigate to your tasmota device’s IP and click on console in the main menu. Once you’re in the console you’ll need to type in switchretain off, and then you’re going to type buttonretain on, followed by buttonretain off. The reason we did that is that you can see this results in tasmota sending a blank retained message to all the different command topics, which clears out any previously retained messages.
Last you’ll need to make sure your PowerOnState is correct. By default the PowerOnState is 3, which means it turns on to the last power state, if you’ve changed it, you should change it back by typing PowerOnState 3.
Now your sonoff should always restore it’s previous state after reboot, no matter which device controlled it last.
The second issue that I see consistently is with incorrect switch states being reported by home assistant after a restart. This issue has to do with the stat or state topic, which is where the tasmota device reports any changes in the state of the relay. The state topic is then used to tell home assistant if the switch is currently on or off. If you’ve ever restarted home assistant and noticed that your switches are not in the correct position, then you need to adjust your powerretain settings. When power retain is on each change in state will result in a retained message published to the state topic. Any time home assistant restarts it will receive that last retained message containing tasmota’s the current state immediately upon resubscribing to the state topic.
To enable power retain, you just need to type powerRetain on into the tasmota console.
The last common issue has to do with using tasmota as a door sensor to monitor the state of a garage door like in DrZzs sonoff SV video, or an interior door like in my sonoff door sensor video. The issue is that after a restart, home assistant won’t show the correct state of the door until the door’s state is changed. In this case we’re going to fix this problem by turning SwitchRetain on.
By using switchRetain we’ll accomplish the same thing that we did with our home assistant switches, where upon restart home assistant will resubscribe to that command topic and receive the last retained message on that topic, which should be an accurate depiction of the current state of the door. In this case we don’t need to worry about this messing with the state of the relay since we’ll also be using a custom SwitchTopic to decouple our switch from the relay.
To enable switchRetain in the event that you are using tasmota for a door sensor you can type “switchRetain on” into the tasmota console.
The option also exists to publish telemetry messages with the retain flag using the SensorRetain on command, but I personally can’t think of a legitimate reason to do so since this information is published every 5 minutes anyway.
These 3 fixes should solve about 90% of the problems that I’ve seen with tasmota on forums and facebook groups. Let me know down in the comments if I missed your issue, or if you have some other fringe case that wasn’t addressed in this video. If you want to know more about MQTT settings like QoS and retain you should check out my video about how IoT devices communicate.
A big thanks to my patreon supporters who allow me to make videos like this one where I’m not really making anything. Most of the support for my channel comes from you guys using amazon affiliate links for the components that I use in my projects, but I didn’t build anything today, I hopefully just helped you fix problems with devices that are already in your house. If you’re interested in supporting my channel check out the links in the description. If you enjoyed this video, please consider subscribing, and as always, thanks for watching the hookup.