search

openhab / org.openhab.binding.zigbee

openHAB binding for ZigBee
Eclipse Public License 2.0
73 stars 112 forks source link

Xiaomi door window sensor not working - on off channel consolidation issue #601

Open mattibal opened 4 years ago

mattibal commented 4 years ago

Hi all,

I have a Xiaomi door window sensor MCCGQ01LM (the rounded non-Aqara ones) that's not working with the Zigbee binding (with both the stable 2.5.7 and snapshot version). The thing is correctly recognized and a "Level Control" channel shows up, but when you link an item to that channel, it doesn't get any event and doesn't change status when you open or close the door.

I looked at what's happening with a debugger and I think there is an issue in the Zigbee binding code. The sensor seems to support On Off and Level Control as client clusters, but only On Off as server cluster. The Zigbee binding creates anyway just a Level Control channel (and not also an On Off channel) due to "consolidation", without taking into account that the level control cluster is supported by the sensor only as client and not as server. So a ZigBeeConverterSwitchLevel is getting created, and it does initializes the device as "client" instead of as "server" because it gets confused by the fact that the level control server cluster is missing, so it doesn't register an AttributeListener for the On Off cluster and doesn't get On Off notifications.

As a workaround, I tried to disable the On Off - Level Control channels "consolidation" by commenting this line: https://github.com/openhab/org.openhab.binding.zigbee/blob/db37991a066c428835b6851c9a1da348bad41d24/org.openhab.binding.zigbee/src/main/java/org/openhab/binding/zigbee/internal/converter/ZigBeeChannelConverterFactoryImpl.java#L65-L66 and it seems to work fine. A "Switch" channel gets created alongside to the "Level Control" one, and when linking an item to the Switch channel, it does receive events and changes status normally when the door is open or closed.

I know that's not a proper fix for the issue, but might it be a good enough temporary solution? I've tested it with my IKEA Tradfri lights and an Innr SP120 plug, and it doesn't seems to break anything.

BTW thank you for your work on the binding!

cdjackson commented 4 years ago

The sensor seems to support On Off and Level Control as client clusters, but only On Off as server cluster.

That's incorrect. Both client and server are supported - they have been for a long time as we support wall switches that send OnOff (ie client) and lights that receive OnOff (ie server).

I don't know why a window sensor is a level control device anyway - it should be an IAS device - level doesn't really make sense. However, that's an asside.

I won't disable the channel consolidation if that's what you are suggesting - this goes against the OH design philosophy which is why it was added in the first place. You are better off considering a static device definition.

mattibal commented 4 years ago

That's incorrect. Both client and server are supported - they have been for a long time as we support wall switches that send OnOff (ie client) and lights that receive OnOff (ie server).

Sorry maybe I haven't explained it well. I was saying that the Xiaomi sensor I've on hands does support these clusters:

This is its XML file in userdata/zigbee directory:

Click to expand ```xml 00158D000460E3C9 42338 0 127 false 4151 END_DEVICE 100 100 false FREQ_2400_MHZ REDUCED_FUNCTION_DEVICE false false 0 RECEIVER_ON_IDLE DISPOSABLE_BATTERY DISPOSABLE_BATTERY FULL 1 260 260 1 0 false 0 0 ZCL Version UNSIGNED_8_BIT_INTEGER true false true false false 0 0 0 16384 16384 SW Build ID CHARACTER_STRING false false true false false 0 0 0 1 1 Application Version UNSIGNED_8_BIT_INTEGER true false true false false 0 0 0 2 2 Stack Version UNSIGNED_8_BIT_INTEGER true false true false false 0 0 0 3 3 HW Version UNSIGNED_8_BIT_INTEGER true false true false false 0 0 0 Europe/Rome 2 4 4 Manufacturer Name CHARACTER_STRING true false true false false 0 0 0 Europe/Rome LUMI 5 5 Model Identifier CHARACTER_STRING true false true false false 0 0 0 Europe/Rome lumi.sensor_magnet 6 6 Date Code CHARACTER_STRING true false true false false 0 0 0 7 7 Power Source ENUMERATION_8_BIT true false true false false 0 0 0 8 8 Generic Device Class ENUMERATION_8_BIT false false true false false 0 0 0 9 9 Generic Device Type ENUMERATION_8_BIT false false true false false 0 0 0 10 10 Product Code CHARACTER_STRING false false true false false 0 0 0 11 11 Product URL CHARACTER_STRING false false true false false 0 0 0 16 16 Location Description CHARACTER_STRING true false true true false 0 0 0 17 17 Physical Environment ENUMERATION_8_BIT true false true true false 0 0 0 18 18 Device Enabled BOOLEAN true false true true false 0 0 0 19 19 Alarm Mask BITMAP_8_BIT true false true true false 0 0 0 20 20 Disable Local Config BITMAP_8_BIT true false true true false 0 0 0 3 false 0 0 Identify Time UNSIGNED_16_BIT_INTEGER true false true true false 0 0 0 6 false 0 0 On Off BOOLEAN true false true false true 0 0 0 Europe/Rome false 16384 16384 Global Scene Control BOOLEAN true false true false false 0 0 0 16385 16385 On Time UNSIGNED_16_BIT_INTEGER true false true true false 0 0 0 16386 16386 Off Wait Time UNSIGNED_16_BIT_INTEGER true false true true false 0 0 0 16387 16387 Start Up On Off ENUMERATION_8_BIT false false true true false 0 0 0 25 false 65535 false 0 true 3 true 4 true 5 true 6 true 8 true 25 true 0 0 Upgrade Server ID IEEE_ADDRESS true false true false false 0 0 0 1 1 File Offset UNSIGNED_32_BIT_INTEGER true false true false false 0 0 0 2 2 Current File Version UNSIGNED_32_BIT_INTEGER true false true false false 0 0 0 3 3 Current ZigBee Stack Version UNSIGNED_16_BIT_INTEGER true false true false false 0 0 0 4 4 Downloaded File Version UNSIGNED_32_BIT_INTEGER true false true false false 0 0 0 5 5 Downloaded ZigBee Stack Version UNSIGNED_16_BIT_INTEGER true false true false false 0 0 0 6 6 Image Upgrade Status ENUMERATION_8_BIT true false true false false 0 0 0 7 7 Manufacturer ID UNSIGNED_16_BIT_INTEGER true false true false false 0 0 0 8 8 Image Type ID UNSIGNED_16_BIT_INTEGER true false true false false 0 0 0 9 9 Minimum Block Request Period UNSIGNED_16_BIT_INTEGER true false true false false 0 0 0 10 10 Image Stamp UNSIGNED_32_BIT_INTEGER true false true false false 0 0 0 ```

The sensor that I have seems to be available from italian resellers since 2019, so it could be different from the one sold in China since several years ago, I don't know.

I don't know why a window sensor is a level control device anyway - it should be an IAS device - level doesn't really make sense. However, that's an asside.

I think the clusters configuration of that Xiaomi device (even if it's not the smartest) is allowed by Zigbee specs, so the Openhab Zigbee binding should correctly get attribute update reports from the OnOff server cluster of the device. Unfortunately that's not working for the reason that I've explained in my previous message. I think that's a bug of the Zigbee binding.

I won't disable the channel consolidation if that's what you are suggesting - this goes against the OH design philosophy which is why it was added in the first place. You are better off considering a static device definition.

Thank you for the suggestion, I didn't know the static device definition feature existed, I'll have a look at it. Could it be used to "disable" the LevelControl client cluster of the device, so that the OnOff server cluster is picked by ZigBeeConverterSwitchOnoff ? This would be a better workaround for the issue.