Invalid config for [cover.template]: [attribute_templates] is an invalid option for [cover.template]. Check: cover.template->covers->rolluik_studenten_template->attribute_templates. (See ?, line ?).
Combined with the new this variable, an attribute, in below use case for id, would allow us to completely copy a full entity config, and fill out the essential id automatically, using a yaml anchor.
Compare the strength of that in a template sensor like:
This example actually has a bug, it’s going to be wrong at restart of HA and then correct itself next update. The problem is this piece in every template:
I get why you put that. If you don’t you get errors at startup because the state template is evaluated before the attributes ones. But by putting it you’re actually hiding a different error. dark_sky_forecast_1 and dark_sky_forecast_2 are going to set their state identical to dark_sky_forecast_0 at startup because id is going to default to 0.
I believe a better way to do this is to use customization to add that attribute to those entities. That way after a startup the value of the id attribute is already there before the state template runs. And there’s no need to add the problematic default value, you can just do this.attributes.get('id').
The other benefit is customization works fine with all types of entities, covers too. So whenever this support is added to template covers you can use the YAML anchor approach there too without needing support for attribute templates.
hehe, I knew I should have provided another example… its just I had posted it to Erik, and I wanted to sync those 2 action of mine
maybe I should have used:
- unique_id: marijn_abroad
attributes:
id: marijn
<<: &id_abroad
name: >
{% set id = this.attributes.id|default('Not yet set') %}
{{id|title}} abroad
state: >
{% set id = this.attributes.id|default('Not yet set') %}
{{not is_state_attr('sensor.' ~ id ~ '_app_geocoded_location','ISO Country Code','NL')}}
picture: >
{% set id = this.attributes.id|default('Not yet set') %}
{% set cc = state_attr('sensor.' ~ id ~ '_app_geocoded_location','ISO Country Code')|lower %}
{% set path = '/local/flags/' %}
{% set ext = '.png' %}
{% if cc is not none %}
{% set flag = cc %}
{% else %} {% set flag = 'nl' %}
{% endif %}
{{[path,flag,ext]|join('')}}
- unique_id: wijke_abroad
attributes:
id: wijke
<<: *id_abroad
as an example, which uses a more logical string in the default.
Main point was the use of an attribute id, so we can copy&paste the full config, and have the id filled automatically.
Customization is a great thing yes, I use it a lot. Reason I didnt use it here, is I have been trying to cut down on those, and moving as much as possible into the core config options.
This might be the spot where not tom and keep customization. thanks for the suggestion!
Still, allowing custom attributes would be streamlining things… making core code more consistent.
So hope you’ll allow the FR to stand for a bit more?
Cheers!
in the customize: section requires a restart. Normally, customizations, even my templates and colors via custom-ui, are loaded via ‘reload customizations’, but not now.
So my experience is that when you reload customizations in the UI then you see those customizations next time the state is updated for that entity. But until then it continues to display without them. The doc actually notes that in the warning at the bottom.
I’m not going to close it, it’s still a valid request. Although I will say that with all the work done to remove/eliminate attributes across core I’m a bit skeptical this one will be taken up. Not just all the recent performance work either it seems like there’s been a concerted effort to reduce or eliminate attributes for years now and instead make more sensors. You can see that not just in core but also even in HACS integrations and addons at this point as they refactor them out over time.
But others may disagree. Other template entities have them so I’m sure covers could too.
Logger: homeassistant.helpers.template
Source: helpers/template.py:1914
First occurred: July 6, 2022, 23:59:46 (18 occurrences)
Last logged: July 6, 2022, 23:59:47
Template variable warning: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'id' when rendering '{% set id = this.attributes.id %} /local/family/{{id}}_home.png'
returns, even though the attribute is already fixed and set to the template…