Deconz-rest-plugin: Xiaomi Aqara Wall Switches

[mathos77]

Hi @manup,

I have ordered these Xiaomi single and double key switches, which are powered by mains.
https://www.gearbest.com/alarm-systems/pp_610096.html?utm_source=email_sys&utm_medium=email&utm_campaign=shipping
https://www.gearbest.com/alarm-systems/pp_625774.html?utm_source=email_sys&utm_medium=email&utm_campaign=shipping

I was hoping to find these supported as being a light (on-off) as they should have this capability.

After joining them into deCONZ, I see this:

Can we get these switches supported, as it would greatly improve my home automation, for places where I do not want a real smart light, so in this case it would become a semi-smart light.

Thanks!

Kind regards, Tom.

[ebaauw]

I was hoping to find these supported as being a light (on-off) as they should have this capability.

Looks like they do - see endpoint 0x03.

Can we get these switches supported, as it would greatly improve my home automation, for places where I do not want a real smart light, so in this case it would become a semi-smart light.

I'd expect the REST API to create already an on/off light for this? Did you open the network from the _Settings_ in the Web app, or from the deCONZ GUI? The REST API will only create a resource when you open the network from the Web app.

Could you open the Cluster Info panel on the _Basic_ cluster on endpoint 0x01, _Read_ the attributes, and post a screenshot? It might take a couple of attempts, but as this switch is mains powered it might work straight away. We would especially need the _Manufacturer Name_ and the _Model Identifier_. If they work like the other Xiaomi switches, you might need to press briefly the reset button, to have the switch report it's _Basic_ attributes.
Please check both the single and double key switches - they're probably slightly different.

The switch looks very similar to the QBKG03LM (#335) and the WXKG02LM (#165), so maybe adding the name is enough to get the buttons to work with deCONZ. You wouldn't be able to sniff the ZigBee network and see what messages the switch sends?

[mathos77]

Hi @ebaauw ,

I did try both, WebUI (deCONZ plain) and deCONZ GUI. I even tried Phoscon.
Anyway, so you believe it should already have entry under lights.
It did not unfortunately.
I can switch (ON or OFF) and Toggle both switches on the Double-Key switch via Cluster Info btw.
Not tried the single switch yet, but will do when I get this one fixed.

The screenshot requested: (btw, deCONZ 2.04.99 with the built REST-plugin)

I believe it is VERY similar if not the same, as the other QBKG03LM

Kind regards, Tom.

[mathos77]

Oh, I do not have a sniffer ready, but....I do have a dusty RaspBee and a spare pi lying around.
How easy is it to start sniffing with that ?

[ebaauw]

Oh, I do not have a sniffer ready, but....I do have a dusty RaspBee and a spare pi lying around.
How easy is it to start sniffing with that ?

Not - you'd need a ConBee.

[mathos77]

oh, well I do have a conbee, as my main device. Can I do this without messing up my setup afterwards ? (I would have to have to revisit all Hue bulps again :) )

[ebaauw]

You'd need to shutdown deCONZ and flash different firmware to the ConBee, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/69. The deCONZ installation would remain untouched, except for the info stored on the ConBee (stuff like PANID, network key, channel). Best make some screenshots of the _deCONZ Network Settings_, so you can restore these. deCONZ should prompt to flash the ConBee firmware back.

Not sure I would recommend this. I would take the next reinstallation (we're still on beta...) to move production to the RaspBee, before messing with the ConBee. Which reminds me: I still need to do a restore test from my production pi to my test/backup pi (both having a RaspBee).

[mathos77]

@manup
Hi Manuel,

As a side-note to the lumi.ctrl_neutral2, I also have a lumi.ctrl_neutral1 (One Button in-wall switch)
(Reference: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/335)

Now, can we get the one that has a typo (neural2 instead of neutral2) fixed, + this one with neutral1.

I would also like to see this as a light ON/OFF, as this is what it supports.
I do see a benefit of it also being a sensor though, so it will match more with the similar remotes, which do not have the switching part. That way you could use it also as a sensor to trigger other things too.

I can click on the On/Off/Toggle button and that works great:

When the switch (light) is "OFF", this is shown:

When the switch (light) is "ON", this is shown:

Please let me know if you require more info.

Kind regards, Tom.

[ebaauw]

I would expect the OnOff cluster on the 03 endpoint to reflect the state of the light.

The _OnOff_ on some other endpoint should reflect the state of (one of the) the key(s), probably true for pressed and false when not pressed (there are stateless switches, aren't they?). If they work like the other Xiaomi switches, the value should change life, when you press/release the key. It would be cool if you could reverse-engineer what the _Multistate Input_ clusters represent (i.e. what value to they show under what condition).

@manup I don't understand why the _On/off light_ isn't exposed. Could it be a ZLL On/off light on a ZHA endpoint (would deCONZ display it like this)?

@mathos77, I'm happy to submit a PR for support of the switches, but you'll have to wait for Manual to return and release a new version.

[mathos77]

Hi @ebaauw Erik,

That would be cool. if you can create the PR.
So, can you elaborate a bit more on what you would like to see as in information?
Do you want to see the status for all nodes from deCONZ UI during the different states ?

[ebaauw]

Yes, we’d need to understand how the attribute value for each cluster changes when you press/release/hold a (or both) key(s). Typically, attribute 0x0000 of cluster 0x0006 of endpoint 02 would be true while you hold the left button and false after you release it. Same for the right button and endpoint 04. Maybe endpoint 05 for both buttons. I’m hoping the multistate input (endpoint 05, cluster 0x0012, I think attribute 0x0055) might provide more specific info, like different values for press, double press or so. We need to map these to the buttonevent values of the REST API. You should be able to observe the value change in real time in the deCONZ GUI.

[mathos77]

Hi Erik, okay, I will test this tonight with both the single and double key switches

[mathos77]

Hi @ebaauw ,

I have tested the single-key wall switch (lumi.ctrl_neutral1) which I also added to the 2.04.99 version of the REST plugin before building it.

It is added as a sensor, but not doing anything (actually 3 clusters are added)
I press the button, to turn it on or off, I see the node giving the blue light.
In REST no changes are seen.

Futher, the only status I see changing is under EP 02 0x0000, Cluster 0x0006:
ON

OFF

On this EP/Cluster, I can also utilize the Toggle, On and Off buttons to switch the light on/off

[ebaauw]

I have tested the single-key wall switch (lumi.ctrl_neutral1) which I also added to the 2.04.99 version of the REST plugin before building it.

You need to pair the switches with the compiled plugin. Please delete the sensor resources from the REST API, delete the node from the deCONZ GUI and re-pair the sensor. It might be prudent to shutdown deCONZ and remove physically the _Deleted_ sensor resources from the database (in ~/.local/share/dresden-elektronik/deCONZ/zll.db). With the latest commit, deCONZ only creates resources for the _Mulitstate input_ (0x0012) and _Analog Input_ (0x000c) clusters for the Xiaomi Smart Cube. And it should create resources for the _Basic_ cluster (0x0006), but I've a hunch that it might not...

Something odd is going on: the GUI screenshots only show endpoints 01, 02, 03 and 04. The REST resources suggest that there's also endpoints 05, 06, and 08, the first two with a 0x0012 cluster and the last with a 0x000c cluster.

Futher, the only status I see changing is under EP 02 0x0000, Cluster 0x0006:

Is this on a one-button switch (ctrl_neutral1)? Did the REST API create a light resource for this one? I assume true when the button is pressed (held) and false when it's not?

On this EP/Cluster, I can also utilize the Toggle, On and Off buttons to switch the light on/off

That's probably because this endpoint is still bound to the 03 endpoint.

[zydeco]

I have two one-key switches, and I've been experimenting with them a bit:

• The OnOff cluster on endpoint 03 does reflect the state of the light, but it doesn't respond to changes, only the 0xFFFF cluster allows turning the light on and off.
• The light isn't exposed to the REST side because the device is an end device, so it's skipped from addLightNode completely

I've tried to implement this on my fork, and it seems to work, but sometimes the switch will stop responding to commands until the device is paired again, and I'm not sure what's going on: the log will have several entries saying delay sending request 139 cluster 0x0004 to 0x00158d0001614b4b and eventually give up.

[ebaauw]

The OnOff cluster on endpoint 03 does reflect the state of the light, but it doesn't respond to changes, only the 0xFFFF cluster allows turning the light on and off.

Do you mean the 0x0006 cluster on the 02 endpoint with device type 0xFFFF? What do you mean by "respond to changes"? Did you try the On, Off, and Toggle commands on cluster 0x0006 of endpoint 03 (the _On/Off light_)?

The light isn't exposed to the REST side because the device is an end device, so it's skipped from addLightNode completely

Bloody hell, it's mains powered but not a ZigBee router. Good catch!

I've tried to implement this on my fork

You're exposing endpoint 02 as the light? Won't that break adding it to a group or a scene, as these clusters are on endpoint 03?

I think in addLightNode() it's probably enough to check for device type (ZLL or ZHA? _On/Off light_) and the MAC address prefix instead of going through the trouble of finding the model. Afaik none of the other Xiaomi devices use an _On/Off light_ device type.

[ebaauw]

Something odd is going on: the GUI screenshots only show endpoints 01, 02, 03 and 04. The REST resources suggest that there's also endpoints 05, 06, and 08, the first two with a 0x0012 cluster and the last with a 0x000c cluster.

See #335: that has the 05, 06, and 08 clusters in the screenshot, but the 03 cluster isn't an _On/Off_ light. If I were superstitious, I'd say these switches are cursed.

[zydeco]

On my lumi.ctrl_neutral1 (single key switch):
Endpoint 02, device type 0xFFFF, cluster 0x0006:

• Attribute 0x0000 reports the state of the light
• On, Off and Toggle commands work, they will turn the attached light on, off or toggle

Endpoint 03, On/off light, cluster 0x0006:

• Attribute 0x0000 reports the state of the light
• On, Off and Toggle commands don't do anything, even though it will say "success" after pressing exec.

This is why I'm exposing endpoint 02 as the light, but I haven't tried to add them to groups or scenes.

Regarding the missing endpoints, the previous screenshots by @mathos77 do have endpoints 05, 06 and 08, like mine do, they seem to have disappeared from his setup?

The one on #335 is the two button model, but it has three 0xFFFF endpoints with a 0x0006 cluster instead of two.

[ebaauw]

The one on #335 is the two button model, but it has three 0xFFFF endpoints with a 0x0006 cluster instead of two.

But no _On/Off light_.

Regarding the missing endpoints, the previous screenshots by @mathos77 do have endpoints 05, 06 and 08, like mine do,

And a 04 0xFFFF endpoint, similar to the two-button switch.

they seem to have disappeared from his setup?

And 04 has changed from device type 0xFFFF and having only an _OnOff_ cluster to an _On/Off switch_ with also a _Multistate input_ cluster?

I suspect pairing, deleting, re-pairing using a different version, without removing the deleted records from the database would do this. Probably combined with the usual Xiaomi pairing blues - the device not being read in full. Maybe you need to press briefly the reset button a couple of times while pairing, as is typically needed for the battery-powered Xiaomi switches.

Doing some digging on Ali-Express, GearBest and YouTube, the two-button switch actually has two independent light outputs. I would expect it to expose two _On/Off lights_. I'd theorise that the 02 and 03 endpoints are, in fact, the two outputs, but the 03 is not fully functional on the lumi.ctrl_neutral1.

Do you have group and scene clusters on your endpoint 02, or only on 03?

[zydeco]

Do you have group and scene clusters on your endpoint 02, or only on 03?

Only on 03, it's like the first screenshots in this thread:

[mathos77]

@zydeco @ebaauw
Mine also have the 05,06,08 now. After re-pairing it.
Now I screwed my ConBee setup bigtime, so I am now migrating all to RaspBee. Then I have the ConBee to play with these safely without messing up my hue stuff again :)

I can then also load the bitcatcher on it so we can sniff.

[mathos77]

@manup @ebaauw
Hi Erik, Manuel,

Can we get something going for these?
I am now running 2.05.02, and even though the 1 and 2 button switches are added correctly to deCONZ, I still see no sensors nor lights.

Please let me know what you require to get these properly supported as both sensor, and switch/light (On/Off).

(ps. I can sniffer if that is required)

Thanks!!!

Kind regards, Tom.

[zladukas]

Hello,

got QBKG03LM from Gearbest https://www.gearbest.com/alarm-systems/pp_610096.html , but unable to add to REST plugin & zll DB . It looks like #335, but not working.

I'm running 2.05.02, compiled REST plugin. Read all issues about that. Tried to add via REST plugin Web interface, PWA, directly making HTTP POST, but no success.

I can see device only in deCONZ GUI and at least EP 2 & 3 cluster 0006 are working, when clicking ON/OFF/TOGLE

also captured debug logs, by running:
deCONZ --dbg-info=2 --dbg-zdp=1 --dbg-zcl=1 --db-aps=1 --dbg-http=2 --upnp=0

deCONZ_QBKG03LM_libde_rest.log

What I'm doing wrong?

BR Dalius.

[manup]

Thanks that's helpful, 2.05.03 will arrive shortly, this should add the REST sensor resource for lumi.ctrl_neutral2, anyway button events likely need some more work.

There will be more debug options too in order to see APS/ZCL payload.

[manup]

Version 2.05.03 is online for Raspbian:
http://www.dresden-elektronik.de/rpi/deconz/beta/deconz-2.05.03-qt5.deb

More noisy debug output via --dbg-aps=2 --dbg-info=2

To add the sensor open the network in the WebApp or Phoscon App (search sensors).
When power-cycle the device and press some buttons.

[zladukas]

@manup,
2.05.03, as You told, successfully added sensor to REST.
I can see buttonevent is changing.

collected two logs with options
deCONZ --dbg-info=2 --dbg-zdp=1 --dbg-zcl=1 --dbg-http=2 --upnp=0 --dbg-aps=2 --dbg-info=2

adding sensor:
deCONZ_QBKG03LM_2.5.3.log

and different button combination:
(1st button) ON, then OFF
(2nd button) ON, then OFF
(both buttons) ON, then OFF
deCONZ_QBKG03LM_2.5.3_button_events.log

BR Dalius.

[manup]

From the logs it looks like the switch does only send 3 states like the battery version of the switch.

The button events should be:

2002   1st button
3002   2nd button
6002   both buttons

If you see these via REST API that's all we can do, since the switch does not send events for press and release.

[simonporter007]

Looking forward to testing on Ubuntu build! Cheers manup!

[ebaauw]

Why not 1002, 2002, and 3002 for first, seconds, and both buttons?

homebridge-hue currently assumes the buttons are numbered 100x, 200x, ... etc. without gaps.

[manup]

I agree makes more sense, the numbers are currently derived from the source endpoint, lazy me ;)
I'll change it for the next release. @simonporter007 Ubuntu and Window will follow later today

[mathos77]

@manup
Does this also expose a "Light" that we could switch on/off via Phoscon/deCONZ UI or REST ?
(REST is most important for me 🥇 so I can enable automations via Home Assistant)

I will give this release a go as well now ;)

[manup]

Does this also expose a "Light" that we could switch on/off via Phoscon/deCONZ UI or REST ?

I don't know :) there were some changes to support end-device lights, give it a try.

[ebaauw]

The device type might fail the whitelist check in addLightNode(). I think, for these, we'd better resort to whitelisting the modelId instead of the device type.

Best double-check the endpoints - I think they're different between the neutral1 and the neutral2.

[simonporter007]

For what it's worth, 2.05.04 didn't change the aqara wall light for me. I can add it via the deconz-config GUI from elsewhere on github as I could before. Nothing gets added through phoscon or old web UI though in this version either. Doesn't show as light or switch and can't see any events being pushed out over websocket. Wondering if anyone else had any luck with the aqara powered wall switches?

[zladukas]

@simonporter007
I did, after last modifications, I've already managed, slightly modifying @ebaauw homebridge-hue, work as triple button in homekit. Still long way to go to work as a switch (at least for me), IMHO :)

Feb 18 22:38:28 ddpi homebridge[27552]: [2018-2-18 22:38:28] [Hue] MI Aqara 1 Left: homekit button single press
Feb 18 22:38:28 ddpi homebridge[27552]: [2018-2-18 22:38:28] [Hue] MI Aqara 1 Right: homekit button single press
Feb 18 22:38:28 ddpi homebridge[27552]: [2018-2-18 22:38:28] [Hue] MI Aqara 1 Both: homekit button single press

[mathos77]

The double-key one gets added as 1 sensor.
I also still mis the Light (On-Off) which is really what I need.

[simonporter007]

Don't know what I was doing last time, clearly my deconz debugging wasn't properly on. Can confirm it is added as a sensor, I can see the events passed over. Added this to homeassistant as an mqtt switch which shows me the state of the lights but obviously can't toggle it this way.

[zladukas]

One part of switch "profile: 0x0104" (Dimmer switch) was correctly added.
But wondering how to add to database & REST "profile: 0x0000" (ON/OFF switch)?

19:18:24:813 APS-DATA.indication srcAddr: 0x00158d0001f5842c, dstAddrMode: 2, profile: 0x0000, cluster: 0x0013, lqi: 255, rssi: 0
19:18:24:813 asdu: 8b76482c84f501008d150084
19:18:24:813 device announce 0x00158D0001F5842C (0x4876) mac capabilities 0x84
19:18:24:813 set fast probe address to 0x00158D0001F5842C (0x4876)
19:18:24:813 device announce 0x00158D0001F5842C (0x4876) mac capabilities 0x84
19:18:24:813 set fast probe address to 0x00158D0001F5842C (0x4876)
19:18:24:813 device announce 0x00158D0001F5842C (0x4876) mac capabilities 0x84
19:18:24:813 set fast probe address to 0x00158D0001F5842C (0x4876)
19:18:24:813 device announce 0x00158D0001F5842C (0x4876) mac capabilities 0x84
19:18:24:813 set fast probe address to 0x00158D0001F5842C (0x4876)
19:18:24:813 APS-DATA.indication from unknown node 0x00158D0001F5842C
19:18:24:814 CTRL restore cached node 0x00158d0001f5842c
19:18:24:820 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 2, node: 0x4876
19:18:24:820 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 1, node: 0x4876
19:18:24:820 new node - ext: 0x00158d0001f5842c, nwk: 0x4876
19:18:24:927 0x4876 nwk changed to 0x1F6F

---

9:18:25:075 APS-DATA.indication srcAddr: 0x00158d0001f5842c, dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: 0
19:18:25:075 asdu: 18000a050042126c756d692e6374726c5f6e65757472616c3201002001
19:18:25:075 ZCL attribute report 0x00158D0001F5842C for cluster 0x0000, ep 0x01
19:18:25:075 payload: 050042126c756d692e6374726c5f6e65757472616c3201002001
19:18:25:075 ZCL attribute report 0x00158D0001F5842C for cluster 0x0000
19:18:25:075 ZCL attribute report 0x00158D0001F5842C for cluster 0x0000
19:18:25:075 Node data 0x00158d0001f5842c profileId: 0x0104, clusterId: 0x0000
19:18:25:075 ~ResourceItem() attr/name -- str 0x1e54c18
19:18:25:076 ~ResourceItem() attr/name -- str 0x2123a08
19:18:25:076 ~ResourceItem() attr/modelid -- str 0x1e54c18
19:18:25:076 ~ResourceItem() attr/name -- str 0x20b8ff0
19:18:25:076 ~ResourceItem() attr/modelid -- str 0x1d34a00
19:18:25:076 ~ResourceItem() attr/type -- str 0x1e54c18
19:18:25:076 ~ResourceItem() config/on -- str (nil)
19:18:25:076 ~ResourceItem() attr/name -- str 0x21c7f48
19:18:25:076 ~ResourceItem() attr/modelid -- str 0x20d2db0
19:18:25:076 ~ResourceItem() attr/type -- str 0x22149d8
19:18:25:076 ~ResourceItem() config/on -- str (nil)
19:18:25:076 ~ResourceItem() config/reachable -- str (nil)
19:18:25:076 ~ResourceItem() state/lastupdated -- str 0x22149d8
19:18:25:076 ~ResourceItem() state/buttonevent -- str (nil)
19:18:25:076 sql exec SELECT * FROM sensors
19:18:25:077 don't close database yet, keep open for 900 seconds
19:18:25:077 SensorNode 2: Switch 2 added

[Michelobb]

Hi everyone, first post here. I'm using deCONZ on a CONBEE behind Homeseer with Jowihue Plugin. I'm on REST 2.05.04.

I got more values visible in Homeseer when I click on that switch :

left 1 time = 4002

• left 2 times : nothing
• left 3 times = 1002

• right 1 time = 5002
• right 2 times : nothing

• right 3 times = 2002

• both simultaneously = 3002

Well, that's what I thought, because since I clicked directly into clusters, one single click on left paddle for example, gives me 4002, suddenly changing after a few moments to 1002 !?!?

If I get it well, endpoint 02 is left paddle, 03 the right one, 04 potentially both ?

Would it be possible that the endpoints 05 and 06 have an impact on 02-03'states ?

I tried a lot of combinations, but nothing clear appeared. Then I thought doing well in resetting (F5) the node, but now I only see Endpoints 02-03-04-05. Lost 01-05-06-08.

At your disposal if I can help.

Michel

[Michelobb]

Oh, Endpoint 01 just came back. I suppose the other ones will follow.

[drbytes]

So what's the status for this? I have a single button switch, it gets added in the deconz gui where I can exec on/off but nothing in rest plugin. I'm running 2.05.08.
Is there anything I can do to get it in the rest?

[manup]

What modelid has your switch? Can you provide a screenshot from the basic cluster: press read to get the attribute values.

Normally in order to add a switch:

• Start sensor search
  Phoscon App > Hamburger Menu > Devices > Sensors > Add new sensor > Other
• While search is running press the switch button for ~10 seconds the LED should blink

On success a new sensor should be added to the REST-API. If it doesn't work likely the modelid is not yet added in the plugin. For that the above info from basic cluster is needed.

[simonporter007]

It is added to the REST API as a sensor but as far as I can see, you can't toggle a sensor/send a buttonevent through deconz REST API unless it's a CLIP sensor? Maybe I'm missing something. As the lights behind the switch buttons aren't added you can't react to the sensor events either and toggle their respective lights. In the deconz GUI you can execute the on/off endpoints and the light switch does then toggle the lights. Is there any plans to get that behaviour over the REST API?

Edit: Haven't tried on 2.05.08 - will give that a go later. The above was the case in 2.05.05 at least.

[mathos77]

@manup
Can you check how we can get to a solution for the On/Off Switch part ?
The sensor for the Double key works fine, but I am really not interested in the sensor for these "On/Off Lights" personally :-)

Let me know what information (or support ticket ?) is required to get it supported so we can turn it off/on via deCONZ.

Thanks !

[kaffeewolf]

Hi everyone, I'll chime in with @mathos77 and would love to get the on/off part working :)
Due to some mishap while ordering i got a qbkg12lm as well (similar to the qbkg03lm, but it requires neutral) that I cant really use. I could donate it to @manup of @ebaauw if that would help with the cause ;-)
I haven't connected them yet, so I don't know if they behave similar to the non-neutral ones that I have.

[ebaauw]

The "on/off part" would apply only to the neutral switches, to control the dumb light(s) hard-wired to the switch. For this, the REST API should expose a /lights resource, in addition to the ZHASwitch /sensors resource(s) for the button(s).

I'll be happy to have a look at the switch. I was tempted to order one, just to figure it out, but I don't have any use for it either. I've replaced all my lights with smart lights, except for the dining room table lights, which are connected through a ubisys dimmer (dimming was a must-have requirement ;-).

I'm guessing the _Analogue Input_ cluster on the 0x0053 endpoint reports consumption or current power, similar to the Xiaomi smart plug. If so, the REST API could expose a corresponding ZHAConsumption or ZHAPower /sensors resource as well.

[kaffeewolf]

Yes, I'm aware of the switch being for dumb lights, the events work just fine, however I want to remote control the lights connected. I have a bunch of lights that are hard to replace with smart lights (weird outside lamps etc) so these switches were a godsend.
I've been trying to figure out what the other endpoints are good for (4,5,6,8) but with no real luck, similar to @Michelobb. It appears endpoint 6, cluster 0006 switches to true (if I have it open in the deconz gui at the moment) when I press a physical button on the switch, however if I execute a read after its false again, if that makes any sense. I can check the analogue input when I get home later today, but from what i recall it doesnt contain much information really.
Anything else you want me to try? I've already dug around in the code a bit but I havent really started doing anything yet.

I'm in Sweden, so if you want one of the qbkg12lm switches I can post it to you (or @manup).

[alexvandervegt]

Would love to see an update on this also

[ebaauw]

I'm in Sweden, so if you want one of the qbkg12lm switches I can post it to you

@kaffeewolf, Can I contact you privately to send my address?

[kaffeewolf]

Sure, drop me a mail at [email protected]

[ebaauw]

I received the switch today, thanks @kaffeewolf . It's yet another model - that would explain why no /sensors resources are created:

It's got four physical connections: L, N, L1, and L2. L is for the live (input) wire (braun in EU); N for the neutral (blue); L1 and L2 for the outputs (black). Out of the box, L1 is linked to the left button and L2 to the right.

The REST API plugin (v2.05.20) creates a single /lights resource for endpoint 01 (which was already whitelisted for the Xiaomi smart plug):

{
  "etag": "71e06aef3db22094b3c71b05f7e7748d",
  "hascolor": false,
  "manufacturername": "Unknown",
  "modelid": null,
  "name": "Light 2",
  "state": {
    "alert": "none",
    "on": false,
    "reachable": true
  },
  "swversion": null,
  "type": "Smart plug",
  "uniqueid": "00:15:8d:00:02:2a:9c:c7-01"
}

Note that the _Basic_ cluster on endpoint 01 is ignored, hence the empty manufacturername, modelid, and swversion. EDIT this is a bug

The _OnOff_ cluster on endpoint 01 is controlling L2; the _OnOff_ cluster on endpoint 02 is controlling L1. _On_, _Off_, and _Toggle_ commands work as expected. The _OnOff_ attribute reflects the current state, but isn't refreshed automatically when sending a command (I suppose the refresh is actually done by the REST API plugin, through a fast-poll after state.on has changed).

The switch supports attribute reporting for both _OnOff_ attributes. After setting this up, the _OnOff_ attributes are refreshed 1-2 seconds after sending a _On_, _Off_ or _Toggle_ command.

The _Analog Input_ cluster on endpoint 03 reports power in W (with a resolution of 0.01W). The switch reports _Present Value_ as unreportable attribute, but the value is updated 1-2 seconds after switching L1 and/or L2. The (server) _Analog Input_ cluster on endpoint 04 reports 0.01 for _Present Value_. I'm assuming this is total consumption in kWh, as for the Xiaomi smart plug.

The _Multistate Input_ cluster on endpoint 05 is linked to the left button; that on endpoint 06 to the right button. _Present Value_ becomes 1 on press/release or press/hold and 2 on double press/release. When reading the attribute, it reports 0, but no separate report for release. When pressing both buttons simulteneously, endpoint 07 reports 1. I haven't been able to get endpoint 07 to report 2 double pressing both buttons.

As far as I can tell, the buttons are hard wired to the output lines. I tried binding/unbinding the _Multistate Input_ clusters to the endpoints with the _OnOff_ clusters, but no change in behaviour.

[ebaauw]

Time for some sniffing...

The REST API plugin is polling the switch to read it's _Basic_ cluster _on endpoint 01_. The switch responds, but the plugin doesn't seem to process the response. The plugin also polls for _Get Group Membership_, _also on endpoint 01_, to which the switch responds as well: capacity 15, one group 0x0000.

After sending a _Toggle_ to endpoint 01, the switch sends two reports:

• _OnOff_ cluster on endpoint 01: attributes _OnOff_ and 0xf000, Uint32: 117440548 (0x07000024);
• _Analog Input_ cluster on endpoint 03, attribute _Present Value_.

A _Toggle_ to endpoint 02 seems to result in similar reports (but now on endpoint 02).

I see occasional reports for the _Basic_ cluster on endpoint 01, manufacturer specific (code 0x115f) attribute 0xff01, String. This looks suspiciously like the other Xiaomi magic strings.

Pressing buttons indeed results in reports for the corresponding _Multistate Input_ cluster, with attribute _Present Value_. Pressing both buttons only results in a report from endpoint 7.

[manup]

The switch responds, but the plugin doesn't seem to process the response.

I guess this happens because currently the plugin expects the basic cluster on the same endpoint as the lights stuff.

From DeRestPluginPrivate::updateLightNode()

    LightNode *lightNode = getLightNodeForAddress(event.node()->address(), event.endpoint());

[ebaauw]

I guess this happens because currently the plugin expects the basic cluster on the same endpoint as the lights stuff.

That won't be a problem for endpoint 01, once the 0xffff device type is whitelisted. But for endpoint 02, there's no _Basic_ cluster...

[ebaauw]

The REST API plugin (v2.05.20) creates a single /lights resource for endpoint 04, because that's the only endpoint with a device type that the API recognises

Nonsense! It has created the resource for endpoint 01 (check uniqueid!). Devicetype 0xffff was already whitelisted for the Xiaomi Smart Plug - the switch has the same manufacturer code and also a server _OnOff_ cluster on endpoint 01, so it satisfies the whitelist. Device ID 0x0053 is _not_ known (I mistook it for 0x0051, Smart plug), but even it it where, there's no server _OnOff_ cluster for that endpoint, so it's excluded.

That does leave the question why the light attributes aren't populated...
EDIT Due to another switch statement where DEV_ID_XIAOMI_SMART_PLUG was missing. I now got the attributes for the endpoint 01 resource, but not for the endpoint 02 resource.

[ebaauw]

With my lastest PR, the lumi.ctrl_ln2.aq1 should be supported. The only issue remaining is that the attributes for the second light resource aren't populated, see below. @manup, we need a similar trick as for the sensor nodes, to copy the attributes from the lightnode for endpoint 0x01. Also, I haven't checked the Xiaomi magic string.

{
  "1": {
    "etag": "7044ace21a7b5920ac18cb20fd654e53",
    "hascolor": false,
    "manufacturername": "LUMI",
    "modelid": "lumi.ctrl_ln2.aq1",
    "name": "Light 1",
    "state": {
      "alert": "none",
      "on": true,
      "reachable": true
    },
    "swversion": null,
    "type": "Smart plug",
    "uniqueid": "00:15:8d:00:02:2a:9c:c7-01"
  },
  "2": {
    "etag": "7044ace21a7b5920ac18cb20fd654e53",
    "hascolor": false,
    "manufacturername": "Unknown",
    "modelid": null,
    "name": "Light 2",
    "state": {
      "alert": "none",
      "on": true,
      "reachable": true
    },
    "swversion": null,
    "type": "Smart plug",
    "uniqueid": "00:15:8d:00:02:2a:9c:c7-02"
  }
}

I also added support for power measurement and for the buttons. I've combined the three _Multistate Input_ endpoints into one ZHASwitch resource. Should probably so the same for the ubisys D1 (and C4).

{
  "2": {
    "config": {
      "on": true,
      "reachable": true,
      "temperature": 0
    },
    "ep": 3,
    "etag": "0617b8a80920775d311e019feb28792e",
    "manufacturername": "LUMI",
    "modelid": "lumi.ctrl_ln2.aq1",
    "name": "Power 2",
    "state": {
      "lastupdated": "2018-04-13T16:22:47",
      "power": 12
    },
    "swversion": "10-12-2017",
    "type": "ZHAPower",
    "uniqueid": "00:15:8d:00:02:2a:9c:c7-03-000c"
  },
  "3": {
    "config": {
      "on": true,
      "reachable": true,
      "temperature": 0
    },
    "ep": 4,
    "etag": "febf8a3dcccd65026e9a7cc56896daf5",
    "manufacturername": "LUMI",
    "modelid": "lumi.ctrl_ln2.aq1",
    "name": "Consumption 3",
    "state": {
      "consumption": 84,
      "lastupdated": "2018-04-13T16:22:43"
    },
    "swversion": "10-12-2017",
    "type": "ZHAConsumption",
    "uniqueid": "00:15:8d:00:02:2a:9c:c7-04-000c"
  },
  "4": {
    "config": {
      "on": true,
      "reachable": true,
      "temperature": 0
    },
    "ep": 5,
    "etag": "e40a61984d7c666f273ea8b4eaf6e22b",
    "manufacturername": "LUMI",
    "mode": 1,
    "modelid": "lumi.ctrl_ln2.aq1",
    "name": "lumi.ctrl_ln2.aq1 4",
    "state": {
      "buttonevent": 2004,
      "lastupdated": "2018-04-13T13:56:46"
    },
    "swversion": "10-12-2017",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:02:2a:9c:c7-05-0012"
  }
}

Note state.power is current power in W; state.consumption is cumulative consumption in 0.001 kWh (or in Wh). state.buttonevent takes the following values:

• 1002 press/release left;
• 1004 double press left;
• 2002 press/release right;
• 2004 double press right;
• 3002 press/release both.

[ebaauw]

@kaffeewolf, @mathos77, others,

Unfortunately it looks like each model of the Xiaomi wall switch differs from the other models and needs to be configured separately in the REST API plugin. I'm lost in all the scattered info above and in other issues. I need your help supporting the other models, lumi.ctrl_neutral1, lumi.ctrl_neutral2, lumi.ctrl_ln1.aq1 and maybe even others. Can you please reply with a comment per model, with the following info:

• Screen shot of the node in the deCONZ GUI (incl. MAC address, endpoints, device type, clusters);
• Screenshot of Node Info panel (showing Manufacturer code);
• Screenshot of the _Basic_ cluster in the _Cluster Info_ panel, after manually reading all attributes;
• Overview of the physical connections (L, N, L1, L2, ...). Which physical button switches with output line;
• For each endpoint with an _OnOff_ cluster (assumed to be used for switching the wired lights):
  
  
  
  • Does it switch L1, L2, ... on commands _On_, _Off_, _Toggle_?
  
  
  • Does the _OnOff_ attribute reflect the output line state (re-read the attributes to make sure)?
  
  
• For each endpoint with a _Multistate input_ cluster (assumed to be used for the switch buttons):
  
  
  
  • Does _Present Value_ change on pressing a button/both buttons? Which button? Different values for press/release/double press/etc?
  
  
  • If also an _OnOff_ cluster on the same endpoint: does _OnOff_ change on pressing a button/both buttons? Which button?
  
  
  • Note that when reading the attributes, _Present Value_ likely returns 0, so you need to look at the _Cluster Info_ panel while pressing the button(s).
  
  
• For each endpoint with an _Analog Input_ cluster (assumed to be used for metering):
  
  
  
  • What value does _Present Value_ report? Does the value update when switching on/off the connected lights? Re-read the attributes if needed.
  
  
• Overview of the /lights and /sensors resources currently created for the switch under v2.05.21. Delete any resources from the database and re-pair the switch.

[simonporter007]

@ebaauw this is much appreciated this work. Just got back home after holidays, let me get this info for you today.

[simonporter007]

Apologies for the screenshot sizes, running the GUI over Xvfb on headless server. Here's the info you requested, if anything is not accurate or expected, please let me know. Not hugely familiar with the GUI as i've only ever really uses the rest part of deconz.

• This particular model has the L1, L2 wires plus the incoming Live wire and Neutral wires.
• For 02 it toggles the L1 wire/lights with on/off/toggle. The attribute also reflects the correct value of the light
• For 03 is toggles the L3 wire/loights woith on/off/toggle. The attribute also reflects the correct value of the light.
• 04,05,06 makes no difference but the GUI reports a success on the on/off/toggle.
• The multistate endpoints do not change the presetn value. either with button pushes and/or manually clicking read after each button press either. It did change the attribute value on the onoff cluster on the first button press but then clicking read wopuld reset this back to false. Not sure what was happening here. Also pushing obth buttons "enabled" the ZLL Extension part of the cluster info box which was greyed pout before but the values did not change. Clicking read also reset this too.
• Anolog input made no changes anywhere that i could see
  
  

Last note I had to use .20 as .21 is not on the website for ubuntu.

Cheers and many thanks again.

[ebaauw]

Thanks, @simonporter007 !

• This particular model has the L1, L2 wires plus the incoming Live wire and Neutral wires.
• For 02 it toggles the L1 wire/lights with on/off/toggle. The attribute also reflects the correct value of the light
• For 03 is toggles the L3 wire/loights woith on/off/toggle. The attribute also reflects the correct value of the light.

Cool. So endpoints 2 and 3 should be exposed as lights. It still uses the 0x1037 manufacturer code, so that can be used to tell it apart from the lumi.ctrl_ln2.aq1 and the lumi.plug. Also lumi.ctrl_neutral2 is an end device where the other two are routers.

It shows _Receiver On When Idle_ as false - I hope that's a glitch, deCONZ expects this to be true before it will create light resources for the switch.

@manup, we will need a different mechanism (than copying the attributes from another lightNode) to "transplant" the _Basic_ cluster from endpoint 01 to endpoints 02 and 03, as for this switch, no lightNode will be created for endpoint 01.

The multistate endpoints do not change the presetn value. either with button pushes and/or manually clicking read after each button press either. It did change the attribute value on the onoff cluster on the first button press but then clicking read wopuld reset this back to false. Not sure what was happening here.

So apparently the _Multistate Input_ cluster is not used and the _OnOff_ cluster is used for reporting the button presses. The switch sends a _Report Attributes_ command when the button is pressed (so the value shows as true in the GUI), but it doesn't store the attribute value (so it shows false when the attributes are read). I'm assuming 04 is used for the left button, 05 for the right button and 06 for both buttons? Can you confirm?

Anolog input made no changes anywhere that i could see

It could be used for consumption. Typically, it only updates after 10 Wh or so has been consumed, so it might take some time before a new value is shown in _Present Value_.

Note that your IKEA bulb is still on the old firmware - you can update that through deCONZ.

[alexvandervegt]

I just updated to deconz-2.05.21-qt5.deb and I have a lumi.ctrl_neutral2 switch.

Is it correct this is not listed as a light resource yet? Or am I missing something?

[mathos77]

I have the lumi.ctrl_neutral1 switch, which used to show the sensor, but this does not work anylonger in 2.05.21 it seems.

The lumi.ctrl_neutral2, I still see that one in the sensor list, even though I kicked it out of deCONZ ....

Anyway, the toggle/on/off buttons work perfectly from deCONZ.

[mathos77]

@ebaauw
The Neutral2 is now showing as a Switch in deCONZ. I still only have a sensor via REST though (and in Phoscon as well)

Was it supposed to expose a /lights entry already ?

[ebaauw]

I think/hope I added support for the lumi.ctrl_neutral switches in my latest PR #552. Untested, as I don't have any of these. Also added (untested) support for the lumi.ctrl_ln1.aq1. @simonporter007, @mathos77 can you please compile and test the PR? Please delete the existing node from the GUI and REST resources from the database before re-pairing the switch.

The lumi.ctrl_neutral2 should be exposed as two light resources (for endpoints 0x02 and 0x03), the lumi.ctrl_neutral1 as one (for endpoint 0x02). The values for manufacturer, model, and swversion are probably still missing. Both should also get a single ZHASwitch sensor resource (for endpoint 0x04) and a ZHAConsumption sensor resource (for endpoint 0x08), but they might be missing due to missing value for modelid.

[alexvandervegt]

Cool @ebaauw or @manup can someone create a new .deb file in:

http://www.dresden-elektronik.de/rpi/deconz/beta/

I would love to test if everything is working!

[mathos77]

Hi Erik @ebaauw

GREAT WORK !!! Woohoo, the double switch produces 4 lights which I can control via Phoscon/deCONZ and also via REST.

I have yet to test the single one, but Neutral2 is looking great.

One note is, there are only 2 switches in the Neutral2 (and only one in the Neutral1) so perhaps the 2 extra lights could be omitted somehow.

But overal I AM VERY PLEASED 😄

[alexvandervegt]

Where did you find the .deb file or can you send one? I sm on osx so its hard for me to compile one :( @mathos77

[mathos77]

Hi @alexvandervegt ,

I just used the latest deb for Raspberry Pi and compiled the master for the REST plugin.

You should really just buy a pi, stick the thing in there, and you are done really, no need to clutter you mac with deCONZ :-)

[mathos77]

@ebaauw

I was building the switch into wall....but now I ran into another issue.....Physical Parameters :-P
The thing does not fit in our europe in-wall boxes ARRGGGG

[ebaauw]

@mathos77 I expected only two lights - could you please list the light and sensor resources? Are all four lights functional?

[mathos77]

Hi @ebaauw

Lights
https://jsoneditoronline.org/?id=18b30cfb1a5a77b6fd8bd2a41edbcc38

"13": { "etag": "ce58933c66ff13d124d2ecb5054df51a", "hascolor": false, "manufacturername": "Unknown", "modelid": null, "name": "bathroom_mirror", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "Smart plug", "uniqueid": "00:15:8d:00:01:f4:cb:5e-02" }, "14": { "etag": "199516eb6bb5e39367298841545ad8b8", "hascolor": false, "manufacturername": "Unknown", "modelid": null, "name": "bathroom_main", "state": { "alert": "none", "on": true, "reachable": true }, "swversion": null, "type": "Smart plug", "uniqueid": "00:15:8d:00:01:f4:cb:5e-03" }, "15": { "etag": "14809e745de9dc89b8bfb0b51fc7b591", "hascolor": false, "manufacturername": "Unknown", "modelid": null, "name": "Light 15", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "On/Off light", "uniqueid": "00:15:8d:00:01:f4:cb:5e-05" }, "16": { "etag": "9e7e7354eb8c544c5ed8fbf28e0fd19c", "hascolor": false, "manufacturername": "Unknown", "modelid": null, "name": "Light 16", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": null, "type": "On/Off light", "uniqueid": "00:15:8d:00:01:f4:cb:5e-06" }

Sensors
https://jsoneditoronline.org/?id=18b30cfb1a5a77b6fd8bd2a41ed6aa83

"21": { "config": { "battery": null, "on": true, "reachable": true, "temperature": null }, "ep": 4, "etag": "e2c557aa1010f0cde74e1e7184250ac7", "manufacturername": "LUMI", "mode": 1, "modelid": "lumi.ctrl_neutral2", "name": "lumi.ctrl_neutral2 21", "state": { "buttonevent": 2002, "lastupdated": "2018-04-22T18:58:24" }, "type": "ZHASwitch", "uniqueid": "00:15:8d:00:01:f4:cb:5e-04-0006" }, "22": { "config": { "configured": false, "on": true, "sunriseoffset": 30, "sunsetoffset": -30 }, "etag": "d17879a8a674cb13b26690b4642c0fb8", "manufacturername": "Philips", "modelid": "PHDL00", "name": "Daylight", "state": { "daylight": null, "lastupdated": "none", "status": null }, "swversion": "1.0", "type": "Daylight", "uniqueid": "00:21:2e:ff:ff:01:41:6b-01" }, "23": { "config": { "battery": null, "on": true, "reachable": true, "temperature": 0 }, "ep": 2, "etag": "e2c557aa1010f0cde74e1e7184250ac7", "manufacturername": "LUMI", "mode": 1, "modelid": "lumi.ctrl_neutral2", "name": "lumi.ctrl_neutral2 23", "state": { "buttonevent": 2002, "lastupdated": "2018-04-22T18:58:24" }, "type": "ZHASwitch", "uniqueid": "00:15:8d:00:01:f4:cb:5e-02-0006" }, "26": { "config": { "battery": null, "on": true, "reachable": true, "temperature": null }, "ep": 8, "etag": "441758a11292f5edf9ad740299330f9c", "manufacturername": "LUMI", "modelid": "lumi.ctrl_neutral2", "name": "Consumption 26", "state": { "consumption": null, "lastupdated": "none" }, "type": "ZHAConsumption", "uniqueid": "00:15:8d:00:01:f4:cb:5e-08-000c" }

For the lights, only 13 && 14 work .

The sensor 21 was already there, if you delete something from deCONZ , perhaps it does not delete the sensors related...?

[mathos77]

I think they just use the same board for all their switches, independent of their number of buttons.

[alexvandervegt]

Any update on the .deb file? :(

[ebaauw]

Thanks, @mathos77 !

The functional lights for endpoints 02 and 03 are intentional. I will need @manup's help to populate the manufacturername, modelid and swversion from the _Basic_ cluster on endpoint 01. The bogus lights for endpoints 05 and 06 are because of the device type On/Off switch. I'll need to blacklist them explicitly.

I'm pleasantly surprised the manufacturername, modelid, and swversion for the sensor resources are populated, but I wonder whether they're copied from the existing sensor or read from the 01 endpoint.

I would expect a ZHASwitch sensor for endpoint 04 - not for endpoint 02. Are you sure the one for endpoint 04 (21) was already there?
Can you please play with the buttons and observe the different values for state.buttonevent of the ZHASwitch sensor(s)? I would expect 1002 for pressing/releasing the left button; 2002 for the right button; and 3002 for both buttons. And no change when turning on/off the lights through the API.

The ZHAConsumption sensor for endpoint 08 is intentional. I'm curious whether it's state will be updated after keeping attached lights on for some extended time.

if you delete something from deCONZ , perhaps it does not delete the sensors related...?

If you delete a node from the GUI, the REST API resource(s) continue to exist. You need to delete each resource separately, through the API. However, when you delete a resource, its corresponding record is marked deleted in the database, but it will be restored next time the device is re-discovered. You really need to delete physically the records from the database to get a clean view. I use sqlitebrowser for that.

I think they just use the same board for all their switches, independent of their number of buttons.

I haven't looked at the hardware, but the lumi.ctrl_neutral1 and lumi.ctrl_neutral2 do have different firmware (specifying a different _Model Identifier_). The lumi.ctrl_ln2.aq1 reports a different manufacturer code and has a very different fingerprint, so it's a safe bet it has different hardware than the lumi.ctrl_neutral2.

[manup]

The functional lights for endpoints 02 and 03 are intentional. I will need @manup's help to populate the manufacturername, modelid and swversion from the Basic cluster on endpoint 01. The bogus lights for endpoints 05 and 06 are because of the device type On/Off switch. I'll need to blacklist them explicitly.

One way to to this is looping over the simple descriptors and related server clusters
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/de_web_plugin.cpp#L2626

and then extract the attributes as done here https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/de_web_plugin.cpp#L2688

[mathos77]

@alexvandervegt
Use this script on a Raspberry Pi (Raspbian)
https://pastebin.com/5T4Q3UNr

[alexvandervegt]

Thanks!

[alexvandervegt]

@mathos77 Maybe a stupid question but how did you pair the neutral2 switch? Nomatter what I do I can not seem to get it connected.

I hold the button for about 4 seconds, then it goes blinking and then i hit on/off over and over again but no results so far...

[mathos77]

@alexvandervegt
Just hold the button untill it blinks red.
Then it will blink a few times blue.

Then it should be paired.

Perhaps you can give it a nudge by pressing the button once more

[alexvandervegt]

Got it paired now after trying several times. I got 5 light resources but none of them are working. I also have 2 sensors.

Please see the files below for the information:

Lights:
https://jsoneditoronline.org/?id=d3c6d51fc81c28ef280cda7cfd9bd2eb

Sensors:
https://jsoneditoronline.org/?id=cc1a51bb7860d1178c60207d26baafaa

[tomfritz1]

I have the Aqara (single) wall switch. After update to 2.05.23 it works immediately for the first time ever - well done!!! It shows 4 lights in Phoscon (and no sensors); one of the 4 lights can turn the switch on/off (the other 3 are without any function). The only problem I see: when I create group and add this single light and switch the group on/off (which I would like to use with sensor) it does not work - only the single light can be switched on/off.

[simonporter007]

serious serious kudos. Deleted the node form deconz gui, deleted the sensor from rest api too and then upgraded to .23 and re-joined the light. It gives me two lamps in the phoscon app (which both work). I have some new daylight sensors and consumption sensors (not sure if they were part of it too). This is fantastic, just what I've been waiting for.

Now back to home assistant to get this hooked up with everything else! Thanks so much!

[ebaauw]

@tomfritz1, which model is this, the lumi.ctrl_neutral1? Could you please list the light and any sensor resources? I'm afraid the switch doesn't support groups, which could be handled better by Phoscon (and by the web app).

@simonporter007, which model is this, the lumi.ctrl_neutral2 or the lumi.ctrl_ln2? Could you also please list the light and sensor resources? The Daylight sensor was recently introduced and is unrelated to the Xiaomi wall switch.

[simonporter007]

@ebaauw Yup, the lumi.ctrl_neutral2
/sensors =

{
    "6": {
        "config": {
            "battery": null,
            "on": true,
            "reachable": true,
            "temperature": null
        },
        "ep": 4,
        "etag": "da23764c0cd9d001967fec85ac258bed",
        "manufacturername": "LUMI",
        "mode": 1,
        "modelid": "lumi.ctrl_neutral2",
        "name": "Kitchen Light",
        "state": {
            "buttonevent": 1002,
            "lastupdated": "2018-04-24T23:43:26"
        },
        "type": "ZHASwitch",
        "uniqueid": "00:15:8d:00:01:6c:73:51-04-0006"
    },
    "7": {
        "config": {
            "battery": null,
            "on": true,
            "reachable": true,
            "temperature": null
        },
        "ep": 8,
        "etag": "da23764c0cd9d001967fec85ac258bed",
        "manufacturername": "LUMI",
        "modelid": "lumi.ctrl_neutral2",
        "name": "Consumption 7",
        "state": {
            "consumption": null,
            "lastupdated": "none"
        },
        "type": "ZHAConsumption",
        "uniqueid": "00:15:8d:00:01:6c:73:51-08-000c"
    }
}

/lights =

{
    "2": {
        "etag": "da23764c0cd9d001967fec85ac258bed",
        "hascolor": false,
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Light 2",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "Smart plug",
        "uniqueid": "00:15:8d:00:01:6c:73:51-02"
    },
    "3": {
        "etag": "da23764c0cd9d001967fec85ac258bed",
        "hascolor": false,
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Light 3",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "Smart plug",
        "uniqueid": "00:15:8d:00:01:6c:73:51-03"
    }
}

The other sensors and lights are just ikea/motion sensor stuff I cut out for brevity sake.

Cheers,

[alexvandervegt]

How come mine is not working?

[KingTomaHawk]

I have the same issue. Only the Light with the name "Xiaomi Wallswitch" works, light 8,9,10 seems to have no effect.

EDIT: It looks like, "light 10" is the name of the device in deConz, but "Xiaomi Wallswitch" (former "light 7") is able to turn it on and off.

Lights REST:

``` {
"10": {
"etag": "b32882b1693f6a0e60d36c9cbfa993b8",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Light 10",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:a2:3f:c3-06"
},
"7": {
"etag": "b32882b1693f6a0e60d36c9cbfa993b8",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Xiaomi Wallswitch",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "Smart plug",
"uniqueid": "00:15:8d:00:01:a2:3f:c3-02"
},
"8": {
"etag": "b32882b1693f6a0e60d36c9cbfa993b8",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Light 8",
"state": {
"alert": "none",
"on": true,
"reachable": true
},
"swversion": null,
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:a2:3f:c3-04"
},
"9": {
"etag": "b32882b1693f6a0e60d36c9cbfa993b8",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Light 9",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:a2:3f:c3-05"
}
}

Sensors REST: 

{
"11": {
"config": {
"battery": null,
"on": true,
"reachable": true,
"temperature": 0
},
"ep": 4,
"etag": "b32882b1693f6a0e60d36c9cbfa993b8",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.ctrl_neutral1",
"name": "lumi.ctrl_neutral1",
"state": {
"buttonevent": 1002,
"lastupdated": "2018-04-25T22:05:12"
},
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:01:a2:3f:c3-04-0006"
},
"12": {
"config": {
"battery": null,
"on": true,
"reachable": true,
"temperature": 0
},
"ep": 8,
"etag": "b32882b1693f6a0e60d36c9cbfa993b8",
"manufacturername": "LUMI",
"modelid": "lumi.ctrl_neutral1",
"name": "Consumption 12",
"state": {
"consumption": null,
"lastupdated": "none"
},
"type": "ZHAConsumption",
"uniqueid": "00:15:8d:00:01:a2:3f:c3-08-000c"
},
}
```

[tomfritz1]

@ebaauw here is the /lights

},
"21": {
"etag": "2c1f2fb4ac36440a9cad9b6843d7718e",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Klo1",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "Smart plug",
"uniqueid": "00:15:8d:00:01:f5:69:52-02"
},
"22": {
"etag": "2c1f2fb4ac36440a9cad9b6843d7718e",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Klo2",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:f5:69:52-04"
},
"23": {
"etag": "2c1f2fb4ac36440a9cad9b6843d7718e",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Klo3",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:f5:69:52-05"
},
"24": {
"etag": "2c1f2fb4ac36440a9cad9b6843d7718e",
"hascolor": false,
"manufacturername": "Unknown",
"modelid": null,
"name": "Klo4",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": null,
"type": "On/Off light",
"uniqueid": "00:15:8d:00:01:f5:69:52-06"
}
}

[tomfritz1]

@ebaauw model identification is "lumi.ctrl_neutral1" it is the xiaomi wall switch (single button)

[ebaauw]

@alexvandervegt , @simonporter007 , @tomfritz1 , @KingTomaHawk ,
My lastest PR should suppress the superfluous light resources and config.battery. Could you please test this and let me know if it works? Please make sure to delete the light and sensor resources and purge the database before re-pairing the switch.

The PR also parses the Xiaomi magic report for the lumi.ctrl_ln2.aq1, see the --dbg-info=2 log from deCONZ:

Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323 APS-DATA.indication srcAddr: 0x00158d00022a9cc7, dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -48
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323 ZCL attribute report 0x00158D00022A9CC7 for cluster 0x0000, ep 0x01
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     payload: 01ff422e64100065100003281d9839000000009539ba1c093e052105009a201008211f110727000000000000000009210001
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323 0x00158D00022A9CC7 extract Xiaomi special
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     64 on/off 0
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     65 on/off 0
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     03 temperature 29 °C
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     98 power (?) 0x00000000
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     95 consumption (?) 0x3E091CBA
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     05 unknown 5 (0x0005)
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     9a unknown 16 (0x10)
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     08 unknown 4383 (0x111F)
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     07 unknown 0 (0x0000000000000000)
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:323     09 unknown 256 (0x0100)
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:324 Node data 0x00158d00022a9cc7 profileId: 0x0104, clusterId: 0x0000
Apr 27 20:14:36 pi1 deCONZ[29394]: 20:14:35:324 Update Sensor 0x00158D00022A9CC7 Basic Cluster

Could you please capture these log messages for the lumi.ctrl_ln1.aq1, lumi.ctrl_neutral1, and lumi.ctrl_neutral2? Thanks.

[alexvandervegt]

@ebauw how can i purge the database?

[ebaauw]

When you delete a resource through the REST API, the corresponding record in the database is marked "deleted". When the node is re-discovered, the "deleted" record is restored. For a clean re-pairing, you need to delete the "deleted" records from the sqlite database in ~/.local/shared/dresden-elektronik/deCONZ/zll.db. The lights are in the nodes table, with the marking in the state column. The sensors are in the sensors table, with the marking in the deletedState column.

I use sqlitebrowser, which, on Raspbian Stretch, is simply installed through sudo apt install sqlitebrowser. Make sure to stop deCONZ before editing the database.

[KingTomaHawk]

@manup Can you please upload a new build with the fix included? I'm not very familiar with the build process.

[1968-Larry]

I created earlier to create a ticket(#543) for my aqara wall switches but @manup refered to this ticket. I have upgraded to latest package available, removed the switches in pwa and database and tried to connect it back to the network. It's paired and I can see it in pwa/device/switches but I can't use it in groups. I tried to read /api/apikey/switches and it's missing.
I got this in the database:
"3549" "5" "lumi.sensor_86sw2 5" "ZHASwitch" "lumi.sensor_86sw2" "LUMI" "00:15:8d:00:01:e0:75:db-01-0006" "" "{""buttonevent"":null,""lastupdated"":null}" "{""battery"":null,""on"":true,""reachable"":true,""temperature"":null}" "{""d"":65535,""ep"":1,""in"":[0,6],""p"":260}" "normal" "1"

[ebaauw]

This is not a wall switch - please use the original issue.

[KingTomaHawk]

I can confirm that the number of detected lights is reduced to 2 (I had to clear the entries from the DB before) :

"7": {
        "etag": "1f5b2e4c2e0286192dbf70c9c41bfe54",
        "hascolor": false,
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Light 7",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "Smart plug",
        "uniqueid": "00:15:8d:00:01:a2:3f:c3-02"
    },
    "8": {
        "etag": "42b52b99cf6b85c55cc5a9dfa1377f2b",
        "hascolor": false,
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Light 8",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": true
        },
        "swversion": null,
        "type": "On/Off light",
        "uniqueid": "00:15:8d:00:01:a2:3f:c3-03"
    }

Light number 7 is the working one. If someone can explain me how to get the the requested --dbg-info=2 log, I will post them too.

[alexvandervegt]

@ebaauw

It looks like all other Xiaomi wireless switches dont work now anymore.

I just updated to deconz 2.0.5.25 and when i check the logs i see:

11:42:22:645 Daylight now: goldenHour1, status: 160
11:42:31:629 no button map for: lumi.sensor_86sw1 cl: 0x0006 cmd: 0x0A pl[0]: 000
11:42:31:629 ZCL attribute report 0x00158D0001711605 for cluster 0x0006, ep 0x01
11:42:31:629 APS-DATA.indication from unknown node 0x00158D0001711605
11:42:32:649 Daylight now: goldenHour1, status: 160
11:42:32:668 Current channel 15
11:42:32:847 no button map for: lumi.sensor_86sw1 cl: 0x0006 cmd: 0x0A pl[0]: 000
11:42:32:847 ZCL attribute report 0x00158D0001711605 for cluster 0x0006, ep 0x01
11:42:32:847 APS-DATA.indication from unknown node 0x00158D0001711605
11:42:42:649 Daylight now: goldenHour1, status: 160
11:42:52:649 Daylight now: goldenHour1, status: 160
11:43:02:649 Daylight now: goldenHour1, status: 160

[ebaauw]

I've only looked at the wired in-wall switches (lumi.ctrl_neutral and lumi.ctrl_ln), not at the wireless switches. My lumi.sensor_switch.aq2 switches work fine with v2.5.25. I think there might be an issue with lumi.sensor_86sw switches, see #543.

[KingTomaHawk]

It seems like none of the light entries are discoverable over the hue Api. Can someone confirm that?

[alexvandervegt]

Any updates about the non working buttons for the wireless switch?

@ebaauw

[saurabh984]

WXKG02LM & WXKG03LM both work for me using deCONZ v2.05.27

It took several attempts to get them to join and be reported by the REST API. I found that resetting them first by pressing the button for >5 seconds after removing and reinserting the battery had better results.

After doing the reset cycle I added them again by opening the network and pressing the button for 5 seconds.

Hope it helps!

[manup]

Closing this issue, discussion continues in issue https://github.com/dresden-elektronik/deconz-rest-plugin/issues/798