Closed rayzilt closed 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
Perhaps the boot loop reset logic gets confused with deep sleep?
Can you explain what the boot reset logic is? I have never heard this. Something new?
I think that meingraham is talking about SetOption36. I have disabled this feature for testing, will let you know.
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
Well that works after setting SetOption36 0
:-) The Wemos did not change back to default settings.
Thanks for point that out meingraham.
@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?
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.
Yes as guessed yesterday the new functionality needs additional care during deepsleep. Now it seems to work as far as I can see.
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
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.
Perfect. Thanks for the explanation.
Cheers!
Mike
Thank you all for your time :-)
Silvan
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 adeepsleep 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 withdeepsleep 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.
status 0
:To Reproduce
deepsleep 50400
and retain flag on;deepsleep 0
and retain flag on;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
settingMODULE
is set toWEMOS