Shelly Binding


Is it possible to put shelly1 in and out of detached mode via OpenHAB?
The reason I’m asking is that our son likes to walk into our bedroom once he wakes up and hits the switch to light up the bedroom :smiley: I’d like to “disable” the switch between certain times or - advanced mode - light a smaller Wifi LED if the switch is pressed during that time.

Let it in detached Mode and do a nice rule for this :wink:

1 Like

fyi: There is a memory leak related to WebSocket handling (Plus / Pro series of devices). I’ll work on this at the weekend.

1 Like

Yes, I do something similar. All my Shelly’s run in detached mode, and I’m reliant on rules to turn the relay on/off depending on my logic. In my case I’m using the one switch to turn different sets of lights on/off depending on single press, double press, long press etc. I also run a timer to turn them off again unless I long press.

To see what I’m doing there, you could look at my logic: Not getting error statements when loading/parsing rules file - #16 by PaulL1

How would I do that? In detached mode OH only recognises a LONG_PRESSED for relay#button every other time.

I’m working with rulesDSL and this triggers…

Channel 'shelly:shelly:xxxx:relay#button' triggered
var trigger = receivedEvent
switch trigger { 		 
Do something 
case 'SHORT_PRESSED' : {
Do something else 


If you gets only ‘long pressed’ check your Shelly device…

I forgot to mention it’s a state switch, not a toggle switch.
I’d expect to see in the logs a LONG_PRESSED every time, but i only see it every other time, so a rule would only fire every other time as well…

With a Switch it doesn’t work…
I modified my Switches with a ballpen spring (Kugelschreiberfeder) and now I have these pushbuttons. Momentary function in Shelly Web-ui.
But in detached Mode…

1 Like

I’m using multiple shelly1 with OH 4.0.3, the problem I have is that the shelly binding does not update it’s button state when the physical button is pressed. It only updates when the “status” interval is up and device info is polled.

It used to work in OH 3.3, so what’s wrong here in 4.0.3? I see it uses Auto-ColoIt but also when I disable ColoIT on the device and it uses other api it doesn’t update quickly when pressed.

Is this a Shelly 1st generation or Plus/Pro device?
If Gen1 you have to enable CoIoT
If you have a Docker install, make sure that UDP CoAP Multicast is routed into the container or (better) activate the CoIOT peer mode of the Shelly and point it to the OH host. This can be done with the Shelly Manager or manually with the device UI.
Make sure to read the documentation, also for Advanced Users. Check the thread’s history, this topic has been discussed already 20 times.

Cheers & have a nice weekend

I’m running a Plus1PMMini in detached mode with the attached activation script to replicate with this Gen 2 device the activation_switch profiles: single_push for 42s light on, long_push for immediate toggle. This works very well.

I can toggle the switch via openHAB sitemaps. Then also the icon is properly set.

However, when the connected button is operated and the activationscript is executed, the channel relay#output which is linked as an item is not synchronised: I would expect that the switch in the sitemap is ON when the output is ON.

Any suggestion is very much appreciated.

Attached the configuration files

Shelly.GetStatus.json (808 Bytes)
Shelly.GetConfig.json (1.6 KB)
activationscript.txt (708 Bytes)

Hey @markus7017
Any chance of looking at Shellyplus 2pm - Addon channels not discovered when in cover mode · Issue #14 · markus7017/myfiles · GitHub ?


Hi @markus7017,

I did try to use the latest Shelly snapshot but received the bellow error:

Updating bundle org.openhab.binding.shelly /
12:19:43.450 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.shelly-4.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [276]
  Unresolved requirement: Import-Package: org.eclipse.californium.core; version="[2.7.0,3.0.0)"

	at org.eclipse.osgi.container.Module.start( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start( ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle( ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles( ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles( ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess( ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process( ~[?:?]
	at ~[?:?]

Hm … after bundle:uninstall looks better

Installing bundle org.openhab.binding.shelly /

the binding didn’t discover all of the things but usually I have to reboot them to make it discover almost all.

It has been discussed several times. You need to manually install coap services. In oh console: feature:install oh-transport-coap

I did.

Anyway, as a result seems Shelly Uni keep showing
Initializing or device in sleep mode.

Hi there,

I’m using a couple of Shellys now for a few weeks, a couple of Shelly Plus 2PM, one RGBW2 and two of the Shelly Plus i4 so far. I use them together with the OH binding. The devices work quite good so far, except one of the i4 devices. The connection between the openhab thing and the i4 gets frequently lost. The device itself remains working, the webinterface is reachable, events are properly displayed in the web interface of the i4. The way to re-establish the connection is to disable the thing and to re-enable it. However, the thing is displayed as online in the OH webinterface.
I use the text-based thing configuration, the behaviour is the same in OH 3.4 and OH 4.0.3.
Does someone experienced this as well or has any advice for me?
Thank you!

I have that for some I4 that is to far away from wifi router.

Same behaviour of my i4DC Shelly devices, even they are with excellent wifi coverage.
OH 4.0.2, 4.0.3 with Shelly binding stable & 4.1.0

I think Wifi connection is pretty good (RSSI around -58 dBm), since the i4 is connected to the Wifi via a Fritz repeater. Maybe this causes the issue? The other i4 is connected to the FritzBox directly.