The ZNCZ02LM has been sitting in a drawer in a lot of homes. I know because I had one in mine. It’s the original Xiaomi Mi Smart Plug ZigBee, that chunky square CN-market plug sold widely across Southeast Asia and China from around 2016 to 2020. A lot of people assumed it only worked through the Mi Home app and the Xiaomi Gateway hub, so when they moved away from that ecosystem they just stopped using it.
That assumption is wrong. The ZNCZ02LM pairs directly with Zigbee2MQTT and integrates with Home Assistant without touching Mi Home at all. This guide covers the pairing sequence, what entities you actually get, the one frustrating batch-specific quirk around voltage reporting, and why that plug can pull double duty as a Zigbee mesh extender.
What you need before starting
This guide assumes you already have a Zigbee coordinator (any CC2652-based stick or equivalent) running Zigbee2MQTT, with the Z2M frontend accessible. No Xiaomi Gateway hub is required. No Mi Home account. No cloud involved on either end.
If you’re still working out the coordinator setup, the Aqara Zigbee devices without a hub guide covers that groundwork. If you’re migrating from Mi Home and wondering what you’re leaving behind in terms of data collection, the Xiaomi Home integration privacy explainer is worth reading first.
Pairing the ZNCZ02LM with Zigbee2MQTT
This is where most people get tripped up, and honestly it’s where I did too on first attempt.
Open the Z2M frontend and enable permit join. Then hold the button on the plug for approximately ten seconds. You’re waiting for the blue LED to start blinking, and then stop blinking. The key thing is you need to wait for it to stop before you release. Most Aqara sensors require a much shorter press. The ZNCZ02LM is longer than you’d expect, and releasing at the blink-start rather than blink-stop leaves you with nothing in the Z2M device list and no idea why.
What I didn’t expect was how definitive the stop is. When it stops, it stops completely. There’s no gradual slow-down. Hold, blink starts, blink stops, release. If the plug doesn’t appear in Z2M within about 20 seconds of release, try again. I’ve occasionally needed two attempts if permit join was enabled too early and timed out.
Once paired, the device will appear as lumi.plug or a variant of that in the Z2M device list. Rename it in the Z2M frontend to something meaningful before it propagates to Home Assistant. Renaming is easier at the Z2M layer than in HA.
Entities and what they actually report
The ZNCZ02LM exposes five entities via Zigbee2MQTT:
| Entity | Type | Notes |
|---|---|---|
| switch | on/off | Primary control entity |
| power | W | Real-time draw in watts |
| energy | kWh | Cumulative consumption counter |
| device_temperature | °C | Internal plug temperature |
| power_outage_memory | boolean | Whether to restore last state on reconnect |
As of the current Z2M device definition, these are reliable on all production batches, with one exception, covered in the next section.
The energy (kWh) counter is cumulative. It does not reset on its own when you restart Z2M or Home Assistant. If you want a running daily or monthly total, you do that in HA’s Energy dashboard rather than by resetting the device counter.
For the Energy dashboard: add the plug’s energy entity as an individual device under “Electricity grid” > “Individual devices.” HA will handle the daily/monthly calculations from there.
Power monitoring: what works and what doesn’t
Power (W) and energy (kWh) reporting work reliably across all batches of the ZNCZ02LM. Voltage does not.
Specifically, voltage reporting is only confirmed working on production batches with a firmware dateCode of 02-28-2017. Later production batches do not report voltage. Because Xiaomi does not publish firmware files for this device, there’s no way to flash an older or newer image to change that behaviour. So if you bought this plug in 2018 or later, you likely won’t see voltage in your Z2M entity list. That’s not a pairing failure or a Z2M misconfiguration. It’s a batch limitation.
The Zigbee2MQTT device page documents this explicitly, but it’s easy to miss if you’re comparing the ZNCZ02LM entity list to what you’d expect from a more recent plug. I’ve seen multiple forum threads from people spending significant time debugging a “missing” voltage entity that simply doesn’t exist on their hardware batch.
Worth knowing: if full voltage and current reporting matters for your use case, such as monitoring an appliance or building an accurate power audit, you’re better served by the ZNCZ04LM, which exposes both reliably. More on that in the comparison section below.
Precision settings are available for both power and energy readings. In the Z2M frontend, under the device’s settings tab, you can set decimal precision from 0 to 3 places for each. The default is usually fine for dashboards, but if you’re logging to InfluxDB and want cleaner numbers, trimming to 1 decimal place makes sense.
Power outage memory: enabling it properly
The power_outage_memory entity controls whether the plug restores its last on/off state after a power cut. Useful for a fan or lamp you want to come back on. Less useful for something heat-generating that you’d rather stay off until you explicitly turn it on again.
Enabling the setting via Z2M or MQTT isn’t enough on its own. After you toggle it on, you need to press the physical button on the plug once. That physical press is what activates the new memory behaviour on the firmware side. If you enable it remotely and never touch the plug, the setting doesn’t take effect.
Timed shutoff is also supported. Sending {"on_time": N, "state": "ON"} to the plug’s MQTT topic turns it on for N seconds and then cuts power. Handy for automations where you want a guaranteed off rather than relying on a second automation trigger.
The ZNCZ02LM as a Zigbee mesh router
Because the plug is mains-powered, it runs as a Zigbee router rather than an end device. That means it actively relays messages between other devices and the coordinator. It extends your mesh, not just occupies a spot in it.
This matters if you have battery-powered sensors in rooms that are at the edge of your coordinator’s range. A plug placed roughly midway between the coordinator and a problem sensor can bring it reliably into mesh coverage. I’ve used a ZNCZ02LM in exactly this role in a back room where a motion sensor was dropping messages, and the plug’s consistent mains power makes it a more reliable router than a battery device could ever be.
A note on firmware: Zigbee2MQTT lists OTA support for the ZNCZ02LM, but Xiaomi does not publish firmware files for this plug, so there’s nothing to actually update to. Treat the firmware on whatever batch you own as fixed. That’s also why the voltage-reporting gap on later batches isn’t something a future update will fix.
ZNCZ02LM vs. ZNCZ04LM: which do you have?
If you’re unsure which model you’re working with, the physical difference is clear: the ZNCZ02LM has a square, chunky body; the ZNCZ04LM is noticeably flatter and slimmer. Both are CN-market Zigbee plugs with power monitoring, both work with Z2M, but they’re distinct devices.
Entity differences matter:
- ZNCZ02LM: switch, power (W), energy (kWh), device_temperature, power_outage_memory. Voltage only on early batches.
- ZNCZ04LM: switch, power (W), energy (kWh), current (A), voltage (V), power_outage_memory. Voltage and current reliable across batches.
The Xiaomi ZNCZ04LM setup guide covers the ZNCZ04LM in detail. If you have both models, use the ZNCZ04LM where full energy monitoring matters and the ZNCZ02LM for locations where its router role is the primary value.
For readers outside CN-market range, the Aqara SP-EUC01 is the EU-market equivalent and worth comparing before importing anything.
Network placement
If you’re running an IoT VLAN, which I’d recommend for any cloud-capable device, even ones you’re running locally, the ZNCZ02LM sits on that VLAN like any other Zigbee device. It communicates via your Zigbee coordinator, which sits on whatever host runs Z2M. The plug itself has no IP address and no direct internet access, so VLAN isolation here is about the coordinator host and your Z2M instance, not the plug directly.
The Aqara and Xiaomi IoT VLAN guide covers network segmentation in more detail if you’re building that out.
For readers new to the idea that any of this can work without cloud, the explainer on whether Aqara works without internet explains the offline model in plain terms.
Honestly, the ZNCZ02LM is the kind of device where I’d call the cloud-free operation less of a feature and more of just how Zigbee works. The plug has no concept of a Xiaomi server. The Mi Home dependency was always the hub, not the plug itself. Once you’re running Z2M, a lot of devices you assumed were cloud-dependent turn out to be straightforwardly local.
The voltage reporting gap is the one thing I’d flag before buying one new. If you already have it, the W and kWh monitoring is solid enough for most automation and energy-tracking purposes.