Add DDFs for Xiaomi Cube MFKZQ01LM, T1 MFKZQ11LM and T1 Pro MFKZQ12LM

[SwoopX]

Adds the DDFs for the following cubes:

MFKZQ01LM - "lumi.sensor_cube" (Mi logo)
MFKZQ01LM - "lumi.sensor_cube.aqgl01" (Aqara logo)
MFKZQ11LM - "lumi.remote.cagl01" (Aqara T1)
MFKZQ12LM - "lumi.remote.cagl02" (Aqara T1 Pro)

and removes the respective legacy code.

[manup]

Is this tested, the C++ code isn't removed?

[SwoopX]

Ups, indeed, was too keen on the description.

This has been tested with the legacy code removed. However, as I recall, I was hesitant to remove the code since could only test the 1st gen device.

[fhinder]

Hello @SwoopX ,
I tried your implementation, and added "lumi.remote.cagl02" in the modelid list in the file "devices/xiaomi/xiaomi_mfkzq01lm_cube.json".
I was not successfull in pairing my magic cubes (nether the old Xiaomi Cube (Magic Cube) nor the new Xiaomi Cube T1).

[fhinder]

Hello @SwoopX ,

I tried the solution, you provided.
For me, the new cube is still not working and wrongly recognized as "On/Off Switch":

[manup]

I'd really love to get this in and the legacy code removed, seems to need some more debugging?

[SwoopX]

When you have a DDF used thrice and just change the model ID and apart from that they also share the very same C++ code, I tend to believe it's not an issue with the DDF if one works flawlessly with it 🙂

[fhinder]

@SwoopX , @manup :
I checked the implementation by SwoopX once more. I did a copy&paste mistake in copying the files to "/usr/share/deCONZ/devices".
After fixing my mistake, the plugin is working with the cubes "magic cube (lumi.sensor_cube)" and "cube T1 pro (lumi.remote.cagl02)".

The only small issue, I found is:
The new cube T1 Pro has a different mapping of the sides compared to the older magic cube.
In the file xiaomi_cube_gestures.js, the line 5 has to be different for the cubes:
var sideMap = [1, 3, 5, 6, 4, 2]; //magic cube
var sideMap = [1, 2, 3, 4, 5, 6]; //cube t1 pro

I'm not sure, which solution is the best:

1. Two sripts, each for one cube, is a good approach.
   Or
2. If it's possible to distinguish between the cubes within the script and having one script with two sideMap tables, depending on the cube mod within "xiaomi_cube_gestures.js"?

Besides this small difference, the implementation is working.

[SwoopX]

@fhinder Thanks for doublechecking! If the map is slightly different, we need ofc account for that. @manup any preference on the approach (dedicated files or using the modelID in the script)?

[Thomas-Vos]

The old Xiaomi cube does indeed have different values compared to the Aqara Cube and the Aqara T1 cube. You should see the same behaviour without this PR as well. I did point it out but breaking it would break existing setups using e.g. rules, so it was never changed. Changing it now would also break my app which currently handles it correctly for all cubes.

[fhinder]

The difference in the cube t1 pro is, that this cube has labelled sides.
Therefore I propose to modify the mapping in the corresponding file/files in order to have the correct sides in deconz indicating the actual side on the cube.

Otherwise everyone who is using the t1 pro cube has to write an own remapping.

[Thomas-Vos]

Thanks, I did not know about the labelled sides. Still, changing this would break existing setups and my app, so making this breaking change would need to be done carefully. Also need to think what to do about the 2nd gen cube which does not have labelled sides but reports different values in the API compared with the 1st gen cube.

[Thomas-Vos]

I just realised there are four different cubes and not three, which I did not know. You are talking about the T1 Pro which is different from the T1.

Should be like this (if I didn't mess it up):
"lumi.sensor_cube" (Mi logo)
"lumi.sensor_cube.aqgl01" (Aqara logo)
"lumi.remote.cagl01" (Aqara T1)
"lumi.remote.cagl02" (Aqara T1 Pro)
The Aqara T1 Pro (last one) is not currently supported in deCONZ I think (and also not in my app), so it seems safe to change it for that one so it matches with the labelled sides. The other three cubes are also a mess with the numbers (inconsistent with each other), but at least there are no numbers on the cube itself.

[Thomas-Vos]

Related issue comment about the original Xiaomi Mi cube: #138 (comment)

[fhinder]

Oh, I didn't know about four cubes. My tests were done with these two cubes:

• "lumi.sensor_cube.aqgl01" (Aqara logo)

• "lumi.remote.cagl02" (Aqara T1 Pro)

[rhapsodicDE]

Tested only the DDF for the Cube T1 Pro and it works for me, but only in Action mode. The T1 Pro has two modes, Action and Scene. The DDF seems to cover only the Action mode, and it seems that the "side selection" gesture of Scene has a bitmask of 0x0400. The following code should address this, but the question is if this should be a separate gesture or also mapped to flip/3. The 'previous side' seems not to be provided for 0x0400.

else if (Attr.val & 0x0400)  { Item.val = side * 1000; R.item('state/gesture').val = 10; }  // side selection of Scene mode

Regarding the different side mapping for Magic Cube and T1 Pro, could the model ID be provided to xiaomi_cube_gestures.js, then the different sideMap mapping could be resolved by using the respective array.

[SwoopX]

@rhapsodicDE Thanks for sharing this. Wasn't aware I could get a hold of that device real quick; ordered some which should arrive tomorrow 🙂 Always beneficial to have a device here to discover all the secrets.

[SwoopX]

@fhinder Now got the device here as well. Thanks for already finding out the required changes on the script, which I can confirm. Currently pending feedback on the preferred approach.

Additionally, the device has 2 modes of operation, scene mode seems to be default and therefore lacking the gestures (or most of them?).

@rhapsodicDE The cube is sending something even simpler on zigbee level for the scenes. Not too sure yet how to get that covered in a convenient way. Eventually, we'll skip the scene support for the initial device support.

[fhinder]

@SwoopX : Based on the manual, the modes scene/normal can be switched via the Xiaomi App and the corresponding gateway. Since I don't have a Xiaomi gateway, I'm not able to test this.
My cube seems to be in the normal mode from the beginning on.

Would be great, if the switch of the mode could be triggered via conbee. But maybe a new feature request.
First of all support the normal mode, later the scene and the switch between them.

One additional difference, I figured out: the gesture "drop" is not available, or my cube has a defect. Can you verify if your cube has the gesture drop?

[SwoopX]

@fhinder Luckily, I was able to find out the mode switch without setting up my Xiaomi gateway. I added the mode switch now, as the mode differences were larger than initially thought. Everything should now be included.

The new cube indeed doesn't have the drop gesture. You just need to have a look at the Aqara device page or in the manual.

[manup]

It's a biggy PR but I'd really like to have it in. @SwoopX please merge when you think it's ready.
I can build a test version prior to the release if any testers would be interested.

[SwoopX]

It's a biggy PR but I'd really like to have it in. @SwoopX please merge when you think it's ready. I can build a test version prior to the release if any testers would be interested.

@manup I'm always open for a new alpha to make sure things handled here are still working :)