Template error in Template Editor while it works fine as custom template sensor #71360

smarthomejunkie · 2022-05-05T17:35:21Z

The problem

I hope this is the right place to report this.

I use this code in a template sensor which works fine in that template sensor. However, when I use this code in the Developer Tools->Template Editor I get an error.

The code is:
{% set sensors = states.sensor
| selectattr('attributes.device_class', '==', 'battery')
| selectattr('attributes.state_class', '==', 'measurement')
| rejectattr('state', 'in', ['unavailable', 'unknown'])
| list %}

The error is:
UndefinedError: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'device_class'

What version of Home Assistant Core has the issue?

Core 2022.5.0

What was the last working version of Home Assistant Core?

core-2022.4.6

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

{% set sensors = states.sensor 
  | selectattr('attributes.device_class', '==', 'battery') 
  | selectattr('attributes.state_class', '==', 'measurement') 
  | rejectattr('state', 'in', ['unavailable', 'unknown'])
  | list %}

Anything in the logs that might be useful for us?

No response

Additional information

No response

elkarto · 2022-05-12T15:51:43Z

Same problem here:

{{ states.media_player | selectattr('attributes.last_called', 'eq', True) | map(attribute='entity_id') | first }}

Template sensor working fine, returning the entity_id of last called alexa media player.

Developer tools return the error:

UndefinedError: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'last_called'

sotima · 2022-05-13T04:48:32Z

Also not working in mushroom template card anymore. I know, thats not HA/core! Just for info!

nkkanzlei · 2022-05-13T14:00:01Z

Also not working ...
{{ states.binary_sensor | selectattr('state', 'eq', 'on') | selectattr('attributes.device_class', 'eq', 'door') | list | count }}

Hamudulu · 2022-05-13T16:27:21Z

Same Problem here...

Version | core-2022.5.4
Home Assistant Supervised

StormyKnight17 · 2022-05-14T11:55:31Z

Same Issue with my RFS Fire Listings in Template & custom:mushroom-template-card

ADVICE
{% set x = states
| selectattr('attributes.type','search','Fire')
| selectattr('attributes.category','eq','Advice')
| list -%}
{%- set ns = namespace(result=[]) -%}
{%- for s in x -%}
{%- set ns.result = ns.result + [ s.state+'km',s.attributes.status,s.attributes.friendly_name+'\n' ] -%}
{%- endfor -%}
{{ ns.result |list | join(' - ') }}

UndefinedError: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'type'

Hooolm · 2022-05-19T09:35:23Z

Same issue here

Home Assistant Core 2022.5.5
Home Assistant Supervisor 2022.05.2
Home Assistant OS 8.0

smarthomejunkie · 2022-05-19T09:38:44Z

This can be solved by first checking if the attributes are defined for the entity.

For instance:

{% set sensors = states.sensor 
  | selectattr('attributes.device_class', 'defined') 
  | selectattr('attributes.state_class', 'defined') 
  | selectattr('attributes.device_class', '==', 'battery') 
  | selectattr('attributes.state_class', '==', 'measurement') 
  | rejectattr('state', 'in', ['unavailable', 'unknown'])
  | list %}

Now you won't get this error anymore

elkarto · 2022-05-19T14:23:37Z

This can be solved by first checking if the attributes are defined for the entity.

For instance:

{% set sensors = states.sensor 
  | selectattr('attributes.device_class', 'defined') 
  | selectattr('attributes.state_class', 'defined') 
  | selectattr('attributes.device_class', '==', 'battery') 
  | selectattr('attributes.state_class', '==', 'measurement') 
  | rejectattr('state', 'in', ['unavailable', 'unknown'])
  | list %}

Now you won't get this error anymore

Well, it seems much better to do that, and it works!!

However, the behaviour in the template editor and in the custom template sensor should be the same.

StormyKnight17 · 2022-05-20T00:16:47Z

I had to remove state_class defined & state_class measurement to show my iphone battery, but other than that it now works for me.

{% set result = namespace(sensors=[]) %}
{% for state in states.sensor '
 | selectattr('attributes.device_class', 'defined') 
 | selectattr('attributes.device_class', '==', 'battery')
 | rejectattr('state', 'in', ['unavailable', 'unknown'])
%}
{% set result.sensors = result.sensors + [state.name ~ ' (' ~ state.state ~ '%)'] %}
{% endfor %}
BATTERIES
{{result.sensors|join('\n')}}

BATTERIES
iPhone Battery Level (100%)
Sensor03 Battery Level (58%)

jokerigno · 2022-06-05T10:37:23Z

Same issue here running 2022.6

StormyKnight17 · 2022-06-05T10:51:27Z

The issue it seems is that you need to check if the attribute actually “is defined” before you try & test it’s value.

smarthomejunkie · 2022-06-05T10:53:16Z

The issue it seems is that you need to check if the attribute actually “is defined” before you try & test it’s value.

That is correct. See my code above.

frenck · 2022-06-07T10:04:41Z

I don't see the bug in this issue report? The given template is iterating over all entities and tries to access the device_class on state objects that don't have a device_class attribute. 🤷

elkarto · 2022-06-07T10:23:45Z

I don't see the bug in this issue report? The given template is iterating over all entities and tries to access the device_class on state objects that don't have a device_class attribute. 🤷

We agree that the behaviour may be correct.

The issue, in my opinion, is that the template editor has a different behaviour than the template sensors.

Same problem here:

{{ states.media_player | selectattr('attributes.last_called', 'eq', True) | map(attribute='entity_id') | first }}

Template sensor working fine, returning the entity_id of last called alexa media player.

Developer tools return the error:

UndefinedError: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'last_called'

If one of the entities doesn't have the specified attribute, the sensor will works fine (ignoring that entity and filtering the others), but the template editor will fail to render.

In previous versions, both rendered without errors. Anyway, it is good to check if the attribute exists before using it for filtering.

probot-home-assistant · 2022-06-07T10:28:34Z

template documentation
template source
_{^{(message by IssueLinks)}}

probot-home-assistant · 2022-06-07T10:28:37Z

Hey there @PhracturedBlue, @tetienne, @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (template) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

github-actions · 2022-09-05T11:05:59Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

parautenbach · 2022-09-05T12:43:59Z

This is still an issue on 2022.8.2.

bcutter · 2022-09-26T16:23:01Z

Why does this frontend error in the dev-tools templating section even exist?

Every time trying to access attributes.* this error is shown and template rendering fails. While template sensors instead are working fine.

Instead of forcing everyone over the world to add a pre-check if e. g. device_class is defined, why not just fix this by removing this unnecessary warning from the frontend?
Or are there plans all templates (template sensors) will fail in future so the pre-check will become mandatory?

Came here because of

{{ states.binary_sensor | selectattr('attributes.device_class','eq','vibration') | selectattr('state','eq','on') | list | length }}

erd82 · 2022-10-04T20:43:31Z

Still an issue in 2022.9.7

DanielSCBO · 2022-10-11T13:14:03Z

Still an issue in 2022.10.3

prnzngr · 2022-11-04T10:40:22Z

Still an issue in 2022.11.1

Soleil01 · 2022-11-05T19:13:43Z

In my case, it gives a fatal error…

Jelmerrevers · 2022-12-24T23:19:38Z

Still an issue in version 2022.12.8

starman2k01 · 2023-01-07T17:03:51Z

Why has this not been fixed? Developer tools is useless to test loops with "selectattr"!
UndefinedError: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'device_class'
In fact it doesn't work with ANY and ALL attributes, not just 'device_class'

pavolholes · 2023-01-08T15:17:22Z

Still an issue in version 2023.1.1.

bcutter · 2023-10-22T11:01:01Z

Still exists. No one (able to fix) cares. New features more important. What a pity.

issue-triage-workflows · 2024-01-20T11:18:44Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

bcutter · 2024-01-20T11:55:15Z

Not stale

teskanoo · 2024-01-22T16:20:17Z

Rather than just triage this ticket every month or so, is there a possibility that we could get some feedback from the developers please? I'm quite happy to keep bumping this every time it goes into the closed down phase, but it would be nice to know if anything can be be done to resolve this issue.

starman2k01 · 2024-01-22T16:27:16Z

The answer we keep getting is finger-pointing. Both think each other is wrong. So it remains broken.

starman2k01 · 2024-01-22T16:27:42Z

Seems like Frenck should step in and resolve this!

bcutter · 2024-01-22T17:48:06Z

Definitely Frenck is some kind of (well-known) HA super guru and I understand many are asking for him sooner or later - but his day probably has 24 hours only, too.

There are many other skilled experts around too. I just don't get why this issue did not get any traction so far - because the impact on a productive use on a daily basis is not that massive maybe?

pedolsky · 2024-01-22T18:01:32Z

I've tested some examples in Developer Tools without any issues.
(HA Supervised 2024.1.5)

parautenbach · 2024-01-22T18:17:08Z

I think there's some conflation of issues.

What should happen if an attribute (or property) that doesn't exist is accessed via the select(attr) or reject(attr) filters?
Is the template editor consistent with other template definitions/implementations?

Regarding (1):

I don't see the bug in this issue report? The given template is iterating over all entities and tries to access the device_class on state objects that don't have a device_class attribute. 🤷

@frenck gave the answer above and I believe it resolves that point.

@smarthomejunkie's later response confirmed it, as did some other posts after that.

Basically, you need to check if it's defined before accessing it:

| selectattr('foo', 'defined')

Mind this though, to highlight the 2nd issue:

We agree that the behaviour may be correct.

The issue, in my opinion, is that the template editor has a different behaviour than the template sensors.

At this point I need to clarify my own comment: The use of templates should be consistent everywhere.

Perhaps what's needed is for the original post to be updated, or a new one should be logged specifically for the second issue. I'm not sure what the core team's preference would be.

I just want to clarify that I haven't tested this recently, so I'm not stating for a fact (2) is still an issue: I'm saying, if it is, then this issue should be cleaned up or a new one logged with the necessary info.

Perhaps to ask directly: @pedolsky when you say you've tested with 2024.1.5, are you referring to (2)?

starman2k01 · 2024-01-22T18:30:26Z

The issue isn't that there is no workaround. The workaround has been discussed for a while.
Yes the issue is that template use/testing should be consistent everywhere.
Templates are hard enough without this frustrating lack of consistency.
So we need a HA guru to say "suck it up, it's never going to be fixed" or "this side needs to fix the issue".

parautenbach · 2024-01-22T18:36:19Z

It's not a workaround. It's the equivalent of a null pointer in programming: you're dereferencing something that doesn't exist. I quoted Frenck and his answer is pretty clear. What more do you want?

starman2k01 · 2024-01-22T18:40:57Z

You are stating the obvious. Try understanding why so many people are saying this isn't fixed.
I'll say it again, as you already said it:
"The use of templates should be consistent everywhere."
Use of templates is NOT consistent everywhere. Leading to obvious confusion when creating a template that sometimes works, sometimes doesn't, and developer tools is NOT consistent with HA execution.
Clear??
Either agree with your own statement or pull it back.

pedolsky · 2024-01-22T19:36:35Z

I refer to (2); that was (is?) an absolutely annoying behaviour in Developer Tools. Tested it again with


{{ states.sensor 
  | selectattr('attributes.device_class', '==', 'xxxxxxx') 
  | list | count }}

which return 0 and with


{{ states.media_player | selectattr('attributes.last_xx', 'eq', True)
| map(attribute='entity_id') | list }}

which returns [].

bcutter · 2024-02-07T19:39:19Z

This is soooooooooo annoying, creating confusion everywhere and making the dev-tools section useless for many templates as you simply can not trust it ❗

https://community.home-assistant.io/t/template-to-filter-certain-update-entities-ignoring-once-with-not-met-requirements/686360

issue-triage-workflows · 2024-05-07T20:05:47Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

bcutter · 2024-05-07T20:41:07Z

Ping

teskanoo · 2024-05-19T02:21:50Z

Pretty sure macros return objects and lists in the developer tools but strings in run-time usages.

Very confusing for people who do not understand that the template editor in dev tools is a cousin, not a clone of the behaviour they will experience after they move their Jinja into a real-world situation.

I spend considerable time helping people navigate the inconsistencies.

issue-triage-workflows · 2024-08-17T03:05:44Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

issue-triage-workflows · 2024-11-15T14:06:47Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

bcutter · 2024-11-15T16:40:24Z

What was the reason again this obviously technically can't be fixed? 66 comments and no idea why it's still open.

frenck added the integration: template label Jun 7, 2022

github-actions bot added the stale label Sep 5, 2022

github-actions bot removed the stale label Sep 5, 2022

starman2k01 mentioned this issue Jan 8, 2023

Selectattr completely broken in Developer Tools Template Editor #85391

Closed

issue-triage-workflows bot removed the stale label Oct 22, 2023

issue-triage-workflows bot added the stale label Jan 20, 2024

issue-triage-workflows bot removed the stale label Jan 20, 2024

issue-triage-workflows bot added the stale label May 7, 2024

issue-triage-workflows bot removed the stale label May 7, 2024

litinoveweedle mentioned this issue Jun 19, 2024

restful sensor availability template is not evaluated #119992

Open

issue-triage-workflows bot added stale and removed stale labels Aug 17, 2024

issue-triage-workflows bot added the stale label Nov 15, 2024

issue-triage-workflows bot removed the stale label Nov 15, 2024

Template error in Template Editor while it works fine as custom template sensor #71360

Template error in Template Editor while it works fine as custom template sensor #71360

Comments

smarthomejunkie commented May 5, 2022 • edited Loading

The problem

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Integration causing the issue

Link to integration documentation on our website

Diagnostics information

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

elkarto commented May 12, 2022

sotima commented May 13, 2022

nkkanzlei commented May 13, 2022

Hamudulu commented May 13, 2022

StormyKnight17 commented May 14, 2022

Hooolm commented May 19, 2022

smarthomejunkie commented May 19, 2022 • edited Loading

elkarto commented May 19, 2022

StormyKnight17 commented May 20, 2022 • edited Loading

jokerigno commented Jun 5, 2022

StormyKnight17 commented Jun 5, 2022

smarthomejunkie commented Jun 5, 2022

frenck commented Jun 7, 2022

elkarto commented Jun 7, 2022 • edited Loading

probot-home-assistant bot commented Jun 7, 2022

probot-home-assistant bot commented Jun 7, 2022

github-actions bot commented Sep 5, 2022

parautenbach commented Sep 5, 2022

bcutter commented Sep 26, 2022 • edited Loading

erd82 commented Oct 4, 2022

DanielSCBO commented Oct 11, 2022

prnzngr commented Nov 4, 2022

Soleil01 commented Nov 5, 2022

Jelmerrevers commented Dec 24, 2022

starman2k01 commented Jan 7, 2023

pavolholes commented Jan 8, 2023

bcutter commented Oct 22, 2023

issue-triage-workflows bot commented Jan 20, 2024

bcutter commented Jan 20, 2024

teskanoo commented Jan 22, 2024

starman2k01 commented Jan 22, 2024

starman2k01 commented Jan 22, 2024

bcutter commented Jan 22, 2024

pedolsky commented Jan 22, 2024

parautenbach commented Jan 22, 2024 • edited Loading

starman2k01 commented Jan 22, 2024

parautenbach commented Jan 22, 2024 • edited Loading

starman2k01 commented Jan 22, 2024

pedolsky commented Jan 22, 2024

bcutter commented Feb 7, 2024

issue-triage-workflows bot commented May 7, 2024

bcutter commented May 7, 2024

teskanoo commented May 19, 2024

issue-triage-workflows bot commented Aug 17, 2024

issue-triage-workflows bot commented Nov 15, 2024

bcutter commented Nov 15, 2024

smarthomejunkie commented May 5, 2022 •

edited

Loading

smarthomejunkie commented May 19, 2022 •

edited

Loading

StormyKnight17 commented May 20, 2022 •

edited

Loading

elkarto commented Jun 7, 2022 •

edited

Loading

bcutter commented Sep 26, 2022 •

edited

Loading

parautenbach commented Jan 22, 2024 •

edited

Loading

parautenbach commented Jan 22, 2024 •

edited

Loading