Deconz-rest-plugin: [Device Support Request] Aqara QBKG03LM - Smart Switch without neutral, 2 rockers

[ychieux]

Hello there,
I recently ordered from AliExpress 2 * AQARA QBKG03LM. These are type 86 smart switch with 2 rockers / buttons and work without neutral wire.

When attempting to join them using Phoscon, the "Add Switch" function does not detect them while "Add Sensor" detects them allowing (i.e. button turns to "Ready" state) but no new light / switch / sensor gets listed under Phoscon.

Using Deconz view, the following node and cluster info are available:

The device exposed by the REST API is not recognized by Homebridge as switch or light.

Please let me know if you need any additional information.

[ebaauw]

Can you post the screenshot of the _Basic_ cluster, after reading all the attributes (double-click on each attribute for the popup window and press the _Read_ button).

Can you attach the debug dump file that homebridge-hue created (see https://github.com/ebaauw/homebridge-hue#debug-dump-file). That file lists the resources as exposed by the REST API plugin.

It resembles my lumi.ctrl_neutral2 switches, but mine have more endpoints. deCONZ should expose it as two /lights resources (endpoints 2 and 3) and one ZHASwitch /sensors resource (endpoint 4). homebridge-hue should create a single accessory (which it seems to have done), with two _Lightbulb_ and one _Stateless Programmable Switch_ service.

[victor-mikhalev]

Same here, unable to add this switch.

[ychieux]

@ebaauw Thank you very much looking into it.

Please find hereafter the relevant section of homebridge-hue debug file:

            "26": {
               "config": {
                  "on": true,
                  "reachable": true,
                  "temperature": 3300
               },
               "ep": 4,
               "etag": "7296ca7752dfdda2f3a8b39f35504464",
               "manufacturername": "LUMI",
               "mode": 1,
               "modelid": "lumi.ctrl_neutral2",
               "name": "lumi.ctrl_neutral2",
               "state": {
                  "buttonevent": 2002,
                  "lastupdated": "2019-11-08T11:43:27"
               },
               "swversion": "04-25-2018",
               "type": "ZHASwitch",
               "uniqueid": "00:15:8d:00:03:a2:d2:29-04-0006"
            }

and here is the basic cluster with all parameters:

[ebaauw]

Please attach the full debug dumpfile.

[ychieux]

2 light bulbs appeared after forcing the switch to reconnect to the zigbee network while using Phoscon App "Add Light".
Note: these lights cannot be operated (i.e. On/Off) using Phoscon but Homebridge now sees 2 switches. Control thru homebridge works fine.

What other section of the dump file are you interested into? (Sorry but I'm not keen on sharing publicly all details of my Zigbee setup)

[jurgen-kluft]

I have the same switch (lumi.ctr_neutral2) at home, and just bought the Conbee-2 (arrived yesterday). Tried to add this switch, it is shown in the deConz application on my Raspberry PI3 but 'unknown'. It does add 4 light devices which is incorrect since it is a switch.
| Smart plug 3 | Unknown | Unknown
  | Smart plug 4 | Unknown | Unknown
  | On/Off light 5 | Unknown | Unknown
  | On/Off light 6 | Unknown | Unknown

Hope this can be supported soon :-)

[ltsalvatore]

hi there..
is there any chance of getting this device (QBKG03LM) connected via deconz conbee2?
i have bought the conbee2 with the hope of replacing the mija hub which i use for my xiaomi zigbee devices.

unfortunately this wall switch is the most important device that has to work with conbee2. otherwise i have to find another solution and return the stick back, which would be a shame....

[logiclabs]

Same here.

[shizlkazizl]

Same problem.

[LouisHerber]

Same here. It does work / is supported with Zigbee2Mqtt, but would rather like to have it in Phoscon/Conbee.

[ychieux]

Dears, I noticed that the support for some Aqara switches was added into the release of 2.05.75.

How could I practically contribute to get the single and two rockers (no neutral) switches properly supported?

[ReX1983]

I have about 25 QBKG03LM (lumi.ctrl_neutral2 - double rockers) and QBKG04LM (lumi.ctrl_neutral1 - single rocker) devices. The switches are 3 years old and they worked flawlessly with the Xiaomi Gateway v2 (I have 3 gateways, due to the number of Xiaomi devices connected). I wanted to get rid of the Xiaomi (*3), Ikea and Philips gateways, hence my (in progress migration) to Deconz / ConBee II.

My setup is Deconz 2.05.74, ConBee II 264A0700 (marthoc docker container). I will update to .75 once the new ConBee II firmware to fix the Ikea Tradfri issues is available.

All the QBKG03LM and QBKG04LM switches work with Deconz using the REST API exposed to Home Assistant but there are many caveats and unexpected behaviours:

1. Following discovery, each switch (both QBKG03LM and QBKG04LM) is reported in Phoscon as 4 devices (2 plugs and 2 lights). Of these 4 devices, the only one(s) working is one switch in case of QBKG04LM and two switches for QBKG03LM. Due to the amount of duplicated devices, it gets messy in both Phoscon and Home Assistant. To avoid getting confused I gave to these "useless" devices a suffix and then disabled them in Home Assistant (e.g. Bathroom, Bathroom A, Bathroom, Bathroom B, Bathroom C - where A, B, C are disabled).

2. All the above devices are in the Phoscon Light section

3. Vendor and model is Unknown

4. Following reboot of Deconz, some of these "unnecessary" A, B, C devices disappear in Phoscon.

5. In the VNC Deconz interface, the nodes are sometime called Bathroom, sometime Bathroom A, sometime Bathroom C, sometime Bathroom B. It seems random how Deconz decides to label the node.

6. Following reboot of Deconz, one of the QBKG03LM (lumi.ctrl_neutral2 - double rockers) went offline and the only way to make it work again was to remove it from Phoscon and pair it again.

7. In one occasion, one QBKG03LM (lumi.ctrl_neutral2 - double rockers) switch "got mixed" with a Xiaomi Transmitter 2-gang WXKG02LM. After pairing a battery operated WXKG02LM, one QBKG03LM reported a new entity in the Home Assistant core.entity_registry file, with the QBKG03LM MAC address concatenated to the battery suffix typical of WXKG02LM. I can't really explain how this happened. My guess was that the QBKG03LM acted as router and Decoz assumed that a cluster of WXKG02LM belonged to QBKG03LM but I have to admit that I don't know enough of the Zigbee protocol plus the QBKG03LM model is not a router.

Beside the above points, the switches operate fast with Deconz, same speed reactivity of using a Xiaomi gateway, but the stability seems an issue (see point 6).

@ebaauw I am happy to help with further debug and info, if needed.

[alexbohariuc]

Any idea if this works? Or are there any other alternatives (no neutral) switches?

[ebaauw]

I have three lumi.ctrl_neutral2 switches in my network. They've been stable, without any issue at all, since 2018, after implementing the _Time_ cluster for the coordinator in the REST API (see #757). To be honest, I don't remember if I had to do any manual tweaking after joining the devices.

I can only help with the REST API plugin; Phoscon is not open source and I don't use it, so I cannot help with that app. For debugging the REST API plugin:

• Please familiarise yourselves with the GUI (see the User Manual under _Help_) and with the API (see http://dresden-elektronik.github.io/deconz-rest-doc/). You will need to interact with both. I prefer to use ph (bundled with Homebridge Hue) to interact with the API, but any REST API client (even curl) will do;
• Please provide screenshots from the deCONZ GUI, showing the node, including the endpoints and clusters, the _Node Descriptor_, and the _Basic_ cluster attributes (make sure to read them all). Xioami tend to change silently the hardware and firmware of their devices, so a newer version of the "same" device might all of a sudden not work;
• Please provide a listing of the REST resources that the REST API plugin has created for the device. If you use Homebridge Hue, the debug dump file will do fine, otherwise please capture the output of a GET of /api/_username_ to a file and attach that file.

Some background info on these switches:

• The API should expose two /lights resources for the output wire(s) (endpoints 0x02 and 0x03), and one ZHASwitch /sensors resource for the rocker(s) (endpoints 0x04, 0x05, and 0x06). There's nothing exposable on endpoints 0x01 and 0x08;
• The lumi.ctrl_neutral1 has the same fingerprint as the lumi.ctrl_neutral2; they can only be told apart by the _Model Indentifier_ attribute in the _Basic_ cluster. Unfortunately, this field has not yet been read when /lights resources are created, so the lumi.ctrl_neutral1 gets a superfluous /lights resource for endpoint 0x03. I think, currently, the only remedy is to delete this resource from the database. To fix this, the whole pairing logic would need to be re-designed. This is long overdue anyways, but I don't see this happening before APIv2;
• The _Basic_ cluster is on endpoint 0x01, which is not exposed as a REST API resource. The attributes should be used by for the resources related to the other endpoints, but they might not be read in time automatically. You probably need to read these attributes in the GUI while the network is still open, to populate the modelid and manufacturername attributes.
• These switches ping the _Time_ cluster on the coordinator and reboot when they don't get an answer. Make sure that cluster (0x000A) is configured under endpoint 0x01 of the coordinator. If not, add it to the _Out Clusters_ in the _Endpoints_ tab of the _deCONZ Network Settings_ popup window in the GUI;
• Despite the _Groups_ clusters on endpoints 0x02 and 0x03, these switches do not react to group commands;
• The _Multistate Input_ clusters on endpoints 0x04, 0x05, and 0x06 indicate whether the left, right, or both rockets where pressed/released. These are combined in a single ZHASwitch /sensors resource, with buttonevent values 1002, 2002, and 3002. The lumi.ctrl_neutral1 only uses endpoint 0x04 and only raises 1002. I'm not sure how useful this ZHASwitch resource is; I don't think the rockers on these switches can be detached from the wires (like for the lumi.ctrl_ln switches).
• I never checked for these switches, but other Xioami end devices to not pick a new parent when their parent is missing. Make sure to keep your Zigbee routers (yellow nodes in the GUI) powered at all times. In particular, don't use 20th century wall switches to power off your smart lights.

[froggy974]

same problem for me,
i have a QBKG03LM and i was unable to make it work in conbee 1 .
i hope it will be integrated soon.
If i can help to provide information on this device , let me know what i should do to provide it

[dxxxm]

@ebaauw Time cluster 0x000A to be configured under either In or Out cluster or perhaps both ?
#774 suggests to add time cluster to In cluster if missing

[ebaauw]

In. It must be added as server (blue) cluster.

[ReX1983]

@ebaauw , I just realised that one of my lumi.ctrl_neutral2 is unreachable, even if it is showed as online in Home Assistant and in Phoscon. In the deCONZ GUI the node is showed but there is no green line and it does not react to any toggle command.

Do you know what I can do to reestablish connection without the need to remove the device from deCONZ / Phoscon and repair from scratch?

Regarding the time cluster, I wonder how my switches worked so far without it: does it mean they keep rebooting since months?

[ebaauw]

Regarding the time cluster, I wonder how my switches worked so far without it: does it mean they keep rebooting since months?

Mine did (which could very well be the cause of your unreachable status). Could also be a different firmware? I haven't sniffed these for a long while. You should be able to see the _Device Announcement_ messages in the deCONZ log (when started with enough debug options).

Do you know what I can do to reestablish connection without the need to remove the device from deCONZ / Phoscon and repair from scratch?

Power-cycling the switch should be enough to bring to back online. You might need to use the breaker for that. You might try hitting the 0 while the node is selected in deCONZ.

[ReX1983]

So your switches were rebooting all the time? How frequently?

Mine are HW version 38, date code 11-25-2017, stack version 2, application version 21.

Power cycling (both the device and deCONZ) didn't work but the 0 button worked: I wonder if this function could be exposed via the REST API so I can call it from Home Assistant on daily basis.

Do you know if the NWK address request broadcast also resuscitate the Tradfri bulbs becoming unreachable?

[ebaauw]

So your switches were rebooting all the time? How frequently?

Every one to two minutes or so. See #757.

Mine are HW version 38, date code 11-25-2017, stack version 2, application version 21.

I have two of these (for which I needed to implement the _Time_ cluster):

And one of these (which I got later - never bothered to sniff it, I guess):

Power cycling (both the device and deCONZ) didn't work

Power cycling deCONZ is almost always a bad idea on connectivity problems. Mostly the coordinator has lost the route to the device, s it needs a sign of life from it, to re-establish a route. Powercyling the device causes it to send a _Device Announcement_ message, hitting 0 causes it send a message announcing it's NWK address. These messages (should) trigger the coordinator. Note that routing is handled by the RaspBee/ConBee firmware.

Do you know if the NWK address request broadcast also resuscitate the Tradfri bulbs becoming unreachable?

That depends on what's causing it. If the device still reacts to broadcasts (so is still working normally) there's a good change it might. The the device firmware hangs, you need to power cycle it. If the device has left the network (lost the network key), you'll need to reset and re-pair it. Best do so without removing it from deCONZ.

[ReX1983]

So your switches were rebooting all the time? How frequently?

Every one to two minutes or so. See #757.

Interesting.
I think that the Xiaomi approach is the reason for which Xiaomi devices never ever require a reboot (some of them, connected to the Xiaomi Gateway are online since 4 years), as they self reboot themselves when they assume the connection is lost. I wish Ikea did something similar, as their lights are the most unstable device I have ever tried.

Power cycling deCONZ is almost always a bad idea on connectivity problems. Mostly the coordinator has lost the route to the device, s it needs a sign of life from it, to re-establish a route. Powercyling the device causes it to send a _Device Announcement_ message, hitting 0 causes it send a message announcing it's NWK address. These messages (should) trigger the coordinator. Note that routing is handled by the RaspBee/ConBee firmware.

Thanks, good to know.

[ychieux]

Hello there, now that the Opple Switches are properly supported, I would really like to dump my Aqara Hub altogether and rely solely on my Conbee II.... but I have over a dozen of QBKG03LM and QBKG04LM (single rocker, no neutral) that are not properly supported by Deconz (and by extension by Homebridge-hue...)

Currently, the double rocker is listed as 2 outlets and 2 dummy lights on Homekit.

I am willing to get my hands dirty but would really appreciate some guidance to know from where to start.

Note: I have a spare Conbee II to tinker with.

[Mimiix]

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!

[ychieux]

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!

How can you close it saying it’s resolved since the last post is 10 days old and states that the devices are still not supported...

[Mimiix]

I missed that one ;) Sorry.

[iloveemma]

Hi, is this going to be added?

[Mimiix]

@ebaauw As it's suddenly a very hot switch and you seem to be doing stuff with this one, can you add some info here? What do we need to do to get this added?

[ebaauw]

They have already been added literally years ago. See my remarks above.

[ychieux]

They have already been added literally years ago. See my remarks above.

@ebaauw

Sorry but I'll have to contradict you on this, QBKG03LM and QBKG04LM are not properly supported by Phoscon / Deconz.

QBKG03LM (2 rockers) is seen as 4 devices i.e. 2 smart plugs that are functional and 2 dummy lightbulbs. The same dummy lightbulbs are exposed to homekit thru homebridge-hue

Same problem of ghost/dummy lightbulb goes for QBKG04LM (1 rocker)

[ebaauw]

I'm sorry, I cannot comment on Phoscon: it's not open source and I don't use it. Please open an issue in the Phoscon repo.

As I've asked above, several times, please list all the four (?) REST API resources that are created for this device, or attach the debug dump file created by Homebridge Hue. I don't understand where the two smart plugs come from; the switches should be exposed as two /lights resources and one ZHASwitch /sensors resource. The uniqueid of the /lights resources should end in -02 and -03; that for the /sensors resource in -04-0006.

As I've stated above, the single rocker switch is exposed the same as the dual rocker switch. The -03 /lights resource is mute. I'm more than happy to call this a bug, but I cannot solve it. Same for the unknown manufacturername and/or modelid: reading the _Basic_ cluster attributes in the GUI should populate these. A real fix requires refactoring the whole pairing logic.

[ychieux]

I'm sorry, I cannot comment on Phoscon: it's not open source and I don't use it. Please open an issue in the Phoscon repo.

I don't use it either other than for pairing devices.

As I've asked above, several times, please list all the four (?) REST API resources that are created for this device, or attach the debug dump file created by Homebridge Hue. I don't understand where the two smart plugs come from; the switches should be exposed as two /lights resources and one ZHASwitch /sensors resource. The uniqueid of the /lights resources should end in -02 and -03; that for the /sensors resource in -04-0006.

Strangely enough the ghost lights are gone for the two rockers QBKG03LM... I did restart deconz recently this might have fixed it...

The two bulbs though are still exposed as outlets/ smart plugs.

/lights
"14": { "etag": "d775ce9161c092b20668d53be3ce3bdc", "hascolor": false, "lastseen": "2020-06-09T17:47:01.877", "manufacturername": "Unknown", "modelid": null, "name": "Parents Bathroom Recessed Lights", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "Smart plug", "uniqueid": "00:15:8d:00:03:59:91:ac-02" }, "16": { "etag": "2fd53a42223096c51a00fe7e6aa285c4", "hascolor": false, "lastseen": "2020-06-10T12:08:07.628", "manufacturername": "Unknown", "modelid": null, "name": "Parents Bathroom Mirror Lights", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "Smart plug", "uniqueid": "00:15:8d:00:03:59:91:ac-03" },
/sensors
"29": { "config": { "on": true, "reachable": true, "temperature": 3500 }, "ep": 4, "etag": "2fd53a42223096c51a00fe7e6aa285c4", "lastseen": "2020-06-10T13:22:01.142", "manufacturername": "LUMI", "mode": 1, "modelid": "lumi.ctrl_neutral2", "name": "Switch 29", "state": { "buttonevent": 2002, "lastupdated": "2020-06-10T12:08:07.961" }, "swversion": "04-25-2018", "type": "ZHASwitch", "uniqueid": "00:15:8d:00:03:59:91:ac-04-0006" },

As I've stated above, the single rocker switch is exposed the same as the dual rocker switch. The -03 /lights resource is mute. I'm more than happy to call this a bug, but I cannot solve it. Same for the unknown manufacturername and/or modelid: reading the _Basic_ cluster attributes in the GUI should populate these. A real fix requires refactoring the whole pairing logic.

The ghost light bulb is now only shown for the single rocker QBKG04LM.

/lights
"19": { "etag": "43ad9f5b42ed59351288b110a1223955", "hascolor": false, "lastseen": "2020-06-10T13:10:26.934", "manufacturername": "Unknown", "modelid": null, "name": "Parents Bedroom Center Light", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "Smart plug", "uniqueid": "00:15:8d:00:03:5b:53:55-02" }, "20": { "etag": "ac24acdb51123169d3722cdbddbf493e", "hascolor": false, "lastseen": "2020-06-10T13:10:26.934", "manufacturername": "Unknown", "modelid": null, "name": "On/Off light 20", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "On/Off light", "uniqueid": "00:15:8d:00:03:5b:53:55-03" },
/sensors
"31": { "config": { "on": true, "reachable": true, "temperature": 2800 }, "ep": 4, "etag": "e742e05630d59f18ddb16bd40032a199", "lastseen": "2020-06-10T13:25:20.741", "manufacturername": "LUMI", "mode": 1, "modelid": "lumi.ctrl_neutral1", "name": "Switch 31", "state": { "buttonevent": 1002, "lastupdated": "2020-06-09T12:03:49.060" }, "swversion": "04-25-2018", "type": "ZHASwitch", "uniqueid": "00:15:8d:00:03:5b:53:55-04-0006" },

Honestly I would be happy with a workaround preventing the ghost bulb (refer to resource 20) to be exposed to homekit. I have 14 single rockers, so I ended up buying a hub (and 2 smart plugs to extend the network) as the ghost bulbs in homekit are rather annoying.

homebridge-hue.json.gz

[ebaauw]

Thanks for the info.

What do the devices look like in deCONZ GUI? In particular, the device types on end points 02 and 03. One of my lumi.ctrl_neutral2 switches has the same firmware as yours (_Date Code_ 04-25-2018), but shows _On/off light_ in the GUI and in the resource.

Interestingly, the numb resource on your lumi.ctrl_neutral does show as _On/Off light_.

I really need to see the ghost resources to understand what's happening. I would theorise the descriptors haven't been read in full, when the resources are created. As I said before, the /lights resources are created before the _Basic_ cluster has been read. The device is recognised by its Mac address, vendor ID, and large number of simple descriptors:

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/ff62b9415a0b454fb4167989144dfd5ce0a187a1/de_web_plugin.cpp#L1754-L1763

I with think the addition of the check for the number of endpoints for the Immax IM-Z3.0-DIM (see #1324) might cause issues when the resources are created before at least 5 descriptors have been read.

/lights resource are re-created on restart (rather than loaded from the database like /sensors resources), but the device info is persisted in the database. That would explain why the ghost resources disappear on restart.

Honestly I would be happy with a workaround preventing the ghost bulb (refer to resource 20) to be exposed to homekit

Create a blacklist resourcelink, see Homebridge Hue README.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.