[Custom Component] Battery Notes

Share your Projects! Custom Integrations
144

Got it. The reason it is confusing is because your notes say:

Restart Home Assistant
In the HA UI go to Settings → Integrations click “+” and search for “Battery Notes”

So maybe change the docs, removing that and dding something like:

After installing the HACs custom component, adding battery_notes: to your configuration.yaml file and restarting Home Assistant, you should see all the newly discovered battery devices in the HA UI Settings → Integrations page. From there, you can configure each discovered battery, either configuring or ignoring each as required. Once all devices are added or ignored, there is no need to add the integration through Home Assistant. It was already added through the configuration.yaml entry.

145

Thanks for the feedback, those instructions were written when the library was very new and you probably had to add a lot manually, I’ll update that soon.

1 Like
146

Wow we where talking about creating a helper to track how old the batteries are, because they become leaky. This is what I really need :wink:
One question is there any card already created for the dashboards?
Ich would like to create a batterie survilance dashboard with the state of all my batteries used, level, when changed and so on.

147

Hi Andrew,

great integration, I loving it!

I found that most of my Homematic IP (HMIP) battery powered devices have a binary sensor

binary_sensor.homematicip_local_000393c99b1197_0_low_bat or binary_sensor.homematicip_local_qeq0080432_0_lowbat.

being either “on” of “off”

and do not show a voltage for the batteries.

So, I could add a template for each and every device to identify if the battery level is low (or not).

Can you think of a way to provide a “pattern” to identify such a sensor (e.g. *_0_low_bat, *_0_lowbat) to add support for such devices “out of the box”?

Best regards

Frank
2 Likes
148

Thanks for the examples, I can’t think of a simple out of the box way of dealing with these that would be useful for more than a couple of devices and increase complexity but I’ll have a think if there would be a re-usable way of doing this in future.

149

Hi,
thank you for that integration.
I tested it but I decided to not use it in the next weeks.
Is there any chance to delete the integration? I did not find a hint in the documentation or via google.

150

You can remove it via HACS, just click on the 3 dots and select remove.

151

Hi,

I have also some HomematicIP devices that I would like to monitor, like @frafro.
Using a custom template works but is quite tedious when having many devices.

I tried to find the location in the code already but I am not too familiar with HA integration development and had no luck so far. If someone can pinpoint me to where the automatic level detection takes place I am happy to try to add support for binary battery sensors myself.

Until then I might be able to add some more insights on how these sensors are available in HA (these are the same for all my battery powered devices)

image
image1127×190 20 KB

The value “off” is interpreted as state “normal”, while “on” indicates a “low” battery.
It’s pretty much the same as the Battery Notes binary sensor.

Maybe this helps.

P.S.: Thank you @codechimp for this great tool.

152

P.S:
Here you can see the state as provided by the HMIP integration on top and the one provided by Battery Notes at the bottom.
image

The battery low template looks like this:

{{ states('binary_sensor.hmip_etrv_2_000a1f29a38eb8_battery') == "Low" }}
153

Anyone else getting errors to repair after the recent battery notes update along with 2024.10?

I created a battery level group helper and the error I’m getting is:

Sensor battery level group no longer has a state class

154

Only translations have changed in the recent releases of Battery Notes so nothing broke from that side.
Not sure what you are doing with helper groups, can you explain more. Just created a sensor group helper myself with a few battery_plus entities and it worked fine.

155

I don’t think this is solvable as guessing entity names from a device will always have odd exceptions (you rename an entity, it has a _1 suffix because it was re-added etc)

156

I agree partially.

First of, there is a the device class that should help.
Then there is a parameter called “LOW_BAT”.
This should help to determine the matching entity.

I would also argue that it would be easier to define that you have a binary sensor and manually provide a suffix or pattern would still be possible and easier than the current solution.

Currently I need to know the device and entity id of the battery state.
Mismatching these is pretty easy.

I will take a look at the code again in the upcoming days.
Maybe I can figure something out.

157

Same here :slight_smile:

158

Not sure if this has been discussed previously, but I’ve got a suggestion:

Is date-created available in the HA device registry? If so, would it be possible to write a one-time thing to go thru all devices in Battery Notes, and set “Battery last replaced” on any device having null / Unknown value, to the date that the device was added to HA? --Could be useful to provide a decent approximation of how old some of the batteries are.

159

That’s an interesting idea and the more recent versions of HA have a created_at date but until I can bring Battery Notes min version up (currently 2024.6) I’m unable to query this.
I think it was August or September this came in so probably early next year I’ll look into this as I like to at least keep a few months of backward support

2 Likes
160

Hi Andrew. Batery Notes / Battery+ attributes have been a great addition to my HA. I now have a monthly reminder to take a look at Battery status in one easy sortable table and replace / recharge those getting too low. I realize I can set up an automation to notify me when % go below certain thresholds, but just haven’t gotten there yet.

Yesterday was one of those days. I noted the battery type for one of my Zigbee Door sensors* reflected the wrong battery type in Battery Notes (from the Database I suppose). Battery Notes said CR2032, it actually takes 2xAAA

*Chinese ‘unbranded’ version from Aliexpress… I wouldn’t buy again or recommend since 6 of 10 were DOA and would not pair to Zigbee!!

image
image1635×181 15.3 KB

The HA device info and Devices view reflects the attached image. Model: TS0203 - Manufacturer: TZ3000_au1rjicn

In the database, the “_TZ3000_au1rjicn” appears only twice - though once as manufacturer and another time as model…

Row 97:
“manufacturer”: “_TZ3000_au1rjicn”,
“model”: “TS0203”,
“battery_type”: “CR2032”

This is the entry Battery Notes is (appropriately) picking up for me… since the attributes match. But my issue is the device’s batteries are 2x AAA

and Row 5180
“manufacturer”: “Tuya”,
“model”: “_TZ3000_au1rjicn”,
“battery_type”: “AAA”,
“battery_quantity”: 2

I think this was another person’s attempt to enter the correct information (correct battery type and quantity) but the person who submitted the entry might have gotten the fields messed up? Matter of fact, I’m pretty sure when I ordered the sensors, AliExpress noted the product as being Tuya sensors, but the box was generic and did not reflect Tuya on the packaging… that could certainly be part of the issue.

Anyway, I 100% understand that you cannot possibly moderate the battery database AND for me this is NOT any kind of major / life & death issue… It was obvious to me that the skinny door sensor in my garage side door could not possibly fit a CR2032 inside the footprint of the sensor. So, I took 2 AAAs (as well as 2 AAs just in case) with me when I went out to make the change.

That said, is there any process for dB ‘corrections’ or ‘edits’ other than sending a note as I am now? I am not a coder so I’m not totally up on github contributions or changes that would be done that way… though I’m open to learn. And of course, my ‘fix’ might turn out to be someone else’s ‘break’ Just thought I’d share and get your thoughts.

Thanks again for your efforts.
John

161

Hi John,
I have come across this before where different revisions of a device have changed their battery but there’s no way of determining this from the manufacturer/model, so perhaps that’s the issue here and as you say fixing it for you will break it for others.
You can always edit the battery note manually to change the battery type (integrations, battery notes, pick your device from the list and configure).
You can submit a revision to the library (no coding required) using this form but that will only work for devices you have not already added so I’d suggest a manual modification if we’re not sure if these exist with CR2032’s.
And just to add more confusion the two different rows are for different integrations, usually Zigbee2MQTT and ZHA so yeah moderating the db is hard!

Glad your enjoying the integration and thanks for the feedback.

1 Like
162

Thanks for the quick reply Andrew.

Funny - the first thing I was going to do was to just edit the Battery type but I couldn’t find where to do that. Thanks for relaying that.

For this particular device (typical door / window sensor with sensor and magnet), it could not be possible to have a CR2032 given the tall & narrow footprint of the body… But I wouldn’t presume a ‘cheap’ manufacturer didn’t just apply the same model / manufacturer coding across the firmware for multiple different devices (e.g. temperature sensor, zigbee ‘button’, etc…) some of which could certainly have a CR2032 or if they changed the physical size of this model from widebody to narrow body. For me, the manual update works. Thanks for pointing it out.

Edit - all fixed manually and I can’t believe I didn’t look in the Integration config in the first place!!

1 Like
163

Thanks for your component, @codechimp ! Very usefull indeed.

I am trying to maintain a record the current stock I have for each battery type, in input_numbers.
for instance, input_number.battery_cr2450_stock, and input_number.battery_cr2032_stock.

  1. How can I archive to update this number, decreasing it, when that specific type of battery is replaced, for instance, with the button press?
  2. How can I archive to update this number, decreasing it, when that specific type of battery is replaced, accounting for battery_notes_battery_increased event?

I could then use this to automatically add to my shopping list when that input_number lowers to a certain level (for instance 5), so that I always have some spares… (This part I can do, lol)

Thanks in advance, never used much events in my automations, but it’s time to understand this.