Wemos loses Modules Configuration after long deepsleep

rayzilt commented 5 years ago

Describe the bug After a deepsleep for 14 hours the Wemos comes back with Module "Sonoff Basic (1)" It was configured as "Generic (18)".

I've setup home-assistant to send an deepsleep 50400 mqtt command for 14 hours, after 13 hours home-assistant sends a deepsleep 0 to keep the Wemos awake. This works great except the Wemos is configured as a "Sonoff Basic (1)" then and therefore loses the GPIO configuration. Before the deepsleep the Module was configured fine.

This does not happen with deepsleep 300 and then keep awake with deepsleep 0.

Not sure, but it seems that other settings are also lost, like Teleperiod.

The Wemos function is to detect rain, this is for the awnings automation. It's not necessary to check for rain in the night.

Connected modules: DHT11: Temperature and Humidity Sensor; YL-38: Rain sensor.

Wemos is battery powered with a solar panel to charge. Battery is full.

[x] Searched the problem in issues and in the wiki
[x] Hardware used : Wemos D1 Mini
[x] Development/Compiler/Upload tools used : Atom / ESPTOOL
[ ] If a pre-compiled release or development binary was used, which one? :
[x] You have tried latest release or development binaries? : 59e5c88fee4536dd7abc7791e70ec5b9d3360e5b

[x] Provide the output of commandstatus 0 :

12:36:26 MQT: raindetector/stat/STATUS = {"Status":{"Module":18,"FriendlyName":["Rain Detector"],"Topic":"raindetector","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[2,2,2,2,2,2,2,2],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
12:36:26 MQT: raindetector/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T00:06:30","StartupUTC":"2019-04-27T10:29:56","Sleep":50,"CfgHolder":4617,"BootCount":6,"SaveCount":18,"SaveAddress":"FA000"}}
12:36:26 MQT: raindetector/stat/STATUS2 = {"StatusFWR":{"Version":"6.5.0.3 stb-1.3(sonoff)","BuildDateTime":"2019-04-26T21:45:52","Boot":31,"Core":"2_4_2","SDK":"2.2.1(cfd48f3)"}}
12:36:26 MQT: raindetector/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["Rayzilt-MGMT",""],"TelePeriod":3600,"Resolution":"558180C0","SetOption":["000A8009","280500000100000000000000000000000000","00000200"]}}
12:36:26 MQT: raindetector/stat/STATUS4 = {"StatusMEM":{"ProgramSize":422,"Free":580,"Heap":27664,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"1640EF","FlashMode":3,"Features":["00000809","00400084","040003A0","21021796","000000C0"]}}
12:36:26 MQT: raindetector/stat/STATUS5 = {"StatusNET":{"Hostname":"raindetector-1430","IPAddress":"192.168.29.104","Gateway":"192.168.29.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.29.254","Mac":"84:0D:8E:8A:85:96","Webserver":2,"WifiConfig":4}}
12:36:26 MQT: raindetector/stat/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.29.22","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_8A8596","MqttUser":"broker","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
12:36:26 MQT: raindetector/stat/STATUS7 = {"StatusTIM":{"UTC":"Sat Apr 27 10:36:26 2019","Local":"Sat Apr 27 12:36:26 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":99}}
12:36:26 MQT: raindetector/stat/STATUS10 = {"StatusSNS":{"Time":"2019-04-27T12:36:26","Switch1":"OFF","DHT11":{"Temperature":16.3,"Humidity":92.0},"TempUnit":"C"}}
12:36:26 MQT: raindetector/stat/STATUS11 = {"StatusSTS":{"Time":"2019-04-27T12:36:26","Uptime":"0T00:06:30","Vcc":3.021,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":20,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Rayzilt-MGMT","BSSId":"F2:9F:C2:F1:BA:F6","Channel":11,"RSSI":40,"LinkCount":1,"Downtime":"0T00:00:05","DeepSleep":0,"Heap":27600}}}

To Reproduce

Configure Wemos to Generic(18) and set GPO functions;
Deepsleep Wemos with deepsleep 50400 and retain flag on;
Set deepsleep 0 and retain flag on;
Wait for device to wake-up;
Wemos is configured as an "Sonoff Basic (1).

Expected behavior Wemos should wake-up with configured settings by user.

Additional context GPIO Configuration: D2 GPIO4 = Switch1 (9) D6 GPIO12 Relay1 = Relay1 (21) D5 GPIIO14 Sensor = DHT11(1) D0 GPIO16 = DeepSleep Switch (156)

The rest is configured ad None (0)

Wemos has been first erase_flash and then programmed with esptool In configuration file my_user_config.h setting MODULE is set to WEMOS

stefanbode commented 5 years ago

Thanks For bringing this up. The limit is 3600 seconds after this time it behave differently. Maybe a bug due to some changes. I will investigate

meingraham commented 5 years ago

Perhaps the boot loop reset logic gets confused with deep sleep?

stefanbode commented 5 years ago

Can you explain what the boot reset logic is? I have never heard this. Something new?

rayzilt commented 5 years ago

I think that meingraham is talking about SetOption36. I have disabled this feature for testing, will let you know.

meingraham commented 5 years ago

Built into Tasmota is logic that resets the module if it goes into repetitive boot loops w/in less than 10 seconds. This has been part of Tasmota for a while. The boot loop reset sequence is now documented... under the SetOption36 entry in the Tasmota wiki. SetOption36 was added to control how many bootloops to allow before beginning the reset mechanism. SetOption36 is a relatively new feature.

Mike

rayzilt commented 5 years ago

Well that works after setting SetOption36 0 :-) The Wemos did not change back to default settings.

Thanks for point that out meingraham.

meingraham commented 5 years ago

@stefanbode - Now the question is... why does returning from deep sleep cause a boot loop... or Tasmota to believe it's in a boot loop?

stefanbode commented 5 years ago

This will need some investigation. Maybe I’m able to avoid this unwanted behavior. The setoption is only a bad workaround. When implemented the deepsleep the boot loop was not there. New feature.

stefanbode commented 5 years ago

Yes as guessed yesterday the new functionality needs additional care during deepsleep. Now it seems to work as far as I can see.

meingraham commented 5 years ago

Stefan,

I did a little more research on the boot loop feature. Detection of boot loops and the resetting of settings was added in 6.1.1.x (Aug.-Nov. 2018). SetOption36 was added in 6.4.1.13 at the end of January 2019.

Is the root cause of this problem that the underlying Tasmota "base" code thinks that the deep sleep is a sign of coming out of a recent boot more than once? Your solution:

RtcReboot.fast_reboot_count = 0;

makes SetOption36 0 the hardcoded setting so that users don't have to be aware of setting the option? Is this setting only "forced" for devices configured to use deep sleep?

I'm sure we agree that deep sleep will not likely be added to "base" Tasmota. However, I wonder if the sensing of boot loops ought to be enhanced in your fork so that deep sleep doesn't get detected as a boot loop. In other words, is "disabling" boot loop detection by hard coding the setting to 0 going to hide some cases where a boot loop is indeed happening for some other reason?

Regards.

Mike

stefanbode commented 5 years ago

Hi Mike, my new deepsleep implementation reset the counter on the intermediate wakeups. Now it works like a charm also with the default settings. I do in the wakeup process that what normally happens after a successful start. resetting the counter. Therefore the small wakeups every hour not counted anymore as invalid starts. The set = 0 is ONLY executed if there is an additional deepsleep required. If there is a normal start I do nothing. If it crashes, then the normal behavior until the total reset will happen.

meingraham commented 5 years ago

Perfect. Thanks for the explanation.

Cheers!

Mike

rayzilt commented 5 years ago

Thank you all for your time :-)

Silvan

stefanbode / Sonoff-Tasmota

Wemos loses Modules Configuration after long deepsleep #142