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

[maverickmoddy]

Having recently installed 3 sonoff mini's that have been flashed with tasmota, all changed their IP address following a power outage. When they initially powered, I added each of the sonoff mini IP addresses in the smartthings devices, had app and voice control, lost power, then lost app and voice control when power came back on. Until I noticed in the Fing app, that I had 3 different IP addresses than I had before, didn't know the IP address could change while on the same network. Here's an added bonus, two other sonoff mini's previously placed did not produce a new IP address after the power came back on. Hongtat on smartthings community is telling me I need to assign a static IP address, so while I'm looking that up, to see if this can be done so the mini's done change IP address every time it boots up would be welcome. mod

[ascillato]

The IP is assigned by YOUR router. If you want a static IP, you have to set that in YOUR router. If you want fixed IP, you can config that in Tasmota using command IPADDRESS1 See the docs for more information on commands.

If you need further assistant, please, address this to the Tasmota Support Chat. The chat is a better and more dynamic channel for helping you. Github issues are meant for Tasmota Software Bug Reporting.

Please check the Contributing Guideline and Policy and the Support Guide.

Thanks.

---

Support Information

See Wiki for more information. See FAQ for common questions/answers and links if none of your question is in the list See Chat for more user experience. See Community for forum. See Code of Conduct

[kristofejro]

@ascillato @ascillato2 Today I have had several frequent power outages and half of my tasmotas were reset to defaults. After reading this topic (issue) wanted to disable fast power cycle detection.

Am I right that this option is responsible for reseting to defaults when there are few power outages?

In documentation there is:

SetOption65 Device recovery using fast power cycle detection 0 = enabled (default) 1 = disabled

On all of my tasmotas I checked and it looks like this:

19:58:43 CMD: SetOption65
19:58:43 MQT: stat/sonoff_foscam/RESULT = {"SetOption65":"OFF"}

20:00:27 CMD: SetOption65 1
20:00:27 MQT: stat/sonoff_foscam/RESULT = {"SetOption65":"ON"}

20:00:52 CMD: SetOption65 0
20:00:52 MQT: stat/sonoff_foscam/RESULT = {"SetOption65":"OFF"}

So how it is? When I use "SetOption65 1" then it is ON and when "SetOption65 0" it is OFF How does it corespond to the documentation when there is 0=enabled and 1=disabled ? Please help me to understand this.

[Jason2866]

SetOption65 Device recovery using fast power cycle detection 0 = enabled (default) 1 = disabled

If it is 0 / Off it does reset device when fast power cycles occur To disable this behaviour it has to be set to 1 / On -> No reseting when power cycling occurs

[s1nbad]

I must comment that this "feature" has reset over 120 Tasmota devices across my campus It is now rainy season in many places across Asia and inconsistent power is very common.
I think some of the comments above should have recieved a little more empathy than simply, yes it is a feature, read the docs. I am now faced with all Tasmota devices in AP mode and having to reload all the configs together with reading all the docs again to figure out which other "features" may break ALL the configs.

[henfri]

+1

[ascillato2]

@s1nbad

I must comment that this "feature" has reset over 120 Tasmota devices across my campus It is now rainy season in many places across Asia and inconsistent power is very common. I think some of the comments above should have recieved a little more empathy than simply, yes it is a feature, read the docs. I am now faced with all Tasmota devices in AP mode and having to reload all the configs together with reading all the docs again to figure out which other "features" may break ALL the configs.

@henfri

+1

I totally understand that this feature was unknown to you and it affects your device config and piss you off. For every setup, Tasmota should be configured accordingly. This feature was added (after a long discussion) to have a way to recovery devices that don't have buttons like bulbs. There are several old issues where you can check that several users have entered a wrong wifi password, or wrong config and they lost access to their bulbs, so they have to take them apart and flash by serial.

So, Tasmota has several options with a default defined. We know that not all default values fit in all use-cases, so it is needed to adapt those option to the users' setup.

I understand your complaint, but now which is your proposed solution?

[meingraham]

+1 "which is your proposed solution?"

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

[henfri]

That is not right. You can explain that the current solution ist Bad, evennif Not knowing a better one.

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

[s-hadinger]

I'm sorry about what happened to you. However this features saved countless devices from being bricked. At least the worst case scenario is a reset device, not a bricked one.

The fast power cycle is a standard process (IKEA, MagicHome...) and is supposed to be a rare event. You need to turn off/on 3 times in less than 10 seconds. But it happens.

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.

I never thought about the option of turning off fast power cycle for devices with buttons, we need to discuss about it. The main problem is that it adds some more complexity on a topic that is already complex. New users might be completely lost.

[arendst]

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.

[meingraham]

With 120 Tasmota devices, hopefully you make configuration backups. Once you restore Wi-Fi settings (yes, a pain for that number of devices), restoring the setup for each device could be automated using decode-config and a list of devices.

[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.