Aqara Temperature and Humidity Sensor ZCL Configuration Request
Closed this issue · 2 comments
Outline
I'm picking up the topic with my Zigbee temperature/humidity sensor again. It bothers me that there is a C2450 battery installed but still the sensor did not last more than 5 months. I was expecting at least one full year with so much energy. Of course there is the possibility that the battery was already weak but I think that there is another reason for the fast decrease of battery. I'm quite a novice with ZigBee so I would need your help to fix the problem.
First of all, I use the Openhab in version 3.0.1. For my investigation I set up a Zigbee packet sniffer with wireshark and also homeassistant for comparison reasons. It turns out that the Aqara sensor sends updates very frequently which I think is the main root cause for the battery drain. Now I wanted to answer the question of why which is where I would need your help. In the following I'm referring to the wireshark files I've attached at the bottom. The decryption keys for those files are 74:68:F5:D3:F9:61:73:90:37:F4:9F:9B:DA:77:08:4E for the openhab file and 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39 for the homeassistant file.
In the decrypted traffic with openhab, the client joins between packets 8-33. It gets assigned address 0x3bc6. After line 33, the sensor waits 3s and starts sending descriptor response messages (packet 40), without getting a request? The client then waits one more second and sends more request responses to the bridge (packet 49, 54, 58), without getting any request from the bridge? It gets interesting I guess with packet 123, where a configure reporting response it triggered after waiting 30s. I guess this is where the client assumes, that it should operate with default settings which is unfortunately reporting the values every 10s (see packets 182 and 185 respectively).
During a pairing mode with homeassistant as the zigbee bridge, reporting gets configured (packet 79) and it seems that this is compatible with the sensor as the sensor reports as told.
So my question is whether or not I overlooked something? If not, I would by happy to help to tackle that problem. One thing that I couldn't answer myself, was where such reporting configuration data should be stored in Openhab. I thought of a channel, but then a channel for me is something that can change very frequently which is not the case when the sensor only comes back online every let's say 3 minutes. What's your opinion?
Configuration
| Configuration | Description |
|---|---|
| Coordinator used | Ember |
| openHAB version | 3.0.1 |
| Hardware | Raspberry Pi 4 |
Download
You should ensure that the device is kept awake during discovery, and also when the thing is created as this is when the configuration is done.
I'll close this - I think this is just a case of the device needing to be kept awake as outlined above.