Low battery level detection & notification for all battery sensors

[Sbyx]

No problem, thanks for the reply. Yes, when manually triggering through the UI, conditions are ignored by default. You can trigger automations manually with conditions in Developer Tools - Services using skip_condition: false.

[KlausDK (Klaus)]

Love it, just had to change to get the battery level also.

{% set result.sensors = result.sensors + [state.name] + [state.state] %}

[Sbyx]

You are actually correct. I wasn’t sure if it was possible to “abuse” the target selector but I managed to find a way. Therefore last version removes the 10 input selectors again and instead adds a target selector for exclusion instead.

If you are updating the blueprint and had excluded sensors before please add them again using the “Pick Entities” button.

[Sbyx]

Great idea, added it to the latest version as well. Thanks!

[CentralCommand (Mike)]

Also, one other small suggestion. The int filter accepts a parameter of a default number. This number is what it returns when asked to convert a non-numeric value to an integer.

So with that you can change this

if 0 < state.state | int < threshold | int

To this

if 0 <= state.state | int(-1) < threshold | int

This way it will only skip alerting you non-numeric sensors with type battery and not for battery sensors with a dead battery

[e-raser]

Great, now even the percentage of sensors is shown in notification message.

I´m wondering in general how to update blueprints or be aware of updates available. Not sure if the HA devs have a roadmap for this.

For this blueprint I just deleted it and imported it again, the automation was still available and referenced the new version of the blueprint.

[Sbyx]

Yeah, that seems to be the way. May need to reload automations as well or at least that’s what I am doing when I change blueprints on disk.

@CentralCommand changed, thanks again!

[trasher (Johan)]

I’ve updated to latest version, and made tests again: all works as expected, thanks!

[epmatt (Matteo Agnoletto)]

Hi @Sbyx,

thank you so much for this really helpful blueprint!

I’m kickstarting a small project which aims to create a curated collection of reliable, documented and high quality blueprints, which could eventually become a valuable resource both for Home Assistant newcomers and experienced users.

I published Awesome HA Blueprints as a website which can be easily browsed, but the codebase, including the list of blueprints, is available in this GitHub repository. The project is still in its early stages but I hope many blueprints will be added in the upcoming weeks and months.

Here’s the original thread:

Awesome HA Blueprints: A curated list of blueprints + easily create controller-based automations (remotes, switches,...) for controlling lights, media players, and more

Update: please read this annoucement post. Hi there! First of all, I’d like to express my appreciation to the community for the effort and energy put into making Home Assistant the absolute best home automation hub out there. I was amazed by the new Blueprints feature which was introduced in the latest release; I think this could be a game-changing feature to help many new users getting started quickly with Home Assistant, but I found the need for a place where the community c…

It would be amazing to have this blueprint in the collection.
If you’ve time and you’re interested in contributing and helping the project, it would be great if you could submit your blueprint by opening a Pull Request there. Also, I could take care of adding it to the list if you’d like to.
Just let me know.

Thank you for your time!

[Sbyx]

Hi @epmatt

thanks for the feedback and your effort. I wouldn’t mind submitting this or my other blueprints to some sort of list of curated blueprints but I am afraid submitting the actual blueprint code and maintaining it in some Git repository is too much overhead besides keeping the code in a Gist and synchronizing it here in the forum manually.

[philsson]

I just wanted to thank you for this automation! I’ve added all sensors manually to a list via AppDaemon so far. It works well but man this is better! Many thanks.

[DrSpaldo (Doctor Spalding)]

I just wanted to jump on and say thanks for the Blueprint. With the updates, is that something we need to manually do when you update it?

[e-raser]

Yes we do, currently. See Low battery level detection & notification for all battery sensors. I´m sure the dev team will provide some kind of update notification or even mechanism, currently it´s a manual process. “Never change a running automation” right

[epmatt (Matteo Agnoletto)]

Thank you for your feedback @Sbyx,

there is no intention to provide a substitute to the blueprint exchange category here on Home Assistant forums, which I think it’s really an amazing place to receive feedback and share the progress of blueprint development. But the main benefit of having a GitHub repository is that this approach ensures all blueprints submitted there follow the same code and quality standards, receive proper testing and have extensive documentation. Moreover, it’s easier to track changes and contributions.

The project is still at the beginning so I’m not sure how it will look in the long run. But to make it short, the core idea is to provide users a place where they can easily find good blueprints, without searching in the whole blueprint exchange, which is seeing lots of new threads being opened every day.

Btw if you have any suggestions I’d be really happy to hear your voice. This is probably off topic here, so we can continue the discussion in the original thread.

It would be really nice to receive a PR for this and your other blueprints, all of them would be a great addition to the collection. Also, if you’d like to try to maintain them inside the project’s GitHub repo, it would definitely be a good test to verify whether this approach really brings too much overhead to blueprint development.

Thank you for your time and effort!

[dave_t_uk (Dave)]

Great blueprint, thanks for contributing it. In fact I was working on something similar and you beat me to it.
My small variation on this theme is as follows:

• Don’t make the user type their own notification template “…{{sensors}}…” etc. Instead just ask them to pick a mobile device to notify.
• Always send a persistent notification as well.
• List device count in the message to it more obvious if devices are missing. i.e. “x out of y devices have low battery”
• Format the message a bit more cleanly (one device per line), and show ‘all devices ok’ if they are all ok.
• Default to Saturday morning

https://gist.github.com/davet2001/5c671f5dda1194758e40e3586f9e5198

I couldn’t get the device exclusion to work (not sure why) but I wasn’t using it so I removed that.

Feel free to merge any of these ideas as you see fit!

[HomeAutoFred (FredZ)]

This is a bit of a random question, and apologies up front as this template is on the cusp of my understanding, but could this template be easily adapted for an attribute of “battery_level” instead of “battery”?

[Sbyx]

It actually doesn’t read attributes at all but only dedicated battery sensor entities (states) atm.

[e-raser]

…so you would need to create a new entity out of/based on an existing attribute first. Not very nice but for only a few sensors it might be a workaround. Does not scale obviously.

[Sbyx]

My main problem is I don’t have a device or know about one that works this way so it is hard for me to test.

[Mabaelst (Bart Teuwen)]

Hello,

Thank you! Really works. But one question, I get a message, but this message does not say which sensor is transmitting this message? Am I doing something wrong? Thanks for the response!