Tasmota: When the power cycles rapidly for a few seconds, TASMOTA on a sonoff basic reverts to default configuration.

[clifforddw]

Describe the bug
When the power cycles rapidly for a few seconds, TASMOTA on a sonoff basic reverts to default configuration.

• [x ] _Searched the problem in issues and in the wiki_
• [ ] _Hardware used_ : Sonoff basic
• [ ] _Development/Compiler/Upload tools used_ : esptool
• [X ] _If a pre-compiled release or development binary was used, which one?_ : TASMOTA 6.3.0 and 6.2.1
• [X ] _You have tried latest release or development binaries?_ :
• [ ] _Provide the output of command_status 0 :

Will update with Status0 tonight

To Reproduce
Flash a Sonoff basic with Tasmota
Configure with either direct WiFi or a Backlog command using termite, tried both.
Connect to mains power, in my case 220v
Validate configuration and WiFi connection.
CYCLE the mains power about 8 times at about 2Hz, in my case I flicked a switch about twice a second for 4 seconds
Turn off for 4 seconds
Turn on again
Tasmota has now returned to is default configuration, like Reset1 or First boot.
I have reproduced on multiple devices with 6.3 and 6.2 firmware.

Expected behavior
Do not expect the config to be lost on a multiple power cycle

Screenshots

Additional context
I discovered this issue while installing 30+ basics into my light switches. The Electrician was cycling the power during the installation and we fond we were losing the configuration of devices we had just set up.

From my research I am guessing there is some timing or corruption of the CFG_HOLDER causing it to default. I wonder if there is something in the startup that causes this if the power is cycled before the startup is complete ?

[arendst]

As designed to solve rapid restarts due to bootloops.

Solution is do not rapidly switch power.

[Geitde]

But this renders several use cases obsolete. Like embed sonoffs into devices, which have power switches.

I have several Sonoff added to existing lamps, so I can "dimm" them by disabling parts or add more light sources to gain light. e.g. over a workbench without installing a new switch for that.

In such case it only needs a child and all such devices in the house is on default all the time.

Loosing the entire config is the worst case scenario.

What about having a config value that can disable this behaviour and break boot loop? It could be auto set before firmware updates.

[clifforddw]

Thanks for the quick feedback @arendst any pointers on how to adjust this if I wanted to compile a version to avoid this ?

[ascillato2]

@clifforddw @Geitde That is a failsafe for booting. If your Sonoff Basic is powered up and you wait 10 seconds before powering off, no configuration losing will happen.

If your Tasmota has a problem with any config that makes it hung, it will disable some configs up to the boot will be normal (normal is more than 10 seconds after power up.)

If you want to avoid the reset configuration, do not power down your sonoff in less than 10 seconds. No need to modify any code.

[ascillato2]

Closing this issue as it has been answered.

Support Information

See Wiki for more information.
See Chat for more user experience.

[clifforddw]

@ascillato2 thanks but I think this is still a scenario that is plausible is especially the one above from @Geitde and the one I experienced in a large installation. Again happy to make some changes if possible.

[ascillato]

Why do you want to take out the power of your smart home devices in less than 10 seconds? That is interpreted as a bootloop error.

If your Tasmota doesn't have power, it can't control anything. Not the actual scope of Tasmota. See Readme.

[clifforddw]

Power fluctuations when the SONOFF's are wired into light sockets very probable where I come form. Secondly I think the bulk installation issue is real. I asked my electrician to install 35 devices I prepared and after he was done all of them had been rest.

I think this woudl be good to be able to override in code or config !

[meingraham]

Perhaps a command to adjust/disable/enable this threshold? This way, when one is in setup/installation mode one can send a command to the device or a bulk publish (e.g., cmnd/sonoffs/...). Or, if power fluctuations are a constant issue, then the device(s) can be configured accordingly for normal operational mode.

[ascillato]

@clifforddw

The bootloop prevention is a feature of Tasmota.

I understand that you don't want it. So, I agree with you in an option in my_user_config.h to be able to disable it.

By default I think it should be enabled. I never had issues in my home with that. Nor installing devices, neither with the power fluctuations. Also, yours is the first issue asking for this.

But anyway, depends on Theo if he agrees to add that or not.

[ascillato]

@meingraham

The bootloop prevention feature has several steps. If Tasmota starts but restarts in less than 10 seconds it will first disable rules. If it restart again and reboot in less than 5 seconds I think, It will disable timers, and so on disabling everything and restarting all config is you have several reboots in less than 2 seconds I think.

So, instead of adjusting the times and the way it works, I think that will be easier and cleaner to just enable or disable this feature. I'm ok with that. What do you think?

[arendst]

It's not only the bootloop prevention but it's simply the corruption of flash due to uncontrolled power off while updating flash. If, after the next restart flash crc is not correct it just loads the default settings.

After every restart the bootcount is written to flash incrementing the flash write slot too.

As with any OS, uncontrolled power cycling can lead to this. Nothing new with Tasmota.

If you do not want a flash write on restart due to bootcount increment comment out the bootcount feature and hope for the best.

[Geitde]

@ascillato2

What about tasmota light bulb devices? AFAIR there are some. Should they be used with a warning on the light switch?

Also it is not as useless as you think to have tasmota devices inside devices that get powered down. I have rooms with four lights, but only one power switch. So I added two Sonoff Basic to two of these lamps, so I can boost light on demand and via Alexa. No additional wireing, no additional light switch needed.

In my Home Cinema I have two ceiling lamps with 3 60cm LED tubes. I installed basics inside the lamps, so I only turn on one tube per lamp using the light switch. When needed e.g. when cleaning the room, I turn on four additional tubes with alexa. Again no light switch needed.

Well, unless some child does not understand that there is a fail safe build in that makes it fail on purpose, when the light switch gets abused.

Once a device is set up properly, the chances of a boot loop are nearly zero. Only a broken flash or so can trigger it. Again wouldn´t a one shot config bit better in this case? It gets set after/before firmware flash and before reboot. Then cleared again after full successful boot (and beeing 1 of course). After that no flashing/reset to defaults takes place as the device has the bit cleared. The bit could be set after changing sensitive changes that may cause reachabiity problem and need an reboot.

[clifforddw]

Hi all,

@ascillato I really like the idea of having it as a switch in my_user_config.h, it think it woudl be a really neat way to solve this. I get that it is not common but my feedback was based on real life in the field deployment and I do wonder if this is not happening more often and people just don't understand what is going on, it took me over a week to reproduce it and figure out what caused the issue. If it only happens every now and again and on one or two devices I woudl have just reconfigured and moved on. Have 35 devices I really needed to get tot he bottom on of this.

@arendst I hear you on the OS side but I guess these are embedded devices and in some cases like this it woudl be really nice to have this level of control.

Lastly I think the idea of having it as a SW that is set for commissioning or certain deployments is a great way to think about it.

[arendst]

To rule out the bootloop feature I suggest you compile a version your own commenting out the feature in file sonoff.ino lines 2646 until 2669

To rule out the flash write corruption on bootcount update I suggest you compile yourself and comment out in file sonoff.ino line 2670.

Happy hunting.

[clifforddw]

Great thanks @arendst is see your comments on line 2646 in the latest code will give it a go and let everyone know. Appreciate the help !

[hhaim]

@arendst what about a way to save 2 flash blocks and mark who is the active. if the active has bad CRC there other be the new active (which is better than the default)

[nonsintetic]

I just had this exact problem happen to a house I installed Sonoff Touch devices to. The area the house is in has rather unstable power, sometimes it drops and comes back only to drop again. Any news on the toggle for this?

[underwoodblog]

Have you tried to ad some big caps between 3,3V and GND?

I've an ESP-01 on my doorbell, powered from the AC-Transformer of the doorbell and I use a 1F Gold-Cap because the voltage drops to nearly 1V, when somebody rings the door.

[hhaim]

I believe that this issue is solved in master. Have you tried?

On Wed, Feb 13, 2019 at 10:47 AM underwood [e-mail] wrote:

Have you tried to ad some big caps between 3,3V and GND?

I've an ESP-01 on my doorbell, powered from the AC-Transformer of the
doorbell and I use a 1F Gold-Cap because the voltage drops to nearly 1V,
when somebody rings the door.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/4342#issuecomment-463110760,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMbjvdklqT_VlxCHgJ0NOp2o9az4umeFks5vM9EegaJpZM4YbM16
.

--
Hanoh
Sent from my iPhone

[cmot-weasel]

Can I re-raise this issue please? Half way through dealing with about 30 devices after storm caused the power to flicker a few times before going out.

Would a greater number of rapid-restarts before resetting the configuration be a better balance point perhaps?

[hhaim]

@cmot-weasel it has been solved long ago.
do this

SetOption36 20

[cmot-weasel]

@cmot-weasel it has been solved long ago.
do this

SetOption36 20

... I'm either an idiot, blind or quite possibly both! Sorry, no idea how I failed to spot that in the docs, classic Layer 8 issue!

Thanks! o/

[sentiment-bot[bot]]

Please be sure to review the code of conduct and be respectful of other users.
Keep in mind, this repository uses the Contributor Covenant.