Button events repeating in mqtt stream, button not pressed!

[danpowpow]

I recently added a 4th and 5th dimmer remote to my hass system. Your bridge has been working flawlessly, but now one of the new remotes (number 4) is listed in the mqtt flow as being pressed everyone or 5 minutes. Interestingly the last_updated message has the correct timestamp (ie I will get a pair of messages, the 'button event'and directly after a 'last updated', but the last updated will show a time in the past which correlates with the last physical button press) I removed the new remotes and found that things calmed down for a day, but then the error / fake events switched over to an older remote! I've disabled your bridge on my pi hass and setup a separate pi3 with the latest node (8.9.1?) and only your bridge on it. The problem remains. I've tried renaming the remotes in the hue app. The name change is reflected in the mqtt flow, but I'm still getting random firings. The hue app shows no extra activity. I've deleted and re-added the remotes in the hue app numerous times but that isn't helping. The new remotes I've added have different printing on the back, but the same model number. Here's a link to an image: https://drive.google.com/file/d/1MxXZlZdiyxURuGdWOE7bEWmu2KstOcy8/view?usp=drivesdk Can you advise where to look for logs, or suggest what could possibly be happening? I'm stumped, and my lights keep turning on and off!

[ristomatti]

I believe I'm experiencing this also. I've yet to investigate further but after working pretty smoothly for several months my single dimmer switch began to randomly toggle the lights on. I have a somewhat complex automation setup of which the switch is a part of but it is my main suspect currently. Finding this report makes it even more so.

Might be some changes on the Hue Bridge firmware causing this?

@danpowpow have you solved the issue since?

[danpowpow]

@ristomatti sorry to hear about your problems - I am glad i'm not alone though with this problem! To see if it is indeed the same issue, run a mosquitto (or whatever mqtt you use) sub on a # topic, and leave it running for a while. I left mine in a tmux pane overnight to review the next day. I saw lots of button presses registered in the message list, but all had the same timestamp, and it was hours old. i fixed it / worked around it, by using the timestamp change as a trigger for automations, rather than a button press.

i documented my workaround here: https://community.home-assistant.io/t/extract-and-match-time-from-mqtt-payload-to-aid-automation/35546 it was a bit of a pain to set up but hey at least my lights aren't turning on and off randomly now!

all the best, dp

[ristomatti]

@danpowpow Awesome thanks! I missed the last_updated bit from your original report. I'll need to check the published timestamps as it definately is the switch creating the false triggers. If it is so, it might be easier to fix it in hue-mqtt-bridge code (to not publish the same event multiple times or something like that).

I find it a bit too hacky to subscribe to two separate MQTT topics and create an action based on that. That said it's a lot better than not using the switch at all as I've got so used to it I'd hate to let it go. :)

[ristomatti]

@danpowpow Based on quick testing I did yesterday it seems like I'm experiencing the same exact issue. I then proceeded to look at the hue-mqtt-bridge source code and added some debug prints to be able to see exactly what happens when these ghost button presses occur.

Unfortunately I didn't get a single one during the whole evening or last night. I'll try again during the weekend if I have time. If the debug prints give me some more insight I believe I'll try to fix the issue and create a pull request.

[ristomatti]

Finally the issue recurred! After looking at the code I got the understanding MQTT publish should only happen if something on the switch state changed (when requested from the Hue Bridge).

I had set console.log to print the stored and new state for the switch/sensor:

OLD STATE
{ state: { buttonevent: 2002, lastupdated: '2018-02-09T16:06:53' },
  config: { on: true, battery: 100, reachable: true, pending: [] },
  name: 'Hue dimmer switch',
  type: 'ZLLSwitch',
  modelid: 'RWL021',
  manufacturername: 'Philips',
  swversion: '5.45.1.17846',
  uniqueid: '00:17:88:01:02:1b:5b:af-02-fc00' }

NEW STATE 
{ state: { buttonevent: 2002, lastupdated: '2018-02-09T16:06:53' },
  config: { on: true, battery: 100, reachable: false, pending: [] },
  name: 'Hue dimmer switch',
  type: 'ZLLSwitch',
  modelid: 'RWL021',
  manufacturername: 'Philips',
  swversion: '5.45.1.17846',
  uniqueid: '00:17:88:01:02:1b:5b:af-02-fc00' }

In this case the only change is on the config.reachable property has chabged. Based on the code the publish event could also occur when the battery level changes. If I'm on the right track I'm not sure how to proceed with fixing this. Should there be a:

1) blacklist of changed properties to ignore 2) whitelist of changes to check 3) check if the timestamp has changed

@dale3h any thoughts on this?

[danpowpow]

@ristomatti thanks for taking this a level deeper than I was prepared to! My workaround is definitely hacky - I'm no coder hehe - but as you implied, when push comes to shove, functionality is paramount. From your options, i would think that no. 2 is the way to go; if Philips add/remove/change functionality, then a blacklist would/could never be comprehensive. @dale3h I'm happy to do any tests you may wish to run if you do come up with any ideas regarding this issue.

[ristomatti]

I've created a pull request #15 which should address this. I didn't test it extensively though.

@danpowpow if you're interested in testing you can either:

1. Clone my fork https://github.com/ristomatti/hue-mqtt-bridge and switch to branch "bug/repeated-events"
2. Just replace the index.js file on your current installation with https://github.com/ristomatti/hue-mqtt-bridge/blob/bug/repeated-events/index.js

[danpowpow]

@ristomatti - i've replaced the index.js and restarted the hue-mqtt-bridge. I'll monitor the mqtt stream and report back when i have anything to say. Thanks so much for looking at this.