Shelly Binding

Add-ons Bindings
,
1687

Funny issue with that button-1 :wink: I did a little bit of testing now. Lets get to the data first, then my observations and last my speculations and questions :wink:

DATA
The collected data was once again posted to pastebin.com, as I’m still not allowed to post that much data right here. The pastes do not expire and do not need a password, so should be fine.

The of the binding I used were 2.5.11.202011291921 (referenced as ‘old’ or Nov 29) and 2.5.11.202012041416 (referenced as ‘new’ or Dec 04).

Comments on the data are inline.
Overview: Overview - Pastebin.com
Trace, old version, dups: Trace / with dup events - Pastebin.com
Trace, new version, no dups?: Trace, new version - Pastebin.com

Observations
That was fun. With the old version of the binding I always got the events two times if the button goes to sleep in between. If it is still awake only once. After upgrading to the new version things got a little bit strange. I sometimes saw duplications after the device was discovered but I was not able to catch that in a Trace. Other times the first press after discovery was not shown at all (only updates, no event).

After those initial hurdles it worked fine. One press → One event. I captured one of those series as a trace. No dups seen, but the initial keypress was missed. In the log you see the change from UNKNOWN to ONLINE. That was initiated by a keypress.

Sidenote: I do not see duplicate events on MQTT. But I do see the event-counter resetting:
12/07/2020 8:57:26 PM {“event”:“S”,“event_cnt”:1}
// Sleep
12/07/2020 8:57:56 PM {“event”:“S”,“event_cnt”:1}
12/07/2020 8:57:58 PM {“event”:“S”,“event_cnt”:2}

As expected button events for other devices (for example one of my SHSW-1) do work with the old version, but not the new one. For that reason I downgraded to the November version for the moment and will try to filter out the dup events by rules :wink:

Speculations
I have no proof for it but I suspect the strange behavior after initial discovery to also happen if the thing got into the UNKNOWN or OFFLINE state again. This happens with those buttons if not used for a longer while. That would explain why I was under the impression (yesterday) that your fix was not working.

Questions
Not sure if I really understood the problem (still trying to figure out your code; I’m not that much of a Java guy). You said that the serial is increased whenever there was a change to a ‘state’. So basically: First press → Serial 1 / Just a status update → Still serial 1 / Another press → Serial 2. It returns to serial 1 when sleeping.

So basically everthing sent by the Button-1 has serial 1, because it usually got to sleep in between? And sometimes it sends events more than once, right? In that case there is something seriously broken with that firmware :wink:

Completely different topic: You are aware that the 1L implementation is still lacking the second switch channel, right? :wink:

And the last question: Is there a useful way to catch CoIoT packets for debugging purposes? Haven’t found a tool yet.

Thanks,
Stefan

1688

Hi Marian,

do you mean that your device seems to be stuck in the Initializing/Unknown state? That probably would be related to the H&T usually sleeping and only sending updates periodically. There is no way for OH to reach the device. It has to wait for the H&T to send a message, at which point it would change it’s state to ONLINE.

But I might be on the wrong track here.

1689

ok, I updated the DEV build, button triggers should work again for Button-1, but also other devices
please verify

1690

yep, you re right

  • serial and event count always reset to 1 when the device wakes up
  • there are usually 2 identical packets after wake-up - that’s makes it hard to detect

what is the “second switch channel”? The 1L has 1 Relay, correct? (still not having one on my table)

CoIoT is based on CoAP, which uses UDP multicast. Capture data on your network, then you could filter on multicast ip 224.0.1.187, UDP:5683

1691

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 ?

Thank you

1692

The 1L does have 1 Relay and 2 Switch Inputs. See below screenshot from MQTT Log.

image
image338×357 10.7 KB

The documentation on this (https://shelly-api-docs.shelly.cloud/#shelly1l-overview) is not really explicit about that fact.

As for the new DEV build: I’ll test later on.

1693

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)

1694

Are the Shellys and OH on the dame subnet/network interface? You may need to set the network interface in the OH system settings.

CoIoT requires Multicast IP with UDP traffic.

Do you have a firewall in between?

1695

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

1696

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

1697

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

image
image1009×900 27.8 KB

With this settings it works perfect.

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

1698

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.

1699

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

1700

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

1701

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.

1702

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.

1703

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.

1704

Thank you very, very much for your big work.

1705

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 !

1706

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."