The one that I have working is a “lumi.sensor_switch.aq2”. I bought it around ~09/2019.
My Aqara button:
OFFLINE - HANDLER_INITIALIZING_ERROR No supported clusters found
modelId | lumi.remote.b1acn01
My thinking is not to buy any more Aqara/Lumi stuff until they put zigbee logos on the boxes.
Hi All,
There are two versions of the Xiaomi Switch - WXKG11LM, having looked at the github binding, only the 2016 version appears to be supported (link at the end).
@chris could you please add the 2018 model. My github/coding skills are lacking so i wouldnt know where to begin. I would be happy to compensate you with a beer!
WXKG11LM
- 2016 - lumi.sensor_switch.aq2
- 2018 - lumi.remote.b1acn01
Button events for the 2016 version “lumi.sensor_switch.aq2”
Event Action 1002 single short press 1004 double short press 1005 triple short press 1006 quad short press Button events for the 2018 version “lumi.remote.b1acn01”
Event Action 1002 single press 1004 double press 1001 hold 1003 hold release
Zigbee binding supported items (org.openhab.binding.zigbee/src/main/resources/discovery.txt)
- philips_sml001,vendor=Philips,modelId=SML001
- philips_rwl021,vendor=Philips,modelId=RWL021
- smartthings_motionv4,vendor=SmartThings,modelId=motionv4
- bitron-video-902010-23,vendor=Bitron Home,modelId=902010/23
- bitron-video-av2010-34,vendor=Bitron Video,modelId=AV2010/34
- xiaomi_lumisensorht,modelId=lumi.sensor_ht
- xiaomi_lumisensor-motion,modelId=lumi.sensor_motion
- xiaomi_lumiremoteb286acn01,modelId=lumi.remote.b286acn01
- xiaomi_lumisensor86sw2,modelId=lumi.sensor_86sw2
- xiaomi_lumisensor-switchaq2,modelId=lumi.sensor_switch.aq2
- xiaomi_lumisensorwaterleak,modelId=lumi.sensor_wleak.aq1
- innr-rc-110,vendor=innr,modelId=RC 110
- osram-switch-4x-eu,vendor=OSRAM,modelId=Switch 4x EU-LIGHTIFY
Thank you
I’m not sure what these events are? Presumably there is an attribute associated with them? If I look at the old switch, there is also no handling of these events, so my guess is that they are using something standard and the binding is detecting them.
Do you have a log showing these events being received - or further documentation on what the definition of these events are?
On a related note (would you prefer new threads for slightly differing issues?)
I had a Lumi Aqara wallswitch remote (WXKG02LM) which I decided to give a go today, it’s on the list of supported items but this might be the same remote named for a different version:
xiaomi_lumiremoteb286acn01,modelId=lumi.remote.b286acn01
I paired it sucessfully after a large number of attempts, and got the correct channels come through:
However only the Range check channel works (tap either button 5 times). It comes up on ClusterID 0:
TelegesisRouteRecordMessageEvent [hops=2, remoteAddress=00158D00040B101C, networkRoute=[42987, 40362, 27506]]
TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=42987, profileId=260, destinationEp=1, sourceEp=1, clusterId=0, messageData=18 38 0A 05 00 42 15 6C 75 6D 69 2E 72 65 6D 6F 74 65 2E 62 32 38 36 61 63 6E 30 31, rssi=-69, lqi=255]
The other two come up on ClusterID 18, which I suspect is non standard:
| Action | DestinationEP | SourceEP | ClusterID | MessageData |
|---|---|---|---|---|
| Left Single Press | 1 | 1 | 18 | 18 3A 0A 55 00 21 01 00 |
| Left Double Press | 1 | 1 | 18 | 18 3B 0A 55 00 21 02 00 |
| Left Long Press | 1 | 1 | 18 | 18 3C 0A 55 00 21 00 00 |
| Right Single Press | 1 | 2 | 18 | 18 3D 0A 55 00 21 01 00 |
| Right Double Press | 1 | 2 | 18 | 18 3E 0A 55 00 21 02 00 |
| Right Long Press | 1 | 2 | 18 | 18 3F 0A 55 00 21 00 00 |
That second byte in the message data seems to be a counter shared between all buttons i.e. the next command would be 0x40 etc.
@chris, do you know if this is different to other devices of the same type? How best to proceed (if possible/plausible) to support it?
Unfortunately you’re looking across multiple layers here. The log would have broken them out better.
I’m not familiar with any of these devices, but from a quick look at the definition it is correct as per the bindings definition. Can you provide a log please?
Thanks Chris,
This a debug log (org.openhab.binding.zigbee and com.zsmartsystems.zigbee) capturing the button presses left single press, left double press and left long press, followed by the same for right, and then both buttons at the same time (sourceEP becomes 3, but there is no channel for this yet).
openhab-zigbee.log (16.1 KB)
Hmmm…
So this is probably a discovery issue - ie the device is not fully discovered. Earlier this year we got ZigBee certification for a product - as part of that there were some tests to make sure that the software doesn’t respond to unknown devices or unknown endpoints, and that test is being triggered here. This is probably because the descriptors for the endpoints wasn’t received during the initialisation.
Can you send me the XML file for this node (in the userdata/zigbee foder - it will have the name of the IEEE address of the device). This should tell me if the discovery is complete or not. There may be another issue after that, but one step at a time…
Ah, I suspect not, it’s basically empty:
<ZigBeeNode>
<ieeeAddress>00158D00040B101C</ieeeAddress>
<networkAddress>42987</networkAddress>
<endpoints/>
<bindingTable/>
</ZigBeeNode>
Yep - that’s your problem 
I’m a bit loath to ask you to include it again, but without this information it’s a bit difficult. We could in theory add some stuff to get it started and that might be enough.
Try adding the following to the <endpoints> tag (ie replace that line in your file with this) -:
<endpoints>
<ZigBeeEndpoint>
<endpointId>1</endpointId>
<outputClusters>
<ZclCluster>
<clusterId>18</clusterId>
<isClient>false</isClient>
<ZclCluster>
<outputClusters>
<ZigBeeEndpoint>
<ZigBeeEndpoint>
<endpointId>2</endpointId>
<outputClusters>
<ZclCluster>
<clusterId>18</clusterId>
<isClient>false</isClient>
<ZclCluster>
<outputClusters>
<ZigBeeEndpoint>
<ZigBeeEndpoint>
<endpointId>3</endpointId>
<outputClusters>
<ZclCluster>
<clusterId>18</clusterId>
<isClient>false</isClient>
<ZclCluster>
<outputClusters>
<ZigBeeEndpoint>
<endpoints>
No guarantees that this won’t cause the binding to crash - let’s see 
Unfortunately, it doesn’t seem to do anything differently (I also added / to those closing tags). Restarting the binding puts the file back to what it was too.
Without removing the thing, I tried discovery from paper UI and got a lot of unknown devices that disappeared from the inbox very quickly, the only one that stayed was Unknown ZigBee Device 00158D00040B101C which matches the IEEE address of the switch im having trouble with. It doesn’t have any information attached to it if I add it and seems to be stuck on Status: OFFLINE Node has not completed discovery
Hi Chris,
I googled them and discovered that those button presses could potentially be supported, sorry I included them and the 4 digit event ID thinking you might know what that meant.
I removed the device, turned on debugging for “com.zsmartsystems.zigbee” in the karaf console, added the device through paperui, waited for initialisation/ discovery, then i started clicking the main button (while the device status is showing as “OFFLINE - HANDLER_INITIALIZING_ERROR - No supported clusters found”).
The log is just under 4,000 lines, should i extract specific lines or dump the lot here?
Thank you
I finally managed to get something sensible in the XML file 00158D00040B101C.xml (52.7 KB)
It seems to my untrained eye that it matches info on ESH-INF/thing/xiaomi/lumiremoteb286acn01.xml The logs still respond in much the same way though:
2020-05-14 13:33:51.635 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data:+N=COO,11,-07,31C8,56206800496F9AA0
2020-05-14 13:33:51.637 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data:OK
2020-05-14 13:33:51.638 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisDisplayNetworkInformationCommand [device=COO, channel=11, power=-7, panId=12744, epanId=56206800496F9AA0, status=SUCCESS]
2020-05-14 13:33:51.643 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data:SR:01,00158D00040B101C,3957,DF75
2020-05-14 13:33:51.645 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisRouteRecordMessageEvent [hops=1, remoteAddress=00158D00040B101C, networkRoute=[14679, 57205]]
2020-05-14 13:33:51.647 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Unhandled Telegesis Frame: TelegesisRouteRecordMessageEvent [hops=1, remoteAddress=00158D00040B101C, networkRoute=[14679, 57205]]
2020-05-14 13:33:51.707 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data:RX:3957,0104,01,01,0012,08:A
U
2020-05-14 13:33:51.709 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=14679, profileId=260, destinationEp=1, sourceEp=1, clusterId=18, messageData=18 41 0A 55 00 21 01 00, rssi=-83, lqi=255]
2020-05-14 13:33:51.711 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=3957/1, destinationAddress=0000/1, profile=0104, cluster=0012, addressMode=null, radius=0, apsSecurity=false, ackRequest=false, apsCounter=--, rssi=--, lqi=--, payload=18 41 0A 55 00 21 01 00]
2020-05-14 13:33:51.712 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=65, commandId=10]
2020-05-14 13:33:51.714 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Unsupported local client cluster 0012
2020-05-14 13:33:51.715 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Incoming message from node 3957 did not translate to command
2020-05-14 13:33:52.586 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1
2020-05-14 13:33:52.587 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis: TelegesisDisplayNetworkInformationCommand [device=null, channel=null, power=null, panId=null, epanId=null]
2020-05-14 13:33:52.590 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis Data:AT+N?
I posted it already in another topic, but I think this topic is more general and maybe someone could help.
I have a Aqara Motion Sensor connected to the Zigbee binding, which was connected via zigbee2mqtt before and worked perfectly.
As I want to reduce the systems in between, therefore I desiced to use my zigBee network directly with the zigBee binding.
I see the Aqara Motion Sensor sensor switch to ON, but never to OFF (only, if I touch the switch manually, i.e. by paperUI from ON to OFF). It seems to me, that it is not polling its data again.
Someone a step ahead, how to realize it - otherwise I need to switch back to zigbee2mqtt.
What do the debug logs show is happening?
Hi Dominik,
I use the Aqara Human Motion Sensor with the Zigbee binding. Indeed the sensor only triggers the switch to ON. I am using the Expire binding to turn the switch to OFF after a given amount of time. For example, the relevant line in the .things file is like this:
Switch Aqara_Motion_Sensor_Occupancy "Motion Sensor Occupancy" <motion> {channel="zigbee:device:xxx:yyy:yyy_1_occupancy", expire="2m,command=OFF"}
This is the log, when it switch occupancy to on:
08:43:51.853 [DEBUG] [.converter.ZigBeeConverterIlluminance] - 00158D00031492CE: ZigBee attribute reports ZclAttribute [cluster=Illuminance Measurement, id=0, name=Measured Value, dataType=UNSIGNED_16_BIT_INTEGER, lastValue=0, lastReportTime=Thu Oct 22 08:43:51 CEST 2020, implemented=false]
08:43:51.859 [DEBUG] [.converter.ZigBeeBaseChannelConverter] - 00158D00031492CE: Channel zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_illuminance updated to 0.0
08:43:51.864 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Updating ZigBee channel state zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_illuminance to 0.0
08:43:51.872 [DEBUG] [g.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:f3174f46:00158d00031492ce
08:43:51.876 [DEBUG] [g.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:f3174f46:00158d00031492ce in 1830 seconds
08:43:51.883 [INFO ] [smarthome.event.ItemStateChangedEvent] - EG_hwr_motion_illuminance changed from 0.027069896026281848 to 0.0
08:43:51.884 [DEBUG] [al.converter.ZigBeeConverterOccupancy] - 00158D00031492CE: ZigBee attribute reports ZclAttribute [cluster=Occupancy Sensing, id=0, name=Occupancy, dataType=BITMAP_8_BIT, lastValue=1, lastReportTime=Thu Oct 22 08:43:51 CEST 2020, implemented=false]
08:43:51.887 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:f3174f46:00158d00031492ce' changed from OFFLINE to ONLINE
08:43:51.891 [DEBUG] [.converter.ZigBeeBaseChannelConverter] - 00158D00031492CE: Channel zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_occupancy updated to ON
08:43:51.894 [INFO ] [smarthome.event.ItemStateChangedEvent] - zigbee_device_f3174f46_00158d00031492ce_00158D00031492CE_1_illuminance changed from 0.027069896026281848 to 0.0
08:43:51.896 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Updating ZigBee channel state zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_occupancy to ON
08:43:51.905 [DEBUG] [g.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:f3174f46:00158d00031492ce
08:43:51.910 [DEBUG] [g.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:device:f3174f46:00158d00031492ce
08:43:51.914 [DEBUG] [g.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:f3174f46:00158d00031492ce in 1830 seconds
08:46:17.746 [INFO ] [smarthome.event.ItemStateChangedEvent] - shelly_shelly25_relay_112d41_device_accumulatedWatts changed from 0.0 W to 23.8 W
08:46:24.258 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Polling [zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_iaslowbattery, zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_illuminance, zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_tamper, zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_occupancy] channels...
08:46:24.265 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Polling zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_iaslowbattery
08:46:25.380 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Polling zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_illuminance
08:46:26.023 [INFO ] [smarthome.event.ItemStateChangedEvent] - network_device_192_168_2_1_time changed from 24.0 to 25.0
08:46:26.709 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Polling zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_tamper
08:46:27.631 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Polling zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_occupancy
Normally I would expect to see something similar, if it switched to OFF after 60 sec (which I triggered manually in this case via paperUI):
08:53:38.460 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'EG_hwr_motion' received command OFF
08:53:38.501 [INFO ] [arthome.event.ItemStatePredictedEvent] - EG_hwr_motion predicted to become OFF
08:53:38.530 [INFO ] [g.eclipse.smarthome.model.script.Info] - HWR Motion Sensor OFF rule Start
08:53:38.531 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00158D00031492CE: Command for channel zigbee:device:f3174f46:00158d00031492ce:00158D00031492CE_1_occupancy --> OFF [OnOffType]
08:53:38.540 [INFO ] [smarthome.event.ItemStateChangedEvent] - EG_hwr_motion changed from ON to OFF
If the device doesn’t send the OFF, then we can’t force this - some devices simply don’t do this and you would have to use the expire binding, or a rule to turn it off again.
But as said, with zigbee2mqtt it works as expected. I think, there is something missing in the binding.
We talk exactely about following device: https://www.zigbee2mqtt.io/devices/RTCGQ11LM.html
I’m not sure - I don’t use the binding, but I don’t really see that is relevant. Maybe the mqtt binding add special functionality for this device, but the ZigBee binding tries to work to the standards.
I don’t think so. If the device does not send an OFF command, then the binding will not provide the OFF command. This is simple for you to add this functionality if this is what you want.