Useful template examples relating to lights that I wish I had known earlier:

[Didgeridrew]

@DefenestrateIT

How do you filter the ‘light’ domain entities from a list of random entities?

{{ expand(area_entities( lights.area_id )) 
| selectattr( 'domain' , 'eq' , 'light' )
| map(attribute='entity_id')
| list }}

[DefenestrateIT]

Thank you (Love the name btw). @Didgeridrew

[123 (Taras)]

@DefenestrateIT

I have edited my original post to include (my interpretation of) your input

The links you added aren’t what I had suggested you should do.

The template examples you have posted are obviously copied from somewhere else in the community forum. Instead of copying a template, just post a link to the forum topic where you found it.

A link allows the reader to see the template’s original context and commentary. In addition, if the reader has questions about the template, they can ask the template’s author. Odds are that the question they have may have already been asked and answered by someone else.

[DefenestrateIT]

The links you added aren’t what I had suggested you should do.

I know, that’s why i wrote “my interpretation of”. To do what you wanted would destroy what i am trying to do, except if i add a foot note wrapped in {##} under an example. But honestly,

The template examples you have posted are obviously copied from somewhere else in the community forum.

The only code i have out write copied so far is Petro’s line ‘| rejectattr ( ‘attributes.entity_id’ , ‘defined’ )’, which i still don’t full understand how that works. But there’s a link to it at the bottom in ‘Counts the lights on’.
There is the line about hue groups & I did come across that some where that i can’t remember where but i change the name from hue to deconz (as that is what i use) & presto it worked.
Other than that, it’s all original code. When I say i am a newbie, I am a newbie with HAss. Tho I haven’t done any real coding in almost ten years, so I am a bit rusty.

btw - The white space is there because that is how I taught my self how to code 30 years ago. I always found it easier to read complicated formulas like that.

[petro]

FYI to tag people use @… @DefenestrateIT

To quote people, highlight the text and click quote.

@DefenestrateIT

Undoubtedly, but that is the way with all thing eventually, naturally (30 years in the industry here, most of what i have learned is obsolete).

[petro]

@DefenestrateIT

The only code i have out write copied so far is Petro’s line ‘| rejectattr ( ‘attributes.entity_id’ , ‘defined’ )’, which i still don’t full understand how that works. But there’s a link to it at the bottom in ‘Counts the lights on’.

Read up on state objects

Last_updated State and last-changed in Lovelace

Ok, so this is where things get funky. You should familiarize yourself with home assistant state objects. This is what home assistant passes around when doing pretty much anything. These state objects contain 8 or so properties. Do not get these properties confused with the devices attributes. These properties are: Field Description state.state String representation of the current state of the entity. Example off. state.entity_id Entity ID. Format: .<object_id>. Example: light.…

@DefenestrateIT

rejectattr

Rejects items from a collection based on an attribute of the object (In python, they aren’t attributes, they are properties). Do not confuse the attr of rejectattr with attributes on the state object.

@DefenestrateIT

‘attributes.entity_id’

This is the attribute of the states object that you’re rejecting.

@DefenestrateIT

‘defined’ )

Does that attribute exist.

Putting it all together. You’re rejecting lights that have the entity_id attribute. Which specifically targets light groups as they are the only lights that have the entity_id attribute.

[123 (Taras)]

@DefenestrateIT

To do what you wanted would destroy what i am trying to do

If you are trying to eliminate a template example’s “how and why” then you have succeeded.

You have also succeeded in formatting the template examples in a style that doesn’t conform to common practice or the official documentation.

At the very least, use YAML code tags (the </> icon in the forum’s editor).

[CentralCommand (Mike)]

@DefenestrateIT

              | rejectattr ( 'attributes.entity_id' , 'defined' )

Is the goal of this line to remove light groups from the list? If so here’s a more accurate way to do that:

              | rejectattr ('entity_id', 'in', integration_entities('group'))

Relying on whether random attributes are defined or not isn’t really good practice. Yes light groups have that attribute but there’s no rule saying that other lights don’t or can’t. You may accidentally exclude random lights from integrations that happen to set that attribute or users that have added it via customization.

integration_entities returns a list of all the entities for a particular integration (group in this case). So excluding everything that comes from that integration is a foolproof way to do that filtering.

I’m not really familiar with these attributes but I’m guessing similar issues apply:

@DefenestrateIT

              | rejectattr ( 'attributes.is_deconz_group' , 'true' )
              | rejectattr ( 'attributes.is_hue_group' , 'true' )

[CentralCommand (Mike)]

@DefenestrateIT

But how would you write a Template that only lists Groups?

Also that’s trivial:

{{ integration_entities('group') }}

[CentralCommand (Mike)]

TBH I’m a bit confused by this whole post. There’s a whole doc on templating here:

Templating

It describes all the filters, provides lots of examples, etc. The Jinja documentation is also very good and explains all the basics, along with the extremely important built-in filters and built-in tests sections. Both the Jinja doc and the HA doc are linked directly in HA on the Developer Tools → Templates page.

So what is this community guide adding exactly? If you think there’s some key example missing then why not just add them to the documentation? There’s an edit button right at the bottom of the Templating document. Click it and add in the relevant examples. Instead of compiling another list of examples here hidden away in community guides?

[Didgeridrew]

@CentralCommand

Also that’s trivial:

{{ integration_entities('group') }}

I think that’s meant to be rhetorical… as if this is a worksheet that someone is using to learn about templating… Based on the “theme” and previous examples it’s also probably meant to be Helper Light groups like:

{{ states.light 
| selectattr( 'attributes.entity_id' , 'defined' )
| map( attribute = 'entity_id' ) 
| list }}

But it’s confusing…

@DefenestrateIT

@DefenestrateIT

Once again Newbies copy & paste the code bellow into your “Template editor:” Change
“office”, “light.office_lights_group” & “0123456789abcdef0123456789abcdef”
to your appropriate parameters for your setup.

{#For newbies in setting variables to test blueprints with Developer Tools:#}
{% set lights = { 
                "area_id" : "office" ,
                "entity_id" : "light.office_lights_group" ,
                "device_id" : "0123456789abcdef0123456789abcdef" }
%}
{{ lights.area_id }}  >< {{ lights.entity_id }} >< {{ lights.device_id }}

The section starting with the above quote has errors (area_id and area_name are not interchangeable) and makes no sense in term of audience and structure. If the target audience is users with little-to-no experience with templating, how are they going to know how to get a device_id, entity_id, and area_id? By starting it this way you create an impediment to new users and also cultivate an incorrect assumption that it’s necessary to set up a multi-part variable in order to access entity attributes.

[petro]

The only drawback to that statement is unavailable entities do not show up under integration_entities. So you’re forced to use these work arounds to actually find all your lights, available or not.

[CentralCommand (Mike)]

They seem to show up for me…

Config for always unavailable light:

light:
  - platform: template
    lights:
      always_unavailable:
        unique_id: always_unavailable_light
        friendly_name: Always unavailable
        value_template: "on"
        level_template: "100"
        turn_on:
          event: now_im_valid
        turn_off:
          event: now_im_valid
        availability_template: "false"

Made a light group in the UI and put that light in it. Both lights definitely exist (that’s why I used the not recommended syntax of states.<entity ID>, got no errors), both have state unavailable, the group’s entity ID still comes back from integration_entities.

EDIT: I also just noticed that my “always unavailable” light group does not have an attribute of entity_id:

So it actually seems like the inverse might be true. integration_entities just works. Trying to find group entities by looking for the attribute entity_id requires extra work to handle edge cases, like when they are unavailable.

[petro]

Hmm might be a bug in the integration I was helping a guy with earlier.

[DefenestrateIT]

Sorry crashed out last night. It was 1am where i am, & i have things to do today.
@petro

@petro

Read up on state objects

Will do, I will be doing that over the next few days.

@petro

Putting it all together. You’re rejecting lights that have the entity_id attribute. Which specifically targets light groups as they are the only lights that have the entity_id attribute.

Hmm ok.

@CentralCommand

@CentralCommand

Is the goal of this line to remove light groups from the list? If so here’s a more accurate way to do that:

Yes. Sweet thanks for that.

@CentralCommand

{{ integration_entities('group') }}

This is exactly the type of feed back i want.

@CentralCommand

Also that’s trivial:

For you it is, not a newbie like me it isn’t. Once again, it’s a rhetorical question designed to encourage the user to start playing with the code for them selves.
What I love about the template editor is that you can play with code & see straight away what the result is, great way to learn.

@CentralCommand

TBH I’m a bit confused by this whole post. There’s a whole doc on templating here:

Thank you for those links (I had just started asking my self the question of is there a isvalid command), I do have a hyperlink to that page on the original post but, for E.g.

{% if variable is defined %}
    value of variable: {{ variable }}
{% else %}
    variable is not defined
{% endif %}

You look at that & it makes total sense to you, but a newbie looks at that & is not sure what parts of that statement can & should be changed. Having some code that shows the user immediate results & can be change easily so the user can see how it works, is what is missing. The default Demo Template tries to do this, but there isn’t enough examples & none of it is to do with the lights, which is what almost every newbie starts off with.

Any way thanks heaps everyone, your input has been greatly appreciated. I hope you continue to take an interest, & share your vastly more experience with me & others on this post.
So that it’s clear what is the point of this post? It is that I am trying to learn Jinja2 Templating for home assistant. I would have liked more examples in the style I have above, & I am more than happy to share what I have learn on this adventure. Since I got half a dozen like within a few hours of posting the original, I assume other newbies agree.

The point of the Second code block will be dealing with 3 different types of variable data ‘entity_id’, ‘device_id’ & ‘area_id’ because that is the data a user will using when making A blueprint targeted at lights.

[CentralCommand (Mike)]

@DefenestrateIT

For you it is, not a newbie like me it isn’t. Once again, it’s a rhetorical question designed to encourage the user to start playing with the code for them selves.
What I love about the template editor is that you can play with code & see straight away what the result is, great way to learn.

It’s trivial for everyone that reads the docs on templating because it’s right here:

integration_entities(integration) returns a list of entities that are associated with a given integration, such as hue or zwave_js.

Which brings me back to my question, what is the point of this guide? Users that want to learn about templating should read the templating doc, it tells you everything you need to know and is filled with examples.

And again, if you think some examples are missing, why not just edit the page and add them? There’s an edit button right at the bottom.

EDIT: Just to be clear, I’m not trying to be mean. I appreciate that you want to help, that’s great! But it feels like the energy is directed in the wrong place.

The templating doc is linked directly in the product from the templates tab in developer tools. It’s also linked all over the documentation and this forum, basically every time templates are mentioned that doc is linked. If you still think that templating is difficult and confusing after reading it then that is the place to correct. This guide on the forum doesn’t have that kind of reach.

[DefenestrateIT]

@CentralCommand

And again, if you think some examples are missing, why not just edit the page and add them? There’s an edit button right at the bottom.

I don’t think I am any where qualified to do that yet. I probably will in the end when I feel a lot more confident, but not yet.

@CentralCommand

Just to be clear, I’m not trying to be mean. I appreciate that you want to help, that’s great! But it feels like the energy is directed in the wrong place.

All good. I am just happy that i have got the attention of others who have vastly more knowledge than i & have been Critiquing my work for errors & are willing to share better ways of doing it.

[DefenestrateIT]

I have Two HAss’s connected in two locations, via ‘HACS’ - ‘Remote Home-Assistant’. If I want to filter out all the lights from the other location (with out excluding them in the integration)?

I assume it is something like:

| rejectattr ('entity_id', 'in', integration_entities('Remote_Home_Assistant')

But I think i have the ‘Remote_Home_Assistant’ name incorrect?

[CentralCommand (Mike)]

For integration_entities you can provide one of two values:

1. the integration’s slug/identifier. This is usually easiest for integrations configured in yaml. It is either the field you put all of it’s config under in configuration.yaml or the value you put in platform (if it told you to add things under sensor, light, etc.). For UI configured integrations you’d have to look this value up in the code, it’ll be the value in domain in it’s manifest.json
2. the name you picked for the integration in the UI. This generally only applies to UI configured integrations and is definitely easiest for them. Just whatever name you picked for the box tile in the integrations page in settings. Although if a yaml configured one appears there and lets you rename it’s tile it’ll work for that too.

[DefenestrateIT]

@CentralCommand

For integration_entities you can provide one of two values:

Thank you for that.