Thanks for the very kind feedback, I thought it was important to get the docs up to a good standard with so many new features being introduced and at least I know it’s being read 
You are not the first to mention wanting to track these types of battery indicators and I am getting an idea together on how I might be able to handle them so that may come in a future release. It’s something new I need to explore so no promises though.
@codechimp Thanks a lot for looking into this topic.
I am happy to contribute as tester, sounding board, provider of usecases and ideas. But unfortunately not as a good coder.
I am having issues with a few devices where “Battery last reported Level” is not reported at all or is wrong. Any idea why?
There are a couple of issues with the battery last reported which have been fixed in beta version 2.0.15 released today.
Hopefully this will fix these, either join the beta in HACS or wait for the release.
Thank you!
Sorry, but issue remains the same.
That looks an unusual device with the charging level as well, I wonder if battery notes is picking up that since it’s also showing as a battery.
Unfortunately there will be devices that it won’t work with.
The Pantry door sensor is a ZOOZ ZSE41.
I have another ZSE41 installed and it works correctly.
That confirms my suspicions. The battery is detected by finding a sensor that is a battery type and a percentage, which the charging status is.
If you disable the charging status sensor, then restart HA it won’t find it and will find the battery instead.
It depends whether Battery+ or the charging status is more important to you, and having just looked at the Zooz manual I don’t understand why it even has a charging status on it.
Good. I don’t know how those charging entities ended up there. They were unavailable, so I deleted them and now it is working fine.
But the other device (chime) which has a rechargeable battery does not work as expected. And by your explanation, it won’t because it is picking up the wrong entity.
This is the full list of entities. I removed all entities with % other than Battery Level and the integration works as expected.
So, Can you add the possibility of choosing the name of the entity that the integration is reading from? At least in my system, all devices with battery have a “Battery Level” with that exact name.
humm. UPS has a “Battery charge” entity. So If we could choose which entity the integrations is getting the information from, it would be great.
It would have to be a manual pick rather than looking for the name as mine are just “Battery” and you’d also get localised variants as well.
I’ll have to think about the implications a bit but I’ll add it to the list for a potential future version.
You are right.
Thank you!
Hi, I have some devices (simplesafe) that show that battery as Normal or Low. I saw in the doc about using templates to work with this. I’m not sure how to proceed with this though.
This is for advanced use where a device does not have a typical battery percentage (or it is innacurate) but still provides an indication of the level, such as a string, boolean or voltage.
You can specify a template that must return true when the battery is deemed low.
Example templates
{{ states('sensor.mysensor_battery_low') }}
{{ states('sensor.mysensor_battery_level') == "Low" }}
{{ states('sensor.mysensor_battery_voltage') | float(5) < 1 }}
Templates are in the beta only at the moment so you will have to turn on betas in HACS to get these.
The best way to do this is to test in the developer tools/template section for your sensor, I’m guessing that the Normal/Low are actually booleans but displayed nicely within the UI so try {{ states('sensor.mysensor_battery_low') }} to start with.
If you are getting a true/false returned then in Battery Notes within Configuration, choose your device and select configure. You will be able to paste that template in and it will use that for detecting the battery is low and raising the battery notes event.
Interesting. So, could that same approach be used to override the automatic detected entity for battery level?
No, it’s specifically used for the low detection logic.
Still thinking how to best choose a battery level.
Just restarted HA and noticed in the logs:
Logger: custom_components.battery_notes.library_updater
Source: custom_components/battery_notes/library_updater.py:101
Integration: Battery Notes ([documentation](https://andrew-codechimp.github.io/HA-Battery-Notes/), [issues](https://github.com/andrew-codechimp/ha-battery-notes/issues))
First occurred: 17:13:42 (1 occurrences)
Last logged: 17:13:42
Library update failed
That indicates that HA cannot pull the latest library from Github, could be a temporary github/internet glitch unless you are seeing it all the time.
You still have the last available library downloaded (either the last time time you started HA or from 24 hours ago)
Maybe it needs to be a less scary warning rather than an error.
how could I trigger reloading the library without restarting HA to check whether it’s a glitch with Github?