OwlWhen Your Enphase Envoy's Production Readout Freezes at Zero
On 2026-07-31 my own Enphase Envoy's local production readout stopped moving. wattHoursToday read 0 and stayed at 0 for at least ten hours while the sun was up and the array kept producing. It wasn't a network hiccup and it wasn't the array. Three separate local aggregators on the Envoy had frozen mid-day, and the meter kept counting the whole time. This is what I measured, what I ruled out, and what's still open.
Short answer
My Envoy — metered, firmware D8.3.5433, part 800-00664-r05 — returned byte-identical numbers from /api/v1/production at 23:31 ET on 2026-07-31 and again at 09:06 ET the next morning, ten hours apart, with roughly 5 kWh produced in between. The endpoint that actually meters delivered power, /ivp/meters/readings, was fine the whole time and kept advancing normally. My own Enphase cloud (Enlighten) daily totals for the same days were also fine. The freeze was local, it hit more than one aggregator at once, and a full power cycle of the Envoy and my IQ Combiner didn't clear it.
What I actually measured
Two samples of /api/v1/production, ten hours apart:
2026-07-31 23:31 ET /api/v1/production wattHoursToday=0 wattsNow=111 wattHoursLifetime=18010122 2026-08-01 09:06 ET /api/v1/production wattHoursToday=0 wattsNow=111 wattHoursLifetime=18010122
Same wattHoursToday, same wattsNow, same wattHoursLifetime — down to the byte — across a ten-hour window that included roughly 5 kWh of measured production on my system. That's not a slow update. That's a stopped one.
At that same 09:06 ET moment, I pulled three more local endpoints on the same Envoy over the same authenticated local session:
/ivp/meters/readings eid=704643328 activePower=4961.5 W actEnergyDlvd=18083082.0 /ivp/pdm/energy eim wattHoursToday=0 wattsNow=111 /ivp/pdm/energy pcu wattHoursToday=2891 wattsNow=2386 /ivp/pdm/energy rgm wattHoursToday=0 wattsNow=0
The eim block matches what /api/v1/production serves — both frozen. rgm read zero the whole time on my system (a revenue-grade meter aggregate I don't have wired to report separately, so I can't say whether it was frozen or simply inactive). pcu was reporting a different, non-zero number — 2,891 Wh and 2,386 W — so at first glance it looked like the one aggregate still working.
It wasn't. I re-sampled pcu 21 minutes later and got the exact same 2891 / 2386 pair back, while /ivp/meters/readings had moved on. So on my Envoy, two separate local aggregates — eim (and the /api/v1/production view onto it) and pcu — were both stuck, just stuck at different values and probably at different times. Only the meter-readings endpoint was live.
The lifetime number tells the same story
The frozen /api/v1/production endpoint reported wattHoursLifetime=18010122. The meter's own lifetime counter, actEnergyDlvd, read 18083082 at the same moment — about 73 kWh higher. That gap is consistent with an aggregator that stopped accumulating at some point in the past and a meter that never did.
What I ruled out, and how
- Full power cycle. I cut power to the Envoy and my IQ Combiner breakers on 2026-07-31. The frozen values persisted across the restart — this wasn't a stuck process that a reboot clears.
- Firmware change mid-issue. Version was
D8.3.5433before and after. Nothing updated out from under me. - Network or auth failure. All four endpoints answered
200over the same authenticated local HTTPS session, seconds apart. If the Envoy were unreachable or the session had expired, every endpoint would have failed the same way. Only some did. - A dead array. All 30 of my microinverters were reporting. The meter showed normal voltage and frequency. Production was happening; only some of the counters tracking it weren't moving.
What stayed accurate: the cloud path
The part of this that matters most if you're trying to decide whether to worry: my Enphase Enlighten cloud daily totals were unaffected across 2026-07-29, 2026-07-30, and 2026-07-31 — the exact window the local aggregators were frozen in. I compare Enlighten's published daily kWh against my own independent trapezoidal integral of instantaneous production readings, and for those three days the two agreed to within 0.1%, 0.0%, and 0.6% respectively. Across 105 days of that same comparison on my system, I've found zero genuine cloud errors. The local Envoy API and the Enphase cloud pipeline are two separate paths from the same hardware, and on my system, one broke while the other didn't.
I run an independent local collector precisely so a gap like this doesn't go unnoticed — it's also why I could catch this at the endpoint level instead of just seeing a flat number on a dashboard and assuming a quiet day.
If you're seeing this on your own Envoy
If your Envoy's production readout looks stuck, here's the check that isolates it: pull /api/v1/production twice, at least an hour apart, during daylight. If wattHoursToday and wattsNow come back byte-identical while your array should be producing, then pull /ivp/meters/readings at the same moment. If the meter reading is moving and the production endpoint isn't, you have the same split I found: a local aggregator stuck while the meter that actually measures delivered power keeps working.
Two things worth checking on your own system before assuming the worst: whether your Enphase Enlighten cloud daily total for the affected day looks right (compare it against a rough estimate from your own weather and array size, or against a recent similar-weather day), and whether a full power cycle of the Envoy clears it — on my system it didn't, but I don't have data on whether that's universal.
Who else this could affect
Anything reading /api/v1/production or the eim/pcu aggregates directly from the local Envoy API — rather than the Enphase cloud — inherits this failure mode. That includes Home Assistant's Enphase Envoy integration and other local-network dashboards built against these same endpoints. If your local dashboard shows a flat number, checking against /ivp/meters/readings or your cloud Enlighten total is a way to tell whether it's a quiet system or a frozen aggregator.
What's still open
I don't know what triggers this, how often it recurs, or whether it's specific to this firmware build, this Envoy generation, or this part number. I haven't found a documented cause and I'm not going to guess at one. What I can say is limited to what I measured on my own system: three local aggregates froze at the same time, a power cycle didn't fix it, and the meter reading and the cloud pipeline stayed accurate throughout.
pcu re-sample. I'm not calling this a defect and I don't have enough data points to know how common it is — that part hasn't changed. I'll update this post with whatever comes back from Enphase. I'm publishing the endpoint-level measurements now because when I went looking for this exact symptom, I couldn't find anyone else's numbers to compare against.