I was looking to do something similar to this… After using this post for inspiration, I’ve ended up with a generic solution using device_class=battery, so there was no need to hardcode group/entity names.
This template outputs a comma delimited list of entity names where battery level is under 30%:
{% set separator = joiner(", ") %}
{% for battery in (states | selectattr('attributes.device_class', 'eq', 'battery')) if battery.state | int < 30 %}
{{- separator() + battery.entity_id -}}
{% endfor %}
I don’t have enough devices to test this properly (and the ones I do have, have fully-charged batteries). Can you do me a favor and try this out on your system and let me know if it produces correct results?
It performs a string comparison of the battery-level (which explains why it rejects 100 because in a string comparison, 100 is not less than 30). It assumes all battery-level values are strings. If there’s even one that is int or float, this template will fail.
NOTE
This is just an exercise to see if useful results can be produced without employing a for-loop.
It looks like your code works. I like it because it doesn’t require me to update all the groups that have batteries. This is what I get with your code snippet:
Just be aware that’s there’s a subtle difference in how often this template will be updated compared to the other version.
In 0.117, a template containing states, and no other identifiable entities, will be evaluated every minute. That’s more than adequate to report a low battery but arguably much more than needed given that batteries last months.
In contrast, a template that expands a group (and contains no reference to states or states.DOMAIN) will be evaluated only when one of the group’s entities changes state. In other words, the template is updated only when something changes (which is more efficient than polling according to a fixed time interval).
You should know that it’s possible (and fairly easy) to create an automation that is triggered at startup and dynamically creates a group containing the entities you desire (like all entities whose device_class is battery). This eliminates the overhead of manually maintaining the group’s membership. The template can then refer to the dynamically-created group.
I spent ages trying to do this without a generator/for loop, as I wanted to have the sensor as “on/off” and have an array/list attribute with the names of the sensors.
As you say, select/rejectattr treats the state as a string, and there doesn’t appear to be any test in jinja/HA templating that will do the lt/gt and cast the state to an integer. I think this would need either custom tests in HA or a custom filter that allows us to treat attributes as numbers instead of strings
I don’t think that 2nd one does work properly as you get different results. The states are being compared as strings instead of numbers so it’s not returning a correct list.
As mentioned, the template I suggested provides different results due to the string comparison.
What is the battery_level of one of the entities that it fails to include? For example, deck_temp_sensor_battery and phone_battery_jeremy? I’m curious to know what failed the string comparison. For example, ‘8’ fails to be less than ‘30’ in a string comparison.
deck_temp_sensor_battery is ‘unavailable’ (I have issues with that sensor)
phone_battery_jeremy is ‘unknown’ (I am going through a re-install currently, so that is probably messed up at the moment)
Anyway, just curious; a string comparison is simply unreliable for this application.
It’s possible to use map('int') to convert values but you can only pass it values, not objects, so you lose all other information about the entity like it’s entity_id.
I’m hoping Petro can enhance the templating engine so that we can be more selective in how a filter is applied.
I know this is a long dead thread, but I’m just wondering if anything ever came of this. I’m running into the same issue now, but am not seeing any mentions of new solutions.
Sorry, thought the thread would provide enough context.
I’m wondering if there are any new ways to cast values in something like selectattr() before the comparison is done, as you’ve mentioned you were looking into above. More specifically, I want to do something like the following template, but ensure that the comparison is treating all values as ints, not strings: