For me it helped to manually bind cluster 0x000c (Analog Input) to the Configuration Tool and to configure the reporting interval of cluster 0x000c / attribute 0x0055 to 600/3600 (reportable change is not working though)… this gave me clean readings every 10 minutes.
A warning: Do not update to V0.0.0_0027 - it changes the Simple Descriptor of the device, the clusters 0x0402,0x0405,0x000c are gone and a cluster 0x500 shows up, but can’t be read.
The device is also missing the cluster 0xfcc0 in the descriptor (in V0022 and V0027),
the Aqara Hub does most of the configuration over this cluster.
cluster 0xfcc0 / attribute 0x0114 (display on the device):
bit 1: mg/m³ or ppb (unset, set)
bit 2: temperature °C/°F (unset, set)
I downgraded back to V0022 via deCONZ OTA but now the device display is misaligned (picture shifted up by 4 pixel :-/).
Edit for clarity:
V0022 is Date Code “20200629”
V0026 is Date Code “20210204”
V0027 is Date Code “20211222”
(Cluster 0x0000, Attribute 0x0006)
Start deCONZ in GUI mode, under Panels activate the STD OTAU Plugin.
Open the STD OTAU Tab, there open the OTAU File tab, open the file you downloaded,
set the file version to 0x0000001C and save.
(This is necessary, because the device does not accept lower file version for downgrade)
Go to the OTAU Update Tab, select the file you saved there. Next select the matching device in the list and click on query. Click the button on the device once, so it makes a connection to the coordinator.
Update should start, maybe you need to click on Update to trigger it.
Be aware: It takes a long time to update (~50mins), so have fresh batteries in the device. Also have the device close to the coordinator and disconnect any routers the device maybe connected through.
It lead to two failed updates for me (because the device had a route through a router and there were some ACK errors going on) until it worked.
Got my hands now on a device with V0026 and played around a bit more.
Two more interesting findings:
The first time the 0x000c / 0x0055 is read as data type u16, but deCONZ has it implemented as float.
When reading the reporting configuration, the reportable change does not show up (it is send as 0x1e00 when read).
Writing the reporting configuration changes the device to float, the reportable change is written as 0, so the device only reports in the min interval set … but:
Sending a reportable change of 1106247680 (float value of 30 interpreted as decimal) or 1092616192 (float value of 10 interpreted as decimal), the device reports on value changes > 30 (or 10)…
I guess something is wrong in the deCONZ-gui interpretation/conversion. Trying “30.0” or “30,0” did not lead to success. Entering “30” sends “0x1e000000” but that’s 4.2039e-44, so the device permanently sends in the min interval.
Actual settings for report: min 10, max 300, change: 1092616192 (float: 10)
Will report back later about stability.
Good find. The 0x0055 attribute is defined as float in the Zigbee specification which is shown by default in the deCONZ UI, it switches to another data type after reading because fortunately the datatype is also part of the message and deCONZ does adapt to that, it’s rare but some devices don’t stick to the standard. It would be interesting to have a sniffer log of what the Aqara gateway does to configure the sensor.
Afair, the Aqara M2 Hub does not touch 0x000c at all, most of the configuration goes via the 0xf… clusters. I can provide a pcapng with explanations if that helps. Anything special I may record?
(btw.: the pairing process of TVOC uses a secret shared key I haven’t found yet in the binary, but I could sniff the M2 Hub network key by pairing another device)
It would be cool if you could take some brief notes on what you did so we can follow that afterwards. Always interested to see what Xiaomi actually does there, however, I guess I already reserse engineered quite some parts of it.
Paired a TVOC with 0022 to an Aqara M2 Hub, NWK for the dump is 0x8152af280d6e1ba4594a47e065e633dc. Around Frame 300 I pressed the button on the TVOC once.
Interesting is in packet 55 and 59 the unknown link key and key-load key. Haven’t figured this out yet.
From what I saw, 0xfcc0 / 0x0114 only changed the display on the device, not the values on the endpoints. Will check that out as soon as I am back from overseas.
About stability:
The V0027 is still stable reporting the values in the given parameters range (min/max/change), the V0026 now stopped sending packets at all after 23 days (nothing to be seen on the sniffer either).
First go on your sensor and selected it. Right click with your mouse or Ctrl+E
Second on your DDF Editor change to bronze status and make a hot reload and after you must wait 20-30 minutes and you will see in deCONZ that he take the Air Quality Sensor
Check if you have the binding part in the DDF (I don’t find it on the page)
The binding have probably failed, just wait a little or try to re-include the device.
, I’ll have a look later.
