Production switch on/off propagates but PCU re-enable unreliable on D8.3.5286 (IQ Gateway Metered, no CTs)

[ThaSoleus]

Describe the bug

The production switch sends the on/off command correctly to the Envoy. I can
see this in the Enlighten event log. The problem is what happens after that.

When I toggle off, only some inverters stop, and they do so in a slow,
staggered pattern. When I toggle on again, production does not come back
within a reasonable time. After two test cycles I had to recover the system
manually via Enlighten Manager (Disable then Enable Power Production task)
to get all 18 PCUs producing again.

Account type

• Installer
• DIY / DHZ
• Home Owner

Envoy

• Metered with CTs installed

• Metered without CTs

• Standard

• FW version: D8.3.5286

• Gateway PN: 800-00656-r06

• Microinverters: 18 x IQ7+

• Grid profile: EN 50549-1:2019 RfG E02 Netherlands:1.2.4

Home Assistant

• HA version: 2026.5.0
• Integration version: 0.8.4
• Token type: installer (verified via the diagnostic sensor)
• The official enphase_envoy integration was deleted before installing this
  one. Disabling was not enough, the new install still hit "already
  configured" until I deleted the old config entry.

What I did

Two test cycles on 2026-05-08, both with battery idle and full (SoC 99 %)
and EV stopped. I used the P1 meter as ground truth because the production
sensor in this integration lags badly (more on that below).

Test 1: 12:41:49 -> 12:53:31, off period 11m42s, baseline around 5 kW PV

The production sensor stayed frozen at 5.061 kW for the whole off period.
P1 settled around -74 W, which I cannot interpret cleanly because the
battery was running its P1 balancing mode and may have masked the actual
PV reduction. After toggle on, PV recovered to roughly 80 % within 80
seconds. So this first test did not give me a clean reading.

Test 2: 15:52:05 -> 15:59:53, off period 7m48s, baseline around 5 kW PV

This time the battery was idle and full, so P1 reflects PV directly.
Negative P1 means export to grid:

t	P1 (W)	Note
0	-3725	full export, all PCUs producing
30s	-2666	partial reduction
90s	-1576	about 60 % reduction
105s	+40	brief near zero
120s	-1340	rebound, PCUs not synchronized
181s	-4007	full PV export again, mid-cycle
332s	-597	about 85 % reduction
437s	-535	end of off, 1 or 2 PCUs of 18 still producing

So the off command works, but only partially and on a slow rolling cycle.

After toggle on at 15:59:53, P1 went to roughly zero and stayed there. PV did
not come back. I waited 18 minutes, then tried an off then on kick (a quick
30 second cycle). No effect.

Recovery via Enlighten task

After about 20 minutes of no recovery I went to Enlighten Manager, opened
the Envoy, and ran the Disable Power Production task (this took 10 to 15
minutes to complete, the UI says "check back later"). Once it had completed
I clicked Enable Power Production. A few minutes after that, P1 jumped to
-1412 W and PV was back to normal output.

Enphase event log (Enlighten CSV)

This confirms my HACS toggles arrived at the gateway correctly:

12:42:43  STATEFUL  Power generation off by command   (HACS toggle off 12:41:49)
12:54:19  CLR       Power generation off by command   (HACS toggle on 12:53:31)
15:53:04  STATEFUL  Power generation off by command   (HACS toggle off 15:52:05)
16:00:52  CLR       Power generation off by command   (HACS toggle on 15:59:53)
16:18:23  STATEFUL  Power generation off by command   (HACS kick off 16:17:34)
16:19:02  CLR       Power generation off by command   (HACS kick on 16:18:04)

Each command shows up at the gateway about a minute after the HACS service
call. The integration is doing its job. The unreliability is downstream of
the gateway: PLC propagation to the PCUs, and the re-enable behaviour
specifically.

Observations

1. Switch state desync after Enlighten task: while the Enlighten Disable
   task was running, the HACS switch flipped to off, which is correct. But
   after the Enlighten Enable task completed and PV came back fully (P1
   showing 1.4 kW export), the HACS switch still showed off. The integration
   does not seem to pick up the Enable from the Enlighten side. Possibly a
   different flag, or just slow polling.

2. sensor.envoy_*_current_power_production is not real-time. I lowered
   "minimum time between entity updates" to 10 s in the integration options,
   but the sensor still lags 5 to 15 minutes. During an off test it shows
   the pre-test cached value for the whole period. After recovery it decays
   slowly toward reality. This makes it unusable as a real-time signal for
   automation.

3. Re-enable is unreliable. The CLR event reaches the gateway fine, but the
   PCUs often do not resume. Multiple toggles did not help. Only the
   Enlighten Disable + Enable task pair worked. This matches your remark
   in [BUG] Production switch does not work. #250 that the production stop and start implementation on the Envoy
   itself is buggy.

Diagnostics

Happy to share the integration diagnostics file if helpful, just let me know.

Workaround for now

I am not going to rely on this switch for automated price-based curtailment.
Instead I let the battery and EV absorb PV surplus during negative price
windows. Less direct, but reliable. If I install CTs later I can move to
Soft PEL with the meter feedback loop.

Suggestions / questions

• Could the integration poll the gateway production state more aggressively
  for a few minutes after a switch.turn_on call, so the entity catches up
  even when the PCUs lag?
• Would it make sense to document the Enlighten Disable + Enable recovery
  in the readme, for D8.3.x firmware?
• Could the switch.turn_on action optionally trigger a Send Latest Grid
  Profile broadcast as a kick mechanism for stuck PCUs?

Thanks for the integration. Even with this issue, installer-account control
from HA is a big step up from the alternatives.

[vincentwolsink]

Hi @ThaSoleus, thank you for your extensive report.

On your observations:

1. All the integration does is poll the API endpoint for the state every minute (by default). So in theory the switch should go back on after maximum one minute. But it could be that the Envoy is actually slow in reflecting the state at the local API.
2. If you don't have CTs installed, production power is polled from the inverters by the Envoy. This polling only happens every 5-15 mins. You can check the polling interval sensor at the Envoy and latest reading timestamp sensors at the individual inverters.
3. Correct. It seems to be less reliable at setups without CTs installed.

On your suggestions:

• The integration polls the power state on every update cycle, which by default is every minute.
• It would make sense, if we have a clear idea on the pattern. But it seems to differ per setup. Generally setups with CTs seem to be faster and more reliable.
• I don't know about an endpoint to do this.

Generally the most reliable way of limiting production/export would be via the enable_dpel action. But you also need CTs for that.

[mpezaro]

Adding a data point from a different setup that hits the same core issue.

System: Envoy-S Metered with CTs installed, 17x IQ8HC microinverters, firmware D8.3.5232 (AU), grid profile AS/NZS 4777.2:2020 Australia A Region, installer token type.

What I saw: Toggled the production switch off, then back on a short time later. After toggling on, the Enlighten "Issue Details" panel showed "Power generation off by command" for 2 of 17 microinverters, with the recommended action being the standard "waiting for permission to operate" message. They did not recover on their own after a normal ~15 minute poll cycle.

Recovery: I didn't try toggling the switch again. Instead I went to the Enlighten cloud PEL settings page (Settings > Power Production Limiting by Gateway) and used "Disable Existing Settings" + Save. This sent a request to the gateway and the stuck inverters recovered shortly after. So this is a second working recovery path alongside the Disable/Enable Power Production task pair mentioned above — possibly the same underlying mechanism triggered via a different UI entry point.

Why I'm interested in DPEL/relay_config specifically: Because I have CTs, I'd been separately experimenting with the local /ivp/ss/dpel endpoint directly (dynamic_pel_settings + relay_config, with an installer-level Entrez token) for export-limit curtailment, independent of this integration. Early findings, still preliminary:

• The PEL UI's "Power limitation target" has separate Production vs Export options, and mine was set to Export. When I sent a limit_value_W target via dynamic_pel_settings, actual production settled at roughly target + house load — consistent with it being an export limit rather than a production limit.
• The relay_config percentage (computed from a configurable installed-capacity figure) didn't seem to be the binding constraint in my tests — changing that capacity figure significantly didn't change the result much, so I suspect limit_value_W + enable_dynamic_limiting may be doing most of the work, with relay_config as a coarser pre-limiter.
• I haven't yet found a clean "disable PEL" payload for this endpoint that's distinct from setting pct: 100 — using 100% as a proxy for "off" is plausibly what contributed to my stuck-inverter situation, similar to how this issue's restore flow doesn't seem to map cleanly to a genuine return-to-normal state.

Suggestion: given this issue's reporter's point about CTs enabling a "Soft PEL" path with meter feedback — I'd be keen to see DPEL/export-limit exposed as a proper HA entity (e.g. a number entity for export limit watts) for systems with CTs, alongside whatever fixes might be possible for the production switch's re-enable reliability. Happy to share more detail on what I've found via the raw DPEL endpoint if it's useful for that.

Thanks for the integration and for documenting this issue in such detail — saved me a lot of guesswork on the recovery path today.

[vincentwolsink]

DPEL is exposed to HA as actions enable_dpel and disable_dpel. The enable_dpel has parameters for watt, slew_rate and export or production limit available.

[mpezaro]

Thanks! I did discover that eventually but it was not obvious at first! I will test it out today.