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 
1 Like
fyi:
- #9395 IllegalArgumentException when switching Shelly Vintage has been fixed
- #9220 Avoid using org.apache.commons.lang was the last blocking point for the OH3 PR and has been implemented
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.
Hi!
i recently got a shelly em and a shelly 3em have set them up via text config.
i’m (obviously) interested in power consumption and so the first thing i configured was [thing]:device#accumulatedWatts (“Accumulated power in W of the device (including all meters)”) but i got no updates for this item.
only after i configured a meter specific item [thing]:meter1#currentWatts i also got updates for the accumulated item. as soon as i remove/deactivate the meter1 item i stop getting updates from the accumulated item.
is this supposed to be this way or am i missing something?
and i have another (not binding-related) question: how do you guys store/evaluate power consumption? with currentWatts i can see the actual consumption but i’d like to store data the way i can later “extract” power consumptions for a specific period (24H, 365D, Month etc.).
totalKWH gives back total consumption but resets on restart, so i should probably calculate the difference of totalKWH (now) and (totalKWH) (5minutesago)?
and what exactly is the difference between accumulatedTotal and accumulatedReturned?
I’d appreciate any help
edit: i’m still on OH2 with binding version 2.5.10
Hmm, usually the channels are non depending on each other. This sounds a little bit unusual.
You should look into OH’s persitance capabilities. You could setup the system to store those items into InfluxDB, which creates time series, which could be visualized using Garfana or jump on OH3, it has some build-in capabilities.
Merry Merry Christmas to all of you!
It’s time to say thank you for joining this post and sharing ideas as well as one of the best sources to get information. I’m always interested in your feedback, this drove already some cool ideas. Don’t hesitate to ask questions, that what’s the community is made for. Happy to include your contributions like config examples or use case descriptions with the binding’s documentation.
I also want to share the XMas release for 2.5 and 3.1, which brings some minor fixes, support for the Shelly Duo Color Bulb (G10), but also for Shelly Motion. I’m already working with the Allterco team on this and the binding supports the current development status, so it will be ready when you get the Motion on the table.
Stay safe, let’s pass the pandemic and have fun with our Shellys.
Latest DEV build: 2.5.12 - 3.1.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. Make sure you deleted older versions of the binding when installing the 2.5.12-SNAPSHOT or 3.1.0-SNAPSHOT if you are already on OH 3.
2 Likes
Yeah thx. Need the Shelly motion. Waiting so long for it.
Can you tell how the Shelly motion works? Just an on signal or on /off signal?
Greets and merry Christmas
I’ve problems with my shellys. They send no update when I do some action with a physical button on the Shelly or when he has an auto-off-timer.
I use Openhab 3.0 with the newest dev binding with shelly 2.5 and 1 (1.9.0 or 1.9.3.rc5 firmware).
Shellys and OpenHAB are in the same subnet and mDNS (Avahi on pfsense) is active.
What can I do? What can I check?
PS: Problem was also in OpenHAB 2.5.11 (and rlease binding).
PS2: After an update or restart it works for a short time and after a while it do no update.
Thanks for you help.
I’ve found the problem:
I use two Asus router with “AI-mesh”. When a shelly was connected to the main router it works, when it was connected to an mesh router, it won’t work.
After I’ve setup boot router as an “AP-Router” without mesh functionality (AI-Mesh) it works like a charme.
good catch
what can i say. on my system it’s perferctly reproducible.
without [thing]:meter1#currentWatts i get no data from [thing]:device#accumulatedWatts
does anyone here have a em3 and can validate/invalidate this?