Is it normal for MPC optimization results to differ so dramatically even when it's run often?

[F21]

I am running naive mpc optmization every 5 minutes. The forecast import price and export price have different rates depending on time period, but is fixed.

This is what my config.json looks like:

{
  "historic_days_to_retrieve": 7,
  "continual_publish": true,
  "costfun": "profit",
  "optimization_time_step": 5,
  "delta_forecast_daily": 2,
  "number_of_deferrable_loads": 0,
  "sensor_power_photovoltaics": "sensor.homekit_homekit_pv",
  "sensor_power_load_no_var_loads": "sensor.house_load",
  "sensor_replace_zero": ["sensor.homekit_homekit_pv", "sensor.house_load"],
  "sensor_linear_interp": ["sensor.homekit_homekit_pv", "sensor.house_load"],
  "set_use_pv": true,
  "set_use_battery": true,
  "inverter_is_hybrid": true,
  "inverter_ac_output_max": 10000,
  "inverter_ac_input_max": 14500,
  "compute_curtailment": true,
  "set_use_adjusted_pv": true,
  "pv_module_model": ["Huasun_HS_182_B108_DSN440"],
  "surface_tilt": [35,35,35],
  "surface_azimuth": [100.27,279.52,13],
  "modules_per_string": [7,8,6],
  "pv_inverter_model": [10000],
  "strings_per_inverter": [3],
  "battery_discharge_power_max": 11000,
  "battery_charge_power_max": 13500,
  "battery_nominal_energy_capacity": 48000,
  "set_nodischarge_to_grid": false,
  "maximum_power_from_grid": 13500,
  "maximum_power_to_grid": 5000,
  "lp_solver_mip_rel_gap": 0.01,
  "lp_solver_timeout": 90
}

This is an example of the runtime parameters passed to the MPC optimization endpoint:

{
   "prediction_horizon":576,
   "soc_init":0.85,
   "soc_final":0.1,
   "battery_minimum_state_of_charge":0.1,
   "battery_maximum_state_of_charge":1,
   "load_cost_forecast":{
      "2026-06-26T21:00:00+10:00":0.407,
      "2026-06-26T23:00:00+10:00":0.308,
      "2026-06-27T11:00:00+10:00":0,
      "2026-06-27T14:00:00+10:00":0.308,
      "2026-06-27T16:00:00+10:00":0.407,
      "2026-06-27T23:00:00+10:00":0.308,
      "2026-06-28T11:00:00+10:00":0,
      "2026-06-28T14:00:00+10:00":0.308,
      "2026-06-28T16:00:00+10:00":0.407,
      "2026-06-28T23:00:00+10:00":0.308,
      "2026-06-29T11:00:00+10:00":0,
      "2026-06-29T14:00:00+10:00":0.308,
      "2026-06-29T16:00:00+10:00":0.407
   },
   "prod_price_forecast":{
      "2026-06-26T21:00:00+10:00":0,
      "2026-06-27T18:00:00+10:00":0.1,
      "2026-06-27T21:00:00+10:00":0,
      "2026-06-28T18:00:00+10:00":0.1,
      "2026-06-28T21:00:00+10:00":0,
      "2026-06-29T18:00:00+10:00":0.1
   }
}

The graphed results of the optimization and the pricing data:
2026-06-26 20:46

2026-06-26 20:55

2026-06-26 21:01

Is it normal for the optimization results to vary so dramatically even though the optimization is called at such a frequent frequency?

[LesIT1]

Short answer: yes, this is normal, and I'd bet the total profit across your three runs is nearly identical. The schedules look different but the objective barely moves. That's degeneracy, not instability.

What's going on: your prices have a small spread (export is 0 except the 0.1 window, midday import is free), so lots of different charge/discharge schedules tie, or nearly tie, on profit. The solver returns one of them, and any small change in the PV or load forecast, or the measured SoC between runs, flips it to a different but equally good plan.

The lp_solver_mip_rel_gap: 0.01 you're running (now the default since #988, off the back of your deep-horizon timeout in #986) feeds into this. A 1% gap means the solver accepts any incumbent within 1% of the bound, so consecutive runs happily land on quite different schedules. I would not tighten it back toward 0 though, that just brings back the user_limit no-plan failures on the slower hardware. It's the right setting, it just makes the variance more visible.

A couple of things that reduce the swing without touching the gap:

1. Add small weight_battery_charge / weight_battery_discharge penalties. They make the optimum more unique so fewer schedules tie, which cuts the run-to-run thrash and usually speeds the solve too.
2. You've got compute_curtailment: true, so some of this could be the curtailment flip-flop in mpc optimiser flip flops during curtailment #565. Worth a read, David's potential-PV template sensor in that thread is the workaround.

Also worth remembering that naive MPC only actuates the first timestep and then re-plans, so the tail reshuffling is mostly cosmetic. What matters is whether the first step or two is stable.

Easiest way to confirm it's degeneracy: log the optimisation cost for the three runs. If the curves jump around but the cost barely moves, that's exactly it, and it's benign.

[F21]

Thanks for the clear and concise explanation, @LesIT1 ! I checked my optimization results and the cost/profit cycles around the same range despite the optimization curves varying dramatically between each run, so it appears everything is working as expected!