Shelly Binding

I had the same Problem. By me was that “Enable Switch Events” was not set:

With this settings it works perfect.

By one switch it not works. After I also had activate “Enable Buttons-Events” -> Only then it works.

I might be early.

But I’m trialing oh3 m5

But binding doesn’t seem to register the URL and enable output change active in Shelly device.
Tried both Shelly pm and Shelly dimmer 1.

Devices goes online and can turn on and off lights.

I must correct me:
After Updating Firmware to 1.9.x the status of the device will not updated every time. Sometime it works, sometime not.
I have activated “Enable Button Events” “Enable Switch Events” and “Enable ColoT Events”.

Thanks for your help.

My Installation: openHAB 2.5.10 Release Build

What do you mean with “URL and enable output change”?
Action URLs are only set if CoIoT is disabled
a) Auto-CoIoT is set to false in the binding config - affects all things (default)
b) Enable CoIoT on the thing level is disabled

Usually you don’t need Action URLs when using CoIoT. CoIoT has various benefits, see README

What does that mean, please be more specific. I now that Alterco is still working to fix some issues in CoIoT, wich will be released soon (1.9.3), 1.9.3rc3 is available as a beta.

fyi: The current DEV build for 2.5 and 3.0 are in sync featurewise. However, I’m re-factoring the input handling, which also brings some other changes. First version is uploaded, @igor and @Rondal will help with testing. This will bring

  • Relay Channels will created dynamically based on features provided by the firmware level. This will dynamically adapt to number of relays (1 vs 2 vs 4 depending on device) and number of input channels (standard 1, Dimmer/1L have 2, iX3 has 3). This will also bring the lastEvent and eventCount channels for all devices running firmware 1.8+ (the channels will not be created for older firmwares)
  • The input channel handling itself (input channel, trigger channel, lastEvent, eventCount, lastUpdate) is re-factored to support the dynamic structure
  • There is one breaking change for Dimmer 1+2: Matching the number of inputs there are now 2 trigger channels (button1+button2), because each input channel specifically triggers events.
  • A work-around for Button-1 to suppress duplicate event triggers has been implemented. I’m still in contact with Alterco how to implement a clean solution, but current status is better than nothing. The problem has also confirmed by other projetcs.
  • Shelly UNI and 1L are now supported, maybe I’ll also add the G10 color bulb

I did initial testing, but of course the number of changes has bug potential. I would highly appreciate if more people could test with existing installations.

Status and timeline for 3.0 does not allow to bring in those changes in the initial 3.0 release. 3.0 will not include those features/changes. AFAIK feature freeze for OH 3.0 is planned end of the week. This means: No chance to run those changes through the PR process until then. Triggering the PR will be the next step, I expect a merge until end of the year, so this would be part of version 3.1 end of January.

1 Like

Sorry, I’m trying to be more precise. I had the following two behaviors in the last 15 minutes:

  1. shelly 1 (Current version: 20201124-091217/v1.9.0@57ac4ad8), has a trigger that 6 seconds after power on, it turns off again. After the command is sent from OpenHAB to switch on, this status remains in OpenHAB (switched on).

  2. shelly 2.5 (Current version: 20201128-102046/v1.9.2@e83f7025). When the light is turned on with the wall switch, the status in OpenHAB remains off (and no events are fired).

I hope this is enough information.

Thank you very, very much for your big work.

Thank you for your answer! Unfortunately I didn’t find the issue until know. I will try next to create another dedicated subnet / network for sensors and try from the router to route the traffic to the network where the RPI is located !

Does anybody help me with the necessary steps to integrate the Shelly H&T sensor with OH when are in different subnet / network? For e.g. OH is in 10.0.5.0/24 and the Shelly sensor in 192.168.1.0/24. Please let me know what I should change on Paper UI / Sensor WEB gui and router config. I found some information in the binding description but is not clear for me. For e.g I need to create a route on a router or a port forwarding for this : 224.0.1.187, port 5683

Any help it’ll be apreciated

From Shelly Binding description:

"The binding defaults to CoIoT events when firmware 1.6 or newer is detected. CoIoT provides near-realtime updates on device status changes. This mode also overrules event settings in the thing configuration.

“Disabling this feature allows granular control, which event types will be used. This is also required when the Shelly devices are not located on the same IP subnet (e.g. using a VPN). In this case autoCoIoT should be disabled, CoIoT events will not work, because the underlying CoAP protocol is based on Multicast IP, which usually doesn’t passes a VPN or routed network.”
and
"Shelly devices do only support IPv4. This implies that the openHAB host system has IPv4 bound to the network interface. The binding is only able to discover devices on the local subnet. Add things manually with the given IP if you have a routed network in between or using a VPN connection.

The binding enables CoIoT protocol by default if the device is running firmware 1.6 or newer. CoIoT is based on CoAP and uses a UDP based signaling using IP Multicast (224.0.1.187, port 5683). Again if the device is not on the same local IP subnet you need special router/switch configurations to utilized CoAP via IP Multicast. Otherwise disable the Auto-CoIoT feature in the binding config (not the thing config), disable CoIoT events in the thing configuration and enable sensors events (http callback). Nevertheless in this setup the binding can communicate the device, but you are loosing the benefits of CoIoT."

I’m in the final stage to prepare the PR. This will be submitted for OH 3.0.1 (coming end of January). Nevertheless the 2.5.x build provides the same feature set. I’m still developing on 2.5 and then migrate the code to the 3.0 build environment in an automated way. The DEV build will keep you up-to-date in between.

This release includes various interesting new features, but also bug fixes. We put significant QA effort in trying to get it as stable as possible - please help on this.

PR #9354 contains the following changes:

  • General adaption to OH3 code base (e.g. more @Nullable handling)
  • Relay Channels (incl. RGBW2) are now created dynamically based on device type, configuration and firmware level. This will dynamically adapt the number of relays (1 vs 2 vs 4 depending on device) and number of input channels (standard 1, Dimmer/1L have 2, iX3 has 3).
  • Input channels lastEvent and eventCount are now available for all devices running firmware 1.8+ (will not be created for older firmwares). In addition the binding checks the configured button mode - only Momentary, Momentary Release, One Button and Two Buttons will provide those events (check device config to verify the selected mode), channel are not created in other button modes.
  • The input channel handling itself (input channel, trigger channel, lastEvent, eventCount, lastUpdate) was re-factored to support the dynamic structure.
  • Improved documentation (see below)

Enhancements

  • #9096: Shelly UNI support
  • #9353: Shelly 1L support
  • #9344: Roller favorites are supported and could be used to select position on UP and DOWN

Bug fixes

  • #9363: Tilt doesn’t get updated for DW2
  • #9359: German translation missing in thing config
  • #9323: Input2 is not provided for Dimmer 1+2
  • #9305: iX3 is not updated when CoIOT is disabled
  • #9219: NPE in ShellyDeviceProfile.inButtonMode() (Shelly 1L)
  • #9216: Button-1 reports duplicate triggers
  • #9097: RGBW2 power meter is not updated via CoAP
  • #9078: White channel missing for RGBW2 in white mode

There is one breaking change for Dimmer 1+2: Matching the number of inputs there are now 2 trigger channels (button1+button2), because each input channel specifically triggers events.

README was updated and additional rule samples were added.
I also create a first Use Case description how to get the maximum out of your Shelly 2.5 in roller mode including additional hints how to use the roller channels. Document is work in progress, I’m looking forward to feedback and other contributions like “How to perate OH+Shelly binding with CCT LED stripes” or “How to setup OH+Shelly Binding in a Docker container”. People will love those, because it brings relevant information together rather then fishing for pieces with Google.

Please note: The version has been updated to 2.5.12-SNAPSHOT. This means you have to uninstall version 2.5.11 before copying the new jar to the addons folder.


Latest DEV build: 2.5.12 - 3.0.0 - README - Installation - Bugs/Features - Firmware Index - Firmware Archive - API Doc


Note: The binding version included in the final OH 3.0 distro is significantly older than the DEV build. I can’t make it in-time, we already have feature freeze for 3.0 - sorry for that, but always a matter of (spare time).


Please help to harden the release, that’s you type of donation to the project :slight_smile:

1 Like

fyi:

PR #9390 Improved documentation and first use case description has been created. This will bring the updated documentation into OH 3.0.0 and will speed up processing of the actual feature/bugfix PR #9354.

The only remaining thing is a new bug #9398 OFFLINE detection doesn’t work with USB powered Shelly H&T, I’m working with Igor on it, should be fixed soon.

Any Chance to fix this problem. Also with latest snaphot 2.5.12 the problem is not fixed. Do you need logs?

which problem?

Power Complete with Shelly 2,5PM

2020-12-18 13:25:44.147 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.639 to 1.361

2020-12-18 13:25:44.520 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.361 to 0.739

2020-12-18 13:25:48.148 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 1.361

2020-12-18 13:25:48.669 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.361 to 0.639

2020-12-18 13:25:59.498 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.639 to 0.739

2020-12-18 13:25:59.762 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 1.363

2020-12-18 13:26:00.214 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.363 to 0.641

2020-12-18 13:26:02.174 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 1.363

2020-12-18 13:26:03.669 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.363 to 0.641

2020-12-18 13:26:14.506 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 0.739

2020-12-18 13:26:14.710 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 0.641

2020-12-18 13:26:15.153 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 1.363

2020-12-18 13:26:24.671 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.363 to 0.641

2020-12-18 13:26:26.147 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 1.363

2020-12-18 13:26:26.668 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.363 to 0.641

2020-12-18 13:26:29.515 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 0.739

2020-12-18 13:26:29.667 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 0.641

2020-12-18 13:26:41.158 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 1.363

2020-12-18 13:26:44.520 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.363 to 0.739

2020-12-18 13:26:51.702 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 0.641

2020-12-18 13:26:56.158 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 1.363

2020-12-18 13:26:56.669 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.363 to 0.641

2020-12-18 13:26:59.492 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.641 to 0.739

2020-12-18 13:26:59.772 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 1.364

2020-12-18 13:27:00.225 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.364 to 0.643

2020-12-18 13:27:14.508 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.643 to 0.739

2020-12-18 13:27:14.779 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 0.739 to 1.364

2020-12-18 13:27:16.669 [vent.ItemStateChangedEvent] - KUC_Shelly_Power_Complete1 changed from 1.364 to 0.643

Number KUC_Shelly_Power_Complete1 "Küche Licht PowerTotal [%.3f kWh]" <energy> (rwe,pc,power,Loggen) {channel="shelly:shelly25-relay:b95032:meter1#totalKWH"}

Could you please provide a proper description, it’s hard to get the context from fragments of information

Hello Markus,

thanks for the great binding. I am wondering if you have a hint for me. I am trying to include a dw2 door/window sensor. For the test I am running OH 3.0.0.M5 in a Docker container.

dw2 detection works flawlessly. However later updates of contact state don’t make it to my thing/item. I checked with tcpdump in the container whether messages from the device reach the container. This looks good (I suspected multicast issues).

From the dumps I can decode the following CoAp messages. Item 3108 is properly set in the message.

18:27:42.380089 IP (tos 0x0, ttl 255, id 17, offset 0, flags [none], proto UDP (17), length 230)
    10.0.0.87.5683 > 224.0.1.187.5683: [udp sum ok] UDP, length 202

Decoded content
{
    "G":[
        [0,9103,0],
        [0,3108,1],
        [0,3109,-1],
        [0,6110,-1],
        [0,3106,105],
        [0,3110,"twilight"],
        [0,3101,24.60],
        [0,3102,76.28],
        [0,3115,0],
        [0,3111,98],
        [0,9102,["sensor"]]
    ]
}
18:43:41.550482 IP (tos 0x0, ttl 255, id 16, offset 0, flags [none], proto UDP (17), length 224)
    10.0.0.87.5683 > 224.0.1.187.5683: [udp sum ok] UDP, length 196

Decoded content

{
    "G":[
        [0,9103,0],
        [0,3108,0],
        [0,3109,-1],
        [0,6110,-1],
        [0,3106,0],
        [0,3110,"dark"],
        [0,3101,24.20],
        [0,3102,75.56],
        [0,3115,0],[0,3111,98],
        [0,9102,["sensor"]]
    ]
}

Is this setup known to work (I guess so)? Is there a way to check whether the multicast message is seen by your binding?

please try the DEV build, this is way newer. The PR didn’t make it into the 3.0 release.


Latest DEV build: 2.5.12 - 3.0.0 - README - Installation - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The binding version included in the final OH 3.0 distro is significantly older than the DEV build. I can’t make it in-time to bring in the PR in advance to the feature freeze for 3.0 - sorry for that, but always a matter of (spare time).

I followed your instructions for OH 2.5.12. I did a fresh (container) installation. The DEV binding is properly installed.

210 │ Active │  80 │ 2.0.0                   │ Californium (Cf) Core
211 │ Active │  80 │ 2.0.0                   │ Californium (Cf) Element Connector
212 │ Active │  80 │ 2.5.12.202012192330     │ openHAB Add-ons :: Bundles :: Shelly Binding

Things (a 2.5 Switch and DW2) are detected. Still I seem to have no luck with CoAP status updates. There are no traces in the log of the binding from DW2.

I can see the multicast CoAP message in tcpdump, but somehow the bindings seems not to get it.

10:57:27.291204 IP (tos 0x0, ttl 255, id 10, offset 0, flags [none], proto UDP (17), length 226)
    xx.xxx.xxx.xxx.5683 > 224.0.1.187.5683: [udp sum ok] UDP, length 198
	0x0000:  4500 00e2 000a 0000 ff11 ceee 0a00 0057  E..............W
	0x0010:  e000 01bb 1633 1633 00ce 790e 501e 59bd  .....3.3..y.P.Y.
	0x0020:  b363 6974 0173 ed0b ec08 5348 4457 2d32  .cit.s....SHDW-2
	0x0030:  2334 3046 3532 3032 4441 3733 4123 32d2  #40F5202DA73A#2.
	0x0040:  4396 0082 0300 ff7b 2247 223a 5b5b 302c  C......{"G":[[0,
	0x0050:  3931 3033 2c30 5d2c 5b30 2c33 3130 382c  9103,0],[0,3108,
	0x0060:  305d 2c5b 302c 3331 3039 2c2d 315d 2c5b  0],[0,3109,-1],[
	0x0070:  302c 3631 3130 2c2d 315d 2c5b 302c 3331  0,6110,-1],[0,31
	0x0080:  3036 2c31 375d 2c5b 302c 3331 3130 2c22  06,17],[0,3110,"
	0x0090:  6461 726b 225d 2c5b 302c 3331 3031 2c32  dark"],[0,3101,2
	0x00a0:  332e 3630 5d2c 5b30 2c33 3130 322c 3734  3.60],[0,3102,74
	0x00b0:  2e34 385d 2c5b 302c 3331 3135 2c30 5d2c  .48],[0,3115,0],
	0x00c0:  5b30 2c33 3131 312c 3130 305d 2c5b 302c  [0,3111,100],[0,
	0x00d0:  3931 3032 2c5b 2273 656e 736f 7222 5d5d  9102,["sensor"]]
	0x00e0:  5d7d                                     ]}

Could it be a Java issue? To my surprise I found the 2.5.12-snapshot-debian container is providing OpenJDK. I was under the impression the Debian images use Oracle Java (that’s at least what the documentation suggests)

root@DS214:/openhab# java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (Zulu 8.50.0.51-CA-linux64) (build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (Zulu 8.50.0.51-CA-linux64) (build 25.275-b01, mixed mode)

For a test I upgraded DW2 firmware to latest RC, but no change

Current firmware version: v1.9.3-rc4/20201216-140701(146c9bd7)

If you are running the binding in a Docker container there are some pre-requities. check the README.
I know that this topic was covered here, so maybe someone of the gang could help - I still didn’t found the time to setup a Docket environment for OH.

Did you tried to use Network type = Host? In this case the container shares the network with the Docker host. That should be the easiest way.

By the way: Who wants to contribute some instructions how to setup OH+Shelly*CoIoT, which I could include in the documentation? Or a new use case description? I already started with additional information on roller setup utilizing new firmware features like Roller Positioning Favorites. Those will become part of the distro and liked into the README. Please start sharing your advanced solutions with the community: More detailed setup guide, smart rules, advanced monitoring etc. I’m pretty sure all of us already found stuff, which could be beneficial for others.