MultiPlus II Settings & Optimisation

I have a MultiPlus II 48/5000 with 10kWh Battery and 12x550W PV

Everything is on essential loads.

My geyser currently has a 4kW element (it’s being replaced soon), so it can’t be run off the Inverter.

With ESS set to Optimized (with BatteryLife) and SoC 100% the PV charges the Battery.
When I turn on the Geyser, it gets powered from the Grid.
To prevent an overload on the Inverter (and batteries draining) when the Grid fails, I have a Smart Isolator on the Geyser and an Automation in Home Assistant that turns off the Geyser Isolator when the Grid fails.

All worked as expected so far, however, when the Battery is fully charged to 100%, I expect the PV to start supplying the AC Loads (to 4000W max) and the grid supplementing the excess. This doesn’t seem to work the way I expected. Instead, the grid still supplies the majority with PV only supplementing a little bit as shown in the screenshot.

So I changed SoC to 30% and suddenly PV supplies the AC Loads, but the Grid doesn’t supply much at all. Why is that?

The inverter also hasn’t overloaded even thought AC Loads are 4313W, which I thought would overload the inverter.

What I’m trying to figure out is how to mix this…
i.e. the Inverter to supply 4000W from available PV to the AC Loads while the remaining PV goes to charge the Battery and the excess 313W AC Loads is powered from the Grid.

I’m still figuring this out…will do some more testing (and figure out my train of throught) and post an update later.

Known issue. Don’t do that. Rather use “Keep Batteries Charged”, which is optimised to do it correctly. Using 100% with Optimised mode is known to be less than… uuuh… optimal.

Noted, thanks!
The reason I did this was that I think I tried Keep Batteries Charged a few days ago and it seemed to charge the batteries from the Grid instead of PV. Let me try it again tomorrow.

On another note, I also have this thing where the Inverter keeps flipping between Ext. Control and Discharging and the Battery between Charging, Idle, Discharging (99%,100%,99% etc.).

Video here

Battery issue that I discovered this week as Glodina explained to you… the South African distributor as well as the manufacturers are already looking into the issue. I already informed @plonkster abut the issue as well as I first blamed ess…


When you say keep battery charged, Victron will throw everything it has (grid included) at the battery to get it to the level (100%) that you ask it to maintain.

Oh, ok, cool. I knew you were looking into it but don’t think I heard back from Glodina about this (other than you’re investigating), so wasn’t aware that it’s been escalated to distributors and manufacturers. Thanks for the update.

Back to ESS

I try to avoid Keep Batteries Charged, because I don’t want to use the grid for that when there is plenty of sun available. I’ll use it when there is no sun.

Last night I noticed that Optimize with Battery Life has increased the Active SoC to 80%, so even though I have plenty of battery, I started pulling from the grid.
My understanding is that Battery Life increases Active SoC by 5% when the battery did not reach 100% in a day. This is to help het the battery to a full charge to preserve it’s life. That’s all fine and well, except that my battery has reached 100% by 11:00 every day so far so the 80% is odd to me. (Maybe it’s related to the other issue, who knows :man_shrugging:)

So I switched to Optimize without Battery Life (with Min SoC at 30%) to override the Active SoC and allow the battery to be used instead of the Grid (my nighttime AC Loads are typically below 500W, so plenty to go from 80% to 30%)

hat still bugs with ESS on Optimize without Battery Life and Min SoC at 30% is that I can’t prioritise Battery charging without hacking it with Min SoC to 100%.

Example (I added descriptions to the screenshots when you hover over them)
Overnight the battery discharged from 80% to 30%.
This morning, the battery started charging from PV and reached 33%.

I then turned on the Geyser, which started discharging the battery down to 30% again.

When the Battery hit 30% the loads switched over to the Grid and PV charged Battery.

As the geyser’s thermostat switches the element off and on again, we go back and forth between these two states. So the battery is discharged again until it reaches 30%, then we go back to the Grid.

If I now set the Min SoC to 100% (like I did yesterday), it forces AC Loads (geyser) to the Grid and charges the battery using PV all the way from 30% to 100%.

If I use Keep Batteries Charged (as @plonkster recommended), it uses both PV and the Grid to get the batteries full quicker. This is expected, but not desirable, since the sun can do the job just fine today and I don’t want to use the Grid to charge my battery.

Like I said, this is a bit of a hack. It would be nice if there was an option to prioritise battery charging (from PV, not Grid), that would temporarily prevent discharging the battery (this back and forth to “assist the grid” when it’s 33% and charge when it’s 30%) until it reaches 100% and therefore improving Battery Life.

Does this make sense or am I missing something?

It sounds to me that your site is the one Jaco told me about that has a battery saying “go… no no stop… go… no no stop…”. That means I should not get involved before that’s resolved. Too many cooks in the kitchen that way.

There is a deep technical reason why it does that not always work in optimised mode with minsoc=100%, related to how the algorithm works. If the battery is at 100%, discharge is allowed. If the battery is at 99%, discharge is NOT allowed. SOC is an estimate. So you end up with something that oscillates between 99% and 100%, and a battery (even a lithium battery) at 99% isn’t taking full charge), severely affecting PV production. The Keep Charged setup is optimised to allow the MPPTs to run full speed while holding the battery at 100%.

But that is all academic, it sounds as if Jaco has the situation in hand.

It sounds to me that your site is the one Jaco told me about that has a battery saying “go… no no stop… go… no no stop…”.

Indeed. Ok. Let’s fix one problem at a time. Perhaps the one is a symptom of the other. Will wait and see.

There is a deep technical reason why it does that not always work in optimised mode with minsoc=100%, related to how the algorithm works.

Is the algorithms code available somewhere? Would be nice to peruse it to get a better understanding of it all.

I guess my question (to start with) would be why are you setting the minimum SoC to 100%? It sounds like you’re happy to discharge down to 30%, so I’m just curious why you need it to be 100% sometimes.

The rest of the issues still seems valid, but sounds like that’s potentially due to a battery related issue, so I’d wait for that outcome. Like plonkster said 100% minimum SoC with ESS isn’t recommended if there’s PV involved, so I’d use 95% at most (or keep batteries charged) if it’s really needed.

I also saw this on my system. I think the first time I switched on BatteryLife it had an 80% Active SoC if I remember correctly (used it without PV for a long time).

Not sure if this will help you, but maybe try switching on BatteryLife again and drop the Active SoC down to what you want to start with and see if that works for you? BatteryLife works fine after that and increases the Active SoC if 100% isn’t reached, but the Active SoC is hit.

I can’t remember if it only relates to scheduled charge or the whole of ESS, but also make sure that you’re running firmware v3.00 on your GX.

The big secret of Optimize with battery life is to not make frequent changes. Set it and let the Algorithm do its job over the next few days. Changes too often just messes around with the operation and defaults back to 80% active SOC.


It will, and will only start using battery again once the SOC reaches 8% higher than Minimum SOC.

1 Like

I am a bit upset about this issue. Been using these batteries for quite some time without any major issues, now we have installed 2 systems this week with the same batteries and are experiencing the same issue on both when paired with Victron. Not good when you as installer promotes a product that you trust and then it lets you down.

I am pretty convinced its only a firmware issue… but lets see what their explanation is.

Correct, I’m happy to discharge to 30% at night, but in the morning when there’s plenty of sun, my first priority is to charging batteries back to 100% (only using PV). Once that’s done I can start running everything else (pool pump, irrigation etc.) from PV.

I know I can just run things at the same time and the battery will charge at a slower rate, but I’d like to have a full battery again (from PV) ASAP. Plus, as I mentioned earlier, when I don’t have the SoC at 100%, and loads increase to higher than the available PV, the battery starts draining again. So my other thinking was that it’s might be better for the battery to have a longer continuous charge and discharge cycle (100% to 30% and back to 100%) rather than short cycles (100% to 30% to 33% to 30% to 33% to 30% repeatedly until a) AC Load is either low enough or b) PV is high enough to supply both AC Load and Charge the battery continuously).

I’ll wait for the outcome of that other issue.

Thanks, will check it out.

Yeah, I’m just a little impatient with the algorithm. It will take around 10 days to get from 80% to 30% if it only decreased 5% every day that it reaches 100%. That’s a lot (quick poor math says 40-50kWh) of stored energy that’s coming from the Grid while the algorithm adjusts. I’ll try the post that @fredhen pointed me to.

You can SSH in to the GX and change the minimum SOC there.

Yeah, I was also thinking it must be a firmware things. What firmware versions are your other sites running?

Speaking of firmware updates, I noticed there’s an MK2 firmware update (the onboard MK3-controller, version v216) which according to the changelog needs to be manually initiated, because there’s a 1-10% chance of a short system outage (30s max)


Are the other older sites also running the latest firmware?

It came out with v2.91 – September 28th 2022 and updated to the latest v3.00 – May 30th 2023.
I suppose we could downgrade to v2.94 – April 13th 2023 (or the version that your other sites run) to see if it resolves the issue?