[Feature Request] Use Actual SOC as Starting Point in Optimization

[martinarva]

Feature Request: Use Actual SOC as Starting Point in Optimization

Problem

Currently, EMHASS uses the configured battery_minimum_state_of_charge and battery_maximum_state_of_chargevalues both as bounds and as hard limits for the initial SOC at the beginning of optimization.

This becomes problematic when the actual SOC is outside these limits — EMHASS assumes it’s at battery_minimum_state_of_charge or battery_maximum_state_of_charge, rather than using the true SOC from the battery.

Why this matters

In setups where EMHASS isn’t the only controller for the battery, this behavior results in incorrect forecasts and potentially suboptimal scheduling decisions.

Example use case

I use EMHASS to optimize my battery within the range of 30%–80% SOC. However, I’m also participating in the MFFR (Manual Frequency Restoration Reserve) market via Qilowatt/Kratt. These signals override EMHASS control:

• MFFR UP events may discharge the battery below 30% (e.g., down to 5%)

• MFFR DOWN events may charge the battery up to 100%

This is intentional — I want to reserve 0–30% for UP and 80–100% for DOWN commands.

But when this happens, EMHASS ignores the actual SOC and treats it as 30% or 80%, leading to an incorrect optimization baseline.

Visual Example

See attached chart:

• Green: actual SOC

• Red: forecast history

• Blue: forecast going forward

You can clearly see that EMHASS assumes the SOC is at 30% when in reality it’s closer to 5%.

Desired Behavior

• EMHASS should always use the real actual SOC from the sensor as the starting point for optimization — even if it’s outside the configured min/max SOC bounds.

• The battery_minimum_state_of_charge and battery_maximum_state_of_charge should still be enforced as constraints on the future steps, but not as assumptions about the starting point.

Why this change is important

This improvement benefits all users who:

• Manually charge or discharge the battery (e.g. for testing or off-grid prep)

• Participate in demand response programs (MFFR, FFR, etc.)

• Use multiple automation layers (Node-RED, scripts, manual control, etc.)

• Experience unexpected SOC drift (e.g. from grid outages or power failures)

Suggested Implementation

• Read the current SOC from the sensor, even if it’s below battery_minimum_state_of_charge or above battery_maximum_state_of_charge

• If the initial SOC is out of bounds:

  • Use it as-is

  • Optionally log a warning

• Only apply battery_minimum_state_of_charge and battery_maximum_state_of_charge as constraints within the optimization horizon

• (Optional) Introduce a new setting, e.g.:
  use_real_soc_as_initial: true
  to allow opting out of this behavior if needed.

[tanelvakker]

As current SOC is passed during runtime, I would rather think this is a bug, not feature request

[davidusb-geek]

Why don't just change the SOC limits dynamically when you need it so?
I don't think that it is a good idea to implement SOC limits that are necessary to constraint the SOC to coherent values and then override those limits by taking passed SOC values as they are as you propose

[tbrasser]

Dayahead seems always to go from 100% to 100%

[scruysberghs]

passing an initial SoC outside the limits will result in an infeasible result. That is why initial is movid to the closed limit It would make more sense to change your min battery soc when you drop below. Same goes for max off course

[martinarva]

Why don't just change the SOC limits dynamically when you need it so?
I don't think that it is a good idea to implement SOC limits that are necessary to constraint the SOC to coherent values and then override those limits by taking passed SOC values as they are as you propose

Thanks for the reply! I think the key problem is that SOC limits and initial SOC are being treated as the same thing, when in practice they serve different purposes:

• SOC limits (battery_minimum_state_of_charge, battery_maximum_state_of_charge) define the allowed operating range during the forecast horizon.
• Initial SOC should simply be the real SOC reported by the battery.

Right now, if my SOC is at 5%, EMHASS assumes 30%.
If I follow your suggestion and dynamically change the SOC limits to 5–80%, then EMHASS starts planning around 5% as if it’s a valid lower limit. That breaks my intent, because:

1. I actually want optimization between 30–80%, not starting from 5%.
2. With dynamic limits, I would have to wait until SOC naturally climbs back to 30% before setting the limit back to 30%, which means forecasts are misleading in the meantime.
3. This creates situations where the plan includes values that are not physically or operationally desired.

What I am requesting

The point of my request is to always use the real SOC as the starting point, but still constrain optimization between 30–80 going forward. That way:

• If SOC is 5%, the plan starts at 5% but immediately targets recovery into the 30–80 band.
• If SOC is 95%, the plan starts at 95% but immediately stays within 30–80 moving forward.

Why this matters

This distinction is important for use cases like:

• MFFR/FFR participation (SOC is intentionally moved outside of EMHASS’ band)
• Manual overrides
• Grid outages or emergency discharge

Without this, forecasts become disconnected from reality.

Suggested solution

Introduce an optional setting such as:

use_real_soc_as_initial: true

This would preserve current behavior for existing users, while allowing those of us with multi-controller setups to keep forecasts aligned with the actual SOC.

[martinarva]

passing an initial SoC outside the limits will result in an infeasible result. That is why initial is movid to the closed limit It would make more sense to change your min battery soc when you drop below. Same goes for max off course

not anymore. this was fixed in some recent versions. Now if real soc is < min soc, ehmass takes the min soc.

[scruysberghs]

"With dynamic limits, I would have to wait until SOC naturally climbs back to 30% before setting the limit back to 30%"

Just make a template sensor for minsoc "if SoC < 30 minsoc = soc else minsoc = 30" ?

"not anymore. this was fixed in some recent versions. Now if real soc is < min soc, ehmass takes the min soc"

That is actually what I said. EMHASS sets initial soc to fall within the limits to prevent infeasible results.

[scruysberghs]

"use_real_soc_as_initial: true" will give you infeasible results if it falls outside the allowed limits for the optimiser. That is why David patched this in the first place

[martinarva]

"With dynamic limits, I would have to wait until SOC naturally climbs back to 30% before setting the limit back to 30%"

Just make a template sensor for minsoc "if SoC < 30 minsoc = soc else minsoc = 30" ?

"not anymore. this was fixed in some recent versions. Now if real soc is < min soc, ehmass takes the min soc"

That is actually what I said. EMHASS sets initial soc to fall within the limits to prevent infeasible results.

What I’m asking for is not to remove or relax the SOC limits. Those should absolutely stay as constraints.

The difference is between initial condition and constraints going forward:
• If my real SOC = 5% and my limits are 30–80%, then the optimizer should:
• Start at 5% (reality)
• Enforce 30–80% for the future steps
• → Which means the very first action must be “charge toward 30%”

Right now EMHASS clips 5% up to 30% before optimization, so the plan acts as if the battery magically had more energy than it really does. That breaks the forecast baseline.

So I’m not asking EMHASS to optimize outside 30–80. I’m asking it to begin from the real SOC even if out of bounds, and then respect the constraints going forward.

⸻

Also worth noting: if I dynamically set the min SOC = real SOC when below 30%, then the optimizer will happily plan around that lower SOC (e.g. 5%) as if it were valid. That means the plan will continue to target 5% until SOC naturally rises above 30%, which is not the intended behavior.

[martinarva]

I did some coding and have some rough solution to overcome my needs., Here is a comparison of default, min soc hack and my solution.

Parameters:
init soc: 5%
min soc: 30%
max soc: 80%
final soc: 80%

Default emhass capping init soc to min soc. keep in mnd that the real soc is 5% not 30%, so realistically it does chanrge only to around 10% on this low price.

Using hack that set's the min soc to init soc, when it's under 30%. Same thing here, it only charges to around 10% and lets the soc down to 5% in the evening again.

My solution that accepts the init soc as it is ant tries to recover to min soc as soon as possible but uses low price hours for that. It uses the cheap hours and charges to arond min soc(30%) and then some more to cover the midday high prices and after that honors the 30% min soc in the evening.

How it works:
Let EMHASS read the real battery SOC even if it’s outside the configured minimum or maximum; don’t clamp it upfront.
Treat any missing energy (below the minimum) or excess (above the maximum) as “temporary slack” so the optimisation stays feasible from the true starting point.

Look at the electricity price forecast and pick the cheapest time slots where charging or discharging at full power would be enough to eliminate that slack.

Add a penalty to the optimiser’s objective whenever slack is still present during those cheap slots (and a smaller penalty for slightly more expensive nearby slots). Carrying slack in expensive hours has little or no penalty.

Keep the slack monotone and force it to zero by the end of the optimisation horizon, so the plan always finishes at the requested target SOC.

Result: the battery will quickly move back inside the allowed SOC band during the cheapest available hours, but it won’t be forced to buy energy during expensive periods unless there’s no alternative.

Im using these penalties to achieve this:

soc_primary_penalty_multiplier: factor applied to the energy price of the timesteps that are in the cheapest set big enough to cover the gap. A higher value means those slots incur a larger penalty for leaving slack, so the optimiser will almost always charge during them. Lower it if you want to give the solver more freedom to skip even the cheapest period.

soc_secondary_penalty_multiplier: factor for the “next best” slots just outside that primary set (i.e. prices within soc_penalty_price_margin of the threshold). These get a lighter penalty so they act as spillover hours if the primary ones can’t fully recover the deficit because of power or grid limits. Increase it to bias the optimiser toward filling the gap sooner; decrease it if you’re fine waiting longer.

soc_penalty_price_margin: how far above the primary price threshold we treat a timestep as “almost as cheap.” With margin = 0, only the exact primary set (and their assigned multiplier) gets penalised. Setting, for example, margin = 0.01 means any hour with price ≤ (threshold + 0.01) also receives the secondary penalty, giving the optimiser a slightly wider window of acceptable recovery slots.

As said it s a very rought first implementation and i'm coding with code x, so probably not very good quality, but first impressions are what i'm looking for. I continue testing and if any devs here find this approach interesting would be nice.

[scruysberghs]

You know you can run the mpc optimiser with a different horizon and a different target SoC?
What if you run the optimiser to get back to 30% in your desired timeframe and then switch back to your 30-80% optimiser and longer horizon? You can switch your battery control over from the results of one model to the other as you see fit.

To me it feels like you are trying to set rules in an mpc optimiser instead of using it for what it is intended.

[martinarva]

You know you can run the mpc optimiser with a different horizon and a different target SoC? What if you run the optimiser to get back to 30% in your desired timeframe and then switch back to your 30-80% optimiser and longer horizon? You can switch your battery control over from the results of one model to the other as you see fit.

To me it feels like you are trying to set rules in an mpc optimiser instead of using it for what it is intended.

Clarifying My Intent

Yes, you're right that I could run a separate MPC instance to recover to 30% and then switch to a 30–80% optimization. I actually experimented with this — and I’ve got a version running now where EMHASS “wants” to fill the gap between 5–30% first in the most cost-effective way before continuing. So far, it sort of works, but I’m still monitoring the behavior and I’m definitely not confident in the long-term viability of the hack.

But fundamentally, I think this is a case where the optimizer should be able to do it all in one run, which is exactly what MPC is designed for.

I’m not trying to “set rules inside an MPC.”
I’m trying to give it an accurate initial condition and let it find the optimal full-horizon strategy — including any recovery behavior that’s needed.

If the SOC is 5%, and my constraints are 30–80%, the best solution may not be to jump straight to 30% and then start optimizing — the best strategy might be to gradually charge up over a few hours, depending on prices, PV forecast, and load. But EMHASS can’t find that strategy if it's fed a clipped initial value of 30% instead of the real 5%.

So yes — it’s technically possible to build a manual pre-step or dynamic limit logic, but:

• It introduces complexity and fragility.
• It splits the problem in a way that loses global optimality.
• It’s solving with two disconnected plans instead of a cohesive one.

MPC optimizers are absolutely capable of:

1. Starting from a state outside constraints, and
2. Planning a return into the constrained space over time,
   as long as the constraints are applied from t+1 onward.

That’s exactly what I’m proposing:
→ Start from reality. Constrain the plan. Let EMHASS figure out the best way forward.