Battery SOC low - infeasible result from MPC

[RudolfRendier]

I have solar, a small LifePO4 battery 2,5kWh and no deferrables.
I try to optimize when to charge/discharge the battery.

I slowly discharge the battery in the evenings and at night. I stop discharging at 5% SOC.
And this is how I run the dayahead early in the morning, with only 15% SOC left.
This works fine for the dayahead optimization, but the MPC always gets me infeasible results.

I tried various changes in the Web UI and it seems that the low soc_init (15%) and soc_final (5%) are the culprit.
If I change both to 30% the MPC is optimal. What should I do differently? Thanks.

[fredriklj]

I've been struggling with this myself for a day now, and I found that setting soc_init to current SoC had no impact. I had to set "battery_target_state_of_charge" which seem to double for both soc_init and soc_final, and then override with whatever soc_final should be.

Perhaps this is the same issue: #348 (comment)

Would love to know the thinking behind this behaviour, so I can adapt my configuration accordingly.

[RudolfRendier]

This part of the documentation makes me think I need to save the soc_init and soc_final values from the day-ahead and re-use that for every MPC-call throughout the day:

"In a practical use case, the values for soc_init and soc_final for each MPC optimization can be taken from the initial day-ahead optimization performed at the beginning of each day."

But I've also seen examples where it's the current SoC:

. `soc_init`:
This part calculates the 'soc_init' value (state of charge initial value). It takes the
'sonnenbatterie_XXXXX_state_charge_user' value, converts it to a float (using `float(0)` as a
fallback default value), and divides it by 100. 

All the snippets on the HA Community forum do this as well, so I'll experiment with that for a bit.

Also this remark of the author confuses me:

Your template leads to what prediction_horizon?
First check that all the passed data on those list templates are correct (no missing data, stranted string, etc).
If all your passed data are correct then this infeasible status can be caused by you asking for something on your system that is just impossible. For example (this may not be your case) if you ask to completely discharge your 5 kWh battery in just one hour but your maximum battery discharge power is 1 kW then the optimization will throw a infeasible status. Check your battery limits settings, the prediction_horizon, the result of that soc_init template, etc. And why are you setting soc_final = 0.05? You are asking the system to completely discharge your battery on one single MPC iteration, that can be a source of problems.

https://community.home-assistant.io/t/emhass-an-energy-management-for-home-assistant/338126/1074

But I'm not sure if this is the next 30 minute-period, or the end of the horizon.

[fredriklj]

I've also been confused by the day-ahead vs. MPC optimisation. However, as the document states in the ingress of the section dealing with the MPC:

"This can be used in combination with/as a replacement for the Dayahead Optimization."[1]

So it should work on its own, I believe. To me it is not exactly clear why you would want to combine them, rather than just running the MPC regularly with the most recent data you have (both actual values and forecast for electricity prices and PV production).

[1] https://emhass.readthedocs.io/en/latest/intro.html#a-naive-model-predictive-controller