Shelly +1 reboots every view minutes

[wimaha]

Hi,

I have multiple Shelly +1 installed in september 2022. They working very well with this firmware.

Suddenly one of the +1 starts rebooting every view minutes. (between 2 and 30 Minutes)
When I revert to the stock shelly firmware the device is working normal.

What can I do?

[wimaha]

Unfortunately, I now have another Shelly with the same problem...

[Ju17091]

I now also have this problem with 4 shelly 1 plus.
Is there no fix for it ?
Have now been running for 3 months and all of a sudden they start rebooting all the time.

[timoschilling]

For all of you, please do the following:

1. open the web UI
2. go to the "System" section
3. click on "Log"
4. keep it open until the shelly reboots the next time
5. after the shelly reboots, copy the log and post it here

[frdmn]

I have a similiar issue, only that I can trigger a reboot by quickly changing the states of my Shelly Plus 1.

@timoschilling I've captured the output here, but it cuts off as soon as it's rebooting.

42803008 shelly_debug.cpp:231    No log file, sending new entries
43693226 shelly_main.cpp:449     Up 43.68, HAP 0/1/16 ns 1, RAM: 212408/205520; st 55; 0.1: st:0 in_st:0 inm:1 ininv:0
48167128 mgos_http_server.c:180  0x3ffcd9d4 HTTP connection from 192.168.1.102:52557
48183583 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52557
48196265 mgos_mongoose.c:66      New heap free LWM: 205212
48203560 mgos_mongoose.c:66      New heap free LWM: 205108
49193998 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52557
49898012 mgos_http_server.c:180  0x3ffcdea4 HTTP connection from 192.168.1.102:52563
49917449 mgos_mongoose.c:66      New heap free LWM: 203024
49928919 mgos_mongoose.c:66      New heap free LWM: 201872
49952456 mgos_mongoose.c:66      New heap free LWM: 200184
50102768 mgos_http_server.c:180  0x3ffcd950 HTTP connection from 192.168.1.102:52565
50109671 mgos_http_server.c:180  0x3ffcd9d4 HTTP connection from 192.168.1.102:52564
50137403 mg_rpc.c:314            Shelly.GetInfo via WS_in 192.168.1.102:52564
50152115 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52564
51079384 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52564
51693201 shelly_main.cpp:449     Up 51.68, HAP 0/1/16 ns 1, RAM: 211332/200184; st 55; 0.1: st:0 in_st:0 inm:1 ininv:0
59694237 shelly_main.cpp:449     Up 59.68, HAP 0/1/16 ns 1, RAM: 211332/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
67084141 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52564
67693213 shelly_main.cpp:449     Up 67.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 55; 0.1: st:0 in_st:0 inm:1 ininv:0
68082178 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52564
69083373 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52564
70083094 mg_rpc.c:314            Shelly.GetInfoExt via WS_in 192.168.1.102:52564
75693144 shelly_main.cpp:449     Up 75.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
83693146 shelly_main.cpp:449     Up 83.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 55; 0.1: st:0 in_st:0 inm:1 ininv:0
91693092 shelly_main.cpp:449     Up 91.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
99693222 shelly_main.cpp:449     Up 99.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
107693273 shelly_main.cpp:449     Up 107.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
115693240 shelly_main.cpp:449     Up 115.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
123694048 shelly_main.cpp:449     Up 123.68, HAP 0/1/16 ns 1, RAM: 211756/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
131693191 shelly_main.cpp:449     Up 131.68, HAP 0/1/16 ns 1, RAM: 211772/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
139693262 shelly_main.cpp:449     Up 139.68, HAP 0/1/16 ns 1, RAM: 211772/200184; st 56; 0.1: st:0 in_st:0 inm:1 ininv:0
147693331 shelly_main.cpp:449     Up 147.68, HAP 0/1/16 ns 1, RAM: 211772/200184; st 55; 0.1: st:0 in_st:0 inm:1 ininv:0
150558423 shelly_output.cpp:64    Output 1: off -> on (HAP)
150704910 shelly_output.cpp:64    Output 1: on -> off (HAP)
150886869 shelly_output.cpp:64    Output 1: off -> on (HAP)
151562958 shelly_output.cpp:64    Output 1: on -> off (HAP)
151776529 shelly_output.cpp:64    Output 1: off -> on (HAP)
151989995 shelly_output.cpp:64    Output 1: on -> off (HAP)
152297787 shelly_output.cpp:64    Output 1: off -> on (HAP)
152520305 shelly_output.cpp:64    Output 1: on -> off (HAP)
152783308 shelly_output.cpp:64    Output 1: off -> on (HAP)
152984586 shelly_output.cpp:64    Output 1: on -> off (HAP)
153229775 shelly_output.cpp:64    Output 1: off -> on (HAP)
153432289 shelly_output.cpp:64    Output 1: on -> off (HAP)
(Here's where it rebooted)

[TonyJacobi]

Same problem for me. I have made 2 LOG's:

LOG 1
150807461059 shelly_debug.cpp:231 No log file, sending new entries
150811869723 shelly_main.cpp:443 Up 150811.86, HAP 0/1/12 ns 1, RAM: 26516/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150819869804 shelly_main.cpp:443 Up 150819.86, HAP 0/1/12 ns 1, RAM: 26792/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150823319085 mgos_http_server.c:180 0x3fff466c HTTP connection from 192.168.68.193:60439
150823934328 mg_rpc.c:310 Shelly.GetInfo via WS_in 192.168.68.193:60439
150827869695 shelly_main.cpp:443 Up 150827.86, HAP 0/1/12 ns 1, RAM: 27644/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150835869553 shelly_main.cpp:443 Up 150835.86, HAP 0/1/12 ns 1, RAM: 27920/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150843869618 shelly_main.cpp:443 Up 150843.86, HAP 0/1/12 ns 1, RAM: 27920/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150851869912 shelly_main.cpp:443 Up 150851.86, HAP 0/1/12 ns 1, RAM: 28720/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150859870234 shelly_main.cpp:443 Up 150859.86, HAP 0/1/12 ns 1, RAM: 28720/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
150863108185 mgos_http_server.c:180 0x3fff466c HTTP connection from 192.168.68.193:60452

LOG2

151059406805 shelly_debug.cpp:231 No log file, sending new entries
151059722381 mgos_http_server.c:180 0x3fff4724 HTTP connection from 192.168.68.193:60498
151059869835 shelly_main.cpp:443 Up 151059.86, HAP 0/1/12 ns 1, RAM: 26184/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
151067869903 shelly_main.cpp:443 Up 151067.86, HAP 0/1/12 ns 1, RAM: 22684/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
151074158366 mg_rpc.c:310 Shelly.GetInfo via WS_in 192.168.68.193:60498
151074731769 mongoose.c:12127 Failed to resolve 'time.google.com', server 8.8.8.8
151075731082 mongoose.c:12127 Failed to resolve 'time.google.com', server 8.8.8.8
151075869752 shelly_main.cpp:443 Up 151075.86, HAP 0/1/12 ns 1, RAM: 24164/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
151077828811 mongoose.c:12127 Failed to resolve 'time.google.com', server 8.8.8.8
151082729121 mongoose.c:12127 Failed to resolve 'time.google.com', server 8.8.8.8
151083871415 shelly_main.cpp:443 Up 151083.86, HAP 0/1/12 ns 1, RAM: 25272/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
151090731411 mongoose.c:12127 Failed to resolve 'time.google.com', server 8.8.8.8
151091869612 shelly_main.cpp:443 Up 151091.86, HAP 0/1/12 ns 1, RAM: 27340/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
151099869900 shelly_main.cpp:443 Up 151099.86, HAP 0/1/12 ns 1, RAM: 27268/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1
151107869857 shelly_main.cpp:443 Up 151107.86, HAP 0/1/12 ns 1, RAM: 28516/15760; st 0; 5.1: cur:closed tgt:closed cl:1 op:-1

[bryanlb]

I've noticed this issue as well, running the latest firmware 2.12.1. There doesn't seem to be any consistency with what triggers it or when it happens. I've had it run for months without an issue, but most recently it crashed multiple times less than 24 hours after a reset - sometimes multiple times in a row, only a few mins apart.

Reverting to the stock firmware and the issue seems to go away, and this only seems to apply to the +1 device - I have a few Shelly 1 and an RGBW2 that doesn't appear to be impacted with this problem.

[markirb]

Can you try this:

#1513

[bryanlb]

Interestingly, I've had this device set to power saving disabled. I'll give the power savings 2 a shot to see if that helps.

I've been exploring the idea that this is network/request related, as I've occasionally seen an apparent crash when trying to modify settings too quickly. I also have multiple home hub devices in the house.

I set my network firewall to block access to the device, and with that in place I've successfully had the device running for over 40 days now without a crash. This obviously isn't ideal since you lose access to it, but has been an interesting observation. 🤔