🔋 (Xiaomi) Batteries values are questionable

[andriej]

What happened

My few-years-old door window's sensor from Xiaomi died. With it's battery value until the last day reported at 100%.

What did you expect to happen

To see battery value more-real, probably like values from Xiaomi Gateway.

Was waiting with this report, but I have to admit - there's an issue with battery reporting/gathering in z2m. Before I've moved to z2m I had most of the sensors I have now conencted to Aqara gateways - each of them was reporting their value getting lower and lower, was much easier to see which sensors had around 40% and which 60-70. Right now it's total guess game.

What could be the reason behind it? I know the value of voltage is reported - but it doesn't change during the time pass - the sensor died had the same 'voltage' report as all other sensors have - 3035 mV. So it's purely wrong information. What Aqara gateway does differently? May it be Xiaomi-specific handling for implementation? I hope the discussion starts and z2m will get even better - currently it's the last struggle I have with my installation, everything else works just fine

How to reproduce it (minimal and precise)

Just look at list of all door-sensors I have since few years. Can't see or even guess when they willl die, before 'availability' kicks in :/

Debug info

Zigbee2MQTT version: 1.21.0-4 Adapter hardware: CC2652P zStack3x0 Adapter firmware version: 20210708

[andriej]

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...

[Shred99]

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.

[andriej]

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.

[McGiverGim]

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%.

[andriej]

@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)

[McGiverGim]

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.

[andriej]

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: https://github.com/home-assistant/core/issues/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% ;-)

[Koenkk]

@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.

[andriej]

@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.

[rindlerblabla]

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%.

[McGiverGim]

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.

[github-actions[bot]]

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

[andriej]

Still valid I guess

[zen2]

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

[ristomatti]

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.

[github-actions[bot]]

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

[andriej]

Still valid

[McGiverGim]

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...

[larod241]

Hi,

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

Hope it can help.

[Koenkk]

@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)

[github-actions[bot]]

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

[larod241]

This morning : WSDCGQ11LM stop to work. Last voltage seen : 2965 mV

[McGiverGim]

This morning : WSDCGQ11LM stop to work. Last voltage seen : 2965 mV

I've one with 2845 mV working without problem...

[larod241]

This morning : WSDCGQ11LM stop to work. Last voltage seen : 2965 mV

I've one with 2845 mV working without problem...

I also have sensors that work under this voltage. But, in order to capitalize and succeed in finding an average to define a real average percentage, I note, as requested, the last known voltage when a xiaomi device turns off and the battery needs to be changed.

[verstrepeng]

I got 3 sensor that are working, different voltages: 3025mV reports 100% 2995mV reports 97% 3045mV reports 100% As 100% should be 3100mV (or higher), 3025 should already be lower. We should consider 2800 or lower as dead, new batteries can be at 3200mV, so shouldn't we just make a linear calculation between those values: 2800mv=0% and 3200mV=100% ?

How does ZHA make the calculation, because this was more correct for me.

[larod241]

Hello,

It is not that simple. the actual ascent of the device must be taken into account. And it turns out that often it stops working around 2900mv ... The important thing is to be warned before the sensor stops in order to be able to anticipate the battery change.

This is why there is a "pastebin" link in order to identify the last valuation recorded before the device where down.

[verstrepeng]

Never said it was simple ;-) I just migrates my 2 last aquara sensors from ZHA to Z2M and this time I noted the values, might be helpful... Sensor 1 - ZHA : 66% - Z2M : 100%, 3005mV Sensor 2 - ZHA : 59% - Z2M : 91%, 2985mV Quite big differences, so I think it's very interesting to see how ZHA makes the calculation.

[larod241]

ZHA seems to be close to reality !

[zen2]

I got a Aqara Door/Window Contact sensor (MCCGQ11LM) that stop to communicate few days ago. Last battery info was: 15% | 2655mV

If you want more data, this is the actual status of all my battery based sensors that currently report regularly:

"voltage":2855 "battery":35 Aqara WSDCGQ11LM [Temperature] "voltage":2885 "battery":40 Aqara WSDCGQ11LM [Temperature] "voltage":2895 "battery":41 Aqara WSDCGQ11LM [Temperature] "voltage":2955 "battery":74 Aqara WSDCGQ11LM [Temperature] "voltage":2955 "battery":74 Aqara WSDCGQ11LM [Temperature] "voltage":2955 "battery":74 Aqara WSDCGQ11LM [Temperature] "voltage":2955 "battery":74 Aqara SJCGQ11LM [waterleak] "voltage":2965 "battery":80 Aqara WSDCGQ11LM [Temperature] "voltage":2975 "battery":86 Aqara MCCGQ11LM [Contact] "voltage":2975 "battery":86 Aqara MCCGQ11LM [Contact] "voltage":2975 "battery":86 Aqara MCCGQ11LM [Contact] "voltage":2975 "battery":86 Aqara WSDCGQ11LM [Temperature] "voltage":2975 "battery":86 Aqara WSDCGQ11LM [Temperature] "voltage":2985 "battery":91 Aqara MCCGQ11LM [Contact] "voltage":2985 "battery":91 Aqara MCCGQ11LM [Contact] "voltage":2985 "battery":91 Aqara MCCGQ11LM [Contact] "voltage":2985 "battery":91 Aqara WSDCGQ11LM [Temperature] "voltage":2985 "battery":91 Aqara WSDCGQ11LM [Temperature] "voltage":2995 "battery":97 Aqara MCCGQ11LM [Contact] "voltage":2995 "battery":97 Aqara MCCGQ11LM [Contact] "voltage":2995 "battery":97 Aqara MCCGQ11LM [Contact] "voltage":2995 "battery":97 Aqara MCCGQ11LM [Contact] "voltage":2995 "battery":97 Aqara RTCGQ11LM [motion] "voltage":2995 "battery":97 Aqara RTCGQ11LM [motion] "voltage":2995 "battery":97 Aqara WSDCGQ11LM [Temperature] "voltage":3002 "battery":100 Aqara WXKG01LM [switch] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3005 "battery":100 Aqara RTCGQ11LM [motion] "voltage":3005 "battery":100 Aqara RTCGQ11LM [motion] "voltage":3005 "battery":100 Aqara SJCGQ11LM [waterleak] "voltage":3005 "battery":100 Aqara SJCGQ11LM [waterleak] "voltage":3012 "battery":100 Aqara WXKG01LM [switch] "voltage":3015 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3015 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3015 "battery":100 Aqara RTCGQ11LM [motion] "voltage":3015 "battery":100 Aqara WSDCGQ11LM [Temperature] "voltage":3015 "battery":100 Aqara WSDCGQ11LM [Temperature] "voltage":3025 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3025 "battery":100 Aqara MCCGQ11LM [Contact] "voltage":3025 "battery":100 Aqara RTCGQ11LM [motion] "voltage":3035 "battery":100 Aqara RTCGQ11LM [motion] "voltage":3035 "battery":100 Aqara RTCGQ11LM [motion] "voltage":3075 "battery":100 Aqara WSDCGQ11LM [Temperature]

I don't rely on voltage or battery % to predict batteries failure so I actually rely on last report timestamp. Battery based device report regularly their states. Aqara ones report their states at least once a hour. So if you got no report for 2 hours, you know the battery have died or worst you got a problem on your zigbee network. I think actually it's the best way to detect battery failure.

It's not obvious to translate voltage to battery percent since each device doesn't need same amount of voltage to function. in addition batteries discharge is not linear and is depending on temperature/humidity too. I got a temperature/humidity sensors in a fridge and another one in a wine cave and its reports always lower voltage than similar sensors. So If you want to collect data to make a voltage based correlation you need at least to do it for each kind of device. Collecting temperature/humidity could be great too but difficult since you need another sensor for it.

Actually I use this bash script to report batteries failure:

zigbee-last-report-warning.sh

#!/bin/bash
#
# Display for each device last report time, number of events for the current day,
# seconds elapsed since last report and WARNING tag if no report in last 2 hours
#

z2m_path="/home/zigbee2mqtt/data"
conf="$z2m_path/devices.yaml"
logs="$z2m_path/log.txt"
exclude="light\."
delta_max=7200

now="$(date +%s)"
devices="$(cat "$conf" | grep friendly | cut -d' ' -f4 | grep -vE "$exclude")"
for device in $devices ; do
  list="$(cat $logs | grep "$(date +%F -d "$day").*MQTT publish: topic "\'"zigbee2mqtt/$device"\')"
  count="$(echo -e "$list" | grep -c "^.")"
  last="$(echo -e "$list" | tail -1 | cut -d' ' -f3,4 | cut -d: -f1-3)"
  delta="$(( $now - $(date +%s --date="$last") ))"
  if [ $delta -gt $delta_max ] || [ $delta -lt 0 ]; then
    last="N/A N/A"
    notice="[WARNING]"
  else
    notice=""
  fi
  echo "$last $device $count $delta $notice"
done | sort -n | column -t -N "Date,Time,Device,Events,Elapsed,Alert"

Ouput example:

Date        Time      Device                                 Events  Elapsed  Alert
N/A         N/A       contact.congelateur                    0       42609    [WARNING]
N/A         N/A       switch.1                               0       42609    [WARNING]
2022-01-06  11:01:09  presence.evier                         28      2940
2022-01-06  11:01:51  alarm                                  12      2898
2022-01-06  11:03:16  contact.fenetre_sdb                    13      2813
2022-01-06  11:04:25  contact.porte_entree_buanderie         13      2744
2022-01-06  11:04:32  contact.fenetre_ch_jeux                13      2737
2022-01-06  11:05:04  contact.porte_fenetre_bureau_terrasse  13      2705
2022-01-06  11:05:10  contact.fenetre_cuisine                13      2699
2022-01-06  11:05:28  contact.fenetre_ch_amis                13      2681
2022-01-06  11:05:50  smoke.studio                           12      2659
2022-01-06  11:06:36  contact.porte_sdb                      13      2613
2022-01-06  11:06:37  contact.porte_wc_etage                 29      2612
2022-01-06  11:07:20  contact.fenetre_ch_enfant              13      2569
2022-01-06  11:07:29  contact.porte_ch_amis                  12      2560
2022-01-06  11:09:32  contact.fenetre_bureau                 13      2437
2022-01-06  11:09:36  presence.escalier                      49      2433

You can easily modify it to collect automatically data or make a command based sensor for home assistant.

[thomashogema]

ZHA seems to be close to reality !

When looking into this problem I found a similar issue raised at ZHA (Zigpy) which might help: https://github.com/zigpy/zha-device-handlers/issues/96

Here they resolved the questionable battery values by changing the minimum and maximum voltage levels to 2800 and 3300 respectively in this PR https://github.com/zigpy/zha-device-handlers/pull/174