Currently there’s no direct way to trigger on a state attribute of an entity. You either have to make a template sensor that grabs the state attribute you want (or use the attributes custom integration that creates sensors based on a certain attribute in entities you define) and use it in a state trigger, or use a template trigger. Something like this would be nice:
trigger:
- platform: attribute
entity_id: climate.thermostat
attribute: hvac_action
to: 'cooling'
As much as I actually enjoy templating, this would still be useful.
To be honest, I am not sure whether this always worked, but it does now (example):
- alias: "Media player: sync KEF LS50 and TV volume"
trigger:
- platform: state
entity_id: media_player.kef_ls50
- platform: state
entity_id: media_player.tv
condition:
condition: template
value_template: >
{{ trigger.from_state.attributes["volume_level"] != trigger.to_state.attributes["volume_level"] }}
...
I used to also go through the “template sensor of an attribute”-route, however, this seems to work now (even though I think I tried this a few months before…)
I’m not sure I fully agree with you here. I understand that the route for Home Assistant have been to create separate entities for all kinds of data a device would provide and we end up with so many entities.
Take power consumption as an example. I believe power consumption should always be an attribute of an entity instead of its own entity but I also understand thats up to the integration to define atm.
Battery level would be another one.
Since attributes “cant” be used at the same places as entities we need to create template entities for them.
Why not make attributes addressable everywhere like many 3rd party integrations does like climate.thermostat.attribute.battery_level or even climate.thermostat.battery_level? That way we can use it in lovelace, scripts or automations.
Right, I’ve done this before too. It’s still clunky though and is triggering on every state/attribute change of those entities to check the template condition.
I think it makes sense to implement this similarly to appdaemon. Make it part of the state change/conditions and only trigger on specific attributes if they are supplied. Prevents having to have a completely separate trigger type and I’ve found it quite natural to use.