Low battery level detection & notification for all battery sensors

I’m not presently aware of an easy way to get notifications of updates to the source blueprint once they’re imported.

First time using blueprints as Im setup for yaml still. When I enter the message line it turns the whole thing in to raw edit and then I cant save it. Gives me a 500 error. Trying to send a notification to discord.

'Low battery warning for: {{sensors}}'

I suggest that you remove the {{sensors}} dynamic and get a message working first. Once you have that then you can modify the sent message to include {{sensors}}

I had to take the raw code and paste it in my yaml. Doesn’t seem like blueprints work with the old method of editing configs.

Just installed this on the latest version 2021.4.3 and everything worked flawlessly, included creating automation from blueprint and manually running actions.

Also, to contribute:
I personally use the ring-mqtt integration and the battery entities do NOT use the battery class. Which means in my case, a lot of the devices would not be checked. But these entities have an attribute called “batteryLevel”, here is a full set for one, so people can understand.

batteryLevel: 100
batteryStatus: full
commStatus: ok
firmwareStatus: up-to-date
lastCommTime: 2021-04-10T20:29:39Z
lastUpdate: 2021-04-10T20:29:39Z
linkQuality: ok
serialNumber: BHDE21932EL000252
tamperStatus: ok
unit_of_measurement: %
friendly_name: Back Door Contact Sensor Battery
icon: mdi:battery

So I have ended up using the attribute to include those devices too, Sbyx feel free to include it in the original blueprint, or as optional code in your first post, should you see value.

This is the code to copy straight into the automation file, replacing what is already there for sensors:

  sensors: "{% set result = namespace(sensors=[]) %} {% for state in states.sensor\
    \ | selectattr('attributes.device_class', '==', 'battery') %}\n  {% if 0 <= state.state\
    \ | int(-1) < threshold | int and not state.entity_id in exclude.entity_id %}\n\
    \    {% set result.sensors = result.sensors + [state.name ~ ' (' ~ state.state\
    \ ~ ' %)'] %}\n  {% endif %}\n{% endfor %} {% for state in states.sensor\
    \ | selectattr('attributes.batteryLevel', 'defined') %}\n  {% if 0 <= state.state\
    \ | int(-1) < threshold | int and not state.entity_id in exclude.entity_id %}\n\
    \    {% set result.sensors = result.sensors + [state.name ~ ' (' ~ state.state\
    \ ~ ' %)'] %}\n  {% endif %}\n{% endfor %} {% for state in states.binary_sensor\
    \ | selectattr('attributes.device_class', '==', 'battery') | selectattr('state',\
    \ '==', 'on') %}\n  {% if not state.entity_id in exclude.entity_id %}\n    {%\
    \ set result.sensors = result.sensors + [state.name] %}\n  {% endif %}\n{% endfor\
    \ %} {{result.sensors|join(', ')}}"

Here is the clean version of only what was added:

    {% for state in states.sensor | selectattr('attributes.batteryLevel', 'defined') %}
      {% if 0 <= state.state | int(-1) < threshold | int and not state.entity_id in exclude.entity_id %}
        {% set result.sensors = result.sensors + [state.name ~ ' (' ~ state.state ~ ' %)'] %}
      {% endif %}
    {% endfor %}

I appreciate this will iterate through states.sensor twice, but I am not familiar with Jinja and I am not sure if you could select multiple attributes in one go.

Hope this helps others too!

LE: fixed selectattr comparison.

3 Likes

@robertalexa Thanks for that. I had the same issue and was trying to modify the code to adjust it for Ring devices. @Sbyx Is this something that can be included in the blueprint? Or optionally a text field to select what attributes to check on with the default being what’s in it currently?

1 Like

you are welcome :slight_smile: glad it helped somebody else too.

as to my original post, you can’t select multiple attr in one single loop, so it has to be this way.

Rob

Thanks for writing and posting this. It saved me a lot of time! I like the new addition that you mention of being able to exclude devices.

@tykeal Just a heads-up, since updating to 2021.5.0 I’m getting a log error with your blueprint now:

Logger: homeassistant.components.automation
Source: components/automation/__init__.py:628
Integration: Automation ([documentation](https://www.home-assistant.io/integrations/automation), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+automation%22))
First occurred: 7:53:25 PM (1 occurrences)
Last logged: 7:53:25 PM

Blueprint Low battery level detection & notification for all battery sensors generated invalid automation with inputs OrderedDict([('time', '10:00:00'), ('actions', [OrderedDict([('service', 'persistent_notification.create'), ('data', 'Low battery warning for: {{sensors}}')]), OrderedDict([('service', 'notify.notify'), ('data', OrderedDict([('message', 'Low battery warning for: {{sensors}}'), ('title', 'Low battery')]))])])]): expected dict for dictionary value @ data['action'][0]['default'][0]['data']. Got None 

@DarrenHill did you hit the test button? That’s the only time I’ve gotten that error.

In fact, I got a notification this morning during my standard scheduled run, and I upgraded to 2021.5.0 yesterday.

Where’s the test button? Happy to give it some testing, but that log error appears at reboot.

Also under integrations it shows as “failed to set up”

Ah… by test button I was meaning the ‘Run Actions’ button in the configuration UI.

I didn’t look at my logs after the restart. But it came up cleanly for me :-/

Having just taken a look, I just see the expected “You’re using a custom integration…” message for each of my HACS integrations

Let me try removing it and reinstalling and see.

OK reinstall didn’t help, but if I try a run actions on the automation then I get the appropriate response (notifications in my case). I’ve set up a test to run at half-past to see if it works correctly under proper conditions.

@tykeal OK the automation seems to be working OK, so I guess we can maybe ignore the log error? No idea why it’s triggering…

I don’t know what’s causing the log error. I don’t get it myself, but maybe I’ve got enough things taking long enough before automations get initialized that all the needed bits are properly loaded when the automation finally initializes.

OK. Was just having a log review and general sort-out after the recent update as I had a few things break on me, so wanted to let you know anyway.

The automation itself is still working fine, which is the main thing anyway.

Thank you @Sbyx for this blueprint. Works like a charm on latest Home Assistant!

@Sbyx just wanted to say thank you for the blueprint. I only had to add the {{sensors}} in the yaml code, and then it all worked. Had been looking for such an automation for some time. Great job!

@Sbyx thanks for the Blueprint, works like a charm!