I am using S20 sockets, and every time there is a minor outage or a Wi-Fi issue I have to go around setting WifiConfig 5 on all sockets, because they reboot and lose state, going into Wifi Manager mode.
Is there a way to have the retry behaviour be the default without recompiling the firmware? Once configured, the device shouldn't fall back to Wifi Manager mode unless the user resets it.
In my case, when the S20 loses connectivity and goes into Wi-Fi Manager mode it resets every few seconds, turning the relay on/off by brief moments and causing wear and tear on the equipment connected to it.
That is not the normal behaviour of the Tasmota Software. If set WifiConfig this states doesnt change normally at power loss. The config is stored in flash. I think your used software is faulty in some way.
What Version do you use and where have you donwloaded it?
5.11.1, from the releases page. I upgrade regularly (about every other release).
Hmm, strange... My suggestion the best would be to try a own compiled version with your wifi setup.
I didnt use any prebuild image, so perhaps prebuilt images react different
I'm confused. So you step into a discussion questioning the origin of the firmware image and outlining the base functionality of the original software and now suggest building a custom image and point out you didn't use a prebuilt yourself?
That makes me curious: what kind of experience do you have with the default behaviour of the prebuilt image?
I never used a prebuild image. But in the configuration of self compiled version there is no option in there is wificonfig configured... So there should no difference in this behaviour from a precompiled to a selfcompiled one. My idea is to try with a selfmade one if the error goes away or it stays
build it yourself.
I鈥檝e just had this happen again, and the repeated reboots after 90s (with the relay flashing upon reboot) fried a lamp. And I am positive I set WifiConfig 5 on that particular socket.
I think there are two distinct issues here: reboots in wifimanager mode and relay toggle, and the loss of WiFiConfig 5 (which I set manually on all sockets) without any apparent reason.
You reference to questions from users who needs help in configuration -> no issues
I can only repeat what @reloxx13 said. Build your own.
And a question why goes wlan down? This is always bad if i setup is installed that needs a reliable one
I think you鈥檙e misrepresenting the issues here. Regardless of cause, two things are happening:
Also, I鈥檓 starting to suspect this is a firmware stability issue and not necessary a WiFi one. I am using homebridge and logging the RSSI values using Node-RED, and the two most problematic outlets have the same signal quality (on average) than the others.
My building my own image won鈥檛 fix this.
Your last sentence is not correct, you think that wont fix that. Others and i do.
Your turn (or not).
I'm honestly quite sorry that you have that attitude. Regardless, for reference, here are the socket RSSI charts. Note that Socket 4 (which was the one that failed today) still has a pretty good RSSI compared to the others both before the crash (which is beyond the chart limit, but recorded) and after.

(Sockets 7, 8 and 9 were removed from the chart to make it easier to see 4)
Ok. Yes the crash and your wlan setup is good.
So one more reason that you try to build your own firmware to see if things are going fine with that.
I have over 10 sonoff and about ten Esp devices with Tasmota in use, and not even one crashed since last firmwareupdate 5.12.... (Uptime 26T19:18:06)
Make sure these boxes are checked before submitting your issue - Thank you!
status 0status 0 gives me (some IDs redacted):15:36:26 CMD: status 0
15:36:26 MQT: stat/socket4/STATUS = {"Status":{"Module":8,"FriendlyName":"Socket 4","Topic":"socket4","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}
15:36:26 MQT: stat/socket4/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://domus1:80/api/arduino/sonoff.ino.bin","Uptime":6,"Sleep":0,"BootCount":44,"SaveCount":96,"SaveAddress":"F4000"}}
15:36:26 MQT: stat/socket4/STATUS2 = {"StatusFWR":{"Version":"5.11.1","BuildDateTime":"2018-01-07T21:51:09","Boot":6,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
15:36:26 MQT: stat/socket4/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"home.lan","LogPort":514,"SSId1":"REDACTED","SSId2":"REDACTED","TelePeriod":300,"SetOption":"00000009"}}
15:36:26 MQT: stat/socket4/STATUS4 = {"StatusMEM":{"ProgramSize":484,"Free":516,"Heap":24,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}}
15:36:26 MQT: stat/socket4/STATUS5 = {"StatusNET":{"Hostname":"socket4","IPAddress":"192.168.1.117","Gateway":"192.168.1.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.254","Mac":"68:C6:XX:XX:XX:XX","Webserver":2,"WifiConfig":5}}
15:36:26 MQT: stat/socket4/STATUS6 = {"StatusMQT":{"MqttHost":"home.lan","MqttPort":1883,"MqttClientMask":"DVES_X","MqttClient":"DVES_81013D","MqttUser":"DVES_USER","MAX_PACKET_SIZE":512,"KEEPALIVE":15}}
15:36:26 MQT: stat/socket4/STATUS7 = {"StatusTIM":{"UTC":"Sat Mar 17 14:36:26 2018","Local":"Sat Mar 17 15:36:26 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":1}}
15:36:26 MQT: stat/socket4/STATUS10 = {"StatusSNS":{"Time":"2018-03-17T15:36:26"}}
15:36:26 MQT: stat/socket4/STATUS11 = {"StatusSTS":{"Time":"2018-03-17T15:36:26","Uptime":6,"Vcc":3.212,"POWER":"OFF","Wifi":{"AP":2,"SSId":"7","RSSI":64,"APMac":"64:XX:XX:XX:XX:XX"}}}
No stack dumps or debugging. syslog (which I also collect) shows nothing special from this device prior to the time of the crash (as far as I can estimate from the chart).
Status 0 looks fine.
From the settings shown they should have been saved.
You might want to consider upgrade to the latest released version (5.12.0) or development version 5.12.0f
@arendst: 5.11.1 sonoff.bin is 484kb
By the same order:
sonof-XXYYSSIDDoes 5.12.0 stop the relay from clicking upon reboot? That alone would help prevent I don't burn out more lightbulbs.
Pls provide RestartReason for further analysis.
You might consider the type of load too as other users experienced strange behaviour with inductive loads interfering with the device flash.
Other than that all my 40+ devices never lost settings...
I suggest to update the one that fails the most to version 5.12.0 (prefferably development) and see what happens.
I will, but am still curious as to what the reboot behaviour will be. Is there any way to make sure it won't keep toggling the relay over and over during the night every few seconds if it enters a reboot loop?
I did just a restart 1 on a S20 device with firmware 5.12. Relay does not toggle.
Some users had problems with mDNS. I have this always disabled by default in my settings (no need).
Worth a try: use the ip adress in settings of your broker not a name (needs to be resolved)
If you keep the relay off it shouldn't toggle when power is restored. What happens at wifi restoration is currently your main problem as mine just wait for wifi to be available and connect again without toggling the relay.
I guess in your case the S20 experiences an exception causing the restart but I still cannot explain the settings loss.
You could also set PowerOnState 0 so the relay will always be off after a power restore.
Let's hope the exception doesn't toggle the relay, but yes, PowerOnState 0 is a good idea.
The exception will toggle the relay if it was on as it will restart the device and every restart will toggle the relay shortly due to SDK default GPIO state.
OK, so that's likely what burned out the bulb. Is that fixable at all?
Nope. Unless you build a device yourself and configure a relay the opposite way than itead did. That way an On relay will stay On but would toggle shortly to On if it was Off. You probably won't have that either...
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.