Aqara WS-EUK02

[letszb]

Device

• Product name: Aqara WS-EUK02
• Manufacturer: LUMI
• Model identifier: lumi.switch.l2aeu1
• Device type : Please remove all unrelated device types.
  • Switch

Screenshots

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

Websocket

API output

{
"etag": "0539a16d14fc06348d72bd05c55a2a0c",
"hascolor": false,
"lastannounced": "2021-06-25T12:44:21Z",
"lastseen": "2021-06-30T07:41Z",
"manufacturername": "LUMI",
"modelid": "lumi.switch.l2aeu1",
"name": "Dusche 1",
"state":
{
"alert": "none",
"on": false,
"reachable": true
},
"swversion": "0x00000E0B",
"type": "On/Off light",
"uniqueid": "54:ef:44:10:00:0f:4c:2d-01"
}

[SwoopX]

Information incomplete and nothing to be done here.

[letszb]

I can't find the Product name and the Model identifier here at Github. Therefore, I assumed that the device is not supported. The problem is that this double rocker switch only delivers at one button websocket events. It seems only one endpoit is working.

[JoMensdorf]

Would be great if you could implement that switch,
I have three installed and only one rocker switch is controllable via Homekit

[timbru31]

Any idea why the Xiaomi Disconnect attribute is readonly? Did they use something else here? sigh

Below are the missing clusters:

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

[SwoopX]

Any idea why the Xiaomi Disconnect attribute is readonly? Did they use something else here? sigh

What do you mean? From the screenshot at the beginning, it's not supported at all... And yes, with the newer devices, they started forcing usage of their own 0xFCC0 cluster. You need the latest F-Firmware (beta) to make it visible (requires re-pairing then). Out latest discovery is that the devices seem to support 3 operational modes. Apparently, one of the annoyances seems to be that, when the switch is not "configured", it sends all its commands through the first endpoint, no matter what. Even while configured in "zigbee mode", that seems to be the case. I, unfortunately, only got a new wireless switch here which goes into deep sleep after 1 min, so it's not really suited for testing (waiting for some wired ones).

I added quite a lot of new attributes #5135, so there's still a lot to discover to unleash all device capabilities.

[timbru31]

Alza has the wired ones in stock, took me 3 days to get one delivered :)

What do you mean exactly with F-Firmware (beta)? Gateway firmware 0x266f0700? Yes

[timbru31]

I've applied your general.xml changed and tried to set the Device Operation Mode (0x0009) - sadly I can't seem to notice a different, the relay is still toggled. (Is that the "not configured part" you are referring to?)

Below are the Lumi clusters (I have a double rocker)

[SwoopX]

Fu*k me, they now started FCC0 on pretty much all endpoints??? That's just going to be a pain in the...

So, if you're up for some play, here's the details. Device operation mode (0x0009) can have 3 different values based on my experience:

1 - "Compatibility mode"
2 - "zigbee mode"
3 - "lumi mode"

I see that the second endpoint is not yet configured, so you might need to set it to 1 as well or something different than 0.

One word of caution: When changing the operation mode, you might need to re-read the active endpoints and simple descriptors by right clicking on the node (those can change depending on the mode). However, this can lead to FCC0 disappearing, since it is dynamically added to the device upon reception of whatever kind of message from that cluster. Changing the mode can cease the device sending anything from FCC0, so it vanishes and does not get accessible any more unless the device is reset.

[timbru31]

Gotcha, thanks for the pointers. Will fiddle around with the switch later today 🤞

[timbru31]

Small update,

I could set the different modes, but did not see any real difference when they've been changed. Do we have any bit of documentation here? Do we need to expand the PR #5136 for this device (l2aeu1), too?

Besides that, I could not find the decoupled option for the FCC0 cluster, which is what I'm looking for. Any hints, too? :)

[timbru31]

Further investigation shows that the field child lock (0x0200) seems the switch mode, too: https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/converters/toZigbee.js#L1832-L1843

[SwoopX]

I could set the different modes, but did not see any real difference when they've been changed. Do we have any bit of documentation here? Do we need to expand the PR #5136 for this device (l2aeu1), too?

The not too obvious changes is pretty much what I'm after here as they might play a rather significant role from a device capability perspective at zigbee level and probably a minor from a user experience perspective. For example, the people are more after having some button events (which admittedly extend the usage capabilities beyond those given on zigbee level) but do not recognize or appreciate the power the zigbee level can give them. E.g. if your automation system goes down, the devices are often useless, as the button events (1002, 2003) cannot be processed. However, if set up appropriately on zigbee level, a button press could still steer a light or whatever, since it uses the zigbee commands etc. behind the translation to the button events do not require any automation system to be run.
So consider it as a kind of fall back mechanism to not render all your devices completely useless upon unavailability of your automation system. It makes the wheel keep spinning... I personally only recognize after days that my middleware has crashed 😉

For the mentioned PR, it presumably makes sense to have that mechanism applied for all Switches if not even for all devices. But it's a bit early to make that fix. The pros/cons can vary throughout the devices so that should be thoroughly tested.

Further investigation shows that the field child lock (0x0200) seems the switch mode, too

Yes, apparently. However, this is getting fugly if Xiaomi reuses the attributes for different purposes, so much for any consistency.

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[timbru31]

Bump.

decoupling does not work as intended yet - regardless of the operation mode value

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[timbru31]

I hate to bump, but not working as expected yet.

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.