openhab/org.openhab.binding.zigbee

Support Xiaomi manufacturer-specific attribute

Opened this issue · 12 comments

Xiaomi devices seem to have manufacturer specific attribute (0xFF01) under Basic cluster. It was already discussed here:
dresden-elektronik/deconz-rest-plugin#42
https://github.com/athombv/homey/issues/2165

It's recognized as CHARACTER_STRING data type, but it's wrong:
2019-12-18 13:26:06.017 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionCommand: ReportAttributesCommand [Basic: 33543/1 -> 0/1, cluster=0000, TID=CD, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=65281, attributeValue=�(&�! ]]

Any ideas how to add support for this?

Here are received data structures extracted from the logs:

Xiaomi Water Leak Detector

lumi.sensor_wleak.aq1

raw id zcl type value comment
01 21 9F 0B 1 33 (UNSIGNED_16_BIT_INTEGER) 2975 2.975V (battery)
03 28 1E 3 40 (SIGNED_8_BIT_INTEGER) 30
04 21 A8 13 4 33 (UNSIGNED_16_BIT_INTEGER) 5032
05 21 3B 00 5 33 (UNSIGNED_16_BIT_INTEGER) 59
06 24 01 00 00 00 00 6 36 (UNSIGNED_40_BIT_INTEGER) 0x0100000000
08 21 04 02 8 33 (UNSIGNED_16_BIT_INTEGER) 516
0A 21 00 00 10 33 (UNSIGNED_16_BIT_INTEGER) 0
64 10 01 100 16 (Boolean) 1 on/off state

Xiaomi Temperature and Humidity Sensor

lumi.weather

raw id zcl type value comment
01 21 9F 0B 1 33 (UNSIGNED_16_BIT_INTEGER) 2975 2.975V (battery)
04 21 A8 13 4 33 (UNSIGNED_16_BIT_INTEGER) 5032
05 21 15 00 5 33 (UNSIGNED_16_BIT_INTEGER) 21
06 24 01 00 00 00 00 6 36 (UNSIGNED_40_BIT_INTEGER) 0x0100000000
0A 21 00 00 10 33 (UNSIGNED_16_BIT_INTEGER) 0
64 29 0F 04 100 41 (SIGNED_16_BIT_INTEGER) 1039 10.39°C
65 21 49 12 101 33 (UNSIGNED_16_BIT_INTEGER) 4681 46.81% RH
66 2B 95 85 01 00 102 43 (SIGNED_32_BIT_INTEGER) 99733 997.33 hPa

Xiaomi Wireless Relay

lumi.relay.c2acn01

raw id zcl type value comment
03 28 24 3 40 (SIGNED_8_BIT_INTEGER) 36
05 21 09 00 5 33 (UNSIGNED_16_BIT_INTEGER) 9
07 27 00 00 00 00 00 00 00 00 7 39 (UNSIGNED_64_BIT_INTEGER) 0
08 21 23 12 8 33 (UNSIGNED_16_BIT_INTEGER) 4643
09 21 00 01 9 33 (UNSIGNED_16_BIT_INTEGER) 256
64 10 01 100 16 (Boolean) 1 on/off state
65 10 00 101 16 (Boolean) 0 on/off state
6E 20 01 110 32 (UNSIGNED_8_BIT_INTEGER) 1
6F 20 00 111 32 (UNSIGNED_8_BIT_INTEGER) 0
94 20 4F 148 32 (UNSIGNED_8_BIT_INTEGER) 79
95 39 66 66 66 3D 149 57 (FLOAT_32_BIT) 0.056250
96 39 51 6A 0B 45 150 57 (FLOAT_32_BIT) 2230.644775 voltage
97 39 A3 20 A5 3D 151 57 (FLOAT_32_BIT) 0.080629
98 39 25 AF 63 41 152 57 (FLOAT_32_BIT) 14.230260
9B 21 00 00 155 33 (UNSIGNED_16_BIT_INTEGER) 0

What does attribute FF01 do? Why do you need it?

This attribute contains all the info Xiaomi device provides, such as battery level, signal quality, chip temperature, is device switched on or off, etc.

I'm not sure why you have posted all the other attributes? Is that related to this attribute FF01?

No, it's all the same attribute. That's format for data structure for this attribute for various devices I have.

P.S. @cdjackson I guess you want to delete/edit your comment as it possibly exposes tokens

Then I don't think this is something we can support in the binding. The data should be available through the standard attributes already shouldn't it?

The email is ok - it's just a badly displayed version of your original mail.

@cdjackson no, it's not available through the standard attributes unfortunately.

P.S. Look at the end, there are links with tokens to unsubscribe and post a reply

The Xiaomi devices already provide information like battery voltage, humidity, temperature, pressure, status etc through the standard attributes. Maybe there is more information available here, but it's unclear what at the moment, and it's unclear if this is really needed (your list doesn't even say what they are).

I don't think that this change is required to provide further information, and it's not something that can easily be accommodated in the binding. The binding will support all the standard ZigBee attributes provided by the Xiaomi devices, and this already supports the information you describe here (battery voltage, humidity, temperature, pressure, status)

None of the mentioned Xiaomi devices provide battery voltage info. #382 confirms it.

Only switches are working for Xiaomi Wireless Relay. But it has to provide much more information, such as chip temperature, current voltage, total active power and power consumption per hour. Total active power is reported under analog input basic cluster, which is also not supported by the binding. But all the other information is only accessible via this attribute.

mething that I will be working on any time in the foreseable future as there are many more things to look at to support devices that respect the standards.

@cdjackson How about a few loo rolls or cans of something to change your mind? In the meantime it might be worth removing the unsupported devices from the openhab webpage. I bought a few Aqara Wireless Mini Switches and they dont seem to work! (https://www.openhab.org/addons/bindings/zigbee/)

Thank you for the binding!

How about a few loo rolls or cans of something to change your mind?

:)

I'm unclear what doesn't work? Most of the features mentioned above are covered through standard mechanisms - I know that the door sensors and temp/humidity sensors work, and I'm pretty sure people are using the switches as well as I think this was discussed on the forum earlier in the year.

Some secondary attributes may not work - eg I think the battery status is not provided on some devices except through these non-standard means, but I don't think that's a big issue and I would not claim that the device doesn't work just because it wasn't reporting the battery.

I'd suggest to discuss your issue on the community forum to work out what the problem is as it's unclear to me at least what doesn't work.

In the meantime it might be worth removing the unsupported devices from the openhab webpage. I bought a few Aqara Wireless Mini Switches and they dont seem to work!

If there are devices that are on the list that are really not supported, then yes, I agree that they should be removed. However, as above it's unclear to me if the device doesn't work (as you claim), or it doesn't work for you due to something you are doing, or something in your system etc. I don't know what "doesn't work" even so please discuss on the forum.

I will post on the forum, I can add the devices, however no channels are created. Thank you

OFFLINE - HANDLER_INITIALIZING_ERROR No supported clusters found

HardwareVersion | 2
modelId | lumi.remote.b1acn01
vendor | LUMI
zigbee_applicationVersion | 2
zigbee_datecode | 20180525
zigbee_device_initialised | true
zigbee_logicaltype | END_DEVICE
zigbee_manufacturercode | 0x1037
zigbee_networkaddress | 23122
zigbee_powerlevel | FULL
zigbee_powermode | RECEIVER_ON_IDLE
zigbee_powersource | DISPOSABLE_BATTERY
zigbee_powersources | [DISPOSABLE_BATTERY]
zigbee_stkversion | 2
zigbee_zclversion | 1

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/zigbee-oh3-0-aqara-humidity-temp-sensor/113804/2

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/testing-zigbee-dongle-and-popular-devices/121237/53