Open kroozo opened 4 years ago
Are you using the same firmware on Shelly when testing 0.1.9 and 0.2.1b1?
No. These tests has been done with 1.8.3 and 1.8.4 shelly firmware, and those do not work with 0.1.9.
I think the last known version is a bit misleading. The old shelly_switch_click event was working all the time, the new shellyforhass.click has obviously not.
What I know for sure:
Shelly4Hass | Shelly Type | Shelly Mode | Shelly FW | Status |
---|---|---|---|---|
0.1.9 | SHSW-25 | relay | 1.6.0 & 1.7.0 | shelly_switch_click works fine |
0.1.9 | SHSW-25 | roller | 1.6.0 & 1.7.0 | shelly_switch_click works fine |
0.2.1b | SHSW-25 | roller | 1.6.0 & 1.7.0 | shelly_switch_click works fine |
0.2.1b | SHSW-25 | relay | 1.8.3 & 1.8.4 | as above: new events are fine, only some of shelly_switch_click |
0.2.1b | SHSW-25 | roller | 1.8.3 & 1.8.4 | as above: no new events, only some of shelly_switch_click |
0.2.1b | SHSW-1 | - | 1.8.4 | as above: new events are fine, only some of shelly_switch_click |
I have memories that the rest falls into this pattern, but I'm not a 100% percent sure what I have tested.
I can arrange to test with any combination of versions and a selection of SHSW-25, SHSW-1 and SHDM-1, just need to find an eventing where I can temporarily mess things up (especially if you need something with 0.1.9, jumping around with firmware versions on a selected switch I can do quickly)
This is because changes in fw that will not allow catching clicks in a good way. Also, Shelly 1 only supports single and long click in fw etc.
Hopefully, this will be fixed in coming fw, I have reported it to Shelly developers.
This is because changes in fw that will not allow catching clicks in a good way
I see, thanks for looking into this. Let's hope it works out.
Also, Shelly 1 only supports single and long click in fw etc.
I'm aware of that (also for 2.5). I agree that the best place for this is in the firmware. While it would be superb if they also implemented short-long, double, etc it's something I could swallow, but loosing the ability to detect click in roller mode is a real setback. Thankfully here is your wonderful add-on and I can just keep those on 1.7 for the time being without the hassle :)
I'm aware of that (also for 2.5). I agree that the best place for this is in the firmware. While it would be superb if they also implemented short-long, double, etc it's something I could swallow, but loosing the ability to detect click in roller mode is a real setback. Thankfully here is your wonderful add-on and I can just keep those on 1.7 for the time being without the hassle :)
Same for me - I'm with FW 1.7 and ShellyForHass 0.1.9 as it seems there are still too many issues with the new versions (no matter who should fix what).
If helps, I've solved for now (in ~95% of the time anyway) the double click using an appdaemon code. Here is my gist: https://gist.github.com/quammy/7a75d3a203494bfb3dd734e89066df84
@quammy I've actually moved to 0.2.1b with shelly4hass and to 1.8 on relays. I'm aware that there was some issues with power metering but I don't care much about that. And the new button detection seems to be more reliable.
Thanks for the gist, I was thinking on doing something similar, but its not needed as of now. (You can just look at shelly_switch_click's count, divide by 2 for the actual double/triple thing if needed. If its odd, then it ended in a long press. (Well, technically you also want to look at the state, because if it is false, then presumably it was ending in a normal press, and the long one was before, but I think its actually impossible as the long would fire off the event anyway)
Environment
Describe the bug
The new and old switching events however are a bit inconsistent. Tested on SHSW-25, (but I suspect it's not specific.) Can test on SHSW-1 and SHDM-1 if it helps.
When the device is on relay mode:
All "normal" pushes (ie push and release) emit a shellyforhass.click event with click_type=single. (Usually one, if your quick enough). These do not emit the shelly_switch_click event at all.
For long pushes both is happening:
1 and 3 are the old behavior, 2. is the new one. My assumption is that unless a timeout is involved the old event is not fired.
I am also unable to get a click_cnt=3 for short-long pushes. I get a click_type=short and then the above sequence
When the device is on roller mode:
For roller mode essentially the same happens, without any of the shellyforhass.click events. This in practice means that I only get indication of long pushes. My guess here is your code does exactly the same, but the shelly firmware does not send the coap message that is the basis of shellyforhass.click.
Steps to Reproduce
Expected behavior
Screenshots
Traceback/Error logs
Additional context