State of Shelly

DasXoanon · February 18, 2025, 9:56am

So to debug my Shelly issue I installed a brand new LXC Container, Debian 12, poxmox-helper script. latest out of the box openHAB install.
Shelly devices have password enabled. Firmware 1.4.4. (latest stable)
Addons: only Basic_UI/Shelly

2025-02-18 08:10:16.244 [INFO ] [org.openhab.core.Activator          ] - Starting openHAB 4.3.2 (Release Build)
2025-02-18 08:10:20.281 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2025-02-18 08:10:25.344 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2025-02-18 08:10:49.385 [INFO ] [p.auth.internal.AuthorizePageServlet] - First user account created: admin
2025-02-18 08:11:03.056 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Berlin'.
2025-02-18 08:11:03.057 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'en_GB'.
2025-02-18 08:12:02.146 [INFO ] [nternal.manager.ShellyManagerServlet] - Shelly Manager started at http(s)://192.168.160.127:8080/shelly/manager
2025-02-18 08:12:02.669 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shelly1mini:dcda0ce3c75c' to inbox.
2025-02-18 08:12:02.962 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellydevice:ec626088ce44' to inbox.
2025-02-18 08:12:07.366 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellydevice:ec62608848dc' to inbox.
2025-02-18 08:12:20.071 [WARN ] [org.eclipse.jetty.io.ManagedSelector] - java.nio.channels.ClosedSelectorException
2025-02-18 08:12:21.971 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer 
2025-02-18 08:12:23.971 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer 
2025-02-18 08:12:25.972 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer 
2025-02-18 08:12:27.972 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer 
2025-02-18 08:12:29.972 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer 
2025-02-18 08:12:32.667 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer 
2025-02-18 08:12:34.669 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.160.127:8080/rest/addons/ui-basic's Observer

Install Wizard is unresponsive. “No service was found.”

systemctl restart openhab.service takes more than 3 Minutes.
the usual java stacktraces in system journal. hiding any usefull hints. (more than 1500 lines)

now the shelly device webinterface shows “reconnection” issues. After some time (30-120s) you get a “reconnection” message for serveral seconds - without adding the Shelly “things”

After restart I add my shelly password and add them as things (two zombie things already there, deleting)
(The Shelly Manager works without any authentication?!) … All (5) Shelly devices have a uptime of more than 600000s …

They are several GitHub issues for what will happen now:

github.com/openhab/openhab-addons

[Shelly] pro3m goes offline /hard/

opened 06:52PM - 20 Jan 25 UTC

SeveranExp

bug

## Expected Behavior Shelly device works normally and does not go offline. ## C…urrent Behavior The PRO3M after some days / weeks working normally goes offline, hard, and only power cycling the device restores it. Local web ui stops working too. Clicking the reset button or pressing it does nothing. ## Possible Solution Power cycle the device ## Steps to Reproduce (for Bugs) Detect Shelly pro3m in openHAB inbox and wait for it to crash. ## Context Well the device becomes completely useless so yeah. ## Your Environment openHAB 4.3.0.M4 (problem has persisted through several versions) Ubuntu 24.04.1 Unifi access points for WiFi. 10+ Shelly devices in entire network have no issues Using addon from addon store

github.com/openhab/openhab-addons

[shelly] Shelly Pro Devices get flooded with requests from Openhab instance

opened 11:54AM - 12 Dec 24 UTC

MiniOh

bug work in progress

Hello, since the firmware updates to version 1.3x and 1.4x, all my Pro Shell…ys have problems. I have been using some Shelly Pro 4 PMs for about 3 years, and also a Shelly Pro 3 EM. The Pro 4 PMs are some of the first to come onto the market in 2021. So far, these have always worked without problems and were always accessible via WiFi. Since the updates to 1.3.2 and 1.4.4, all of my devices have been running very unstable. There are a lot of ping losses. The uptime of the devices, which used to be 1 year in some cases, is only between 5 and 30 minutes. The devices also restart very frequently. After a few days, some of the devices are not accessible at all and only switching off the power supply helps. Switching off the ECO mode provides some relief. This alleviates the problems somewhat. Still very unsatisfactory compared to the time before the firmware update. I contacted Shelly Support about the issue. It turned out that the devices were being flooded with requests every second from the Openhab instance. According to Shelly, these thousands of requests are to blame for the crashes. So the question at this point is, why so many requests sent by Openhab? The query interval is set to 60 seconds. The Openhab version is the current openHAB 4.2.3. But I also tested the current snapshot version of the Openhab binding. The behavior is the same here. All my 40 non Pro Devices has no Problems, but they only beeing contaced every 60 seconds by openhab. This is the according log, which floods the log a hundred times a minute. ``` 13:19:35.094 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - shellypro4pm-123456789123: WebSocket connected /192.168.0.xxx:33552<-/192.168.0.xxx:80, Idle Timeout=2147483647 13:19:36.063 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Closing Rpc API (socket is connected, discovery=true) 13:19:36.063 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Disconnect Rpc Socket 13:19:36.064 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - shellypro4pm-123456789123: Disconnecting WebSocket (/192.168.0.xxx:33552 -> /192.168.0.xxx:80) 13:19:36.065 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: WebSocket connection closed, status = 1006/Disconnected 13:19:36.067 [DEBUG] [.discovery.ShellyDiscoveryParticipant] - shellypro4pm-123456789123: Shelly device discovered: IP-Adress=192.168.0.xxx, type=shellypro4pm 13:19:36.132 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Closing Rpc API (socket is connected, discovery=true) 13:19:36.133 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Disconnect Rpc Socket 13:19:36.133 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - shellypro4pm-123456789123: Disconnecting WebSocket (/192.168.0.xxx:41414 -> /192.168.0.xxx:80) 13:19:36.134 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: WebSocket connection closed, status = 1006/Disconnected 13:19:36.137 [DEBUG] [.discovery.ShellyDiscoveryParticipant] - shellypro4pm-123456789123: Shelly device discovered: IP-Adress=192.168.0.xxx, type=shellypro4pm 13:19:36.204 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Closing Rpc API (socket is connected, discovery=true) 13:19:36.205 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Disconnect Rpc Socket 13:19:36.206 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - shellypro4pm-123456789123: Disconnecting WebSocket (/192.168.0.xxx:41418 -> /192.168.0.xxx:80) 13:19:36.207 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: WebSocket connection closed, status = 1006/Disconnected 13:19:36.209 [DEBUG] [.discovery.ShellyDiscoveryParticipant] - shellypro4pm-123456789123: Shelly device discovered: IP-Adress=192.168.0.xxx, type=shellypro4pm 13:19:36.227 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Connect Rpc Socket (discovery = true) 13:19:36.228 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - shellypro4pm-123456789123: Connect WebSocket, URI=ws://192.168.0.xxx/rpc 13:19:36.231 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellypro4pm-123456789123: Connect Rpc Socket (discovery = true) 13:19:36.232 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - shellypro4pm-123456789123: Connect WebSocket, URI=ws://192.168.0.xxx/rpc ``` Thank you in advance.

Lets wait … its 9:00 CET…

Now … (10:25) the first shelly device ( shelly1minig3) has an uptime of 700s…
Now … (12:06) the shellypro2pm is gone…
Now … (12:51) the shelly1minig3 gone (again)
Now — (14:05) my second shellypro2pm is gone (uptime 1500s)

The rest will follow.

Right now, there is a serious reproduce able issue. Perhaps its the debian environment. Perhaps the enabled passwords. Both github tickets are stale since one month.
I startet migrating my Shellies to MQTT.

It even does not help to remove the “things” - you need to disable the plugin to stop all devices in the same network from rebooting.

But could somebody remove the binding from the installation wizard? Or ensure that the add-on is only installed in “approved” environments (e.g. openhabian) I mean I already replaced one of the Shellys thinking it was a hardware fault. Right now, the add-on is running a DoS attack on all Shellys causing an unresponsive device until the (shelly) internal watchdog reboots the shelly.
You cannot turn on/off the light until that happens. This is dangerous.

krikk · February 18, 2025, 10:39am

full acknowledge, have seen exactly the same when i exchanged my shelly 3EM with a new “Shelly Pro 3EM” …unusable, because of constant reboots, not available …until i uninstalled the shelly binding in openhab, since then no more problems, shelly runs rock stable…