Tasmota: Restart Power State Always ON

Created on 15 Aug 2017  Â·  33Comments  Â·  Source: arendst/Tasmota

Restarting Sonoff Tasmota 5.5.2 with web interface resumes with Power state ON always.

I have just uploaded new Tasmota 5.5.2 to a new Sonoff. I am using Home Assistant as my Automation server, however I am not sure that is in play here. The problem I have is that after resetting the device with the Tasmota web interface, it comes back with power state ON even if it was OFF when the restart occurred and even if the Home Assistant last state was off.

After the restart, the web interface and Home Assistant are updated to show the ON state. I have changed many settings suggested here, but non seem to work. This is the current state:
With Tasmota user. config.h:

define SAVE_DATA 1

define SAVE_STATE 1

define MQTT_USE 1

define MQTT_BUTTON_RETAIN 0

define MQTT_POWER_RETAIN 1

define MQTT_SWITCH_RETAIN 1

I did not change any of the PUB_PREFIX, SUB_PREFIX defaults. I just changed the topic in the web interface to "pumpswitch".

It took me a long time to figure out I needed the "POWER" as the last bit of the state_topic and command_topic in HA to get the talking back and for to work in a way I expected.

Home Assistant configuration.yaml:

switch:

  • platform: mqtt
    name: "Fountain Pump"
    state_topic: "stat/pumpswitch/POWER"
    command_topic: "cmnd/pumpswitch/POWER"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
    My understanding of the above options, Tasmota is not only supposed to save the last state to flash (so as to recover it after a problem?), but also Home Assistant also has retain set, so I should be covered both ways. So even without HA, the Sonoff should come back in the state it left. But that does not happen.

I found that if I used the console and send "cmnd/sonoff/PowerRetain on" then on restart, it would come back in the state it was before the reset. Can this be set in user.config.h somehow as an option? If it is already there, please point it out to me. This is the preferred setting for me, not something I should have to enter on the console command of the web interface each time I update the firmware.

Most helpful comment

Oh nevermind, I figured it out, there were other retained message in cmnd/# and when the lights received any configuration it turns on, so you can't really use retain flag in HASS since you'll be turning the lights on every time they restart.

All 33 comments

read the wiki page on poweronstate, especially look at the mqtt retain section.

that retain option causes so much confusion I wish it wasn't available

Thank your for the reply. I have looked it over and tried what I can. Please take a look at this one minute video. It shows clearly setting the device OFF, it shows OFF retain in the console, it is restarted and it goes on after ward with retain ON in the console.
https://www.dropbox.com/s/n3l0o9e990u2m8j/final.wmv?dl=0

enabled detailed debugging and you will see that the device is getting a command
to turn it on.

go through the steps on that page to see what's retained by the mqtt server and
look at eliminating it (and then disable the retain flag on the firmware)

turn on 'more debugging' and you will see that it's receiving a command telling
it to turn on.

then red the poweronstate page of the wiki and see how this command can be saved
and sent by the mqtt server, and how to disable it.

It looks like the device is restarting with the last state published from Home Assistant. If I turn off the switch with Home Assistant and just restart the device through its web interface, it restarts to an OFF state. If I turn it on in Home Assistant, then turn it off in the web interface before restarting, it will resume in the ON state. It is as if the web interface commands is not updating the state.

@JSCSJSCS

yes, you have set things up so that you have told the mqtt server to remember the last command that it saw, and send that to the tasmota device when it connects after being disconnected.

If you would configure the log to 'more debugging' you would see in the log that it powers up, implements the poweronsave result, then connects to mqtt and is issued a command telling to to switch on.

This is well documented on that wiki page, please read it!!!

Thank you for your patience @davidelang. I have looked over that page many times. I only post after I am at a loss.
I am still at default:
PowerOnState | 3 | (default) Turn relay(s) on as last saved

I am not being clear because I am new to this system. It looks like the Tasmota web interface is not correctly setting the last state.

I would have thought that if I used the web interface to turn off the device, it would update the last know state to OFF and with the PowerOnState set to 3, it would go retrieve the state it should have updated and do the right thing when it came back. Shouldn't the last command the broker saw was Tasmota's web interface saying it turned OFF before the restart?

@JSCSJSCS:

power state ON after restart is cause by this line in HA

retain: true

Change it to retain: false. You will have correct power state but this will have one negative side effect. When you restart HA, your switch will show OFF even device will be ON. Because HA after restart didn't receive "stat/pumpswitch/POWER"

you can solve the problem of not knowing the state on poweron by having your
home automation watch for tele/ as well as stat/ messages (I don't know how to
do this on HA, I did it on openhab)

just turning retain off won't fully solve the problem. It will stop tasmota from
sending new status to the mqtt server, but the existing command that the mqtt
server has for that device is still stored and will still be issued. you have to
follow the steps on
https://github.com/arendst/Sonoff-Tasmota/wiki/PowerOnState-Configuration in the
second section (side effect with mqtt messages) to clear this.

@davidelang You have been very patient and I appreciate that. Here is where I am at in my understanding and testing WRT Sonoff Tasmota and MQTT:

1.) PowerOnState setting is for use with the Tasmota web app. It works as expected.
2.) PowerRetain setting is in user.config.h is for use when MQTT is defined. It sets the retain flag on topics it publishes to. It works as expected.
3.) Per the link you mentioned:

The stored/retained MQTT message will always override the PowerOnState!!!

Also, when MQTT is defined:

4.) The Sonoff web app publishes Toggle button presses to stat/topic/POWER
5.) The Sonoff web app DOES NOT publish to cmnd/topic/power to update last known state when you press the Toggle button.
6.) PowerRetain setting is for use when MQTT is defined, will retain published states, but in the case of Sonoff web app, that is to stat/topic/POWER, not cmnd/topic/POWER.
7.) When the Sonoff device restarts and MQTT is defined, it appears to check cmnd/topic/power for the state and will always set its state to the one retained in the broker at cmnd/topic/power, a topic it NEVER publishes to.

So:

If you use the Sonoff web app and press the toggle button, it physically turn the switch ON or OFF and if MQTT is enabled, it will tell all the other subscribers to stat/topic/POWER about it so they will have the last state. However, if you reset the Sonoff, it looks to cmnd/topic/POWER not stat/topic/POWER, so after restart and reconnecting to MQTT, it will get the last state that some other publisher put in cmnd/topic/POWER.

If MQTT is enabled, the Sonoff Tasmota firmware should either look to stat/topic/POWER for its initial state, or should publish to cmnd/topic/POWER with each press of the web app Toggle button. Then if it restarts, it will behave more as one would expect.

The solution I would like to see is for Tasmota to check to see if MQTT is defined and if so, when using the web app interface, to publish to cmnd/topic/POWER when the Toggle button is pressed as well as it's current publishing to stat/topic/POWER (as a response to a publish on that topic) which Home Assistant and other subscribers use to update their interfaces. That way, it (and every other device that asks) will get the correct current state.

ps: I would also like to see QOS settings allowed for both subscribing to and publishing topics, but one thing at a time. :)

having the device publish to cmnd/ is a problem, as it will then see that
message arrive as if it was sent by someone else.

mqtt retain only works well if you never use the web page, and never use the
local button, and only control the device via mqtt.

since almost nobody using the tasmota firmware is going to be using their
devices in this mqtt-only mode, the retain flag should be turned off. You can
implement this retain type functionality in your home automation software
(watching for stat/ and tele/ messages and issuing commands to force a desired
state if the device reports an incorrect state)

@davidelang

"mqtt retain only works well if you never use the web page, and never use the
local button, and only control the device via mqtt."

Agreed.

"since almost nobody using the tasmota firmware is going to be using their
devices in this mqtt-only mode, the retain flag should be turned off."

This does not help the restart problem since regardless of retain setting, Tasmota looks to cmnd for last known state and not stat; the last setting it published. Why not my other suggestion to have Tasmota look to stat instead of cmnd on restart? My devices are being unplugged and moved around. I am not smart enough to get my home automation software to do what you suggest. Home Assistant MQTT switches publish to cmnd and subscribe to stat so they are always up to date WRT state. Tasmota publishes to stat but restarts looking to cmnd, so it can get out of sync with Home Assistant.

I do so much appreciate your help. I learned so much about how Tasmota works with MQTT.

On Wed, 16 Aug 2017, JSCSJSCS wrote:

"since almost nobody using the tasmota firmware is going to be using their
devices in this mqtt-only mode, the retain flag should be turned off."

This does not help the restart problem since regardless of retain setting,
Tasmota looks to cmnd for last known state and not stat;

This is incorrect, Tasmota looks at the poweronstate setting and if it's
enabled, looks at the record of the last state it was in and sets itself
accordingly.

It then connects to the MQTT server, and if the MQTT server has been instructed
to retain messages, that MQTT server then issues the last message(s) it
retained.

If the retain flag was never set, then the MQTT server has nothing to send and
nothing overrides what tasmota did at startup.

If the retain flag was set at one point in the past, then the MQTT server has a
message to send, and it will send it even if new messages have gone by that
don't have the retain flag set. You have to explicitly clear the retained
messages (or switch to a different device id that has never had one set.

Tasmota never goes looking for messages of any type, it just listens for (and
tells the MQTT server it is interested in) cmnd/ messages and outputs stat/ and
tele/ messages

you can solve the problem of not knowing the state on poweron by having your home automation watch for tele/ as well as stat/ messages (I don't know how to do this on HA, I did it on openhab)

This is not solution.

  • HA allows to subscribe only one topic
  • tele message depends on time period. For devices like switch, which doesn't measure anythink has no sense to send tele data. And when they send and period will be e.g. 5 minutes, it will take up to 5 minutes than HA after restart receive next tele message to update status of switch

From other hand, advantage of retain flag is exactly for this case. Device which collect data from different sources and show them can get correct status after start immediately.

Perhaps it's time to move on and select a proper Home Automation tool (not being HA) ...

well, it seems as if using the retain flag is incompatible with switching the
device via any method other than mqtt.

so consider the advantages and disadvantages of the retain flag, make your
choice, and live with the resulting limitations.

@arendst That is not very helpful. You write some killer code, but I have a use case that causes me issues that I thought could be easily taken into account by the smart people behind Tasmota, and in my effort to resolve it I am insulted by it's author? I'm not sure a "proper" home automation system would solve it. It doesn't bother you so the solution is "if it hurts, don't do it". Incredible.

@davidelang You have been very kind and helpful. I very much appreciate it.

I have the same issue using Wemos D1-mini and Openhab - Mqqt (Mosquitto) and the problem is anoying it openens garage randomly even if it gets a network glitch, restart, mqqt fail or connection loss. all the same restarts and blinks.

I had this same problem. Changing the retain flag was only part of the solution.
For me I had to restart the mosquitto broker service so it no longer published the cmnd that cycled the relay.
A test to see where the problem is....stop the mosquitto broker service and then restart the sonoff/tasmota. If it no longer cycles the relay, then the problem is not with the sonoff/tasmota

if you look at the poweronstate/retain wiki page, it tells you how to see what
messages the MQTT broker is retaining, and how to clear them.

Thanks for this diskussion. It was very helpful to understand what I searched for. :+1:

I'm on the same boat, the B1 works fine without MQTT broker, but when I connect to mosquitto the light turns blue everytime it restarts/powers on. I have set PowerOnState to 3, PowerRetain to 0, and retain: false in HASS configuration. What am I doing wrong? Also I had the retained message in mqtt broker deleted by following https://github.com/arendst/Sonoff-Tasmota/wiki/PowerOnState-Configuration now there is nothing retained in cmnd/+/POWER

16:26:19 MQT: Attempting connection...
16:26:19 MQT: Connected
16:26:19 MQT: tele/sonoff_b1_f/LWT = Online (retained)
16:26:19 MQT: cmnd/sonoff_b1_f/POWER =
16:26:19 MQT: Subscribe to cmnd/sonoff_b1_f/#
16:26:19 MQT: Subscribe to cmnd/sonoff_b1/#
16:26:19 MQT: Subscribe to cmnd/DVES_B1_5/#
16:26:19 MQT: tele/sonoff_b1_f/INFO1 = {"Module":"Sonoff B1","Version":"5.12.0","FallbackTopic":"DVES_B1_5","GroupTopic":"sonoff_b1"}
16:26:19 MQT: tele/sonoff_b1_f/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff_b1_f-3655","IPAddress":"192.168.1.9"}
16:26:19 MQT: tele/sonoff_b1_f/INFO3 = {"RestartReason":"Software/System restart"}
16:26:19 MQT: homeassistant/light/sonoff_b1_f/config = (retained)
16:26:19 RSL: Received Topic cmnd/sonoff_b1_f/DIMMER, Data Size 3, Data 100
16:26:19 RSL: Group 1, Index 1, Command DIMMER, Data 100
16:26:19 MQT: stat/sonoff_b1_f/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FFFFFF0000","CT":499}
16:26:19 RSL: Received Topic cmnd/sonoff_b1_f/CT, Data Size 3, Data 250
16:26:19 RSL: Group 1, Index 1, Command CT, Data 250
16:26:19 MQT: stat/sonoff_b1_f/RESULT = {"POWER":"ON","Dimmer":100,"Color":"000000B747","CT":250}
16:26:19 RSL: Received Topic cmnd/sonoff_b1_f/COLOR, Data Size 10, Data FFFFFF0000
16:26:19 RSL: Group 1, Index 1, Command COLOR, Data FFFFFF0000
16:26:19 MQT: stat/sonoff_b1_f/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FFFFFF0000","CT":499}
16:26:19 HTP: Console
16:26:20 MQT: stat/sonoff_b1_f/RESULT = {"POWER":"ON"}
16:26:20 MQT: stat/sonoff_b1_f/POWER = ON

Oh nevermind, I figured it out, there were other retained message in cmnd/# and when the lights received any configuration it turns on, so you can't really use retain flag in HASS since you'll be turning the lights on every time they restart.

Can you please explain how you solve it? I have the same issue

Can you please explain how you solve it? I have the same issue

Which issue do you have? Can you paste the console log after the tasmota restart?

If you have the same issue with me (unwanted MQTT commands sent when restart), then you probably have retain flag on and have tested the mqtt command using mqtt publish at some point. This means mqtt server has these commands stored so there are 2 ways to fix this. Either by overwrite these saved commands (need retain flag enabled) or by deleting the commands completely (and turn retain off).

How do i remove the retain flags? My lamp turns blue every time the power is off/on. I am using a sonoff B1 with tasmota

Thank you again

Without the console logs I can only guess the issue here which might not solve your issue but here we go.

Basically the issue is normally the retain flag so to remove it you need to install mosquitto client on your pc. Then run "mosquitto_sub -h -p 1883 -u -P -d -t cmnd/+" and you should see something like:

Client mosqsub/3795-raspberryp received PUBLISH (d0, q0, r1, m0, 'cmnd/sonoff_b1/POWER', ... (1 bytes))
ON

Client mosqsub/3795-raspberryp received PUBLISH (d0, q0, r1, m0, 'cmnd/sonoff_b1/CT', ... (1 bytes))
250

You can do 2 things to fix this, either remove all retained messages (and stop change retain flag in HASS to false) using the below command or reorder the retained command to make POWER the last command sent.

"mosquitto_pub -h -p 1883 -u -P -d -n -r -t cmnd//POWER"

repeat for all topics that belongs to your B1 (for example /CT and /COLOR)

For some reason github doesn't allow me to use < username > and < password > so for the commands, -u then put your username after and for -P put your password after. You don't have to put anything after -d, -n and -r.

tele/Kitchen_Lamp/LWT Online
cmnd/Kitchen_Lamp/POWER (null)
stat/Kitchen_Lamp/RESULT {"POWER":"OFF"}
stat/Kitchen_Lamp/POWER OFF
tele/Kitchen_Lamp/INFO1 {"Module":"Sonoff B1","Version":"5.14.0","FallbackTopic":"DVES_XXXXXX","GroupTopic":"sonoffs"}
tele/Kitchen_Lamp/INFO2 {"WebServerMode":"Admin","Hostname":"Kitchen_Lamp-xxxx","IPAddress":"192.168.XX.XX"}
tele/Kitchen_Lamp/INFO3 {"RestartReason":"Power on"}
stat/Kitchen_Lamp/RESULT {"POWER":"ON","Dimmer":100,"Color":"0000007D81","HSBColor":"0,0,0","Channel":[0,0,0,49,51],"CT":329}
stat/Kitchen_Lamp/RESULT {"Dimmer":100}

tele/Living_Room_Lamp/LWT Online
cmnd/Living_Room_Lamp/POWER (null)
stat/Living_Room_Lamp/RESULT {"POWER":"ON"}
stat/Living_Room_Lamp/POWER ON
tele/Living_Room_Lamp/INFO1 {"Module":"Sonoff B1","Version":"5.14.0","FallbackTopic":"DVES_XXXXXX","GroupTopic":"sonoffs"}
tele/Living_Room_Lamp/INFO2 {"WebServerMode":"Admin","Hostname":"Living_Room_Lamp-XXXX","IPAddress":"192.168.XX.XX"}
tele/Living_Room_Lamp/INFO3 {"RestartReason":"Power on"}
stat/Living_Room_Lamp/RESULT {"Dimmer":100}
stat/Living_Room_Lamp/RESULT {"POWER":"ON","Dimmer":100,"Color":"0,0,255,0,0","HSBColor":"240,100,100","Channel":[0,0,100,0,0],"CT":499}

tele/Living_Room_Lamp/STATE {"Time":"2018-06-28T11:35:03","Uptime":"0T00:00:13","Vcc":3.339,"POWER":"ON","Dimmer":100,"Color":"0,0,255,0,0","HSBColor":"240,100,100","Channel":[0,0,100,0,0],"CT":
499,"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"XXXXXXXXX","RSSI":100,"APMac":"XX:XX:XX:XX:XX:XX"}}

These are the logs file from two B1 lamps. i have 5 of them and only the one turn blue after power on/off.

Ok for your Kitchen_Lamp the issue is that it is receiving "dimmer 100" command after the "power off" command so after the dimmer is set the B1 will turn itself on.

And for your Living Room Lamp, it receives color command after turning on so that's why it turns blue.

To confirm these, you need to use the mosquitto_sub executable to probe the retained messages in your MQTT server. Run this command and post the result:

"mosquitto_sub -h -p 1883 -u < username> -P < password> -d -t cmnd/Living_Room_Lamp/+"

➜ ~ mosquitto_sub -h 192.168.XX.XX -u xxxxxxxx -P xxxxxxxxxxxx -d -t cmnd/Living_Room_Lamp/+
Client mosqsub|872-xxxxxxxx-te sending CONNECT
Client mosqsub|872-xxxxxxxx-te received CONNACK
Client mosqsub|872-xxxxxxxxx-te sending SUBSCRIBE (Mid: 1, Topic: cmnd/Living_Room_Lamp/+, QoS: 0)
Client mosqsub|872-xxxxxxxxxx-te received SUBACK
Subscribed (mid: 1): 0
Client mosqsub|872-xxxxxx-te received PUBLISH (d0, q0, r1, m0, 'cmnd/Living_Room_Lamp/power', ... (2 bytes))
ON
Client mosqsub|872-xxxxxxxxx-te received PUBLISH (d0, q0, r1, m0, 'cmnd/Living_Room_Lamp/dimmer', ... (3 bytes))
255
Client mosqsub|872-xxxxxxxxxxx-te received PUBLISH (d0, q0, r1, m0, 'cmnd/Living_Room_Lamp/color', ... (7 bytes))
0,0,255

OK now you have to choose whether you want to keep using this retain function, this is good if you have power outage a lot, once the B1s come back online it will go to the last state it was set. But if you normally turn the B1s off and on using the physical switch then this doesn't work so you need to turn retain flag off.

To clear these messages do the following commands:

"mosquitto_pub -h -p 1883 -u < username> -P < password> -d -n -r -t cmnd/Living_Room_Lamp/power"

"mosquitto_pub -h -p 1883 -u < username> -P < password> -d -n -r -t cmnd/Living_Room_Lamp/dimmer"

"mosquitto_pub -h -p 1883 -u < username> -P < password> -d -n -r -t cmnd/Living_Room_Lamp/color"

Once you have done, disconnect the mosquitto_sub and reconnect using the same command, you should have no retain messages left.

This worked like a charm! Thank you for saving the day

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Ndrinta picture Ndrinta  Â·  3Comments

renne picture renne  Â·  3Comments

kckepz picture kckepz  Â·  3Comments

esp32x picture esp32x  Â·  3Comments

JoergZ2 picture JoergZ2  Â·  3Comments