Battery forecast declinging with each MPC run

[martinarva]

Describe the bug
I'm using ML Forecast for load forecast that I run daily and MPC that runs every five minutes, but facing issue that every time there is a max sell to grid hour, battery power forecast starts with max power and then every MPC run it decreases the power. Issue is that i'm not able to fully utilise the selling potential and the SOC is much higher by the end of the hour than in the optimisation plan.

Here is a screenshot from today

I have tried alpha 1, beta 0 and vice versa, but no effect on my issue.

Also iI don't understand the battery SOC forecast. At the moment my battery is 49% but in the EMHASS forecast it's showing 25.3%. Im feeding in soc_init with every MPC run every 5 minutes, so emhass should have the latest state. I could think that EMHASS will show the SOC for the end of hour, but here you can sxee that it's 21:02 and emhass thinks my battery is 20.6%, but it's 48%.

So actually two issues that may be related:

• Decreasing battery power forecast
• Battery SOC forecast i don't fully understand

Home Assistant installation type

• Home Assistant Core

Your hardware

• OS: Linux, Docker
• Architecture: amd64,

EMHASS installation type

• Docker Standalone

[martinarva]

Here is a screenshot of EMHASS forecast vs real battery power

You can see that every MPC run the p_batt_forecast decreases for idk what reason.

Here is the SOC forecast vs real

What is wierd here is that even though i post the real SOC with every MPC run every 5 minutes, EMHASS still is using some internal forecast SOC. You can see that the SOC increase and decrease are not linear, but jumping from one value to another. Maybe this will cause the decrease of the forecast power because emhass thinks the battery is more full/emty than it actually is?

[martinarva]

Could it be that as the SOC decreases, the MPC is still trying to reach the SOC target by the end of the period, but it assumes that it has a full hour remaining? For example, if the actual time is 14:30, the MPC might think it’s still 14:00 and that it has the full hour to discharge or charge the battery. As a result, it might reduce power output to a lower level, thinking there’s more time left to meet the SOC target by the end of the hour. In reality, since there’s only half an hour left, it should be discharging with higher power to hit the target.

Since the MPC runs every 5 minutes, it could be recalculating as if the full hour is available each time, even when less time remains. This might cause the system to apply less power than needed, believing it has more time to reach the desired SOC.

To resolve this, a few options come to mind:

1.	Time-Adjusted Approach: The optimizer should account for the actual time left in the hour. For instance, if there are only 30 minutes remaining, it should increase the discharge power to ensure the target SOC is reached by the end of the hour.
2.	Run the MPC Less Frequently: Running the MPC every hour (or every 15 minutes) instead of every 5 minutes might help stabilize SOC management and prevent the issue of gradual power reductions due to the system assuming it has more time than it actually does.

Would anyone have suggestions on how to implement a time-aware approach in MPC or has anyone faced a similar issue?

Also, would running the MPC only once per hour help prevent the model from mistakenly thinking it has more time left than it actually does? This might avoid scenarios where it reduces power output gradually to meet the SOC target, without realizing that the time remaining is less than it assumes.

[martinarva]

So I tried running MPC one a hour at 59th minute and publish data once hour on 00 minute.

As you can see on the right is the whole hour was full sell to grid. So i think that the issue is reason i tried to explain in my prevoius post that every MPC run it sees that the soc has been decreased and thinks that it has the whole timestep to spend the energy, but in reality maybe only half an hour or less is to go and in lower power it cant spend the energy.

So all in all there will be an issue when MPC run frequency is higher than the timestep configured.

One option is to make the timestep same lenght as the MPC run frequency. I think it's possible to generate 5 minutes datapoints from Solcast and Nordpool. Other data should be alresdy there.

@davidusb-geek , what are your thoughts?

UPDATE: I have now 15 minute timestep and MPC run every 15 minutes and everything looks great.

[fredriklj]

Can't say for sure it is related, only been playing with emhass for a day now. But, I have noticed that the MPC does not take soc_init as a truth, but rather just mixing it in with some weight. And alpha/beta parameters seem to not have any noticeable effect on it.

Only way I could get the MPC to work with the actual SoC was to set "battery_target_state_of_charge", which seem a bit awkward to me. It sort of doubles for both initial and final state, but final state can then be overridden with soc_final. I found soc_init to be useless.

I am sure there are some clever thinking behind this behaviour, would love to know what that is.

[martinarva]

Can't say for sure it is related, only been playing with emhass for a day now. But, I have noticed that the MPC does not take soc_init as a truth, but rather just mixing it in with some weight. And alpha/beta parameters seem to not have any noticeable effect on it.

Only way I could get the MPC to work with the actual SoC was to set "battery_target_state_of_charge", which seem a bit awkward to me. It sort of doubles for both initial and final state, but final state can then be overridden with soc_final. I found soc_init to be useless.

I am sure there are some clever thinking behind this behaviour, would love to know what that is.

I think that the Battery SOC number you see in the battery forecast is the SOC that will be by the end of this timestep. Fro example 14:00 SOC is actually the 14:59 SOC.

So all in all the main issue is how the first timestep is handled. Would be nice if EMHASS could handle the first timestep in a better resolution and knows there in time the current time ise

[fredriklj]

I think that the Battery SOC number you see in the battery forecast is the SOC that will be by the end of this timestep. Fro example 14:00 SOC is actually the 14:59 SOC.

Quite sure that wasn't the problem, because the numbers were off by 70% of the battery capacity, and I can not pull that much from my mains in one hour. And it would have shown on the grid consumption number, I guess.

So there is still something mysterious with the soc_init parameter.

[fredriklj]

After a closer look, I think you are right. It seems emhass don't publish data for the current hour. So the sensor readings are actually for the next hour, and the same as the first element in the list provided in the attribute.

Seem a bit weird to me, wonder if that is really intentional. I'll ask a question in the discussion group to see if I can get a clear answer. Thanks!

[davidusb-geek]

@davidusb-geek , what are your thoughts?

UPDATE: I have now 15 minute timestep and MPC run every 15 minutes and everything looks great.

Sorry to come late on this but definetly I would not run MPC to a higher frequency (and hence the overall timestep) to what your available data can manage. That may result in strange results.

[davidusb-geek]

Can't say for sure it is related, only been playing with emhass for a day now. But, I have noticed that the MPC does not take soc_init as a truth, but rather just mixing it in with some weight. And alpha/beta parameters seem to not have any noticeable effect on it.

Only way I could get the MPC to work with the actual SoC was to set "battery_target_state_of_charge", which seem a bit awkward to me. It sort of doubles for both initial and final state, but final state can then be overridden with soc_final. I found soc_init to be useless.

I am sure there are some clever thinking behind this behaviour, would love to know what that is.

Setting SOC init and SOC final at runtime should work just fine, but that works only for passed data at runtime, ie via the curl template command. This has been well tested and approved.

The "battery_target_state_of_charge" was originally intended to be used outside an MPC approach, for example just for a day-ahead optimization

[tobre6]

@davidusb-geek , what are your thoughts?
UPDATE: I have now 15 minute timestep and MPC run every 15 minutes and everything looks great.

Sorry to come late on this but definetly I would not run MPC to a higher frequency (and hence the overall timestep) to what your available data can manage. That may result in strange results.

This makes a lot of sense, but documentation says multiple times that frequency should be high, i.e 5 minutes. Maybe better explanations needed in documentation?

An MPC controller performs the following actions:
Set the prediction horizon and receding horizon parameters.
Perform an optimization on the prediction horizon.
Apply the first element of the obtained optimized control variables.
Repeat at a relatively high frequency, ex: 5 min.

[tobre6]

After a closer look, I think you are right. It seems emhass don't publish data for the current hour. So the sensor readings are actually for the next hour, and the same as the first element in the list provided in the attribute.

I had problem, when published sensor data was off and not for current hour. Please see parameter method_ts_round. For me better results I got when it is first, but default is nearest.

But this is not for batter init soc. This works like @martinarva described.