Runtime Params no longer repected in 0.17

[projectcobalt]

After upgrading to 0.17 latest many of my runtime params are no longer respected during the optimization

One in particular is min_soc, but im sure there are others.. attached screenshots below show parsing min_soc at 0.4, optimization still resolves at 0.36.. which is equla to the 0.2 min_soc during boot.

Interestingly this value is respected after a reboot but will not change during runtime calls

[kairisku]

I have noticed the same with the dayahead-optimization (which I run every 15 minutes), i.e. the passed value for battery_target_state_of_charge is effectively ignored and old values are used from the cache.

Seems the warm-start Optimization cache in 0.17 is to blame, because after a reboot or restart of EMHASS the first optimization run works perfectly, but additional runs that get stuff from the cache seem to have explicitly passed runtime parameters being overwritten with values from the cache.

As as workaround I am currently wiggling the nominal_power_of_deferrable_loads value by a very small fraction in order to cause a deliberate cache miss.

[davidusb-geek]

Thank you both for signaling this.
Yes effectively it seems like an issue introduced at PR #711 with the new Optimization Cache functionality.
I've proposed in PR #737 a fix for this issue by explicitly passing the plant_conf and optim_conf dicts that contain those params that were previously ignored by the cache system. This is all in command_line.py and set_input_data_dict method in the "Cache hit" case.
I have also added a unit test to check the approach and trying to replicate as much as possible the real usage: test_mpc_cache_plant_conf_updates
But we will need you to test this and confirm if solved.
What do you think @sokorn ?

[sokorn]

I missed a few parameters with the caching, mea culpa. Thanks for the PR.
I just checked the code again and there are several other parameters which are also not covered via the PR.
Especially def_current_state creates also stale results. We should update it to parameter instead of constraint so it can be used without rebuilding the object.
@davidusb-geek shall I create a seperate PR, or do you update it with yours?

[davidusb-geek]

@davidusb-geek shall I create a seperate PR, or do you update it with yours?

Thanks for your reply.
I've just merged my PR, you can go ahead and create a new one starting from current master and yes please add the missing params.