It's time to fix Aqara battery bug

Do I want to intercept Home Assistant that much? It’s only the head system.

  • 1st stage device firmware: expect nothing :x:
  • 2nd stage zigbee coordinator: next earliest stage possible :heavy_check_mark:
  • 3rd stage smart home system: a bit late :x:

Today one sensor again created those -100 ° values:

The last time the battery was changed was on 2022-04-23. So pretty exactly 8 months of battery life. Interesting:

  • battery was shown as 95 %
  • battery had 2.99 V (measured with a multimeter)!

I’m not into electronics, but 2.99 V is not even close to “empty”, right?


My summary:

  1. Percentage is TOTAL CRAP. Some months ago I adjusted my battery warnings for all Aqara devices to “< 70 %”. Well, see above - even on 95 % this -100 ° bug is triggered. I nowadays tend to say “don’t rely on Aqara battery percentage sensors AT ALL”. Would be great to have the actual voltage instead. I guess this is not exposed from the devices to deCONZ, is it?
  2. For now I see the -100 ° bug as indicator of a “not perfectly well” battery. Not an empty one. There might be days to even weeks (depending on the environment - especially cold areas - and the update intervals) until the battery really dies.
  3. I hope deCONZ can and will do sth. about this to filter those -100 ° values. I will then loose this “indicator” and suffer from Inacceptable huge default "sensor unavailable time" of 24 hours (so I only know about a REALLY dead battery 24 hours after it died), but this will save me about 1 to 1,5 hours per device/incident (because wiping out those -100 ° values from the Home Assistant database takes quite some time!). So in the end: please get rid of those wrong values in deCONZ!

Follow-up on is this confirmed to work? E. g. @Smanar did you write this from the top of your head (theory) or do you use this already?

It sounds like a pretty good approach as it would
a) work immediately (no need to wait for PRs, new updates and their shipment)
b) allow individual users to suppress the -100 ° values by choice.

I’m running the posted SQL Trigger and get the -100 updates now “successfully” trigger SQLExceptions when openhab tries to put them into the database:

java.sql.SQLException: Updates with value -100 are not allowed

So, at least your Nr3 (the hours of work to remove false data from the database) has a workaround.

I never do it with temperature sensor ^^, I don’t have issue on them. But I do that on some power measurement sensor.

The test is fast , if you have 18 degree at home, test this code

"eval": "if (Attr.val > 18) {Item.val = Attr.val;}"

You need to have a line that never decrease under 18

I’m not into electronics, but 2.99 V is not even close to “empty”, right?

Strange you already have the -100 °C issue with this voltage.
On a 12 Volt battery, if you have a 12V tension (without charge connected and battery full charged) it mean the battery is dead.
IDK for this kind of battery and hard to find tests on it, all tests are made with a charge, try to connect a resistance (you can find the value on google) and check again the voltage.

For exemple

But even on this sample, with the minimum 0.5 mA the voltage start a 2.9V (and it can be 3.2V without charge), And I don’t found on google the voltage without charge for used battery.

This one CR2032 Lithium Battery Charge Level Measurement - Uncannier Software with a 15 Kohms charge.

Catching up on the database option according to:

I’m not sure if/how this is working (without massive side effects):

There’s no additional filter next to the table selection.

  1. So no way to specify this should only work for specific data (entities e. g.).
    While -100.0 is unwanted for these Aqara devices, those might be legitimate values for other data in this table.
  2. In addition, it’s now run on EVERY INSERT so it will slow down things.

Talking bout Home Assistant which heavily uses the states table for plenty of other stuff.

So how to further specify this SQL TRIGGER?

Would this work (only excerpt, not full trigger definition)?

   IF (NEW.entity_id = "sensor.aqara_one" OR NEW.entity_id = "sensor.aqara_two")
      IF NEW.value = -100 THEN
      SIGNAL SQLSTATE ‘45000’ SET MESSAGE_TEXT = ‘Updates with value -100 are not allowed’;
      END IF;
   END IF;

Or this one?

   IF NEW.entity_id LIKE "sensor.aqara_%"
      IF NEW.value = -100 THEN
      SIGNAL SQLSTATE ‘45000’ SET MESSAGE_TEXT = ‘Updates with value -100 are not allowed’;
      END IF;
   END IF;

First, I don’t know about HA.
Openhab sql persistance works by having a table per item and inserting values on every change or every update for this item into this table.
I added this trigger and since the trigger rule in SQL database is attached to this table it only fires when this item gets a new INSERT. All other operations like SELECTS for graphs or INSERTS on other tables/items are exactly as before.
I do not see any side effects although I might just not be looking at the right things :wink:

Edit: I completely forgot about this topic since it works flawlessly. Just checked and I got 270 updates of -100 from 1170 updates in the last 6 days. The temperature is reported perfectly when you ask me and I’m not replacing an obviously fine working battery because some think reporting -100 degrees makes any sense anywhere for anyone.

That’s impressive. Exactly what’s in my mind. Today another sensor sent -100 degree value, battery was shown as 98 % and had 2.98 V…

I want to achieve the same but I try to do so in deCONZ. The database thing is quite dangerous, especially as Home Assistant’s database structure is completely different so adjustment is key.

I’ll likely

  1. give It's time to fix Aqara battery bug - #14 by Smanar a chance as it blocks values from even being written to the (HA) database and
  2. afterwards probably need to live with Inacceptable huge default "sensor unavailable time" of 24 hours (choose your pain: annoying -100 degree bug or loosing up to 24 hours of data because deCONZ does not ping for battery status more often).

For now I choose the second pill cause it does not produce additional work for me. Flat line is better than spending 1 to 1,5 hours for fixing database stuff every few days/weeks.

I have also had this problem with -100℃ readings but I only noticed it in the last couple of months after a deCONZsoftware upgrade. Constantly replacing working batteries has gotten old by now so I started to dig a bit into the matter.

It turns out that deCONZ used to filter out this bad value but that workaround was removed about a year ago when a DDF was added.

Working with DDF is very new to me so maybe the following can be improved. But I located the file xiaomi/xiaomi_wsdcgq11lm_temp_hum_press_sensor.json and added the parse section from generic/items/state_temperature_item.json, modified with an if as @Smanar suggested (the value is actually the temperature multiplied by 100):

--- xiaomi_wsdcgq11lm_temp_hum_press_sensor.json
+++ xiaomi_wsdcgq11lm_temp_hum_press_sensor.json
@@ -168,6 +168,13 @@
           "name": "state/lastupdated"
+          "parse": {
+            "at": "0x0000",
+            "cl": "0x0402",
+            "ep": 0,
+            "eval": "if (Attr.val + R.item('config/offset').val != -10000) {Item.val = Attr.val + R.item('config/offset').val}",
+            "fn": "zcl"
+          },
           "name": "state/temperature"

The full file is here:

(I mount the modified file in my Docker container with

-v ./xiaomi_wsdcgq11lm_temp_hum_press_sensor.json:/usr/share/deCONZ/devices/xiaomi/xiaomi_wsdcgq11lm_temp_hum_press_sensor.json

but that will vary based on installation method.)

This works for me; the bad readings are gone and my batteries will now hopefully last as long as they used to.

I noticed that there is a different Xiaomi -100 fixup still left in the deCONZ code so maybe the above change is actually acceptable and could be added to the official version.

1 Like

Oh WOW! That’s a load of helpful information! :tada::tada::tada:

Hopefully I can manage to make this DDF hack work too at the weekend as a workaround, can’t wait to test this (first by using a current real life value of one sensor to check if it works).

So there already was a permanent solution and parts of it is still there!? Indeed I did not see this issue right from the beginning. Would need to check my update and incident logs but definitely somewhere in 2022. Before I ran into the „battery died silently“ case because of the once per 24 hours battery state reporting behavior.

…so: what is caused by code can be fixed by code, right. @Mimiix do you see a window of opportunity to re-add that validation check/filter, e. g. by providing an updated DDF containing that fix, shipped as default (next deCONZ update)? That would re-solve this issue for everyone.

I think @amelchio provided all needed information to get this started.


I’d suggest creating a Pull Request with the change on Github. Everyone is able to do so.

If it’s created, i’ll ask Manup to put it on top of the list :slight_smile:

1 Like

PR created: Ignore invalid Aqara -100 temperature by amelchio · Pull Request #6723 · dresden-elektronik/deconz-rest-plugin · GitHub


Pinged manup :slight_smile:

1 Like

Great :tada::partying_face:

I’m gonna create a custom DDF with the content of Ignore invalid Aqara -100 temperature by amelchio · Pull Request #6723 · dresden-elektronik/deconz-rest-plugin · GitHub for now and will monitor closely when this PR will make it into a stable release (probably gonna take a few weeks to months).

Just to make sure: this PR is about Aqara Temperature, Humidity and Pressure Sensor WSDCGQ11LM Zigbee compatibility

Not sure if we always talked about the same device (I only have and use the linked WSDCGQ11LM /, but there seem to be other models too like Aqara Temperature, Humidity and Pressure Sensor T1 WSDCGQ12LM Zigbee compatibility (newer T1 model, the successor), just to mention.

It should only be done by devices which have the faulty firmware.

PR is merged :slight_smile: hope it fixes this. Thanks for the effort @bcutter and @amelchio

1 Like

I updated to the latest stable release v2.21.2 more than two weeks ago.

After that I removed my custom DDF as it is not needed anymore.

I noticed, since then battery values are not updated anymore at all: not in Home Assistant and not in Phoscon.

All other values (temperature, pressure, humidity) are updated regularly in HA.

If I today select „Edit DDF“ in deCONZ on one of the affected multi sensor nodes, the opened GUI still references the former custom DDF - which is deleted and not available anymore. That sounds like a proper reason for the missing battery value updates, right?

Much more interesting: how to fix this?

I already performed a „hot reload“ from the Edit DDF GUI. No change.

You mean for the device “”, the battery level is not updated ?
If I m right it’s updated every hour with the periodic report ?

For information, IDK what you are doing with DDF, but deconz load DDF only at start, so if you delete it after deconz running, it will be not updated.

Yes, it does not change. For none of those devices (while all others including Aqara do). Even for one or two I replaced the battery meanwhile.

OK thanks. I‘m gonna try reloading the deCONZ addon/container and see if it changes something.

It does not change, but what is the actual value ? 0 ? (and the previous one)
On my side I have one with a 92% value.

Remember the value used is taken from the periodic report, not the value you can see in the GUI (and idk if this one is good)

          "name": "config/battery",
          "parse": {"fn": "xiaomi:special", "at": "0xff01", "idx": "0x01", "script": "xiaomi_battery.js"}

The values differ (e. g. 88 %, 72 % etc.) but they are frozen (not changing) for at least two weeks.

Reloaded deCONZ now (which by the way also brought new diagnostics entity „duration“ for the Aqara motion sensors) and I will monitor battery values the next days.

At least when now selecting „Edit DDF“ the default DDF opens. A good sign.

All sensors got battery value updates meanwhile. Restarting deCONZ to get rid of a deleted DDF seems to have done the trick.