Shelly Binding

Hi Nico,

I’m using a Shelly PlusPlugS (model SNPL-00112EU), not a Gen3 one. The script is running fine on the Shelly from start. In the Diagnostics console I see regular messages like

shelly_script.cpp:205   script:1 7.4% CPU utilization
shelly_notification:210 Event from script:1: {"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":98,"Illuminance":6170,"Rain":1,"Speed":[1.4,2.1],"UVIndex":0,"Direction":[89],"addr":"28:68:47:ef:ae:fb","rssi":-88,"packet":"40 00 62 05 28 6a 09 20 01 44 8c 00 44 d2 00 46 00 5e c4 22"},"ts":1765790156.05}

This is interesting…
My model is “S3PL-00112EU”, which has the common name “Shelly Plug S Gen3”.
Interestingly, the previous scanner script from OH ran fine on them.

By the way, I gave it a try and made some analysis runs with ChatGPT through the script, and the most notable findings were:

  • Dimmer parsing logic is wrong and can corrupt parsing state (it reads the device ID and starts reading the content still from the same address)
  • Potential infinite scan retry loop
  • Unbounded growth of device caches (esp. SHELLY_BLU_CACHE and LAST_PID), which might largely grow when many BLE devices are around (which is the case here… ;-))

I did not go into deep detail, but told it to fix these issues, and the resulting script was no longer crashing and outputting reasonable logs. Nevertheless, this did not fix the fact that OH does not detect any Shelly Blu devices and does not receive events.

Anyone else out here who observed such effects?

@markus7017 I am back at the game and would like to update my setup to openHAB 5.0.3, so the 5.0.2 Snapshot is working with that version? And also the pm mini problem should be fixed now? WS90 is also included, so I don not have to test it with 5.1.0.M3? Or will it help , if I test it also with the Milestone release?

btw. I have a new shelly device, the linkedGo Smart Thermostat powered by Shelly ST1820-W … What do you think, is it possible to include it to the binding? :slight_smile:

cheers

Andreas

I updated the DEV builds for 5.0.x and 5.1 (should fix missing channel definition)

yes, the 5.0.1 build should run on 5.0.3

Beginning of September I bought some of the new Flood Sensor Gen4.
I’m on OH 5.0.3 and they are still found as unknown.
Is this correct or am I doing something wrong?

One global question from side, @markus7017, if I may. Do you know which version of your dev branch will make it in the 5.1 OH official release?
Is it going to be the one from Release openHAB 5.1.0.M2 · openhab/openhab-distro · GitHub (this is the last milestone which had enhacements/fixes I think for Shelly binfing) ?
Or a more recent one?

Thanks,

Hi @markus7017 ,

after some issues, I made it to openHAB 5.0.3 and the latest DEV Binding, can you tell us, what is new, so we now what to test?

What I can say so far is that triphase warning is still present, but it seems that the pmmini Watt is updating now correct. The new EM mini gen4 is missing its total kWh channels. WS90 is found automatically in the THING inbox. The direction Channels are looking not OK at the moment:

the percipation channel is not working probably. when creating an item you have to choose a dimension first, otherwise there is a 400 error. I choosed lenght

It will be based on the latest merged PR

This will not include PRs for Plus/Pro Dimmers, enhanced RGBW support, Lora Addon and WS90

I just haven‘t the time for the review process

MaBe I could get in the PM Mini fix

Hi @markus7017

thanks a lot for the DEV update. The WS90 channels get created and update just fine. I see the same issue on the direction channels as described by @alaub81

Also I’m seeing WebSocket Errors like this:

2025-12-17 21:18:25.727 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellybluws90-286847efaefb: BLU event oh-blu.scan_result received from address 28:68:47:ef:ae:fb, pid=0 (JSON={"src":"shellyplusplugs-a0a3b3e91890","dst":"openhab-172.17.0.3","method":"NotifyEvent","params":{"ts":
1766002707.60,"events":[{"component":"script:1","id":1,"event":"oh-blu.scan_result","data":{"addr":"28:68:47:ef:ae:fb","name":"SBWS-90CM","rssi":-82},"ts":1766002707.60}]}})
2025-12-17 21:18:25.727 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellybluws90-286847efaefb: BLU Device SBWS-90CM discovered, mapped to serviceName shellybluws90-286847efaefb
2025-12-17 21:18:25.738 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellybluws90-286847efaefb: BLU event oh-blu.data received from address 28:68:47:ef:ae:fb, pid=69 (JSON={"src":"shellyplusplugs-a0a3b3e91890","dst":"openhab-172.17.0.3","method":"NotifyEvent","params":{"ts":176600
2708.02,"events":[{"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":69,"Illuminance":0,"Rain":0,"Speed":[0.6,1],"UVIndex":0,"Direction":[61],"addr":"28:68:47:ef:ae:fb","rssi":-82,"packet":"40 00 45 05 00 00 00 20 00 44 3c 00 44 64 
00 46 00 5e d4 17"},"ts":1766002708.02}]}})
2025-12-17 21:18:25.739 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplusplugs-e465b8b5b3fc: WebSocket error
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
	at org.openhab.binding.shelly.internal.api2.ShellyBluApi.onNotifyEvent(ShellyBluApi.java:292) ~[?:?]
	at org.openhab.binding.shelly.internal.api2.Shelly2RpcSocket.onText(Shelly2RpcSocket.java:268) ~[?:?]
	at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:70) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.annotated.OptionalSessionCallableMethod.call(OptionalSessionCallableMethod.java:68) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onTextMessage(JettyAnnotatedEventDriver.java:301) ~[?:?]
	at org.eclipse.jetty.websocket.common.message.SimpleTextMessage.messageComplete(SimpleTextMessage.java:69) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.appendMessage(AbstractEventDriver.java:67) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onTextFrame(JettyAnnotatedEventDriver.java:287) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:152) ~[?:?]
	at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:326) ~[?:?]
	at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:202) ~[?:?]
	at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:225) ~[?:?]
	at org.eclipse.jetty.websocket.common.Parser.parseSingleFrame(Parser.java:259) ~[?:?]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:459) ~[?:?]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:440) ~[?:?]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[?:?]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[?:?]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[?:?]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[?:?]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[?:?]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[?:?]
	at java.lang.Thread.run(Thread.java:1583) [?:?]
2025-12-17 21:18:25.742 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplusplugs-e465b8b5b3fc: Closing Rpc API (socket is connected, discovery=false)
2025-12-17 21:18:25.744 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplusplugs-e465b8b5b3fc: WebSocket connection closed, status = 1006/Disconnected
2025-12-17 21:18:25.744 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplusplugs-e465b8b5b3fc: Closing Rpc API (socket is disconnected, discovery=false)

Thanks!

DEV builds are updated to fix channel naming and the Websocket Error

1 Like

Hi @markus7017

thanks, but I don’t see any change. I did upgrade to the new version and see both issues still, the channel naming and the WebSocket error.

openhab> bundle:list | grep -i shel
361 │ Active │  80 │ 5.1.0.202512171715    │ openHAB Add-ons :: Bundles :: Shelly Binding
openhab> bundle:stop 361
openhab> bundle:uninstall 361                                                                                                                                                                                                                                    
openhab> bundle:install https://github.com/markus7017/myfiles/raw/refs/heads/master/shelly/org.openhab.binding.shelly-5.1.0-SNAPSHOT.jar
Bundle ID: 362
openhab> bundle:start 362
openhab> bundle:list | grep -i shel
362 │ Active │  80 │ 5.1.0.202512181522    │ openHAB Add-ons :: Bundles :: Shelly Binding


did you removed the things and re-discovered?

Hi @markus7017

yes, I did - multiple times. I removed everything including the binding and reinstalled / rediscovered. I still see the same behavior like with version 5.1.0.202512171715. Even the missing unit for the Precipitation item. Maybe I need to delete the cache and/or restart OH?

@alaub81 @Hundertvolt1 is the new DEV build working for you?

Thanks!

I had to revert to an older version, because all my BLUGW Devices aren’t working fine and I don’t have time at the moment for debugging. Perhaps someone is seeing the same behaviour, that all Things, which has enabled BLUGW are getting the websocket error randomly. And some of my BLU Device Items didn’t get updates.

That’s never a bad troubleshooting idea, I think.

… I did and I don’t see anything different than before. Dunno what else to try :man_shrugging:

Try the updated DEV build, I think I found it

@alaub81 I think this was caused by the NPE I fixed in between

Hi @markus7017

thanks, I updated to the latest DEV build and can confirm the channel names as well as the unit being fixed :+1:

I let the WS90 rediscover and added the thing. But I’m still seeing an error on every data transmission:

Unable to process Rpc message (Index 1 out of bounds for length 1)

2025-12-20 13:35:30.517 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellybluws90-286847efaefb: BLU event oh-blu.data received from address 28:68:47:ef:ae:fb, pid=149 (JSON={"src":"shellyplusplugs-a0a3b3e91890","dst":"openhab-172.17.0.3","method":"NotifyEvent","params":{"ts":1766234136.66,"events":[{"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":149,"Illuminance":4870,"Rain":1,"Speed":[0,0.5],"UVIndex":0,"Direction":[87],"addr":"28:68:47:ef:ae:fb","rssi":-81,"packet":"40 00 95 05 58 6e 07 20 01 44 00 00 44 32 00 46 00 5e fc 21"},"ts":1766234136.66}]}})
2025-12-20 13:35:30.518 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8b5b3fc: Unable to process Rpc message (Index 1 out of bounds for length 1): {"src":"shellyplusplugs-a0a3b3e91890","dst":"openhab-172.17.0.3","method":"NotifyEvent","params":{"ts":1766234136.66,"events":[{"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":149,"Illuminance":4870,"Rain":1,"Speed":[0,0.5],"UVIndex":0,"Direction":[87],"addr":"28:68:47:ef:ae:fb","rssi":-81,"packet":"40 00 95 05 58 6e 07 20 01 44 00 00 44 32 00 46 00 5e fc 21"},"ts":1766234136.66}]}}
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
	at org.openhab.binding.shelly.internal.api2.ShellyBluApi.onNotifyEvent(ShellyBluApi.java:292) ~[?:?]
	at org.openhab.binding.shelly.internal.api2.Shelly2RpcSocket.onText(Shelly2RpcSocket.java:268) ~[?:?]
	at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:70) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.annotated.OptionalSessionCallableMethod.call(OptionalSessionCallableMethod.java:68) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onTextMessage(JettyAnnotatedEventDriver.java:301) ~[?:?]
	at org.eclipse.jetty.websocket.common.message.SimpleTextMessage.messageComplete(SimpleTextMessage.java:69) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.appendMessage(AbstractEventDriver.java:67) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onTextFrame(JettyAnnotatedEventDriver.java:287) ~[?:?]
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:152) ~[?:?]
	at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:326) ~[?:?]
	at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:202) ~[?:?]
	at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:225) ~[?:?]
	at org.eclipse.jetty.websocket.common.Parser.parseSingleFrame(Parser.java:259) ~[?:?]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:459) ~[?:?]
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:440) ~[?:?]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[?:?]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[?:?]
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[?:?]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[?:?]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[?:?]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[?:?]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[?:?]
	at java.lang.Thread.run(Thread.java:1583) [?:?]

The WS90 sends 2 data packets, one is fine and the other not. This one is fine:

2025-12-20 13:43:41.002 [DEBUG] [ng.shelly.internal.api2.ShellyBluApi] - shellybluws90-286847efaefb: BLU event oh-blu.data received from address 28:68:47:ef:ae:fb, pid=205 (JSON={"src":"shellyplusplugs-a0a3b3e91890","dst":"openhab-172.17.0.3","method":"NotifyEvent","params":{"ts":1766234621.27,"events":[{"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":205,"Battery":100,"Pressure":1004.4,"Dewpoint":3.11,"Voltage":2.5,"Humidity":84,"Temperature":[5.6],"Precipitation":2,"addr":"28:68:47:ef:ae:fb","rssi":-83,"packet":"40 00 cd 01 64 04 58 88 01 08 37 01 0c c4 09 2e 54 45 38 00 5f 14 00"},"ts":1766234621.27}]}})

This one is not:

2025-12-20 13:43:55.583 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8b5b3fc: Unable to process Rpc message (Index 1 out of bounds for length 1): {"src":"shellyplusplugs-a0a3b3e91890","dst":"openhab-172.17.0.3","method":"NotifyEvent","params":{"ts":1766234635.89,"events":[{"component":"script:1","id":1,"event":"oh-blu.data","data":{"encryption":false,"BTHome_version":2,"pid":207,"Illuminance":3650,"Rain":1,"Speed":[0,0.7],"UVIndex":0,"Direction":[248],"addr":"28:68:47:ef:ae:fb","rssi":-79,"packet":"40 00 cf 05 c8 91 05 20 01 44 00 00 44 46 00 46 00 5e e0 60"},"ts":1766234635.89}]}}

Also, adding the Item for Precipitation is still not good. By default a Number type is proposed. Changing this to Number:Length leads to UNDEF:

2025-12-20 13:58:39.420 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WS90_Precipitation' changed from NULL to UNDEF (source: org.openhab.core.thing$shelly:shellybluws90:286847efaefb:sensors#precipitation)

Anyhow, pretty close!

crap, it seems that also this fix got lost, check updated DEV build

Hi @markus7017 latest dev build looks good so far! BLU Gateway devices also stable again.

3 things, I found in my 5min test for the WS90:

  • Wind and Gust Direction are set as km/h , they have to preset to angle °
  • Precepation should set to length and unit mm
  • Gust Direction isn’t getting updates

will test everything in the next 24h and will share my results. Thank you again for your great work!