PowerOnState is not obeyed

[niklasfink]

Hi, I'm using a Sonoff T1 and am noticing a sudden power toggle during day or night, without interacting with the device. Upon further research, I found out that after the device reboots, it turns power ON, even though it was OFF before rebooting.

I played around with the settings a bit, but I can't figure out why it is doing that. The specific settings are:

23:32:53 MQT: stat/sonoff-light2/STATUS = {"Status":{"Module":29,"FriendlyName":"Sonoff","Topic":"sonoff-light2","ButtonTopic":"0","Power":2,"PowerOnState":0,"LedState":1,"SaveData":1,"SaveState":0,"ButtonRetain":0,"PowerRetain":0}}

This is how the log looks like when rebooting and then switching the light ON, even though it was OFF:

ESP-HTP: Web server active on sonoff-light2-5465.local with IP address 192.168.120.80
ESP-MQT: Attempting connection...
ESP-MQT: Connected
ESP-MQT: tele/sonoff-light2/LWT = Online (retained)
ESP-MQT: cmnd/sonoff-light2/POWER = 
ESP-MQT: Subscribe to cmnd/sonoff-light2/#
ESP-MQT: Subscribe to cmnd/sonoffs/#
ESP-MQT: Subscribe to cmnd/sonoff-light2/#
ESP-MQT: tele/sonoff-light2/INFO1 = {"Module":"Sonoff T1 2CH","Version":"5.11.1d","FallbackTopic":"sonoff-light2","GroupTopic":"sonoffs"}
ESP-MQT: tele/sonoff-light2/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff-light2-5465","IPAddress":"192.168.120.80"}
ESP-MQT: tele/sonoff-light2/INFO3 = {"RestartReason":"Software/System restart"}
ESP-RSL: Received Topic cmnd/sonoff-light2/POWER1, Data Size 3, Data OFF
ESP-RSL: Group 0, Index 1, Command POWER, Data OFF
ESP-MQT: stat/sonoff-light2/RESULT = {"POWER1":"OFF"}
ESP-MQT: stat/sonoff-light2/POWER1 = OFF
ESP-RSL: Received Topic cmnd/sonoff-light2/POWER2, Data Size 2, Data ON
ESP-RSL: Group 0, Index 2, Command POWER, Data ON
ESP-MQT: stat/sonoff-light2/RESULT = {"POWER2":"ON"}
ESP-RSL: Received Topic cmnd/sonoff-light2/POWER1, Data Size 3, Data OFF
ESP-RSL: Received Topic cmnd/sonoff-light2/POWER2, Data Size 2, Data ON
ESP-CFG: Saved to flash at F7, Count 1717, Bytes 1648
ESP-MQT: stat/sonoff-light2/RESULT = {"POWER1":"OFF"}
ESP-MQT: stat/sonoff-light2/POWER1 = OFF
ESP-MQT: stat/sonoff-light2/RESULT = {"POWER2":"ON"}
ESP-MQT: stat/sonoff-light2/POWER2 = ON
ESP-APP: (UTC) Sun Mar 11 21:16:19 2018
ESP-APP: (DST) Sun Mar 25 02:00:00 2018
ESP-APP: (STD) Sun Oct 28 03:00:00 2018
ESP-MQT: tele/sonoff-light2/STATE = {"Time":"2018-03-11T23:16:25","Uptime":0,"Vcc":3.520,"POWER1":"OFF","POWER2":"ON","Wifi":{"AP":2,"SSId":"WIFI","RSSI":54,"APMac":"--removed--"}}

I'm using Mosca as my MQTT broker. I would assume there is a power ON message saved on the broker which then gets read by the Sonoff, even though I set the settings to not read it (PowerRetain 0).

Any help appreciated. :-)

[arendst]

Check your mqtt server for retained messages as tasmota is never requesting any status from the mqtt server.

In case off T1 also clear the possible rf code it might have learned while you pressed the key too long. Again, not tasmota related.

[JuliusLedoux]

I have a similar issue I am using a Sonoff SV with a temperature sensor, a reed switch and home assistant to control my garage door.
I have set switchmode2 1 (Set switch mode to FOLLOW (0 = Off, 1 = On)). In home assistant the icons show properly (if the door is closed, it shows). I have an automation that alerts me via google assistant when the door is open. It works, but when the door closes it tells me again that the door is open (even though it is closed and the icon shows it). And now the really annoying part: for some reason that I cannot explain, my garage door it is randomly opening. I have done the following to prevent that from happening: I set PowerOnState 0 to be sure that the relay is off when the device reboots or loses its connection with the network. I also changed wificonfig to 4 (Disable wifi config but retry other AP without restart). So far it works for some time but suddenly my door opens, again with no particular pattern.
I am also including a detailed log at the moment that the issue occurs:
11:33:04 WIF: Connected
11:33:20 MQT: Attempting connection...
11:33:25 MQT: Connect failed to 192.168.1.80:1883, rc -2. Retry in 10 sec
11:33:29 WIF: Checking connection...
11:33:29 WIF: Connected
11:33:36 MQT: Attempting connection...
11:33:41 MQT: Connect failed to 192.168.1.80:1883, rc -2. Retry in 10 sec
11:33:51 MQT: Attempting connection...
11:33:56 MQT: Connect failed to 192.168.1.80:1883, rc -2. Retry in 10 sec
11:33:59 WIF: Checking connection...
11:33:59 WIF: Connected
11:34:07 MQT: Attempting connection...
11:34:12 MQT: Connect failed to 192.168.1.80:1883, rc -2. Retry in 10 sec
11:34:14 DHT: Received 02, AE, 00, 36, E6 =? E6
11:34:18 DHT: Received 02, AE, 00, 36, E6 =? E6
11:34:21 DHT: Received 02, AE, 00, 36, E6 =? E6
11:34:23 MQT: Attempting connection...
11:34:23 MQT: Connected
11:34:23 MQT: tele/garage/LWT = Online (retained)
11:34:23 MQT: cmnd/garage/POWER =
11:34:23 MQT: Subscribe to cmnd/garage/#
11:34:23 MQT: Subscribe to cmnd/sonoffs/#
11:34:23 MQT: Subscribe to cmnd/DVES_95A637/#
11:34:24 RSL: Received Topic cmnd/garage/power, Data Size 4, Data STOP
11:34:24 RSL: Group 0, Index 1, Command POWER, Data STOP
11:34:24 MQT: stat/garage/RESULT = {"POWER":"OFF"}
11:34:24 MQT: stat/garage/POWER = OFF
11:34:24 RSL: Received Topic cmnd/garage/POWER, Data Size 2, Data ON
11:34:24 RSL: Group 0, Index 1, Command POWER, Data ON
11:34:24 MQT: stat/garage/RESULT = {"POWER":"ON"}
11:34:24 MQT: stat/garage/POWER = ON
11:34:24 DHT: Received 02, AE, 00, 36, E6 =? E6
11:34:24 MQT: cmnd/2/POWER2 = ON
11:34:24 MQT: cmnd/2/POWER2 = OFF
11:34:24 WIF: Checking connection...
11:34:24 WIF: Connected
11:34:24 MQT: cmnd/2/POWER2 = ON
11:34:25 MQT: stat/garage/RESULT = {"POWER":"OFF"}
11:34:25 MQT: stat/garage/POWER = OFF

Any help is highly appreciated!

[curzon01]

@jnherm All that is configurable and user related, not Tasmota related. For example two mistakes can be made here by user (not Tasmota):

• User configure PowerRetain ON and is wondering why sometimes devices are switched on. In that case an involved third system (HASS) system is doing the translation based on the delivered Tasmota stat messages from broker, which is retain.
  In that case don't use Retain at all and the world is perfect - and - do not forget to delete the previously misleading retained message from your broker.
• Second the user configure same topics for status and commands. This mistake leads also in unwanted results. As Theo already tried to explain to you, Tasmota never publish command message, if retained or not, it only publish status retain (if configure as *Retain) message on status topic. But if the topics are configured (by user) to the same, sh... happens.
  Solution: leave topics as designed - different

we are just using MQTT broker that only follow MQTT protocol?

A car which is steered to the wall is not bad designed - only the parameter is wrong selected - the direction.
The protocol has nothing to do with the mistakes happend here, only the logic which uses the MQTT protocol.

One of the reason I think is when Tasmota subscribed a Topic from the broker Tasmota sets Retained flag.

Subscription can not have retain flags, only the result of a subscription is retain by a previously publish command which had set the retain flag.
And because Tasmota is always sending results to stat topics (e.g. stat/mydevice/POWER) only the stat message can have set a retain flag from Tasmota. But the command to power a device is subscribed on cmnd topic (e.g. cmnd/mydevice/POWER). This is different to the status message may be set from Tasmota having retain.

So in that case you (as user) have done the mistake as explained above: Ether you has set same topic for status and cmnd or a thirds system sets the retain flag for cmnd to Tasmota.

[niklasfink]

@curzon01 but neither of those two mistakes is made:

• "PowerRetain":0 is set to OFF and therefore shouldn't save any state retained
• cmnd and status are different topics: MQTT Full Topic: cmnd/sonoff-light2/

@arendst how can I clear the rf code? I can't find that in the wiki.

[curzon01]

@niklasfink - you have forgot the third system and you may have skipped my sentence

• and - do not forget to delete the previously misleading retained message from your broker.

Retained message are stored in broker until they are explicit delete. This can not be done by simply send a non-retain message over the retained. Example

• Send retained e.g. topic 'test' with payload 'ON' to a broker
• Start subscription to topic 'test'
• retrieve message from topic 'test' - you will get 'ON'
• Send non-retained topic 'test' with payload 'OFF' to a broker
• You immediately retreive the message from topic 'test' - you will get 'OFF'
• Stop subscribtion
• Restart subscribtion - you will get 'ON' (!)

To delete a retained message you have to send a retained null message to broker. If the HASS system does not make that, the wrong retained message will stay forever within broker.

THIS will often make the wrong retain cmnd MQTT message which is then subscribed by Tasmota.

[arendst]

Clearing RF codes is documented by iTead as it is not controlled by Tasmota so you should be able to find RF specific information on their site.

[arendst]

@jnherm yes you're wrong (again). See the answer #2080

[JuliusLedoux]

I want to report back on this issue. After I deleted any retained message in my broker by sending a null message with the retain option on using Node-Red, my system has been stable for the last 24 hours. I was checking the logs and at the moment that the system reconnects to MQTT, my sonoff does not get the ON state as it used too. So far so good, I will keep monitoring and I will report back.

[niklasfink]

How are these retained messages created? I don't think I ever had the PowerRetain set to ON, so it should've never retained any message. How can I prohibit this from happening again?

Also, how do I delete retained messages? :-)

[JuliusLedoux]

The first time that I used the "Tasmotized" Sonoff device in Home Assistant I copied my regular settings for my MQTT garage controller and modified just the topics, but kept the other settings and for that reason I ended with the retain setting on.
To "delete" retained messages, you can use any MQTT client, if you have an android phone you can use MQTT dashboard (I used Node-Red). Basically you select the topic that it is causing you grief, in my case it was: cmnd/garage/POWER, and set the retain option to true (depending on your MQTT client) and public a null value. After that when your Home automation software connects to the MQTT it will get a null value rather than ON.
Hope that helps!

[curzon01]

@niklasfink PowerRetain sets default to 0 (OFF). If you compile your own firmware, please check #define MQTT_POWER_RETAIN in user_config.h - possibly you or someone else has changed it.

Deleting a retained msg depends environment you are using - As @JuliusLedoux aleady explained, one possible way to delete a retained topic is

• publishing a retained null payload using a MQTT client.

My favorite client on Linux is MQTT.fx. Clients overview can be found under The Seven Best MQTT Client Tools.
A good tool for Android is MQTT Snooper, that's a basic app which can also handle subtrees of topics. This tool can also do steps to delete retain payloads with one command.

[M4RiO32s]

Sending null vale is exactly what protocol says about it
You can remove retained messages by publishing a zero length retained
message to the topic you wish to clear. For example, you could do it
with mosquitto_pub as follows:

mosquitto_pub -t -r -n

Quick but a bit dirty way to delete ALL retained messages is to stop broker and delete persistence file,
in my case: sudo service mosquitto stop sudo rm /var/lib/mosquitto/mosquitto.db sudo service mosquitto start. You can check in your mosquitto.conf where your persistence_file is located.