state_trigger firing although value and old_value are the same.

[kmorris81]

This state_trigger keeps tripping even though the actual state doesn't appear to have changed. I will be at home and regularly/randomly get notifications on my phone from this function:

@state_trigger("device_tracker.my_iphone == 'home'")
def someone_arrived(**kwargs):
    log.info(f"Someone arrived, disarming system: {kwargs}")
    alarm_control_panel.alarm_disarm(entity_id="alarm_control_panel.ha_alarm")
    notify.mobile_app_my_iphone(title="Status", message="Someone arrived, disarming system.")

The logging above provides this output:

INFO (MainThread) [custom_components.pyscript.file.example.someone_arrived] Someone arrived, disarming system: {'trigger_type': 'state', 'var_name': 'device_tracker.my_iphone', 'value': 'home', 'old_value': 'home', 'context': Context(user_id=None, parent_id=None, id='xxxxxxxxxxxxxxxxxx')}

As you can see, both value and old_value are home; so I'm not sure exactly why this is happening.

My interim-fix is to manually check value and old_value inside the function and return if they are equal.

[craigbarratt]

I just confirmed an attribute change will cause HASS to send a new state changed event, even if the value doesn't change. That seems unexpected, but we'll have to live with it. I guess I need to figure out the exact cases where a state changed event can happen and make sure it is clearly documented.

So your workaround is the right one. You could also equivalently do it in the @state_trigger:

@state_trigger("device_tracker.my_iphone == 'home' and device_tracker.my_iphone.old != 'home'")

BTW - Yikes! Sorry about the unexpected disabling of your alarm.

[kmorris81]

Thanks for the quick and informational response.

None of my other state_triggers seem to exhibit this behavior. Perhaps it's unique to the mobile_app tracking and HASS companion app?

The fallout isn't a huge deal and neither is the workaround; I just wanted to verify that I wasn't doing something stupid or see if this was a known caveat to the pyscript implementation.

Thanks again!

[craigbarratt]

It would be great to confirm that it is in fact an attribute change causing the state change notification. Assuming you still have the if statement inside the function, before that can you log that state's attributes? This should do it:

log.info(f"device_tracker.my_iphone attributes = {state.get_attr('device_tracker.my_iphone')}")

[dlashua]

I can say, for certain, that many other devices trigger an update on attribute change that pyscript sees. I've taken to adding a .old check to almost everything, even when I'm not certain it needs it just because so many seem to do this.

[dlashua]

From what I can gather from the Home Assistant docs and from my experience with AppDaemon, a state_changed event is fired when any part (including state attributes) of a state changes. There are even some cases (i.e. a sensor with force_update: True that a state_changed event will fire when nothing has changed at all.

In the state_changed event, there should be three properties: entity_id, old_state, and new_state. These last two should be the entire state object, which includes attributes.

For this to work seamlessly, and with the least amount of confusion, @state_trigger (and task.wait_until) need to have something like a "only_on_change" kwarg which, I believe, should default to True. The code for this is pretty straight forward for checking the state:

if state_changed_event.old_state.state != state_changed_event.new_state.state

However, it's more complicated for attributes since the state_changed event is focused on the entire state. Hopefully, there's some way to track that, even though the state_changed event is for sensor.test, we are actually triggering on sensor.test.some_attrib and then the check can be:

if state_changed_event.old_state.attributes.some_attrib != state_changed_event.new_state.attributes.some_attrib

[kmorris81]

As suggested, I added the attribute logging, which for a mobile device includes lat/lon/alt, battery level, etc. Those things obviously change quite a bit throughout the day where as most of my other devices (lights, switches, misc sensors) don't seem to have attributes that change very often.

I'm very new to HASS and pyscript, but I like @dlashua's suggestion above with having pyscript compare the new/old states behind the scenes by default.

Perhaps a separate @attribute_changed decorator if you know the data you care about is in fact an attribute.

Or leave everything as-is and create a new decorator @state_changed that handles the new/old values specified in the decorator parameters?

[craigbarratt]

I agree that @state_trigger shouldn't evaluate the expression if some unmentioned attribute changes.

I'm adding additional comments to the PR #76.

[craigbarratt]

This is fixed with #82 from @dlashua. State triggers only are evaluated if the specific variables mentioned have changed.