is there actually a need/benefit to pass "load_power_forecast" runtime parameter to the naive-mpc-optim?

[scruysberghs]

To my understanding emhass already gets those from the chosen prediction method (naive, mlforecaster of typical)?

I have seen people that pass it as a runtime parameters starting the range of values with the actual value of the sensor_power_load_no_var_loads sensor and then fill the rest of the range with the values posted to the the sensor.mpc_p_load_forecast from the previous run. Does that make sense?

Something like this:

  {% set forecasts = state_attr('sensor.mpc_p_load_forecast', 'forecasts') %}
  {% set load_forecast_list = forecasts | map(attribute='mpc_p_load_forecast') | map('float') | list %}
  {% set first_value = states('sensor.power_load_no_var_loads') | float(0) %}
  "p_load_forecast" = {{ [first_value] + load_forecast_list[1:pred_horizon] }},

What would be the benefit?

I do the same with pv_power_forecast, post the first value as actual measured instant PV yield and then add the pv prediction values but for me that somehow makes more sense as emhass doesn't predict those in my case.

[davidusb-geek]

The runtime functionality is there to do exactly the same as you do with the pv_power_forecast, that is provide the load power forecast by using an external forecasting method. Probably not a lot of people is using this in that way but I would imagine that someone use an external method (using machine learning or other method) to do load power predictions and this is just the functionality that allows you to inject that into EMHASS.
So in my case I don't understand why would you ever want to inject the previous internal forecast generated by EMHASS there. It does not makes sense to me.

[scruysberghs]

Thanks for confirming my feeling that this indeed doesn't make sense David.