But also here: if the router is down, I can’t check these logs… And I don’t assume there’s a log file on the Shelly device itself?
Edit: I assume you mean these messages will continue to be logged.
@markus7017 restarting the THING which has an enabled BLU Gateway, will restart the shelly, or just the script on the device? Or what should happen on the shelly device?
Hi All, it seems the Shelly Pro RGBWW PM is not supported by the binding in OH5.1, does anyone know if its supported in later releases? Thanks
About the problem with BLU devices after WiFi connection loss: I ran another test, and simply disabling and re-enabling the BLU Gateway Things (in openHAB) seems to do the trick for the BLU Button and BLU Door/Window.
However, restarting the Thing does not seem to suffice for the BLU motion…
I’ll send you my logs, @markus7017.
@Nadahar you have my Debug Logs, were it Looks the same. Channels Report the values but they are not more visable in OH. The Channels from the thing will not more get updates.
After disable and enable the thing, all is fine, since 1,5 day.
Edit: And then it stop 2h ago… 
I’m sorry, but I don’t think I’m able to figure this out, since I don’t have any devices and can’t debug or test what happens under different circumstances. I’m therefore hoping that @markus7017 will make sense of it.
Not yet, there is a PR, but this requires more work and has low priority
This restarts the thing handler, re-creates tge WS connection and restarts the scirpt on the Shelly device.
But that’s apparently not enough for the BLU Motion devices…
I’ve been speculating it perhaps the script on the Shelly devices must be restarted if the WS connection is reestablished after a network outage. The reason I have a slight suspicion of this, is that I saw in the logs that they refer to the outgoing port that was used for the WS connection (incoming port is 80, but outgoing is random). It so, they won’t “find” the recipient once the connection has been reestablished, because a new random port is used, which would explain “no DST”.
I also think that this ‘port designation’ is a/the problem.
That sucks 
I’m going to give this to Claude and get it to create me a jar with support
@Nadahar What’s so funny?
So far good progress in 30minutes
EDIT: Done, now supported and now working.
Part A — Binding now persists
The clean mechanism: I overwrote the jar the Shelly feature resolves from in the persistent maven repo:
/var/lib/openhab/tmp/mvn/…/org.openhab.binding.shelly-5.1.0.jar ← now your custom build
- shelly stays in the feature list, so the feature keeps providing the californium (CoAP) dependency the binding needs — that was the trap when I briefly removed it (the binding couldn’t resolve and all 6 Shellys dropped; recovered immediately).
- Applied live via bundle:update+refresh. On any restart, openHAB loads my code whether it reads from the felix cache or re-resolves from maven — both now point at my build.
- Stock jar saved as *.jar.stock.bak; config backed up as org.openhab.addons.cfg.bak.
One caveat: an openHAB version upgrade will replace that jar with a new stock version, so the custom binding must be re-applied after upgrades (source + built jar are retained on the host for that). All 5 other Shelly devices are unaffected and ONLINE.
Part B — 3 white-channel items, linked
┌──────────────────┬───────────────────┬─────────────────────────────┬───────┐
│ Item │ Label │ → Channel │ State │
├──────────────────┼───────────────────┼─────────────────────────────┼───────┤
│ Vergola_Channel1 │ Vergola Channel 1 │ relay1#brightness (light:0) │ 100 │
├──────────────────┼───────────────────┼─────────────────────────────┼───────┤
│ Vergola_Channel2 │ Vergola Channel 2 │ relay2#brightness (light:1) │ 0 │
├──────────────────┼───────────────────┼─────────────────────────────┼───────┤
│ Vergola_Channel3 │ Vergola Channel 3 │ relay3#brightness (light:2) │ 0 │
└──────────────────┴───────────────────┴─────────────────────────────┴───────┘
Created as Dimmer items (dimmable white strips; ON/OFF still work in rules) following your Vergola_… naming, category light, tagged Lighting/Point. The distinct states (100/0/0) confirm each item drives its own physical channel. (Channels 4 & 5 exist on the thing but are left unlinked.) Cleaned up the temporary test item/link too.
Two notes:
- Channel 1 reads 100% — that’s the device’s actual current state (it’s the heavily-used output); I didn’t change any light levels. Let me know if you want it off.
- I haven’t forced a full openHAB restart to prove persistence (it briefly takes the whole system down). The mechanism is sound, but if you’d like 100% confirmation I can restart openHAB at a moment that suits you and verify the Vergola comes back ONLINE on its own.
On my setup restarting all BLU GW Things is not working. But I didn’t figured out, what really helps to get all my BLU Devices working again. What I tried: restarting the BLU Thing which doesn’t get any updates and restarting some of my perhaps miss functional shelly devices, but only the once with the BLU GW Script and also not all of them. Only thing we can say at the moment, That a wifi disconnection brings up the problem. But I think only restarting the oh-scanner script is not fixing the connection issue. I can’t test at the moment, but perhaps someone wit a small setup and perhaps only one BLU GW Thing running can test.
- Disable WIFI (router or access point restart)
- Check if after wifi coming back data is coming in to openHAB from the BLU devices
- if not, Restarting the BLU GW Thing by disable and enable again
- check again if data is coming in
- Restarting the BLU Device Things one by one
- check again for new data
- Restart the shelly device, where the blu gw script is running.
After that, we can see, what fixes the problem and perhaps @markus7017 can provide some fixes. And also we should have an eye on the no DST messages. perhaps they are related to this issue.
“Claude”. But sure, whatever floats your boat…
I have a Duo Gen3 bulb that the binding does not recognize (“shellyunknown”).
Manual selection of Duo also fails.
@markus7017 Would you want me to open an issue?
2026-06-02 10:10:51.069 [DEBUG] [org.openhab.binding.shelly.internal.ShellyHandlerFactory ] - Shelly Duo Kabuff: Create new thing of type shelly:shellybulbduo using ShellyLightHandler
2026-06-02 10:10:51.084 [DEBUG] [org.openhab.binding.shelly.internal.ShellyHandlerFactory ] - Thing handler for uid shelly:shellybulbduo:KabuffDuo added, total things = 17
2026-06-02 10:10:51.095 [DEBUG] [org.openhab.binding.shelly.internal.handler.ShellyLightHandler ] - Thing is using class org.openhab.binding.shelly.internal.handler.ShellyLightHandler
2026-06-02 10:10:53.140 [DEBUG] [org.openhab.binding.shelly.internal.handler.ShellyBaseHandler ] - shellybulbduo-kabuffduo: Config: Device address=, HTTP user/password=/<none>, update interval=60
Events: Button: false, Switch (on/off): false, Push: true, Roller: trueSensor: true, CoIoT: true
Blu Gateway=false, Range Extender: true
2026-06-02 10:10:53.141 [DEBUG] [org.openhab.binding.shelly.internal.handler.ShellyBaseHandler ] - shellybulbduo-kabuffduo: Start initializing for thing Shelly Duo Kabuff, type shellybulbduo, Device IP address 192.168.178.136, Device port none, Bluetooth device address none, Gen2: false, isBlu: false, alwaysOn: true, hasBattery: false, CoIoT: true
2026-06-02 10:10:53.194 [DEBUG] [org.openhab.binding.shelly.internal.handler.ShellyBaseHandler ] - shellybulbduo-kabuffduo: Unexpected API result: 404/Not Found
GET http://192.168.178.136/settings > Not Found
at org.openhab.binding.shelly.internal.api.ShellyHttpClient.innerRequest(ShellyHttpClient.java:223)
at org.openhab.binding.shelly.internal.api.ShellyHttpClient.httpRequest(ShellyHttpClient.java:115)
at org.openhab.binding.shelly.internal.api1.Shelly1HttpApi.getDeviceProfile(Shelly1HttpApi.java:131)
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.initializeThing(ShellyBaseHandler.java:364)
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.lambda$0(ShellyBaseHandler.java:213)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Yep, should be easy to add
In general you can’t use Gen1 things for Gen3 devices (totally different APIs)
I think I solved the WiFi reconnect issue, @ErikDB thanks for test support 
PR #20886 fixes issues on reconnect handling of the gateway devices and controlling the oh-scanner start/stop - see PR for details.
@ErikDB and others: I provided this build: myfiles/shelly/org.openhab.binding.shelly-5.2.0-SNAPSHOT-wifireconnect.jar at master · markus7017/myfiles · GitHub
Could you please do a test:
- BLU Motion / Button paired through a Plus hub. Disconnect hub from WiFi for 60 s, reconnect. Verify BLU channel updates resume without restarting the binding.
- Verify hub thing logs show “Script already running with current version, leaving it” on reinitialization when script version is unchanged.
On positive result I submit the PR for merge.
Up and running!
please try 3 reboots with some delays in between