some battery+ Sensors switching between LOW and NORMAL, while the source sensor remains LOW

[ChristophCaina]

Checklist

• I have added battery_notes: to my configuration.yaml and restarted.
• I have read the FAQ's.
• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Battery Notes Version

2.10.11

Describe the issue

For some of my Homematic IP Devices, I noticed a kind-of strange behave of the Battery_plus_low binary sensor.

While the source sensor remains "ON" (low) - the sensor from BatteryNotes keeps switching between ON (Low) and OFF (Normal)...
And I don't see the pattern for this.

I have no Idea how to reproduce this...
But right now, this is conflicting with some of my automations for battery monitoring.
Using the Source-Entity seems to be more reliable at the moment... but I know, that it can happen for Homematic IP devices, that the sensor would switch between low and normal (but this would be reflected in the source sensor as well, then)

For non binary-sensors, the threshold would be 10%...
In case the sensor would switch from 10% to 9% - and then back to 10% I would understand this behave.
But in my case, the source sensor is also just a binary sensor...

reloading the source device caused the battery+ sensor to switch back to low...

Reproduction steps

1. unknown

...

System Health details

HA OS 2025.10.0
BatteryNotes: 2.10.11
debug logs activated but not yet collected

Debug logs

Diagnostics dump

No response

[andrew-codechimp]

That's very strange and not something I've come across.

It does just listen/track the source binary sensor and mirrors its state, as long as it's not unavailable/unknown.

Is this something new happening since 2025.10?

I'll have to add it as a bug to investigate so no quick solution I'm afraid.

[ChristophCaina]

tbh - not sure if this is new since 2025.10.
The problem is, that I did a complete fresh installation and working on it since then to improve / optimize monitoring.

I was running the 2025.10. beta ... but until now, I am not sure if this happened before - as I just started looking more closely to the battery states as I am working on some automations based on these sensors.

if there's any way on how I can support with the investigation, pls. let me know.
I could try to create some kind of logging to see, if there might be a pattern.

[andrew-codechimp]

At the moment I don't have anything to suggest as far as logging.

Does the Fenster (Nord) device have any other binary sensors that match this pattern of on/off? Battery Notes shouldn't be picking up those but it's odd it's staying Normal so long.

[ChristophCaina]

hm... the devices have some binary sensors yes...
As well as others that could MAYBE cause the conflict...
The device does provide information on the "Operational

The device is also reporting operational voltage level - in percentage.
I haven't seen that this value had changed, when the battery sensor of the integration switched to normal.
Right now, they are looking OK... both devices where I have seen this are reporting LOW as expected.

Other diagnostic sensors are "Duty Cycle" - which hasn't changed
And a manipulation-sensor, but this hasn't changed as well.

I will keep an eye on this and try to report any additional findings.
Unfortunately, these are currently the only devices with low battery...

[andrew-codechimp]

Oh, that's a very confusing device.

Since it has a battery percentage it uses that as the low indicator, it does not look at the binary sensor. Does not explain the fluctuations but does explain why it could be different.

For these devices add a template for the low, mapping it to the devices boolean battery low as indicated here
https://codechimp.org/HA-Battery-Notes/#battery-low-template

[ChristophCaina]

all right, thank you.
I just had a look - and it seems the sensor didn't change again for 19 hrs now.
Not sure, what was causing the issues yesterday - I had an update of the integration of the source device, it might be, that the new sensors were added shortly - or hat a communication issue messed up the values... somehow.

I will check the template option - I guess, this could then happen for other, similar devices from the same manufacturer.

[ChristophCaina]

hm... just an update.
After setting the template, it started to look quite good.
But I had to restart my HomeMatic Server as well as my HomeAssistant.

I recognized, that the sensor became unavailable - and when it came back, it was "normal" again.

Again, this is true for both devices mentioned above.
Both of them are showing "normal" while the source sensor remains "low"
In both cases, the "operational voltage level" and "Battery+" sensor are showing 0%
The operational voltage is showing 2.1 V

In theory, all conditions are met for the sensor to show "low" (source sensor) as well as "operational voltage level" and the derivated battery+ sensor are showing 0%

[andrew-codechimp]

That's very strange, I'll setup my test environment with a similar style device and see if I can reproduce it, but at the moment since it works with most others it's baffling.

[ChristophCaina]

yes, I agree.

I will download my logs and have a look if I can see something there.

[ChristophCaina]

Hi,
Sorry for the delayed response.
Debugs log were for some reason disabled - and it took me some time to finish some other topics, before investigating further into this.

I think, the topic might be related to the option "filter outliners"

In debug logs, I filtered for all devices of this specific type - I have 6 of them in total:

2025-10-07 09:50:00.776 DEBUG (MainThread) [custom_components.battery_notes.discovery] 8253e870ba91b653264c5eb143d49e4c: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.777 DEBUG (MainThread) [custom_components.battery_notes.discovery] 73dad42ab71f87b544683ca9c28d6256: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.781 DEBUG (MainThread) [custom_components.battery_notes.discovery] 9c3ba7508b151fba4b4be809423498dc: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.783 DEBUG (MainThread) [custom_components.battery_notes.discovery] a992ebe027b3f05d60f37bc06a1e0c37: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.784 DEBUG (MainThread) [custom_components.battery_notes.discovery] 04ed9b873db61133e76eb5249efb9d08: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.785 DEBUG (MainThread) [custom_components.battery_notes.discovery] 23e9ccb7abb39160d4ba5c16453e45a2: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)

I noticed, that both sensors I've reported have been switched to "normal" again.
After a restart, they became "unavailble"... for a few minutes.
I thought, they would start as "LOW" after a restart, but instead, they were again showing "normal" while the source was low.

Going through the logs for all HmIP-SWDO-I devices, I noticed, that only on two of them it does logg outliner options.

2025-10-07 09:50:00.777 DEBUG (MainThread) [custom_components.battery_notes.discovery] 73dad42ab71f87b544683ca9c28d6256: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.777 DEBUG (MainThread) [custom_components.battery_notes.discovery] bn_73dad42ab71f87b544683ca9c28d6256: Already setup, skipping new discovery
2025-10-07 09:50:14.440 DEBUG (MainThread) [custom_components.battery_notes.coordinator] Checking outlier (73dad42ab71f87b544683ca9c28d6256=0) -> 0.0
	
2025-10-07 09:50:00.784 DEBUG (MainThread) [custom_components.battery_notes.discovery] 04ed9b873db61133e76eb5249efb9d08: Auto discovered device (manufacturer=eQ-3, model=HmIP-SWDO-I)
2025-10-07 09:50:00.784 DEBUG (MainThread) [custom_components.battery_notes.discovery] bn_04ed9b873db61133e76eb5249efb9d08: Already setup, skipping new discovery
2025-10-07 09:50:14.380 DEBUG (MainThread) [custom_components.battery_notes.coordinator] Checking outlier (04ed9b873db61133e76eb5249efb9d08=0) -> 0.0
2025-10-07 09:51:20.155 DEBUG (MainThread) [custom_components.battery_notes.coordinator] Checking outlier (04ed9b873db61133e76eb5249efb9d08=0) -> 0.0

I also searched for the sensors-name - and here, it looks like it was set to "Normal" via template

2025-10-07 09:51:04.109 DEBUG (MainThread) [custom_components.battery_notes.binary_sensor] binary_sensor.fenster_nord_battery_plus_low binary sensor battery_low set to: False via template

2025-10-07 09:51:04.109 DEBUG (MainThread) [custom_components.battery_notes.binary_sensor] binary_sensor.fenster_ost_battery_plus_low binary sensor battery_low set to: False via template

I think, after disabling the filter outliners - and removing the battery-template (which was probably wrong)... it seems that the correct state will now be reflected again.
I will monitor this further and update again.

[andrew-codechimp]

Thanks for the additional info, the template is using the standard template engine so as long as your template is right it will work as HA would to a value change.
My mock sensor (an ESP device) hasn't had issues in the last few days but I'll keep an eye on it.