ptvoinfo / zigbee-configurable-firmware

PTVO firmware for CC2530, CC2531, and CC2652 Zigbee chips
https://ptvo.info/zigbee-configurable-firmware-features/
MIT License
211 stars 22 forks source link

Release gets sent without hold first #215

Closed mortenmoulder closed 1 year ago

mortenmoulder commented 1 year ago

I configured a device as a regular multi purpose switch with single, double, triple and hold/release. As discussed on Telegram, the delay between click and "send hold to coordinator" is about 2000ms. I will use 2000ms as an example further on.

If I hold down a button, I would expect to see "hold" in my Zigbee coordinator after 2000ms. However, if I hold down the button for maybe 1900ms and let go, it will instead send a "release" signal. The "hold" never gets sent to the coordinator. Here's a timeline example:


0ms: click button
2000ms: "send hold"
2500ms: release button
2600ms: "send release"

This is the intended behavior. I added a 100ms delay between releasing the button to device sending "release" signal, just as an example.


0ms: click button
1500ms: release button
1600ms: "send single_1"

Again, intended behavior. I didn't hold the button long enough to trigger a hold, therefore hold/release never gets sent. This is expected.


0ms: click button
1900ms: release button
2000ms: "send release"

In this example, "hold" never gets sent to the coordinator, but "release" signal is sent instead. Because the time clicked is less than 2000ms (which is the hold delay as we discussed on Telegram), I would expect it to send "single_1" instead of "release". It should never be possible to send "release" without a "hold" first, unless the switch is configured as a switch and not multi purpose (single, double, triple).

Can you try to replicate and confirm if this is an issue? Here is a clear screenshot that shows Z2M is able to receive a "release" without a "hold" first:

image

ptvoinfo commented 1 year ago

@mortenmoulder I've tested it on CC2530 and I cannot repeat this problem (if I press a button with a finger). Could you enable debug logs in z2m and check zigbee messages?

debug 2023-08-01 14:34:52Received Zigbee message from '0x00124b0022055177', type 'attributeReport', cluster 'genMultistateInput', data '{"presentValue":4}' from endpoint 1 with groupID 0
debug 2023-08-01 14:34:53Received Zigbee message from '0x00124b0022055177', type 'attributeReport', cluster 'genMultistateInput', data '{"presentValue":0}' from endpoint 1 with groupID 0

"presentValue":0 - release "presentValue":4 - hold

It is a good idea to verify it using a sniffer. Maybe, these messages were sent by a device but not processed by a coordinator.

mortenmoulder commented 1 year ago

@ptvoinfo What happens if you release it JUST before hold is supposed to be sent? It takes me about 10-15 tries to replicate this behavior. Depends how good I am at counting to 2 in seconds.

Release too early and it says single, release too late and it says hold+release, but release at the exact time, and it will just say release.

ptvoinfo commented 1 year ago

@mortenmoulder I get single_1. But I cannot catch a moment like in your 3rd example.

obrain17 commented 1 year ago

I can reproduce this behaviour on a CC2652P with this Input configuration:

image

Input 2 sends _singlel2, _doublel2 for short clicks and after having hold the button longer than 2 seconds: _releasel2. But no _holdl2 in between. Only presentValue = 0 can be seen in both Z2M log and sniffer:

image

@mortenmoulder I did several attempts with different time holding the button but cannot produce the behaviour that _holdl2 is sent ever.

Very interesting is the fact: Input 1 does send _holdl1 when pressing longer than 2 seconds, and _releasel1 afterwards. (no _single1, _double1 ... but On/off state for Output 1 as expected for a linked input) Shouldn't it send any multistate messages as it is configured as as linked to Output 1 ? (according GPIO inputs :

Link – The input immediately controls the linked output state (e.g., Input 1 – Output 1). The device sends the on/off state of the output to a coordinator. Otherwise, the input is independent.

Edit:

I tested the behaviour with a CC2530:

image

With a CC2530 it works as expected: Input 2 sends _singlel2, _doublel2 for short clicks and after having hold the button longer than 2 seconds: _holdl2 and then _releasel2 when relasing the button Input 1 also here sends hold_l1 when pressing longer than 2 seconds, and release_l1 afterwards. (no single_1, double_1 ... but On/off state for Output 1 as expected for a linked input)

So probably this issue is only connected to CC2652 ?

Edit 2:

Tried with another CC2652P: Everything is OK with this one. _holdl2 it sent correctly The only difference is that it is a P28/P29 Antenna switch instead of a P06/P05 one. I will do further invetigation and then report here.

ptvoinfo commented 1 year ago

@obrain17 Please reset the device that works incorrectly (by switching power or by Input 1). Maybe, the device restores keys mode from NVRAM.

obrain17 commented 1 year ago

Reset did not help, even worse: the device did not join anymore. Also no action visible on Wireshark sniffer. So it was probably damaged. (maybe by accidentally attaching 5V to VCC). Also re-flashing did not bring it up again.

I then flashed the firmware into a new module of the same brand (Ebyte E72) and now it works correctly.

Additional info: While sensors (e.g. DS18B20) are being processed (e.g. shortly before reporting) the processor might be too busy with that. Key press infos might not work in this short period.

Anyway it is not a usecase to check buttons and read temperatures with the same device.