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:
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?
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.
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!
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.
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.
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.
I’m not sure if/how this is working (without massive side effects):
There’s no additional filter next to the table selection.
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.
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)?
BEGIN
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;
END;
Or this one?
BEGIN
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;
END;
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
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.
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):
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.
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 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.
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.
