Optional post-adjustment PV feedback for MPC step 0

[MMicieli]

Context

EMHASS already supports live first-step forecast mixing, externally supplied pv_power_forecast values and adjusted-PV regression. These mechanisms are documented and useful; this proposal does not seek to replace them.

In naive-mpc-optim, Forecast.get_mix_forecast() can blend a current PV measurement into the first forecast timestep. When set_use_adjusted_pv=true, the adjusted-PV regression subsequently uses the forecast as input and returns a new Series. Consequently, the original first-step measurement blend is not guaranteed to survive as the final optimiser-facing value.

Runtime PV lists already allow callers to construct their own corrected forecast, but there is no equivalent native post-adjustment feedback stage.

The potential addition is therefore narrow: adjust only the first optimiser-facing PV timestep after native forecast adjustment, leaving the remainder of the forecast and optimiser unchanged.

Retrospective evidence

We evaluated 677 five-minute forecast origins against retained approximately five-second PV measurements over 13–17 October 2026.

On 603 matched eligible origins:

First-slot forecast | MAE -- | -- Native adjusted PV | 1,661 W Latest measured PV, fixed gain 0.50 | 1,017 W Latest measured PV, fixed gain 0.75 | 874 W

The 75% blend also worsened absolute error by more than 1 kW in 39 of 603 cases. Rapid cloud transitions remain a material limitation.

Trailing 15–120-second averages did not improve pooled accuracy over the latest observation at the same gain. More complex adaptive weighting showed no material benefit over fixed weighting.

This is retrospective produced-PV forecast accuracy, not demonstrated economic benefit, improved battery dispatch or evidence that a specific gain should become a default.

Detailed research results

Curtailment compatibility

The distinction between actual produced PV and available PV before curtailment is already recognised in EMHASS.

Relevant existing work includes:

• Discussion #536 and Issue #565: curtailment-induced feedback and the potential-PV sensor workaround.

• PR #566: first-step PV feedback bypass.

• PR #1027: exclusion of curtailed production from adjusted-PV training.

These protections should be preserved. We are not proposing automatic reconstruction of available PV through measured production plus planned curtailment, because planned curtailment does not prove the amount physically withheld.

Proposed architectural decision

Would maintainers consider a small, opt-in, default-off correction to the final adjusted-PV forecast at timestep zero, or is caller-side modification of the documented pv_power_forecast runtime input the preferred architectural boundary?

If a native feature is appropriate, the proposed initial implementation would:

• Apply a simple fixed-weight correction only to optimiser-facing PV timestep zero, after adjust_pv_forecast().

• Use a valid, fresh, time-aligned observation from existing input sources.

• Preserve every subsequent PV forecast value, load forecasting, optimisation constraints and default behaviour.

• Preserve existing curtailment feedback protection and distinguish genuine zero measurements from invalid or missing input.

• Include focused tests for native and external forecast paths, UTC alignment and disabled-path parity.

Any PV-specific weighting should avoid silently changing the established load-forecast behaviour of shared alpha/beta.

This proposal does not include adaptive learning, additional polling, a high-frequency scheduler, multi-step corrections, automatic curtailment add-back, a second optimiser or inverter-specific controls.

The purpose of this Discussion is to settle the architectural scope before proposing implementation code.

# Optional post-adjustment PV feedback for MPC step 0

Context

EMHASS already supports live first-step forecast mixing, externally supplied pv_power_forecast values and adjusted-PV regression. These mechanisms are documented and useful; this proposal does not seek to replace them.

In naive-mpc-optim, Forecast.get_mix_forecast() can blend a current PV measurement into the first forecast timestep. When set_use_adjusted_pv=true, the adjusted-PV regression subsequently uses the forecast as input and returns a new Series. Consequently, the original first-step measurement blend is not guaranteed to survive as the final optimiser-facing value.

Runtime PV lists already allow callers to construct their own corrected forecast, but there is no equivalent native post-adjustment feedback stage.

The potential addition is therefore narrow: adjust only the first optimiser-facing PV timestep after native forecast adjustment, leaving the remainder of the forecast and optimiser unchanged.

Retrospective evidence

I evaluated 677 five-minute forecast origins against retained approximately five-second PV measurements.

On 603 matched eligible origins:

First-slot forecast	MAE
Native adjusted PV	1,661 W
Latest measured PV, fixed gain 0.50	1,017 W
Latest measured PV, fixed gain 0.75	874 W

The 75% blend also worsened absolute error by more than 1 kW in 39 of 603 cases. Rapid cloud transitions remain a material limitation.

Trailing 15–120-second averages did not improve pooled accuracy over the latest observation at the same gain. More complex adaptive weighting showed no material benefit over fixed weighting.

This is retrospective produced-PV forecast accuracy, not demonstrated economic benefit, improved battery dispatch or evidence that a specific gain should become a default.

[Detailed research results](https://github.com/MMicieli/home-assistant-config/blob/research/541-native-adaptive-first-slot/docs/evidence/issue541_offline_ab_replay/STAGE16_DENSE_PV_RESULT_20261019.md)

Curtailment compatibility

The distinction between actual produced PV and available PV before curtailment is already recognised in EMHASS.

Relevant existing work includes:

• [Discussion #536](Solar predictions and curtailment, how to handle? #536) and [Issue #565](mpc optimiser flip flops during curtailment #565): curtailment-induced feedback and the potential-PV sensor workaround.
• [PR #566](Add runtime parameter to prevent PV forecast feedback loop during cur… #566): first-step PV feedback bypass.
• [PR #1027](fix: exclude curtailed timesteps from the adjusted PV forecast training data #1027): exclusion of curtailed production from adjusted-PV training.

These protections should be preserved. I am not proposing automatic reconstruction of available PV through measured production plus planned curtailment, because planned curtailment does not prove the amount physically withheld.

Proposed architectural decision

** @davidusb-geek would you consider a small, opt-in, default-off correction to the final adjusted-PV forecast at timestep zero, or is caller-side modification of the documented pv_power_forecast runtime input the preferred architectural boundary?**

If a native feature is appropriate, the proposed initial implementation would:

• Apply a simple fixed-weight correction only to optimiser-facing PV timestep zero, after adjust_pv_forecast().
• Use a valid, fresh, time-aligned observation from existing input sources.
• Preserve every subsequent PV forecast value, load forecasting, optimisation constraints and default behaviour.
• Preserve existing curtailment feedback protection and distinguish genuine zero measurements from invalid or missing input.
• Include focused tests for native and external forecast paths, UTC alignment and disabled-path parity.

Any PV-specific weighting should avoid silently changing the established load-forecast behaviour of shared alpha/beta.

This proposal does not include adaptive learning, additional polling, a high-frequency scheduler, multi-step corrections, automatic curtailment add-back, a second optimiser or inverter-specific controls.

If this is something of interestfor EMHASS ill move this into an issue if not ill keep it local.