On/off control works fine. Zigbee2MQTT or ZHA sees the plug, Home Assistant flips it instantly, and nothing about pairing or connectivity looks wrong. It’s the power numbers that break. Watts stuck at 0, energy and voltage reporting N/A, or a reading that updates so rarely it’s useless for anything but the crudest automation.
Across the Aqara/Xiaomi plug family there are two separately documented reporting faults hiding under that one symptom, plus a widely-misread firmware bug that sends people chasing the wrong fix entirely. The GitHub issues describing them rarely cross-reference each other, so this piece pulls them together. Knowing which one you have determines whether there’s anything to fix at all.
Everything below happens on-device or in Zigbee2MQTT/ZHA logs. Nothing here requires the Aqara or Mi Home app, and diagnosing it doesn’t touch the cloud.
This is a troubleshooting reference across the plug family, not a setup guide for one model. If you haven’t paired your plug yet, use your model’s own guide first, linked further down, then come back here if power monitoring specifically is the problem.
The mechanism behind most of it
Both documented faults trace to the same place, and it isn’t Zigbee2MQTT. Zigbee devices are supposed to accept a reporting configuration: a rule telling the device to push an attribute when it changes by more than some delta, or after some maximum interval. On these plugs, the firmware frequently refuses that configuration.
Zigbee2MQTT issue #22269 documents it precisely on the SP-EUC01. Attempts to configure reporting for power, voltage and current fail; Zigbee2MQTT logs a SOFTWARE_FAILURE status, and reading the same configuration back from deCONZ returns an UNREPORTABLE_ATTRIBUTE error. On the firmware build in that report, only the seMetering cluster’s currentSummDelivered attribute (the cumulative energy total) accepted a reporting config at all. The issue was closed as not planned, which is the maintainers saying this is device behaviour rather than something Zigbee2MQTT can patch.
The consequence is worth internalising: the plug still knows its own power draw, and manual reads work fine. What’s broken is the device volunteering that value on a schedule you chose.
Failed to configure 'kitchen_plug', attempt 1 Error: ZCL command failed (Status 'SOFTWARE_FAILURE') Read attribute 'haElectricalMeasurement' failed Error: ZCL command failed (Status 'UNREPORTABLE_ATTRIBUTE')
If you see either line against a plug whose switch works, you’re in the territory this article covers.
Pattern 1: updates that only fire on a big load change
The most commonly reported symptom on the EU-format plugs (SP-EUC01 and related hardware) isn’t a total failure. It’s lag. Zigbee2MQTT issue #19039, titled “Aqara/Xiaomi EU smart plug – slow and inaccurate power report”, describes the value updating only when consumption changes by roughly 5 to 10 watts or more. The reporter contrasts it with a Shelly plug that publishes a new value on a 0.5W change. A phone charger drawing 8W might never register; switching on a kettle shows up immediately.
That’s the reporting-configuration refusal above, seen from the reader’s side. The plug falls back to sending a value when it decides to, which per #22269 can mean hours between updates.
The practical damage is to automations built on transitions. If yours watches for a washing machine finishing by its draw dropping to near zero, the plug will often miss that moment entirely, not because the automation is wrong but because the plug never reported the change. No Zigbee2MQTT setting tunes around it.
Pattern 2: every power attribute goes N/A at once
A more severe version shows up on the Aqara Smart Wall Outlet T1. Zigbee2MQTT issue #16608, opened in February 2023, reports power, energy, device_temperature, voltage and current all showing N/A simultaneously, alongside a led_disabled_night setting that doesn’t take effect either.
The multi-attribute pattern is the tell that separates this from Pattern 1. If watts alone sits at 0 while voltage still updates, that’s the lag pattern or a genuinely idle load. If everything goes N/A together, you’re looking at this.
One detail from that thread is worth acting on: the reporter could still retrieve uncalibrated power readings through the Zigbee2MQTT developer console, even with every entity showing N/A. Same shape as Pattern 1, a reporting failure rather than a dead meter, which makes the developer console the fastest way to confirm which side of the problem you’re on.
The led_disabled_night failure alongside it is a corroborating signal rather than a coincidence: the same class of non-implemented attribute is documented on the ZNCZ12LM, where auto_off, led_disabled_night and overload_protection all return UNSUPPORTED_ATTRIBUTE.
The firmware trap: v42 is a toggle bug, not a metering bug
Search for SP-EUC01 firmware problems and you’ll land on Zigbee2MQTT issue #13903 almost immediately. It’s a real bug, but not this one. Its title is “Xiaomi Aqara Plug (SP-EUC01/lumi.plug.maeu01) Toggles without reason”: on firmware v42 the plug misreads Zigbee routing traffic passing through it as a toggle command and switches its own relay at random, with documented triggers involving IKEA buttons on the same mesh. Our SP-EUC01 setup guide covers it in full.
This matters here because the documented workaround for v42 is a firmware downgrade to v32 using a modified file that reports itself as a higher version to defeat the plug’s downgrade protection. That’s a reasonable trade for a plug randomly powering your appliances on and off. It is not a fix for a stale wattage reading, and nothing in the sources ties v42 to metering behaviour at all.
Do not downgrade firmware to fix power monitoring. The v32 downgrade addresses the spontaneous-toggle bug, not reporting. It requires a modified firmware file that bypasses the device’s own version check, carries the usual risk of any circumvented downgrade path, and there is no documented case of it restoring power reporting. If your plug’s relay isn’t toggling by itself, this workaround has nothing to offer you.
Which models this affects
| Model | What it is | Documented power-monitoring status |
|---|---|---|
| SP-EUC01 | Aqara EU (Schuko) plug | Reporting configuration rejected at firmware level; values update sporadically, manual reads work (#19039, #22269) |
| Smart Wall Outlet T1 | Aqara wall outlet | power, energy, device_temperature, voltage, current all N/A together; still readable via developer console (#16608) |
| ZNCZ12LM | Aqara CN-market wall-socket plug | Power monitoring works. Its documented bug (#20430) is auto_off / led_disabled_night / overload_protection, not metering |
| ZNCZ11LM | Earlier Xiaomi/Aqara plug | No power-monitoring report found in this pass. Absence of a filed issue is not a clean bill of health |
This site has separate setup guides for several of these models: the SP-EUC01, ZNCZ12LM, T1 CN plug (ZNCZ15LM), and Xiaomi’s ZNCZ04LM and ZNCZ02LM. If you’re unsure which generation you own, checking against its own guide is the fastest way to rule out a pairing or entity-naming issue first.
Is this Zigbee2MQTT/HA, or the plug itself?
Independent of Zigbee2MQTT, deCONZ users report the same category of problem on Aqara plugs: the power monitor either never initialises or reports nothing. Issue #22269’s reporter confirmed the UNREPORTABLE_ATTRIBUTE response through deCONZ, not Zigbee2MQTT.
So these failures are device- and firmware-side, and switching from Zigbee2MQTT to ZHA or back is very unlikely to fix either pattern. Both stacks read the same attributes off the same hardware, and both get the same refusal.
When the number is wrong, not missing
A different complaint is a reading that’s present but off by a round factor, ten times too high or too low. That turns up across smart-plug brands generally, but we found no report of it filed against a specific Aqara or Xiaomi model. If you’re seeing it on one, treat it as its own problem: the faults here produce stale or absent values, not mis-scaled ones.
What to check, in order
- Confirm which fault you have. Slow-but-moving is Pattern 1; everything N/A at once is Pattern 2.
- Check the Zigbee2MQTT log for
SOFTWARE_FAILUREon configure orUNREPORTABLE_ATTRIBUTEon read. Either confirms the firmware is refusing reporting configuration. - Try reading the attribute manually in the developer console. If a value comes back while the entity shows N/A, the meter is fine and only reporting is broken.
- Check whether other attributes on the same device are updating normally. If everything is dead at once, that’s Pattern 2.
- Don’t switch stacks and don’t downgrade firmware. Zigbee2MQTT and ZHA read the same clusters, and the v42 downgrade addresses the toggle bug, not metering.
Honestly, the most fixable thing here isn’t the firmware. It’s that Zigbee2MQTT presents entities the device has already refused to report: the plug says UNREPORTABLE_ATTRIBUTE at configure time, and the entity appears in Home Assistant anyway, indistinguishable from a working one until you notice it never moves.
FAQ
Why does my Aqara smart plug show 0W in Home Assistant?
Most commonly the firmware has refused Zigbee2MQTT’s reporting configuration, so the plug only volunteers a value on large load changes or at intervals of its own choosing. A small load then looks identical to no load. If energy, voltage and current are also N/A, that’s the more severe variant seen on the Smart Wall Outlet T1.
Why is my Aqara/Xiaomi plug’s power reading so slow to update?
This is the documented lag pattern, most reported on the SP-EUC01. Per issue #19039 the device tends to send an update only once load changes by roughly 5 to 10 watts, and per #22269 the gap between spontaneous updates can stretch to hours.
Does Zigbee2MQTT support power monitoring on Aqara smart plugs?
Yes. Zigbee2MQTT exposes the power-monitoring attributes these plugs implement. Whether the device reports those attributes on a useful schedule is a separate question, and the faults in this piece are device-side rather than a Zigbee2MQTT limitation.
Why did my Aqara plug’s power monitoring stop working after a firmware update?
Check what you’re actually looking at first. The famous SP-EUC01 firmware v42 bug (issue #13903) makes the plug toggle its relay by itself. It is not a metering bug, and the v32 downgrade circulated for it will not restore power reporting. Issue #22269 does tie reporting behaviour to a specific firmware build, so a genuine regression is possible, but check your symptom against the two patterns above before assuming the v42 story applies.
Is Aqara smart plug power monitoring accurate?
Issue #19039 is titled “slow and inaccurate power report”, and both words are fair. The inaccuracy is mostly a consequence of the staleness: when updates arrive sporadically, the displayed figure can be hours behind reality even though the measurement was fine when taken.
What this piece verified
This is a research-synthesis piece built from Zigbee2MQTT GitHub issues and community forum reports, not from hands-on testing of any of these plugs. Issue titles and states were checked directly: #19039 (slow and inaccurate reporting), #16608 (all attributes N/A on the Smart Wall Outlet T1), #22269 (reporting configuration refused, closed as not planned) and #13903 (spontaneous toggling on firmware v42).
That last check changed this article. The v42 bug is routinely described elsewhere as a power-monitoring failure, and it isn’t one: the issue and our own earlier coverage both document it as a relay-toggle problem, so we removed a firmware-downgrade recommendation on that basis.
The ZNCZ11LM row is marked “no report found” rather than implying it’s unaffected, because absence of a filed issue isn’t confirmation of clean behaviour. The deCONZ cross-check is circumstantial rather than a controlled comparison. Aqara has published nothing acknowledging either reporting fault, so the current state of knowledge on both is community-documented only.