It seems that if I want to be notified about low battery levels on my sensors and devices, I need to create an automation with triggers for all of them, or create a device group, either of which need to be maintained as things are added or removed. Why is there not a checkbox in my user preferences to just notify me if any of my devices have low batteries?
This is one of the several reasons I haven’t moved to ZWave on HA, and am still using my Vera.
Or perhaps a more generic feature, as the battery level reporting on most of the devices is garbage, of an automatically created automation to report when a device hasn’t been heard from in awhile. This would provide a broader set of functionality for comms drop outs, battery, etc.
I see this question quite a lot. So lets consider what this entails:
You might want to include/exclude some devices. Some devices can go down to 10% of battery, while others you need to replace at 40%.
Next up comes the notification, so you might want to send out a specific message, to a specific device or integration. Maybe repeating even? With an actionable notification?
For some devices I like a notification a bit earlier to remind me of buying batteries and a notification later again to actually replace them (so that is two different things).
Considering the variables above, we’ve described the bare essence of an automation. While not a click -> go solution, it does allow to fit for any situation or personal wish possible.
Not a native solution, but I have this simple AppDaemon app that loops over all my entities and searches for the ones that have "battery" in their name. If the value is below a threshold, you’ll get a notification.
Maybe something for the cookbook?
This is a little old, but I’ve been using this automation for more than a year. I dont have to add devices, I just added domains, that have batteries.
It’s not perfect as @frenck mentions above. I have some devices that drop to 10% and stay there for months, I have one or two that go to 0% and then still work for another month or two. I could replace the batteries if I wanted to not get alerted, but of course seems like a waste of battery. For those few, honestly I’d need to do a different type of automation, to check to see when they stop reporting status for a specfic amount of time.
But in general, I think this solution works well, and could be tweaked for each persons needs if they wanted
I could see having a general higher level feature set but then the details need to get filled in by each integration, and many of those integrations would need a per device type implementation.
Example my zwave setup:
But those behaviors are fairly well known for those devices. So the work could be done once for a given device and we all benefit. You would basically at the integration level define the trigger. Then when bringing in a new device or integration, the user could be given the option to setup an automation around that trigger.
Good work Frenck!
AFAIK, a big goal of HA is to become non-programmer friendly.
This will require UI-friendly settings.
In this case I would envision a “settings page” per sensor (type), maybe even a battery domain.
Here you could set a per-sensor threshold, and a drop-down list of “installed” notification services.
Of course, all of this would be possible in YAML too.
I agree with pretty much everything that’s been said in this thread… the battery drain pattern and “battery needs replacing” notification will be different for different devices… but it also seems like the sort of thing that could be tracked/learned/stored over time. Basically, there could be a “wizard” for setting up a new device with battery-related values:
And there could also be a “learned battery usage pattern” on a per-device basis, which could be used to show a “historical battery pattern” for each device, and could allow the user to see a graphical representation of battery usage that could be used when re-running the wizard, so that you could adjust the various timings/messages based on empirical data for how that specific device uses batteries. (I’m imagining a graph that starts with “device came online for first time with 100% battery” and ends with “device stopped responding, battery presumed dead”, and shows all the various levels which were reported in between with their relative timings.)
Additionally, this could allow for things like, “your window sensor is still reporting 100% battery, but is approaching 6 months on this battery, so based on historical data, we’ll send the user a warning that this battery may need replacing in the next X weeks”. Basically allow for a “calculated battery life remaining” to be used for the “early notification” setting, so that the user could have a chance at receiving a usefully-timed alert on those devices which do a poor job of reporting remaining battery life on their own.
Yes, in theory each user could create their own separate set of automations for each individual device for battery notifications, but there are also only a handful of relevant configuration values that relate to battery usage, so creating a standardized system for this still makes sense. Furthermore, the real power for this sort of thing would be tracking/storing the usage patterns on a per-device basis, which involves a decent amount of “architectural overhead” that’s likely beyond the average user (especially since “doing it right” would involve a development life cycle spanning many months to monitor actual battery draining, and lots of different devices).
There could be a wizard that loops through any battery found in the system which has not had this configured. This would handle existing objects as well, and a user could customize each battery as they have time until eventually the list of uncustomized battery alerts has exhausted.
Here’s how I did it:
still no easy way to simple trigger those battery low notifications ?! … come on …
Hey im trying to use your battery app, under service in the conf do you enter an notification device or entity? or how does the app notify you?