All runtime parameters as Add-on options

[GeoDerp]

Question: Since there are a few runtime parameters that aren't optional option parameters. Would we like to add these as well or keep them separate? (Ie. Would we like to be able to set all possible parameters in the add-on options? (Have the ability to set them all in one place) My thoughts would be that these parameters would need to be overridden if a runtime was passed.

(Considering how big change this would likely be. There is a high likelihood I won't be the one to implement this.)

[davidusb-geek]

What are these missing runtime parameters?

[GeoDerp]

prediction_horizon
soc_init
soc_final
sklearn_model
num_lags
split_date_delta
perform_backtest
model_predict_publish
model_predict_entity_id
model_predict_unit_of_measurement
model_predict_friendly_name
custom_pv_forecast_id
custom_load_forecast_id
custom_batt_forecast_id
custom_batt_soc_forecast_id
custom_grid_forecast_id
custom_cost_fun_id
custom_optim_status_id
custom_unit_load_cost_id
custom_unit_prod_price_id
custom_deferrable_forecast_id

here are some I found. As I don't know what most of these do I'm sure some if not all of these are only necessary as runtime variables

[davidusb-geek]

Ok thanks. I don't that we should add all these parameters to the configuration. My logical reasoning is that there are already a lot of parameters to configure and most people get confused and frustrated with that. Your effort to organise the add-on parameters and make a bunch of them optional was a good move to simplify this but I still think that there are some parameters that are not meant to be set in the configuration pane but only as runtime params. For example those related to MPC. People doing MPC should set these options at runtime otherwise it doesn't makes sense. This is why there is a whole list of parameters that are not intentionally in the add-on configuration pane.

[davidusb-geek]

But this doesn't mean that there are some parameters that we can still add to the config pane. For example those related to the ML forecaster. The disadvantage of adding these is that if an user is not using the ML forecaster method at all then all those parameters options related to ML forecaster will be there in the configuration for nothing and adding to more complexity. But well this is also the case for battery or PV related parameters for someone that does not have batteries or PV.

[philjohn]

I'm working on a pull request to expose soc_init and soc_final to the dayahead-optim mode, the idea is I'll pass in the current SOC of the battery and then what you want it to be at the end of the optimization period - would you be open to that pull request?

[davidusb-geek]

I'm working on a pull request to expose soc_init and soc_final to the dayahead-optim mode, the idea is I'll pass in the current SOC of the battery and then what you want it to be at the end of the optimization period - would you be open to that pull request?

Why not just use the MPC? This is what MPC is for, while day-ahead is intended to be focus on a complete day and balanced battery charging with SOCinit = SOCfinal. You can set MPC with a prediction horizon of 24 hours and obtain exactly what you are describing.