Repository navigation
Correct button vs. rotary caching issues - #456
Conversation
A live button press or dial rotation event no longer also reports whatever the other one last was: the bridge's cached device resource keeps each sub-service's last-known state independently, and HueButtonsMessage previously re-derived both from that sticky cache on every push with no idea which one actually just changed. hue-buttons.js now tells it via the updatedType already carried on the push event, so a button press correctly reports rotation as false (and vice versa), and a metadata-only push (battery, connectivity) reports neither. An on-demand status query still returns whatever was last known, as before.
HueButtonsMessage skips the services that did not fire the event with one check per service type instead of wrapping both searches in extra blocks. A live event is reported by exactly the service that sent it, so a doorbell ring also no longer looks through the regular buttons first. The node clears the cached button and dial states in a single loop.
|
@FredBlo thanks again – second pull request in a row that's less work to take than to write :) Your diagnosis was spot on. The bridge keeps the last event of every service separately, and It also fixes something you only mentioned in passing: a battery or connection update of a switch used to repeat its last press or rotation as if it had just happened. That hit the doorbell worst, because nothing ever clears its last ring – a battery update could ring it again. That's gone now too, and it has its own line in the changelog. I've pushed two small things into your branch: The check is flat now. Instead of wrapping both searches in an extra block, every service type is checked against the one that fired the event, so the change in Comments and tests are trimmed to the style of the rest. The tests themselves stayed – thanks for adding them, they're worth having. I checked that the message test actually fails without the fix. I also looked at "Send initial events": for buttons and dials nothing changes, because the bridge strips their states when it loads its resources, so there was never a cached press to send on startup anyway. The doorbell was the odd one out – its last ring survived that, so with the setting on it could ring again on every deploy or reconnect. With your change it stays quiet like the rest, which I think is the right call. It's in the latest update – v5.1.1 is out and on npm now. Thanks for taking the time to track this one down properly! |
Hi Foddy,
While using the button node with a tap dial, I noticed an issue :
In the current situation, the main output (when not additional one was defined using rules) output all calls (=working as designed). However, it seems to 'cache' part of message :
-> if a press a button, output is button:1 action"short_release" for example
-> But it also still has 'rotation' object info (the last one which was received) while i actually did not rotate now
The same logic also applies when rotating :
-> if you rotate, rotation info is OK
-> but button info (number and action) are also included in payload, while button was not pressed.
I improved this by making a difference between when an action (button / rotation) triggers the flow vs. last cached info usage to remain compatible with the existing structure. I tried to re-use your existing options logic.
PS : tests also added on this one when checking using Claude, I let you check & decide whether this is necessary