🧯 Zigbee2MQTT - Xiaomi Cube Controller

There’s another patch out today with another fix for it.
My HA has been in limbo fo 24hrs now due to ssl problems, I have not been able to test anything. But I assure you, if you copy the blueprint from the repo and paste it into a file manually, it will work. This is a HA problem causing everyone with selectors and some other items that have enum’s to not import… At least that’s that the release notes said today.

New Version today.
I did this a couple of days ago but released it today because of the problems with 2033.5.0 and 2022.5.1 releases not allowing Blueprint Imports.

Please Click the :orange_heart: at the end of the Top Post if you find this Useful

  • 2022-05-05: Updated for 2022.5.0 HA. Added Markdown to !input Descriptions plus shortcut or.
1 Like

Not getting any responses from the automation…
I get this error in debug:

Error: UndefinedError: 'dict object' has no attribute 'to_state'

Step ConfigChanged VariablesRelated logbook entries

any idea?

1 Like

I think my z2m is not sending the expected data, I managed to change the template condition to something where the result is true, here is what I have :

  condition: template
  value_template: '{{ trigger.from_state.state in (''rotate_right'', ''rotate_left'',
    ''flip90'', ''flip180'', ''slide'', ''tap'', ''shake'', ''fall'') }}'

But then nothing happens because the “action” variable is set to ‘’.

what is your payload? wonder if thats my issue too.

Here’s what mine looks like when shaken:

    "action": "shake",
    "action_angle": null,
    "action_from_side": null,
    "action_side": null,
    "action_to_side": null,
    "battery": 99,
    "current": 0,
    "linkquality": 145,
    "power": 123,
    "side": 0,
    "temperature": 25,
    "voltage": 2975

Just need to verify you are in legacy mode and the action sensor exists and that action sensor is what you have listed as input 1 named “remote” in the blueprint builder… That is the most common problem. Details above in the posts from others. 🧯 Zigbee2MQTT - Xiaomi Cube Controller - #7 by Sir_Goodenough

That said, trigger.to_state.attributes.action is generated from the data received when the trigger happens, that is set to when the cube action sensor changes and the data populated in the state that the action sensor changed to. It will only triggers the blueprint cube actions when it contains one of the valid responses, (in (''rotate_right'', ''rotate_left'', ''flip90'', ''flip180'', ''slide'', ''tap'', ''shake'', ''fall'') ) because the thing tends to trigger 5 bad times for every time it has valid data. It you look in the traces you will see this happen. The blueprint will trigger multiple time and drop out at the check for valid in the conditions, however the valid ones will cascade thru the rest of the blueprint and start actions.

If it’s not getting a valid trigger at the action sensor, you likely are not looking at the right action sensor. It is possible there is a new firmware out there that is messing with this, but your data example contains ‘shake’ which should be valid.

Now if you are expecting to see the value when you drop the sensor in a dashboard, you aren’t going to see it, because like I said, it multi-triggers. The Blueprint will look for a valid result and act on it. If you want to ‘see’ the value that was acted on, you need to read the documentation and build the template sensor and drop that in a dashboard. (🧯 Zigbee2MQTT - Xiaomi Cube Controller) That will latch the valid last result for ‘training’. Believe me, this cube thing has a learning curve how hard to bang it for taps and flips, etc…

Once you dial it in, it’s awesome!

Thanks for the reply.

I have the legacy APIs enacted. I think i have the right action sensor also:

The Trace log shows this:

This was a slide on side 0 automation.

    "action": "slide",
    "action_angle": null,
    "action_from_side": null,
    "action_side": null,
    "action_to_side": null,
    "battery": 99,
    "current": 0,
    "linkquality": 69,
    "power": 242,
    "side": 0,
    "temperature": 22,
    "voltage": 2975

Look at prior traces in the list. Yes, there are false fires, as I mentioned above, where the condition statement screens out non-valid triggers from the cube.
The trace in your picture above is a non-valid trigger.
You need to click the little white arrows to see the successful actions from prior cube communications:

Good run: (This was found 2 or 3 traces back from the most recent trigger of the cube.)

Either way, valid triggers will preform the actions matching the stack logic and triggers where the action doesn’t match anything will drop out at the condition, as in your picture, and you never know or care that they happened.

It seems to work now, on top of the legacy API stuff that was already enabled, I had to enable the following option in z2m. After a z2m restart it works.

Not sure if this will cause issues for other devices.

Apparently mine had defaulted to that setting. I don’t remember changing it.
I captured your input here and added it to the instructions in the top post.

I wanted to run a separate Zigbee/Zwave server off of an SSD-bootable raspberry Pi 4 so I ended up doing a fresh install of zigbee2MQTT and re-pairing all my sensors. (I’m planning a z-wave 7 upgrade also).

This is now working as a result and Man… what a fun project. Thanks for taking the time to build this blueprint and support questions. Any links to places that make stickers for it?

1 Like

I have a vinyl cutter similar to a cricket. That’s all I used.

Ya, I started with what someone else had and just kept coming up with variations.

It’s WAY more complicated that anyone can use now, BUT that means there are multiple ways so you can find one that works well for you.

Plus I added the simple mode that don’t care about sides for getting used to the thing.

Lots of fun for sure!

Updated the ‘other blueprints’ links.

25 may 2022 Added Troubleshooting Tip.

im new and now finished flashing and passing my sonoff zigbee 3 stick through to haos.
now i wonder if i can use the dimmer script to control my volume via a tasmota ir blaster?

with kind regards

Hardware is quite different, but if the IR Blaster can give you an angle value in degrees, then I’m sure you could adapt it.

the IR Blaster is this: auvisio S06 IR Controller Configuration for Tasmota

so i guess it doesn’t give anything back. The Cubes ration should send IR Volume Down or IR Volume UP to my Stereo :smiley:

Solution: it seems like you have to create Scripts for the IR remote and call them with this blueprint

Hi there. I just got this setup, thank you for this extremely detailed blueprint!

I’m seeing about 1 second delay between interacting with the cube, and having Zigbee2MQTT show anything in its logs. Is this latency expected? Thanks.

I understand now.
Get the ir blaster working in an automation first. Then use that ‘action’ to plug into this blueprint. Anything that works in an automation will work as your action, but you have to have something that functions. If you are testing an unknown with something as complicated as this blueprint it will be hard to tell what is the problem.

There is a delay between actions. It is there on purpose to prevent a light from flashing, IE getting the same command 2x and it just flashes instead of staying on.
At the very end of the blueprint is a 1 second delay. You can turn that off or change it there if you like, but it worked best for me with that delay in there.

1 Like

yep the available actions work.
i tested with double tap and turn CW / CCW to send IR commands.

but i noticed that when i turn the cube for example 90° cw it only sends the IR command once.
so i have to turn the cube cw like 40+ times to get my volume up a little :frowning:

so it would be nice is it was possible to set the cube to send 1 action for every X° of turn cw

Edit… Oops, replied to the wrong post… Sorry Rubin110. Meant for @DS_DV DS_DV

Instead of scripting to trigger every 10% there are 2 things you can adjust in this blueprint.
The easier one is use this method and set your action on the ‘short press’ to be 10% and the ‘Long Press’ to be 20%.

The other would be to adjust the sensitivity using by changing this 0.4 to a different value until it is something that fits your needs better.

        brightness_pct: >
          {% set step_size = angle * 0.4 %}

What this does as currently set, if you move the angel 100 degrees, this reads that as 40 degrees or 40% of the actual.

One of these methods should work better for you than triggering every 10%.

1 Like