Hue Dimmer Switch firing events every 5 minutes about hue-sensors-hass

[j3kestrel]

A possible simple solution is to report a 'None' click when there is no timestamp update instead of leaving the last click type. My preference would be to make the battery a separate sensor. I find it obnoxious that I have to template a battery attribute for every battery in my system. ...not just for Hue.

[j3kestrel]

I am seeing this issue at 5 minute intervals when my remote is cold enough that the battery isn't reporting a steady 100% charge. I expect that this can be fixed in the Hue Sensors code but would have to study the event stream/data flow a bit to figure the right place.

[yottatsa]

Please try this version.

[robmarkcole]

Very strange.. Any ideas @koying ?

[sragas]

Have the same issue here, but the time is varying betweent a few seconds and a few minutes. It seems like this only happens to the last used dimmer switch. Setup is only in Home Assistant with Template Sensor on last_update and regular autonation. Will also try to investigate this issue deeper.

[robmarkcole]

The component does not itself fire events so this almost certainly is an issue with the template/automation

[mmmente]

I circumvented the issue by placing a rbe (Report by Exception) node after the Hue dimmer switch and configuring it to "block unless value changes" on the property "msg.data.new_state.attributes.last_updated". Now it works as expected.

I guess the issue is, that the hue Hub sends the last pressed button every 5 minutes and the component passes it through.

[f-bader]

Did anyone has a good way to work around this behaviour without node-red.
The following automation will turn on the livingroom lights every 5 minutes until I use another button on the remote.
Maybe this implementation is flawed to begin with, but does anybody has a good idea.

- alias: hue_remote_TurnOnLightsInLivingRoom
  initial_state: true
  trigger:
    - entity_id: sensor.switch_livingroom
      platform: state
  condition:
    - condition: or
      conditions:
        - condition: state
          entity_id: sensor.switch_livingroom
          state: '1_click'
        - condition: state
          entity_id: sensor.switch_livingroom
          state: '1_click_up'
  action:
    - service: light.turn_on
      entity_id: light.livingroom

To define every possible state in the from: trigger seems a bit much, also what about dimming or if someone turned off the lights trough another method.

[raoulteeuwen]

could you try:

- alias: hue_remote_TurnOnLightsInLivingRoom
  initial_state: true
  trigger:
     - platform: state
       entity_id: sensor.switch_livingroom
       to: '1_click'
     - platform: state
        entity_id: sensor.switch_livingroom
        state: '1_click_up'
  action:
    - service: light.turn_on
      entity_id: light.livingroom

[CantConAnHonestJohn]

This really is annoying. I'd really like to help, but how can I debug that? I am having two hue dimmer switches of the same kind. One always works as it should (only fires when pressed), the other one is firing its last state every 5 (or sometimes 10) minutes. I even tried removing it with hue app and resetting but nothing changed.
@mmmente
A rbe node is a mitigation but not a real solution. You turn on your light with your hue switch, turn it off another way. Then how can you turn it on again with your hue switch without having to press two different buttons?

[mmmente]

@CantConAnHonestJohn I just live with it and get occasionally yelled at for having a stupid smart home... Did not find a solution, tried to understand the code and still no luck.
I am still hoping

[f-bader]

This worked somewhat for me. I switched to zigbee2mqtt in the end

- alias: hue_remote_LivingRoom_TurnOnLightsInLivingRoom
  initial_state: true
  trigger:
    - entity_id: sensor.switch_livingroom
      platform: state
  condition:
    - condition: and
      conditions:
      - condition: template
        value_template: "{{ trigger.to_state.state != trigger.from_state.state }}"
      - condition: or
        conditions:
          - condition: state
            entity_id: sensor.switch_livingroom
            state: '1_click'
          - condition: state
            entity_id: sensor.switch_livingroom
            state: '1_click_up'
  action:
    - service: light.turn_on
      entity_id: light.livingroom

[CantConAnHonestJohn]

@f-bader That is principally what the rbe node does in node-red, so you presumably experience the same problem as @mmmente and me, don't you?
You don't use robs hue sensor at all but only zigbee2mqtt and it still happens. Am I getting this right? Doesn't that mean that the device itself is in fact repeating its last state with zigbee messages? 🤔

[f-bader]

Yes that is what node red does. And yes the problem is the same, you can mitigate it a bit by adding click_up.

No with zigbee2mqtt I don't have the problem anymore. The remote itself does not send the event multiple times but only once.
That's one of the reasons why I replaced the plug-in with zigbee2mqtt.

[CantConAnHonestJohn]

@j3kestrel Fantastic observation 👍! This is a starting point. The one hue remote I'm having this problem with sent the following battery values in its last periodic (5 min) messages: 85, 88, 99, 93, 97, 100 after i took it from the wall to a warmer place. No more message for half an hour until now since it reached 100.
With this new information, could the sensor be fixed, so that changing battery values do not fire the last click event every five minutes? @robmarkcole @yottatsa

[yottatsa]

Please post a history for this remote. I'm not familiar with states it returns.

I could ignore battery readings, but this will break battery monitoring if you doesn't press any buttons for a long time. This is because there's only one way to change sensor state and attributes. The only viable option would be splitting it onto multiple devices and/or events.

[CantConAnHonestJohn]

IMHO getting the real click events should be the main purpose of this sensor component. If battery readings interfere with that purpose and fire periodic click events they should be changed to either only happen when a button is pressed and otherwise be ignored or be put in their own HA sensor. What do the others who are affected think?

If it can't be fixed I will soon have to replace this component with zigbee2mqtt like @f-bader to stop my wife from asking why the lights go on/out on their own so often.

@yottatsa the data part of the last four messages (not fired because of real clicks but probably because of changed battery readings):

2019-02-06T06:04:39.089Z

{"entity_id":"sensor.wz_fernbedienung","old_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":90,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T05:59:38.138206+00:00","context":{"id":"fbf974763b344291a3ad353fc801f524","user_id":null}},"new_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":99,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:04:39.035997+00:00","context":{"id":"f9fd688a71184cddbed367f25030d7a5","user_id":null},"timeSinceChangedMs":392048}}

2019-02-06T06:09:40.082Z

{"entity_id":"sensor.wz_fernbedienung","old_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":99,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:04:39.035997+00:00","context":{"id":"f9fd688a71184cddbed367f25030d7a5","user_id":null}},"new_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":90,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:09:40.030655+00:00","context":{"id":"0826068a096546d587edc1a125aa5652","user_id":null},"timeSinceChangedMs":693040}}

2019-02-06T06:24:43.113Z

{"entity_id":"sensor.wz_fernbedienung","old_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":90,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:09:40.030655+00:00","context":{"id":"0826068a096546d587edc1a125aa5652","user_id":null}},"new_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":88,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:24:43.049368+00:00","context":{"id":"32f756b947d649f9be6e453bfb0a721e","user_id":null},"timeSinceChangedMs":1596072}}

2019-02-06T06:39:45.088Z

{"entity_id":"sensor.wz_fernbedienung","old_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":88,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:24:43.049368+00:00","context":{"id":"32f756b947d649f9be6e453bfb0a721e","user_id":null}},"new_state":{"entity_id":"sensor.wz_fernbedienung","state":"4_click_up","attributes":{"last_updated":["2019-02-06","05:58:05"],"battery":96,"on":true,"reachable":true,"friendly_name":"WZ_Fernbedienung","icon":"mdi:remote"},"last_changed":"2019-02-06T05:58:07.029444+00:00","last_updated":"2019-02-06T06:39:45.031478+00:00","context":{"id":"53a6b2e67916454c9ce09aee9ebba1c1","user_id":null},"timeSinceChangedMs":2498047}}

[j3kestrel]

To ensure clarity, some form of this appears to be a correct solution:

#55 (comment)

[j3kestrel]

I won't be home for a few days, but will give it a try when I am. Thanks!

[CantConAnHonestJohn]

Thanks! I will test it tomorrow.

[CantConAnHonestJohn]

Thank you very much @yottatsa
As expected the events are still fired but the automations now work straight-forward again 👍
Nevertheless batteries should have their own sensors in the medium-term but that is nothing new and I think there already is some kind of consensus, see @marthoc 's conceptual thoughts and @robmarkcole 's and your answers in this thread: home-assistant/architecture#128 (comment)

[j3kestrel]

Working as expected here also. The one thing that I didn't expect is that the "attribute only events" come through as 'unknown' instead of None when viewed from AppDaemon. Thanks! :-)

[Norien]

This has come back up for me after upgrading to v2.4. In 2.2 I didn't have any issues.. Automation started to fire every 5-10 mins on last button pressed.

[Norien]

with v2.6 last pressed button is continuing to fire automation making lights blink on and off quite comically. I use a Toggle switch for each button but off!

  - alias: 'nursery_switch_1'
    initial_state: 'on'
    trigger:
      - platform: state
        entity_id: remote.nursery_room_switch
    condition:
      - condition: state
        entity_id: remote.nursery_room_switch
        state: '1_click_up'
    action:
      - service: switch.toggle
        data:
          entity_id: switch.nursery_lightswitch

[dotAnti]

I see the same behaviour in v2.4+
I user recorder: to track 'remote' and since v2.4 I get multiple events every minute for two of my remotes in the logbook.

[acordill]

Same problem here as well, only exception is that the light blinks on and off every second or so after toggeling the light once.

[Norien]

I also have constantly blinking lights all over the house with the v2.6 update. I have to use my switches as normal but always following a long press of an unassigned button to stop it.

[robmarkcole]

Can any of you provide some logs? It would be useful to see what events are firing around the time of this behaviour

[koying]

I confirm the "force_update" is not behaving quite like I expected.
I suggest to rollback that one for now, until I have a bit of time to find a proper solution.
#187

[robmarkcole]

Resolved in release 2.7

[inforsgit]

I’m very new to this component and in theory love it but am also running into this bug, even when running 2.7 :( I’m happy to dig into it and provide some logs but I think this one isn’t quite closed for now.