Automations triggering on other attribute updates (since v0.2) about hue-remotes-hass HOT 25 OPEN

@iamcagn thanks for your detective work on this. Lets get @azogue input, as the main contributor to this repo recently

from hue-remotes-hass.

I have been getting two hue remote automations triggering randomly since updating to 0.2. One is a simple light turning on and the other is a script that turns off most lights and tv's off d/stairs. Rolled back to v0.1 and so far so good it is not happened since.

from hue-remotes-hass.

@grantclem having a template condition of:
{{ as_timestamp(now()) | int - as_timestamp(states.remote.ABC_bedroom_switch.last_updated) | int < 1 }}
Has solved the issue for me. It checks to ensure that the late_updated attribute is within 1 second of the automation trigger. So if the state of the remote changes (e.g. updated battery level) it won't trigger the automation. It may be possible to have a condition based on the changed attribute, but I'm not 100% sure.

from hue-remotes-hass.

@iamcagn I'm thinking I might want to add your timestamp consideration to my own code, just to be safe. Would you mind posting your full condition, including the timestamp consideration? I often get templates wrong, so it would be helpful to see yours. Also, can you click the "<>" button above so it is formatted as code? I know I'm being picky!! :) Thanks!!

from hue-remotes-hass.

@iamcagn Also, dumb question.... Maybe I am reading it wrong, but it looks like your condition is saying that it is greater than one second rather than less than one second difference between now and the last time it was updated.

from hue-remotes-hass.

@mikesalz I ended up changing it, but forgot to update it here. Also I can't get the code tags to work, so see https://pastebin.com/6X9j7QYD

Edit: found the issue returned, so I'll need to do some further troubleshooting.

from hue-remotes-hass.

@iamcagn Well, that stinks! Maybe @robmarkcole can review this issue?

from hue-remotes-hass.

Oddly it was working when I had it as > 1, so just doing some debugging at the moment.

from hue-remotes-hass.

So the last_updated in the state is a field set by HA, and is set when the state changed in HA, not the attribute from the remote. For that we need:
state_attr('remote.abc_bedroom_switch','last_updated')

That's returning a UTC time for me, so the difference between the two times is actually closer to 36000/36001. I don't know how to handle this without needing to update the difference when my timezone switches to daylights savings. Anyone have any suggestions?

from hue-remotes-hass.

@mikesalz

So I found the issue. The last_updated timestamp on the remote is UTC time, but since it has no timezone suffix, Home Assistant takes it as whatever your timezone is set to (e.g. +10:00 for me). as_timestamp() always returns the seconds based on UTC, regardless of what you pass to it (e.g. now() and utcnow() return the same value).

Since the last_updated time stamp is being assumed as local time, converting it to UNIX time it is adding/subtracting the local timezone from it. To work around this, you can append +00:00 to the string before converting, telling HA that it's already UTC time.

{{ as_timestamp(now()) | int - as_timestamp(state_attr(''remote.ABC_bedroom_switch'',''last_updated'') | join('' '') ~ ''+00:00'') | int <= 2 }}

Full condition:

condition: template
value_template: '{{ as_timestamp(now()) | int - as_timestamp(state_attr(''remote.ABC_bedroom_switch'',''last_updated'') | join('' '') ~ ''+00:00'') | int <= 2 }}'

I noticed that sometimes, maybe due to rounding as the remote time_updated doesn't go past seconds, that it would sometimes have a difference of 2 seconds. I've set the check to be less than or equal to 2. Your setup may vary, so you may need to adjust that comparison. So far I've had no false positives. There is a chance that the battery level could update within 2 seconds of pressing a button, but so far it's not occurred.

@robmarkcole would it be possible to include +00:00 at the attribute level, so I don't need to format it myself?

I suspect it's related to https://github.com/robmarkcole/Hue-remotes-HASS/blob/master/custom_components/hueremote/implemented_remotes.py#L104:
"last_updated": self.sensor.lastupdated.split("T"),

but I'm no coder, at best I can hack together things from other peoples code.

from hue-remotes-hass.

Hi @iamcagn, wow!

I'll try to summarize the issue here:

• Using a generic state change trigger makes false positives when something changes, even when nor the press code or the bridge timestamp change.

Yes, that is true and could be inconvenient.

Let's see how HA works, and the actual trends in dev:

• In HA automation, state triggers are checked by 2 ways: with specific to/from state, or generic. In the 2nd case, the trigger fires when anything in the state+attributes is changed (like the battery level, which is known to oscillate when batts are not at 100%). So this is per design in HA core.
• In "modern" HA integrations, battery levels are extracted into separate special entities, linked to the same device in the devices list (and then they show the batt level in the right column)
• Also, the actual trend in development is to extract anything "variable" and unrelated to the main state into different entities, always grouping them in devices. Also, constant attributes related to the physical devices are encapsulated in the device_info property, to be shown/stored at device level, instead of entity level.

Now about the lastupdated attribute:

• In HA every entity has a last_updated and last_changed attribute, related to the HA state, but these don't say anything about when the buttons are pressed, it only talks about when HA sees those changes. These attributes are internal datetimes in UTC.
• But the Hue bridge also stores the "real" timestamps of the button presses, with a naive timestamp (but in UTC). We are showing it as an extra state attribute lastupdated made by splitting the ts string in a date/time tuple. Why is that is something I don't know, but the thing is that timestamp is never parsed into a datetime, so it looks similar to the state.last_changed but it is a simple string from the hue bridge data.
• In HA >=0.108, with remotes implemented and firing events hue_event, HA is also using internally this lastupdated string to check for new presses (because if not, a new press on the last pressed button would pass undetected)

So everything above must be taken into account. Now, finally, how to address the specific problem of false positives? ---> Do not use generic state triggers :)

My general suggestion for a scenario like this: instead of 1 generic trigger + 4 "or" conditions, make it 4 specific triggers:

trigger:
- entity_id: remote.abc_bedroom_switch
  platform: state
  to: 1_click_up
- entity_id: remote.abc_bedroom_switch
  platform: state
  to: 2_click_up
- entity_id: remote.abc_bedroom_switch
  platform: state
  to: 3_click_up
- entity_id: remote.abc_bedroom_switch
  platform: state
  to: 4_click_up
action:
  service: script.abc_bedroom_hue_remote
  data_template:
    button: '{{ trigger.to_state.state }}'
    room: abc_bedroom

And at this point, you could say to me: "sorry, but I tried that and it didn't work!". And you may be right :) (I'm not sure, but I can imagine that it won't work for repeated presses)

But there are solutions for this: Use device triggers without any extra custom integration

Device triggers for button presses are implemented in last HA, and they won't fail because of a battery level change. They will fire if the button changes, or if the sensor lastupdated string changes. So this issue is solved with them, and, in fact, after HA 0.108 this CC is basically deprecated:

• You have the battery level of remotes in their own battery entity
• You have the device info (almost every constant attr) of the remote assigned to a "device" in HA.
• You have events fired when a button press is detected
• You have "device triggers" to easily configure these events as automation triggers from the UI.

So every piece you need is already present, just in a different way :), but is the general trend for modern HA, so we should get used to it.

"Ok, but what you said doesn't mirror completely what we have with this CC!". Well, you're right again. Let's review what main Hue doesn't give us, and suggestions to overcome that:

• I want to have a HA entity to show what the last button press was, when it was, have a state "history" of it, etc ---> Use eventsensor CC to create a sensor entity for each remote press event.
• I need a faster refresh rate for sensors&remotes than the 5s of the main hue ---> Use fasthue CC to enable any refresh rate you want, and even use different rates for each bridge or change it dynamically.

I hope I've been of any help :)

from hue-remotes-hass.

About what to do, if something, in this repo right now, relating to this issue, my only suggestion would be to:

• remove the battery_level attribute from the remote entity, so battery oscillations don't affect the remote state, so no STATE_CHANGED event, and no extra trigger fires.

As things are right now, main hue already creates sensor entities to track the battery level of remotes, so that attribute is not necessary!

from hue-remotes-hass.

@iamcagn Unfortunately, I just encountered the same issue as you, with automations firing after a non-button press event. @azogue I sure how you guys can fix this!! :)

from hue-remotes-hass.

@azogue thanks for the great insight in your answer. Regarding you point after HA 0.108 this CC is basically deprecated:, I am thinking this could be the time to archive this CC, and point users to your CC.

from hue-remotes-hass.

What seems to trigger my automations randomly is that the remote goes unavailable for 2 seconds randomly through out the day which in turn ends up as a state change that triggers the automation.

from hue-remotes-hass.

What seems to trigger my automations randomly is that the remote goes unavailable for 2 seconds randomly through out the day which in turn ends up as a state change that triggers the automation.

Hi @acordill, I suppose when that happens you also get a "Fetching error" for the hue integration in the HA logs, right?

In the last version we are sharing basically everything with the main hue, and the remote entities created here inherit from the GenericHueSensor, so when one of the requests to the hub fails and the main hue sets all sensors as unavailable, the remote entity also moves to unavailable.

This usually only lasts 1 update interval, but the 'collateral damage' is that 2 state change events are fired, first one going to unavailable and the 2nd restoring the old state, resulting in another false positive.

Again, this is fixed for hue device triggers or automations listening directly to hue_event (the button press event is not fired in these 'unavailable' moments)

Also, if using the eventsensor CC from HACS to extract those events to a sensor entity, for those entities that 'bug' is never going to happen, as they rely on fired events.

So, 1 more reason to migrate :)

cc @robmarkcole

I am thinking this could be the time to archive this CC, and point users to your CC.

I'm currently working on an update for eventsensor to move it to UI config flow, no HA-restart, etc. Also trying to make easier the migration with a config wizard for hue remotes, so if you wait a bit I can redact the migration instructions by this week.

from hue-remotes-hass.

Thanks for the info. Yes lets ty make the transition as smooth as possible, and well communicated

from hue-remotes-hass.

What seems to trigger my automations randomly is that the remote goes unavailable for 2 seconds randomly through out the day which in turn ends up as a state change that triggers the automation.

Hi @acordill, I suppose when that happens you also get a "Fetching error" for the hue integration in the HA logs, right?

In the last version we are sharing basically everything with the main hue, and the remote entities created here inherit from the GenericHueSensor, so when one of the requests to the hub fails and the main hue sets all sensors as unavailable, the remote entity also moves to unavailable.

This usually only lasts 1 update interval, but the 'collateral damage' is that 2 state change events are fired, first one going to unavailable and the 2nd restoring the old state, resulting in another false positive.

Again, this is fixed for hue device triggers or automations listening directly to hue_event (the button press event is not fired in these 'unavailable' moments)

Also, if using the eventsensor CC from HACS to extract those events to a sensor entity, for those entities that 'bug' is never going to happen, as they rely on fired events.

So, 1 more reason to migrate :)

cc @robmarkcole

I am thinking this could be the time to archive this CC, and point users to your CC.

I'm currently working on an update for eventsensor to move it to UI config flow, no HA-restart, etc. Also trying to make easier the migration with a config wizard for hue remotes, so if you wait a bit I can redact the migration instructions by this week.

Thank you. I just switched over to using your eventsensor, seems to have fixed my issue so far.

from hue-remotes-hass.

I too will try out the eventsensor/fasthue CC's instead, if it means less work to get the automations working then it sounds good to me.

from hue-remotes-hass.

I've converted my things over and found no issues so far. For those who have remotes, you can use the state map below and save a little time having to type it out ;)

state_map:
1000: 1_click
1001: 1_hold
1002: 1_click_up
1003: 1_hold_up
2000: 2_click
2001: 2_hold
2002: 2_click_up
2003: 2_hold_up
3000: 3_click
3001: 3_hold
3002: 3_click_up
3003: 3_hold_up
4000: 4_click
4001: 4_hold
4002: 4_click_up
4003: 4_hold_up

from hue-remotes-hass.

I can redact the migration instructions by this week.

It took a little bit more than I wanted, but at last there is a proposal in #16, please take a look

from hue-remotes-hass.

For those who have remotes, you can use the state map below and save a little time having to type it out ;)

@iamcagn check the new version of EventSensor, with UI configuration and wizard to configure Hue remotes :)

from hue-remotes-hass.

@azogue Thank you so much for all of your hard work! I installed EventSensor. Just to make sure I understand, my best bet is to capture the event data, correct? I see the data changing in the sensor details in the HA UI, but I must be missing something in my automation yaml. I tried capturing both forms of "1 clck up." It works, but it takes several seconds before a click is registered and the trigger fires. How should I write my trigger?

  trigger:
    - platform: state
      entity_id: sensor.loft_hue_switch
      to: '1002'
    - platform: state
      entity_id: sensor.loft_hue_switch
      to: '1_click_up'
  action:
    - service: light.turn_on
      entity_id: light.loft_ceiling_fan_light

from hue-remotes-hass.

Hi @mikesalz,

It works, but it takes several seconds before a click is registered and the trigger fires

That is because of the hue polling every 5 secs. It is not a problem with the automation trigger (or the EventSensor CC)

For an immediate response, you need to use another ZigBee controller for your switches (like a conbee usb stick with the deconz integration, for example)

If you don't want to change and need a faster polling rate, use the Fast-Hue Polling CC, as it is described now in the README.

BTW, in your automation you don't need the 2 triggers: if using a state mapping, leave only the 2nd one, and if not, then the "code" would not be "1002" but 1002 (a number instead of a string).

from hue-remotes-hass.

Thanks for for the info, @azogue! I will give the Fast Hue Polling CC a try. I do still have a problem, though. This issue has not been resolved with the new CC. The buttons still "stick" until a different button is pressed.

from hue-remotes-hass.