search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 496 forks source link

Xiaomi Door/Window Sensor Battery state not reported #1069

Closed peer69 closed 5 years ago

peer69 commented 5 years ago

This is an issue i have found but no viable solution to this. The reporting of open/closed works fine which seems to be odd if you look at the screenshots from the GUI below:

Version info:

image

Problem is battery status is not reported and not shown in Phoscon GUI for door sensor:

image

In the GUI the Basic Cluster shows nothing:

image

Only two clusters are shown at all:

image

Node Info:

image

Power Source should probably be set to "battery" but it's "Mains" in my case which might be the problem. But I don't know how to change this and how this info got mixed up in the first place.

I've tried to fill in a value for battery to at least get rid of "low battery"-warnings in homekit when using homebridge-hue but this doesnt work either:

image image

Any solution to this? I've already tried waiting for the hourly(?) reporting for battery information for some days, deleting and re-pairing the sensor and restarting deconz. I've even purged the sensor from the zll.db database file and re-paired it afterwards, nothing brought back the battery info and info shown in GUI remained the same.

manup commented 5 years ago

Which modelid has the sensor?

Normally battery state should be available after the hourly report is received.

However it looks like there are differences between older Mi vs. new Aqara version of this device.

peer69 commented 5 years ago

Not sure about the model id, do you mean the value for model in the node list?

image
manup commented 5 years ago

Yes this is the modelid. I guess this is the old Xiaomi Mi version of the sensor. I've the Aqara version which has the modelid lumi.sensor_magnet.aq2.

So the question is if the Mi version also sends the battery state somehow.

If possible can you please start deCONZ in a terminal with the following options:

deCONZ --dbg-info=1 --dbg-zcl=1 --dbg-aps=2 --http-port=80 > log.txt

Let this run for two hours. With the log we can check what the sensor reports.

peer69 commented 5 years ago

I'll let it run for two hours from now. Does the log contain any sensitive information which I should remove? How can I send the file to you?

manup commented 5 years ago

Does the log contain any sensitive information which I should remove?

It contains mac addresses of all devices but otherwise no sensitive data.

How can I send the file to you?

Either you drop it here as upload, or via mail to mpi@dresden-elektronik.de

peer69 commented 5 years ago

Attached you can find the log. Ended up with a bit more data than expected, had the wrong window in focus while hitting delete and accidentally deleted the node and let it run for another two hours. Readded it afterwards so you have a repairing in the logs as well. Hope there is any useful information regarding the battery issue. log.txt.zip

manup commented 5 years ago

Thanks that helps, I've found one new promising command which isn't supported yet.

@ebaauw currently we handle only special report 0xff01, looks like this is a new version of it. Same data but different structure. I'll add some code to support this as well.

Magic Report Xiaomi attribute 0xff02

17:01:39:252 APS-DATA.indication srcAddr: 0x00158d0002c6687b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 143, rssi: -73
17:01:39:252    asdu: 1c3412020a02ff4c0600100121d10b21a801240000000000216e002050

1c frame control: server to client, disable default response, manufacturer code
3412 manufacturer code (0x1234)
02 seq
0a cmd ZclReportAttributesId

02ff attribute id
4c attribute type: structure
0600 number of elements
10 bool
01

21 unsigned 16-bit
d10b

21 unsigned 16-bit
a801

24 unsigned 40-bit
0000000000

21 unsigned 16-bit
6e00

20 unsigned 8-bit
50
manup commented 5 years ago

@peer69 one question: is the sensor located in a cold area? Trying to make sense of the 0x01a8 (424) value, might be temperature 4.24°C.

peer69 commented 5 years ago

No. It’s been located on my desk at room temperature all the time during log recording.

manup commented 5 years ago

Ok, will skip this attribute for now and just extract battery and open/close state.

ebaauw commented 5 years ago

Interesting. I haven’t come across this attribute, but I don’t have any non-Aqara Xioami devices. This one doesn’t contain any tags? And yet another manufacturer code?

Checking my notes, my lumi.magnet.aq1 sensors report:

                                            1                       2
                     1 2  3 4  5 6  7  8 9  0 1  2 3  4 5  6 7  8 9 0 1 2  3 4  5 6  7 8  9
         attr tp  l   battery    temp             RSSI dB             LQI                On
         ---- -- -- --------- ------- --------- --------- --------------- --------- -------
door:    01ff 42 1d 0121 d10b 0328 15 0421 a813 0521 a200 0624 0300000000 0a21 0000 6410 00
                 29    3.025V                                                        closed
door:    01ff 42 1d 0121 db0b 0328 14 0421 a843 0521 9a00 0624 0100000000 0a21 c841 6410 00
                 29    3.025V                                                        closed
door:    01ff 42 1d 0121 bd0b 0328 15 0421 a833 0521 3b00 0624 0100000000 0a21 9ff8 6410 00
                 29    3.025V                                                        closed
door:    01ff 42 1d 0121 c70b 0328 13 0421 a813 0521 9200 0624 0100000000 0a21 c96b 6410 00
                 29    3.015V                                                        closed

Trying to match the types and values, I’d guess the first element seems to be the Open/Close state, the second the battery voltage, the fourth the LQI, the fifth the RSSI dB. No clue about the third and last elements.

manup commented 5 years ago

Just received my WXKG01LM (Xiaomi Mi round button switch) today. It also reports the 0xff02 attribute with manufacturer code 0x1234.

Will dig a bit deeper into the sniffer log now.

peer69 commented 5 years ago

Can you recommend a safe way to completely remove the device from the database? I thought I had purged it from the zll.db file but the sensor still appears magically in the deconz-gui after some minutes (deleting via deconz-gui again didnt help, I restarted the gateway after deleting). Its not visible via REST-API anymore.
I assume that the battery status is fixed in 2.05.54 as the release notes indicate, but I still cant get the device to report the battery status. It looks just as before after deleting via the web interface / and or deleting all traces I could find in the zll.db database and readding the sensor. I might be missing something in the db-file which causes this resurrection.

image
manup commented 5 years ago

Can you recommend a safe way to completely remove the device from the database? I thought I had purged it from the zll.db file but the sensor still appears magically in the deconz-gui after some minutes (deleting via deconz-gui again didnt help, I restarted the gateway after deleting).

deCONZ will show all nodes which are somehow transmitting in the network.

I assume that the battery status is fixed in 2.05.54 as the release notes indicate, but I still cant get the device to report the battery status. It looks just as before after deleting via the web interface / and or deleting all traces I could find in the zll.db database and readding the sensor. I might be missing something in the db-file which causes this resurrection.

How long was 2.05.54 running? It may take up to 1 hour until the report is received.

peer69 commented 5 years ago

It’s running for about 14 hrs now. So this shouldnt be an issue. If the sensor is still transmitting to the network i might have not been able to reset it completely. I will try again with first resetting the device and deleting it from the dB afterwards. Is there anything I can look for in the logs to make sure the battery status is reported by the device as it should?

I have received the Aqara version of the sensor today. It shows the battery status right after pairing.

manup commented 5 years ago

It’s running for about 14 hrs now. So this shouldnt be an issue. If the sensor is still transmitting to the network i might have not been able to reset it completely. I will try again with first resetting the device and deleting it from the dB afterwards.

To reset the sensor it should be enough to press the small button until the LED blinks.

Is there anything I can look for in the logs to make sure the battery status is reported by the device as it should?

The logs should show something like this (with mac address of the sensor):

07:58:48:255 0x00158D00028A97C2 extract Xiaomi special attribute 0xFF02
07:58:48:255    64 on/off 1
07:58:48:255    01 battery 3122 (0x0C32)
07:58:48:255    03 unsupported index (data type 0x21)
07:58:48:255    04 unsupported index (data type 0x24)
07:58:48:255    05 unsupported index (data type 0x21)
07:58:48:255    06 unsupported index (data type 0x20)
peer69 commented 5 years ago

I have done the procedure again, deleted the sensor from Phoscon and deCONZ GUI, cleaned the db file afterwards. I then added the sensor once again via Phoscon and battery status appeared immediately. Don't know what fixed it for me but now it all works as expected.

Thanks for your great work! :)