Shelly Binding

Let’s say V3: yes, V2: 95%
I need to find a way to efficiently manage the code for both versions. However, this might be blocked by the review process. I saw a post that only bug fixes will make it into 2.5.10. Let’s see

1 Like

Hello Markus,

I’m using OH 2.5.9 and a shelly plug with version 20200827-070415/v1.8.3@4a8bc427
With your new binding, it is now possible to switch on the Power and Status LED.
Here is the logfile for it.

2020-10-04 19:37:47.793 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_heartBeat changed from 2020-10-04T19:37:17.000+0200 to 2020-10-04T19:37:47.000+0200

2020-10-04 19:37:47.881 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_Laufzeit changed from 857210 s to 857240 s

2020-10-04 19:37:47.891 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Meter_lastUpdate changed from 2020-10-04T19:37:17.000+0200 to 2020-10-04T19:37:48.000+0200

2020-10-04 19:37:55.134 [ome.event.ItemCommandEvent] - Item ‘GartenRasenpumpe_Device_powerLed’ received command ON

2020-10-04 19:37:55.166 [nt.ItemStatePredictedEvent] - GartenRasenpumpe_Device_powerLed predicted to become ON

2020-10-04 19:37:55.194 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_powerLed changed from OFF to ON

2020-10-04 19:37:55.540 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_heartBeat changed from 2020-10-04T19:37:47.000+0200 to 2020-10-04T19:37:55.000+0200

2020-10-04 19:37:56.279 [ome.event.ItemCommandEvent] - Item ‘GartenRasenpumpe_Device_powerLed’ received command OFF

2020-10-04 19:37:56.302 [nt.ItemStatePredictedEvent] - GartenRasenpumpe_Device_powerLed predicted to become OFF

2020-10-04 19:37:56.340 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_powerLed changed from ON to OFF

2020-10-04 19:37:56.639 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_heartBeat changed from 2020-10-04T19:37:55.000+0200 to 2020-10-04T19:37:56.000+0200

2020-10-04 19:37:57.293 [ome.event.ItemCommandEvent] - Item ‘GartenRasenpumpe_Device_statusLed’ received command ON

2020-10-04 19:37:57.322 [nt.ItemStatePredictedEvent] - GartenRasenpumpe_Device_statusLed predicted to become ON

2020-10-04 19:37:57.357 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_statusLed changed from OFF to ON

2020-10-04 19:37:57.658 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_heartBeat changed from 2020-10-04T19:37:56.000+0200 to 2020-10-04T19:37:57.000+0200

2020-10-04 19:37:58.504 [ome.event.ItemCommandEvent] - Item ‘GartenRasenpumpe_Device_statusLed’ received command OFF

2020-10-04 19:37:58.524 [nt.ItemStatePredictedEvent] - GartenRasenpumpe_Device_statusLed predicted to become OFF

2020-10-04 19:37:58.548 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_statusLed changed from ON to OFF

2020-10-04 19:37:58.856 [vent.ItemStateChangedEvent] - GartenRasenpumpe_Device_heartBeat changed from 2020-10-04T19:37:57.000+0200 to 2020-10-04T19:37:58.000+0200

Any idea, why the shellyplug itself do not react when I switch off and on the LED’s
No reaction on the plug itself. In the shelly app itself it is not possible to switch the LED’s.

BR
Jochen

I have a build ready to test. This implements an additional binding config option “Local IP”. Usually this is empty and the binding gets the default interface from the OH network config. In your case you could set a different local interface IP, which is then used to setup the CoAP listening.I hope this will have no side effect, that’s the reason why I made it a test build. Please let me know your test result so I could integrate that option into the regular code.

1 Like

I can’t reproduce your problem. Keep in mind: setting those Switches to ON means your are disabling the the LED (not enabling). On the other side sometimes it take some seconds until the device responds.

What I verified is that when changing the config in OH it is reflected in the device Web UI. Device is running 1.8.3

Thanks for the tipp Markus.

one additional information here:
As the plug was in the configuaration, before I was updating to the 2.5.9, I have complete delete the thing and also all the assigend items. After a rebooted from OH, the thing was found automaticly and I attched all items to the new thing.

As I have tryed more than a handfull, the switch off and on, and also this is vissible in the log. I have no Idea anymore why the thing do not switch off or on the LED’s.

I have also enabled all the settings in the thing.

In past I have had issues with my HT with a set of username and password to the thing.
Have you set username password by your plug? Can you verify?

BR
Jochen

@markus7017 the test build works like a charm in the last 1h. I will leave it installed and look if it is stable over time. Karaf console with normal log does not show any errors so far. I did not look into debug log so far.

My setup: Openhab 2.5.9 on current Debian Linux on a Pi with one LAN adapter eth0. Configured two networks on that eth0 and eth0.50 (VLAN). Openhab network configuration is for IP of the eth0. Shelly test build binding is configured to listen for CoIoT on the IP of the eth0.50.

I had some problems installing the .jar file. The download with wget did not downloaded the full file and I did not noticed that. After downloading with Windows client and moving the .jar file on my Debian Linux openhab system and setting opehab user as owner of the file, it worked.

THANK YOU for this great solution! Hope this could be included into the next version of the binding.

Thanks for all the efforts in this excellent binding! I have also installed the latest test version and it works, response time is way better than it was before with the old firmware!

The only problem I have: I cannot see any triggers of my Shelly I3 (the button trigger). Trigger for Hue switches are working. Is there something I need to set for the Shellies?

Thanks!

Thanks for the feedback :+1:

Hmm, there seems to be something strange with the i3. In my setup it works, but you are not the first one reporting issues. Could you please provide a DEBUG log (use code fence when posting here of send a PM with the log). I need to see the complete thing initialization and some test cycles.

I assume that AutoCoIoT in the binding config or CoIoT in the thing config is enabled and the device sits on the same local subnet and is running the latest firmware?

@markus7017 I think this was overlooked, still happy to provide any logs, if you have any filter options I could use?

filter options?

Enable DEBUG log in the OH console: “log:set DEBUG org.openhab.binding.shelly”

Make sure the Shelly device is on the same network and CoIoT is enabled.

Hi,

sorry just thought there’s something you also want to see outside of the binding. Here’s the relevant log:

2020-10-09 20:29:48.049 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: CoIoT Message from /192.168.1.42:5683 (MID=21715): {"G":[[0,9103,0],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,1],[0,2202,"L"],[0,2203,15],[0,4101,0.00],[0,4103,1274],[0,6102,0],[0,4201,0.00],[0,4203,248],[0,6202,0],[0,3104,59.39],[0,6101,0],[0,9101,"relay"]]}
2020-10-09 20:29:48.052 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: CoIoT Sensor data {"G":[[0,9103,0],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,1],[0,2202,"L"],[0,2203,15],[0,4101,0.00],[0,4103,1274],[0,6102,0],[0,4201,0.00],[0,4203,248],[0,6202,0],[0,3104,59.39],[0,6101,0],[0,9101,"relay"]]} (serial=5422)
2020-10-09 20:29:48.053 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: 18 CoAP sensor updates received
2020-10-09 20:29:48.899 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: CoIoT Message from /192.168.1.42:5683 (MID=21716): {"G":[[0,9103,0],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,1],[0,2202,"L"],[0,2203,16],[0,4101,0.00],[0,4103,1274],[0,6102,0],[0,4201,0.00],[0,4203,248],[0,6202,0],[0,3104,59.39],[0,6101,0],[0,9101,"relay"]]}
2020-10-09 20:29:48.899 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: CoIoT Sensor data {"G":[[0,9103,0],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,1],[0,2202,"L"],[0,2203,16],[0,4101,0.00],[0,4103,1274],[0,6102,0],[0,4201,0.00],[0,4203,248],[0,6202,0],[0,3104,59.39],[0,6101,0],[0,9101,"relay"]]} (serial=5678)
2020-10-09 20:29:48.900 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: 18 CoAP sensor updates received
2020-10-09 20:29:48.900 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-10521cf18e7a: Update button state with L/LONG_PRESSED
2020-10-09 20:29:52.123 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyswitch25-10521cf18e7a: Channel relay2#input updated with ON (type class org.eclipse.smarthome.core.library.types.OnOffType).
2020-10-09 20:29:52.156 [DEBUG] [.internal.handler.ShellyRelayHandler] - shellyswitch25-10521cf18e7a: Set relay output to ON
2020-10-09 20:29:52.601 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: CoIoT Message from /192.168.1.42:5683 (MID=21717): {"G":[[0,9103,0],[0,1101,1],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,1],[0,2202,"L"],[0,2203,16],[0,4101,11.07],[0,4103,1274],[0,6102,0],[0,4201,0.00],[0,4203,248],[0,6202,0],[0,3104,59.27],[0,6101,0],[0,9101,"relay"]]}
2020-10-09 20:29:52.605 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: CoIoT Sensor data {"G":[[0,9103,0],[0,1101,1],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,1],[0,2202,"L"],[0,2203,16],[0,4101,11.07],[0,4103,1274],[0,6102,0],[0,4201,0.00],[0,4203,248],[0,6202,0],[0,3104,59.27],[0,6101,0],[0,9101,"relay"]]} (serial=5934)
2020-10-09 20:29:52.606 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: 18 CoAP sensor updates received
2020-10-09 20:29:52.609 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellyswitch25-10521cf18e7a: Channel relay1#output updated with ON (type class org.eclipse.smarthome.core.library.types.OnOffType).
2020-10-09 20:29:52.610 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellyswitch25-10521cf18e7a: 1 channels updated from CoIoT status, serial=5934

So it takes around four seconds until everything is done. Yes it’s in CoIoT mode and same network. Interestingly this delay is only their if I use the real physical hardware-switch, if I turn it on via the Shelly app it’s also updated in openhab almost instantly.

hmm, not sure if that relates to the binding. Is it possible that some other addon is blocking execution (e.g. 5 sec timeout)?

Initially you talked about a Shelly1, log is from Shelly 2.5, so it’s a general problem in your setup?

Please provide a TRACE log of at least 2 examples

I can actually reproduce it with a Shelly 1 as well as a Shelly 2.5. Here’s a 1.5 secs lag on a Shelly 1:

2020-10-13 21:46:52.872 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Message from /192.168.1.49:5683 (MID=29341): {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,50]]}
2020-10-13 21:46:52.876 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Sensor data {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,50]]} (serial=15361)
2020-10-13 21:46:52.878 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: 5 CoAP sensor updates received
2020-10-13 21:46:53.661 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Message from /192.168.1.49:5683 (MID=29342): {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,51]]}
2020-10-13 21:46:53.665 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Sensor data {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,51]]} (serial=15617)
2020-10-13 21:46:53.667 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: 5 CoAP sensor updates received
2020-10-13 21:46:53.670 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1-e098068d898e: Update button state with L/LONG_PRESSED
2020-10-13 21:46:54.085 [DEBUG] [lly.internal.util.ShellyChannelCache] - shelly1-e098068d898e: Channel relay#input updated with ON (type class org.eclipse.smarthome.core.library.types.OnOffType).

I’m not sure what should block the execution, I have neither modified the Shellys nor the binding. Also the lag differs.

Same device, but this time around 2 seconds:

2020-10-13 21:55:56.690 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Message from /192.168.1.49:5683 (MID=29382): {"G":[[0,9103,6],[0,1101,1],[0,2101,0],[0,2102,"L"],[0,2103,51]]}
2020-10-13 21:55:56.692 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: Serial 17409 was already processed, ignore update
2020-10-13 21:55:57.499 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Message from /192.168.1.49:5683 (MID=29383): {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,51]]}
2020-10-13 21:55:57.503 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Sensor data {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,51]]} (serial=17665)
2020-10-13 21:55:57.505 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: 5 CoAP sensor updates received
2020-10-13 21:55:58.306 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Message from /192.168.1.49:5683 (MID=29384): {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,52]]}
2020-10-13 21:55:58.309 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: CoIoT Sensor data {"G":[[0,9103,6],[0,1101,1],[0,2101,1],[0,2102,"L"],[0,2103,52]]} (serial=17921)
2020-10-13 21:55:58.310 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly1-e098068d898e: 5 CoAP sensor updates received
2020-10-13 21:55:58.311 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shelly1-e098068d898e: Update button state with L/LONG_PRESSED
2020-10-13 21:55:58.685 [DEBUG] [lly.internal.util.ShellyChannelCache] - shelly1-e098068d898e: Channel relay#input updated with ON (type class org.eclipse.smarthome.core.library.types.OnOffType).

Sequence starts with “CoIoT Message from” and ends with “Channel relay#input updated”
21:46:53.661 until 21:46:54.085 = 700ms
21:55:57.499 until 21:55:58.685 = 1,1sec
Those is the expected range.

Works great with Shelly 2.5 roller.

Thanks

I have the following Problem with shelly Binding an 2.5PM-Device
Power is always jumping beetween 0 and xxx, also if device is offline.
Also the PowerOn is jumping beetween on and off all seconds.
With mqtt all is ok. I don´t have an idea at the moment whats the problem.
I´m on openhab 2.5.9 with last shelly-dev-binding and firmware 1.8.3 on 2.5PM.
Any ideas?

2020-10-18 12:36:47.392 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 4.5 to 0.0

2020-10-18 12:36:47.393 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.513 to 0.024

2020-10-18 12:36:48.207 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 0.0 to 103.7

2020-10-18 12:36:48.208 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.024 to 57.874

2020-10-18 12:36:48.209 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from OFF to ON

2020-10-18 12:36:51.023 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from ON to OFF

2020-10-18 12:36:51.024 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 103.7 to 0.0

2020-10-18 12:36:51.024 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 57.874 to 0.024

2020-10-18 12:36:51.278 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 0.0 to 98.0

2020-10-18 12:36:51.279 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.024 to 43.557

2020-10-18 12:36:51.280 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from OFF to ON

2020-10-18 12:36:53.282 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 98.0 to 100.2

2020-10-18 12:36:54.682 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from ON to OFF

2020-10-18 12:36:54.684 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 100.2 to 0.0

2020-10-18 12:36:54.684 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 43.557 to 0.024

2020-10-18 12:36:57.275 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 0.0 to 88.5

2020-10-18 12:36:57.282 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.024 to 43.557

2020-10-18 12:36:57.283 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from OFF to ON

2020-10-18 12:36:58.015 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from ON to OFF

2020-10-18 12:36:58.016 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 88.5 to 0.0

2020-10-18 12:36:58.017 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 43.557 to 0.024

2020-10-18 12:37:00.471 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 0.0 to 4.3

2020-10-18 12:37:00.472 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.024 to 1.513

2020-10-18 12:37:00.472 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from OFF to ON

2020-10-18 12:37:00.878 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 4.3 to 102.7

2020-10-18 12:37:00.879 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.513 to 57.876

2020-10-18 12:37:01.701 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from ON to OFF

2020-10-18 12:37:01.701 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 102.7 to 0.0

2020-10-18 12:37:01.702 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 57.876 to 0.024

2020-10-18 12:37:02.277 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 0.0 to 99.3

2020-10-18 12:37:02.278 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.024 to 43.557

2020-10-18 12:37:02.278 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from OFF to ON

2020-10-18 12:37:05.384 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from ON to OFF

2020-10-18 12:37:05.385 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 99.3 to 0.0

2020-10-18 12:37:05.385 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 43.557 to 0.024

2020-10-18 12:37:08.275 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 0.0 to 91.0

2020-10-18 12:37:08.277 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.024 to 43.557

2020-10-18 12:37:08.277 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from OFF to ON

2020-10-18 12:37:09.578 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 91.0 to 112.1

2020-10-18 12:37:09.578 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 43.557 to 57.876

2020-10-18 12:37:09.579 [vent.ItemStateChangedEvent] - KUC_Shelly_Relay1 changed from ON to OFF

2020-10-18 12:37:09.580 [vent.ItemStateChangedEvent] - KUC_Shelly_Power1 changed from 112.1 to 0.0

Are you using the latest Dev build? I think this is an issue fixed in between

Here is the first build for openHAB 3.0 (AFAIK they plan to publish first milestone during the next days)


Latest DEV build: 2.5.9 - 3.0.0 - README - Installation - Firmware Index - Firmware Archive - API Doc

I´ve tested last 2.5.9 dev version and 2.5.10 snapshot-version and the problem is not fixed.
Do you need any logs?

Hello! Thank you for your contributions and continued updates. I made sure to update to the latest firmware and searched for a solution to my question but couldn’t find a mention of it.

My Shelly RGBW2 is working with Openhab using an RGBW LED strip. The issue that I’m seeing is that the White channel brightness cannot be controlled with Openhab like in the Shelly App where there is a white brightness slider. Am I missing this in the set up somewhere?

Color picking, gain, and saturation all work with the RGB leds.

Thanks for the clarification. So, I did some more tests, as the actual lag is definitely more like 3-4 seconds. It seems like that the CoIoT events arrive quite late in openhab, when the wifi-signal is weak. Interestingly the native Shelly actions (calling a url) are a lot faster. I used a dummy webserver running on the same machine as openhab that gets pinged about 2-3 seconds earlier than the CoIoT arrives in openhab. This is only the case for weak WiFi-signals, if the WiFi-signal is strong the CoIoT arrives almost realtime. I also tried to use the button and push events, same behavior, my dummy webserver gets the signal 2-3 seconds earlier than the openhab binding.
So to solve this issue I’ll probably create a minor shelly-proxyserver which then calls the openhab rest-api, even with this extra hop it’s still faster than the current openhab-integration. I’ve no idea what’s generating this delay, that seems to depend on the WiFi-signal of the shelly.