Multiple fired events on one button press #4227
Comments
|
Yep someone is working on a patch here #3611 (comment) No solution yet, but he is making a workaround. This is for tuya, for aquara its something new .... |
|
This has been happening to me for quite some time also on aqara switches. It can often be solved by a home assistant restart. Sometimes a full system restart is needed or a restart of the docker service. I've been thinking of implementing some kind of "debounce"functionality to solve this. |
|
I did restart and reboot many times. Still the same..... |
|
Another thing worth trying is rebuilding the deConz module.
…On Tue, 19 Jan 2021, 08:37 petosak, ***@***.***> wrote:
I did restart and reboot many times. Still the same.....
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABV6MAWZJT4POZDWCHU7SWTS2UZDFANCNFSM4WH2XURA>
.
|
|
how could i do that? I'm only user with RPI4 and HASSIO on it. |
|
Not possible with hassio, it use docker. |
Well, let alone you could install hassio in rpi directly, without containering stuff (dockers etc), what could this issue have with the hassio? Just it could work for TS0043, but if I correctly understand the issue is also about Aquara, so applying the patch (e. g. 203bc71) directly would not help, because there is a check for the manufacturer in line 4538, then it should be extended with yet another manufacturer condition, e. g.: - && sensor->manufacturer().startsWith(QLatin1String("_TZ3000_"))
+ && (sensor->manufacturer().startsWith(QLatin1String("_TZ3000_"))
+ || sensor->manufacturer().startsWith(QLatin1String("Aquara_OR_Whatever_Manufacturer_Name_Prefix_For_That_Device"))
+ )
Well it is a bit complex for a normal user (without developer know-how), but you can try it:
|
And that's what smanar tries to say. Hassio is way to complicated for the users they serve with it. Nevertheless: The addon is nothing official, meaning we don't develop it. |
There is nothing about hassio, if you take a look attentively, I was just talking about how to patch and (re)build deconz-rest-plugin.
What do you talking about? deconz-rest-plugin is this repository and has only marginal to do with hassio. Hassio just using conbee gateway over the API and can only consider events "published" by deconz. |
I was just backing up on Smanar's "Not possible with hassio, it use docker." and explaining his stance :) I totally agree with you. |
|
I have no problem with hassio, I have problem with dockers. I say that because it s not the first one that is trying. I think you can't imagine how many time we have explained how to compile the code, or just to install correctly deconz.
User generaly install hassio AND deconz in docker, they generaly don't do much more than waiting the docker is officialy updated and update it on their turn. I can't force them to install it a second time oustide the docker on their production machine.
Sorry but there is no "/usr/share/deCONZ/plugins/libde_rest_plugin.so" on docker installation, at least the last time I have tried, and the file compiled outside the docker can be incompatible inside it. If you want to explain how to do on HASSIO, no problem, but I have already tried, I give up on my side, there is nothing to help you, first you need to explain how to install SSH, serioulsy even the principal is not in place. Good luck to explain how to install dev-tools, even on raspian some users don't succed. For the patch with Xiaomi, IDK, for tuya, I know the hardware (and the issues) I have see all the logs with APS, I m sure the device for aquara , on the log on first post, you don't see APS log, and on ZCL log you can see the code react too on cluster 0x0012. So for me need more investigations for the aquara issue, I m realy not sure it s the same problem. For tuya it s a workaround, it s perhaps possible to solve the problem for the second brand. |
I also don't prefer docker (either real virtualization), but what is the problem here? In docker it is even more safe, because you can create a snapshot (and restore it if something becomes wrong). And your sentence was "Not possible with hassio, it use docker", what is basically totally irrelevant for aforementioned reasons (hassio has nothing to do with the subject, our patch, etc, it just notices events from deconz, so doesn't use direct gateway communique). It's like to bother the editor program about broken file, if the hard disk is full with bad sectors.
Nothing else I wrote above: "I know it is either a bug of device firmware or whatever" and that it was just a workaround of me, not a real solution.
Clear, therefore I also wrote that this patch would probably not help here (also if one would extend the condition)... But one could try. I understand that many people (calling themselves "normal user") could need several how-to's and that you don't have time (and probably the intention to navigate them or provide tips here and there), but some of them are probably smart enough to read manuals or even to use google to find some how-to self-dependently, so to tell them "it is impossible" is not only wrong, it is simply contra productive. Back to the aquara issue (if it is really the same), I could also help to debug/investigate deeper here, but either need more logs or even the device (which I don't have at the moment). One friend of me told me that he doesn't have any issue with the button events... imported this blueprint in hassio... anyway it looks like model-id of switch is the same ( @petosak is it a single aquara device or do you have possible more of them? if so are other affected too in the same way? |
|
OK, we were eventually wrong with "either a bug of device or its firmware": replaced Phoscon integration with ZHA integration (via zigpy-deconz library) in HASS and tried the same TS0044 using ZHA now. And as result: it does not generate double events in HASS using the same rpi, same gateway (conbee 2) and same switch. excerpt of events log (listening for "zha_event") and "home-assistant.log" ...At the same time the hass was logging into so I'm still unsure whether some stuff is indeed ignored by zigpy (or it's even not correct considered by deconz), must still check the spec and source code of zigpy. So maybe (I say only maybe) it is indeed an issue of deconz, since I don't know any prevention such my workaround zigpy-deconz may do to avoid too fast coming events (must check the source code yet). Anyway @petosak can you possibly try your Aquara switch with ZHA instead of phoscon in hassio (just stop deconz/deconz-gui services and in hassio add ZHA integration, add new device, goto devtool->events and listen for |
|
An amend to my previous comment... diff of 2 events occurring by decoding ZCL-frame in ZHA...-Event 0 fired 3:08 AM:
+Event 1 fired 3:08 AM:
{
"event_type": "zha_event",
"data": {
@@ -7,16 +7,14 @@ Event 0 fired 3:08 AM:
"device_id": "...",
"endpoint_id": 1,
"cluster_id": 6,
- "command": "press_type",
- "args": [0]
+ "command": "remote_button_short_press",
+ "args": []
},
- "time_fired": "2021-01-20T02:08:24.869018+00:00",
+ "time_fired": "2021-01-20T02:08:24.869259+00:00",
}Also note the time of events gets fired (reached the gateway or processed in zigpy) - since both events are done almost immediately (second only 240µs later), I guess it is indeed arriving in the same ZCL frame, so for some reason the deconz, if it receives the same data, causes a frame decoder issue and even retards the second part for 1 second (what looks at least suspicious). If this strange delay by decoding could be "fixed", the second part of the frame can be either ignored or somehow marked in order to distinguish the commands correctly. The specification of zigbee cluster library seems to be a bit ambiguous here (but maybe I found some old man, and there is some newer variant specifying another type of ZCL-layer frame or its processing more precise). Basically I have nothing further to add here, excepting that I don't believe anymore the error is with the device. BTW, it is opening also a possibility to provide a new common command for automation (which may be given in blueprint) like "remote_button_any_press" reacting on "press_type", which can trigger for any type of key press (combining several variants to the single common trigger), so "if any key of switch is pressed, do ...". |
|
I can add that when this happens with my aqara switches it happens to all of them. I cannot say if it happens to switches of other brands as my other switches (IKEA) are not used in home assistant but directly with groups in deconz, and they don't experience this issue when present on the aqara ones. |
|
So is it either sporadic issue with aquara? If it is reproducible to some extent, you could probably also try ZHA integration in HA, whether it becomes "healed" then. |
|
I can debug some more next time I get the issue. It normally gets resolved with a restart of HA. The issue normally arises randomly, but sometimes comes after a HA restart as well, e.g. after an update. Never has it resolved itself. And as mentioned it affects all my aqara switches. |
|
Just as tip: zigpy could apparently have the issues with false multiple presses also, zigpy/zha-device-handlers#712 (e. g. with Philips RWL021), so I don't think it has on board some special tricks to avoid repeated events by default. But because they seem to arrive really immediately in the same or adjacent ZCL frame, one could easy discard them regularly. Whereas in deconz due to delay ca. 1 second, it would remain a workaround either. |
|
But my question is, why now ? |
|
dunno... it isn't so simply to answer... but software evolves (deconz growing on codebase, devices get new firmware etc), so something conflicting there... and in between it is hardly conceivable to me the device is to blame (at least not alone;). |
|
Gents, although it is always great to see a vivid an in-depth discussion, I wonder during my fly by why not check the actual root cause? I mean, all relevant data can be made available by setting the right debug flags. With DBG_INFO_L2, you get the ZCL payload length, attribute, data type and actual data and with DBG_APS_L2, you move up one layer and also get the full asdu, also containing the ZCL sequence number. Checking all that info should cease any speculation about what exactly has been send and if the identical message was just repeatedly send by whatever device. As a side not with regard to Xiaomi devices, they are not too famous for adhering to the specs. I've seen devices seemingly stopping to send reports at will or randomly reporting different clusters and endpoints. Also got one single Tuya based device in my hands, which had a rock solid appearance on the very first glimpse, but also revealed some totally random behaviour on the longer run... |
|
For tuya #3611 (comment)
|
Strictly seen it brings more questions as answers.
Yep... but indirectly they are not really raw data (but an info how deconz API disassembled the frame), and there is this strange delay (so one could not be sure the second cycle obtains the same data as if first attempt, e. g. no shift in frame buffer). Anyway there is a bit more chatty log in the comment containing only one I'll still provide the raw data if I get time to debug zigpy (hopefully this evening), perhaps it is a bit different, at least we will not see this extra 1 second latency in-between :) But traversing over source code of zigpy, I found this one - https://github.com/zigpy/zha-device-handlers/pull/611/files#diff-3398e3e5af3c0cd6aa2a1854e46bc12638ebcc6c542da27de73df9e37a944bd5R400, and following blame points to this - tube0013/zha-device-handlers@cb7efe9#diff-3398e3e5af3c0cd6aa2a1854e46bc12638ebcc6c542da27de73df9e37a944bd5R396-R400 with this code initially implemented for TS0044 (but the same can be found for TS0043 etc, so it was combined later): if self.last_code != message[1]:
self.last_code = message[1]
super().handle_message(profile, cluster, src_ep, dst_ep, message)
else:
_LOGGER.debug("TS0044: not handling duplicate frame")Thus the TuyaSmartRemote.handle_message has indeed a prevention against duplicate frame before it supply that to handle_message of superclass CustomDevice. |
|
Lol, so, same than us, and using work around too. So it mean the device send the button event, (in some situation the same again), then another event but different (not used by code). Else one time you have used the device, you will be not able to use it a second time. |
|
No, it works (tested this as first several times). I assume in this message the byte1 (which is compared with last known |
|
Ok so you are right.
So they are not checking the command, but the sequence number, as you have said before , they are filtering the double command using the same sequence number. Edit: |
|
So a better place found to move our "workaround" to :) + "options": ["discard_same_sequence": true]Fixed coding is ugly and is not too strict only, but also pollute the code with hacks used for every single device only. |
|
If you said 2.09.01 do you mean with or without my fix suggested in #4265? |
|
Actually, I don't think it should be completely ignoring those messages. I think that's the problem, the messages appear to not be handled properly because they are ignored. The event being fired is the last event that the button fired, not newly generated from the message. So if I delete every state of a button from the database, then restart before it gets a message the previous event will be null and this is fired. If I double press a button it sends another double press five minutes later, same for single press and long press. Then every hour after maybe closer, it's pretty infuriating to wait unless you setup an automation then it is triggered over and over. I haven't had a chance to look into the source much more yet but it appears that the event is firing because a message was received regardless of whether the message was actually useful or not. I will grab you the logs, hopefully today or tomorrow. Sorry for lagging, I've just had a bunch of surgeries so I'm kinda messed up for the time being. EDIT: Its 2.09.03 beta channel package btw. |
|
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs. |
|
I posted logs in the other issue that I referenced. I think that this issue may have regressed, I am unsure it was actually fixed though. I'm still getting double events but only some of the times. For instance in that log, the first press actually triggered two events in home assistant. There's only mention of one event though. So I'm am thinking there is some sort of fall through that is expecting that a proper event has been generated but it has in fact been ignored or processed in another way. I still haven't had time to get into any of the code..... |
|
No this issue is not yet fixed, the PR is still in wiating list. |
|
Hi, yes i have this same problem with Ikea Tradfri shortcut button. it sends duplicate 1002 events on each button press. |
|
You are not alone, the PR is still here #4265 |
|
Please provide a deCONZ log that includes the |
|
Which toggle(s) will log that information? |
|
APS and aps_l2 |
|
I have the same issues with the tradfri shortcut button. I've included a sniplet of the log with APS on:
|
|
I'm frustrated with switches and buttons... My buttons are now becoming unavailable, the links turned red. Removing and re-adding them results in the same thing. There's nothing when I select APS toggles because the buttons don't appear to be working. In fact, all my switches and buttons are having issues with connectivity with this last update. I have had to reconnect switches that were working a bunch of times to get them to work again. Now I'm afraid they'll just stop working one day... |
|
The version v2.10.5 ? And not sure it s the same, because this switch have stoped working after the version 2.09.01 but was working fine before. |
|
The latest available version to me on Debian Buster is 2.10.04 / 3/14/2021 / 26660700 from beta. I am having trouble with Samsung, Sengled, and Hue switches. The Samsung are completely unusable, the others will go to sleep and then need to be reconnected with probably twenty attempts which hopefully makes it through a restart. Is there any reason why Alexa is finding the same device multiple times but only one is accessible? Because that's the behavior of all my other devices. And does Alexa not have the ability to use sensors and scenes from deconz over the local emulated phillips bridge? |
|
Lol, here there is too much question, I don't use alexa on my side, and for the HUE switches that disconnect, I don't remember an actual issue with that. |
|
Hue were the only working switches I had. I think there's some sort of problem with a recent version and compound devices. Every device I have that has multiple components is having issues as of some recent version, although I've no idea which. I can get APS from my Hue switch but my Samsung button is a red link, I could previously force read information to get it working but that doesn't appear to be doing anything anymore. Removing, restarting, and repairing results in the same. The other buttons are green until you try to use them then they turn red. Ironically still getting random hourly button presses but not actual button presses, lol.... |
|
Hello, I have the same problem here with aqara switches. Running deconz as a HASS plugin. I don't have any zigbee sniffer though. |
|
For what I can see it's the device sending out multiple times. Probably to make sure one is received :) |
|
The last PR (some days old) work only for tuya, but have a better log output. This PR is just a pach, it hide the problem (Known for tuya), not possible just using it for aqara if you are the only one with this problem without more information. |
|
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs. |
|
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again. |
|
I have an issue since using ZHA (with Conbee II) my IKEA TRADFRI always fires multiple events (4x) when pressing the button once: 
This leads to lights just flickering instead of turning ON. I already tried to reconnect the TRADFRI. With my Philips Remote everything works fine … |
This is something you need to have ZHA fix. |
|
For anybody encountering this issue ... I "fixed" it by adding a 2 second delay after any action: |
Describe the bug
On some Zigbee switches i've got multiple events on one press.
On TS0043 i've got two events, so one turns on the light and second event immediately after turn the light off.
On Aquara single button i have even 6 fired events!
Steps to reproduce the behavior
I don't know. It happen only on some switches.
Expected behavior
I expect only one event.
Screenshots
Deconz log:
Environment
HASSIO
core 2021.1.4
ConBeeII on RPI4 USB3 port
Version 2.07.01 / 8. 12. 2020
Firmware 26660700
deCONZ Logs
HA deconz_event listener:
{ "event_type": "deconz_event", "data": { "id": "car_switch", "unique_id": "00:15:8d:00:04:50:76:40", "event": 1002, "device_id": "8ca77365f3dcfc3ee5b140653b39858c" }, "origin": "LOCAL", "time_fired": "2021-01-16T13:24:25.247702+00:00", "context": { "id": "c6d94224df8f774ad7d40762250b9ecc", "parent_id": null, "user_id": null } } Event 100 fired 2:24 PM: { "event_type": "deconz_event", "data": { "id": "car_switch", "unique_id": "00:15:8d:00:04:50:76:40", "event": 1002, "device_id": "8ca77365f3dcfc3ee5b140653b39858c" }, "origin": "LOCAL", "time_fired": "2021-01-16T13:24:24.423746+00:00", "context": { "id": "878047f82de764ac9dced361b7350ed5", "parent_id": null, "user_id": null } } Event 99 fired 2:24 PM: { "event_type": "deconz_event", "data": { "id": "car_switch", "unique_id": "00:15:8d:00:04:50:76:40", "event": 1002, "device_id": "8ca77365f3dcfc3ee5b140653b39858c" }, "origin": "LOCAL", "time_fired": "2021-01-16T13:24:24.003543+00:00", "context": { "id": "b22bd330fcbf63b1876cee681e498903", "parent_id": null, "user_id": null } } Event 98 fired 2:24 PM: { "event_type": "deconz_event", "data": { "id": "car_switch", "unique_id": "00:15:8d:00:04:50:76:40", "event": 1002, "device_id": "8ca77365f3dcfc3ee5b140653b39858c" }, "origin": "LOCAL", "time_fired": "2021-01-16T13:24:23.795933+00:00", "context": { "id": "6fc82d1cd42fe6f22923d60a1dc7c261", "parent_id": null, "user_id": null } } Event 97 fired 2:24 PM: { "event_type": "deconz_event", "data": { "id": "car_switch", "unique_id": "00:15:8d:00:04:50:76:40", "event": 1002, "device_id": "8ca77365f3dcfc3ee5b140653b39858c" }, "origin": "LOCAL", "time_fired": "2021-01-16T13:24:23.696384+00:00", "context": { "id": "28d007542612cc64a8a88b1bfdb35d6e", "parent_id": null, "user_id": null } } Event 96 fired 2:24 PM: { "event_type": "deconz_event", "data": { "id": "car_switch", "unique_id": "00:15:8d:00:04:50:76:40", "event": 1002, "device_id": "8ca77365f3dcfc3ee5b140653b39858c" }, "origin": "LOCAL", "time_fired": "2021-01-16T13:24:23.529084+00:00", "context": { "id": "392550fe480ee14dda5c179deef288dc", "parent_id": null, "user_id": null } }Additional context
I suspect this happens on switches that I use multiple times. Maybe some remains in Deconz config?
The text was updated successfully, but these errors were encountered: