openhab> bundle:list | grep -i shelly
368 │ Active │ 80 │ 5.2.0.202605080611 │ openHAB Add-ons :: Bundles :: Shelly Binding
Running it since 9/5, and no issues yet.
I have 2 smoke sensors, too. All good on my side. Perhaps check if the correct outbound web socket connection is set on the devices.
What is the different between this one which is online, and the Rest?
Thanks for the reply. I just checked the outbound websocket. All devices have got the same settings:
- Enabled
- ca.pem
- ws://:8080/shelly/wsevent
Is this correct?
IP address of your openhab server is missing. or did you delete it to anonymize it?
Yes. Sorry.
I can not see any difference.
Nevertheless, I now delete all smoke things and re-added them. Let’s see what will happen.
I Guess the difference is the openhab version…I am using the new oh5.2 snapshot already
That is true. I am on OH 5.1.4.
But, after deleting and re-adding the things, this morning they are all online.
@markus7017, I did have an issue with BLU (Motion) devices (shellyblumotion), which sometimes didn’t seem to transfer anything, until I (again) re-initialized the gateway Thing. I thought I’d delete all Things, and recreate them, as your readme states.
Then openHAB didn’t find the BLU Things during the scan, but I’ve seen that before. I suppose they’re in some kind of cache. I tried adding the Things manually, but no response…
I created a shellyblumotion Thing, with Thing UID and MAC address set to the MAC address (without colons). That’s all I should set, right? (I also made sure the gateway Things have Enable BLU Gateway Support enabled.)
Does anyone have any idea how to resolve this? It’s quite critical, as the lady of the house expects the motion detectors to trigger lights. If this doesn’t work, I’ll be in trouble. 
Mmm, I sort of figured out how to fix the real world.
As before (which is the reason I started the delete-everything-crusade), I had to disable, and then re-enable the gateway Thing. I assume that, because I had first created the IP Things, and only then the BLU Things, I had to do that again now.
In any case, there is a problem with the binding, it seems… This need to re-enable comes back at a certain point, as I didn’t have the problem yesterday, but it was there this morning (and openHAB had not been restarted).
I had similar issues with older dev builds (last two dev builds are ok, I think) After restarting my openHAB setup, some of my BLU H&T sensors stoped getting new values. So I programmed a switch item and a rule, which disabled and then enabled the BLU GW Things, after that, all was running until next restart of openHAB. But I didn’t see that issue with the last two dev builds.
Are you on the latest dev build? I am on openHAB 5.1.4 and Shelly Binding 5.2.0.202605080611.
btw. My Motion Sensors are triggering my lights directly with a shelly js script, have a look at my GitHub repo: GitHub - alaub81/shelly · GitHub - it’s faster then using openHAB rules
By the way, when I disable a Shelly Thing, I see this in the regular logs:
09:26:50.234 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
Is that by design?
openhab> bundle:list | grep -i shelly
368 │ Active │ 80 │ 5.2.0.202605080611 │ openHAB Add-ons :: Bundles :: Shelly Binding
I assume the lights you control are also controlled via Shelly? My lights are controlled through the EnOcean binding.
Another issue, which I don’t understand at all, because everything worked yesterday, and I didn’t change anything. My BLU Motion devices don’t seem to transfer motion events to the channels, although they are registered in the logs…
yes, my lights are controlled by shelly relays
Hehe, it’s not supposed to happen, but it can happen if things are out of sync. When you disable a Thing, the ThingHandler goes through a “dispose procedure” to release all resources. From that point on, the ThingHandler can’t perform “normal duties” like updating the status, but some thread didn’t get the memo that it had been disposed, and still tried. Most likely the thread was never notified that it should shut down/abort when disposal of the handler was started.
Is this with one of the latest dev builds?
Yes, but maybe it’s not a Shelly issue: FroniusWattpilotHandler tried updating the thing status although the handler was already disposed - #3 by ErikDB