Discharge Rate (Drain Rate) - Feature Request

[PlayFaster]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

There is no easy way that I know of to see how fast a battery is discharging "at-a-glance". It can be checked, but its cumbersome and has to be done per battery. There is no easy way to identify batteries that are draining very fast or batteries that are reporting a battery level, but not showing any drain. Maybe the Battery Notes module could provide this?

Describe the solution you'd like

Add a Battery Discharge Rate as an attribute to the Battery Plus sensor please?

• Given average battery life spans for smart home devices, maybe this could be in % per month?
• A linked attribute could be estimated battery run-time remaining, but I'd be delighted just to have discharge rate.
• Discharge or Drain or Use or Usage ... Rate would be possible names for the attribute.

Describe alternatives you've considered

This type of information is also available by

• Using long term statistics graphs
• Creating a template sensor
• Creating a Derivative Sensor Helper
• ???

However, with these methods, a manual effort must be made, for each battery. I do this via LTS graphs for key/high-drain batteries, but it is cumbersome and would take a lot of work to replicate for each battery.

Additional context

I have been really happy with this module for HA, since I saw it highlighted on the BeardedTinker's YouTube channel. So, a big THANK YOU for creating this - it's really really useful, and for me fills a big gap in HA functionality.
I understand that a discharge rate functionality might not be straightforward to implement, but I'm hoping that it is feasible and seen as worthwhile. I would certainly find it a very useful addition. Thanks

[andrew-codechimp]

I have had this suggest before and it will be an interesting one to explore.
Statistics aren't my thing so I'll definitely want some input from yourself/others on what will be useful and methods to calculate it.
I'm moving it to Discussion/Ideas for longer term planning but happy to keep this on the to-do list.

[ScottG489]

This highlights the often overlooked idea that you don't really care about your smart device's battery percent. You care when that battery is going to run out. As @PlayFaster mentions, this can currently somewhat be done using a derivative helper and template sensor. Example template to get the timestamp for the estimated time the battery will reach 0:

{%  set seconds_to_0 =
    (states("sensor.some_battery_level")|float
    / states("sensor.some_battery_level_derivative")|float|abs)
    * 60 * 60
%}
{{
  as_local(as_datetime(
    as_timestamp(now()) + seconds_to_0
  ))
}}

I've only played with this concept a little, but I think the biggest challenge might be the time window to choose for the derivative sensor. For a smart phone you might want the window to be an hour, for a smart device it could be days or weeks. Otherwise I think if there's no change in that window it will just say the discharge rate is 0.

[andrew-codechimp]

I'll be very interested to see what you do with this.
I won't be able to create a sensor automatically for another integration/platform so I'd have to write my own but I can use the core statistics code as a good reference point.
Statistics really aren't my thing so if you get something working please share and explain what you are doing/what you achieve and I'll have a look at how I could replicate this.

[ScottG489]

I had assumed integrations could create other integrations sensors like this, but after thinking about it for a bit I think you're right which makes sense, but also seems a little strange at the same time. I'd have to look into that more. And yeah statistics aren't really my thing either so we'll see :) I'm not really sure how to choose the "right" value for the sample size.

[PlayFaster]

Hi Folks. @ScottG489 , thanks very much for the input here, both with the derivative/template and the statistics approach.

I have set up a bunch of statistics sensors, based on this, just to see what they give. I've tried some different time periods and sample sizes, 1 day, 2 days and a week. I have my database "keep days" set at 10, so a week works. As far as I know the Statistics platform only works with Current/"Short Term" statistics, so the sampling period has to be within the "Keep Days".

Mixed but useful results so far. For a "medium-fast" discharge battery, which has reduced 25% this week, the results with a sample period of a week are very clear. The change per second is extremely small, but for this case the basic "Change" statistic works, it shows 25%, which is correct.

For a slower discharge rate, it's not as clear. I have a battery discharging at about 1% per week, but as it does so, it jumps around a bit. 71%, jumps down to 70% and back for a while, now, jumping between 70% and 69%. This shows zero change for the week, because it started and finished at 70%, despite some jumping around. The "Distance Absolute" statistic is useful here, as it shows 2%, which is correct for the range of values within the week.

For batteries that show no change within the week, the statistics all show zero, as expected. The big differences in discharge rates/times between different battery types seems to be a big gotcha here.

Thanks again

[ScottG489]

Without looking at history I think it's probably best to use a sample size rather than time window since you don't have to worry as much about rate of change for each sensor your configuring.

That's a great point about the statistics sensor, slow-discharging batteries, and short-term statistics. The statistics sensor (or I think any sensor for that matter) doesn't use long-term statistics. This could be a problem since there are a lot of batteries that are probably reporting on month or longer intervals and I think most people purge data after a few weeks (default for recorder is 10 days).

That might be a strong enough reason not to use the statistics sensor directly for this implementation and instead make our own, possibly based on the existing stats sensor while also taking into account LTS.

[ScottG489]

@andrew-codechimp So I was tooling around with the idea of creating a sensor from another integration and I was able to prototype something out in sensor.py:

from homeassistant.components.history_stats.sensor import async_setup_platform

async def async_setup_entry(hass, f, async_add_entities):
  entry = {...} # This has all the properties required to make the sensor.
  await async_setup_platform(hass, entry, async_add_entities)

Also in my __init__.py async_setup_entry() I call await hass.config_entries.async_forward_entry_setups().

Nothing too complicated to it, but I can't say I've seen something like this done before, so I thought I'd throw it out there.

The idea here would be to create a statistics sensor configured to our liking without having to re-implement it's behavior in our own sensor.

[PlayFaster]

Hi Folks. I've just set up some UTILITY METERS to see what these will show. I've set them up as "Net Consumption" with no reset initially, I will report back with any useful results.

Since the large differences in time-spans for battery life seems to be an issue here, I'm hoping a Utility Meter might be useful for recording changes in very slow discharge batteries. If the Utility Meter was reset each time the battery was replaced, its value should be the discharge since the last replacement date? I know that this should just be ((100 - current-value)/time), but not every battery resets to 100% on replacement.

This does not account for the issue that the discharge rate can increase as some batteries go low, this is where a weekly or daily meter or statistic would come in I guess?