Can battery_low threshold timeout be confiugred?

[lindhe]

Hi!

First of all, thanks for providing an amazing integration! It makes my life a lot easier! ❤️

I have a couple of humidity sensors from Aqara which seems to have unreliable battery reporting. They frequently report 2-3% battery level for a minute or so only to jump back to their "real" battery level (like 90% so). This makes my battery low notifications pretty noisy. I guess I could filter out those particular device_id's in my automation, but then I would lose reports from those devices completely. A better way would be if I could configure a duration for which the battery_low threshold should be true for before it triggers the event. For example if battery_low == true for 1:30:00 then trigger battery_notes_battery_threshold.

Is this currently possible? I was looking around in the documentation but didn't find something like that.

[andrew-codechimp]

Hi, glad Battery Notes is making life easier for you.

It's not possible to do what you are asking for at the moment, but it's certainly an interesting idea.
Battery Notes would have to look back at history, which isn't something I've done before but it should certainly be possible so I'll add this as a future idea.

[lindhe]

Thanks for the answer! Looking forward to if it becomes a feature. Happy to help with beta testing or whatever. 👍

[varyamereon]

Funny, I was just looking for something similar as I have a device that is doing this:

I'm not getting a notification every time it drops randomly, but we do get a huge amount of false alerts from this device. Again, I'd not like to ignore it completely, but somehow filter out the noise of those random drops.

[varyamereon]

Here is a better image:

You can see the Battery+ reporting matches the device, and it is triggering the battery_low to be true every time.

[andrew-codechimp]

Thanks, I still have this on my todo list so it's not forgotten!

[varyamereon]

Awesome! I've managed to solve it in the mean time by setting the battery low template to this:

{{ is_number(states('sensor.frasier_feeder_battery_level')) 
   and (states('sensor.frasier_feeder_battery_level') | float < 10) 
   and (now() > states.sensor.frasier_feeder_battery_level.last_changed + timedelta(minutes=30)) }}

[davic80]

awesome! I still would vote for native implementation but thanks!

[andrew-codechimp]

I've had some time to look at this and think I have a suitable approach.

When the battery level changes it will look at the last 3 values received and if the new value is larger than an 80% change when compared to the average of the last 3 it will ignore that value and not raise events, if it gets 3 new values that are that low then it will raise the event. This will obviously delay raising events but it will be a per device configuration toggle so you can just switch it on for certain devices.
It will also work if things went the other way and a battery got a one off high level.

Lots I still need to test here though so not quite ready yet!

[varyamereon]

That sounds good, I'm just wondering with the high level version, if that would be a problem when say new batteries are inserted in a device? In this case, the state would jump dramatically but that would be correct.

[andrew-codechimp]

That's a very good point, I will look at not filtering it when It spikes higher.

[andrew-codechimp]

The latest beta just released adds support for filtering low outliers (switch it on by configuring the specific device battery note).

Please feedback here if you have issues/questions.

To get the beta release via HACS follow these instructions
https://andrew-codechimp.github.io/HA-Battery-Notes/faq/#how-do-i-install-pre-release-versions-via-hacs

[varyamereon]

It's been a few days, I've still observed the same random drops with our cat feeder battery sensor, but none of them have triggered the battery low entity thanks to this update. So it appears to be doing the job for me!

[lindhe]

I just got a false alarm, but it was a particularly long lasting outlier (almost an hour). That can probably not be prevented with a simple timeout solution, possibly with something more sophisticated like a Kalman filter. Not sure it's worth the effort to implement that just to handle buggy hardware, though.

It would not surprise me if the battery reading of cheap/bad devices gets progressively worse the less true charge it has. But that's just a guess.

[andrew-codechimp]

Thanks for the report, that is a particularly bad sensor to report 0 for 3 consecutive values over an hour.
I'm using the same outlier method as the HA Core helper, I don't think I'd want to start looking at alternatives as reading through history is intensive and increasing the number of previous values would delay events for legitimate sensors.

As you say, there's a balance in effort vs what it's catching, I think what I have at the moment will stop the most regularly annoying ones and I'm never going to be able to catch all cases.

[lindhe]

To combat cases like this, would it be possible for me to create a helper sensor (like a rolling average or whatever) that I control and connect Battery Notes to that helper? 🤔

[andrew-codechimp]

You could do that with functionality already in Battery Notes, create your helper and get it to return a boolean or string of Low/Normal and reference that in Battery Notes template field, that way you can play with all the statistics functions until you get one that worked for you.
https://andrew-codechimp.github.io/HA-Battery-Notes/#battery-low-template