[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.

[gettech]

Unfortunately I've got the same issue with my QBKG03LM with similar behaviour.

I've added it in phoscon and it apears to be recognized as a "Transmitter" with "unknown" brand and there are 2 lights and 2 on/off switches appearing, they vanish after some time as stated in the other comments here.

I'm running deconz as an addon of HomeAssistant (v6.6.2) as version 2.07.01 and my conbee is running firmware 26680700.

Are there any new news on an flawless integration? I've ordered the switch, because it was listed as compatible.

[Mimiix]

@ebaauw Can you shed some light here? I am not sure what the issue is and what we need to get it solved.

thisgoesabovemyhat.

[ebaauw]

Not really, lacking any useful info. Please list the resources that the API exposes, and please provide the usual GUI screenshots of the node with endpoints and clusters, and of the Basic cluster, having read all attributes.

What do you mean by “vanish”? Do they disappear while deCONZ is running, or do they not re-appear after restarting deCONZ? Do the endpoints and clusters look different in the GUI after restart?

[gettech]

What do you mean by “vanish”? Do they disappear while deCONZ is running, or do they not re-appear after restarting deCONZ? Do the endpoints and clusters look different in the GUI after restart?

I've restarted the addon in HA and its now shown as "Smart Plug 20", before the restart was "On/Off Light 18".

in HA:

[ebaauw]

That’s exactly the same version as I have. The API should expose two /lights resources, for endpoints 2 and 3, and one ZHASwitch resource for endpoint 4. The issue is that light resources are created before the Basic cluster has been read, so the blacklisting of endpoints 4, 5, and 6 happens on the info from the Node Descriptor and Simple Descriptors. That used to work fine, until they added support for some other unholy devices, with similar fingerprint. The switch is recognised as one of those, before all Simple Descriptors have been read, causing the additional endpoints to be exposed. You can try deleting the resources for these endpoints through the API. The node will be deleted from the GUI, but it should re-appear once the core sees traffic from it. You might need to update the name of the resource for the first end point, to update the label of the node in the GUI.

[gettech]

Thanks for the explaination.

Any chance that deconz is reacting to this behaviour in the future? The explanation sounds like its always a hit or miss till it works correctly.

Currently I've integrated it with zigbee2mqtt (and a CC251) and everything worked directly.

[ebaauw]

Any chance that deconz is reacting to this behaviour in the future?

Yes.

[FreakyMithril]

Unfortunately I've got the same issue with my QBKG03LM with similar behaviour.

I've added it in phoscon and it apears to be recognized as a "Transmitter" with "unknown" brand and there are 2 lights and 2 on/off switches appearing, they vanish after some time as stated in the other comments here.

I'm running deconz as an addon of HomeAssistant (v6.6.2) as version 2.07.01 and my conbee is running firmware 26680700.

Are there any new news on an flawless integration? I've ordered the switch, because it was listed as compatible.

If you update/revert your Conbee 2 to the version of firmware - 264a0700. It will work fully.

I had this version a long time ago, and any upper version, just does not work after 48h, switches just do not react. I try all these versions and all they have the same problem: 26660700, 26680700, 26700700.

p.s. I use HA with the current deCONZ plugin, 6.10.0. They based on deCONZ to 2.12.6.

[ReX1983]

@ebaauw did you manage to make qbkg03lm (double buttons, no neutral) work in decoupled mode?

I have enabled decoupled mode for one of the two buttons (the right one) and I can confirm it is in such mode (no relay click when pressing the button). When I press the button I see the following message in the log:

ZCL attribute report 0x00158D0001F4864F for cluster: 0x0006, ep: 0x05, frame control: 0x18, mfcode: 0x0000

From the Phoscon API I can see:

    "31": {
        "capabilities": {
            "alerts": [
                "none",
                "select",
                "lselect"
            ]
        },
        "config": {
            "groups": []
        },
        "etag": "9d408903658978b97e92657a66e60782",
        "hascolor": false,
        "lastannounced": null,
        "lastseen": "2023-02-16T17:43Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.ctrl_neutral2",
        "name": "Ground Stairs Light Switch",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "On/Off light",
        "uniqueid": "00:15:8d:00:01:f4:86:4f-02"
    },
    "32": {
        "capabilities": {
            "alerts": [
                "none",
                "select",
                "lselect"
            ]
        },
        "config": {
            "groups": []
        },
        "etag": "e30111509092e78f8ca9ccf20b24194f",
        "hascolor": false,
        "lastannounced": null,
        "lastseen": "2023-02-16T17:43Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.ctrl_neutral2",
        "name": "Hallway Slave (Ground Stairs)",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "On/Off light",
        "uniqueid": "00:15:8d:00:01:f4:86:4f-03"
    },
   "84": {
        "config": {
            "on": true,
            "reachable": true,
            "temperature": null
        },
        "ep": 4,
        "etag": "bb85d6e0a8d214b31c3f9801d1840f16",
        "lastannounced": null,
        "lastseen": "2023-02-16T17:43Z",
        "manufacturername": "LUMI",
        "mode": 1,
        "modelid": "lumi.ctrl_neutral2",
        "name": "Switch 84",
        "state": {
            "buttonevent": null,
            "lastupdated": "none"
        },
        "type": "ZHASwitch",
        "uniqueid": "00:15:8d:00:01:f4:86:4f-04-0006"
    }

And in the deCONZ log I have:

But I still can't see any event in Home Assistant when pressing the button.

Any idea?

[SwoopX]

@ReX1983 Could you please open up a new issue (bug) for this one and pretty much reuse the content from your last post here? Make it for both switch versions. We can then clarify a couple of things and keep that topic cleanly seperated.

Upfront: I'd say there's a rather easy fix for it.

Thanks a lot!

[ReX1983]

@ReX1983 Could you please open up a new issue (bug) for this one and pretty much reuse the content from your last post here? Make it for both switch versions. We can then clarify a couple of things and keep that topic cleanly seperated.

Upfront: I'd say there's a rather easy fix for it.

Thanks a lot!

Thanks for the prompt response - issue created: #6758

I am afraid I create it as device request, as I can't. update it to bug, could you? Thanks!