Non deterministic malfunction of shelly 1 plus

Hi @mpmario,

I can provide my build that I am currently using. But I have a few comments to make:

  • It’s a build based on the openhab-addons repository’s 4.2.2 branch.
  • It might or (most probably) might not work out of the box. For instance, on my openhab machine I was missing openhab-transport-coap feature enabled in order to load the custom binding.
  • I am not the maintainer of the binding and @markus7017 is not convinced that my proposed solution is expedient.

That’s being said I admit that I am also not sure if my solution solves the root cause of the issue or rather only the symptoms. Nonetheless, it evidently works for me and I think it might be useful to know, if it solves the issue for others as well. That way we can rule out, that my installation is somewhat special (not in the good way).

I cannot upload the jar file here. I uploaded the custom build to Filebin | gy1qewqw1j2qofir instead. Be aware, this link will expire in 6 days.

If you are willing to build the binding yourself, here is the patch you would need to apply on a branch of GitHub - openhab/openhab-addons: Add-ons for openHAB that suits your installed version of openhab:

I’m wondering if this is a general issue to all Shelly devices or only to devices that are configured in detached mode.
Does anybody has information about this? Because if only detached mode is affected I would try to reconfigure my openHab setting to accomplish my goal.

By the way - has this issue been fixed in the meantime so an update make sense?

@pafleck, what would you try to accomplish with reconfiguring openhab? I am having this issue with a Shelly i4 which does not have detached mode (due to the absence of any actor).

So far, I haven’t heard of any updates addressing this issue.

Hi Baschdi,
Many thanks for your version of the binding. So, since installing it 4 days ago, all problems are gone and the WAF factors of the system have increased significantly :slight_smile:
How can we help @markus7017 to apply a fix to the binding?

@mpmario, I am glad to heat that. But I have to admit that I moved from openhab to home assistant for reasons other than this issue with the Shelly binding. Thus, I may not be of help anymore as I cannot test patches on my system or provide logs.

@markus7017, regarding the issue with Shelly I4, I still suspect that the Shelly device closes the websocket if it does not receive any data via it. The standard device poll (which I assume is the HTTP GetStatus request) does not seem to keep the websocket alive. That’s why I added the GetStatus request via websocket (one additional line, see patch above) which seems to work. What can we do to prove or disprove this suspicion?

Hello,

I already posted this in the Shelly Binding thread, but maybe it fits better here?

===========================

since the firmware updates to version 1.3x and 1.4x, all my Pro Shellys 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.

Here are a few Shelly logs:

Dec  5 00:05:52.629 8964 77.21.165.202:59362 W shos_rpc_inst.c:374     0x3fff2978: duplicate id 'openhab-'
Dec  5 00:05:54.074 8965 77.21.165.202:59362 W shos_rpc_inst.c:374     0x3fff2978: duplicate id 'openhab-'
Dec  5 00:05:54.078 8966 77.21.165.202:59362 I shos_rpc_inst.c:243     Shelly.GetConfig via HTTP_in POST 192.168.0.xxx:34220 user admin
Dec  5 00:05:55.369 8967 77.21.165.202:59362 W shos_rpc_inst.c:374     0x3ffb78e4: duplicate id 'openhab-'
Dec  5 00:05:55.421 8968 77.21.165.202:59362 W shos_rpc_inst.c:374     0x3fff2978: duplicate id 'openhab-'
Dec  5 00:05:55.425 8969 77.21.165.202:59362 I shos_rpc_inst.c:243     Shelly.GetConfig via HTTP_in POST 192.168.0.xxx:36682 user admin
Dec  5 00:05:55.799 8971 77.21.165.202:59362 W Expected seq 8970, got 8971 (gap 1)
Dec  5 00:05:55.799 8971 77.21.165.202:59362 W shos_rpc_inst.c:374     0x3fff2978: duplicate id 'openhab-'
Dec  5 00:05:55.799 8972 77.21.165.202:59362 I shos_rpc_inst.c:243     Shelly.GetConfig via HTTP_in POST 192.168.0.xxx:36710 user admin
Dec  5 00:05:55.917 8973 77.21.165.202:59362 W shos_rpc_inst.c:374     0x3fff2978: duplicate id 'openhab-'

Thank you in advance.

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

Hi @MiniOh,
from the logs and what you described it looks to me as if this is some different problem. Your problem seems to be connected to the update of your shelly devices whereas the issue discussed here does not.

Did you try to remove/purge all devices and re-discover one by one (maybe start with just one and check logs and behavior)?

Hello Sebastian,

yes, you are right. My behavior is completely different.

That is why “your solution” did not help.

I have had a lot of contact with Shelly Support, but they see the error on Openhab’s side
and also categorically reject a firmware downgrade.

I have decided to buy another Shelly Pro 4PM and test it with “old” firmware.

The result is almost as expected.

With firmware 1.0.7, the Shelly works completely normally, there is a websocket login from Openhab,
which also remains.

All Pro Shellys with FW 1.4.4, however, show the above behavior, with a websocket connect / disconnect between the Openhab instance and Shelly taking place hundreds of times per minute.

@baschdi I am running an BLE motion detection switching lights on/off based on lumination. I also use the wall switch to “overwrite” motion detection and to turn on light continuously. Both is handled in openHAB. If this issue would be only regarding devices in deteached mode I would turn this off and would configure an workaround in openHAB.

I will try your patch. Because I’m running openHAB in docker I need to configure a new host to compile the patched version. If this handles the error - even if it is only a workaround - I would be glad about it :slight_smile:

I updated the DEV build

  • Use “oh-”+serviceName (“shelyxxx-xxxx”) for RPC srcId - this makes it device specific rather than host specific
  • Every 70sec get RPC GetStatus is send on the WebSocket channel, this should keep the connection open

Please try this one, check READMEbeta for installation


4.3-DEV | README | READMEbeta
Avdanced Users | Shelly Manager | Bugs/Features | API Doc
Note: The DEV build is always newer than the version in the official Distro or Milestone builds…