core: Template error in Template Editor while it works fine as custom template sensor

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

Still hoping to hear of a code update in the works to bring the template editor in line with the back end implementation of the templating language. (or vice-versa)

It would be really useful to know that what we ‘design’ in the template editor was going to function identically in a YAML template.

I thought that was its purpose

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.

It apparently is a waste of time to report this issue, as it is still present in Home Assistant 2023.6.1 Supervisor 2023.06.2 Operating System 10.2 Frontend 20230608.0 - latest

The work arounds are probably obvious to those already familiar with jinja, but for a beginner -trying to get to know the massive area of templating- this template tool is very much needed to work correctly and as easily as possible.

This is sloppy at best, poorly managed at worst-- but why should users have to fix what is clearly a bug or poor design choice by the author of the template module in Developer tools? Does HA have an arbitor who can make this simple judgement? Or is this truly just a wild west of anybody can do anything they want and have it included in Home Assistant? Are reporting bugs in Github a waste of time (as it appears to be)?

Still an issue with current version.

The “Sensors” code in this blueprint works, but not in the template editor.

100% agree with @starman2k01, what works (or fails) in one, should work (or fail) in the other.

Still an issue in 2022.11.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. 🤷

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.

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 [].

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.

Looks like neither developer accepts this as their problem, it’s the other guys fault. It seems obvious the template editor by definition should match the behavior of actual templates. So can you please fix this???

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 }}