The original Aqara Magic Cube (MFKZQ01LM) has been around since well before the T1 Pro (CTP-R01) showed up with its mode-switchable faces and better gesture recognition. If you already have one, or found it cheap secondhand, it still pairs straight into Zigbee2MQTT with nothing else in the loop. No Aqara hub, no Mi Home account, no cloud dependency to strip out later.
I still keep one of these on a shelf next to my desk. It’s not as capable as the newer cube, but for the price it usually sells at now, it’s a genuinely useful six-sided remote for scenes and quick toggles once you know what to expect from it.
What the MFKZQ01LM actually is
It’s a small foam-covered cube with an accelerometer inside. Flip it, shake it, rotate it, tap it, or throw it (gently) and it reports the gesture over Zigbee. There’s no display, no buttons, no app pairing step of any kind. Our guide to the newer Magic Cube T1 Pro (CTP-R01) covers that model if you’re deciding between the two before buying.
The design difference that matters most for this article is that the MFKZQ01LM is a one-way reporter. It sends gesture data out over Zigbee and that’s the whole relationship. The T1 Pro can be put into different operating modes that change how it reports gestures, which means something can be written back to the device. Nothing can be written back to this one. Whatever Zigbee2MQTT exposes is read-only, full stop.
Pairing directly to Zigbee2MQTT
Pairing is the same procedure as any other battery Aqara Zigbee device. Put your Zigbee2MQTT instance into permit-join mode, then hold the small reset button on the cube (it’s under a cover on one face) until the LED flashes. It joins as a standard Zigbee end device and Z2M identifies it as MFKZQ01LM automatically, no manual quirk file needed. If you don’t have a Zigbee coordinator running yet, our guide to running Aqara devices without the Aqara hub walks through that first.
Once it’s joined, Home Assistant picks it up through the standard MQTT discovery Z2M publishes. You’ll get a device with several entities and one that matters more than the rest, which is the action sensor. That’s the one you’ll actually build automations against.
Full exposed entity and action reference
As of the current Z2M device page, the MFKZQ01LM exposes:
battery— percentagevoltage— battery voltage, millivoltsdevice_temperature— internal temperature readingpower_outage_count— increments on power loss events (relevant mostly for troubleshooting battery pull/reseat)action_angle— rotation angle in degrees, signed by rotation directionside— the face currently reported as upaction_from_side— which face it was on before the gestureaction_to_side— which face it landed on after the gestureaction_side— the face associated with the reported actionaction— the gesture itself, one of:shake,throw,wakeup,fall,tap,slide,flip180,flip90,rotate_left,rotate_right
That’s a decent set of triggers for a passive battery device. The catch is in how reliably each field populates, which is the next section.
The null-side quirk
Here’s where the friction actually is, and it’s worth knowing before you build anything that depends on side detection.
On rotate_left and rotate_right actions specifically, action_from_side, action_to_side, and action_side commonly come back null. This isn’t a misconfiguration on your end. It’s a long-standing behavior in the Z2M device driver, not something that got fixed in a later firmware or Z2M release. A related open issue also documents the cube occasionally dropping most of its reporting, or reporting the wrong side after a rotation that doesn’t register as a clean face change.
My first pass at automating this cube was to build a full 3D-style controller: each side mapped to a room, rotate to select, tap to toggle. That fell apart almost immediately because half my rotate-based automations just never fired. The action field was populating fine. action_side was coming back empty on exactly the gestures I needed it for.
The community consensus, and what I’ve settled on myself, is to build automations off the action value alone for anything that needs to be reliable. Treat side, action_from_side, and action_to_side as best-effort context you can log or display, not something to gate a trigger on. flip90, flip180, shake, tap, slide, throw, wakeup, and fall all report cleanly and consistently. rotate_left/rotate_right still fire reliably as actions, you just can’t reliably know which side it started or ended on when they do.
One more thing worth knowing: some users on ZHA report fuller action coverage on certain firmware and coordinator combinations where Zigbee2MQTT is inconsistent. That’s not a reason to switch integrations just for this one device, but if you’re troubleshooting a specific coordinator and seeing worse behavior than what’s described here, it’s a known variable. See our ZHA vs Zigbee2MQTT comparison for Aqara devices for the broader tradeoff.
Example automations that don’t rely on side data
These trigger off action only, which sidesteps the null-side problem entirely.
automation:
- alias: "Cube shake - toggle bedroom scene"
trigger:
- platform: state
entity_id: sensor.magic_cube_action
to: "shake"
action:
- service: scene.turn_on
target:
entity_id: scene.bedroom_evening
- alias: "Cube flip90 - next media track"
trigger:
- platform: state
entity_id: sensor.magic_cube_action
to: "flip90"
action:
- service: media_player.media_next_track
target:
entity_id: media_player.living_room_speaker
- alias: "Cube tap - mute toggle"
trigger:
- platform: state
entity_id: sensor.magic_cube_action
to: "tap"
action:
- service: media_player.volume_mute
target:
entity_id: media_player.living_room_speaker
data:
is_volume_muted: true
If you want to use rotation for something like volume adjustment, use action_angle rather than side. The angle value reports consistently even when the side fields don’t, and you can template a volume step off the sign and magnitude of the angle instead of which face it landed on.
MFKZQ01LM vs Cube T1 Pro
I think the older cube is still the right pick if you already own one, or if you’re building a low-stakes scene controller and don’t need mode switching. It’s cheaper, it pairs the same way, and once you stop relying on side detection for rotation, it does its job fine.
Where the T1 Pro earns its price premium is mode switching and generally more consistent gesture recognition across the full action set, including rotation with side data intact. If you’re buying new specifically to build side-aware automations, or you want the cube to behave differently depending on which room mode it’s in, the T1 Pro is worth the extra cost. If you just want shake-to-scene and tap-to-mute style triggers, the original does that without any compromise worth worrying about.
FAQ
Does the Aqara Magic Cube work without the Aqara hub?
Yes. It pairs directly to any Zigbee2MQTT coordinator using the standard reset-and-join procedure. No Aqara hub or Mi Home account is involved at any point.
Why does my Aqara cube show “null” for side or rotation values?
This happens specifically on rotate_left and rotate_right actions, where action_from_side, action_side, and action_to_side frequently come back null. It’s a known, long-open behavior in the Z2M device driver, not a pairing or config problem on your setup. Build automations off the action field instead.
What’s the difference between the original Aqara Cube (MFKZQ01LM) and the Cube T1 Pro?
The original is a one-way gesture reporter with no configurable modes and the rotate-side null quirk described above. The T1 Pro supports switchable modes and generally more consistent gesture and side reporting, at a higher price.
Can the Aqara Magic Cube control lights directly, or does it need Home Assistant?
It needs something to interpret the gestures. It’s not a standalone remote that pairs directly to a bulb. Zigbee2MQTT reports the raw action events, and Home Assistant (or another automation platform) is what turns “shake” or “flip90” into an actual light or scene change.
Does the cube need a battery replacement often?
Aqara doesn’t publish an official battery-life figure for the original cube, and real-world drain depends heavily on how often you trigger gestures. Rather than guess at an interval, use the exposed battery percentage and voltage entities to track drain over time and set a low-battery notification in Home Assistant.
Whether Aqara ever backports the T1 Pro’s mode-switching to this hardware over Zigbee is unlikely at this point, given how long the null-side issue has sat open without a driver fix. For now, building around action instead of side is the stable path, and it’s stable enough that I haven’t touched that part of my config in months.