# It's time to fix Aqara battery bug **URL:** \ **Category:** General Support\ **Created:** [August 24, 2022, 8:15pm UTC](https://forum.phoscon.de/t/its-time-to-fix-aqara-battery-bug/2368 "2022-08-24T20:15:03Z")\ **Posts on this page:** 1\ **Showing post:** 59
**Author:** ![bcutter](https://forum.phoscon.de/user_avatar/forum.phoscon.de/bcutter/32/599_2.png) [@bcutter](https://forum.phoscon.de/u/bcutter)\ **Post date:** [February 4, 2024, 7:52pm UTC](https://forum.phoscon.de/t/its-time-to-fix-aqara-battery-bug/2368/59 "2024-02-04T19:52:49Z")
Managed to implement it. Unfortunately, instantly after the new DDF started working, Home Assistant reported that few entities (illuminance and battery) of two sensors became unavailable. I checked and compared them. These (firmware \*21) are working just fine - no change (so far): ![grafik](https://forum.phoscon.de/uploads/default/original/2X/5/5cc1dbc3afc4108bbddd7e3a76cbafa9eaeed25e.png) But these became unavailable (firmware \*27): ![grafik](https://forum.phoscon.de/uploads/default/original/2X/f/fa014238c52958fe46e7579636fa076211657c2d.png) Update: 1 out of 2 devices (firmware \*27) still with `unavailable` entities, the other one recovered within minutes. What the…? 1. Any idea? 2. Maybe those devices that would have a battery value of 0 (zero) now will be shown as `unavailable` due to the changed DDF? Or shall they keep the last value they had? Reading of `0001 Power Configuration` cluster: ![grafik](https://forum.phoscon.de/uploads/default/original/2X/8/819a6b8a71e30653d7fd2f58827cee57ce8e0418.jpeg) And this is the deconz API output: ```auto "107": { "config": { "battery": 100, "on": true, "reachable": false, "tholddark": 12000, "tholdoffset": 7000 }, "ep": 1, "etag": " ***REMOVED***", "lastannounced": null, "lastseen": "2024-02-04T19:30Z", "manufacturername": "XIAOMI", "modelid": "lumi.sen_ill.mgl01", "name": "Lichtsensor ***REMOVED***", "state": { "dark": false, "daylight": false, "lastupdated": "2023-12-30T19:15:16.375", "lightlevel": 0, "lux": 0 }, "swversion": "0.0.0_0027", "type": "ZHALightLevel", "uniqueid": " ***REMOVED***" }, ``` That ` "reachable": false,` looks suspicious to me… * * * Update: - No it’s not suspicious, same for all light sensors not currently triggered. - After I triggered a value change for the remaining light sensor, its entities came back online. Theory: after changing the DDF, the `*27` firmware powered light sensors need some kind of trigger/interaction to push their new values. I think the DDF change made them “reset” somehow. Not into that inner processes of deCONZ, so just assumptions… ⚠⚠⚠ **Latest remaining issue: all values don’t update anymore… meaning that illuminance is stuck on the value prior to the DDF swapping…** ⚠⚠⚠ Why does that stuff need to be that complicated… 👿 @Smanar I tested with several sensors: value `"lux": 18` does not update anymore according to the API. What can I do to resolve this? > **My DDF looks like this (only the battery part changed, put in in the \`/data/.local/share/dresden-elektronik/deCONZ/devices/\` folder and hit "hot reload" in the deCONZ DDF editor):** > > ```auto > { > "schema": "devcap1.schema.json", > "doc:path": "xiaomi/xiaomi_gzcgq01lm_light_sensor.md", > "doc:hdr": "Light sensor GZCGQ01LM", > "manufacturername": ["$MF_XIAOMI", "$MF_LUMI"], > "modelid": ["lumi.sen_ill.mgl01", "lumi.sen_ill.mgl01"], > "vendor": "Xiaomi", > "product": "Mijia Light Sensor GZCGQ01LM", > "status": "Gold", > "md:known_issues": [], > "sleeper": true, > "subdevices": [ > { > "type": "$TYPE_LIGHT_LEVEL_SENSOR", > "restapi": "/sensors", > "uuid": [ > "$address.ext", > "0x01", > "0x0400" > ], > "fingerprint": { > "profile": "0x0104", > "device": "0x0106", > "endpoint": "0x01", > "in": [ > "0x0001", > "0x0400" > ] > }, > "items": [ > { > "name": "attr/lastseen" > }, > { > "name": "attr/manufacturername" > }, > { > "name": "attr/modelid", > "awake": true > }, > { > "name": "attr/name" > }, > { > "name": "attr/swversion", > "awake": true, > "parse": { > "at": "0x00f7", > "ep": 1, > "fn": "xiaomi:special", > "idx": "0x08", > "script": "xiaomi_swversion.js" > }, > "read": { > "fn": "none" > } > }, > { > "name": "attr/type" > }, > { > "name": "attr/uniqueid" > }, > { > "name": "config/on" > }, > { > "name": "config/battery", > "awake": true, > "parse": { > "at": "0x00f7", > "ep": 1, > "fn": "xiaomi:special", > "idx": "0x01", > "eval": "const vmin = 2700; const vmax = 3000; const v = Math.max(vmin, Math.min(Attr.val, vmax)); const bat = Math.round(((v - vmin) / (vmax - vmin)) * 100); if (bat>0){Item.val = Math.max(0, Math.min(bat, 100));}" > } > }, > { > "name": "config/reachable" > }, > { > "name": "config/tholddark" > }, > { > "name": "config/tholdoffset" > }, > { > "name": "state/lightlevel", > "parse": { > "at": "0x0000", > "cl": "0x0400", > "ep": 1, > "script": "../generic/illuminance_cluster/sml_light_level.js" > } > }, > { > "name": "state/dark" > }, > { > "name": "state/daylight" > }, > { > "name": "state/lux" > }, > { > "name": "state/lastupdated" > } > ], > "example": { > "config": { > "battery": 100, > "on": true, > "reachable": true, > "tholddark": 12000, > "tholdoffset": 7000 > }, > "ep": 1, > "etag": "761fff5a33ee73a8b9e4ec2e8ee5dac2", > "lastseen": "2021-01-13T12:07Z", > "manufacturername": "XIAOMI", > "modelid": "lumi.sen_ill.mgl01", > "name": "Light Sensor", > "state": { > "dark": false, > "daylight": false, > "lastupdated": "2021-01-13T12:07:27.511", > "lightlevel": 13425, > "lux": 22 > }, > "swversion": "0.0.0_0027", > "type": "ZHALightLevel", > "uniqueid": "04:cf:8c:df:3c:7f:1f:80-01-0400" > } > } > ], > "bindings": [ > { > "bind": "unicast", > "src.ep": 1, > "cl": "0x0400", > "report": [ > { > "at": "0x0000", > "dt": "0x21", > "min": 10, > "max": 3600, > "change": "0x0064" > } > ] > } > ] > } > > ``` I think it might be because of the changed location… - HA deCONZ addon default DDF storage: `/usr/share/deCONZ/devices/xiaomi/` - HA deCONZ addon custom user DDF storage: `/data/.local/share/dresden-elektronik/deCONZ/devices/` And I think the path to the light level script… ```auto { "name": "state/lightlevel", "parse": { "at": "0x0000", "cl": "0x0400", "ep": 1, "script": "../generic/illuminance_cluster/sml_light_level.js" } ``` as well as the swversion script… ```auto { "name": "attr/swversion", "awake": true, "parse": { "at": "0x00f7", "ep": 1, "fn": "xiaomi:special", "idx": "0x08", "script": "xiaomi_swversion.js" }, ``` can not be found anymore now. So: a) source them in, too? b) change paths? relative would be difficult, not sure if absolute ones would work? * * * Another update: fixed now. I copied all the (only two) referenced `*.js` files also to the persistent custom DDF storage (`/data/.local/share/dresden-elektronik/deCONZ/devices/` for HA deCONZ addon/container). Some inconsistent fiddling around with “Edit DDF”, edit another one, open the custom one again etc. together with several “Hot reload” magic in between… finally made it work. **Values report back via API and are shipped to Home Assistant. ✅** _That’s when just a small workaround either makes your smart home stop working or takes two hours of your time. Always fun to work with deCONZ, DDFs and stuff._ Note: absolute paths did **NOT work** (even the addon should be able to find the files… really strange). Maybe the DDFs only work with relative paths (as used in the default)? **Would be really interesting to know!** --- _[View the full topic](https://forum.phoscon.de/t/its-time-to-fix-aqara-battery-bug/2368)._