Template all open windows on a floor?

Configuration
1

I defined my entities with areas and floors.
Now I would like to use the assined floor to filter the entities in a template.

E.g. all open windows on a floor

There does not seem to be a funktion to get all entities on a floor. Just in an area.

This is what I use for a different area:

{{ states.binary_sensor 
      | selectattr('attributes.device_class', 'defined')
      | selectattr('attributes.device_class', 'eq', 'window')
      | rejectattr('entity_id', 'in', area_entities('Hobbyraum'))
      | rejectattr('entity_id', 'in', area_entities('Hauswirtschaftsraum'))
      | rejectattr('entity_id', 'in', label_entities('Dach'))
      | selectattr( 'state', 'eq', 'on') 
      | list | count }}
2

https://www.home-assistant.io/docs/configuration/templating/#floors
image

3

FWIW, starting from one of the entity list functions like area_entities() or floor_entities() and selecting with the newer tests like is_state_attr() can result in a simpler template. The new tests eliminate the need to check if attributes are defined like you do when starting from the state objects.

{{ floor_entities('First Floor')
| select('is_state_attr', 'device_class', 'window')
| select('is_state', 'on') 
| list | count }}
2 Likes
4

New? these have been around for some time no?

5

The functions have been around for some time, but they weren’t useable as tests in selection filters until relatively recently, compared to other common tests like in, eq, etc. Since they are custom to HA, they are not documented in the Jinja docs; so not all users are aware of them.

6

Sorry, but I must be missing your point. What recent change are you referring to?
Just 1 ancient template in my backend config to maybe illustrate what you can see as new?

  - binary_sensor:

      - unique_id: selected_hue_group_active_scene
        state: >
          {% set select = states('input_select.hue_group')|slugify %}
          {% set group ='light.' + select %}
          {{is_state_attr(group,'dynamics',true)}}

and one in the Frontend Markdown:

              {%- if is_state('binary_sensor.dst_alert','on') -%} - Dst: Klok 1 uur {{is_state_attr('sensor.daylight_savings_times','dst active',true)|iif('terug','vooruit')}}!{{'\n'}}{%- endif -%}

(it’s not very important, Im just curious to maybe have missed something useful :wink: )

7

Just to clarify, my use of the words “new” and “newer” was relative to the tests OP was using in their first post. I was not trying to say this is “brand new”, “never-before-seen” functionality.

Your examples uses is_state_attr as a function acting on a single entity ID, not as a test in a select filter that iterates over a list of entity IDs…

{{area_entities('Kitchen')|select('is_state_attr','brightness',254)|list}}

… that functionality was added more recently than what is shown in your examples. And, it has become more and more useful as each of the entity listing functions have been added; reducing the need to use for loops and the expand function.

1 Like
8

yes, I overlooked that, sorry.

{{integration_entities('Philips Hue 2')
                | select('is_state_attr','is_hue_group',true)|list}}

and the likes a are useful, especially with labels :wink:

      - unique_id: mill_heaters_samenvatting
        state: >
          {{label_entities('mill')|select('is_state_attr','hvac_action','heating')|list|count}}

cool, great options indeed.
as you say, could be pointed out a bit more