Tasmota Devices are Restarting when TasmoAdmin is open

[boyfromgermany]

Expected Behavior

Devices should stay online

Current Behavior

After update to 12.3.1
some devices are randomly restarting, but only when tasmoadmin is open on a browser

Possible Solution

Steps to Reproduce

1. fresh install
2. added devices via auto-discovery
3. open webinterface
4. devices have uptime 22h but after some minutes devices are restarting

Context (Environment)

HomeAssistant AddOn

PowerRetain":"ON
WifiConfig":{"5":"Wait"}}

Context (Device)

Version 12.3.1
hardware different manufacturers of same device
https://templates.blakadder.com/gosund_SP111.html
https://www.amazon.de/dp/B0054PSI46?

Detailed Description

here are the different restart reasons
RestartReason:"Hardware Watchdog" | Uptime:"0T00:13:26"
  |  
RestartReason:"Software Watchdog" | Uptime:"0T00:31:06"
  |  
RestartReason:"Software/System restart" | Uptime:"0T00:31:54"
  |  
RestartReason:"Hardware Watchdog" | Uptime:"0T00:15:57"
  |  
RestartReason:"Software/System restart" | Uptime:"0T00:02:33"

RestartReason:"Software Watchdog" | Uptime:"0T00:28:03"

[inverse]

TasmoAdmin calls the HTTP API on the devices to get the status when you're not actively toggling the device or configuring the settings.

It sounds like it could be an issue with Tasmota that's causing this.

I've noticed it too but didn't look too deeply into what's causing it.

It might be worth creating an issue on https://github.com/arendst/Tasmota to see if they have any insights. Do you know the version of the firmware that didnt have this behaviour to narrow down the potential regression?

[inverse]

@alexdelprete Have you ever noticed this behaviour?

[alexdelprete]

Have you ever noticed this behaviour?

no, I would've noticed, but I can test right away: if I understood correctly, , if I leave TasmoAdmin browser window open, devices should restart, correct?

If so, I can do a test on Shelly devices (Plug S, Shelly 1, Shelly 1PM, Shelly EM, etc.) and also Sonoff TX Switches...

[inverse]

Exactly that, leave it open on the devices view and devices will restart... like 10 minutes should be enougg. i havent pin pointed what causes it.

could be something device specific as i have the same plugs as the op.

[CityJumperAC]

I have exactly the same issue,
Especially with the POW devices, if I request them via MQTT there is no problem, seem to be a problem with the http request being to frequent.

My s2 samt plugs have no problem, but the POW habe this very frequent, maybe it have something to do with the message length, would be nice to find a fix in the tasmoadmin but I think it's a tasmota related bug, of the message Generation time vs the software watchdog

[alexdelprete]

If it's device specific, it will be difficult to tackle this in TasmoAdmin. Maybe you could introduce a sort of throttling parameter (optional) for users who have a lot of these devices, so TA won't "flood" with http requests.

Right now, what is the default refresh rate/polling period?

[boyfromgermany]

Hello, i also tried to change the interval to 30sec but it changed nothing for now i have stopped tasmoadmin and the devices have uptime since a couple days also the problem is that if the devices restart the devices behind lose power so it is not usable right now for server,pc, fridge… i could start it again and gather logs of the restarts if you could tell me how 😅 Alessandro Del Prete ***@***.***> schrieb am Di. 17. Jan. 2023 um 10:50:

…

If it's device specific, it will be difficult to tackle this in TasmoAdmin. Maybe you could introduce a sort of throttling parameter (optional) for users who have a lot of these devices, so TA won't "flood" with http requests. Right now, what is the default refresh rate/polling period? — Reply to this email directly, view it on GitHub <#752 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6JYR6PHNBWTDU5JWXNZTWSZTNFANCNFSM6AAAAAATYNNAHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alexdelprete]

None of my devices (Shelly devices and Sonoff TX switches) show that behaviour.

When one of my devices is restarted, power to the physical device (the fridge) is not lost. If that's the behaviour with your plugs/switches, you should check here for the optimal configuration (PowerOnState, SetOption63): https://tasmota.github.io/docs/PowerOnState/#poweronstate-functionality

[boyfromgermany]

Yes this is configured and it works it also worked before with every update that the energy keeps on but with the crashes fron tasmoadmin(?) the power is lost 😩 i have write above the options +wificonfig also on wait Alessandro Del Prete ***@***.***> schrieb am Di. 17. Jan. 2023 um 13:30:

…

None of my devices (Shelly devices and Sonoff TX switches) show that behaviour. When one of my devices is restarted, power to the physical device (the fridge) is not lost. If that's the behaviour with your plugs/switches, you should check here for the optimal configuration (PowerOnState, SetOption63): https://tasmota.github.io/docs/PowerOnState/#poweronstate-functionality — Reply to this email directly, view it on GitHub <#752 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6JYTGFI7AVX34A2EMMZDWS2GHBANCNFSM6AAAAAATYNNAHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[CityJumperAC]

I also habe the right config!
The pow seems to have an issue by the software watchdog that is also toggles the output, the s2 keeping its state!

But both showing the software watchdog error if tasmoadmin is running.

Without I habe uptimes of weeks and month.. but with tasmoadmin running, they rebooting frequently

[alexdelprete]

Yes this is configured and it works it also worked before with every update that the energy keeps on but with the crashes fron tasmoadmin(?) the power is lost

Be careful, on warm reboots PowerOnStart is not executed, you need to carefully check the configuration of SetOption63:

If you have issues of losing power when a device restarts, no matter what kind of restart, you should open an issue @ Tastmota repo to get an advice for your specific device.

What is the value of SO63 on your affected devices?

[alexdelprete]

As you can see from this screenshot, I'm on the TasmoAdmin List page, tested since 1h, and no reboots, the uptime increases:

[alexdelprete]

Now 2 hours with TasmoAdmin open, no reboots:

[inverse]

Thanks for the reporting @alexdelprete 🙏

I'll see what I can do around the request throttling behaviour - I'm guessing it's very chatty.

But yeah we've both reported the gosund SP111 has this behaviour :/ At least it's reproducible :)

[inverse]

@CityJumperAC what device model is problematic for you?

[boyfromgermany]

Yes this is configured and it works it also worked before with every update that the energy keeps on but with the crashes fron tasmoadmin(?) the power is lost

Be careful, on warm reboots PowerOnStart is not executed, you need to carefully check the configuration of SetOption63:

If you have issues of losing power when a device restarts, no matter what kind of restart, you should open an issue @ Tastmota repo to get an advice for your specific device.

What is the value of SO63 on your affected devices?

Hello,

The Value is {"SetOption63":"OFF"}

[inverse]

Right now, what is the default refresh rate/polling period?

The default time is 8 seconds - it's been like that since 2018.

[alexdelprete]

The default time is 8 seconds - it's been like that since 2018.

Maybe it's a little too much (I think 15 would be better)...but it's configurable IIRC.

[alexdelprete]

The Value is {"SetOption63":"OFF"}

And SetOption0?

[boyfromgermany]

SetOption0

{"SetOption0":"ON"}

[alexdelprete]

Did you try with SO63 set to 1? It was created exactly for these "strange" cases:

SetOption63 was introduced to disable the startup scan for devices where the scan leads to undefined results.

[crashdown79]

I was also able to reproduce with Gosund SP111, SP211 and Nous A1T (which are basicaly SP111 with preflashed Tasmota) it´s independent to TasmoAdmin Version 2.4.2 up to 3.0.0.beta3 and also not bound to a tasmota Version tried 7 diffrent 10.x to 12.4.0.1
I was not able to identify a valid cycle yet. Most SP111 restart at least every 1-2 days some SP211 running 7-14days without restart.

[boyfromgermany]

I was also able to reproduce with Gosund SP111, SP211 and Nous A1T (which are basicaly SP111 with preflashed Tasmota) it´s independent to TasmoAdmin Version 2.4.2 up to 3.0.0.beta3 and also not bound to a tasmota Version tried 7 diffrent 10.x to 12.4.0.1 I was not able to identify a valid cycle yet. Most SP111 restart at least every 1-2 days some SP211 running 7-14days without restart.

interesting for me it only applied after update
what does your device say is the restaart reason ? my devices restartet every couple minutes

are you sure they are not restarting because of wifi ?

I resettet all my tasmota devices completely (not because I wanted to, i had a power outage and that triggered the reset) but i will test if the issue still persists soon

[crashdown79]

"RestartReason":"Software/System restart"
I´ve some other Sonoff Switches and more the 15 Wemos/NodeMCU,ESP32 Device which are not influenced.
If i look at the >30 TasmoAdmin connectd devices only the Gosund/Nous Switches have this behavior.

[crashdown79]

The cycle time on a short test now differs from about 100s up to 1700s between reboots. All devices are Gosund and have a Teleperiod of 300. I´ve also tried Sleep and DeepSleepMode parameters with no influence yet

[inverse]

Are you able to reproduce it by just curling the device?

while true; do curl "http://<ip>/cm?user=<user>&password=<pass>&cmnd=status+0" | jq '.StatusPRM.Uptime'; sleep 1; done

With jq to print out the current uptime to make it easier to know whats going on

I managed to reproduce it with curl alone

"0T00:08:34"
"0T00:08:35"
"0T00:00:55"
"0T00:00:58"

[mafrei2019]

Ich kann das bestätigen, habe aber den Eindruck bei allen Geräten die Leistung messen können. Allerdings tritt es weniger auf mit älteren Versionen z.B Tasmota 9.1

[crashdown79]

Syslog Msg while reboot:

Feb 23 17:08:18 energy9-4632 ESP-MQT: tele/energy9/INFO3 = {"Info3":{"RestartReason":{"Exception":4,"Reason":"Software Watchdog","EPC":["40003b53","00000000","00000000"],"EXCVADDR":"00000000","DEPC":"00000000","CallChain":["40101bc3","4024fcfe","401020c1","4024fd37","4024f532","40000f49","40000f49","40000e19","40105acd","40105ad3","40100aa0","4010000d","40102714","40270440","402703f1","40100aa0","40102714","401059c7","401032ab","4010348c","40100aa0","4010394e","4010394e","4000050c","40103670","40100aa0","40255713","40255dba","402562b7","40256809","40255cf0"]},"BootCount":104}}

You´re right my Gosund SP111 with Tasomota 10.x reboot less often then newer Versions

[inverse]

Can you test it with sleep 5 and in case it does it again with sleep 10?

Trying with 5s sleeps been going for over 20 min now... It's strange as the default sleep is 8s - perhaps there's some bug in the logic in the JS

[alexdelprete]

Can you test it with sleep 5 and in case it does it again with sleep 10?

Trying with 5s sleeps been going for over 20 min now... It's strange as the default sleep is 8s - perhaps there's some bug in the logic in the JS

That's what I suspected...the problem is that some of these tiny devices will go under pain when flooded with too many connections. The delay is necessary, and probably it's not working in TA.

[inverse]

That's what I suspected...the problem is that some of these tiny devices will go under pain when flooded with too many connections. The delay is necessary, and probably it's not working in TA.

Did some checking and it looks like it is working :/

this is with 8 seconds set.

[alexdelprete]

Good job. Release it asap because this means that TA is actually stressing all devices quite often. ;)

[inverse]

Gonna leave my TA open for a while to see if I see the resets... I didn't do a whole lot tbf.

I did add a connect_timeout on the HTTP client to cut after 5s

#798

The latest beta build has all that in https://github.com/TasmoAdmin/TasmoAdmin/releases/tag/v3.0.0-beta.6

[alexdelprete]

It's not configurable?

[inverse]

Not yet - that was the one that was there before I refactored it ages ago :/

[inverse]

I can make it quickly configurable from the json config? Would that suffice for you?

[alexdelprete]

Let's wait for the UI. 5s is a decent default (I would use 10s).

[inverse]

Spoke so soon, something is def up - with TA open I noticed it reset - even with 8 seconds and connections to the app showing 8 seconds between 🤔

[alexdelprete]

The best thing would be sniffing all traffic from TA to that device. Probably you would notice something unexpected. :)

[inverse]

I guess intercepting that would paint the full picture.

"0T00:14:00"
"0T00:14:12"
"0T00:01:09"
"0T00:01:18"
"0T00:01:26"

Left curl running on one of the devices for longer and it also shows the same behaviour - this is with 8 seconds 😢

[inverse]

Even with 10s - I printed out the .ResearchReason too - I also upgraded plugs to to 12.4.0

malachi@pulsar ~ $ while true; do curl -s "http://192.168.1.12/cm?user=<redacted>&password=<redacted>&cmnd=status+0" | jq '.StatusPRM | .RestartReason, .Uptime'; sleep 10; done
"Software/System restart"
"0T00:12:58"
"Software/System restart"
"0T00:13:08"
"Exception"
"0T00:01:12"
"Exception"

[alexdelprete]

Trying with 5s sleeps been going for over 20 min now... It's strange as the default sleep is 8s - perhaps there's some bug in the logic in the JS

so this was just a lucky episode? :)

[crashdown79]

same here also with beta6 again restarts when TasmoAdmin is opened in a browser

[mafrei2019]

Tritt auch mit TasmoAdmin 3.0.0 auf. (FW 12.4.0)

[loganjohnlong]

I'm seeing this with both Sonoff S31s and Cloudfree P2s. Stopping the TasmoAdmin HA plugin solves the problem. I'll try running the current release of TasmoAdmin as a standalone container and see how it goes. The rebooting issue only seems to affect my tasmotized plugs, my switches and iFan04s don't seem to be affected.

[mafrei2019]

I am also testing, a question for loganjohnlong on the subject. Have you also entered data in WLAN 2 (SSID2) in the wifi entries and if so can you limit this to one entry for testing ?

[arendst]

I noticed this issue and since a long time I tested http again using curl to retrieve status 8 from an energy monitoring device. To my suprise it restarted immediately with a core panic. No exception, just a restart.

Took some days to find the cause being lack of stack space!!!! What happens is the rewritten energy code uses stack to store strings and depending on how many phases I wanted to support I extended these strings in the assumption that every function receives a 4k stack space. After the test I noticed that was no true! Since v12.4.0.3 I've rewritten the string handling for energy monitoring removing the burden from stack to heap. This provides less stack usage and I was finally able to access my device with curl and retreive status 8 while keeping enough stack space.

A test with 100 requests and 0.5 second interval went fine.

I suppose this will solve most TasmoAsdmin reported restarts on energy monitoring devices.

Give it a try (from the dev branch).

[alexdelprete]

Took some days to find the cause being lack of stack space!!!!

Great job in solving this one. BTW: this was the most probable suspect (lack of mem resources, etc.) when I talked about it with @inverse.

Finally we can take off the blame from TasmoAdmin for causing the reboots, even though there were some bugs in the sleep logic also there, but have been solved. :)

[inverse]

Great investigation and thanks for the fix! Upgraded two devices and will check if it happens again!

[mafrei2019]

Hatte bisher keine Probleme mehr mit der 12.4.0.3. Mann darf hoffen ;)

[alexdelprete]

@boyfromgermany did you test 12.4.0.3? If it's working, can you close the issue please? Thanks.

[CityJumperAC]

Hi,

I tested with 12.4.0.3 and 12.4.0.4 and had no further issues till know!

Great work! THY

[slimline33]

Mir ist das Problem auch ausgefallen. Vorallem an den Gosund Steckern. Bin dann wieder zurück auf Tasmota 11.1.1 und damit läuft es.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[alexdelprete]

@inverse Malachi, I think you can close this.