And not to blame it only on door-window sensors (MCCGQ11LM), here are:

• smoke sensors (JTYJ-GD-01LM/BW aka Honeywell Xiaomi)
  

• xiaomi buttons ( WXKG11LM and WXKG01LM )
  

• motion sensors ( RTCGQ01LM and RTCGQ11LM)
  

And this installation is a-lot-months old already, so it's not fault of often restarts/rebindings or not gathered enough data...

Are you sure that this is a problem with Zigbee2MQTT? As far as I know, all it does is publish the values transmitted by the ZigBee sensor.

I have quite a number of Xiaomi sensors that have been in service for 2-3 years... possibly longer. I'm currently seeing most of the door switch sensors reporting battery health in the 91% - 100% range. I have three environment (temperature/humidity/barometric pressure) sensors that send updates quite frequently. One of them recently needed a new battery and I was able to see the voltage and battery percentage trend down over time, before the sensor finally stopped transmitting.

I'm almost certainly sure, as those sensors in xiaomi aqara gateways and it's app reported values that seemed reasonable. Much more reasonable. So 90% after few months is much more reasonable than 100% after 3 years.
On the same sensor.

As far as I know the sensor only sends the voltage, and z2m translates it into a percentage the best it can.
So if you don't see a change in the voltage, you will not see any change in the percentage.
Here is where it makes the magic:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/fe7d0ec950dec5af824e153220777806f29ac59a/converters/fromZigbee.js#L4277-L4301
and here (I think it uses the 3V_2100 option):
https://github.com/Koenkk/zigbee-herdsman-converters/blob/fe7d0ec950dec5af824e153220777806f29ac59a/lib/utils.js#L132-L168
The conversion from voltage to percentage maybe can be done better/different, but first you need the voltage to be changing.
Over 3 V it will always show 100%.

@McGiverGim I'm aware it's z2m that does the calculation. I've opened the issue because I'm somehow nervous about not having oppoturnity to i.e. exchange batteries before I go for holiday, because I can see they're low (i.e. <20%).
Main question is - what's the difference with approach of Xiaomi Aqara gateway (for specifically Xiaomi sensors), that makes their values much more reasonable?

If sensors send it's voltage, are we 101% sure it's pure voltage without any calculations done?
I guess it's not difference in protocol - older Xiaomi gateways were zigbee 2 (the ones I had), newer ones are zigbee 3 already.

--
some time before migrating to z2m I've been using deconz, which also had different approach with battery reporting.
There was funny situation, when I've came across thread on smartthings forum, which had third approach of calculation. And the only reference I had was aqara gateway, which was the closest to reality (in perception of percentage, not voltage)

It works with the data the sensors sent. Nothing more. If it is the real or some strange calculation voltage I can't say. The same does the Aqara/Xiaomi gateway as far as I know.
The method z2m uses for the percentage is the best z2m found, because z2m don't know how Aqara/Xiaomi converts the voltage to percentage. If someone knows how it does this conversion, it can be changed to be similar.

I started to dig some once again, as maybe there's a oppoturnity for some fine tuning.
So, calculations are/were (don't know, don't use) in ZHA too: home-assistant/core#44578
but!
I've found some nice battery-level count method, which I've checked with one of my sensors:
https://community.home-assistant.io/t/xiaomi-aqara-battery-level/36222/14

So, taking a look at:
(2.8 is 'completely dead, 2.9 should be considered to exchange):

z2m shows 100%, solid
while:
Math.min(Math.round((voltage - 2200) / 10), 100) found and used in nodered is:
((3025 - 2200) / 10) -> 82,5%

and that's the value I could believe, because I remember that I was exchanging that battery some time ago already.
Let's take a look on the other one I've changed earlier:
(3085 - 2200) / 10 -> 88,5%

I'm just not sure if taking '2500mV' to account is proper way for calculation, as I don't think any xiaomi sensor will report anything with battery lower than 2.8V

It's open for discussion, I'd just like to have my fav software fine-tuned in that aspect too... and cut the myth of 100% ;-)

@andriej since we focus on Xiaomi devices here, could you change the title to mention Xiaomi?

My WXKG02LM_rev1 currently reports the following so it should drop off soon, will keep an eye on the last known voltage before it stops working.

@Koenkk this will be surely nice catch - the sensor that was the reason of starting this thread has gone out with 3035 (last value I see in HA) and I'm even more worried about it right now. ;-)

To not be blamed of being 100% pesimistic - there's something 'better' in calculating temp/hum and temp/hum/press sensor:

WSDCGQ11LM and WSDCGQ01LM

Maybe they get different counting schema and that's why their values are more to be respected?
I don't have much more stuff from Xiaomi with batteries, but also have GZCGQ01LM outside house.
Would you believe it has 100% after winter out there? ;-) It's voltage is 3000, so below what's 100% (new battery), but z2m shows as 100%.

I hope maybe more people will join the thread and solution may come later on.

I have some 20 of those contact sensors. Those reporting 3015-3025 mV report 100%, 2995 mV report 97%, 2985 mV report 91% and 2975 report 86%.

One of my WSDCGQ01LM is low too:

I will keep an eye on it too, but I'm pretty sure it can last some months with this battery level. And I suppose different devices will have different dead levels.

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

Still valid I guess

I'm come here following two dead batteries on xiaomi temperature/humidity sensors.
Last battery % i get from this sensors was respectively 91%(2985mv) and 100%(3005mv).

I suspect several things about % calculation:

• calculation is not linear since battery discharge is not
• calculation is depending on temperature/humidity
• different kind of sensors can have different minimum voltage to work properly
• discharge is depending on resistive load of device
• possibility that xiaomi gateway battery calculation is based with a 100% based on new battery voltage

So it's a complex topic to find the perfect solution.
I can see only two way to find an acceptable solution:

1. the best one: retro-engineering of xiaomi gateway (or may be application ?)
2. use a xiaomi gateway and try to guess a general formula depending of voltage seen, battery % from gateway/app, kind of sensors, temperature/humidity
3. create a central database of voltage for different kind of sensors from several users to determine minimum voltage for each kind of sensors

For the battery problem alert, actually it's not possible to rely on % battery for all kind of devices by experience.
I actually use last_seen report to detect died battery since sensors emit regularly and suddenly stop.
But I can't see a way to alert before battery die.

Complete PDF about CR2032 lithium battery: High pulse drain impact on CR2032 coin cell battery capacity

Has anyone tested the accuracy of the sensor voltage readings with a decent quality multimeter or compared readings between two devices with the same battery? My guess would be the values might vary quite a lot.

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

Still valid

I'm waiting to see when my device dies. The latest report was at 40%, the 25th august. Now is at 29% (2.815V) and working...

Hi,

To help, my WSDCGQ11LM stop working.
Last values before it die :

Hope it can help.

@larod241 thanks, I will keep track of these values here: https://pastebin.com/64HP9i10 (so others please also report the last voltage before it dies)

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

@zen2 it would be interesting to see a screenshot right before the battery dies. Does the pattern break or is it consistent?

@zen2 it would be interesting to see a screenshot right before the battery dies. Does the pattern break or is it consistent?

It will be consistent because battery reporting is done less often than sensors reporting.
Usually you do not see a battery voltage variation right before batteries dies.

I'm sure that % battery level depends on temperature (that all xiaomi aqara devices report) and that low voltage limit is different for each kind of devices.

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

Come on, bot

I have the same problem with all my Aqara door/window sensors:

However, most (!) of my Aqara temperature, pressure and humidity sensors actually report a battery percentage less than 100:

How come (most of) the weather sensors show a battery percentage less than 100, when the door sensors don't?

Yeah this is happening to me too, battery on aqara sensores are always 100% until they no longer have beterry and I realize they are no longer transmitting...
Xiaomi sensors works tho

Unfortunately I can confirm it. My window/door sensors just used to stop to work and the battery was 100% or so. Now I just look at the voltage (mV) and do my own math: problem solved.

Unfortunately I can confirm it. My window/door sensors just used to stop to work and the battery was 100% or so. Now I just look at the voltage (mV) and do my own math: problem solved.

But zigbee2mqtt doesn't send the mV reading to Home Assistant - right? (Why not?) I don't have any mV readings in HA...

Unfortunately I can confirm it. My window/door sensors just used to stop to work and the battery was 100% or so. Now I just look at the voltage (mV) and do my own math: problem solved.

But zigbee2mqtt doesn't send the mV reading to Home Assistant - right? (Why not?) I don't have any mV readings in HA...

it is... you just need to enable it. it's disabled by default.

@Smandurlo to you have a template to do the math?

it is... you just need to enable it. it's disabled by default.

Wow - how do you do that?

Works well. But how do you use the mv then ? how to know which percent it represents ?

Just to mention that the same problem happened on a Aqara E1 TRV, i.e. Xiaomi SRTS-A01. I've enabled voltage reading and will add information at the end of the next battery cycle.

Same here with Xiaomi WSDCGQ11LM. Still 100% and 3005mv after a year of constant reporting. But I don't think there is much we can do with it.

Hi there,
I also have the issue that all of my (most Aqara) battery levels are at 100%.
If I read this thread correctly, there is no way to get the real values?
Before Z2MQTT I used ZHA and the values were showed correctly...

Check mW... If it's over 3V you have 100%. If it's under 3V then you have less then 100%. The battery drain faster with less then 3V...

@Koenkk : as many users report that ZHA display batteries voltage correctly I've dived in homeassistant code to find how they calculate it. In fact homeassistant ZHA component is based on zigpy.

Battery calculation in Zigpy code:

• MASTER: 436: https://github.com/zigpy/zha-device-handlers/blob/master/zhaquirks/xiaomi/__init__.py
• DEV: 474: https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/xiaomi/__init__.py

Another related and interesting code is the zha xiaomi test code:

• https://github.com/zigpy/zha-device-handlers/blob/dev/tests/test_xiaomi.py

As far as I understand they seems to use 2820/3100 mV for 0/100 % per default and min/max voltage can be overridden by device quirks.

2820/3100 mV for 0/100 % per default and min/max voltage

So, if you decide here to use this values you get a problem. Some device will show 85%, but battery changed before. I do it yesterday and don't have 3100 mV. So my device show 3053 mV. Wise versa to undervoltage. You have 2850 mV and my device stop working. But it shows me 10% of charge. So that also bad as well. If you work with Voltage and you want to calculate battery state, you need upper and lower percent that save you for mistakes. Each battery manager work like this.

@zen2 it's also just a linear calculation, z2m uses 2850 <-> 3000, while ZHA uses 2820 <-> 3100. If that's better, we can easily change to that.

That isn't better. That's worse. I don't have any device starts with 3100 mW. If we set this to 3100 then all my device never will show 100% full state. That's stupid then.

It's a never-ending story... :)
Mine window sensors (MCCGQ11LM) most of the time starting from 3175mV with Varta batteries:

I have no clue how it can be solved.

The different capacities of battery's are a problem either. If you have a CR2032 capacity is 225mA...if you have a CR2450 you have capacity of 650mA. We have then other Voltages. We have this issue with different types and we have also different Voltages and we have non linear uncharging. You can solve this only within this devices itself. But we can't. We get only the voltage and don't have any clue about capacity. That is the big problem here... When we say hey we have 2% range around 3100 then we get a good value for 100%... That means a range between 3100-2% also for 3100+2%... Then you can start with calculation an we get something around 3035... So then we have 100% but at the end... It doesn't matter what we calculate, with linear calculations we are affected and dependent on uncharge curve of the battery... And draining will be faster at the end. So what should we do now? If we put it to 3100 mW no of my device or the most of them will show all times under 100%. I will never get 100% anymore with a new fresh battery.
The solution for me is then very easy... If a battery device is offline, I get a message from my home system that is it and I change the battery and don't care about voltages, capacity or percentages of load.

I think while the current solution isn't perfect, at least you get an estimate of the battery charge. I agree with @Wikibear - The easiest solution to the inaccurate battery stats is to use an automation that checks if all of the device's sensors stay unchanged for a period of time. This usually indicates a weak or dead battery. It's not ideal as you might lose some information during its downtime if the battery really is dead, but I for example have no sensors that are so important, that they'd have to have 100% uptime.

@stickpin: It's a never-ending story... Replace battery and life is back ! :)

Legend: Several WSDCGQ11LM (temperature/humidity sensor) end of life in similar environment.

Most sensors have an end-of-life voltage that follows a logarithmic curve that accelerates until the battery dies, but some have a voltage that drops suddenly before the battery is dead.
For the same type of device, the minimum voltage before the battery dies varies considerably.
In addition, the environment seems to have an impact, particularly temperature, which clearly modifies the voltage like an offset, but also humidity, which seems to reduce the discharge rate without changing the voltage too much.

In short, I agree with @Wikibear and @johannes-z, the battery percentage is just an indicator and it's better to rely on another strategy for replacing batteries. Personally, I always have spare batteries ready to use and I get an alert if I don't have any reports from a device within 2 hours. The Aqara sensors send at least one report per hour. For me that's more than enough and the batteries are fully used.

If I wanted to guarantee continuity of service for a sensor by replacing the battery before it died, I'd look at the voltage derivative or, more simply, I'd trigger an alert if the voltage dropped by more than a certain delta over a certain period of time.

And if it's really important, all you have to do is observe the discharge time in general per type of device and change the battery regularly according to how long it's been in use.

I also agree, but it's maybe not the best solution.

Making an automation based on the percentage is way way easier to understand for non power users.

Looking at derivative, delta, or making an automation based on the last time a device reported are already an advanced way of doing things imo.

A simple user will probably never think like that.

That's why I think that we need to have a "reliable" percentage. Maybe it's ok that limits (0 and 100%) are rounded or faked, because anyway having a device close to die is the same has being dead: it's time to changes batteries.

@zen2 it's also just a linear calculation, z2m uses 2850 <-> 3000, while ZHA uses 2820 <-> 3100. If that's better, we can easily change to that.

I gave it a shot. This conversion is based on battery manufacturer specs on how much energy is left depending on the voltage.

However, this also depends on the temperature - which, well is available here, but I don't want to go down this rabbit hole ;)

The different voltages are somewhat non-linear, so I converted it somewhat non-linear. It should show 90% or higher for a full battery, depending on the ambient temperature and how old the battery stock is.

I think that's a good compromise.

This however also doesn't take into account that some devices have a pretty high minimum voltage which they will operate on, like @zen2 showed for the WSDCGQ11LM which seems to be around 2.8 V.

Usually, you would expect that the devices can at least run the battery down to 2.6 V, which is why this is shown as 0% in the conversion.