I see that you recently added type and quantity as attributes, would it be possible to do the same for last replaced timestamp? I use tile cards to display all my battery decives and it would be nice to also display the last replaced timestamp.
I think I am going to be able to go one better than that and add a whole new battery that echo’s the real battery but add’s everything from battery notes as attributes so it’s a simple drop in replacement battery entity.
A bit like the change device type of switch helper where it hides the original.
Still in prototype stage but probably in the next week or two.
From what I see it depends on which integration is listed first on the entity detail page.
Only those icons changed at my installation where Battery Notes comes first. For those where Zigbee is still the first I have the Zigbee icons as before.
Hello, and thank you for this fantastic component!
I’m currently working on creating an automation to add the battery type to the shopping list when the battery level drops below 20%. I’ve set up a template sensor to identify the sensor with the lowest battery level, intending to use it as a trigger for the automation.
My challenge is figuring out how to programmatically obtain the battery type for a sensor. Has anyone found a way to retrieve the battery type and quantity for a specific entity_id?
I have Battery Notes working for devices with batteries. My question is how can I use this will entities? The heating system I have has several sensors and TRVs. The sensors and TRVs appear as entities and NOT devices.
A room has a climate device. The temperature is measured from a sensor that has a battery. The room may have one or more TRV, each battery powered.
Unfortunately those devices won’t work with Battery Notes, it needs the device to be able to add the new sensors against the same device and also get a manufacturer/model for the library, which is at device level only.
In a soon to be released version it will also need to look at the entities/sensors for the devices so I can’t use entity only.
Out of interest what’s the climate/TRV you are using here?
@codechimp - I am using Genius Hub https://www.geniushub.co.uk/ and have been for probably well over a decade. As a solution it works well but with HA could probably do something similar in a more controlled manner. By using HA to control it can be local only which is good.
alias: Battery Low Notification
description: Battery Low Notification with auto dismiss
trigger:
- platform: event
event_type: battery_notes_battery_threshold
event_data:
battery_low: true
id: low
alias: Battery went low
- platform: event
event_type: battery_notes_battery_threshold
event_data:
battery_low: false
id: high
alias: Battery went high
condition: []
action:
- choose:
- conditions:
- condition: trigger
id:
- low
sequence:
- service: persistent_notification.create
data:
title: |
{{ trigger.event.data.device_name }} Battery Low
notification_id: "{{ trigger.event.data.device_id }}"
message: >
The device has a battery level of {{
trigger.event.data.battery_level }}% {{ '\n' -}} You need {{
trigger.event.data.battery_quantity }}x {{
trigger.event.data.battery_type }}
- conditions:
- condition: trigger
id:
- high
sequence:
- service: persistent_notification.dismiss
data:
notification_id: "{{ trigger.event.data.device_id }}"
mode: queued
In the condition: trigger: id: low actions you can add the battery to your shopping list and then in the condition: trigger: id: high action you can remove the item from your shopping list. Simple!
I’d recommend using the battery_increased event for the removal from your shopping list, this will better handle any battery level flutter or if you change the battery before it’s low if your going away.
Have I mentioned yet that this new integration is “the greatest thing since slided bread!” for battery devices in HA?? I’ve purged my system of the very old and unmaintained Battery Alert Package by NotoriousBDG as I now have something vastly superior and as good as if not better than HomeSeer’s SDJ-Health Plug-in which I used up until 3 years ago when I switched to HA.
One feature missing perhaps that SDJ-Health has is a notification if a device fails to wake up and send a battery report which could indicate the battery has died.
For those not following the Version 2 sneak peak discussion on github, here is the announcement for the beta release of Version 2.0:
Version 2.0 has just been released in beta and will probably stay there for a few weeks as this is a big lot of changes.
Thanks to those who’ve contributed to shaping these features, I hope I’ll please at least most with the options available.
If you want to try this you will have to go into HACS/Battery Notes/Redownload and switch on Betas to see version 2
New Features
A new Battery Plus sensor, it echo’s the normal battery but has additional attributes from Battery Notes to make it easier to use in the ui and automations, you can optionally hide the original battery with a configuration setting.
A Battery Low binary sensor, it uses a global default threshold (10%, changeable in configuration) to indicate when a battery is low, you can also manually configure a device in battery notes and set a specific threshold for each device.
A Battery Threshold event which is fired when the battery goes low, or returns high. Useful for notification automations.
A Battery Increased event which is fired when a battery increases by a certain percentage (25%, changeable in configuration). Useful for battery replaced automations.
Thanks for the great support of my little project!
I have been thinking about device not responding but with things like MQTT being slow to do a first report I’d have to be careful how I catch that without false hits, it’s on the list!
After 100 people have tried the beta with no issues reported I’m now releasing version 2 of Battery Notes with some big new changes. Read at least the community examples to get an idea of how to use these features.
New Features
A new Battery Plus sensor, it echo’s the normal battery but has additional attributes from Battery Notes to make it easier to use in the ui and automations, you can optionally hide the original battery with a configuration setting.
A Battery Low binary sensor, it uses a global default threshold (10%, changeable in configuration) to indicate when a battery is low, you can also manually configure a device in battery notes and set a specific threshold for each device.
A Battery Threshold event which is fired when the battery goes low, or returns high. Useful for notification automations.
A Battery Increased event which is fired when a battery increases by a certain percentage (25%, changeable in configuration). Useful for battery replaced automations.
Improvements to the json schema validation when editing within HA custom components folder, thanks @heyrichard17
Agree with you on the decimal place but some batteries show .5 so I have to include it to be consistent with those devices. Might provide a round configuration option later.
First of all: superb integration. It’s sound, well documented and even enriched with easy-to-use blueprints. Thanks a million @codechimp
And of course there is a question as well:
How could I use battery notes with devices that have an battery_state sensor instead of a battery sensor?
The battery_state sensor indicates only high, medium or low.
It would be really beneficial (at least for me) to be able to use battery notes for all my devices that contain a battery, even if its state is reported not very accurate.
the newly introduced events could fire when the state changes
battery_notes_battery_threshold: to low - true; from low to medium or medium to high - false
battery_notes_battery_increased: from low to medium or medium to high
sensor.klima_t2_battery_state