ESS Minimum SoC limitation

First, the scenario: With loadshedding upon us again I have set my Minimum SoC in the ESS menu to 40%. This leaves me enough battery reserve to endure the worst overnight loadshedding I’ve experienced so far.

The issue I have is that the Multi will always recharge the batteries from the grid if the SoC falls below 40%. This costs me money, often unnecessarily, because tomorrow the sun will recharge my batteries for free. I want it to only recharge from the grid once the battery level falls critically low, say 15% SoC.

Effectively, I want ESS to manage my battery SoC levels as follows:

  • Below 15% SoC: Do not discharge the batteries if the grid is available. Charge the batteries from the grid, if available.
  • Between 15% and 40% SoC: Do not discharge the batteries if the grid is available. Do not recharge from the grid.
  • Above 40% SoC: Freely discharge the batteries regardless of whether the grid is available or not.

This doesn’t seem possible without resorting to hackery, or am I missing something? @plonkster Consider this a feature request :smile:.

Yeah, I want this myself. An option to disable “Auto recharge”. Which is easy to do. Or an option to have a different threshold for activating auto-recharge (which is more work, and will probably cause confusion for some users).

I’m generally so swamped with other cr*p that I can hardly write good specs for features like this. The best would actually be to mention it on the Community site, gather a heap of "me too!"s (not to be confused with that other one, sorry), and then let it roll from there :slight_smile:

Done:
https://community.victronenergy.com/questions/118789/ess-minimum-soc-limitation.html

Please direct some of those "me too!"s to the post.

What happens if the SOC is 40% @ 15:00 but the charging time schedule has been set to only charge from 20:00 - 23:00?

https://www.victronenergy.com/media/pg/Energy_Storage_System/en/configuration.html#UUID-eea56ee5-efe2-0fce-ab6f-ba51656dfb45

Doesn’t this solve this problem?

A bit off topic perhaps, but one thing I do not like about the scheduled charging functionality is that it blocks discharge regardless of SoC, e.g. If scheduled charging is active with a target SoC of 40% and the current SoC is 100% the Multi will draw power from the grid instead of the battery.

Is there a reason why it behaves like this?

Yes. Because we did not want to duplicate the entire ESS-functionality into scheduled charging (on a practical level), but also… a system that shows “Sched charge” on the screen, but is currently doing self-consumption will be hugely confusing.

Also, the basic philosophy is that the system is ALWAYS doing self-consumption unless the battery is too low, so scheduled charging had to fit into that philosophy. If we’re not doing self-consumption (which we we are not, we are charging), then we cannot discharge.

In the beginning it didn’t even allow PV to be used for loads. As you might imagine, when the PV is DC-coupled, that involves the whole exercise of calculating how much AC you can make if you have this much DC, without overestimating (and discharging the battery) but also not underestimating too much. And the present solution was simply the simplest one.

Simple means less chance of bugs. And support questions.

That is not to say everything is perfect… just that it is not as simple as just allowing it to discharge while in scheduled charging. A whole rethink of the philosophy is required, so that it remains consistent, simple, and doesn’t cause support questions… :slight_smile:

Also, did I mention support questions?

Also, scheduled charging was meant for people with TOU tariffs who would be charging in the wee hours of the morning. Who the heck charges during sunlight hours… or so we thought…

Your users always find use for your stuff beyond what you imagined :slight_smile:

Although, admittedly, the feature where it does not discharge was also somewhat deliberate. Because people use that to prevent discharge during the early evening peak…

1 Like

Just set the SOC in scheduled charging and it stops at a certain level.

Node red could do this with a few rules as well but that’s another discussion/thread.

image

It also doesn’t allow discharge regardless of the current SoC, so not useable for what I want to achieve.

Would it be worthwhile to file a feature request for a Allow discharge down to 'Stop on SOC’ option in scheduled charging, or will that not gain any traction? I suppose this must have been asked before…

Perhaps I should rephrase the original feature request, and rather ask for a Grid charging maximum SoC option in ESS. I can set that to 15%, and if the SoC is above 15% it will never use the grid to charge.

This is fairly easy to do with Home Assistant. You set two SoCs. A minimum SoC for discharge and an “ESS min SoC”. The minimum SoC for discharge, say 40%, would trigger an automation to put the inverter limit to 0 and the ESS min SoC would be the 20%, say, after which you want to have anything recharge your batteries.

This is on my to do list…

1 Like

Good suggestion. If the feature request doesn’t get any traction I’m going to have to look into doing something like this.

I’ve just realised that there might be an even better solution, one that will ensure that you use the minimum of grid power, except when the battery is critically low. Using your example of 20% and 40% SoC:

Above 40%:
Solar - prioritizes loads, excess to battery
Battery - discharge allowed in order to carry loads
Grid charging - off

Between 20% and 40%:
Solar - prioritizes loads, excess to battery
Battery - discharge not allowed, unless grid is not available
Grid charging - off

Less than 20%:
Solar - prioritizes charging battery
Battery - discharge not allowed, unless grid is not available
Grid charging - on

Perhaps the setting could be called a “Power Failure Margin” in the ESS menu. So if I set that to +20%, and the “Minimum SoC” to 20%, then it’ll give me the desired middle band of 20% to 40%. Below 20% and above 40% behave as they would currently, without this setting.

If I understand your three scenarios correctly, implementing my suggestion will achieve it exactly (after the following addition):

Between 20% and 40% dynamically limit the inverter capacity to the PV generated. I do it currently. Well, a little bit more. I have two inputs, battery discharge cap before sunset, and battery discharge cap after sunset (typically they can be the same).

My Home Assistant automation then sets the inverter limit equal to the PV being generated plus the applicable cap. So effectively it limits the discharge from the batteries to the specified cap but still use all the available PV.

I do this to prevent the batteries from being discharged too quickly.

So all I’ll need to do is to switch to a 0 discharge from batteries cap when the SoC drops below 40% while keeping the ESS min SoC at 20%.

The reason I have different caps for night time and day time is because in the day I am typically happy with a higher discharge rate (because it is likely that they’ll be recharged again) but at night I might want it lower to get me through the night without powering the aircon, for example, when my wife can’t sleep. So the nighttime discharge rate is set to be enough to power my essentials but not my non-essentials so that if loadshedding kicks in unexpectedly, I still know I’ll be safe.

2 Likes

Ah yes, that’ll do what I want. First prize would still be if I can get Victron to implement it for me though :slight_smile: I’m a total newbie when it comes to the home automation stuff.

18% SOC - dropping - with clouds.:man_facepalming:

I’m quite far down the track. Inverter max watts are set to match the panel production to not use batteries on bad weather days. Still needs a wee bit of tuning.

Just need to remember to up the Min SOC in the Cronjob when there is LS and no $(%*#& sun!

The SOC increase is also controlled by HA, for evening use, spreading the loads over 24h, less strain on the batts.

The ideal would be to have this under ESS control.

1 Like

Indeed!

A “no battery self-consumption below X% SoC” setting.

That is of course also an answer, and one of the reasons why the “large image” includes nodejs. For those special cases, you can then tell people to roll their own.