The Xiaomi Mi Wireless Switch, model WXKG01LM, hasn’t been in production for years and it still shows up constantly on secondhand marketplaces for a few dollars a unit. It’s the plain round button, not the square Aqara-branded WXKG11LM that replaced it. I get asked fairly often whether it’s still worth bothering with, and whether it needs the Mi Home app to work. Short answer: no Mi Home, no cloud, no hub. Zigbee2MQTT talks to it directly once it’s paired to your coordinator — the same no-vendor-hub approach we use across these devices.
This is a walkthrough of pairing, the action set you’ll build automations against, a legacy quirk you’ll want to fix on sight, and the mesh placement rule that trips people up because this device has zero tolerance for being the weak link in your Zigbee network.
What the WXKG01LM Is, and Why It’s Still Worth Using
It’s a battery-powered, single-button Zigbee remote. Round housing, CR2032 coin cell inside, no display, no light beyond a status LED during pairing and low-battery events. Once joined to Zigbee2MQTT it exposes four entities: battery percentage, voltage in millivolts, a power_outage_count counter, and the action sensor that actually matters for automations.
Voltage is more useful than it sounds. Z2M derives the battery percentage from it, and if you track voltage over a few months in Home Assistant’s history graph, you get a real read on discharge curve rather than a percentage number that can lag or jump. power_outage_count increments on events like a dead or pulled battery, which is a decent early-warning signal if a button suddenly stops responding and you’re not sure whether it’s dead or just out of range.
Pairing with Zigbee2MQTT
Put Z2M into permit-join mode from the frontend or dashboard, then pair the switch one of two ways:
- Hold the reset button on the back for roughly 5 seconds until the LED starts blinking blue, or
- Tap the button quickly several times in a row until the LED double-flashes
Either method puts it into join mode and it should appear in Z2M’s device list within a few seconds. I’ve had both methods work fine on the same unit at different times, so if the hold method feels finicky, the rapid-tap approach is a legitimate fallback rather than a workaround.
The Action Set: What You Can Automate Against
The action entity is what fires your automations. Values you’ll see: single, double, triple, quadruple, hold, release, and many (any burst over four presses arrives as many). Each press pattern publishes its action value momentarily, then the entity resets to empty, so your Home Assistant trigger should fire on the state changing to a specific action value, not on the action entity having a persistent state.
hold and release are a pair worth understanding before you build anything around them. The WXKG01LM only reports a raw button press and a release; Z2M turns that into a hold when enough time passes between the two. Two Z2M device options control that behavior: hold_timeout sets how long a press has to last before it counts as a hold rather than a single press (default around 1000 ms), and hold_timeout_expire sets how long Z2M waits before auto-sending a release if the button never sent one itself — some units occasionally drop the release event, and this stops a stuck “held” state (default around 4000 ms). If your “hold to dim” automation feels laggy or fires a stray release a beat late, those two settings are where to look before you start rewriting the automation itself.
Fixing the Deprecated click Event (legacy: false)
Out of the box, older Z2M configs may still publish a legacy click topic alongside the modern action events. This is deprecated behavior carried forward for backward compatibility, and it clutters your MQTT topic tree with duplicate signals for the same physical press. Setting legacy: false in the device’s Z2M options switches it over to clean action-based events only.
Worth knowing: if you copied an automation blueprint from a community thread written a few years ago, there’s a real chance it was written against the legacy click topic. If your button pairs fine but nothing fires, checking whether legacy: false is set (or unset) on that device is a five-minute check before you start suspecting a bad unit.
Mesh Placement: End Device Only, No Routing
This is the rule most likely to bite you if you’re coming from Wi-Fi thinking. The WXKG01LM is a Zigbee end device, full stop. It cannot act as a router and doesn’t support binding to other devices directly. It needs to sit within solid range of your coordinator or a genuine Zigbee router device, and a chunk of otherwise-Zigbee-compatible hardware won’t do that job for it. Z2M’s own documentation calls out known-incompatible router brands: Centralite, GE, Iris, Ledvance, Legrand, OSRAM, Sylvania, SmartThings, and Securifi.
When I saw a Z2M GitHub discussion about a WXKG01LM dropping off the network after a Zigbee2MQTT update, my first assumption was a firmware regression baked into the release. Reading through the thread, that wasn’t it. The pattern people traced it back to was signal and mesh topology, not the update itself. The switch was sitting at the edge of range through a router that either didn’t handle it well or wasn’t routing at all, and the update just happened to coincide with something on the network shifting. If your button starts dropping after an update, checking mesh health and router placement before filing a bug report will save you time.
Building Automations: Blueprint vs Manual YAML
Community blueprint threads for this exact device exist, and they’re a reasonable starting point if you want a working automation in five minutes. The tradeoff is that blueprint quality varies a lot between threads, and a few of the older ones were written against the legacy click topic mentioned above, so double check legacy: false compatibility before importing one blind.
Writing the automation manually isn’t much more work once you understand the action values. A trigger on the action sensor’s state changing to single, double, or hold gives you three, sometimes five, distinct actions off one physical button — enough for a real light-control scheme without needing a second switch.
WXKG01LM vs Aqara WXKG11LM: Which to Buy if Starting Fresh
The Aqara-branded WXKG11LM is a different SKU in a different housing — the flatter square button — and it’s the device Aqara still sells new where the WXKG01LM has been out of production for years. The practical difference in Zigbee2MQTT is less about the action set than about how each device produces it. Both cover single, double, hold, and release, and both report multi-click patterns; but because the WXKG01LM reports only a raw press and release, Z2M derives its hold by timing the gap between them — which is exactly why the hold_timeout options above exist for it. The WXKG11LM reports its actions more directly, so its hold behavior doesn’t depend on a timing threshold you tune yourself. That’s the one concrete edge the newer unit has. For a full walkthrough of the newer button, see our Aqara Wireless Mini Switch guide.
I think this is a case where buying secondhand is the right call rather than a compromise. If you find WXKG01LM units for a couple dollars each, the action set already covers single, double, triple, quadruple, hold, and release, which is more granularity than most people actually use in a real automation. Unless you specifically need the newer unit’s more direct hold reporting, paying more for new-production hardware to do the same job doesn’t make sense to me.
Troubleshooting Disconnects
Most disconnect reports trace back to one of two things covered above: mesh placement through an incompatible or absent router, or a legacy-topic mismatch confusing an automation into looking broken when the device itself is fine. Before assuming a dead unit, check battery voltage in the entity history, confirm a compatible router sits between the switch and your coordinator, and verify legacy: false is set if you’re using a newer automation built against action events.
FAQ
Does the Xiaomi WXKG01LM work with Home Assistant without the Mi Home app?
Yes. Once paired to Zigbee2MQTT it’s controlled entirely through Z2M and Home Assistant. Mi Home is never involved.
What’s the difference between the Xiaomi WXKG01LM and the Aqara WXKG11LM?
Different SKU, different housing, and the WXKG11LM is Aqara’s actively sold successor rather than a discontinued Xiaomi-branded unit. The main functional difference in Zigbee2MQTT: the WXKG01LM reports only a raw press and release, so Z2M computes hold from the timing between them, while the WXKG11LM reports its actions more directly. The action set you can automate against is otherwise broadly the same.
Why does my WXKG01LM keep disconnecting from Zigbee2MQTT?
Usually mesh and router compatibility, not a faulty unit. Check that a genuine Zigbee router (not one of the known-incompatible brands) sits within range, and pair closer to the coordinator if you’re at the edge of your network.
How do I fix the deprecated “click” event in newer Zigbee2MQTT versions?
Set legacy: false in the device’s options in the Z2M frontend. This switches the device fully over to the modern action event set and stops the duplicate legacy topic from publishing.
Can I use ZHA instead of Zigbee2MQTT with this switch?
Yes — the WXKG01LM (Zigbee ID lumi.sensor_switch) is supported in ZHA through the zha-device-handlers quirks, and it fires its button presses as zha_event actions (single, double, hold). The catch is that ZHA’s event names and payloads differ from Z2M’s action values, so a Z2M blueprint won’t drop straight into a ZHA setup and vice versa. This guide covers the Zigbee2MQTT path specifically, since that’s where the device’s behavior is best documented. If you’re weighing the two stacks, our ZHA vs Zigbee2MQTT comparison goes deeper.
The many action value is documented but I haven’t found a common automation pattern built around it yet. If Z2M’s device page gets more detail on when it fires versus quadruple, that’s worth revisiting here.