Only list batteries from sensor template < 10 % in notification

I use the following to list unavailable devices from a binary sensor in a notification.

Does anyone know how to alter it, so it can be used to only list batteries within a sensor template with a % lower than 10 please?

  message: >-
    {% for sensor in state_attr('sensor.batteries', 'entity_id') |
    select('is_state', 'unavailable')  %}

    {{ state_attr(sensor, 'friendly_name') }}{% endfor %}
  title: Battery below 10%

I can’t figure out what to use instead of select('is_state', 'unavailable')

Thanks a lot!

Copy-paste the following template into the Template Editor and confirm it reports the desired results.

If it works the way you want, use it in the message option.

{% set batteries = state_attr('sensor.batteries', 'entity_id') %}
{% set ns = namespace(weak=[]) %}
{% for b in expand(batteries) if b.state | is_number and b.state | int(0) <= 10 %}
  {% set ns.weak = ns.weak + [] %}
{% endfor %}
{{ ns.weak | sort | join(', ') }}

I created a new sensor template and copied/pasted it.
It doesnt seem to show what I’m hoping for though.

The result is the friendly name of a device with a battery, that I’m pretty sure has a battery level higher than 10%. I only added the device, with fresh batteries, this morning.
I changed the % to 90, which should catch a couple of batteries to list, but the output didnt change.

Am I trying it correctly?
It looks like a pretty different approach, which is checking various additional things. Like that the % is a number? That might good as they’re not always reported…
The current sensor.template is handling that though, showing only the lowest numeric value…

My original message seems pretty close to what I’m hoping for? I just cant get the Select() right to only list <10%

Thanks a lot

What did the template report in the Template Editor?

It wasn’t. You cannot perform an arithmetic comparison using an entity’s state directly because it’s a string (an entity’s state value is always a string even if it is numeric). You have to convert it to a number, using int or float, and that’s not possible the way you were attempting to do it (a chain of filters) while still preserving the entity’s entity_id. A for-loop is needed.

Copy-paste the following template into the Template Editor and report the results.

{% set batteries = state_attr('sensor.batteries', 'entity_id') %}
{% for b in expand(batteries) %}
  {{ b.entity_id }}: {{ b.state }}
{% endfor %}

It originally returned ‘Full sensor battery’, the friendly name of the battery entitity of a leak sensor I have on the top of a fish tank (so it screams at me as its filling up and near the top).
If I change the % to 90, which should catch some other battery entities, it stays at ‘Full Sensor battery’.

The second set of code produces:
sensor.battery_2: 12 sensor.battery: unavailable sensor.pir_conservatory_battery: unavailable sensor.pir_stairs_battery: unavailable

…which looks kinda like the entity IDs I’ve added to sensor.batteries, with 'unavailable’s and a 12 in there too

edit: I lied… thats not the sensor I added this morming. it may well be the one with the lowest battery right now.
if I increase the % though, I only that one listed rather than any below the %

Three of the four entities are unavailable (meaning Home Assistant has lost communication with them and doesn’t know their current value) so there’s no way any template can tell you their battery level until you fix the cause of the problem.

One of the four entities is 12. The original template I posted above won’t report that one because it is above the threshold value of 10. If you increase the threshold value then the template will report it. When you increased the threshold to < 90 then that was the only sensor that met the criteria because the other three are unavailable.

Your topic’s title asks to list the batteries that are < 10% in a notification. The template I provided can do that. However, three of your four battery sensors are offline and the fourth is still above the 10% threshold.

ah… then this approach might not work at all then?
They’re battery powered PIR and leak sensors, that show as unavailable the majority of the time. They only report a battery level periodically, and I think when theyre going off

The sensor template and then automation should pick them up as theyre reported though, so it might still be OK. Maybe its only as I’m testing it now that this is a problem?
Do you know any way to do this but as more of a ‘when last reported’ than as its run?

How I wish that important detail was mentioned in the first post.

I suggest you use an automation that detects when the state of any of the four sensors changes from unavailable to a numeric value then checks if the value is below the threshold. If it is, then it notifies you immediately.

Yes but it’s overkill because it’s designed to report when multiple entities have a low battery level. In this case, the devices you have are normally sleeping, wake up periodically but unlikely all at the exact same time, and their reported state is momentary and reverts back to unavailable when it goes to sleep again.

Sorry, I didn’t realise it was so relevant.
I don’t mind if it’s triggered from a min level as I currently have the automation set, or if the automation’s checking each directly.

If I skip the and just add them as triggers, would trigger.to_state.attributes.friendly_name be the right way to include the triggering entities friendly name in the notification?

Thanks again for your help (and I’m sure I’ll end up using this somewhere else somehow, so it’s not a waste)

It can still do the job you wanted just not the way you intended to use it in message. Use it in a Template Sensor, or Trigger-based Template Sensor, then refer to that sensor’s value in message.

Get it set and then checked by manualy setting one of the unavailable ones to <10. Working
Thanks again

1 Like

You’re welcome!

Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.

For more information about the Solution tag, refer to guideline 21 in the FAQ.