Aqara D1 2 switch (with neutral) (Xiaomi QBKG24LM) hold & release actions and decoupled mode missing

[adorobis]

What happened

I have a few Aqara D1 2 gang smart wall switch (with neutral wire) / Xiaomi QBKG24LM devices, they are nicely connected via Conbee II but I can see only single and double push actions being exposed. Also I can't get it to change or read the operation_mode by publishing MQTT messages.

What did you expect to happen

I'm expecting the hold and release actions being exposed when long pushing the buttons. I'm also expecting the decoupled mode to be available.

How to reproduce it (minimal and precise)

Connect the device to Zigbee2MQTT, long push the button and observe MQTT (I'm using MQTT explorer). For operation mode read publish a message to topic: zigbee2mqtt/Bathroom Lights Inside/get payload: {"operation_mode_right": ""} For setting the operation mode publish a message to topic: zigbee2mqtt/Bathroom Lights Inside/set payload: {"operation_mode_right": "decoupled"}

Debug info

The following messages are in the log when trying to read the operation mode:

Debug Publishing get 'get' 'operation_mode' to 'Bathroom Lights Inside'
Error Publish 'get' 'operation_mode' to 'Bathroom Lights Inside' failed: 'Error: Read 0x00158d0006d5b605/2 genBasic([65314], {"sendWhenActive":false,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
Info MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'get' 'operation_mode' to 'Bathroom Lights Inside' failed: 'Error: Read 0x00158d0006d5b605/2 genBasic([65314], {\"sendWhenActive\":false,\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"Bathroom Lights Inside"},"type":"zigbee_publish_error"}'
Info MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'get' 'operation_mode' to 'Bathroom Lights Inside' failed: 'Error: Read 0x00158d0006d5b605/2 genBasic([65314], {\"sendWhenActive\":false,\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"Bathroom Lights Inside"},"type":"zigbee_publish_error"}'

Zigbee2MQTT version: 1.20.0 commit: 41b67fdd Adapter hardware: Conbee II Adapter firmware version(revision): 0x26660700 Zigbee Model: lumi.switch.b2nacn02 Description: Aqara D1 2 gang smart wall switch (with neutral wire) Firmware build date: 10-22-2020 Manufacturer: Xiaomi Model: QBKG24LM

[adorobis]

Any news on that? How can I help in analyzing this issue?

[jusxon]

I am in a somewhat similar situation, except that my switches are US versions which never got all the full options like operation_mode.

Can you post the database.db entry for your switch? Looking at the converter for your switch (QBKG24LM) is uses xiaomi_operation_mode_basic from https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/converters/fromZigbee.js.

xiaomi_operation_mode_basic: { cluster: 'genBasic', type: ['attributeReport', 'readResponse'], convert: (model, msg, publish, options, meta) => { const payload = {}; if (model.meta && !model.meta.multiEndpoint) { const mappingMode = {0x12: 'control_relay', 0xFE: 'decoupled'}; const key = 0xFF22; if (msg.data.hasOwnProperty(key)) { payload.operation_mode = mappingMode[msg.data[key]]; } } else { const mappingButton = {0xFF22: 'left', 0xFF23: 'right'}; const mappingMode = {0x12: 'control_left_relay', 0x22: 'control_right_relay', 0xFE: 'decoupled'}; for (const key in mappingButton) { if (msg.data.hasOwnProperty(key)) { payload['operation_mode_${mappingButton[key]}'] = mappingMode[msg.data[key]]; } } } return payload; }, },

According to the above function, my switch is missing the needed attributes to work like yours is supposed to so I am curious to see your database entry. For example, my database entry looks like this;

{ "id":9, "type":"Router", "ieeeAddr":"0x04cf8cdf3c761f8e", "nwkAddr":36512, "manufId":4447, "manufName":"LUMI", "powerSource":"Mains (single phase)", "modelId":"lumi.switch.b1naus01", "epList":[ 1, 242 ], "endpoints":{ "1":{ "profId":260, "epId":1, "devId":256, "inClusterList":[ 0, 2, 3, 4, 5, 6, 9, 1794, 2820 ], "outClusterList":[ 10, 25 ], "clusters":{ "genBasic":{ "attributes":{ "modelId":"lumi.switch.b1naus01", "manufacturerName":"LUMI", "powerSource":1, "zclVersion":3, "appVersion":25, "stackVersion":2, "hwVersion":1, "dateCode":"09-06-2019" } }, "genOnOff":{ "attributes":{ "onOff":0 } }, "genScenes":{ "attributes":{ "count":0 } }, "genIdentify":{ "attributes":{ "identifyTime":0 } }, "haElectricalMeasurement":{ "attributes":{ "measurementType":8, "activePower":0 } } }, "binds":[ { "cluster":6, "type":"endpoint", "deviceIeeeAddress":"0x00124b00237dfbd3", "endpointID":242 }, { "cluster":6, "type":"endpoint", "deviceIeeeAddress":"0x00124b00237dfbd3", "endpointID":1 } ], "configuredReportings":[ { "cluster":6, "attrId":0, "minRepIntval":0, "maxRepIntval":3600, "repChange":0 } ], "meta":{ } }, "242":{ "profId":41440, "epId":242, "devId":97, "inClusterList":[ ], "outClusterList":[ 33 ], "clusters":{ }, "binds":[ ], "configuredReportings":[ ], "meta":{ } } }, "appVersion":25, "stackVersion":2, "hwVersion":1, "dateCode":"09-06-2019", "zclVersion":3, "interviewCompleted":true, "meta":{ "configured":1 }, "lastSeen":1639203129752 }

I have seen several issues reports with Aqara devices where new firmware (dateCode) is breaking functionality. like this one where it looks like the attribute has changed locations (at least it has for my plugs) so that the sensor now shows null.

I am still fairly new to this, but I plan on trying to sniff my switches like they did here so I can try to get support working for the rest of their functionality like decoupled mode. This may be necessary to do for your switch as well if new firmware has changed the way it works.

[adorobis]

Here it is: {"id":14,"type":"Router","ieeeAddr":"0x00158d0006d5b605","nwkAddr":48859,"manufId":4447,"manufName":"LUMI","powerSource":"Mains (single phase)","modelId":"lumi.switch.b2nacn02","epList":[1,2,3,4,5,6,7],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[0,4,3,6,16,5,10,1,2],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"65281":{"3":30,"5":32,"8":4159,"9":1793,"100":0,"101":0,"149":1.0116310119628906,"152":0,"154":0},"65314":18,"65520":{"type":"Buffer","data":[170,16,5,65,135,1,1,16,0]},"modelId":"lumi.switch.b2nacn02","appVersion":1,"manufacturerName":"LUMI","powerSource":1,"zclVersion":1,"stackVersion":2,"hwVersion":18,"dateCode":"10-22-2020"}},"genOnOff":{"attributes":{"61440":62839552,"onOff":0}}},"binds":[],"configuredReportings":[],"meta":{}},"2":{"profId":260,"epId":2,"devId":81,"inClusterList":[6,16],"outClusterList":[],"clusters":{"genOnOff":{"attributes":{"61440":117440557,"onOff":0}}},"binds":[],"configuredReportings":[],"meta":{}},"3":{"profId":260,"epId":3,"devId":9,"inClusterList":[12],"outClusterList":[12,4],"clusters":{"genAnalogInput":{"attributes":{"presentValue":0}}},"binds":[],"configuredReportings":[],"meta":{}},"4":{"profId":260,"epId":4,"devId":83,"inClusterList":[12],"outClusterList":[12],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}},"5":{"profId":260,"epId":5,"devId":0,"inClusterList":[16,18],"outClusterList":[],"clusters":{"genMultistateInput":{"attributes":{"presentValue":1}}},"binds":[],"configuredReportings":[],"meta":{}},"6":{"profId":260,"epId":6,"devId":0,"inClusterList":[18,16],"outClusterList":[],"clusters":{"genMultistateInput":{"attributes":{"presentValue":1}}},"binds":[],"configuredReportings":[],"meta":{}},"7":{"profId":260,"epId":7,"devId":0,"inClusterList":[18,16],"outClusterList":[],"clusters":{"genMultistateInput":{"attributes":{"presentValue":1}}},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":1,"stackVersion":2,"hwVersion":18,"dateCode":"10-22-2020","zclVersion":1,"interviewCompleted":true,"meta":{},"lastSeen":1639251571781}

[jusxon]

From what I can tell that looks right, but I do not know how you would determine if there has been a change with the recent firmware build.

[jusxon]

Looking at your error log again, have you tried to re-pair and/or reconfigure the switch to Z2M? I would try that and see if you get the same error.

If you absolutely need the full functionality of the switch and have an Aqara or Xiaomi hub you can do what I am doing for now and add just those switches through the Aqara or Mi Home app to your hub now that there are ways to connect HA native Aqara integration with several hubs. I am using this method to enable telnet on an Aqara M1S and it works great — see screenshot for how all the sensors show up and the button sensor receives the action of the button when you have enabled decoupled mode from the Aqara or Mi Home app. You may check this out as well as your switch seems supported.

Seems like because of all the issues with some Aqara devices, like not being fully Zigbee compliant and firmware updates breaking functionality, this may be a better option — I have a couple of switches that need decoupled mode and Z2M currently only supports switch state.

[adorobis]

Actually after the last HA update (also updated earlier to the latest zigbee2mqtt as well) I can see some additional controls in HA: Interestingly I still don't see those options in ziggbee2mqtt: but the state shows it all nicely: I'll test it a bit now and see what can be achieved. Ideally I'd like to bind now the button to the relay so on one hand I would be able to normally switch on the light and also capture those extra button presses.

[adorobis]

Just tested it. Indeed when in decoupled mode it is not controlling the relay anymore but still only single and double clicks are being sent. No hold or release actions.

[madmurl0c]

Just tested it. Indeed when in decoupled mode it is not controlling the relay anymore but still only single and double clicks are being sent. No hold or release actions.

I am experiencing the same issue. Holding the right button just triggers the "single_right" action. Any news on this?

Edit: Here's some debug output from testing:

Hold right

Zigbee2MQTT:debug 2022-02-12 12:18:41: Received Zigbee message from 'bedroom_switch', type 'attributeReport', cluster 'genMultistateInput', data '{"presentValue":1}' from endpoint 6 with groupID 0

Zigbee2MQTT:info 2022-02-12 12:18:41: MQTT publish: topic 'zigbee2mqtt/bedroom_switch', payload '{"action":"single_right","linkquality":99,"operation_mode_right":"decoupled","power":0,"state_left":"OFF","state_right":"OFF"}'

Zigbee2MQTT:info 2022-02-12 12:18:41: MQTT publish: topic 'zigbee2mqtt/bedroom_switch', payload '{"action":"","linkquality":99,"operation_mode_right":"decoupled","power":0,"state_left":"OFF","state_right":"OFF"}'

Zigbee2MQTT:info 2022-02-12 12:18:41: MQTT publish: topic 'zigbee2mqtt/bedroom_switch/action', payload 'single_right'

Double right (works) Zigbee2MQTT:debug 2022-02-12 12:20:27: Received Zigbee message from 'bedroom_switch', type 'attributeReport', cluster 'genMultistateInput', data '{"presentValue":2}' from endpoint 6 with groupID 0

Zigbee2MQTT:info 2022-02-12 12:20:27: MQTT publish: topic 'zigbee2mqtt/bedroom_switch', payload '{"action":"double_right","linkquality":99,"operation_mode_right":"decoupled","power":0,"state_left":"OFF","state_right":"OFF"}'

Zigbee2MQTT:info 2022-02-12 12:20:27: MQTT publish: topic 'zigbee2mqtt/bedroom_switch', payload '{"action":"","linkquality":99,"operation_mode_right":"decoupled","power":0,"state_left":"OFF","state_right":"OFF"}'

Zigbee2MQTT:info 2022-02-12 12:20:27: MQTT publish: topic 'zigbee2mqtt/bedroom_switch/action', payload 'double_right'

Tripple right No event/log triggered

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[adorobis]

Not solved yet. Unstale.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[adorobis]

Unstale

[mpashka]

Hello. I've recently bought Xiaomi Aqara D1 2 gang smart wall switch (with neutral wire) aka QBKG24LM. And I have exactly the same problem - switch doesn't expose the following actions: hold_left, release_left, hold_right, release_right, hold_both, release_both It exposes only single_left, double_left, single_right, double_right, single_both, double_both. I've bought this QBKG24LM especially to enable some additional actions from my wall switch but this problem makes it almost useless. I enabled zigbee2mqtt and herdsman logs, switched off some other devices to prevent log pollution and did several actions: switch on/off for left & right button, then switch on, then double click, then hold. So is there any possibility to find out what is the problem - why aren't actions triggered correctly. I'm using docker version koenkk/zigbee2mqtt:1.23.0.

Device

Device type: Router Zigbee Model: lumi.switch.b2nacn02 Zigbee Manufacturer: LUMI Description: Aqara D1 2 gang smart wall switch (with neutral wire) Support status: Supported IEEE Address: 0x00158d0005049bc1 Network address: 0x7D02 Firmware build date: 09-17-2021 Manufacturer: Xiaomi Model: QBKG24LM

Adapter hardware

SONOFF Zigbee 3.0 USB Dongle Plus Zigbee2MQTT version: 1.23.0 commit: 6ea61ba Coordinator type: zStack3x0 Coordinator revision: 20210708 Coordinator IEEE Address: 0x00124b00258d6052

xiaomi_switch_actions-1.23.0.zip

[mpashka]

After upgrading zigbee2mqtt to the latest version I've started to receive hold data messages that can be used to recognize hold action({"65520":{"data":[170,16,5,65,135,1,1,16,0],"type":"Buffer"}}), but I suppose this is still not the best solution.

Adapter hardware

Zigbee2MQTT version: 1.25.1 commit: 3f6a1378 Coordinator type: zStack3x0 Coordinator revision: 20210708 Coordinator IEEE Address: 0x00124b00258d6052

Z2m logs during for hold action (previos events/actions like single click, power change are omited)

z:a:zStack:unpi:parser <-- [254,38,68,129,0,0,0,0,2,125,1,1,0,36,0,38,197,211,0,0,18,28,95,17,178,10,240,255,65,9,170,16,5,65,135,1,1,16,0,203,82,28,219]
z:a:zStack:unpi:parser --- parseNext [254,38,68,129,0,0,0,0,2,125,1,1,0,36,0,38,197,211,0,0,18,28,95,17,178,10,240,255,65,9,170,16,5,65,135,1,1,16,0,203,82,28,219]
z:a:zStack:unpi:parser --> parsed 38 - 2 - 4 - 129 - [0,0,0,0,2,125,1,1,0,36,0,38,197,211,0,0,18,28,95,17,178,10,240,255,65,9,170,16,5,65,135,1,1,16,0,203,82,28] - 219
z:a:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":0,"srcaddr":32002,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":36,"securityuse":0,"timestamp":13878566,"transseqnumber":0,"len":18,"data":{"type":"Buffer","data":[28,95,17,178,10,240,255,65,9,170,16,5,65,135,1,1,16,0]}}
z:c:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":178,"manufacturerCode":4447,"commandIdentifier":10},"Payload":[{"attrId":65520,"dataType":65,"attrData":{"type":"Buffer","data":[170,16,5,65,135,1,1,16,0]}}],"Command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}},"address":32002,"endpoint":1,"linkquality":36,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
Zigbee2MQTT:debug Received Zigbee message from '0x00158d0005049bc1', type 'attributeReport', cluster 'genBasic', data '{"65520":{"data":[170,16,5,65,135,1,1,16,0],"type":"Buffer"}}' from endpoint 1 with groupID 0
z:controller:endpoint Write 0x00158d0005049bc1/1 genBasic({"65520":{"value":[170,16,5,65,71,1,1,16,1],"type":65}}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false})
z:a:zStack:adapter sendZclFrameToEndpointInternal 0x00158d0005049bc1:32002/1 (0,0,1)
z:a:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":32002,"destendpoint":1,"srcendpoint":1,"clusterid":0,"transid":5,"options":0,"radius":30,"len":18,"data":{"type":"Buffer","data":[20,95,17,4,2,240,255,65,9,170,16,5,65,71,1,1,16,1]}}
z:a:zStack:unpi:writer --> frame [254,28,36,1,2,125,1,1,0,0,5,0,30,18,20,95,17,4,2,240,255,65,9,170,16,5,65,71,1,1,16,1,252]
z:a:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:debug Converted to {}
z:a:zStack:unpi:parser <-- [254,1,100,1,0,100]
z:a:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
z:a:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
z:a:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
z:a:zStack:unpi:parser --- parseNext []
z:a:zStack:unpi:parser <-- [254,3,68,128,0,1,5,195]
z:a:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,5,195]
z:a:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,5] - 195
z:a:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":5}
z:a:zStack:unpi:parser --- parseNext []
z:a:zStack:unpi:parser <-- [254,26,68,129,0,0,0,0,2,125,1,1,0,66,0,159,210,211,0,0,6,28,95,17,4,4,0,2,125,29,74]
z:a:zStack:unpi:parser --- parseNext [254,26,68,129,0,0,0,0,2,125,1,1,0,66,0,159,210,211,0,0,6,28,95,17,4,4,0,2,125,29,74]
z:a:zStack:unpi:parser --> parsed 26 - 2 - 4 - 129 - [0,0,0,0,2,125,1,1,0,66,0,159,210,211,0,0,6,28,95,17,4,4,0,2,125,29] - 74
z:a:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":0,"srcaddr":32002,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":66,"securityuse":0,"timestamp":13882015,"transseqnumber":0,"len":6,"data":{"type":"Buffer","data":[28,95,17,4,4,0]}}
z:c:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":4,"manufacturerCode":4447,"commandIdentifier":4},"Payload":[{"status":0}],"Command":{"ID":4,"name":"writeRsp","parameters":[{"name":"status","type":32},{"name":"attrId","type":33,"conditions":[{"type":"statusNotEquals","value":0}]}]}},"address":32002,"endpoint":1,"linkquality":66,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
z:a:zStack:unpi:parser --- parseNext []

Full zigbee2mqtt configuration and logs attached: xiaomi_QBKG24LM_switch_actions-1.25.1.zip

[mpashka]

Examination of github://zigbee-herdsman-converters/converters/fromZigbee.js#xiaomi_operation_mode_basic gave me an idea that genBasic/data/"65520":[Buffer] is still valid response from QBKG24LM. My long tap response has 0xFFF0 (65520) data.OwnPropertyKey. But it looks that button info is not passed - we always have the same byteBuffer[170,16,5,65,135,1,1,16,0] and the same endpoint ID 1. And I'm not even sure this is long tap. But at least now I'm able to catch and process long tap without button recognition. It is possible to save last button id and state from original click action and then use it to convert my hold into hold on->off, hold off->on and hold_left, hold_right - not sure if this is good solution.

But I still hope it is possible to recognize button by proper zigbee response parsing and catch release action. Probably later will try to connect QBKG24LM to xiaomi switch and dump some data but I'm newbie in this and have zero competence in zigbee protocol parsing so if there is somebody that can help please give me hand.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[adorobis]

Unstale

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[adorobis]

Unstale

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[webtoucher]

Unstale

[adorobis]

Is there any progress with this one to bring the hold and release actions?

[Koenkk]

@z-x-f if I understood you correctly, the device does not support this right?

[z-x-f]

@z-x-f if I understood you correctly, the device does not support this right?

Yes, many of aqara's switches enter the initialization state by long pressing the button. I think it is for this reason that the release function is not provided.

[adorobis]

Indeed it is the long press that triggers the initialization state although should be over 10s. Anyway if that is confirmed not to be possible, only the device description could be updated to remove the hold and release actions.

[adorobis]

I've opened a PR to update the documentation: https://github.com/Koenkk/zigbee2mqtt.io/pull/1601