configuration settings lost on power outage

[dacorn]

IMPORTANT NOTICE
If you do not complete the template below it is likely that your issue will not be addressed. When providing information about your issue please be as extensive as possible so that it can be solved by as little as possible responses.

Describe the bug
I am located in the Philippines, I have over 40 T1 switches (so far) in my beach house. I live on the beach so we suffer from a lot of power brown outs. I have a solar system, generator and a automatic transfer switch to allow for a full failover scenario. However, there is still a split second where things failover. During this time some of the switches lose their configuration and the wifi light will blink and then switch wifi access point is available, if I connect the switch has gone back to its bare configuration, I then have to restore a back up config file to get the switch back to its configuration.

I have tried the 6 short presses to restart the switch but it doesn't seem to help.

Can you help with what may be wrong? It only happens to 3 or 4 switches every time this happens, it isn't on all switches.

Also, make sure these boxes are checked [x] before submitting your issue - Thank you!

• [x ] Searched the problem in issues and in the wiki
• [x ] Hardware used : Sonoff T1 (1 2 and 3 CH)
• Development/Compiler/Upload tools used :
• Provide the output of commandstatus 0 :

STATUS 0 OUTPUT HERE

To Reproduce
Steps to reproduce the behavior:
On power loss and power on the switch loses configuration.

Expected behavior
A clear and concise description of what you expected to happen.
Switches should restart with last settings and configuration.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

[ascillato]

Hi, that is not a bug. It is a misconfiguration. Please provide all the information in the troubleshooting template in order to have all the information needed for properly help you. Thanks.

[dacorn]

Hi,
Thanks for the response. I am not sure if its a bug or not but I am grateful for your help.
Here is my light.yaml for one switch

CA9 1376 Light Switch - 2 Gang - 192.168.1.170

  - platform: mqtt
    name: "CA9-1"
    command_topic: "cmnd/CA9/power1"
    state_topic: "stat/CA9/POWER1"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: false
 
  - platform: mqtt
    name: "Outdoor Kitchen"
    command_topic: "cmnd/CA9/power2"
    state_topic: "stat/CA9/POWER2"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: false   

01:57:15 MQT: stat/CA9/STATUS = {"Status":{"Module":29,"FriendlyName":["CA9-1","Outdoor Kitchen"],"Topic":"CA9","ButtonTopic":"CA9","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":1}}
01:57:15 MQT: stat/CA9/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://domus1:80/api/arduino/sonoff.ino.bin","RestartReason":"Software/System restart","Uptime":"0T02:17:24","StartupUTC":"2018-10-14T22:39:51","Sleep":0,"BootCount":220,"SaveCount":228,"SaveAddress":"F8000"}}
01:57:15 MQT: stat/CA9/STATUS2 = {"StatusFWR":{"Version":"6.2.1","BuildDateTime":"2018-09-09T16:50:26","Boot":6,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
01:57:15 MQT: stat/CA9/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"domus1","LogPort":514,"SSId":["Turbo","indebuurt2"],"TelePeriod":300,"SetOption":["54000029","55818000","00000001"]}}
01:57:15 MQT: stat/CA9/STATUS4 = {"StatusMEM":{"ProgramSize":471,"Free":532,"Heap":15,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3,"Features":["00000809","0FDAE794","000003A0","23B617CE","00000000"]}}
01:57:15 MQT: stat/CA9/STATUS5 = {"StatusNET":{"Hostname":"CA9-1376","IPAddress":"192.168.1.170","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"84:0D:8E:48:65:60","Webserver":2,"WifiConfig":2}}
01:57:15 MQT: stat/CA9/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.185","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_486560","MqttUser":"casaacorn","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
01:57:15 MQT: stat/CA9/STATUS7 = {"StatusTIM":{"UTC":"Mon Oct 15 00:57:15 2018","Local":"Mon Oct 15 01:57:15 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":1,"Sunrise":"07:10","Sunset":"18:01"}}
01:57:15 MQT: stat/CA9/STATUS10 = {"StatusSNS":{"Time":"2018-10-15T01:57:15"}}
01:57:15 MQT: stat/CA9/STATUS11 = {"StatusSTS":{"Time":"2018-10-15T01:57:15","Uptime":"0T02:17:24","Vcc":3.190,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"Turbo","RSSI":98,"APMac":"FC:EC:DA:3B:66:90"}}}

[Jason2866]

Change WifiConfig to Disable wifi config but retry same AP without restart and flash writes
Command: WifiConfig 5

[ascillato]

@dacorn

Hi, any update on this? I would like to get this resolved if possible. Thanks!

Yes, please follow the instructions from Jason

[ascillato2]

@dacorn

Have you managed to solve your issue?

[digiblur]

Wonder if during the underpowering of the switch is it thinking a button is being held for 40 seconds?

[dacorn]

I don't understand Jason's instructions. Can I get better details?

[dacorn]

Just to be 100% in the console the only change is to WifiConfig 5

Correct?

[ascillato]

@digiblur, that could be the issue

@dacorn, What @Jason2866 said is to go to the Tasmota console and type WifiConfig 5

[dacorn]

Ok done... I just did one switch for now.

I want to understand what this does, so on power loss it will keep the same WifiConfig from prior to the outage?

[ascillato]

Wificonfig 5 will try to reconnect to your wifi router without restarting.

I think there is problem in your connections. As @digiblur said, It seems that when your voltage is low, your devices interpret that as a more than 40 seconds to be pressed your buttons on GPIO0.

A full reset as yours, will only occurs if you send the command reset 1 or if you press GPIO0 for more than 40 seconds.

[dacorn]

Ok I will have to wait for the next brown out to see if this worked.

But to comment on this further, when this happens there is a complete cut in power, this is only for a few seconds when the system cuts over from grid power to generator power, this will also knock off the wifi as in the router will reboot. So when this happens there is multiple things happening. We will make a change so the power is moving from the grid to solar this will help as we should not see any fluctuation when the system goes from grid to generator and the solar will be unaffected. But Wifi will still restart as it is not on solar. (I might change this also).

[ascillato]

Ok, That sounds good.

[ascillato2]

If you experience the issue again, please ask to reopen this issue. Thanks

[henfri]

Change WifiConfig to Disable wifi config but retry same AP without restart and flash writes
Command: WifiConfig 5

Do you suspect that the reboot that ist Part of other WifiConfigs leads -if enough reboots accumulate- to a config reset?

I am asking, as I Had a partial Power loss at Home today and all my Tasmota devices lost their settings.

[ascillato]

See commands SetOption36 and SetOption65 in the docs. Thanks.

[henfri]

Hello,

thank you.
In my case, the device lost power and then possibly the AP was not reachable. Also, multiple (up to 10) power cycles could have happened.

Would Setoption36 explain the reset of the configuration?
Because:

(a restart caused by any exception or watchdog timer)
Here, I did not have any exception or watchdog timer.

How does Tasmota prevent, that a reboot due to no AP present causes a reset?
It seems like I am not the only one with this problem:
https://groups.google.com/forum/#!topic/sonoffusers/aIeDfE7Mm_M

It seems that fluctuating power will reset all tasmotas in the house with the default behaviour.

Can we think about a way to prevent this?

Regards,
Hendrik

[ascillato]

A way to prevent that is to disable those features. See commands SetOption36 and SetOption65 in the docs. Thanks.

[henfri]

Hello,

I understand that. I am not thinking of myself only, but of the default. I do not think that the current behavior is an acceptable default behavior.

Greetings,
Hendrik

[ascillato]

It is the default as explained in commands in the wiki/docs. If you don't need those features, you can disable them.

Bootloop refers to a problem in the configuration and/or rules that makes your device to keeping restarting.

Power loop is a way to reset devices where you can't access the onboard button for resetting. So, these defaults are needed for most devices, specially bulbs.

If you don't need or don't want them, just disable them when you are configuring your device.

[henfri]

Hello,

I understand.
I do not understand that they are needed for most devices. If a button is available (e.g. on a Sonoff S20) this can be used to reset, can't it?
It would make sense to disable these options in the templates.

I lost the configuration of all my Tasmota devices. I know how to disable these features - now. And the same will be true for every user. It is not expected behaviour that a power loop resets the device. It should not be the default if it is not needed. And we can detect if it is needed by:

• Templates
• Checking what's configured on the GPIOs and use those to reset

Does that make sense?
Or is it not possible to use any GPIO to cause a reset?

Greetings,
Hendrik

[ascillato]

Tasmota has a lot of customization options. You should configure Tasmota depending on your setup. If the device has or not an external button for recovery. If the device is installed in a place of difficult access, etc etc.

[ghost]

Hi everyone, I have the same problem. If the power goes out three or four times in succession, the tasmota configuration on the sonoff mini is reset.

[ascillato]

yes, that is a feature. see in the docs command SETOPTION65 for more information and configuration

[henfri]

However this features saved countless devices from being bricked. At least the worst case scenario is a reset device, not a bricked one.

Understood and agreed.

The fast power cycle is a standard process

But still Not intuitive.
What ist your estimation, how many Users are aware of it?

There is no such thing as a first login on the web interface. Tasmota is designed as MQTT first, the web console is only here to help. There are many ways to configure or pre-configure Tasmota.

Understood. But I bet that 99.9% of the Users when using Tasmota dir the very First time DO Access the Webinterface.
Thus, my proposal would Help almost all users, as it would make them aware

[henfri]

I'm sorry too but....

If you clever enough to run 240 devices you may also like to read the release notes before installing new versions like a real system manager.

I'm sorry too but....

If you clever enough to run 240 devices you may also like to read the release notes before installing new versions like a real system manager. Simply disabling the features you don't need could safe your life.

Honestly: do you do that for every Software (every Windows Release, every Update of every App, ...)

1. read all Release notes
2. read all Docs
3. disable all unused Features

[ascillato]

But anyway:
At First Login to the Webinterface ask if this Feature should bei activated - explaining the consequences.

OR (worse in my View)

Only activate this, If no Button configured

That could be one solution, but makes the problem more complex because there are some devices like Shelly 2.5 that they connect to mains ac switches but they also have a small button on the back. Those devices are installed inside the light or switch boxes. So, in case of any issue that needs to reset or to provide the AP, the user need to open the box and touch that button while the device is powered (not recommended) or to power down the electricity and take that device out.

So, at the end, setoption65 and setoption36 are just tools and the main issue is just to make the user aware of those features. Some users wants that, other don't depending on their preference and on their setup.

In the docs at GETTING STARTED ( https://tasmota.github.io/docs/Getting-Started/ ) it is the following warning note:

As a solution, I vote for the fast power cycle detection (SetOption65) to have 7 times power on in a row instead of the actual 4, in order to make this problem less common.

[blakadder]

Finally 👯‍♂️

[arendst]

Let's wait for the request to up it to 8 interrupts...

[pfeerick]

Why not 9? 🏃

I think the important takeaway is that the documentation need to be improved, so that people are aware of the danger of some of the defaults... so it was good to see that the warning note was added to the quick start guide four days ago! 😛 If there's more settings like that which could cause grief, might be worth a section of it's own, as it's currently hidden at the very end of the guide. Either way, I for one certainly wouldn't want that option disabled by default since I have several lights that need it for recovery!

[ascillato]

I think the important takeaway is that the documentation need to be improved

@pfeerick

Ok, please help us and do a pull request to the docs.

[henfri]

Hello,

thanks for the improvements!
I do not understand why you discard my remark of showing this warning at first logon?

Regards,
Hendrik

[blakadder]

Why not 9? 🏃

I think the important takeaway is that the documentation need to be improved, so that people are aware of the danger of some of the defaults... so it was good to see that the warning note was added to the quick start guide four days ago! 😛 If there's more settings like that which could cause grief, might be worth a section of it's own, as it's currently hidden at the very end of the guide. Either way, I for one certainly wouldn't want that option disabled by default since I have several lights that need it for recovery!

Thats just for punishment for people refusing to read the guide 🚑

[henfri]

Again: die you read every Guide of every Thing you use?

[meingraham]

@henfri

Again: die you read every Guide of every Thing you use?

Pretty much, yes. Especially when I dive into the bowels of something and am hacking it. Replacing the factory firmware with Tasmota qualifies... and continues to qualify even as I upgrade Tasmota.

I also don't upgrade unless there is a feature I need. Most of my devices are still on 6.6.x. So I'm not blanket updating dozens of devices at once. When I do, I check the features delta between the version of the devices or small number of devices are on with the version I'm about to upgrade to. This typically keeps me out of trouble. But when I have missed something or actually encountered a bug, the damage is limited to one or a very few devices, not dozens.

[henfri]

Hello,

amazing. I never read the manual of Android, Windows, Debian.

Do you think that most of the users do it similarly well as you do?

Regards,
Hendrik

[ascillato]

If comments continue to be offtopic, the issue will be locked. Please, if better docs are required, please just do a pull request with the improvements you think should go. Thanks.

[meingraham]

My Windows laptop and Android phone are managed by my corporation so I don't control when they roll updates to my devices. I rely on our IT department to have done the testing before releasing them to us. This is why updates are delayed while they perform the tests. They do the same testing for all the systems in our data centers before rolling them out to prod.

As for Debian... I only use Raspbian on my Raspberry Pi SBCs... and I don't roll out updates unless I have an issue and find that an update resolves it... and then I do peruse the release notes before doing so. I try to be as diligent to looking at the docs before applying an update to any installed packages. I definitely diligently read the notes before updating my openHAB server.

An example for Tasmota... I had a device running 6.6.0.x. I'd been hindered in wanting to use additional rules due to hitting the rule sets capacity. Recently, @s-hadinger added compression. So I decided to upgrade this single device so I could use compression and add more of the rules I wanted to implement. So... I looked at all of the change logs for 7.x and 8.x. Once I felt I understood the changes and any impact (good or bad), I followed the migration path to get this device on the latest version of Tasmota. In fact, I looked at all the new compilation directives in my_user_config.h in order to tailor my binary properly and added them to my user_config_override.h to fully implement any features I wanted (or didn't want). The upgrade from 6 to 7 to 8 was a bit tedious but required due to structural changes to Tasmota. Had I not read first and just tried the OTA update, I'd have bricked the device. So, yes, I read the release notes.

Maybe that's just me.

[s1nbad]

I am pleased to say I am all up and running.

My comment was not a complaint, although I was pretty unhappy at the time, the software did exactly as it was designed to do. It was more to do with the responses on the thread which seemed to focus on "you should have read the manual" rather than discuss how serious the ramifications of this default feature is.

The "warnings" were in an area that I mistakenly thought would not be relevant to an install and yet it wiped out my whole campus by design.

I do not know the answer but consider carefully how this "feature" could be used maliciously !!

[pfeerick]

@blakadder Rather, punishment for not reading that documentation you went to the trouble of prettifying! :-P

@meingraham Yes, just you! :-P I mean... really... sheesh... what's this my_user_config.h and user_config_override.h... and what's that got to do with pressing the big blue 'Tasmotize!' button on Tasmotizer? 😆 Jokes aside, some due diligence is needed on the part of user, but since when has that gotten in the way of ThingsGoingWrong(tm)?

@ascillato What do you think of another heading/section in the Getting Started guide... or better yet... it's own page? Common traps for new users? Think of it as a catch all troubleshooting page. Surely this isn't the only default option that can backfire spectacularly in the right circumstances? Or are there not enough to warrant it's own 5 seconds of glory?

@s1nbad Good point there on the malicious use... it would be like knowing that you only have to turn any Cisco router on and off five times and it would reset to the default password! :-O There's however no easy answer due to how many devices and variances Tasmota supports. Yes, it could be linked to the hardware template supporting a physical button, but even then, someone will get caught out after they've installed their device inside a hard to get area, and are trying to get it to reset. Better to somehow draw their attention to it in the first instance, so it is configured correctly for their application. And since you can't rely on the web interface, due to MQTT users, documentation it will have to be.

How about 42 cycles, since that's the ultimate answer? :-P 😆

[meingraham]

There are two paths that we've tried to guide users through - Getting Started ideally would be where new users would start... you can lead a horse to water... 😉 The other is the migration path for existing users. Perhaps these notes (e.g., QPC) or a separate article re: "gotchas" could be referenced in both of these paths. But again, you can lead a horse... but you can't make him read the docs!

[blakadder]

Whoops, seems I mistakenly edited that post instead of quoting it. Sorry

What do you think of another heading/section in the Getting Started guide... or better yet... it's own page? Common traps for new users?

For that to work we'd need new users to submit where they got caught! Its difficult for seasoned users to think in a new user way as much as we try.

Maybe you should start one ;)

[martusi61]

The same problem happened to me every now and then, about 30 sonoff energy fluctuations with tasmota lose configuration, then I found this post and I'm trying the solution, but I have an idea, the SetOption65 problem is clearly a communication shortage / reading the guide, then why not move it to the web interface? This way everyone will see it and can set it up as they like.

[ramanraja]

I knew this configuration loss problem before I installed Tasmota for the first time; but I was fooled by my misplaced notion of consistency. I thought I was disabling the diabolical 'option 65', but actually enabled it!
A very small sample:

SetOption56 : 0 = disable
SetOption57 : 0 = disable
SetOption58 : 0 = disable
SetOption59 : 0 = disable
SetOption62 : 0 = disable
SetOption66 : 0 = disable
SetOption67 : 0 = disable

But unfortunately:
SetOption65 : 0 = enable

[tangoTH]

+1 "which is your proposed solution?"

A complaint without a proposed alternative or solution is just that, a complaint.

How about detecting the template applied then turning on or off this feature. I just lost 5 sonoff switches and have to reconfigure them by walking around my properly.

That said, it's a small price to pay for something I couldn't design myself (Tasmota)

[tangoTH]

Change WifiConfig to Disable wifi config but retry same AP without restart and flash writes Command: WifiConfig 5

Does this "WifiConfig 5" command tell the system to keep trying the old AP and not erase it's config?

I just had a 30 minute power outage and my Tasmota switches were all stripped to default configs and sharing their own SSID

[barbudor]

So your problem is not WifiConfig but most likely the Fast Power Cycle recovery mecanism

https://tasmota.github.io/docs/Device-Recovery/

[tangoTH]

Thanks Barbudor. As I wrote, I had a 30 minute power outtage and when the device was powered back up (and left for about 16 hours as I wasn't home and they are night lights) it was broadcasting the tasmota SSID and not connecting back to to my wireless network and the config was gone.

Are you saying the "WifiConfig 5" is not the fix. I don't have fast power cycles it's either off or on

[barbudor]

Have you read the doc ? Have you understood it ?

What I am saying is that Fast Power Cycle IS the reason for your configuration to be wiped and Tasmota restarting from fresh, broadcasting its AP

In many places, when power comes back after an outage, it does't come back nicely. Most of the time it comes up, down, up down a few times before being stable back on.
This may triggers the Fast Power Cycle recovery mecanism.
To avoid that you must have SetOption65 1 to disable Fast Power Cycle recovery. WifiConfig 5 will no help you with regards to that problem.

[tangoTH]

I've read the doc, but No, i don't understand the different WifiConfig examples. It is quite confusing for a home user.

I've done the SetOption 65 1 via the WebUi command line. I'm confident my power came back in a single time because I have records of my inverter after they replaced the failed electrical component up the street.

Appreciate the help, i'll keep an eye on it. Thank you

[barbudor]

Hi @tangoTH
I'm not talking about WifiConfig but if your whole configuration is being erased (not only wifi credentials but every settings) the only possible reason is device recovery which can come from only 2 sources:

• Button_1 being pressed for more than 40 seconds
• Fast Power Cycle

If your configuration is not erased but your Tasmota starts their own AP but successfully reconnect to your WLAN after a restart, then indeed WifiConfig 5 is your 1st level solution. The most possible cause is that Tasmotas devices restarts before your AP is UP, they can't find the SSID so they reboot in WIfiManager mode.

Note if you want to be safe from any of those, I suggest that you build your own binary/binaries with hardcoded Wifi credentials and WifiConfig 5.
For that you need to compile with the following defined in your user_config_override.h:

#undef  STA_SSID1
#define STA_SSID1         "YourSSID"             // [Ssid1] Wifi SSID
#undef  STA_PASS1
#define STA_PASS1         "YourWifiPassword"     // [Password1] Wifi password

#undef WIFI_CONFIG_TOOL       
#define WIFI_CONFIG_TOOL       WIFI_WAIT // WifiConfig 5 : Wait for the AP without rebooting

#undef APP_DISABLE_POWERCYCLE  
#define APP_DISABLE_POWERCYCLE  true             // [SetOption65] When true, disable fast power cycle detection for device reset

With such embedded setting, even in case of Fast Power Cycle, your device will stick on your Wifi and wait for it to be ready.

[tangoTH]

Thank you. I have made the appropriate changes to my Tasmota (Sonoff 4 channel)

As long as the device will try to connect to WIfi when it's up and NOT erase the config, i'm good. I can walk into the yard and reset it.

Thanks again

[coolchip]

Thank you! Searched for this issue for very long. I ever thought my hardware is broken.

I've got a battery/solar powered esp8266 and sometimes the voltage of the battery drops and the esp seems to do a boot loop. After that my configuration was erased and a have to put it back in.
With SetOption65 1 this never happens again since a long time.