Add attribute condition (for visibility and conditional cards)

[Mariusthvdb]

please consider adding a condition like

- condition: state
  entity: climate.thermostat
  attribute: hvac_mode
  state: heat

or

- condition: numeric_state
  entity: sun.sun
  attribute: elevation
  below: 20

from the automation condition:

  condition: numeric_state
  entity_id: climate.living_room_thermostat
  attribute: temperature
  above: 17
  below: 25

and

  condition: state
  entity_id: climate.living_room_thermostat
  attribute: fan_mode
  state: "auto"

maybe this would be an alternative syntax if the 'state' for the attribute would be confusing:

- condition: attribute
  entity: climate.thermostat
  attribute: hvac_mode
  value: heat

so we can directly conditionalize based on an entity's attribute and not have to create template entity first as an intermediary.
not sure which syntax would be best, considering the other reserved words in HA, and also comparing to https://www.home-assistant.io/docs/automation/trigger/#triggering-on-attribute-changes

Thanks for considering

[Stutchbury]

This certainly seems an omission of documented functionality that would be very useful if implemented. As a workaround, I've created a template sensor but that is not particularly (new) user friendly!

Edit: Would also like to add 'Badges' to the list as that is what I'm trying to hide/show.
Edit 2: As there is a mismatch between the documentation of conditions and the implementation, I thought it appropriate to raise an issue: #22215

[TheMClaeys]

Ooh, that's why this isn't working?
I was trying to set some buttons only visible if some attributes where met, but couldn't get it to work, while in documentation for numeric state it was mentioned somewhere on the forum the attibute value was possible for automation triggers.

For me for example it's a button to open all blinds. It should only be visible if any one of the blinds isn't completely open (so attribute current_state below 100).

[Stutchbury]

You can create (fake?) a sensor from a template defined in configuration.yaml:

template:
  - sensor:
      - name: "Your template name"
        unit_of_measurement: "Days"
        device_class: "duration"
        state: "{{ state_attr('sensor.your_sensor_name', 'your_attribute_name') }}"

And that will be listed in the visibility conditions as a sensor. A bit of a kludge but it works.

I've not yet found a link to a definitive list of unit_of_measurement or device_class but if you specify an invalid one you'll get a notification which if you follow through to the log will show you a list of valid ones!

HTH

[TheMClaeys]

Thanks, great tip as a workaround. I'll be trying that.

[Jonny-T-cyber]

I also agree with this request.
It would be really VERY useful!
Thank you and congratulations

[teskanoo]

This would be massively useful

I have a Lovelace view for every room and am reusing the same YAML for each room.
I have sections for climate, thermostat, media players, lighting, scenes, switches, occupancy etc.
Not every section is applicable to every room so I have to create a separate helper for everything I want to show/hide

binary_sensor.has_thermostats_bathroom
binary_sensor.has_media_players_bathroom
binary_sensor.has_climate_readings_bathroom
binary_sensor.has_climate_windows_bathroom
binary_sensor.has_climate_doors_bathroom
binary_sensor.has_scenes_doors_bathroom

With the implementation of attributes access in conditions I could simple have one template sensor that stores all the required data after startup

template:

- sensor:
  - unique_id: lovelace_room_detail_helper
    name: lovelace_room_detail_helper
    state: "THIS WOULD BE AWESOME - PLEASE IMPLEMENT - home-assistant/frontend/discussions/21550"
    attributes:
      # Main
      has_thermostats_bathroom: true
      has_thermostats_bathroom: "{{area_entities('bathroom')|select('match', '^climate')|count}}"
      has_climate_readings_bathroom: "{{area_entities('bathroom')|select('in', label_entities('climate_reading'))|count}}"
     # and so on
     ...

[karwosts]

In general the maintainers have decided that they are slowly moving away from attributes and new UI features related to attributes tend to get denied.

Case in point:
#10241

[Mariusthvdb]

yes, thanks for posting to that again.
That is an ancient discussion however, and many things have changed since 2021/2 .... ;-)
hope this will be reconsidered.

Of course we are aware of the move to singled out attributes, the config options for the attributes that (will) remain could be used the conditional options. There are many core entities still having sane attributes, and we even have the dedicated card options for entities, offering the type: attribute to single those out in the card.

it would be very consistent to be able to use that attribute option (read, feels very inconsistent we can Not.... ) in the conditional/visibility) and are forced to create extra more template entities.... the UI is getting slower and slower because of the entity creep, which would be an extra reason to reconsider

Ive opened a WTH yesterday..... there is no such thing as coincidence....

[fsmythe]

This would be very useful.

I am using Chore Helper which generates sensors that can be 'completed' but the completed state is an attribute. So it would be very helpful to have the attribute as a visibility condition.

It's all very well to say that developers are moving away from attributes. But for one as far as I can tell they are not and for another all the historical integrations people have set up do and will continue to use attributes.