Shelly 2.5 reboots every x-minutes

[patricks]

Hi,

I have currently 3 Shelly's (2.5) installed for a few months now. One of them reboots every x-minutes. I figured this out because the light turns off for a few seconds and the uptime in the web ui is also reseted. Is there a way to figure out whats going wrong? I tried to enable debug logging, but it looks like after a reboot the log gets cleared?

I am always running the latest firmware (currently 2.4.0), but this problem also appeared with older ones.

[rojer]

go to http://DEVICE/debug/core in your browser. if the firmware crashed, you'll get a core dump. please send it to rojer@rojer.me, i'll take a look.

[Pixel-Chris]

@patricks
Is that an Shelly 2.5 in garage door mode?

[patricks]

go to http://DEVICE/debug/core in your browser. if the firmware crashed, you'll get a core dump. please send it to rojer@rojer.me, i'll take a look.

It rebooted a few times today (see it via the uptime in the web ui) but there is no core dump.

[patricks]

@patricks
Is that an Shelly 2.5 in garage door mode?

No it is in the switch mode

[rojer]

reboot with no crash dump likely points to hardware issue, voltage instability (sags, spikes) or some such.

[andyblac]

possibly over heat too ?

[rojer]

overheating just disables HAP service, it doesn't reboot the device

[andyblac]

overheating just disables HAP service, it doesn't reboot the device

Ok good to know thanks

[rudyemm]

Hi guys! I have 4 Shelly 2.5s setup as light switches (each only as a single switch), and I have the exact same problem. I thought I had defective units, which seemed unlikely since multiple units face the same issue. It’s reassuring to know others are seeing the same problem, so hopefully we can solve it.

Some more details about my specific issue. Sometimes, the Shelly will run “stable” for many days. Sometimes, they will restart every few hours. A couple times, the Shelly seemed like it was on a restart loop, every few seconds. It was bizarre. I rolled back the stock firmware and set those affected units up on a timer (sunset till 11pm), and the lights seemed to stay on consistently. When the 2.4.0 firmware came out, I thought I would try HomeKit again but the issue persists.

Separately, I’ve also noticed that an automation in HomeKit to turn off all my lights in the evening had failed on one of the Shellys. When I try to access that Shelly by (static) IP, the web server is completely unresponsive until I power down and back up the Shelly.

Also, the WiFi signal is not strong to the Shellys that exhibit these issues, but it’s not terrible either (-63 to -72). I’m not sure if that is playing any part in the restart issue.

Please let me know if you’d like any more details, tests, or logs from me. Keep it up 👍 I love your work!

[rojer]

hm. naturally, i'd like to see logs.
i've recently made a change to make acquiring latest logs easier, it hasn't bee released yet, so please install a beta from here - http://rojer.me/files/shelly/2.5.0-beta1/ and go to http://DEVICE/debug/log
leave the page open, it will be tailing the log. when device reboots, please take last dozen lines or so from that page.

[rudyemm]

Hey @rojer I've emailed you the core dump files. I'm installing the beta FW on 2 of my Shellys (the most problematic ones). I also wanted to point out that the temperatures of the Shellys (as per the UI) are: 74°C, 95°C, 92°C, and 86°C. I will also note my electrical wiring has no N wire at the switch, so my Shellys are installed at the light end (inside the housing, so maybe that's also why its getting hot in there).

@patricks Can you share more details about your setup? Is it the standard wiring behind the light switch? How's your temp?

[rudyemm]

More notes 😊

Some more bizarre behavior. I check in the UI and see the Shelly has recently rebooted, reporting "Uptime: 0:00:00:31". A few moments later, I wanted to check if the Shelly rebooted again, but now (less than 10 minutes later), it's reporting "Uptime: 0:01:13:07". I recall this weird behavior occurring in the previous firmware as well, before I installed 2.5.0-beta1.

A little while later, one of the Shellys starting behaving possessed. Within 4 minutes, it rebooted 10 times. I used the stopwatch on my phone, and here's the duration between each reboot:
34s
6s
12s
5s
22s
1m01s
18s
10s
4s
1m10s

I've now switched them off, I'll try them again shortly. But super weird behavior. I'm wondering if anyone else has had this issue. The only other / last time this happened was about 3 weeks ago.

[rojer]

@rudyemm i've taken a look at the core dumps - looks like stack is smashed, i'm not getting a meaningful stack trace out of it right away, will need more digging.

[rudyemm]

Sure, let me know if I can provide any other dumps, logs, etc and I’m happy to help you experiment 👍

[rojer]

i've take a closer look at the dumps.
the reason i'm not getting backtrace is not because of stack smashing but because the crash happens in binary libs supplied by espressif and those don't have the debug symbols necessary to find function entrypoints.
anyway, the firmware enters an endless loop and gets reset by the WDT.
as far as i can tell from the disassembly, it prints "mac 985" as the reason:

   0x40102612:  l32r    a2, 0x4010214c
   0x40102615:  l32r    a3, 0x40102150
   0x40102618:  movi    a4, 0x3d9
   0x4010261b:  l32r    a0, 0x4010115c
   0x4010261e:  callx0  a0
=> 0x40102621:  j       0x40102621

0x4010214c is the format string, %s %u 0x40102150 is "mac" and 0x3d9 is 985.

i see other people reporting it as well, but without any reason or resolution...
possibly some device on your network generates some traffic that confuses the esp's wireless stack, this happened before.
unfortunately, there's very little i can do, this is all in closed code.

[rudyemm]

Oh nice, thank you so much for your investigation. This makes some sense, at least I feel confident there is no malfunction with the Shelly. This could be a result of the 2 most problematic Shellys connecting to my WiFi repeater(they’re located in the garden) while the other 2 “stable” Shellys connect straight to my UniFi network inside the house and do not exhibit so much of the restart problem. I restarted my WiFi repeater, and theShellys connected to it have been stable for a full day without restarting. I will keep testing and perhaps extend my UniFi to these Shellys that keep restarting, and I’ll report back with my findings.

@patricks can you confirm how the Shellys are configured in your home network? Do you have any WiFi repeaters?

Separately @rojer do you think the temperatures I’m seeing with my Shellys of up to 95°C could be causing any stability issues, and more importantly is this normal or is it dangerous to be running that hot?

Thanks again for everyone’s help, and keep up the great work 👍👍

[patricks]

This sounds interesting, @rudyemm it looks like I have a very similar WiFi setup. UniFi Amplifi Router + WiFi repeater. The problematic shelly is also the only one which is connected via the repeater. I have already tried to reboot my router and then the Shelly works for a few days, but after a few days I have the same problems.
The temperature on my Shellys is about 65°C

[patricks]

@rudyemm are your problems gone since the router restart? I have the same problems again.

[konagar]

Hi, at what voltage do you run your shellys. There are problems with 24 volts.

[rudyemm]

@konagar mine is on 230v

@patricks after a lot of testing, my conclusion is that a weak WiFi signal is causing the FW to crash and reboot – even after completely removing the repeater. My network setup is enterprise Unifi, not the Amplifi. I have moved my access point closer to the Shelly although the signal is still weak (they are in my garden). The web server is still slow to respond and the Shelly is still exhibiting the reboot behavior.

There is still a scenario when it falls in a reboot loop – I’m not sure what causes this. I dunno if the high temperature has any effect on this behavior. I have ordered another access point to provide better WiFi to the Shellys, and will report back with my findings of the Shellys once they have a good WiFi signal.

@rojer perhaps it’s worth testing the reliability/stability of the FW with a weak signal (RSSI: -80 or lower)?

[andyjp80]

I've been experiencing the same issue with a Shelly 2.5 I had installed. I have over 15 other Shelly 1's and 1PM's running the firmware that have been running perfectly for over 6 months now on the same network config. I purchased some more 2.5's and have just done some more testing. The 2.5 I started having this issue with is next to a 1PM behind a switch and is about 3m away from the closest Nano HD access point. I have 2 Nano HD's and I have a 2.4G SSID setup on each one which makes sure the Shellys only connect to the closest AP to them physically and don't hop between AP's. RSSI is -52 so I don't think signal strength is an issue. Reverted to stock firmware and ran for a week with no issues on the same network config. I setup a second new 2.5 yesterday on the bench and it ran for about 8hrs before dropping off. I've got some other devices on that SSID that I'm going to move off and test again, failing that I'm going to try and setup a VLAN on Unifi Controller with only the 2.5 on it and see if that has any impact.

[rojer]

this is interesting, there must be something to the 2.5 that causes it... but at the moment i have no idea what it could be.
if someone could capture serial logs continuously from a running device, that would be great.
warning: you HAVE to use an isolated serial to usb adapter, or you will regret it.

[andyjp80]

If you could point me in the direction of the right kind of serial usb adapter and how to capture the logs I'll have a crack at it. I'd love to get these working as reliably as the 1's and PM's as they're probably more reliable than some of my genuine homekit stuff ha ha.

[rojer]

i wish i could... i have a custom thing i use. but you need an isolated TTL level serial converter to USB

[andyblac]

If you could point me in the direction of the right kind of serial usb adapter and how to capture the logs I'll have a crack at it. I'd love to get these working as reliably as the 1's and PM's as they're probably more reliable than some of my genuine homekit stuff ha ha.

i use this https://www.amazon.co.uk/gp/product/B07BBPX8B8/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

[rojer]

@andyblac it's not isolated, never connect it while the device is connected to mains, you know what happens if you do :)

[andyblac]

ye, i always remove all wires 1st 😄

[rudyemm]

@andyjp80 hi there 👋 great to hear your feedback. Are you facing (a) reboots only, (b) unresponsive web UI, or (c) both? It’s good to have more people involved in this, hopefully we can get to the bottom of what is going on. It’s also reassuring to hear from you that your Shelly 1 devices are operating normally.

[andyjp80]

@rudyemm the core dump from my unit pointed to the "mac 985" issue. When it happens it has "no response" in homekit and it disappears from my network and web ui isnt accessible. If I power the circuit off at the breaker in the switch board it comes back to normal operation. Yesterday I moved the 2.5 onto its own 2.4G SSID and VLAN on a different IP range (it's the only device on it) to the rest of my network and so far its been up for 24hrs without issue. I'll report back in a few days to see if it's still going.

[rojer]

please update to 2.7.1, i fixed a whole bunch of bugs that could have affected stability.

[patricks]

Updated to 2.7.1 in the morning. Still have these light on/off problems.

[Jose-2021]

I have a similar problem. One of my 2 Shelly2.5 is rebooting randomly for the last 3 days.

In my case it doesn't seem to be a problem of WiFi range but could be associated with a malfunction of my Asus Router, which is also rebooting from time to time (nevertheless, they are not synchronised, the Shelly is rebooting while the router is working well - I cannot confirm the other way around - )

[Jose-2021]

@rudyemm , have you tried going back to stock, disabling that option and installing Mongoose again?

[rojer]

we don't respect the stock setting for this but the firmware does have logic in it to reboot if wifi is configured but has been down for more than 5 minutes.
the reboot should not be noticeable and it preserves the state of the outputs and only happens if the device is otherwise idle.

[rojer]

so it does mean that if wifi router goes down, shelly devices will be on a 5 minute reboot cycle. but again, it should not actually result on any state changes of the outputs.

[patricks]

This is strange, I still have problems with random light on/off problems with one of my Shelly's. If you say the state is restored after reboot, this has to be an other problem.

[Jose-2021]

Thanks @rojer for the responses. The 5min reboot logic seems good to me.

I'm digging a bit more in my problem:

• It is happening to the 2 Shelly2.5 I have and not to the 2 Shelly1 (all of them with the latest version)
• I know that it is affecting both Shelly2.5 because of their uptime value but, it seems that lights don't turn off with one of them.
• It is not a reboot every 5 minutes, sometimes the lights are almost flashing...
• The Wifi is very unstable (I have an open support ticket with Asus)

[Jose-2021]

No.... both lights turn off and on...
But no problems with any of the Shelly1

[timoschilling]

since @patricks reported other problems, it looks like we can close this issue now.

[patricks]

Is there already an issue for the light flashing problem?

[kerhbal]

hi @patricks @rudyemm @Jose-2021 can you check your device hardware name/version? I found my issue is strictly related to some devices. Details in the issue above. Thanks

[rudyemm]

Hi there 👋 where can we find this data? I’m on the stock FW.

[kerhbal]

hi @rudyemm , although I'm not 100% sure it is some kind of device hardware name/version, I get it from the default wifi name generated by shelly2.5
Since all my problematic ones(3 out of 6) come with a prefix as 98F4ABF2, I bet it's not coincidence. (other 3 good ones do not have this prefix)

[rudyemm]

I have five Shelly2.5s – the four problematic ones have the prefix D8BFC0

[rudyemm]

So maybe there was an issue with the hardware that was later resolved

[kerhbal]

Thanks for sharing. Good to know another bad prefix.

[protoblade]

I have this issue with 98cd running 20211109-125214/v1.11.7-g682a0db, 9/10 shellies running into the same wifi, most of them further than this one, all others are 1/1l/1pm. initially i tough it was related to spikes in powergrid as only 2.5 can measure the voltage but the occurrences are usually around stable voltage (215 to 230v) while in the extremes (200 to 250v) it does not even blink/reboots.

[timoschilling]

@protoblade v1.11.7 is stock firmware not this firmware

[protoblade]

@timoschilling, the FW has been update directly from the shelly web and it is 1.11.7 (20211109-125214/v1.11.7-g682a0db) i just put the whole build version that is reported in home assistant.

[Alexivia]

I have a single Shelly 2.5 with stock firmware 20220209-093016/v1.11.8-g8c7bb8d, connected to HomeAssistant (but not with Shelly cloud), and this reboot issue has happened to me 4 times in the course of almost 2 months. My device's ID starts with 98CD as well. It doesn't seem to be related to power outages, since voltage is always at normal values when this happens, and internal temperature was never above 50ºC.

[timoschilling]

@protoblade @Alexivia you both are using the original firmware not the firmware from this GitHub repository. Our software didn’t work with HomeAssistent or the Shelly app and has version numbers in a 2.x range. If you have any problem contact the Shelly support

[FreekBos]

I have this issue too...

• running latest fw on my 2.5
• running latest sw on ubuntu and mosquito
• my shelly 2.5's are the only one acting up like this
• all 2.5's are configured the same way
  Feel like a mushroom :-(
  Thanks,
  F

current log
1022327297615 mgos_mqtt_conn.c:579 MQTT0 queue overflow!
1022327303904 mgos_mqtt_conn.c:579 MQTT0 queue overflow!
1022327756219 mgos_http_server.c:180 0x3fff34f4 HTTP connection from 192.168.190.88:7923
1022327783162 json.c:426 RAM: 50720 total, 33768 free
1022327915004 mgos_http_server.c:180 0x3fff369c HTTP connection from 192.168.190.88:7924
1022328197105 mgos_sys_config.c:323 Saved to conf9.json
1022328266751 mgos_http_server.c:180 0x3fff374c HTTP connection from 192.168.190.88:7925
1022328282954 mgos_mongoose.c:66 New heap free LWM: 27696
1022328297834 mgos_system.c:58 Rebooting in 200 ms
1022328306136 mgos_mqtt_conn.c:257 MQTT0 Disconnect
1022328451958 mgos_http_server.c:180 0x3fff3204 HTTP connection from 192.168.190.88:7926
1022328502746 esp_main.c:138 SDK: state: 5 -> 0 (0)
1022328508517 esp_main.c:138 SDK: rm 0
1022328513805 esp_main.c:138 SDK: pm close 7
1022328527201 switch.c:1200 Going to reboot!
1022328818840 mgos_sys_config.c:323 Saved to conf9.json
1022328826758 switch.c:493 POSITION AND CALIBRATION DATA SAVED!!!!!!!!

previous log:
4798866696 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:42952
4803843221 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:38624
4808792767 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:38638
4813797009 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:35334
4818804864 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:35350
4823957857 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:46788
4828808955 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:46794
4831753326 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.190.88:9672
4831777649 json.c:426 RAM: 50720 total, 35792 free
4833313789 shelly_sntp.c:441 minute tick at 13:11:00
4833818768 mgos_http_server.c:180 0x3fff2e4c HTTP connection from 192.168.115.57:48672
4838840704 mgos_http_server.c:180 0x3fff2e4c HTTP connection from 192.168.115.57:48676
4843819749 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:39362
4848821833 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:39378
4853827079 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:60348
4858847096 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:60360
4863829597 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:52702
4868882105 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:52708
4873900093 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:52126
4878842234 mgos_http_server.c:180 0x3fff2e0c HTTP connection from 192.168.115.57:52130
4883846443 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:50592
4888870177 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:50598
4891747127 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.190.88:10381
4891772104 json.c:426 RAM: 50720 total, 35792 free
4893326078 shelly_sntp.c:441 minute tick at 13:12:00
4893863785 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:41618
4898856121 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:41630
4903862677 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:41972
4908857569 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:41982
4913868187 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:36306
4918867865 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:36318
4923872879 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:35520
4928907047 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:35534
4933899597 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:37380
4938874302 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:37392
4943876205 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:40548
4948881110 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:40554
4951743800 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.190.88:10417
4951803217 json.c:426 RAM: 50720 total, 35792 free
4953323809 shelly_sntp.c:441 minute tick at 13:13:00
4953887172 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:37786
4958901005 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:37796
4963904688 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:54960
4968928648 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:54970
4973942868 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:38238
4978902539 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:38250
4983909317 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:49350
4988993223 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:49358
4993926898 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:60616
4998939780 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:60628
5003954476 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:48828
5008918503 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:48842
5011761196 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.190.88:10432
5011785551 json.c:426 RAM: 50720 total, 35792 free
5013322167 shelly_sntp.c:441 minute tick at 13:14:00
5013925890 mgos_http_server.c:180 0x3fff2e4c HTTP connection from 192.168.115.57:33866
5018921407 mgos_http_server.c:180 0x3fff2e4c HTTP connection from 192.168.115.57:33878
5023927576 mgos_http_server.c:180 0x3fff2054 HTTP connection from 192.168.115.57:39810
5028934625 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:39824
5033942410 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:36726
5038962792 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:36732
5043942180 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:50434
5049051172 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:50446
5053949273 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:55176
5058953343 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:55178
5063956997 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:51566
5069068269 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:51572
5071738271 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.190.88:10443
5071765569 json.c:426 RAM: 50720 total, 35792 free
5073319691 shelly_sntp.c:441 minute tick at 13:15:00
5073989606 mgos_http_server.c:180 0x3fff2054 HTTP connection from 192.168.115.57:47896
5078966153 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:47910
5083971658 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:32914
5088976553 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:32916
5093977873 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:42170
5098983901 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:42172
5104024080 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:56168
5109064557 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:56170
5114055657 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:36914
5118995710 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:36928
5123998235 mgos_http_server.c:180 0x3fff2e0c HTTP connection from 192.168.115.57:59682
5129001568 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:59690
5131756889 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.190.88:10467
5131819739 json.c:426 RAM: 50720 total, 35792 free
5133317886 shelly_sntp.c:441 minute tick at 13:16:00
5134008014 mgos_http_server.c:180 0x3fff2e4c HTTP connection from 192.168.115.57:37950
5139007753 mgos_http_server.c:180 0x3fff2e4c HTTP connection from 192.168.115.57:37952
5144029154 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:56456
5149043135 mgos_http_server.c:180 0x3fff2054 HTTP connection from 192.168.115.57:56460
5154084073 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:54740
5159074903 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:54748
5164021473 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:48464
5169024113 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:48476
5174147251 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:41070
5179056762 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:41080
5184025898 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:56516
5189030717 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:56522
5191765122 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.190.88:10498
5191791230 json.c:426 RAM: 50720 total, 35792 free
5193326947 shelly_sntp.c:441 minute tick at 13:17:00
5194040454 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:37046
5199037976 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:37060
5204046009 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:50108
5209050574 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:50122
5214061269 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:48206
5219080157 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:48216
5224047420 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:37154
5229047554 mgos_http_server.c:180 0x3fff2d94 HTTP connection from 192.168.115.57:37158
5229838603 mgos_mqtt_conn.c:257 MQTT0 Disconnect
5229843873 mgos_mqtt_conn.c:551 MQTT0 connecting after 2064 ms
5231913806 mgos_mqtt_conn.c:472 MQTT0 connecting to 192.168.115.69:1883
5234051366 mgos_http_server.c:180 0x3fff2e0c HTTP connection from 192.168.115.57:56088
5237993743 mgos_mqtt_conn.c:230 MQTT0 TCP connect error (-8)
5237998971 mgos_mqtt_conn.c:257 MQTT0 Disconnect
5238003976 mgos_mqtt_conn.c:551 MQTT0 connecting after 4020 ms
5239049686 mgos_http_server.c:180 0x3ffefb3c HTTP connection from 192.168.115.57:56100
5242030750 mgos_mqtt_conn.c:472 MQTT0 connecting to 192.168.115.69:1883
5244062229 mgos_http_server.c:180 0x3fff2e0c HTTP connection from 192.168.115.57:33094
5248242510 mgos_mqtt_conn.c:230 MQTT0 TCP connect error (-8)
5248247755 mgos_mqtt_conn.c:257 MQTT0 Disconnect
5248252773 mgos_mqtt_conn.c:551 MQTT0 connecting after 8121 ms
5249076718 mgos_http_server.c:180 0x3fff1f84 HTTP connection from 192.168.115.57:33106
5251759636 mgos_http_server.c:180 0x3fff1f84 HTTP connection from 192.168.190.88:10507
5251783710 json.c:426 RAM: 50720 total, 36188 free
5253319296 shelly_sntp.c:441 minute tick at 13:18:00
5254057217 mgos_http_server.c:180 0x3fff1ffc HTTP connection from 192.168.115.57:46902
5256379730 mgos_mqtt_conn.c:472 MQTT0 connecting to 192.168.115.69:1883
5259059239 mgos_http_server.c:180 0x3fff2ec4 HTTP connection from 192.168.115.57:46904
5261496903 mgos_mqtt_conn.c:230 MQTT0 TCP connect error (-9)
5261535906 mgos_mqtt_conn.c:257 MQTT0 Disconnect
5261540933 mgos_mqtt_conn.c:551 MQTT0 connecting after 14415 ms
5264058178 mgos_http_server.c:180 0x3fff1ffc HTTP connection from 192.168.115.57:43862
5269060263 mgos_http_server.c:180 0x3fff1ffc HTTP connection from 192.168.115.57:43870
5274073015 mgos_http_server.c:180 0x3fff2834 HTTP connection from 192.168.115.57:44204
5275961749 mgos_mqtt_conn.c:472 MQTT0 connecting to 192.168.115.69:1883
5275981330 mgos_mqtt_conn.c:230 MQTT0 TCP connect ok (0)
5276045477 mgos_mqtt_conn.c:274 MQTT0 CONNACK 0
5276051248 mgos_mqtt_conn.c:212 MQTT0 sub shellies/command @ 1
5276056763 mgos_mqtt_conn.c:212 MQTT0 sub shellies/shellyswitch25-483FDA8D1B81/command @ 1
5276063050 mgos_mqtt_conn.c:212 MQTT0 sub shellies/shellyswitch25-483FDA8D1B81/roller/0/command/pos @ 1
5276102452 mgos_mqtt_conn.c:212 MQTT0 sub shellies/shellyswitch25-483FDA8D1B81/roller/0/command @ 1
5276108757 mgos_mqtt_conn.c:212 MQTT0 sub shellies/shellyswitch25-483FDA8D1B81/relay/1/command @ 1
5276114010 mgos_mqtt_conn.c:212 MQTT0 sub shellies/shellyswitch25-483FDA8D1B81/relay/0/command @ 1
5276118852 shelly_mqtt.c:161 CONNACK: 0
5276145329 json.c:426 RAM: 50720 total, 35204 free
5276164871 mgos_mqtt_conn.c:579 MQTT0 queue overflow!
5276171735 mgos_mqtt_conn.c:579 MQTT0 queue overflow!
5276178911 mgos_mqtt_conn.c:579 MQTT0 queue overflow!
5276346414 switch_mqtt.c:156 roller cmd: [shellies/shellyswitch25-483FDA8D1B81/roller/0/command] "close]"
5276351920 roller.c:82 ========= roller 0 move direction=2 time=51001
5276356890 roller.c:101 ========= roller 0 moved 0, at pos=100
5276363414 switch.c:1098 Relay on pin 15 changed state 0 to 1
5276401721 powermeter.c:97 pm measure interval: 200
5279081225 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:44214
5284072074 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.57:34638
5286203601 mgos_http_server.c:180 0x3fff30b4 HTTP connection from 192.168.115.65:49812
5286212798 roller.c:82 ========= roller 0 move direction=0 time=0
5286221113 roller.c:101 ========= roller 0 moved 19, at pos=81
5286226253 switch.c:1098 Relay on pin 4 changed state 0 to 0
5286231272 powermeter.c:97 pm measure interval: 0
5286235938 powermeter.c:105 oneshot measure in 150
5286242640 switch.c:1098 Relay on pin 15 changed state 1 to 0
5286247337 powermeter.c:105 oneshot measure in 150
5289069367 mgos_http_server.c:180 0x3fff2ec4 HTTP connection from 192.168.115.57:34650
5291483372 mgos_sys_config.c:323 Saved to conf9.json
5291491239 switch.c:493 POSITION AND CALIBRATION DATA SAVED!!!!!!!!
5294069947 mgos_http_server.c:180 0x3fff3074 HTTP connection from 192.168.115.57:36696
5299070668 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:36710
5304072614 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:41020
5309090397 mgos_http_server.c:180 0x3fff28ac HTTP connection from 192.168.115.57:41036
5311759372 mgos_http_server.c:180 0x3fff28ac HTTP connection from 192.168.190.88:10538
5311785497 json.c:426 RAM: 50720 total, 35364 free
5313321603 shelly_sntp.c:441 minute tick at 13:19:00
5314098412 mgos_http_server.c:180 0x3fff3074 HTTP connection from 192.168.115.57:42022
5319091456 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:42038
5324075269 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:47534
5329075492 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:47550
5334096882 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:56510
5339097764 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:56520
5344093795 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:46606
5349086448 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:46608
5349703869 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.65:45192
5349713091 roller.c:82 ========= roller 0 move direction=1 time=0
5349719175 roller.c:101 ========= roller 0 moved 0, at pos=81
5349724583 switch.c:1098 Relay on pin 4 changed state 0 to 1
5349729475 powermeter.c:97 pm measure interval: 200
5354111340 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:44712
5359087561 mgos_http_server.c:180 0x3fff2ffc HTTP connection from 192.168.115.57:44728
5359939584 roller.c:82 ========= roller 0 move direction=0 time=0
5359948243 roller.c:101 ========= roller 0 moved 20, at pos=100
5359987015 switch.c:1098 Relay on pin 4 changed state 1 to 0
5359992038 powermeter.c:97 pm measure interval: 0
5359996727 powermeter.c:105 oneshot measure in 150
5360003496 switch.c:1098 Relay on pin 15 changed state 0 to 0
5360008220 powermeter.c:105 oneshot measure in 150
5364089839 mgos_http_server.c:180 0x3fff324c HTTP connection from 192.168.115.57:60096
5365252093 mgos_sys_config.c:323 Saved to conf9.json
5365259989 switch.c:493 POSITION AND CALIBRATION DATA SAVED!!!!!!!!

[wtadler]

@protoblade and @Alexivia: Were you ever able to fix the Shelly restarts? I also have a Shelly 2.5, with device ID beginning with 98cd, that restarts within a few minutes of turning on the first relay. (It otherwise doesn't restart. Nothing shows up in the Shelly logs.) Sounds similar to what was happening to you all. (I'm aware that the firmware in this repo seems unrelated to our issue—apologies. Just trying to keep the discussion in one place for future folks with this problem.)

[Alexivia]

@wtadler, your problem does not look like the problem I was reporting. My restarts happened randomly wether the device was with the relay ON or OFF, and they happened like once a day or every 2 days.
The problem you are reporting looks more like a power and/or temperature issue. If the device does not restart at all if you do not use the relays, but once you turn on one of them it restarts soon after, then I would say it's not the same problem. Check if your connections are solid, and that you use appropriate crimped ferrules in case you are using stranded wires, especially for higher loads.
In any case, for completeness, my problem seems to have been solved by a FW update (official, from Shelly), soon after this post was made. My device now does not randomly restart anymore, or at least not that I notice.
Good luck!

[wtadler]

Thanks for the tip! I replaced all my connections with crimped ferrules, and all the connections feel very secure. Unfortunately it didn't solve the issue, but I've found an acceptable workaround.