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]

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.

[DB-Alex]

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.

[DB-Alex]

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 😄

[DB-Alex]

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.

[DB-Alex]

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

[DB-Alex]

Thanks!

[DB-Alex]

@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

[DB-Alex]

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,

[DB-Alex]

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.

[DB-Alex]

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

[DB-Alex]

@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?

[DB-Alex]

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