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

[DB-Alex]

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 johannes@gscept.com

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