Xiaomi Mi Smart Cube - Githubissues

ebaauw commented 7 years ago

New gadget!

untitled

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

manup commented 7 years ago

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 commented 7 years ago

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:

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;
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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

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

wvuyk commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

ebaauw commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Ok, will try now

manup commented 7 years ago

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 commented 7 years ago

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

manup commented 7 years ago

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

ebaauw commented 7 years ago

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

wvuyk commented 7 years ago

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

ebaauw commented 7 years ago

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 commented 7 years ago

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

ebaauw commented 7 years ago

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

wvuyk commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

Joining the network (causing the node to show in the GUI);
Reading the device endpoints, clusters, and Basic configuration (causing the node to be populated in the GUI);
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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

ebaauw commented 7 years ago

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 commented 7 years ago

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

manup commented 7 years ago

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

manup commented 7 years ago

Fresh baked :)

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

dresden-elektronik / deconz-rest-plugin

Xiaomi Mi Smart Cube #138