Xiaomi Mi Temperature / Humidity Sensor

[NisseDILLIGAF]

Hi... Is it hard to get Xiaomi Temp/Humidity sensor to work? I've looked att the code... but I don't know where to start... My C++ Isn't that good... I guess I have to add it in 'de_web_plugin.cpp' and 'sensor.cpp'? it's added to deCONZ... http://imgur.com/a/TwUvH

I've found this in the SmartThings forum... maybe some help? https://community.smartthings.com/t/xiaomi-zigbee-door-window-sensor-motion-sensor-smart-button-device-type-beta/31948/144

Data comes in as Parsing 'read attr - raw: 5C14010000240500420E6C756D692E73656E736F725F6874, dni: 5C14, endpoint: 01, cluster: 0000, size: 24, attrId: 0005, encoding: 42, value: 6C756D692E73656E736F725F6874' Update: Updated log Parsing 'humidity: 41.73%' Parsing 'temperature: 27.24'

[wizkidorg]

Same here. Having issues getting device to Pair, and when it does pair no clusters appear. In smart things it is active until the device sleeps then is lost.

Looking for a way to export RAW zigbee data from the deCONZ software (such as clusters device is reporting, etc.)

[manup]

Hi for the first step I've added the missing sensor clusters 0x000c and 0x0012 to the ZCLDB general.xml file (part of deCONZ). Can you please update your general.xml and check if the sensors will provide any meaningful values in the cluster info panel.

Updated general.xml: https://gist.github.com/manup/d5e81c349df0cf4d82eadd9689211d60

Do the lack of the sensors I can't test it here. Further I haven't found the device ids 0x5f01, 0x5f02 and 0x5f03 in the specs yet.

[NisseDILLIGAF]

Thanx for taking the time to look into it...

0x0012 Number of states: 6 Out of service: false Present value: 0 Status flags: 0x00

0x000c: Out of service: false Precent value: 0.00 Status flags: 0x00

[NisseDILLIGAF]

maybe this can help? But if I'm understanding this right, my sensor doesn't have these device id and clusters? https://github.com/ericleu/xiaomi/blob/ca625869bf62b52c27276a5af7a5dbebfdaee142/devicetypes/a4refillpad/xiaomi-temperature-hunidity-sensor.src/xiaomi-temperature-humidity-sensor.groovy

edit: I get this in debug when i press the button

00:11:17:539 APS-DATA.indication srcAddr: 0x00158d0001597b01, dstAddrMode: 2, profile: 0x0104, cluster: 0x0003, lqi: 255, rssi: -33
00:11:28:005 APS-DATA.indication srcAddr: 0x00158d0001597b01, dstAddrMode: 2, profile: 0x0104, cluster: 0x0402, lqi: 255, rssi: -52
00:11:28:031 APS-DATA.indication srcAddr: 0x00158d0001597b01, dstAddrMode: 2, profile: 0x0104, cluster: 0x0405, lqi: 255, rssi: -51

edit2: I added useZcl="false" on <domain name="Measurement and sensing" and I got Temp and humidity, but no values... I guess the 'attribute id' is wrong....

[wizkidorg]

When I updated the general.xml, in the deCONZ UI on my RaspberryPI there is no clusters displayed. (the radio button is missing). It looks like its not responding with the Basic Clusters. I have used the smartthings configuration posted above but when the device goes to sleep it becomes non-responsive until its repaired. I have a batch of 10 of these and they all do the same.

Attached are screen shots of the deCONZ app UI

[NisseDILLIGAF]

I've got values! :) Add this file in preferences, under general.xml https://gist.github.com/NisseDILLIGAF/8c40a6e44057344b6225857c3817c60c I get values like 9496 (have to figure out how to get that to temp)

I guess I'm not doing this the right way, because I'm using command... any suggestions are welcome.. :) The sensor reports values by itself when I get it warmer or colder..

edit1: attribute id 0003, I get a hex value that i convert to decimal and divide by 100, and there is temp and humidity :)

[NisseDILLIGAF]

So I've been trying to wrap my head around the rest plugin code. I'm guessing the sensor doesn't get recognized because I have to set useZcl="false" in deCONZ general.xml

How do I handle non Zcl sensors in rest code? I get 0x0000 from zclFrame.manufacturerCode() when I guess it should be 0x1037 Is it in apsdeDataIndication? (de_web_plugin.cpp) or handleIndicationFindSensors (rest_sensors.cpp) I also get stuck in findSensorsState != FindSensorsActive or am I just completely lost...? ;)

In deCONZ its recognized as Measurement and sensing, cluster 0402 and 0405. Model Identifier: lumi.sensor_ht Manufacturer Code: 0x1037 Thanx!

[NisseDILLIGAF]

I know I shouldn't bump, but I'm just stuck... any help or point in right direction would help... My main question now is how do I handle useZcl="false"(as I did in deCONZ) in the rest plugin code. I think it's where I have to start to get the rest plugin to recognize the sensor.

[manup]

Hi, bump is totally fine, I sometimes miss the posts. I think the deactivation of ZCL is not needed here, are you sure that the sensor is not a ZCL based one?

The main problem I see in the screenshot are the missing queried endpoints (only one dot instead of two in the ui node). For sleeping devices like sensors these should be queried directly after joining the network. Can you pleaser try to put deCONZ in sensor search mode and then pull out battery and pull it in agin after a few secs — deCONZ tries to query the endpoints after receiving the join notification (device announce)

[NisseDILLIGAF]

Thanx for answering... I think you are talking about wizkidorg problem... I'm getting Temp and humidity in deCONZ (hex value), but not in REST plugin...

[manup]

Sorry my bad, looked at the wrong screenshot. The sensor is not in the whitelist yet, and also the more generic clusters for sensor values must be supported.

During the next days I'm working on support for another humidity sensor I'll add the LUMI one thereby. Can you please provide a screenshot with queried values of a 000C and 0012 cluster?

[NisseDILLIGAF]

I've written the values of 000C and 0012cluster in the 4th post in this thread...

0x0012
Number of states: 6
Out of service: false
Present value: 0
Status flags: 0x00

0x000c:
Out of service: false
Precent value: 0.00
Status flags: 0x00

I've also added in de_web_plugin.cpp

static const SupportedDevice supportedDevices[] = {
...
    { VENDOR_XIAOMI, "lumi.sensor_ht"},
    { 0, 0 }
};

and in de_web_plugin_private.h #define VENDOR_XIAOMI 0x1037

I get values in deCONZ if I set general.xml like this https://gist.github.com/NisseDILLIGAF/8c40a6e44057344b6225857c3817c60c

let me know if there is anything else I can try... :)

[wizkidorg]

I was finally able to get it to pair properly.. I had to actually rebuild the raspberrypi image, and deconz applications, etc. So may have been something from a previous build.

I am having same issue now as Nisse where the REST api doesn't report any data, i am using your build that you committed a few hours ago for the humidity sensor, and there is no state data.

The state response is blank.

(BTW I'm using Powershell to pull the RestAPI): /sensors/1 config : @{on=True; reachable=True} ep : 1 etag : a2a89c5e9ead54ed65aafc2086efadaf mode : 1 modelid : lumi.sensor_ht name : lumi.sensor_ht 1 state : type : ZHASwitch uniqueid : 00:15:8d:00:01:2c:ac:80-01

/sensors/2 config : @{on=True; reachable=True} ep : 1 etag : a2a89c5e9ead54ed65aafc2086efadaf modelid : lumi.sensor_ht name : ZHATemperature 2 state : type : ZHATemperature uniqueid : 00:15:8d:00:01:2c:ac:80-01-0402

This is /sensors/3 config : @{on=True; reachable=True} ep : 1 etag : a2a89c5e9ead54ed65aafc2086efadaf modelid : lumi.sensor_ht name : ZHAHumidity 3 state : type : ZHAHumidity uniqueid : 00:15:8d:00:01:2c:ac:80-01-0405

Not sure if it helps.

[manup]

Heyo, just ordered one out of curiosity, due oversea shipping it takes 14-21 days though :(

I'm confused since the clusters in the screenshot 000C and 0012 don't match the debug print clusters 0402 and 0405.

edit: I get this in debug when i press the button

00:11:17:539 APS-DATA.indication srcAddr: 0x00158d0001597b01, dstAddrMode: 2, profile: 0x0104, cluster: 0x0003, lqi: 255, rssi: -33 00:11:28:005 APS-DATA.indication srcAddr: 0x00158d0001597b01, dstAddrMode: 2, profile: 0x0104, cluster: 0x0402, lqi: 255, rssi: -52 00:11:28:031 APS-DATA.indication srcAddr: 0x00158d0001597b01, dstAddrMode: 2, profile: 0x0104, cluster: 0x0405, lqi: 255, rssi: -51

and the clusters in @wizkidorg last post

vs

0x0012 Number of states: 6 Out of service: false Present value: 0 Status flags: 0x00

0x000c: Out of service: false Precent value: 0.00 Status flags: 0x00

It seems that we have different devices here?

The following looks good, since the sensor is created based on the humidity cluster 0x0405:

This is /sensors/3 config : @{on=True; reachable=True} ep : 1 etag : a2a89c5e9ead54ed65aafc2086efadaf modelid : lumi.sensor_ht name : ZHAHumidity 3 state : type : ZHAHumidity uniqueid : 00:15:8d:00:01:2c:ac:80-01-0405

The state is empty since no value has yet been received. The latest commits did contain a automatic creation of ZCL attribute reporting and binding. Not sure why it didn't work on the Xiaomi yet. Can you try to read humidity cluster in cluster info, the state attribute should then have at least a value.

[wizkidorg]

Here is the debug from my unit, I enabled --dgb-info & --dbg-aps and removed the Node is known by neighbors lines. In the GUI under the Temp & Humidity there are temp values, just not in the REST API unless I'm doing something wrong.

19:13:22:646 APS-DATA.indication srcAddr: 0x00158d00012cac80, dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -37 19:13:22:647 Node data 0x00158d00012cac80 profileId: 0x0104, clusterId: 0x0000 19:13:22:647 SensorNode id: 1 (lumi.sensor_ht 1) available 19:13:22:648 Update Sensor 0x00158D00012CAC80 Basic Cluster 19:13:22:648 SensorNode id: 2 (ZHATemperature 2) available 19:13:22:648 Update Sensor 0x00158D00012CAC80 Basic Cluster 19:13:22:648 SensorNode id: 3 (ZHAHumidity 3) available 19:13:22:649 Update Sensor 0x00158D00012CAC80 Basic Cluster 19:13:22:670 APS-DATA.indication srcAddr: 0x00158d00012cac80, dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -37 19:13:22:671 Node data 0x00158d00012cac80 profileId: 0x0104, clusterId: 0x0000 19:13:22:671 Update Sensor 0x00158D00012CAC80 Basic Cluster 19:13:22:671 Update Sensor 0x00158D00012CAC80 Basic Cluster 19:13:22:671 Update Sensor 0x00158D00012CAC80 Basic Cluster 19:13:23:596 APS-DATA.request id: 33, addrmode: 0x02, addr: 0x0000, profile: 0x0000, cluster: 0x0031, ep: 0x00 queue: 0 len: 2 19:13:23:669 APS-DATA.confirm id: 33, status: 0x00 SUCCESS 19:13:23:670 APS-DATA.confirm request id: 33 -> confirmed, timeout 10000 19:13:23:695 APS-DATA.indication srcAddr: 0x00212effff00b6e5, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -37 19:13:23:695 APS-DATA.request id: 33 erase from queue 19:13:23:695 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000 19:13:25:021 Idle timer triggered 19:13:25:022 Force read attributes for SensorNode lumi.sensor_ht 1 19:13:25:023 enable support for CIE 1931 XY color mode for groups 19:13:26:021 Wait 1s till query finished 19:13:26:477 APS-DATA.request id: 35, addrmode: 0x02, addr: 0x0000, profile: 0x0000, cluster: 0x0031, ep: 0x00 queue: 0 len: 2 19:13:26:553 APS-DATA.confirm id: 35, status: 0x00 SUCCESS 19:13:26:555 APS-DATA.confirm request id: 35 -> confirmed, timeout 10000 19:13:26:579 APS-DATA.indication srcAddr: 0x00212effff00b6e5, dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -37 19:13:26:580 APS-DATA.request id: 35 erase from queue 19:13:26:581 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000 19:13:27:021 Idle timer triggered 19:13:27:022 Force read attributes for SensorNode ZHAHumidity 3 19:13:27:521 sql exec CREATE TABLE IF NOT EXISTS config2 (key text PRIMARY KEY, value text) 19:13:27:525 save zll database 19:13:27:528 sql exec REPLACE INTO sensors (sid, name, type, modelid, manufacturername, uniqueid, swversion, state, config, fingerprint, deletedState, mode) VALUES ('1', 'lumi.sensor_ht 1', 'ZHASwitch', 'lumi.sensor_ht', 'LUMI', '00:15:8d:00:01:2c:ac:80-01', '', '{"buttonevent":0,"lastupdated":"1970-01-05T14:00:00"}', '{"on":true,"reachable":true}', '{"d":24321,"ep":1,"in":[0],"out":[5],"p":260}', 'normal', '1') 19:13:27:531 sql exec REPLACE INTO sensors (sid, name, type, modelid, manufacturername, uniqueid, swversion, state, config, fingerprint, deletedState, mode) VALUES ('2', 'ZHATemperature 2', 'ZHATemperature', 'lumi.sensor_ht', 'LUMI', '00:15:8d:00:01:2c:ac:80-01-0402', '', '{"lastupdated":"1970-01-05T14:00:00","temperature":0}', '{"on":true,"reachable":true}', '{"d":24321,"ep":1,"in":[1026],"p":260}', 'normal', '1') 19:13:27:534 sql exec REPLACE INTO sensors (sid, name, type, modelid, manufacturername, uniqueid, swversion, state, config, fingerprint, deletedState, mode) VALUES ('3', 'ZHAHumidity 3', 'ZHAHumidity', 'lumi.sensor_ht', 'LUMI', '00:15:8d:00:01:2c:ac:80-01-0405', '', '{"humidity":0,"lastupdated":"1970-01-05T14:00:00"}', '{"on":true,"reachable":true}', '{"d":24321,"ep":1,"in":[1029],"p":260}', 'normal', '1') 19:13:27:568 database saved in 46 ms

[manup]

Hi, the sensor arrived today and is now supported in version 2.04.50.

Setup

• search for new sensors by opening the ZigBee network (Web App > Settings > Open network)
• reset to factory new by pressing the sensor button for 10 s
• it should rejoin and two new sensors ZHATemperature and ZHAHumidity will be created.

http://www.dresden-elektronik.de/rpi/deconz/beta/deconz-2.04.50-qt5.deb

The sensor messes a bit with the ZigBee standard therefore it was needed, to adjust the deCONZ core application as well as the REST plugin.

As seen in the logs the sensor transmits its values in proper ZCL attribute reporting commands, but doesn't list related clusters in the simple descriptor. deCONZ will now attach the misssing clusters 0402 Temperature measurement and 0405 Relative humidty measurement when ZCL attribute reports are received.

Another strange thing: The model id might change between lumi.sens and lumi.sens_ht, the first one comes from reading the basic cluster, the second one is received when pressing the sensor button.

[NisseDILLIGAF]

Thanx for all the help! Now I've got a working sensor! :)

[manup]

Hope it works well, let me know if any problems occur. :)

[ostgardh]

Hi. I have deCONZ 2.04.93. And my 2 Xiaomi temp sensor are in my ZigBee network. But the are bad to update the temp. Is it possible to trigg update to get current temp from sensors?

//P

[manup]

The updates happen only in large intervals or when the values differences are significant. This is sure to safe battery life. If I recall correctly when you press the small button on the sensor it should also report its current state.

[abmantis]

@manup no way to pool the sensor? Or configure it to increase the frequency? I know it will impact battery life, but it would be good for some use cases.

[ebaauw]

The battery-powered Xiaomi sensors (and switches) only seem to support sending push notifications (attribute reporting commands) to the gateway. They don't seem to listen to any command from the gateway, let alone respond to it. This includes the command to configure attribute reporting.

Maybe some-one with the Xiaomi gateway could check whether they get more response from the sensor, and if so, sniff the ZigBee traffic, but I don't hold high hopes that would lead to new insights.

[manup]

Yep they only seem to support push attribute reporting, albeit they do it quite well when value changes significantly.

[abmantis]

@ebaauw I have the Xiaomi gateway and the update frequency is the same (about once per hour or after significant changes).

[AndyScott77]

It Reports temp changes every +/-0.5 deg change. Therefore, polling shouldn't be required, if you haven't received a frame in X mins, you know the temperature is within 0.5 deg of the last report and therefore the zone / area is holding steady at a consistent temperature.

As it's based on the temperature, or humidity, changes, the time between reports could exceed a number of Hours.

Additionally, the inverse applies, that is if the temp changes rapidly, Reports are sent. You can test this by blowing on the device, you will see that it immediately reports temperature changes. I've seen the device send some 10+ temperature change reports within a single minute, by moving the sensor quickly between hot & cold locations.

This approach, that Xiaomi has taken, is really quite effective, as it allows for the device to be used in environments where the temperature or humidity change has both a high and low atrophy.

However, every 55~58 mins another Report Attribute frame is emitted, using the Basic Cluster. The Report is using the Attribute ID of 0xFF01, which is a non-standard ZigBee Attribute for the Basic Cluster. Within the payload the Attributes value contains a some ~30 bytes of data.

For Example :

1F0121A90B0421A813052154000624020000000064292207652111160A210000

This buffer contains a range of data, such as Battery Percentage Remaining. While I haven't fully decoded the payload yet, I imagine it also includes the current Humidity and Temperature as each of the MeasuredValue attributes for TemperatureMeasurement and RelativeHumidityMeasurement ZCL clusters are are only int16, so only requires 4 of those bytes.

We're use this payload frame, with our C# / .net ZigBee, Zwave & OpenThings RF Library, which is not using any part of deCONZ, as an indication that the device is alive and connected to the network. We're using either the Dresden RaspBee Module, the Dresden ConBee USB module or an XBee chip, directly as simple Serial Modems. Our RF lib also tracks the battery level and send notifications when it gets low. While we're using our own library, it should be possible to achieve the same with deCONZ and the REST API, as for sure the hardware supports it.

[ebaauw]

However, every 55~58 mins another Report Attribute frame is emitted, using the Basic Cluster. The Report is using the Attribute ID of 0xFF01

I've seen that as well, I think it also sends this (or something similar) when press/releasing the reset button. Same for other Xiaomi devices. Indeed, the battery level is encoded in there somewhere, but I wouldn't know where. Would appreciate if you could share what you've decoded so far; I'm eager to add config.battery support to deCONZ for these sensors.

[AndyScott77]

@ebaauw - yep. Battery voltage is held in bytes 3 & 4. Temperature in bytes 22 & 23. Humidity in bytes 26 & 27. I think byte 15 contains LQI information, but is mapped to Silicon Labs or Texas Instruments "Chip Errors / Byte : LQI" table. I think RSSI dB is held in Byte 11.

[AndyScott77]

If you have the square version of the sensor, where the ModelIdent attribute is lumi.weather, not lumi.sensor_ht, the Battery Voltage, Temperature and Humidity values have the same indexes within the buffer / payload.

As the device also supports the PressureMeasurement cluster, it includes the current Pressure in bytes 30, 31, 32, & 33.

[ebaauw]

the Battery Voltage, Temperature and Humidity values have the same indexes within the buffer / payload

I would theorise each value is actually preceded by a 2-byte tag, e.g. the battery voltage is preceded by 0x2101, also for the flood sensor. I'll do some more sniffing on my Aqara weather sensors, door sensors, and smart button to confirm.

it includes the current Pressure in bytes 30, 31, 32, & 33.

That's odd, the Measured Value for Pressure Measurement is two bytes, just as for Temperature Measurement and Humidity Measurement.

[ebaauw]

Why sniff when I still run with logging enabled?

On my production Raspberry (4x Door, 2x Weather, 1x smart switch, 1x smart cube):

$ journalctl -au deconz-gui | grep 'payload: 01ff'
Feb 22 18:13:16 pi2 deCONZ[11677]: 18:13:14:145     payload: 01ff421d0121d10b0328150421a8130521a200062403000000000a210000641000
Feb 22 18:14:54 pi2 deCONZ[11677]: 18:14:52:346     payload: 01ff421d0121db0b0328140421a84305219a00062401000000000a21c841641000
Feb 22 18:19:11 pi2 deCONZ[11677]: 18:19:07:928     payload: 01ff422501218b0b0421a84305212b00062401000000006429b0016521f719662b4a8f01000a21c96b
Feb 22 18:31:19 pi2 deCONZ[11677]: 18:31:18:381     payload: 01ff421a0121db0b0328150421a83305219400062401000000000a213974
Feb 22 18:34:12 pi2 deCONZ[11677]: 18:34:07:239     payload: 01ff421d0121bd0b0328150421a83305213b00062401000000000a219ff8641000
Feb 22 18:38:18 pi2 deCONZ[11677]: 18:38:13:366     payload: 01ff422a0121bd0b0328170421a8430521c200062401000000000a210a519721000098210c089921bb079a210300
Feb 22 18:55:31 pi2 deCONZ[11677]: 18:55:31:265     payload: 01ff421d0121c70b0328130421a81305219200062401000000000a21c96b641000
Feb 22 18:56:06 pi2 deCONZ[11677]: 18:56:05:171     payload: 01ff42250121b30b0421a84305211300062401000000006429150965219a0b662b148f01000a215938

On my test Raspberry (1x Flood):

$ journalctl -au deconz-gui | grep 'payload: 01ff'
Feb 22 17:37:29 pi deCONZ[17328]: 17:37:25:420  payload: 01ff42220121db0b0328180421a8330521540006240100000000082104020a211e67641000
Feb 22 18:27:36 pi deCONZ[17328]: 18:27:31:995  payload: 01ff42220121db0b03281a0421a8330521540006240100000000082104020a211e67641000

Note that this is the payload of the Report Attributes command, so it starts with the attrbute ID (0xff01), the data type (string, 0x42) and the length (one byte). Then it contains 0x2101, followed by the battery voltage.

[ebaauw]

I feel like trying to read the Matrix from screen ;-)

EDITED with the latest insights

Assuming a one-byte tag, followed by a one-byte data type, we get:

                        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
         attr tp  l   battery    temp             RSSI dB             LQI
         ---- -- -- --------- ------- --------- --------- --------------- ---------
switch:  01ff 42 1a 0121 db0b 0328 15 0421 a833 0521 9400 0624 0100000000 0a21 3974
                 26    3.035V

                                            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
door:    01ff 42 1d 0121 db0b 0328 14 0421 a843 0521 9a00 0624 0100000000 0a21 c841 6410 00
                 29    3.025V
door:    01ff 42 1d 0121 bd0b 0328 15 0421 a833 0521 3b00 0624 0100000000 0a21 9ff8 6410 00
                 29    3.025V
door:    01ff 42 1d 0121 c70b 0328 13 0421 a813 0521 9200 0624 0100000000 0a21 c96b 6410 00
                 29    3.015V

                                            1                       2                       3
                     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 0  1 2  3
         attr tp  l   battery    temp             RSSI dB             LQI                          On
         ---- -- -- --------- ------- --------- --------- --------------- --------- --------- -------
wleak:   01ff 42 22 0121 db0b 0328 18 0421 a833 0521 5400 0624 0100000000 0821 0402 0a21 1e67 6410 00
                 34    3.035V

                                                   1                       2                        3
                     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  0 1 2 3  4 5  6 7
         attr tp  l   battery                     RSSI dB             LQI      temp  humidity      pressure
         ---- -- -- ---------         --------- --------- --------------- --------- --------- ------------- ---------
weather: 01ff 42 25 0121 8b0b         0421 a843 0521 2b00 0624 0100000000 6429 b001 6521 f719 662b 4a8f0100 0a21 c96b
                 37    2.955V                                                 4.32°C    66.47%    1022.18hPa
weather: 01ff 42 25 0121 b30b         0421 a843 0521 1300 0624 0100000000 6429 1509 6521 9a0b 662b 148f0100 0a21 5938
                 37    2.995V                                                23.25°C    29.70%    1021.64hPa

                                            1                        2                      3                        4
                     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 0  1 2  3 4  5 6  7 8  9 0  1 2
         attr tp  l   battery    temp             RSSI dB             LQI
         ---- -- -- --------- ------- --------- --------- --------------- --------- --------- --------- --------- ---------
cube:    01ff 42 2a 0121 bd0b 0328 17 0421 a843 0521 c200 0624 0100000000 0a21 0a51 9721 0000 9821 0c08 9921 bb07 9a21 0300
                 42    3.035V

[manup]

For the window/door it seems that the last byte is the open/closed status

0x00 closed 0x01 open

[manup]

Byte 7 is very interesting, it seems to reflect the coarse temperature measurement made by the rf controller resistor measurement.

By looking to a overnight sniffer log of my Xiaomi devices they all seem to provide this information, the resolution is very coarse but is enough to detect some patterns like night, or heating on/off. All combined this might be handy to improve presence or night/day detection in rooms without specific sensors.

[ebaauw]

Byte 7 is very interesting ... sniffer log of my Xiaomi devices they all seem to provide this information

Are you talking about the word after the (assumed) 0421 tag, or the byte after the (assumed) 0328 tag?

it seems to reflect the coarse temperature measurement made by the rf controller resistor measurement.

Like the “cpu temperature” of the sensor? Something like the higher the value, the more active the sensor has been, so the more changes the sensor has detected?

[manup]

Are you talking about the word after the (assumed) 0421 tag, or the byte after the (assumed) 0328 tag?

The byte after the 0328.

Like the “cpu temperature” of the sensor? Something like the higher the value, the more active the sensor has been, so the more changes the sensor has detected?

Embedded controllers often have a primitive integrated temperature sensor but the resolution is very low. It measures the environment temperature like a normal temperature sensor. The value is not suitable as proper temperature measurement, like it's exactly 20°C and might be off a bit, but it's good enough to detect temperature changes over the day.

[manup]

Oh and it seems the weather sensors don't have the 0328 tag, makes sense since they have a real temperature sensor on board.

[ebaauw]

The byte after the 0328.

So the value is actually the (imprecise) temperature in ˚C. I wonder what they'll report below zero.

Oh and it seems the weather sensors don't have the 0328 tag

Hence my confusion.

The value is not suitable as proper temperature measurement, like it's exactly 20°C and might be off a bit, but it's good enough to detect temperature changes over the day.

Not much difference from the temperature in the Hue motion sensor, then. When placed next to each other, they all report a different temperature by a few degrees. I think that's why Philips don't advertise the temperature sensor. "With one watch a man knows what time it is, with two he's never sure..."

I recently added config.offset to the ZHATemperature resource for calibration, but that assumes the sensor is always off by a constant value.

[manup]

So the value is actually the (imprecise) temperature in ˚C. I wonder what they'll report below zero.

Luckily it's freezing cold here in Dresden ;) I'll check that.

Not much difference from the temperature in the Hue motion sensor, then. When placed next to each other, they all report a different temperature by a few degrees. I think that's why Philips don't advertise the temperature sensor. "With one watch a man knows what time it is, with two he's never sure..."

I recently added config.offset to the ZHATemperature resource for calibration, but that assumes the sensor is always off by a constant value.

If the value turns out to be mostly (+/- 3°C) on par with other sensors it would be very cool, so we could provide a ZHATemperature for all Xiaomi devices. Albeit the update rate is very long at ~1 hour it sure is a nice feature.

[ebaauw]

we could provide a ZHATemperature for all Xiaomi devices

Let's try and do battery first.

Now here's an interesting thought: we don't have a separate ZHABattery resource for battery, thought technically, it is a different cluster. Same holds for ledindication and usertest of the Hue motion sensor. All these are exposed as config attributes, though, in line with the Hue API.

We could expose this temperature as config.temperature of the existing sensor resource, instead of state.temperature of a new ZHATemperature resource, in line with config.battery. Logically, state.battery would make more sense (but then, so would state.battery, state.reachable, and probably action.alert).

[manup]

Now here's an interesting thought: we don't have a separate ZHABattery resource for battery, thought technically, it is a different cluster. Same holds for ledindication and usertest of the Hue motion sensor. All these are exposed as config attributes, though, in line with the Hue API.

We could expose this temperature as config.temperature of the existing sensor resource, instead of state.temperature of a new ZHATemperature resource, in line with config.battery. Logically, state.battery would make more sense (but then, so would state.battery, state.reachable, and probably action.alert).

Agree config.battery provides continuity and is in line with hue api. Not so sure about config.temperature, till now we have state.temperature in ZHATemperature sensors I would prefer to just attach the state.temperature to the existing Xiaomi sensors to prevent confusion why some sensors use config.temperature and some state.temperature.

[manup]

Further details on the tags:

0x0121:
    0x01     battery
    0x21     ZCL datatype 16-bit unsigned int

0x0328:
    0x03     temperature
    0x28     ZCL datatype 8-bit signed int

0x0421:
    0x04     ????
    0x21     ZCL datatype 16-bit unsigned int

0x0521:
    0x05     ????
    0x21     ZCL datatype 16-bit unsigned int

0x0624:
    0x06     ????
    0x21     ZCL datatype 40-bit unsigned int

0x0a21:
    0x0a     ????
    0x21     ZCL datatype 16-bit unsigned int

0x6410:
    0x64     on/off state
    0x10     ZCL datatype bool

0x6429:
    0x64     temperature
    0x29     ZCL datatype 16-bit signed integer

0x6529:
    0x64     humidity
    0x29     ZCL datatype 16-bit signed integer

0x662b:
    0x66     pressure
    0x2b     ZCL datatype 32-bit signed integer

[manup]

I'm cooking a little handler to dissect these will be online soon. Almost forgot how much fun these reverse engineering stuff is :)

[ebaauw]

OK, so the tag is actually one byte, followed by a one-byte data type. Makes sense actually, then you'd know how many bytes to expect for the value. 0x0624 might be the LQI indicator and 0x0521 the RSSI dB, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/42#issuecomment-367701576. I've updated my overview above with these insights.

So the lower tags (0x) seem generic (nwk-related?) the higher ones (6x, 9x) seem device specific (aps-related?).

Almost forgot how much fun these reverse engineering stuff is :)

"Whatever gets you through the night..." -- John Lennon

[manup]

Seems to work, battery is actually state.voltage now not sure if that is the proper attribute for that or if we need state.batteryvoltage?

[ebaauw]

Nice!

Seems to work, battery is actually state.voltage now not sure if that is the proper attribute for that or if we need state.batteryvoltage?

I would prefer config.battery, in line with other devices. The Smartthings groofy files translate the voltage to percentage using a linear scale it between 2.5V and 3.0V. This would also avoid the question why we don't expose the battery voltage for other devices.

I scaled state.voltage for smart plugs to V - if we maintain state.voltage the value should be 3. Alternatively, we need to re-scale state.voltage to 0.01V. The last digit seems to be 5 all the time across my nine Xiaomi devices, so 2 decimals would be fine-grained enough. Of course, state.batteryvoltage could be in 0.01V next to state.voltage in V.

Likewise, state.temperature is in 0.01 degrees, so the value should 2200. Given the lack of precision, that looks ridiculous, but so would adding another attribute.

Tag 98 of the Cube seems to be related to the Multistate Input cluster; 99 to the Analog Input. 97 appears to have value 0 all the time, and 9a value 3.

[manup]

I would prefer config.battery, in line with other devices. The Smartthings groofy files translate the voltage to percentage using a linear scale it between 2.5V and 3.0V. This would also avoid the question why we don't expose the battery voltage for other devices.

I scaled state.voltage for smart plugs to V - if we maintain state.voltage the value should be 3. Alternatively, we need to re-scale state.voltage to 0.01V. The last digit seems to be 5 all the time across my nine Xiaomi devices, so 2 decimals would be fine-grained enough. Of course, state.batteryvoltage could be in 0.01V next to state.voltage in V.

Good idea I'll add this to the next version, 2.05.09 is just compiling now.

Likewise, state.temperature is in 0.01 degrees, so the value should 2200. Given the lack of precision, that looks ridiculous, but so would adding another attribute.

This is fixed now.

Tag 98 of the Cube seems to be related to the Multistate Input cluster; 99 to the Analog Input. 97 appears to have value 0 all the time, and 9a value 3.

Cool this should be added too, it's nice that the cube tells the state also if not active.

[ebaauw]

Cool this should be added too, it's nice that the cube tells the state also if not active.

Of course it will do so only once every couple of hours (and when the reset button inside the battery compartment is pressed).

Good idea I'll add this to the next version, 2.05.09 is just compiling now.

Pity, the lumi.sensor_switch.aq3 will have to wait for next version as well, then?

[manup]

Pity, the lumi.sensor_switch.aq3 will have to wait for next version as well, then?

Damn I missed the PR, tomorrow I can bake a new version, I'm a bit in a hurry today

[manup]

2.05.10 is now online for RPi and Ubuntu