Deconz-rest-plugin: Xiaomi Mi Smart Cube

[ebaauw]

New gadget!

It sends unicast _Report Attribute_ commands to the RaspBee, endpoint 1:

• From endpoint 2 to cluster 0x0012, attribute 0x0055, uint16 on double-tap, flip, move. The attribute value seems to indicate the kind of action, but it's going to be a hell of a job to reverse-engineer what value corresponds to what action. I think they use different values for flipping the cube from side x to side y for every x, y combi.
• From endpoint 3 to cluster 0x000c, attribute 0xff05, uint16, and attribute 0x0055, float (0x39), on turn. 0xff05 always has value 0x01f4 (500), 0x0055 seems to indicate the angle of turning.

[ebaauw]

I think I figured out the _Multistate Input_ cluster (0x0012). The cube has six sides (duh), numbered as follows:

    | 2 |
+---+---+---+
| 4 | 0 | 1 |
+---+---+---+
    | 5 |
    +---+
    | 3 |
    +---+

Side 5 is with the MI logo; side 3 contains the battery door.

Depending on the action, the following values for 0x0012/0x0055 are reported:

• _Shake_: 0x0000 (side on top doesn't matter)
• _90º Flip_ from side x on top to side y on top: 0x0040 + (x << 3) + y
• _180º Flip_ to side x on top: 0x0080 + x
• _Push_ while side x is on top: 0x0100 + x
• _Double Tap_ while side x is on top: 0x0200 + x

_Push_ works in any direction. For _Double Tap_ you really need to lift the cube and tap it on the table twice.
Sometimes I see value 0x0002 - I think when putting the cube on the table/single tapping, but this is not repeatable. Maybe it's when "waking" the cube.

In the _Cluster Info_ plane in the deCONZ GUI, the 0x0012/0x0055 attribute is updated in real-time, but the 0x000c/0x0055 attribute isn't. In the _Report Attribute_ command, this attributes is reported seconds, after the 0xff05 attribute. Could this be a bug in the deCONZ GUI, that it discards the whole message, when it finds an unknown attribute?

[manup]

Awesome! Mine hasn't delivered yet, from your findings it looks to be perfect to trigger some rules.

In the Cluster Info plane in the deCONZ GUI, the 0x0012/0x0055 attribute is updated in real-time, but the 0x000c/0x0055 attribute isn't. In the Report Attribute command, this attributes is reported seconds, after the 0xff05 attribute. Could this be a bug in the deCONZ GUI, that it discards the whole message, when it finds an unknown attribute?

I'll check that, normally every command should be forwarded at least in the apsdeDataIndication(), but the NodeEvent might miss it then the cluster is not defined in the ZCLDB xml file.

[wvuyk]

Sure looks like a fun gadget here.. guessing I will order one to and tag along for testing if that is ok with you all.

[ebaauw]

Sure looks like a fun gadget here.. guessing I will order one to and tag along for testing if that is ok with you all.

Yes, please, the more the merrier!

I'll check that, normally every command should be forwarded at least in the apsdeDataIndication(), but the NodeEvent might miss it then the cluster is not defined in the ZCLDB xml file.

The cluster is defined, as is the 0x0055 attribute, but the 0xff05 attribute isn't. Haven't tried adding it to the file yet.
Edit: After adding the 0xff05 attribute, the fields are updated.

Awesome! Mine hasn't delivered yet, from your findings it looks to be perfect to trigger some rules.

Loads of rules! It has 43 (if I count correctly) different values for 0x0012/0x0055. Would we want to expose the raw value as buttonevent (like we do for the Hue tap)? Or would we want to map them to a b00a scheme (where _b_ is the button and _a_ the action, like for the Hue dimmer and Trådfri remote)? And if so, how would we map the raw values to these? We probably need more advanced rule conditions to leverage the cube in full. Or only support the basic functions (_Shake_, _Flip 90º_, _Flip 180º_, _Push_, _Double Tap_) and ignore/hide which side is on top? Or use a second state attribute for the side?

Mapping the rotation is going to be even more challenging. I think we would need to translate the angle into a series of button events (cf. holding a button), where the number of x001 events corresponds to the size of the rotation. E.g. 30º would be 2000, 2002; 90º would be 2000, 2001, 2001, 2003; and -90º would be 3000, 3001, 3001, 3003. This would allow for rules similar to those for the _DimUp_ and _DimDown_ buttons of the Hue dimmer or Trådfri remote.

[wvuyk]

Spontaniously, I would not go for the 43 options/rules. Practically this would never work I think. Just think how you would want a simple guy like me to memorize 43 options to reach my goal ;-)
I would suggest to go for the basic function and then think of adding the side option..... Short, start at the bottom and then extend?
BTW, placed my order just now. Guess its waiting time now for me

[ebaauw]

Implemented provisional support in PR #139, using the raw values for state.buttonevent.

[manup]

If I'm lucky the cube and various other Xiaomi sensors will arrive today :)

The cluster is defined, as is the 0x0055 attribute, but the 0xff05 attribute isn't. Haven't tried adding it to the file yet.

The deCONZ core will be extended so that yet unknown clusters and attributes will be attached on arrival of ZCL attribute reports. This is possible since the reports contain all the information including datatype (beside the complexity the ZCL generic stuff is really nice).

Loads of rules! It has 43 (if I count correctly) different values for 0x0012/0x0055. Would we want to expose the raw value as buttonevent (like we do for the Hue tap)? Or would we want to map them to a b00a scheme (where b is the button and a the action, like for the Hue dimmer and Trådfri remote)? And if so, how would we map the raw values to these? We probably need more advanced rule conditions to leverage the cube in full. Or only support the basic functions (Shake, Flip 90º, Flip 180º, Push, Double Tap) and ignore/hide which side is on top? Or use a second state attribute for the side?

I'm for an abstract simple approach like the six sides mapped to buttonevent 1000–6000 with meaningful actions press, release, shake, etc. That way it should be relative easy to configure useful rules and maybe provide an nice ui for selecting actions :)

Mapping the rotation is going to be even more challenging. I think we would need to translate the angle into a series of button events (cf. holding a button), where the number of x001 events corresponds to the size of the rotation. E.g. 30º would be 2000, 2002; 90º would be 2000, 2001, 2001, 2003; and -90º would be 3000, 3001, 3001, 3003. This would allow for rules similar to those for the DimUp and DimDown buttons of the Hue dimmer or Trådfri remote.

The buttonevent attribute seems to be not appropriate to represent rotation, just an idea but I can imagine a ZHAGyro sensor here state: { x: -90, y: 0, z: 0}. I reckon there will be more sensors of this kind in future.

[ebaauw]

BTW, placed my order just now. Guess its waiting time now for me

If I'm lucky the cube and various other Xiaomi sensors will arrive today :)

I hope you get yours soon! This waiting on Chinese shipments is not my thing...

Spontaniously, I would not go for the 43 options/rules.

I'm for an abstract simple approach

Agreed.

I do want to be able to support different use cases:

1. Actual home control. You'd probably only want to use the different gestures on the cube and ignore which side's on top. Ideally, you'd only need to create a single rule per gesture;
2. Fooling around. I'd leave the cube inconspicuously on the table for my nephew to find it. The more erratic my home reacts to the cube, the more fun we'll have. I'll happily create 43 different rules for this (actually, I use scripting for that).

In other words, we need to cater for both simple and complex rule schemes.

the six sides mapped to buttonevent 1000–6000 with meaningful actions press, release, shake, etc.

So e.g. push while side 1 is on top would be 1001, for side 2: 2001, for side 3: 3001, etc. For the second use case, I really don't mind, but for the first, you'd need a rule condition for push. In this scheme, that condition would be buttonevent % 10 == 1, which cannot be expressed in the current rule syntax. Consequently, you'd need six rules with six different conditions: buttonevent == 1001, buttonevent == 2001, etc.

If we were to flip the coding: use the action for the 1000s and use the side for the 1s, we'd have e.g. push for side 1: 1001, for side 2: 1002, for side 3: 1003, etc. Now the condition becomes buttonevent / 1000 == 1. This still not expressible in the rule syntax, but buttonevent > 999 && button event < 2000 is!. So now you'd only need a single rule, albeit with two conditions (and one for lastupdated).

The buttonevent attribute seems to be not appropriate to represent rotation

No, it doesn't. And yet, it sort of does. Note that the cube is stateless: it only reports gestures. If I gently flip the cube, it doesn't send any _Report attributes_, so there's no way of knowing which side currently is on top, or what the actual rotation orientation is.

I reckon there will be more sensors of this kind in future.

I suppose the IKEA dimmer?

Again thinking use cases: I'd want to dim my lights by rotating the cube. Of course, when I rotate a small angle, I'd want to change the brightness a little bit, and when I rotate a big angle, I want a big change in brightness. Ideally, I would be able to pass the angle reported by the cube as parameter to the action to set bri_inc. While I think it's safe to assume bri_inc will be implemented shortly (hint ;-), I don't think we'll have parameters to actions anytime soon (if at all).

Again, I could workaround this by creating a whole bunch of rules, which different conditions: angle > 0, angle > 29, angle > 59, etc. and issue a bri_inc from each each rule (so with value 60, we'd issue three bri_incs. From an REST API consumer perspective, I'd rather create a single rule for the x001 buttonevent and receive a variable amount of events, depending on the angle.

BTW: I don't think there's a hard limit on the number of rules that deCONZ supports? I'm currently on 231 rules with 693 conditions and 377 actions on my RaspBerry Pi 3. This is more than I'd need once I no longer need to workaround issue #98 (dare I give another hint ;-). Even then, this is obviously way too much to manage manually. I really think we need to care not to explode the number of rules needed for using the cube.

[manup]

Depending on the action, the following values for 0x0012/0x0055 are reported:

Shake: 0x0000 (side on top doesn't matter)
90º Flip from side x on top to side y on top: 0x0040 + (x << 3) + y
180º Flip to side x on top: 0x0080 + x
Push while side x is on top: 0x0100 + x
Double Tap while side x is on top: 0x0200 + x
Push works in any direction. For Double Tap you really need to lift the cube and tap it on the table twice.
Sometimes I see value 0x0002 - I think when putting the cube on the table/single tapping, but this is not repeatable. Maybe it's when "waking" the cube.

In the Cluster Info plane in the deCONZ GUI, the 0x0012/0x0055 attribute is updated in real-time, but the 0x000c/0x0055 attribute isn't. In the Report Attribute command, this attributes is reported seconds, after the 0xff05 attribute. Could this be a bug in the deCONZ GUI, that it discards the whole message, when it finds an unknown attribute?

The package has delivered, I can confirm the above observations — oh the possibilities :) This is a very children friendly device.

[ebaauw]

This is a very children friendly device.

Makes you never want to grow up ;-)

oh the possibilities

Love to hear you view how to tame these (see my earlier post).

Below the changes I made to the ZCLDB xml file, to monitor the values from the deCONZ GUI _Cluster Info_ panel. Alternatively, use my PR in combination with a web sockets monitor to see which events reach deCONZ.

Unlike my initial observation 0x000c/0xff05 does occasionally change value while rotating the cube. I haven't been able to detect any pattern, nor what this attribute stands for.

    <cluster id="0x000c" name="Analog Input (Basic)">
        <description>An interface for reading the value of an analog measurement and accessing various characteristics of that measurement.</description>
        <server>
            <attribute-set id="0x000" description="Analog Input Information">
            <attribute id="0x0051" type="bool" name="Out of service" required="m" access="rw" default="0"></attribute>
            <attribute id="0x0055" type="float" name="Present value" required="m" access="rw" default="0"></attribute>
            <attribute id="0x006f" type="bmp8" name="Status flags" required="m" access="r" default="0">
                <value name="In Alarm" value="0x01"></value>
                <value name="Fault" value="0x02"></value>
                <value name="Overidden" value="0x04"></value>
                <value name="Out_of_Service" value="0x08"></value>
            </attribute>
            <attribute id="0xff05" type="u16" name="Unknown" required="o" access="r" default="0" showas="hex"></attribute>
            </attribute-set>
        </server>
        <client>
        </client>

    <!-- TODO -->
    </cluster>

    <cluster id="0x0012" name="Multistate Input (Basic)">
        <description>Provides an interface for reading the value of a multistate measurement and accessing various characteristics of that measurement. The cluster is typically used to implement a sensor that measures a physical quantity that can take on one of a number of discrete states.</description>
        <server>
            <attribute-set id="0x000" description="Multistate Input Information">
            <attribute id="0x004a" type="u16" name="Number of states" required="m" access="rw" default="0"></attribute>
            <attribute id="0x0051" type="bool" name="Out of service" required="m" access="rw" default="0"></attribute>
            <attribute id="0x0055" type="u16" name="Present value" required="m" access="rw" default="0" showas="hex"></attribute>
            <attribute id="0x006f" type="bmp8" name="Status flags" required="m" access="r" default="0">
                <value name="In Alarm" value="0x01"></value>
                <value name="Fault" value="0x02"></value>
                <value name="Overidden" value="0x04"></value>
                <value name="Out_of_Service" value="0x08"></value>
            </attribute>
            </attribute-set>
        </server>
        <client>
        </client>
    <!-- TODO -->
    </cluster>

[wvuyk]

I hope you get yours soon! This waiting on Chinese shipments is not my thing...
I have ordered two yesterday, waiting time will be 9 to 14 days.

As a guy with a soft spot for gadgets, this is indeed a long wait! Won't grow up anymore I think :-) I know what you're saying there @ebaauw .... But at least I can prepare playing with it in my head for now....

Actual home control. You'd probably only want to use the different gestures on the cube and ignore which side's on top. Ideally, you'd only need to create a single rule per gesture;
In other words, we need to cater for both simple and complex rule schemes.

I am looking a bit of a different standpoint. as I am not looking for rules on the gateway level really, my users like to be able to control many types of devices within their system that can be Zigbee of course, X10, Zwave, klikaanklikuit or other protocol types of devices. And this is done with events and action controled outside the gateway, in the homeseer environment.
That is a bit of the fun with homeseer, you can combine all different kinds of control together.
So in my case I am very interested in getting those changes in the REST API, in a useful way so I can present this to the user. The user takes the status set by my plugin in the homeseer system and then choose what it will trigger from there.

The side of the cube could be an important parameter pointing to the light I am controlling (or a thermostat, blinds, whatever...). So it is a bit of a bummer that this status is not always updated. Maybe I could guide this a bit to my users by expecting a push for instance before enabling triggering a shake or accepting a second push shortly after that?
Other usage gestures I can imagine for for the plugin (limiting myself now):

• A double tap could toggle on/off of for the device that is 'çonnected' to the the current side of the cube
• a twist could influence the inc_bri, inc_ct, inc-sat or inc_hue, whatever the user likes to do through my plugin. But this might get confusing , as the user might also twist to control a new device. if there is a way to tell my user to push first, so I know my current side .
• a shake could be used to say move the device to a different (random) colorsetting (how sensitive is the shake? Would a speaker cone do something there?)

Lots of possibilities here, am seeing lots of use cases in my house, for laying, but also serious (how about shaking to put the TV on... a double push for changing channels.....).
In summary I would need values for the following statuses in the WebSocket/REST API:

• side up for the cube
• shake
• push
• tap?
• double tap

Just thinking out loud here...

[ebaauw]

In summary I would need values for the following statuses in the WebSocket/REST API:

I documented the raw values above. Whatever mapping we'll make, we won't be able to create more info. Currently, I'm exposing these raw values 1:1 as buttonevent values. Basically you're stating the same as I: you want to be able to get "everything" the cube reports for use in your home automation (be it homeseer, gateway rules, ...).

So it is a bit of a bummer that this status is not always updated.

The cube doesn't keep a status - it just sends notifications for gestures: _Shake_, _Push_, _90º Flip_, _180º Flip_, _Double Tap_, _Rotate_.
For _90º Flip_, _180º Flip_, _Push_, _Double Tap_ the (new) side on top is included in the notification. For _Flip 90º_, even the old side on top is included. For _Shake_ or _Rotate_, the side on top is not included. For _Rotate_ the angle (of the rotation, not of the cube's orientation) is included, for the other gestures, it isn't.

Sometimes the cube doesn't register a gesture, so it doesn't send a notification, e.g. if I gently flip the cube. When the next gesture is _90º Flip_, _180º Flip_, _Push_, or _Double Tap_, it sends the actual (new) top side during that gesture. When the next gesture is _Shake_ or _Rotate_ it doesn't send the top side. Any status tracking of which side would be on top in between _90º Flip_, _180º Flip_, _Push_, or _Double Tap_ notifications is your own guess.

[wvuyk]

I guess I will need to play with it when it arrives.. Will set it in toy mode surely before getting too serious..

If with a 90° flip the old side is delivered, then that is promising, as we can calclulate the old side for 180° Flip as well right? With push old side should show the correct side for the plugin, as does Double tap. As for shake or rotate I could use the saved value for last know side, or demand a push before excuting shake or rotate.

I am glad you are sharing the experiences, trying to get the picture in my mind how to get it all and make this usefull for the users.
back to my cave, waiting for postman

[ebaauw]

we can calclulate the old side for 180° Flip as well right?

Yes, see the "map" I drew of the sides.

[wvuyk]

Ok, I was really thinking on the thumb of "7". If you want to know what is on the other side of a dice, the sum of top and bottom is 7. I am expecting it would not be much different for this cube. The other side of 3 is 4, the other side of 1 is 6 etc. For the 90° flip it is more difficult, as you could go 90° left, right, forward of backward...

[ebaauw]

I was really thinking on the thumb of "7"

I was as well. Let's renumber the sides, so opposite sides add up to 7 (and the opposite side can be computed by 7 - side). Taking a small sample of the dice I have at home, with 1 on top and 2 on front, 3 is on the right. So the numbers would become:

    | 5 |
+---+---+---+
| 4 | 1 | 3 |
+---+---+---+
    | 2 |
    +---+
    | 6 |
    +---+

where side 2 holds the MI logo and side 6 has the battery door.

For the 90° flip it is more difficult, as you could go 90° left, right, forward of backward...

The cube doesn't know its orientation. It only knows that you flip to side 1 from side 3, which could be front, right, back, left, depending on the orientation.

I'm for an abstract simple approach like the six sides mapped to buttonevent 1000–6000 with meaningful actions press, release, shake, etc.

Let's try that for now. We need to add 7000 for gestures where there's no side (shake, rotate). As for the action, I would use the previous side here, with 0 for push, the same side for double tap, the opposite side for 180° flip, and the other four sides for 90° flip. This leads to:

• x000 for push, so 1000, 2000, 3000, 4000, 5000, 6000;
• x00x for double tap, so 1001, 2002, 3003, 4004, 5005, 6006;
• x00o for 180° flip (where o = 7 - x), so 1006, 2005, 3004, 4003, 5002, 6001;
• x00y for 90° flip (where y ≠ x and y ≠ 7 - x), so 1002, 1003, 1004, 1005, 2001, 2003, 2004, 2006, 3001, 3002, 3005, 3006, 4001, 4002, 4005, 4006, 5001, 5003, 5004, 5006, 6002, 6003, 6004, 6005;
• 7007 for shake;
• 7008 for drop (EDITED);
• 7000 for wakeup (the cube sends raw value 2 when I just tap it after a while).

Note: the cube reports these gestures from the _Multistate Input_ cluster on endpoint 2, so these are the state.buttonevent for the corresponding ZHASwitch resource (with a uniqueid of 00:15:8d:00:01:xx:xx:xx-02-0012). The cube reports the rotate gesture from the _Analog Input_ cluster on endpoint 3, which corresponds to a different ZHASwitch resource (with a uniqueid of 00:15:8d:00:01:xx:xx:xx-03-000c). For now I'll continue to use the angle * 100 as its state.buttonevent value (which is positive for clock-wise rotation and negative for counter-clock-wise rotation, whereas in physics, positive angles are counter-clockwise).

[ebaauw]

Added HomeKit support for the cube in homebridge-hue v0.5.23 (based on PR #146).

[ebaauw]

@manup, could you please post the resources for the Xiaomi motion sensor (https://github.com/dresden-elektronik/deconz-rest-plugin/commit/b66487222cd6309a2e7bf771a12b4b5251ddaf8c), so I can add support for this to homebridge-hue as well?

[manup]

Sure, it actually shows as two sensors. The light sensor seems to report too low light levels compared with other light sensors.

 "40": {
        "config": {
            "on": true,
            "reachable": true,
            "tholddark": 12000,
            "tholdoffset": 7000
        },
        "ep": 1,
        "etag": "7c0a0c28a3c8df5aadc71cda3ee3da02",
        "manufacturername": "LUMI",
        "modelid": "lumi.sensor_motion.aq2",
        "name": "Treppe",
        "state": {
            "dark": true,
            "daylight": false,
            "lastupdated": "2017-08-26T10:29:52",
            "lightlevel": 1542,
            "lux": 1
        },
        "swversion": "3000-0001",
        "type": "ZHALightLevel",
        "uniqueid": "00:15:8d:00:01:a2:4a:ff-01-0400"
    },
    "41": {
        "config": {
            "duration": 60,
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "7c0a0c28a3c8df5aadc71cda3ee3da02",
        "manufacturername": "LUMI",
        "modelid": "lumi.sensor_motion.aq2",
        "name": "Treppe",
        "state": {
            "lastupdated": "2017-08-26T10:29:52",
            "presence": false
        },
        "swversion": "3000-0001",
        "type": "ZHAPresence",
        "uniqueid": "00:15:8d:00:01:a2:4a:ff-01-0406"
    }

[ebaauw]

Thanks @manup!

I assume it uses _Report Attribute_ commands for the 0x0400 and 0x0406 clusters, like the other Xiaomi devices?

The light sensor seems to report too low light levels compared with other light sensors.

That could be compensated by adjusting config.tholddark and config.tholdoffset and only using state.dark and state.daylight in rules.
Better, of course, is to lookup "lightlevel" in a Chinese dictionary and see how their value translates to the ZHA value. Also, there might be another attribute in the _Report Attributes_ command for the 0x0400 cluster (cf. the _Scaled Value_ and _Scale_ in the _Pressure Management_ cluster for the weather sensor, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/57#issuecomment-323532612).

Out of interest, does the 0x0406 cluster support _PIR Occupied to Unoccupied Delay_? I'd expect not, as all other Xiaomi devices only support attribute reporting.
EDIT: Ah, I see that's already answered here: cc4a5ec71c869e3e49970f1a476679cfb6502820

Does it also report when motion is no longer detected (like the Hue motion sensor), or only when motion is detected (like the TRADFRI motion sensor)?

[manup]

I assume it uses Report Attribute commands for the 0x0400 and 0x0406 clusters, like the other Xiaomi devices?

It does, there is also a manufacturer specific report to basic cluster, haven't figured out what it does yet (maybe battery report).

That could be compensated by adjusting config.tholddark and config.tholdoffset and only using state.dark and state.daylight in rules.

Yes these should be adjusted.

Better, of course, is to lookup "lightlevel" in a Chinese dictionary and see how their value translates to the ZHA value. Also, there might be another attribute in the Report Attributes command for the 0x0400 cluster (cf. the Scaled Value and Scale in the Pressure Management cluster for the weather sensor, see #57 (comment)).

The ZCL values and based on lux value is defined by the ZCL spec, maybe Xiaomi is creative here again and they just forward the raw lux value, so we just could skip the transform. Needs more observation but by looking on the values it kinda makes sense.

Does it also report when motion is no longer detected (like the Hue motion sensor), or only when motion is detected (like the TRADFRI motion sensor)?

It seems that the sensor only reports 0x01 as presence when motion is detected, same is true for light value. When no motion is detected it keeps total radio silence, very likely to safe battery.

[ebaauw]

It does, there is also a manufacturer specific report to basic cluster, haven't figured out what it does yet (maybe battery report).

The other Xiaomi sensors seem to send a report for 0x0000 when the setup button is pressed, but I don't think I saw the _Manufacturer Specific_ flag set in any of these. I did capture several of these (this is from the weather sensor):

Frame 446: 87 bytes on wire (696 bits), 87 bytes captured (696 bits)
IEEE 802.15.4 Data, Dst: 0x3d2e, Src: 0x6799
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x6799
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
    Destination Endpoint: 1
    Cluster: Basic (0x0000)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 48
ZigBee Cluster Library Frame, Command: Report Attributes, Seq: 83
    Frame Control Field: Profile-wide (0x18)
    Sequence Number: 83
    Command: Report Attributes (0x0a)
    Attribute Field, String: 
!!�!

        Attribute: Unknown (0xff01)
        Data Type: Character String (0x42)
        Length: 37
        String: \001!\027\f\004!\357\277\275\023\005!\n

Wireshark actually truncates the string, because it contains \0 (0x00) characters, but there's a full 37 bytes of data. I figured it might be a logo, picture, or some Chinese text for the Mi app, but in my very small sample, I see different values for one byte.

[manup]

For the motion sensor it happens after I tried to read the occupancy attribute. Same attribute is reported, 34 bytes, attribute id 0xff01 with manufacturer code 0x115f.

[wvuyk]

I received my cube today. I have the cube connected to deCONZ, but no reports yet in the REST api. Do I miss a step or is it not available?

[ebaauw]

You might need to read the Basic cluster attributes manually in de the deCONZ GUI, while moving/shaking the cube to keep it awake, while the network is open. Two sensor resources should be created: one for Shake/Push/Double Tab/Flip 180°/Flip 90°, and one for Rotate.

[wvuyk]

Had to leave to do some chores for the wife... WAF huh? Came back, no responses anymore on the REST api, a restart done, now still the map is incomplete... I think the deCONZ is not liking the new device here....

[wvuyk]

After a long wait, the cube came visible. I have deleted it, and again rebooted the raspbee. Same issue, map not building up.... am afraid it will be a candlnight here..

[manup]

If no lights showup you may check if the channel is still correct in the deCONZ settings (there is a bug which might have happened here).

Also, have you tried to powercycle a light?

[wvuyk]

No lights were showing, only a few motion sensors (not all) the channel setting in deCONZ is still the same (15) here. Swithing a few lights on/off here makes the light return - but it seems to have lost its name - and they start as yellow - router, but turn red within a few seconds. there seems to be no more communication?

[manup]

This looks very much like the bug I mentioned.
Can you please try the following

• open deCONZ Settings
• increase NWK Update ID by 1
• press Save button
• press Leave button
• after a few seconds press Join button
• power cycle the lights again

[wvuyk]

What I notice here also is that I cannot see the second bullet (hardly could anyway) on the devices anymore, so cannot read the clusters ....

[wvuyk]

Ok, will try now

[manup]

What I notice here also is that I cannot see the second bullet (hardly could anyway) on the devices anymore, so cannot read the clusters ....

Yea, the UI needs to improve color contrast.
No second button means that the device descriptors (in ZigBee called simple descriptors) have not been queried yet.

[wvuyk]

Increasing the NWK update worked here, pfeewww! Thanks a lot!
Should I try to add the cube again or wait for now?

[manup]

Cool, yes this should be safe, I don't think the cube caused the problem.

[ebaauw]

The cube is way to cool to cause problems ;-)

[wvuyk]

LOL I am hoping... No response on the REST api yet. But I do see the clusters I think?

[ebaauw]

Yup, that looks familiar (see first post to this issue). The _Manufacturer Name_ and _Model Identifier_ in the _Basic_ cluster must be read, before the REST API plugin recognises the cube and creates the sensor resources.

[wvuyk]

Those are read I think? i see them in the cluster info:

[ebaauw]

Yes, looking good. Now the resources should be created when you open the network (from the Settings menu in the web app).

[wvuyk]

You just lost me? I have added the device by opening the network already? It is how it appeared in deCONZ. But no sensor REST api responses? I did the same just now, on the web app, but no responses still. It says silent so far?

[wvuyk]

Opened the cube just now and did a press on the link button dusring the open network. Now sensors are reported. Why do I need to do this twice? First to add it to deCONZ and another to activate the resources?

[ebaauw]

The REST API plugin only adds resources while the network is open.

As far as I understand, there's three steps involved in adding a device:

1. Joining the network (causing the node to show in the GUI);
2. Reading the device endpoints, clusters, and Basic configuration (causing the node to be populated in the GUI);
3. Creating the REST API resource(s), based on the device configuration.

Normally, these steps follow in quick succession. However, battery-powered devices tend to fall asleep during step 2. The Xiaomi devices more often than the Hue motion sensor and dimmer switch. You can "repair" that by manually reading the attributes while forcing the device to be awake (moving the magnet, pressing a button, waiving in front of the sensor, ...). But the network still needs to be open for the REST API plugin to create the resource afterwards.

Alternatively, keep bugging the device while joining, to prevent it from falling asleep in the first place. It takes some practice, and even then sometimes a couple of attempts. Worst case, power off your lights (and other ZigBee routers) and keep the device close to the RaspBee when joining, to prevent any hopping.

[wvuyk]

Ok, will test that on later. I have a second one waiting here. I will dance while Joining this one to the network and see if that works :-)

[snozzlebert]

Yesterday I received my cube and tried to add it to deCONZ. It took a while before Multistate Input and Analog Input appreared in the deCONZ API and before the 2 sensors appeared in the rest api. Don't know the exact steps to describe what I did to get it working (open network, pressing buttons, shaking, etc). Eventually both sensors appeared in the rest api. I'm able to get all the events of the Multistate Input sensor (0012). When connected to the websocket I notice some delay between the cube action and the event: about 1 second.
When rotating the cube, the analog sensor is triggered:

{"e":"changed","id":"13","r":"sensors","state":{"buttonevent":0,"lastupdated":"2017-09-10T10:01:25"},"t":"event"}

(multiple times)

However the value of buttonevent is always 0. I tried all kinds of rotations in different directions. Is there a way to fix or debug this?

[wvuyk]

Same here. Was concentrating on the multistate values here, but indeed also noticed the "buttonevent":"0" on the analog sensor.....

[ebaauw]

Did you guys add the 0xff05 attribute to the analog input cluster in the ZCLDB? See: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/138#issuecomment-324911430.

[wvuyk]

No, I skipped that, thinking it would be updated during upgrade....

[manup]

Just building the 2.04.76, the attribute is added there..

[manup]

Fresh baked :)

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

[wvuyk]

@manup many thanks! I have installed the new version and am now seeing the values for the rotation as well. Would love to connect this to the hue and/or dim values! I will be dividing the angles back with 100 here as I do not need the high values, angle would be enough for me I think.

Am also glad with the reduced number of websocket calls for sensors in this version, checked it, just one for one event thanks!

[Krocko]

I have a question about the usage of the Cube. On side 3 i have a Action „turn off light xy“.
Side 3 is on top, light xy is on. How can i use now the Action from side 3, without toggling an Action from an other side?

[ebaauw]

You could try and lift the cube and flip it gently and then flip it back to side 3 the normal way. Or you configure it to turn the light off on double tap or push instead of on flip.

[Krocko]

Ah yeah. That‘s an idea. Thank you.

[iantait]

I've got a cube recognised in home app - but with 9 unconfigured buttons - if I try and add actions for buttons in the home app, I get an error 'Could not add automation Front Room lumi sensor cube 2 Side 1 Single Press" for example.

Is there another method to add actions for the cube?

[ebaauw]

You could try and create a rule with a condition on the Programmable Switch Event in Eve (they now support Stateless Programmable Switches in v3.0).

I fear this won't help. It looks like the error is on the HomeKit side, probably a miscommunication between your iPhone/iPad and your AppleTV. I'd try and restart the AppleTV first, maybe then the iPhone/iPad. Are all on iOS 11.2.1 and tvOS 11.2?

[iantait]

It shows up in the new Eve, with unconfigured scene assignment, but won't let me assign them :-) I'll keep fiddling...

[iantait]

T'was the apple tv. I've plumbed in an ipad, and now works.
Thanks very much for all your work on this.

[olemr]

Great work!
I got my shipment from Aliexpress a week ago.
My first mistake was ordering the Xiaomi Gateway, but one learns from ones mistakes. :-)
The Gateway was OK, and it interfaced nicely with the openHAB binding, but it only reported gestures. Not which side was facing up. This was really a showstopper for me as my main application is using this cube as a TV channel remote for my old mother. Thinking channel logos on the faces.

Anyway, after some creative Googling I came across deCONZ and ordered the ConBee on Amazon.

Now I'm able to get the face data through the REST API. Nice!
I bought 5 white Aqara and 3 pink Mi cubes, but i now faces the same problem as others described here
(The Xiaomi Gateway also did not expose the Aqara Cubes, just the Mi cube, on the API)

I'm on 2.05.20 testing on Windows at the moment. (Will move to openHAB Ubuntu server).
Being a newbie here, I was not able to find any pre-compiled betas for Windows.
Is it a description somewhere on how to compile and install a snapshot/beta of the API?
Is it a Jenkins setup somewhere?

What is the ETA for a release that will support the Aqara cubes?
These are the cubes delivered from many Aliexpress vendors when ordering Mi cubes.

Finally, since I played with the original Ziaomi Gateway, I just want to point you to a gesture you might have missed: FREE-FALL, Throwing the cube into the air sets id 0x0055 to value 0x0003. Similar to shake, it is not face-up related. Getting this into the REST API would also be nice.

Edit:
Testet the Shake gesture, and that is not provided through the REST API.
Is this by choice?

[ebaauw]

Which cube model are you talking about? deCONZ issues buttonevent 7007 when I shake my old model (non Aqara) cube.

[olemr]

I stand corrected.
I just got confused by the raw 0x0055=0 value mapping to 7007 buttonevent.
The free-fall gesture (0x0055=3) is not coming through to the buttonevent thought.

[ebaauw]

Just did some juggling with my cube, and, indeed, it reports a _Present value_ of 3. Hadn't seen that before. I'll map it to buttonevent 7008.

PR #632.

[olemr]

Sorry for whipping this closed thread (tell me if you want me to open a new issue), but I just want to come with an observation.
I have interfaced openHAB to the deCONZ REST API using their http binding.
It does a GET of sensor 3 every 500ms

// deCONZ Cube Pink1 side/gestures sensor 3
MiCubePink1GestureCache.url=http://127.0.0.1:8090/api/071E2774E0/sensors/3
MiCubePink1GestureCache.updateInterval=500

I have a rule triggering every time lastupdated changes:

rule "Xiaomi Cube action"
when
    Item Pink1CubeButtonLastUpdated changed
then
    Thread::sleep(600)
    var actionName = Pink1CubeButtonEvent.state

    var name = "Cube P1" 
    logInfo(name, "Event: " + actionName)
}

Note the Thread:sleep(600) I had to put in.
Without that delay, I was always reading the previous value of buttonevent.

Could it be that the state lastupdated is updated before the buttonevent?
If so, wouldn't it make sense to do all other updates before updating lastupdated?

Apologies if the problem I'm seeing is not deCONZ related.

[ebaauw]

Could it be that the state lastupdated is updated before the buttonevent?

I don't know how OpenHAB works, but in deCONZ state.lastupdated is updated immediately _after_ the "real" state attribute has been updated. I don't think it's possible for a REST API request to be handled in between the two updates, so you would either get both updated values, or both previous values. A delay of 600ms (I assume) is ridiculously long. I suspect state.buttonevent value is only retrieved in the next poll cycle. Best raise an issue with OpenHAB or the OpenHAB deCONZ plugin/binding/interface (I don't know what it's called).

I have interfaced openHAB to the deCONZ REST API using their http binding.
It does a GET of sensor 3 every 500ms

That might be stretching it (depending on what hardware deCONZ runs on). I find that the Hue bridge cannot handle polling more frequently than once every two seconds (2000ms). I never tested this extensively with deCONZ, because, in my HomeKit plugin, I use the web socket events for instant notifications, instead of polling deCONZ. I think OpenHAB should do this as well.

[olemr]

deCONZ state.lastupdated is updated immediately after the "real" state attribute has been updated.

Fine, just wanted to check the source first.
But you are right, the problem must be at the openHAB end.
I've set up a polling to cache scheme per sensor, but it is probably better to poll the whole /sensors list and then do the JSON picking afterwards.

I also found that reducing the Thread:sleep to just 10ms also did the trick.

My deCONZ is running on the same host as openHAB on a Intel Celeron 2957U / 1.4 GHz so polling the two sensors makes top show deCONZ with 2-3% CPU every now and then.

Thank you so much for your help so far. Maybe tomorrow we will see how the Aqara cubes fare? :-)
Cheers.

[tamasv]

@ebaauw I'm currently running deconz 2.05.35, but i seems, that analog input events are not broadcasted over websocket.
Would it be possible, to broadcast an event json with the angle and/or raw value when a rotation is detected?

[ebaauw]

analog input events are not broadcasted over websocket.

They are:

Sep 14 23:57:28 pi2 dc_eventlog[691]: /sensors/228/state: {"buttonevent":7000,"lastupdated":"2018-09-14T21:57:28"}
Sep 14 23:57:29 pi2 dc_eventlog[691]: /sensors/229/state: {"buttonevent":-7868,"lastupdated":"2018-09-14T21:57:29"}

Note that the cube has two /sensors resources: one for the digital events (228 in my case) and one for the analogue events (229 in my case):

$ ph get /sensors/228
{
  "config": {
    "battery": 100,
    "on": true,
    "reachable": true,
    "temperature": 2000
  },
  "ep": 2,
  "etag": "27d4258488358758cac767f7f26405c3",
  "manufacturername": "LUMI",
  "mode": 1,
  "modelid": "lumi.sensor_cube",
  "name": "Living Room Cube",
  "state": {
    "buttonevent": 7000,
    "lastupdated": "2018-09-14T21:57:28"
  },
  "swversion": "3000-0001",
  "type": "ZHASwitch",
  "uniqueid": "00:15:8d:00:01:0a:ec:25-02-0012"
}
$ ph get /sensors/229
{
  "config": {
    "battery": 100,
    "on": true,
    "reachable": true,
    "temperature": 2000
  },
  "ep": 3,
  "etag": "a93d453a488630505d2c51756a16a1d9",
  "manufacturername": "LUMI",
  "mode": 1,
  "modelid": "lumi.sensor_cube",
  "name": "Living Room Cube",
  "state": {
    "buttonevent": -7868,
    "lastupdated": "2018-09-14T21:57:29"
  },
  "swversion": "3000-0001",
  "type": "ZHASwitch",
  "uniqueid": "00:15:8d:00:01:0a:ec:25-03-000c"
}

[tamasv]

thanks for the info!
However, my logs are a bit different.

06:50:52:165 Websocket 192.168.X.X:46296 send message: {"e":"changed","id":"2","r":"sensors","state":{"buttonevent":6006,"lastupdated":"2018-09-15T06:50:52"},"t":"event"} (ret = 115)
06:50:52:165 Websocket 192.168.X.X:47944 send message: {"e":"changed","id":"2","r":"sensors","state":{"buttonevent":6006,"lastupdated":"2018-09-15T06:50:52"},"t":"event"} (ret = 115)
06:50:55:412 APS-DATA.indication srcAddr: 0x00158d000278f0ef, dstAddrMode: 2, profile: 0x0104, cluster: 0x000C, lqi: 255, rssi: -58
06:50:55:413 ZCL attribute report 0x00158D000278F0EF for cluster 0x000C, ep 0x03
06:50:55:413 Node data 0x00158d000278f0ef profileId: 0x0104, clusterId: 0x000C
06:51:11:960 APS-DATA.indication srcAddr: 0x00158d000278f0ef, dstAddrMode: 2, profile: 0x0104, cluster: 0x0012, lqi: 255, rssi: -58
06:51:11:960 no button map for: lumi.sensor_cube.aqgl01 ep: 0x02 cl: 0x0012 cmd: 0x0A pl[0]: 055
06:51:11:960 ZCL attribute report 0x00158D000278F0EF for cluster 0x0012, ep 0x02
06:51:11:961 Node data 0x00158d000278f0ef profileId: 0x0104, clusterId: 0x0012
06:51:11:961 update ZCL value 0x0012/0x0055 for 0x00158D000278F0EF after 19 s
06:51:11:964 Websocket 192.168.X.X:46296 send message: {"e":"changed","id":"2","r":"sensors","state":{"buttonevent":6006,"lastupdated":"2018-09-15T06:51:11"},"t":"event"} (ret = 115)
06:51:11:964 Websocket 192.168.X.X:47944 send message: {"e":"changed","id":"2","r":"sensors","state":{"buttonevent":6006,"lastupdated":"2018-09-15T06:51:11"},"t":"event"} (ret = 115)

It shows a doubletap-rotation-doubletap chain and I don't see any "Update ZCL value"/"Websocket send message" for the 00C, which supposed to be the rotation iirc.

[ebaauw]

Could you double-check that you have two sensor resources? If not, better reset the cube, delete the resources through the API, delete the node from the GUI, and re-pair the cube.

Another cause could be that the 0x000C cluster is missing from the ZCL definitions in general.xml. What system do you run deCONZ on? Could you double-check that the cluster is visible in the deCONZ GUI, and the the _Current Value_ attribute (0x0055) gets updated.

[tamasv]

@ebaauw thanks for the info, remove/add just worked fine. It turned out, that the trick is - which I obviously missed in the docs - during Add process I need to do make an action for both sensors ( shaking/rotating the cube and rotating on a flat surface).

Thanks!

[Idelean]

Hey guys!

I am having trouble to setup the cube in Deconz.
I have it connected to Deconz directly, everything seems working as expected, states are detected on Phoscon etc, however I am not able to assign any actions to the cube when I try to add it to a group or equivalent.

any idea ?

[Oliviakrkk]

How to you add the Cube to deconz? I am having issues with pairing...

[siggi85]

How do I have to add the cube? I have issues too with pairing. Other sensors from aqara are no problem.

[pawelbura]

@Oliviakrkk, @siggi85 try to get cube very close to ConBee stick (for pairing) and check battery (low battery is casing problems).
Than try to trigger the reset button (short press) (under the cover), shake the cube, flip it 90° etc. to trigger events and keep it awake.
I took me something like 15 seconds of shaking and it works :)

[siggi85]

@Oliviakrkk, @siggi85 try to get cube very close to ConBee stick (for pairing) and check battery (low battery is casing problems).
Than try to trigger the reset button (short press) (under the cover), shake the cube, flip it 90° etc. to trigger events and keep it awake.
I took me something like 15 seconds of shaking and it works :)

Thanks for help! I did it this way long time ago und it worked. 😊