Shelly Binding

Dear HT and HT Plus users…

after trying, reading, frustation and more I find now the rootcause, why the HT plus are not like the HT
send to my two DEV and TEST system every 10 min their values…

HT’s are using CoIoT and sending more or less every 10 min to all clients, in my case my three system their values and OH and all systems are using them. All my other used Shelly Products act like that. Multiable use on different system from different sensors.

The HT PLUS do not have any more CoIoT. They use now WEBSOCKETS. WOW something new, I have not heard so far about that.
When creating the first the ITEM on the OH system the information for the WEBSOCKET is created and sended to the HT PLUS configuration.

This means, that only ONE, (1) OH system is able to get the values from the HT’s every 10 min.
I was not aware of this that GEN2 devices with battery (USB Powered in my case) only works this way. Normal GEN2 devices line, like my Shelly plus 1 with his AddOn works like before without this settings for WEBSOCKET.

I found this in the documenation for OH under chapter Shelly:

Generation 2: WebSockets

The Plus and Pro series of devices use WebSockets for device communication. Usually the binding establishes a WebSocket connection to the device (http port 80). However, battery powered devices like the Plus HT are not reachable while the device is in sleep mode. For those the binding sets up a so called “Outbound WebSocket” during device initialization. Afterwards the device wakes up and calls the configured URL, which is the processed by the binding. The device UI shows the URL when active. Battery powered devices could only report events to a single host, take care if you have multiple openHAB instances on the same network.

In the config from device it looks like that:

As summery for me, it’s now over, to have three 1:1 configed OH systems, which are all the time getting from all sensors all their data…

Have a issue free weekend OH and Shelly users…

That’s not correct

  • The binding creates a WebSocket connection initializes and setups a listener (inbound WebSocket)
  • Every time something changed on the device side you’ll see an event coming from the device through WebSocket. This is used by the binding to updated channel information
  • I’m 97% sure you could have more than 1 instance as a host, every of them registering their own WebSocket

Re: Shelly HT / battery powered devices: There was a bug holding the thing from switching to ONLINE status. This has been fixed in between on the 4.2.x branch, I’m not sure if there is a backport to 4.1.x

Usually my DEV buiild provides up-to-date implementation and device support. Try it.
I’m currently working to merge several PRs to get the enhancements/fixes into the 4.2.x branch. Afterwards I’ll create an up-to-date DEV build (it’s a hazzle to maintain multiple branches at the same time)


I have problem with adding SHelly Blu Motion as Blu Motion - it does not work. But if I add this as Shelly Blu Button it works. I’m using Openhab 4.1.1 stable.

is the BLU gw enabled in the thing config?
get tge acript installed and is running?

Thanks Markus. I will anyway Update to 4.2, when it has been released.
So far I have nothing found about more than one target host.
Not in the OH documentation, or in the GEN2 API documentation from Shelly.
Also it is not possible to add more than one target host in the UI from the Shelly itself.

Each application registers to the device (creating a web socket). AFAIK they support up to 4 or 5, but never tried that. Just try it out and let me know.

I have deleted the ITEMs and the THING from my dev System and created them new.
After wake it up, the OH status was changed from unknown, to online.
Then I waked him up, and was logging on app ui.
Result is, that the new configuration from my DEV System.
So it changed to the last used System.
See here:

My opinion is, that also the UI do not support more that one host

The other thing, you already reported, that the current 4.1.1-1 has an bug, that it hide
the HT plus from wake up.
yes, I have had to wake him up by hand today. He stoped report at 04:00am tonight.

Yes, BLu gw is enabled in thing config and oh-blu-scanner.js is installed on shelly. I can manually add blumotion as blu button and it seems to work, but if I’m trying to add is as blu motion type it has status: ERROR:COMM

Don‘t add the BLU motion thing manually, this will be dine automatically the script reports a new device. did you paired the motion with the shelly?
try rebooting the shelly

Hello @markus7017

my three OH 4.1.1-1 systems (PROD,TEST,DEV) have yesterday before high noon, now got the 4.2 DEV Binding for Shelly. I was struggeling a little bit with the installation, but after running “feature:install openhab-transport-coap” it work on all systems.
At least the stability for the PROD system, were the host for the two HT Plus is entered seems to be working stable now again.
So fine, that the DEV 4.2 binding is now doing his job again. Hope to see this in an offical 4.2. version.

So cross the fingers, that there will be a solution for a mulitiple setup for WEBSOCKETS and OH 4.x and Shelly HT plus.

Thanks for you effort!

Hi, did you mean pairing blumotion with Shelly Ble Debug Application ? Or setting it up in Shelly Smart Control App ?

And one more question - Should I only turn bluetooth on Shelly Wifi device ? It is forbidden to switch on Bluetooth Gateway on it ?

I’ve got the impression the above discussion is also around adding BLU devices?

I’m trying to add a Shelly BLU Door/Window, and I followed the instructions, but the device doesn’t show up in the inbox. Also not when I scan the Shelly binding.

The Shelly BLU Door/Window was already paired with the Shelly Plus 1PM before I tried adding it to openHAB. So I deleted it from the Shelly cloud, and added it again (after I had enabled “BLU Gateway Support” in the openHAB thing configuration of the Shelly device acting as gateway).

I tried rebooting above mentioned Shelly Plus 1PM.

Still nothing.

Please check if the script was copied to your Plus 1 PM.

I have one BLU Door/Window paired with a Plus 2PM and it did show up in my inbox, not straight away and not after a scan, but couple of minutes later. It is also listed in shelly manager.

Aha, you are a savior!

The script was there:

I thought pressing the ‘play’ button was a good idea. Turned out this actually stopped the script, so I pressed it again. And then the device was found. Hooray!

Maybe something to include in the binding documentation?

Great it is working now.
But I don’t think, this is something to be documented, as there should be no need to do this.
If you check my screenshot, ther is no play button and I did not do anything.

Sometimes there’s a long interval (several seconds) between the actual state change of a switch (through the button or the Shelly app) and the registration of this state change in openHAB. Conversely, changing the state through openHAB has immediate result.

Is this a known issue? Is there a way I can log this?

This might be due to the usage of Shelly cloud.
I have mapped anything to just communicate locally, even my IX 3 or 4 send commands directly to other Shelly devices ( using Http API) and I do not see delays.

You mean you don’t use the Shelly binding? And send HTTP’s through rules?

An example:

I only use one of the four Shelly RGBW2 channels, but the physical button always turns on all four channels. If all four channels are ON, and then the only working channel is turned OFF through openHAB or the Shelly app, the remaining three channels stay ON. That means that if the physical button is next pressed, it turns these three channels OFF, rather than doing what the user expects: turning the only used channel ON.

Therefore I added the remaining three channels as items, and created a group for them, and wrote the following rule:

rule "Niet-gebruikte LED-lampjes uit"
    Item Ledlampjes_keuken_nietgebruikt_brightness changed
    if (Ledlampjes_keuken_nietgebruikt_brightness.state === ON) {

I just pressed the physical button, with this logs as result:

09:25:49.924 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_brightness' changed from 0 to 100
09:25:49.924 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'Shelly_verlichtingen' changed from OFF to ON through Ledlampjes_keuken_brightness
09:25:49.925 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'Alle_verlichting' changed from OFF to ON through Shelly_verlichtingen
09:25:49.926 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_Power_Consumption' changed from 0 W to 18 W
09:26:50.003 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_2_brightness' changed from 0 to 100
09:26:50.004 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'Ledlampjes_keuken_nietgebruikt_brightness' changed from OFF to ON through Ledlampjes_keuken_2_brightness
09:26:50.004 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_2_brightness' changed from 100 to 13
09:26:50.006 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_3_brightness' changed from 0 to 100
09:26:50.007 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_4_brightness' changed from 0 to 100
09:26:50.008 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_Event_Count' changed from 0 to 1
09:26:50.008 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_Power_Consumption' changed from 18 W to 18.5 W
09:26:50.035 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Ledlampjes_keuken_nietgebruikt_brightness' received command OFF
09:26:50.035 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Ledlampjes_keuken_2_brightness' received command OFF
09:26:50.035 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Ledlampjes_keuken_3_brightness' received command OFF
09:26:50.036 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Ledlampjes_keuken_4_brightness' received command OFF
09:26:50.036 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Ledlampjes_keuken_2_brightness' predicted to become OFF
09:26:50.036 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Ledlampjes_keuken_3_brightness' predicted to become OFF
09:26:50.036 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_2_brightness' changed from 13 to 0
09:26:50.037 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Ledlampjes_keuken_4_brightness' predicted to become OFF
09:26:50.037 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_3_brightness' changed from 100 to 0
09:26:50.038 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Ledlampjes_keuken_4_brightness' changed from 100 to 0
09:26:50.038 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'Ledlampjes_keuken_nietgebruikt_brightness' changed from ON to OFF through Ledlampjes_keuken_4_brightness

As you can see, there’s a delay of a full minute (lines 4 and 5 of the log) between openHAB’s (immediate) registration of the button push (since the switch of the used channel was registered) and the registration of the brightness change of the second channel…