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 (b664872), 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 #57 (comment)).

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: cc4a5ec

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]

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

[jaimyborgman]

just received my aqara smart cube today and succesfully connected it with deconz all gestures are recognized except for the rotate version; anyone who could help me to get this enabled? would like to dim my lights with this option which should be possible of course but ain't seeing any events coming through is there another way to test this out?

[SwoopX]

Put it in front of you, start sensor search in Phoscon, do not lift it, but spin clock-/counterclock wise a few times.

[jaimyborgman]

@SwoopX its already connected with deconz... all other gestures are coming through it's only that the motion "rotate" is not being detected. So no issues with connecting it to deconz that's working perfectly fine :-)

[SwoopX]

If you wanna ignore the solution, feel free 🤷‍♂️

[jaimyborgman]

well not ignoring the solution otherwise I wouldn't have asked right? but if that's not helping? 😉

[pawelbura]

@jaimyborgman as it is described here: in Cube there are 2 seperate sensors, and both of them need to be activated.
Try:

• remove cube from Phoscon app
• get cube very close to ConBee stick (for pairing)
• check battery (low battery is casing problems).
• 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 was trying couple of times, but finnaly succeded

[jaimyborgman]

@pawelbura many thanks for taking the time to reply! I’d already managed to get it working shortly after my first question.

I’d removed indeed the cube first and then paired it first as a sensor by rotating it on its own axes. After that I’d again paired it as a switch which eventually resulted in both sensors being registered under the switch tab.

At first pair I’d connected it as a switch which resulted in issues in deconz for me also while trying to add it as a sensor after it turned green but wasn’t showing up.

So the order of the steps taken are important; first the sensor after the switch worked out perfectly fine for me!

[SwoopX]

Erm, deleting the sensor shouldn't have been necessary but great that it works now.

by rotating it on its own axes.

That's what I said, right? Badly expressed?

Btw, you can create both sensors while searching for sensors. When the first one is found, you get the green success indication but the network is only closed after do click on the button. So by not clicking it, it should allow you enough time to perform gestures required for both sensors.