There is also a native position channel when you activate “advanced channels”
The DEV version had not been installed. I deleted the manually detected shelly device, installed the above DEV Version and did a scan. The scan detected the correct device “shellyazplug”. Thank you @markus7017 for your advice!
I just realized that after cabibration the position channel appeared 
Now I just need to figure out how to update the shelly binding to the dev version
I‘m using also several Shelly 2PM Gen3 in Rollo Mode.
On my OH 5.0.3 with the prod Shelly binding I have as usual a channel for the position from 0-100 %
I trigger this channel, e.g. when it starts to rain with a rule an send the command to the Shelly, like here:
For me it has worked with a old Shelly 2.5 as well.
please disable/enable the thing, this restarts the scanner script on the device. The binding expects a device discovery packet (scan result) before processing data packets
- script sends scan result to the binding
- binding created a new thing in the Inbox
- you need to add the BLU thing
- then data packets get processed and create / update the channels
check device debug and oh loh for the disxovery procesd
did everything you told me before, I have a complete fresh setup with 5.1.0.M2, Only installed the dev binding you gave me:
bundle:list | grep -i "shelly"
272 │ Active │ 80 │ 5.1.0.202511111606 │ openHAB Add-ons :: Bundles :: Shelly Binding
I restarted the complete setup and also the device, where the openhab scanner is installed many times. All my other blu devices are in the inbox, only the weather station isn’t. Device Debug Log is showing data coming in from the weather station:
Parsed BTH data from device SBWS-90CM : {"encryption":false,"BTHome_version":2,"pid":206,"Battery":100,"Pressure":995.9,"Dewpo
int":4.71,"Voltage":2.6,"Humidity":94,"Temperature":[5.6],"Precipitation":29.8,"addr":"c0:2c:ed:aa:57:d5","rssi":-80,"packet":"4
I can see other blu devices with that kind of message:
New device found: address= 7c:c6:b6:72:bb:5f , name= SBHT-003C
but not from the weather station.
in openHAB log I can see these lines belonging to the weather station:
logs/openhab.log:2025-11-25 18:55:22.922 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
logs/openhab.log:2025-11-25 18:55:49.167 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
logs/openhab.log:2025-11-25 18:56:09.012 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
logs/openhab.log:2025-11-25 18:56:23.690 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
logs/openhab.log:2025-11-25 18:56:34.081 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
logs/openhab.log:2025-11-25 18:56:59.111 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
logs/openhab.log:2025-11-25 18:57:36.155 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - shellyplusplugs-e465b8414ef4: NotifyEvent oh-blu.data for unknown BLU device c0:2c:ed:aa:57:d5 or Thing in Inbox
So openHAB gets the messages. And also, There is no device type shown up, when I try to add it manually.
I also pressed the device button more than one time.
Perhaps the device is missing in binding? I can see it in the openhab scanner script on the shelly device.
@markus7017, which Shelly firmware version do you consider stable for the DEV binding?
I upgraded all my Gen1 devices to 1.4 and Plus/Pro to 1.7.1. For me it seems to be stable for daily use. However, I don‘t do realtime energy monitoring or comparable use cases
1 Like
I updated the 5.1 DEV build and fixed the fact that the thing type doesn’t show up, please retry the discovery and post the first lines of the device debug log, which shows the discovery of the device (initial messages including the mac address)
I can confirm that. Also have all devices on 1.7.1 and also all BLU Devices on the latest possible Version. Everything is stable since a few month now. 1.7.0 was very unstable.
1 Like
did you saw my note above?
Hi @markus7017 ,
yes saw it and just installed the newest 5.1. build. Now the weather station was in the inbox. I added it as THING, waited that it came online (good thing here is, that the weather station is delivering data in less than 5 seconds) and tried to add items to the channels. But…
there are way to less channels shown up, that’s already the advanced view. But if it is like with my blu mqtt script, I have to wait, until all sensor data is send once from the weather station. Will keep you updated on that. Thank you so much again 
that’s a problem, because I use the initial packet to create channels on thing initialization. The binding doesn’t re-checks every time to avoid overhead.
Try the updated build
perfect! Now all Channels are there.
Is it possible to configure the channels, so the correct icon is shown up by default, or this something openHAB core does?
I know from my script, that the wind packet has 2 values, one wind average and one wind gust, also the wind direction has these two in one packet.
At the moment the firmware of the shelly weather station is publishing the rain fall in mm since the station was setup the first time. I managed that with some calculations for rain in 1h and also rain in 24h. But I think that can also be done in an openHAB rule.
here are some bugs:
- Precipitation is not dimension m3 it is mm
- rain status has a temperature icon perhaps the switch icon is better
- that channel looks weird
the rest is looking good so far, I hav added an item to all channels and will have a look if the values are also correct. Nice job!
addendum:
following items are not getting values:
- Pressure
- Device Firmware
- Dew Point
- Illumination
- Precipitation
- UV Index
- Wind Speed
If you like to have a look into my mqtt script:
cheers
Andreas
Shelly Plus Plug UK no longer can be turned off and on from OH after firmware upgrade from 1.4.4- to 1.7.1. I had recently upgraded to openHAB 4.3.8 before the firmware upgrade and all Shelly devices were working without issue then. I can turn off/on the Shelly Plus Plug UK from the app and from its own HTTP interface, and openHAB will reflect the W, kWh and relay state in my items, but the actual turning off and on of the relay no longer works. I use password authentication on all my Shelly devices.
I’ve reset the device and reconfigured it manually, hoping to eliminate anything left over from the old firmware, but to no avail. I’ve disabled/re-enabled the thing, stopped and restarted the Shelly binding bundle, to no effect.
I turned on TRACE and then DEBUG on the binding and saw messages about the device including “Unable to process Rpc message (Update for invalid relay index)” but I don’t know enough to say it’s relevant. There was also a “API value null was mapped to UNKNOWN” message. There were also reports of WebSockets being successfully created.
I’ve searched github and here trying to find matches for these circumstances but have not spotted any. Any advice is appreciated.
Anyone else unable to update Shelly firmware via ShellyManager proxy in OpenHAB?
Devices and openHAB both have internet access right now, but I want to block the Shelly’s from the internet if updates can go through openHAB reliably.
openHAB 5.0.3, but I have this issue for as long as I can remember.
372 │ Active │ 80 │ 5.0.2.202509231052 │ openHAB Add-ons :: Bundles :: Shelly Binding
openHAB and Shelly’s are on a different vlan, firewall rules and UDP broadcast relay (IP Multicast 224.0.1.187, port 5683) are set up. Autodiscovery works fine, so I don’t think the firewall is the issue here.
Firmware Update
---
Updating device Kookplaat 1 (shelly:shellypmmini:E4B063E12304) with version prod, connection type=local
Update url: http://10.80.1.63/ota?url=http://10.40.0.10:8080/shelly/manager/ota%3FdeviceType%3DS3PM-001PCEU16%26version%3Dprod
Wait 1-2 minutes, then check device UI at [10.80.1.63](http://10.80.1.63), section Firmware.
Do not power-off or restart device while updating the firmware!
Log:
2025-11-29 11:39:11.791 [INFO ] [nternal.manager.ShellyManagerOtaPage] - shellypmmini-e4b063e12304: Firmware update initiated, device returned status Update initiated
2025-11-29 11:39:11.804 [INFO ] [nternal.manager.ShellyManagerOtaPage] - ShellyManager: Update firmware (deviceType=, version=, URL=)
2025-11-29 11:39:11.804 [INFO ] [y.internal.manager.ShellyManagerPage] - ShellyManager: No firmware files found for device type
2025-11-29 11:39:11.804 [WARN ] [nternal.manager.ShellyManagerOtaPage] - ShellyManager: Unable to find firmware for device type , version= (URL=)
2025-11-29 11:39:20.493 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellypmmini-e4b063e12304: INFO: New firmware available: current version: 1.7.0-, new version: 1.7.1
1 Like
Further investigation shows there might be a problem with the setting of defaultUserId in the binding’s configuration when Plus/Pro devices are being used, where the value is not admin, because there are HTTP 401 codes reported in the binding’s DEBUG log when I try to change the relay state from openHAB. I have a number of Shelly 1 devices that use a common defaultUserId and defaultPassword with no problem. I have the one shellyplusplug and it claims to use the defaultUserId at one stage, and I can get status updates in the binding.
2025-11-29 12:23:55.295 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellypluspluguk-ffffffffffff: Using default userId xxxxxx from binding config
2025-11-29 12:23:55.298 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellypluspluguk-ffffffffffff: Using default password from bindingConfig (userId=xxxxxx)
but later when I try to change the relay state:
2025-11-29 12:23:55.507 [TRACE] [shelly.internal.api.ShellyHttpClient] - shellypluspluguk-ffffffffffff: HTTP POST http://shl.pls.plg.ip/rpc
Accept-Encoding: gzip
User-Agent: Jetty/9.4.54.v20240208
Authorization: Digest username="admin", realm="shellypluspluguk-ffffffffffff", uri="/rpc", nonce="1764419035", cnonce="bda3e8f", nc="00000001", qop="auth",response="db68bc7bdcbcc1c958dbffff75c5d6cd97ef54628f08bf5852c64fff3b07246b8", algorithm="SHA-256",
Content-Type: application/json; charset=UTF-8
{"id":1754638223,"src":"openhab-my.oh.svr.ip","method":"Shelly.GetStatus"}
2025-11-29 12:23:55.517 [TRACE] [helly.internal.api2.Shelly2RpcSocket] - Table Lamp: Inbound Rpc message: {"id":513782364,"src":"shellypluspluguk-ffffffffffff","dst":"openhab-my.oh.svr.ip","error":{"code":401,"message":"{\"auth_type\": \"digest\", \"nonce\": 1764419035, \"nc\": 1, \"realm\": \"shellypluspluguk-ffffffffffff\", \"algorithm\": \"SHA-256\"}"}}
2025-11-29 12:23:55.525 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellypluspluguk-ffffffffffff: NotifyStatus update received: {"id":513782364,"src":"shellypluspluguk-ffffffffffff","dst":"openhab-my.oh.svr.ip","error":{"code":401,"message":"{\"auth_type\": \"digest\", \"nonce\": 1764419035, \"nc\": 1, \"realm\": \"shellypluspluguk-ffffffffffff\", \"algorithm\": \"SHA-256\"}"}}
When trying to change the relay state I get 401 codes, which might suggest a mixing of admin and my different defaultUserId. Setting userId="admin" for the shellyplusplug thing does not remove the 401 errors, and it’s not advertised as being a valid property for that thing type anyway.
Are there other users of the 4.3.8 version of the binding with defaultUserId set in the binding configuration to a non-admin value, and using Plus/Pro devices with no issues?
After upgrading from 5.0.2.202511091248 to 5.0.2.202511100759 the websocket error for shellypmmini is back. All other Shelly’s work as expected.
==> /var/log/openhab/openhab.log <==
2025-11-30 11:16:55.759 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellypmminig3-e4b063e1a400: NotifyStatus update received: {"src":"shellypmminig3-e4b063e1a400","dst":"openhab-10.40.0.10","method":"NotifyStatus","params":{"ts":1.76449781377E9,"pm1:0":{"apower":123.6}}}
2025-11-30 11:16:55.759 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellypmminig3-e4b063e1a400: Channel device#heartBeat updated with 2025-11-30T11:16:55.000+0100 (type class org.openhab.core.library.types.DateTimeType).
==> /var/log/openhab/events.log <==
2025-11-30 11:16:55.759 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ShellyPMWerkplekBarDeviceHeartBeat' changed from 2025-11-30T11:16:19.000+0100 to 2025-11-30T11:16:55.000+0100
==> /var/log/openhab/openhab.log <==
2025-11-30 11:16:55.759 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - WebSocket error
java.lang.IndexOutOfBoundsException: Index 10 out of bounds for length 1
at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) ~[?:?]
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) ~[?:?]
at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) ~[?:?]
at java.util.Objects.checkIndex(Objects.java:385) ~[?:?]
at java.util.ArrayList.get(ArrayList.java:427) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiClient.updateRelayStatus(Shelly2ApiClient.java:322) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiClient.fillDeviceStatus(Shelly2ApiClient.java:240) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiRpc.onNotifyStatus(Shelly2ApiRpc.java:663) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2RpcSocket.onText(Shelly2RpcSocket.java:251) ~[?:?]
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-11-30 11:16:55.761 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellypmminig3-e4b063e1a400: Closing Rpc API (socket is connected, discovery=false)
==> /var/log/openhab/events.log <==
2025-11-30 11:16:55.761 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellypmmini:E4B063E1A400' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Unexpected error: WebSocket error
==> /var/log/openhab/openhab.log <==
2025-11-30 11:16:55.762 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellypmminig3-e4b063e1a400: WebSocket connection closed, status = 1006/Disconnected
2025-11-30 11:16:55.762 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellypmminig3-e4b063e1a400: Closing Rpc API (socket is disconnected, discovery=false)
5.0.2.202511091248:
2025-11-30 11:27:57.160 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellypmmini-e4b063e1a400: NotifyStatus update received: {"src":"shellypmminig3-e4b063e1a400","dst":"openhab-10.40.0.10","method":"NotifyStatus","params":{"ts":1.76449847511E9,"pm1:0":{"apower":108.0,"current":0.529}}}
2025-11-30 11:27:57.160 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellypmmini-e4b063e1a400: Channel device#heartBeat updated with 2025-11-30T11:27:57.000+0100 (type class org.openhab.core.library.types.DateTimeType).
2025-11-30 11:27:57.161 [DEBUG] [helly.internal.api2.Shelly2RpcSocket] - Shelly PM Werkplek bar: Unable to process Rpc message (Update for invalid relay index): {"src":"shellypmminig3-e4b063e1a400","dst":"openhab-10.40.0.10","method":"NotifyStatus","params":{"ts":1764498475.11,"pm1:0":{"apower":108.0,"current":0.529}}}
The proxy mode is not supported for Plus/Pro devices. Allterco doen‘t provide a public firmware repo, which could be used to buid the proxy mode
2 Likes