[New device support]: Aqara Cube T1 Pro support request

[dabrahim]

Link

https://www.aqara.com/en/product/cube-t1-pro

Database entry

{"id":5,"type":"EndDevice","ieeeAddr":"0x54ef44100062e05a","nwkAddr":25105,"manufId":4447,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.remote.cagl02","epList":[1,2,3],"endpoints":{"1":{"profId":260,"epId":1,"devId":259,"inClusterList":[0,3,6],"outClusterList":[0,3],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}},"2":{"epId":2,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}},"3":{"epId":3,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":25,"stackVersion":2,"hwVersion":1,"dateCode":"20220602","swBuildId":"2019\u0000www.","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1671404743897,"defaultSendRequestWhen":"immediate"}

Comments

I tried creating a custom converter using the one already exisiting for the older model MFKZQ01LM but I was stuck at some point, I didn't know how to properly fill the fromZigbee array in.

External converter

const fz = {...require('zigbee-herdsman-converters/converters/fromZigbee'), legacy: require('zigbee-herdsman-converters/lib/legacy').fromZigbee};
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;

const definition = {
    zigbeeModel: ['lumi.remote.cagl02'],
    model: 'CTP-R01',
    vendor: 'Xiaomi'
    description: 'Aqara Cube T1 Pro',
    fromZigbee: [fz.xiaomi_basic],
    toZigbee: [], // Should be empty, unless device can be controlled (e.g. lights, switches).
    exposes: [e.battery(), e.battery_voltage(), e.angle('action_angle'), e.device_temperature(), e.power_outage_count(false), e.cube_side('action_from_side'), e.cube_side('action_side'), e.cube_side('action_to_side'), e.cube_side('side'), e.action(['shake', 'wakeup', 'fall', 'tap', 'slide', 'flip180', 'flip90', 'rotate_left', 'rotate_right'])],
};

module.exports = definition;

Supported color modes

No response

Color temperature range

No response

[filipeaparicio91]

@oskarslusitis, if your Cube was integrated correctly, you should see a Side Up sensor under the device in HA. It reports whatever side is currently facing up when an action occurs. (From experience, having the cube in scene mode, reports the side up for reliably). You can then use that as an automation condition. In my case, I have an automation set up for each one of the Cube's sides, which are triggered when an mqtt payload is received from the cube. I have 6 automations in total, each one has a condition for Side up of "1, 2, 3, 4, 5 or 6". Then I have a Choose action for each payload value. Ex: if trigger payload is rotate_left, do X, if trigger payload is rotate_right, do Y, if trigger payload is shake, do Z. If you'd like, I can share an example. In fact, I don't think it would be too complicated to whip out a Blueprint for this.

[ybizeul]

you have to be in "action" mode and I believe it's a double tap

I forgot to mention that’s already the mode I’m using.

EDIT: Lol, I just figured it out. It's not tapping the cube, it's tapping the cube on the table :-)

[JuMi2006]

I tried the cube today and was very surprised. After pairing and playing with the cube it switches of every Silvercrest smart plug in my house. Not real funny. ;)

TS011F _TZ3000_kdi2o9m6 https://www.zigbee2mqtt.io/devices/HG06337.html#lidl-hg06337

So now i am not able to figure out more information because i am not alone at home. ;)

[jzee923]

@JuMi2006 a few of us were having a similar issue because the device wasn't being configured properly. You can give my converter code above a try, it works for me.

[JJPro]

I'm thinking could it be like your other devices are bound to coordinator's genOnOff cluster. And then the converter you have also binds the cube's genOnOff to the coordinator's genOnOff. So they now act together.

Check the bind tab on affected devices.

[JJPro]

Then do the following might help:

1. remove genOnOff binding code in your converter
2. add fz.ignore_onoff_report to fromZigbee definition part

[sladiri]

Hi, thanks for the code. My cube Pro is working as well, using the Sonoff 3.0 Usb Plus dongle.

I tried the config by @filipeaparicio91 first (https://github.com/Koenkk/zigbee2mqtt/issues/15652#issuecomment-1378753370). Rotate and tap were both very reliable and instant (I made a video too). For tap I just picked the cube up with my fingers about a cm or two and set it down immediately/abruptly.

Then I tried to change the config from @jzee923 (https://github.com/Koenkk/zigbee2mqtt/issues/15652#issuecomment-1373029151). I did not remove the cube from the network though, I just restarted the addon. Is this a problem? I had errors after this and I had to force-remove the cube.

After pairing it did work, but tap has been very unreliable since then. There i no error, just most of the time, there is no tap event. Sometimes it registers a double-tap.

I tried restarting the Z2M and resetting the cube, didn't help apparently. As I said, initially tap worked 100% of the time, I tried using the cube for the first time too.

I am very new to this and Home Assistant, but I'll try to help debugging, if needed.

[jzee923]

@sladiri according to the documentation a "tap" is triggered by picking up the cube and tapping twice. i do see the tap triggering sometimes when i only do a single tap, however with a double tap it works very consistently for me. regarding any kind of config change, i think it's probably best to first remove the device and re-pair it after using a new config and restarting z2m.

[wvanbruksvoort]

@oskarslusitis, if your Cube was integrated correctly, you should see a Side Up sensor under the device in HA. It reports whatever side is currently facing up when an action occurs. (From experience, having the cube in scene mode, reports the side up for reliably). You can then use that as an automation condition. In my case, I have an automation set up for each one of the Cube's sides, which are triggered when an mqtt payload is received from the cube. I have 6 automations in total, each one has a condition for Side up of "1, 2, 3, 4, 5 or 6". Then I have a Choose action for each payload value. Ex: if trigger payload is rotate_left, do X, if trigger payload is rotate_right, do Y, if trigger payload is shake, do Z. If you'd like, I can share an example. In fact, I don't think it would be too complicated to whip out a Blueprint for this.

If you can share an example or share it as a blueprint would be great 😊

[smartmatic]

@jzee923 Thank you for sharing your code. Its working on my side. Where i am a bit struggling is to change the mode? And what is also not detected is to tap the device in action mode. Do you have some tipps?

[jzee923]

the only way i've been able to use the ui to change modes is by physically clicking the button in the cube once. I believe this sends some kind of ping or wake command and if i immediately try to change the mode in the ui after this it works. that kind of defeats the whole point of a UI button though because if i have to open up the cube to hit the button once, i might as well just hit it 5x.

as far as tap goes, i lift up the cube and tap it against the table twice. this works very consistently for me.

[smartmatic]

as far as tap goes, i lift up the cube and tap it against the table twice. this works very consistently for me.

That works!

[sladiri]

@jzee923 Re-paired the cube. Tap triggered consistently with double tap now, as it should be.

Looks like you need to use it on a flat hard surface, otherwise gestures fail very often.

[jzee923]

If you don't like the official double tap in action mode i think there's a way to replicate a tap in scene mode as well. Every time you flip the cube the side_up action is triggered. It is also triggered if i just lift up and place the cube down quickly (like a tap). so you should be able to compare the previous value of side_up to the current value of side_up and if they are equal you can consider this a "tap" and run whatever automations you need from there. I don't use mine this way, but it is a behavior i've noticed, so in theory it should work. It just requires a few more lines in your automation.

[JJPro]

Hey guys, I have polished my converter, posted here JJPro/CTP-R01-converter, now it supports three new features:

• one minute inactivity (new action)
• mode switch in Z2M frontend
• reconfigure

with guided procedures for paring, reconfiguring, and mode switching.

Please try it out and provide your feedback.

A PR based on it is WIP. Your feedback is valuable to move the PR forward.

Especially for folks who just got their devices fresh and haven't paired yet, your feedback is extremely important. Because as mentioned in previous post, I paired my cube with Aqara hub prior to Zigbee2MQTT, Aqara hub mostly likely initialized something, and I never came across the configuration issue that some other folks had with my first converter attempt. I only have one cube, and can't test that particular part myself. Therefore, your feedbacks are extremely important.

Thanks!

• External Converter: JJPro/CTP-R01-converter
• PR for device image: Koenkk/zigbee2mqtt.io#1833
• PR for converter: Koenkk/zigbee-herdsman-converters#5367

[MisterFab1an]

Just paired my new cube to Zigbee2Mqtt with your converter @JJPro Mode switching works pretty flawlessly and most actions as well However, in action mode, when flip90 is registered, the 3 attributes action_from_side, action_side and action_to_side are also filled but not really correct I think

E.g. cube is in action mode, currently side 3 is up - I flip so that side 2 is up and I get the following values back: "action_from_side":2, "action_side":1 and "action_to_side":1

Full response

``` { "action":"flip90", "action_angle":null, "action_from_side":2, "action_side":1, "action_to_side":1, "angle":16.67, "battery":100, "current":0.001, "device_temperature":25, "from_side":2, "linkquality":135, "operation_mode":"action_mode", "power":0, "power_outage_count":19, "side":2, "side_up":6, "to_side":1, "update":{ "state":null }, "update_available":null, "voltage":3180 } ```

Another example, current side is 5, flip so that 1 is up "action_from_side":4, "action_side":0 and "action_to_side":0

Full response

``` { "action":"flip90", "action_angle":null, "action_from_side":4, "action_side":0, "action_to_side":0, "angle":16.67, "battery":100, "current":0.001, "device_temperature":25, "from_side":4, "linkquality":117, "operation_mode":"action_mode", "power":0, "power_outage_count":19, "side":1, "side_up":6, "to_side":0, "update":{ "state":null }, "update_available":null, "voltage":3180 } ```

Also why are there so many redundant attributes? action_from_side, from_side, action_to_side, to_side, ...

[jzee923]

looks like in the most recent code those actions are being imported from the previous version of the cube where the sides are labeled 0-5 so that's why you're seeing everything is off by 1. it doesn't seem like this will be an issue in his pr code though. It looks like the to_side and from_side stuff has something to do with the legacy api

[oskarslusitis]

From your description looks like enumeration on sides is from 1 to 6, but code is from 0 to 5. I switched to @JJPro new code as well, I'm working my cube in scene mode, have only one side action set up for now and at least for me in scene mode it's side 2 reported up and side 2 actual side up.

[JJPro]

@MisterFab1an Thanks for the feedback, indeed, the sides attributes are returned from the classic cube's function, then I offset them by one, but some are left out by mistake. Fixed now.

As for redundant attributes, @oskarslusitis is right, they're for legacy integration. I have noticed that too, I'll probably look into what legacy integration is tomorrow.

[dedeckerni]

hi, I'm new to zigbee and this Cube T1 Pro was my first device. Can confirm the converter code is working for me + can also switch operating mode between scene/action mode.

Made some basic automations, but I wonder if there is a blueprint for Home Assistant that works with this config?

[JJPro]

@dedeckerni I recommend learning Node-RED, it's super powerful and flexible.

It's easy to pick up and create awesome stuff, if you are okay with JavaScript.

Here is my cube flow for reference:

It can connect anything, e.g. I have a flow that receives server downtime notice via webhook, and then send notifications to HomeAssistant app on my phone and tablets.

I had another flow that checks daily against Aqara server for firmware update of T1 Pro using curl, and send mobile notifications if there is one. But it failed after a few days, cuz the API endpoint requires authentication header, and the user session expired days later.

Materials:

• Steve Cope's youtube
• JSONate in 5 mins

[JJPro]

Hey guys, I suddenly realized that the "one hard shake" thing is actually an unlisted action, it's a forceful one-way movement without backward motion. I named it "throw".

The converter is updated with throw action.

In fact, the throw action could be a perfect trigger for toggling operation mode. With one throw, it both initiates the mode switch command, and makes the cube respond to the command at the same time. Brilliant!

Here's my node-red flow. I use "throw with logo side up" as trigger, and leave other sided throws for other activities.

Pretty cool experience! Don't need to touch z2m frontend to toggle modes any more.

[SirGoodenough]

@JJPro @filipeaparicio91

I have found a problem with all the converter versions offered here... While the flip90 action provides the required side information as needed for automations...

The flip180 action never provides this. It is impossible to build an automation against the cube if the flip180 action doesn't tell me where it is.

This is looking thru MQTT.

As an alternative the from_side and to_side that I also see reported is also only on the flip90, not the flip180 actions.

As a matter of fact, automations to this device and the older generation of the cube should report side and last side on every state change. I would not have to try to generate the last side manually for automations and providing the info should be 'free'...

[SirGoodenough]

Another Observation. The Fall or Drop function is no longer mentioned in the operation manual sent with the device and 'dropping' it like the old one no longer appears to generate any action at all. I am thinking that this action could be removed from the list for this version of the cube.

[oskarslusitis]

This is my first cube, I'm not sure if code is working correctly, but when I do a cold rotate action, it doesn't register half the time. Working in scene mode. Might be just the specifics of this kind of sensor, but boy do I hate unreliable tech. Makes me wonder is it even worth to invest further automations in this :(

[JJPro]

Update

requiresRemoval (See How to Upgrade)

1. improve pairing/reconfigure experience, no longer require user intervention
2. remove legacy integration
3. clean up action* exposes and action payload
   • remove side_up, it is now merged with side
   • add action_from_side to flip180
   • remove from_side
   • remove to_side
   • remove action_to_side
   • remove action_side
   • add new action throw
   • remove unsupported action fall
   • add action flip_to_side

More on flip_to_side (only in scene mode)

This action is reported right before action side_up, and they contain the same info (side).

side_up action always reports, while flip_to_side only reports when the movement is noticeable.

---

Let me know if everything works as expected, I feel like this is very close to completion.

[jzee923]

@JJPro why did you remove side_up? isn't side_up an "action" vs side just being a "state"

[JJPro]

My view on this:

The intuition of side being a state comes from its last value always shown in the exposes table, while action_* related are ephemeral. Right?

The side value stays because the value is cached, same for battery, voltage, device_temperature, operation_mode ...

Its value is updated upon each action report, so it's really part of the action payload.

---

I know I had side_up dedicated to scene mode previously, after thinking twice, I'm leaning towards making scene mode and action mode updating the same side attribute. This, IMHO, keeps the exposes table cleaner, and less confusing for newcomers.

If you were using side_up for automations, now you can use the combination of operation_mode == 'scene_mode' and side values to achieve the same automation.

[jzee923]

oh i think i misunderstood

else if (msg.data.hasOwnProperty(329)) {
      payload.action = 'side_up';
      payload.side = msg.data[329] + 1;
    }

the action is still side_up, you only merged the side_up states. am i getting that right?

[JJPro]

The old cube's code has many seemingly duplicate exposes, IMO, is because that's joint effort from multiple patches over the years, and they were kept to avoid breaking automations already deployed by millions (maybe) of people.

Since this is a new project, we are lucky to start fresh and clean.

[JJPro]

oh i think i misunderstood

else if (msg.data.hasOwnProperty(329)) {
      payload.action = 'side_up';
      payload.side = msg.data[329] + 1;
    }

the action is still side_up, you only merged the side_up states. am i getting that right?

The action name is still side_up, it's just the side value to it is now in side.

See this Supported Actions table.

[amaisano]

FYI: The ControllerX AppDaemon app works really well with this:

https://xaviml.github.io/controllerx/controllers/MFKZQ01LM/#light (using the Z2M config option)

[stephennutt]

I am a complete Zigbee2MQTT noob having just installed 2 days ago. Shockingly, I was able to figure out how to create the external converter. However, the number side up is not agreeing with what is printed on the cube. I can fix in Node Red so there is a workaround but I am concerned I am doing something stupid as a newbie that is easily corrected. Is anyone else experiencing this?

[SirGoodenough]

@JJPro Thanks for the great work here. One question. I assume that even though you use the new 'Throw' action for some baked in functions in the configuration, it is still an action that can be automated against in the real world without and conflicts with it's 'internal' uses.

[JJPro]

Thanks for the great work here.

Glad it works great for you.

One question. I assume that even though you use the new 'Throw' action for some baked in functions in the configuration, it is still an action that can be automated against in the real world without and conflicts with it's 'internal' uses.

Good question. You are exactly right, you are free to use throw for automations, and it won't conflict with internal uses.

---

A bit more on throw

The cube is a battery powered device. To preserve battery, it doesn't always respond to incoming commands (e.g. mode toggle). The auto-response frequency is once per hour. It'll send a dataObject247 message to indicate that it is now accepting incoming commands. The soft mode switch works by saving a callback function to z2m memory, and then fetch & execute the callback when the cube is ready to respond (when dataObject247 message arrives). Therefore, mode switch will also take effect within an hour, even you don't throw.

Now onto the throw. throw causes two things to happen:

1. genMultistateInput reports the throw action
2. aqaraOpple reports dataObject247, indicating it is now accepting commands

BTW, The two reports come in order as listed. Therefore, throw is a perfect candidate action to automate mode toggle. The callback is scheduled (in 1), then immediately gets executed (in 2).

Of course you are free to use throw for any other automations. When dataObject247 message comes in, the system won't do anything if there's no callback scheduled. So there's no conflicts with "internal" uses.

How did I figure the response frequency?

I had a NodeRED flow that sends me a mobile notification when the response message (dataObject247) is received. The notification came in roughly once an hour.

[JJPro]

@stephennutt

the number side up is not agreeing with what is printed on the cube. I can fix in Node Red so there is a workaround but I am concerned I am doing something stupid as a newbie that is easily corrected. Is anyone else experiencing this?

R u using this?

[SirGoodenough]

Note to all when you load the latest, be sure to purge the old MQTT entries for the device or some of the old attributes will hang around and confuse you.
Don't ask me how I know...

If you are looking for a blueprint for this cube for Home Assistant, here you go. Based on @JJPro 's extension.

https://github.com/SirGoodenough/HA_Blueprints/blob/master/Automations/Zigbee2MQTT-Aqara-Magic-Cube-T1-Pro-CTP-R01-Xiaomi-Lumi.md

[JJPro]

Update (Most likely the last one)

I got my second cube today, and from my experiments, removing the following from configure doesn't break pairing or affect anything.

await endpoint.write('aqaraOpple', { mode: 1 }, { ...manufacturerOptions.xiaomi, disableResponse: true }); // attr: 0x0009
await endpoint.write('aqaraOpple',
  {
    0x00ff: {
      value: [0x45, 0x65, 0x21, 0x20, 0x75, 0x38, 0x17, 0x69, 0x78,
        0x53, 0x89, 0x51, 0x13, 0x16, 0x49, 0x58],
      type: 0x41
    }
  }
  , { ...manufacturerOptions.xiaomi, disableResponse: true });

So I'm removing them. This resolves the two concerns I've had since the beginning of the project.

[SirGoodenough]

@JJPro I see HOLD in the action list, but have not seen it activate. Can you elaborate? Something in Scene mode?

[JJPro]

@SirGoodenough Exactly, in scene mode. when you pick it up and hold in hand.

[jzee923]

@JJPro I finally had some time to test out your latest code and I'm still seeing the issue I had before

Debug 2023-01-26 14:30:10No converter available for 'CTP-R01' with cluster 'genOnOff' and type 'commandOff' and data '{}'
Debug 2023-01-26 14:30:10Received Zigbee message from '0x54ef4410006a47c0', type 'commandOff', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 0
Debug 2023-01-26 14:30:10No converter available for 'CTP-R01' with cluster 'genOnOff' and type 'commandOff' and data '{}'
Debug 2023-01-26 14:30:10Received Zigbee message from '0x54ef4410006a47c0', type 'commandOff', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 0
Debug 2023-01-26 14:30:10No converter available for 'CTP-R01' with cluster 'genOnOff' and type 'commandOff' and data '{}'

I'm seeing these genOnOff with commandOff or commandOn which basically turns on or off every zigbee light I have on my network. I don't know why our cubes are behaving differently, but for me your previous commit WITH the config lines works.

If it helps, I use the sonoff zigbee 3.0 usb dongle.

[JJPro]

hmm... @amaisano had reported this issue a few days back, and had it solved by:

I force removed the cube and set it to ONLY join to the main coordinator (something I've had to do with many other Aqara Xiaomi devices).

I kept pressing the link button on the cube ...

And now it seems to be working without affecting the rest of my Zigbee devices.

I have a sniffer, and have listened to traffic for 30mins while playing with the cube, and interestingly there is no genOnOff cluster message ever caught. Searching through my logs, both cubes never emits genOnOff commands.

I'm with latest stable versions of HA and Z2m. (Docker) cube firmware version: 0.0.0_0025

@amaisano Can you help test using the latest code following these procedures to ensure cache is cleared:

1. replace with latest converter code
2. remove device from the network
3. restart z2m (restart z2m container if Docker, otherwise restart the machine running z2m)

[SirGoodenough]

@jzee923 Mine is set to legacy mode. I loaded the .js file into the zigbee2mqtt folder. Went into the Z2M UI and under settings, external converters I added the path, saved it, restarted it, and it is there and happy.

Now I have these showing up which may be related in the HA logs. Don't know, have to track more.

Logger: homeassistant.helpers.template
Source: helpers/template.py:589
First occurred: January 25, 2023 at 23:29:48 (21 occurrences)
Last logged: January 25, 2023 at 23:30:49

Template variable error: 'value_json' is undefined when rendering '{{ value_json.power_outage_count }}'
Template variable error: 'value_json' is undefined when rendering '{{ value_json.side }}'
Template variable error: 'value_json' is undefined when rendering '{{ value_json.action }}'
Template variable error: 'value_json' is undefined when rendering '{{ value_json.action_from_side }}'
Template variable error: 'value_json' is undefined when rendering '{{ value_json.action_angle }}'

-------------->

Logger: homeassistant.helpers.template
Source: helpers/template.py:592
First occurred: January 25, 2023 at 23:29:48 (6 occurrences)
Last logged: January 25, 2023 at 23:30:49

Error parsing value: 'value_json' is undefined (value: , template: {{ value_json['update']['installed_version'] }})
Error parsing value: 'value_json' is undefined (value: , template: {{ value_json['update']['latest_version'] }})

------->

Logger: homeassistant.components.mqtt.mixins
Source: components/mqtt/mixins.py:436
Integration: MQTT (documentation, issues)
First occurred: January 25, 2023 at 23:29:48 (27 occurrences)
Last logged: January 25, 2023 at 23:30:49

Erroneous JSON:

[jzee923]

hmm... @amaisano had reported this issue a few days back, and had it solved by:

I force removed the cube and set it to ONLY join to the main coordinator (something I've had to do with many other Aqara Xiaomi devices). I kept pressing the link button on the cube ... And now it seems to be working without affecting the rest of my Zigbee devices.

I have a sniffer, and have listened to traffic for 30mins while playing with the cube, and interestingly there is no genOnOff cluster message ever caught. Searching through my logs, both cubes never emits genOnOff commands.

I'm with latest stable versions of HA and Z2m. (Docker) cube firmware version: 0.0.0_0025

@amaisano Can you help test using the latest code following these procedures to ensure cache is cleared:

1. replace with latest converter code
2. remove device from the network
3. restart z2m (restart z2m container if Docker, otherwise restart the machine running z2m)

@JJPro nope, that doesn't work. The only thing that works is putting those 2 configurations back in. A flip generates a genOnOff commandOn A rotate generates a genOnOff commandOff

[JJPro]

@jzee923 can you test which one of the 2 is making it work? or require both? thx

[jzee923]

Needs both

[JJPro]

great! I'll keep them then. thx

[jzee923]

@JJPro sorry, i tried again and it looks like I only need the first config

await endpoint.write('aqaraOpple', { mode: 1 }, { ...manufacturerOptions.xiaomi, disableResponse: true }); // attr: 0x0009

It definitely doesn't work without it.

[amaisano]

@JJPro and @jzee923 I am using the following commit/version with no genOffOn troubles:

https://github.com/JJPro/CTP-R01-converter/commit/69569f1e13a1e8754b70295e67c6e4c81377fb9c (this version HAS the attr: 0x0009 line in it)

At first, I experienced the same trouble that @jzee923 had and was very scared, haha.

Then, I did a force-remove from zigbee, chose "Permit Join: Coordinator" (no other devices), and held the link button for 5 seconds and let go. I didnt' TOUCH the cube while it was pairing and it has been working fine since. Note, I was standing very close to my coordinator when i paired it this way.

The first time i paired it, I was playing with it while it was being interviewed by Z2M (throwing, turning, pressing the link button), which I think caused the issues.

[jzee923]

@amaisano yes that commit includes the configuration that is required (for me) to get the cube running properly. @JJPro removed it since he never experienced the same issue with the genOnOff cluster, but will be adding it back in since it wasn't working for me without the config.