Prevent Xiaomi reset on long press #1060
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Respond to long press like stock hub does.
Currently added behavior only to devices I own, but most likely applies
to "without neutral" variants as well, since those lie in-between battery
and "with neutral" devices.
Remaining questions:
options
(device specific configuration) needs to be passed toonEvent
or I need a way to obtain it using the passed indevice
. Or, does this need to be dynamically configurable via mqtt?[0xaa, 0x10, 0x05, 0x41, 0x87, 0x01, 0x01, 0x10, 0x00]
On wired devices in the report, the last octet is always 0, and the "counter" octet (after
0x84
) is always 1.On wireless buttons, the last octet was 1 (like in the
write
response from hub) and the counter was incremented on the device side, sometimes by 2.The
write
response always has0x47
instead of0x87
, so that bit is moved, always 1 in the last octet, and is generally identical for all devices tested, just merrily incrementing the counter (IIRC globally, for any device it sends this to). Not incrementing the counter didn't interfere with the functionality of this PR, even if the response value was less than that in the report, so its purpose remains unknown.It might be worthwhile to mess around more with what we send and see what works, but currently the goal is achieved.
I tested this with CC2531 to not disturb my production networks.