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.
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.
Hmm might be a bug in the integration I was helping a guy with earlier.
Sorry crashed out last night. It was 1am where i am, & i have things to do today.
@petro
Will do, I will be doing that over the next few days.
Hmm ok.
Yes. Sweet thanks for that.
This is exactly the type of feed back i want.
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.
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.
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.
1 Like
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.
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.
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?
For integration_entities you can provide one of two values:
- 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.yamlor the value you put inplatform(if it told you to add things undersensor,light, etc.). For UI configured integrations you’d have to look this value up in the code, it’ll be the value indomainin it’smanifest.json - 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.
Thank you for that.
I just read the community guide again & notice that it is bad edicate to ask a question, find the answer; then delete the question. Sorry my bad.
Edited Question: “can you hardcode return carriages?”
Answer: Force newlines or linebreaks in a template?
How do you reject a light from a group of entities that the device_class is not 'light"? E.g.
{{expand ( area_entities ( 'office' ))| selectattr ( 'domain' , 'eq' , 'light' ) | map ( attribute = 'entity_id' ) |list}}
Would list all lights in the ‘office’ but it also includes the lights on other device_class’s E.g. the light on the z-wave Smart Power-Switch?
Answer: https://community.home-assistant.io/t/how-do-you-reject-a-light-from-a-group-of-entities-that-the-device-is-not-a-light/483426?u=defenestrateit
How do you get A lights state (On/Off/unavailable) from the device_id?
Answer: https://community.home-assistant.io/t/wth-how-do-you-reference-a-devices-state-on-off-unavailable-for-a-target-selector/484428?u=defenestrateit
As someone who has taught myself how to use HA over the last 5 years or so I really appreciate this fresh approach and can see great value in this form of instruction.
Frankly, I think you are missing the point of the OP. This post gives a massive sandbox to play in all focused on one domain. There are so many positive aspects to this approach. It would not be appropriate for the technical writing in the docs. Those docs need a set structure to be comprehensible in the larger context of HA.
Also, (at least for English speakers) this is a fun, light-hearted, approachable exercise. It’s something I wish I had when I was learning from the official docs. It would have helped me get the concepts a lot quicker. The massive amount of extra white space wouldn’t be practical for an efficient coder, but that’s not the target audience here. For beginners that kind of excess CAN be helpful.
This is clearly not your cup of tea, but don’t toss it out. Some beginners may find this inspiring. I know I have.
I have a 6-year-old daughter, and I am trying to find ways to make home automation interesting to her. Even though I won’t be using this for her directly, it does give me some ideas on how I might make it fun for her.
4 Likes
You’re right, it’s not my ‘cup of tea’, for reasons I stated 4 months ago. However, it was changed to a Community Guide with the ability for anyone to modify it. Seeing that you like the format, and have been a community member since 2017, feel free to contribute to the first post.
This is great and I really appreciate you posting it. One question… the results of the template but the symbols [ ] around the outside of the entire list and the symbols ’ ’ around each light in the list. Is there a way to eliminate these symbols?
1 Like
This is fantastic - I have been able to get a better idea here of how to achieve my goals, than I can get from the official documentation.
{% set x = area_entities(room_target) %} {{
expand(states.light)|selectattr('entity_id','in',
x)|selectattr('state','==','on')|selectattr('attributes','contains','brightness')|map(attribute='entity_id')|list
}}
This lets me select all lights that are on, in an area, that support the brightness command
and
{% set x = area_entities(room_target) %} {{
expand(states.light)|selectattr('entity_id','in',
x)|selectattr('state','==','on')|selectattr('attributes.supported_color_modes','contains','color_temp')|selectattr('attributes.color_mode','eq','color_temp')|map(attribute='entity_id')|list
}}
This lets me select all lights that are on, in an area, that support the color_temp mode AND are currently set to color_temp (I don’t want to adjust the lights that have been set to an RGB color)
Note I am assuming that {% set x = area_entities(room_target) %} is a more resource friendly way of doing things, because it is called once, whereas I assume that it would be called for every light selectattr tests if I used it in the selectattr call?
I’m definitely not an expert on the subject, but I would assume it would require less resources if you reduce the pool of entity IDs who’s state objects you have to expand then filter though… using states.light starts with a pool that includes every light entity.
{% set x = area_entities(room_target) %}
{{ expand( x | select('match', 'light.')) | selectattr('state', 'eq', 'on')
| selectattr('attributes.supported_color_modes','contains','color_temp')
| selectattr('attributes.color_mode','eq','color_temp')
| map(attribute='entity_id') | list }}
1 Like
Which is kind of the point the OP was making - if there are ways to do these things, you are unlikely to find them on the official documentation page.
There are only 2 ways I know of to reduce the pool - one would be to provide a hardcoded list of lights, and the other would be to add those lights to a group, and then expand just the group.
Neither are set and forget solutions though, both require intervention when you add or change a light in a room. All I have to do with this code though, is ensure I add the light to the correct area when I add it to Home Assistant.
Your solution appears to function here. Thank you for that.
You can create an automation that employs a template that contains states.light to automatically generate your group on HA startup using group.set.
e.g.
alias: blah
trigger:
- platform: homeassistant
event: start
action:
- service: group.set
data:
object_id: my_auto_group
entities: >
{{ states.light | ... }}
then in your other templates…
{{ expand('group.my_auto_group') | ... }}
2 Likes
Is “Set and Forget” a realistic goal… there’s going to be either config or template maintenance when adding new devices. Among the thousands of integrations and devices supported by HA, there are many that expose light entities like indicator lights, screens, etc that users might not want treated the same as their room lighting. In the end it boils down to whether you prefer to opt-in or opt-out new devices.
It’s a goal for me…
2 Likes
Maybe “goal” wasn’t the right word for what I was trying to say; “expectation” might be more accurate.
It would nullify my argument if lights had device classes so there was a more uniform way to reject indicators, screens, etc.
2 Likes