Thank you for your feedback. @markus7017 Please find below the issue that I counted:
I didn’t got the temp value (via CoIoT) when I’m going with the RPI and 3xShelly H&T on other location that has the same subnet netw. address as one that I tested on my house.
My Home network config is:
RT1 (192.168.1.0/24) ------- RT2 (192.168.1.0/24) ------- RT3 (192.168.1.0/24) and 10.0.5.0 for RPI3 /Shelly Sensors
Second Location:
RT1 (10.0.5.0/24) ---------- SW - RPI3 (10.0.5.230) and AP (10.0.5.248) used for Shelly Sensors
all the configured IPs for RPI and Shelly Sensors are static config…
Please let me know:
It’s recommended to get via DHCP the IPs since maybe are necessary others parameters to be proper configured than IP and Address MAsk ?
Do you see other possible issues ?
If you have working Shelly H&T in one location (IP address) and not in another location (another IP) this shall not be related to shelly binding itsellf but rather general network setting/knowledge
I am not a network expert and your address (10.0.5..) seems a bit strange for me, but:
The static IP address is recommended for Shelly H&T, since this device is going into sleep mode then from time to time loging in to the network and shall have the same IP address as specified in the binding.
You can configure static IP in Shelly H&T (or router) in which you need to set IP address (ex 192.168.0.x) Network mask and Gateway. (I am using shelly H&T only as Wifi client and NOT as AP)
Hi @markus7017. Thank you again for you answer.
Both Shelly and OH are in the same subnet network as I specified in my previous messages (10.0.5.0/24).
The network interface of OH was set from PAPER UI - System - Network Interface.
The network administrator told me that no firewall or filter are active for the internal traffic.
My last request for him was to allocate via DHCP server the static IPs for Shelly sensors and OH.
I’ll check again the next days since the location is not close to my home.
Unfortunately I’m not the administrator of that network and only I need to trust the admin.
Please let me know if do you know a way to check if it’s a network issue (something is blocking the Multicast IP with UDP traffic).
Thanks again
as a first think remeber to check if in your router for the subnet (the one not transferring UDP trafic or if you use port forwarding - options depends on routers you have) you have UDP protocol enabled
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”.
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.
Sorry, I’m trying to be more precise. I had the following two behaviors in the last 15 minutes:
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).
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).
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.
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.
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
