OwlWhen Your Enphase Envoy's Production Readout Freezes at Zero
If your Envoy is showing a flat zero on a sunny day, you're probably wondering whether your array died or your monitoring did. I had that exact morning. On 2026-07-31 an Enphase Envoy on a system we monitor stopped moving its local production readout. 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
The 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. The 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 that 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, and both were frozen. rgm read zero the whole time on this system (a revenue-grade meter aggregate not 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. We cut power to the Envoy and the IQ Combiner breakers on 2026-07-31. The frozen values persisted across the restart, so 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. Every microinverter on the array was 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, we'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 this system, one broke while the other didn't.
We run independent local collectors precisely so a gap like this doesn't go unnoticed, and 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 this one 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 from 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 we measured on the affected 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, and 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.
A frozen counter is the quiet version of this problem. The loud version is a number that keeps moving and is simply too low.
Say your system should make 10,000 kWh a year and it's running 10% under. At 30¢/kWh that's 1,000 kWh and about $300 a year you never see, because nothing on your dashboard is telling you what the number should have been. OwlWatt is $9.99/month, or $87.89 a year, and it computes that expected number independently and shows you the gap. Use your own annual production and your own rate off your bill and the arithmetic is yours to check.
To be straight with you: we measure and document the gap, we don't recover the money, and whether a claim goes anywhere depends on your contract. Plenty of systems turn out to be fine, and knowing that is worth something too.