WTH: Why don't low batteries show up in the repairs section?

Month of "What the heck?!"
1

I’ve got a Hue sensor in the hallway. It reports its battery state, and right now it’s got about 2% battery left. I wouldn’t know it’s about to die, unless I was actively looking at battery percentages, or unless I walked into the hallway and wondered why my automation didn’t run.

You can loop through devices and get a list of battery percentages using templates, but it’d be nice to have low battery stuff appear in the Repairs section so you can get on top of replacing / recharging batteries before they become an issue

2

A better idea is to send a notification to yourself when a battery becomes low. This can be done with a simple automation. Or a complex automation.

- id: 692821db-ad38-424c-be2b-b3abc50d892f
  alias: 'Low Battery Alert'
  trigger:
  - platform: numeric_state
    entity_id: 
      - sensor.dining_door_battery
      - sensor.dining_window_e_battery
      - sensor.dining_window_w_battery
      - sensor.kitchen_window_e_battery
      - sensor.kitchen_window_w_battery
      - sensor.lane_gate_battery
      - sensor.lounge_door_battery
      - sensor.lounge_window_e_battery
      - sensor.lounge_window_s_battery
      - sensor.mailbox_door_battery
      - sensor.mailbox_lid_battery
      - sensor.master_bedroom_window_battery
      - sensor.rumpus_door_battery
      - sensor.shed_door_battery
      - sensor.spare_bedroom_window_battery
    below: 40
  action:
  - service: notify.telegram_system
    data:
      title: '⚠️ <b>Low Battery</b>'
      message: "{{ trigger.to_state.name }} low battery level: {{ trigger.to_state.state }}%"
3 Likes
3

While I personally use the automation system to tell me about low batteries. We have a repairs section, and this would definitely sit well in there.
The issue here, is that in order to be proactive about replacing batteries, new users have to create an automation / find a blueprint.

This should really be something that works out of the box, so if not by using the repairs system, then a low battery blueprint could be available out of the box.

6 Likes
4

The additional issue is that each device has a different battery profile, some sit at 90% then plummet to 0.Some reduce gradually, some sit at 30% for ages then stop. Where do you put the the low battery level for inclusion into repairs?

A blueprint would be required for each device type, if not each device.

5 Likes
5

Maybe - if they were to make use of the repairs section for this information, it could be done on this basis:
If a device has a sensor attached to it that has a device_class of battery, and either the reported value is below a threshold configured in general settings (where you set units of measurements etc), or the device becomes unavailable - then it will be added to the repairs section?

3 Likes
6

If a certain battery-powered device usually reports data every minute/hour/day/whatever, HA could learn how large is the period between each update. If suddenly the battery-powered device stops reporting data for longer than n times the usual period, something smells wrong, and is worth checking. This could be an automatic way to detect dead batteries. Sure, it’s not preventive, but it’s better than nothing.

2 Likes
7

I think there is something good here. Sure you can create an automation. I do that, and made some blueprints to do this in the general case.

But far better would be a default ‘below 10%’ battery warning that was easy to turn on.

I think it is a bit of a leap to assume device offline means dead battery, but we could give an offline alert that said the last time seen and the battery %.

8

This (getting things that have a device_class of battery and setting a minimum threshold somewhere) is precisely what I had in mind, plus you should have the option to ignore some warnings, and / or the warnings should go away next time the detected battery level is above your threshold

This’d cover instances where you’d expect a low battery fairly often (e.g. your phone) and don’t care because you plug your phone in to charge every night anyway

9

I agree, but a device that we know is battery powered, going offline - should still be something that pops up in the repairs area, because it’s something that requires attention.

7 Likes
10

I think being able to set a global threshold then customising at the device type level could be good.

I also feel like battery usage/forecasts could potentially be an (actually useful) area for some HA machine learning projects?

“14 days battery remaining”.

Could be interesting if the community opted to make battery usage/lifetimes available and this could be used to inform others. Mi Flora and other Xiaomi devices could be an example. Then some fixed values/profiles could come with the device. Would need to account for actual battery capacity I guess

Anyway this last bit is all a bit brain fart/off-topic/pie in the sky.

11

Home Assistant keeps track of battery levels in the recorder / History tab, so I guess you could run some statistical functions to compare battery levels over time and get a rough estimate of how long you’ve got until your battery runs out. It’d be far more complicated than that (I’m not a maths person, but I suspect it’d be complicated), but the data is there should you want to get some stats on roughly how long your battery will last.

12

That would be nice functionality instead of just realizing an automation isn’t triggered and having to hunt down the issues.

13

I think there’s both some simple and complex things you could do. I’ve got a long forgotten mathematics degree.

At the most basic you could fit a linear forecast model.

More complex you could account for forecasted usage of the device (it may not have linear usage/energy consumption).

So basically you’re going from % battery left to time left.

Sometimes it’s not so clear if 5% battery gives you 2days or two weeks to replace it. Probably gets even harder to forecast when closer to 0 as things get particularly non-linear at this end.

But I think managing batteries in % left, not days left is probably sufficient for most people.

14

Interestingly the Plant integration has something similar to what we’re suggesting.

min_battery integer (optional, default: 20)
Minimum battery level before triggering a problem.
15

While having some more automated way of tracking what sensors need a new battery, I don’t think “Repairs” is a good spot for it. If you have lots of battery operated devices you would never be able to get rid of the “in your face repairs notifications” and it would get annoying quickly, also, as another person mentioned, different devices / batteries need the batteries replaced at different percentages so how do you create a one size fits all threshold?

There are currently lots of solutions in the wild ranging from automations, node red, and lovelace based solutions, but it would be nice to have something more standardized. Maybe a threshold for each battery that is set on the device page itself and some view where they appear when getting low, or a view that shows them all but with clear sortable states. While at it… they could give a way to record what battery it needs… I have to refer to an excel spreadsheet…

16

I use customize_glob for adding battery_type to my battery sensors - it’s simple to add battery_low too which could then be used in the automation.

My Shelly DW2 normally die after reaching 85%.

customize_glob.yaml:

sensor.shdw2_*_battery:
  battery_type: 2x CR123A
  battery_low: 86

Not that exhausting…

3 Likes
17

There’s a few potential solutions to the issues you mentioned:

  • Make it opt-in so you have to tick a box in the entity settings in order for it to show up in the Repairs section. Here’s a mockup. You could also set a low battery threshold there, like you mentioned.
  • Make it opt-out. If the constant notifications annoy you, have an “ignore this device” button
  • Group all the repairs into a single notification. The issue is resolved when all the batteries are replaced, or you’ve ignored them / turned off the low battery notification

The way I see it, the “Repairs” section should be for things that need repairs / attention, and a flat battery is something that needs repair / attention, because, as I said, the battery going flat in something could lead to issues further down the line.

If that section of Home Assistant is only for things that will affect your Home Assistant instance (e.g. integrations that are being deprecated or have a breaking change etc.) then it should really be renamed because it’s stuff that only affects the Home Assistant software, not the products it lets me interact with.

4 Likes
18

Putting the onus on individuals to specify battery profiles is bad UX. If you have a physical device with a battery that Home Assistant is aware of, it came from an integration somewhere. Integrations should be what defines the battery profile, not every individual person. Overrides still make sense, but don’t default to forcing everyone to become a battery engineer.

19

All and well, but what about e.g. Zigbee and Z-Wave that integrate devices from different manufactures. My Ikea devices have totally different battery profile from my Aqara devices or my Tuya devices. Yet it is all Zigbee.

20

I’m not suggesting that all devices that use the same protocol should have the same battery profile. That doesn’t make any more sense than having a single profile for all devices regardless of protocol.

In any case, there’s always a seam where behavior can be inserted. For example, both Z-Wave JS UI and Zigbee2MQTT have ways to inject information about specific devices. There’s no technical reason they can’t insert battery profile information.