Is it possible that with WifiConfig set to 0 and the Wifi Access Point going down, bootloop detection would be triggered and everything reset to Sonoff Basic?

[badabing2005]

ISSUE DESCRIPTION - TROUBLESHOOTING

Is it possible that with WifiConfig set to 0 and the Wifi Access Point going down, bootloop detection would be triggered and everything reset to Sonoff Basic?

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
• Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
• Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers)
• Searched the problem in the chat (https://discord.gg/Ks2Kzd4)
• Device used (i.e. Sonoff Basic) : many different types
• Tasmota binary firmware version number used : release 6.5.0
• Development IDE - Compiler / Upload tools used : release bin
• Provide the output of command status 0 :

DETAILS

Originally reported here

All my Tasmota devices reverted to Sonoff Basic

Hi,

All my devices are on Sonoff 6.5.0, all kinds of different module types from Sonoff Basic all the way to custom modules.

I was playing with my Unifi AP and it got disrupted for a while, afterwards most of my devices (majority, perhaps with the exception of 2 or 3) had reverted to Module type Sonoff Basic

I didn't realize this at first, but then I opened the fridge and there was no power, (the fridge is attached to Teckin power monitoring smart plug (Module type: Teckin US 59)
At first I thought the PowerOnState 1 hadn't kicked it, so I tried to turn it on through HA, no luck, I tried to turn it on through Tasmota UI, still no go, even the power button on the device didn't work.

Checked the Freezer, the other fridge, wine fridge ...
All had the same issue
Panicked and to avoid ruining the food, I unplugged my devices.

Then started investigating what was the problem only to realize that the module type had reverted to Sonoff basic, corrected the module type and the devices started working as before.

This is the first time that has ever happened to me, and I have many devices and been using Tasmota for years.

It can't be a coincidence that this happened, something in the code flow (a bug? or a feature?) must have caused this.

Anyone has any clues? how can I avoid this? can't afford connecting essential appliances on these smart devices without assuring that this won't happen again.

Thanks

That's when I learned about the bootloop detection

Thank you Michael and Phil for your replies.
I think what Michael describes is what might have happened to me, the big question is why would re-provisioning the Unifi or restarting it cause bootloops.
Certainly looking at this thread #5054 it's obvious that it's put in place as a safety measure, and mostly people running into issues with this safety mechanism are folks who have flickering AC, but AP going up and down causing this?

Could setting WifiConfig option to 0 cause this? I guess if the restart is under 10 seconds and the code considers it a bootloop it could.
Anyone knows what is the restart time with WifiConfig 0?
Many of my devices were set to WifiConfig 0, but not all, only one of the Teckin smart switches survived the ordeal (and couple of non Teckins) and that had wificonfig set to 4

It looks like SetOption 36 can disable the feature, but I prefer lowering the threshold from 10 seconds to perhaps 1s and increasing the counter to 200.
I see no SetOption to change the BOOT_LOOP_TIME I guess I'd have to customize it with user_config_override.h

Phil, why would MQTT not being available cause this? that would be very bad,
MQTT could go down for various reasons, and unlike a bootloop it's much more likely that MQTT server is down, and some of those could be totally out of my control, relying on batch scripts to disable / enable mqtt would be unreliable.

It is also worth to note that one of my devices was actually Sonoff Basic, and it had additionally set GPIO14 to switch 1
that setting was lost which I guess was expected to happen at 4th restart.

Many thanks
BB

Then I inquired about it in here which is a relevant ticket, but I guess it didn't get noticed because it's a closed issue.

I'm reporting in here in case WifiConfig being set to 0 triggers the bootloop detection (which would be undesired/bug).

Thanks
BB

[ascillato]

Hi,

The reboot time for wificonfig 0 is 20 seconds and the bootloop protection is 10 seconds.

Anyway, I tested your setup and the device just reboots as expected while there is no AP (using wificonfig 0). After several minutes of rebooting, it still keeps the config.

So, seems that your issue was a problem with the power and not with the wificonfig parameter. May be you suffered for a power glitch at the same time you were testing with your wifi.

[badabing2005]

Thanks @ascillato for a quick reply.
Good to know that WifiConfig cannot be the culprit.

I doubt that I suffered power issues, as my UPS data does not show any power issues during that period.
Furthermore it did happen one other time again, and again the only common denominator was Unifi AP was being reprovisioned or rebooted.

Pretty coincidental that most Tasmota devices exhibited the same problem.

Unfortunately with no further data that can isolate the issue, reluctantly I have kept all my essential appliances of Tasmosta, I'll reduce the timeout and test it out before using them again.

Thanks again
BB

[ascillato]

Hi,

You can config the bootloop behaviour using SetOption36 (see wiki)
If you didn't modify it, but you flash your devices without erasing first, sometimes, wrong data is left on the flash (especially on the SDK part that controls the wifi radio) producing weird behaviours.

It is recommended to follow the flashing procedure explained in the wiki so as to avoid some weird issues.

I keep testing this, and I couldn't make it fail. Sorry. That is why, I suspect of a power glitch or a problem in the flashing.

[badabing2005]

Thanks @ascillato

I do flash properly when possible, unfortunately for Teckin US 59s, I had to use Tuya-Convert as it's not practical to do so cleanly without damaging the plugs.

I have already looked at SetOption36 but I think it doesn't support changing BOOT_LOOP_TIME value.
Thanks for all your assistance.

BB