MP II: Safety Timeout (low voltage) when comms lost: Make Optional, default to internal voltage

DIY
, , , ,
1

System: MP II 48/5000, Cerbo GX, some MPPTs, JK Inverter BMS connected via CAN.

Scenario: I will replace the MPII 48/5000 with a 48/6k5 this week. To minimize downtime I decided to power up the new 6k5 unit from a bench power supply and update firmware and VE.Configure before swapping it in.

The exact opposite of minimizing downtime happened: quite soon I was sitting in the dark…

I don’t have a MK3 cable, so I decided to plug the new 6k5 unit into the Cerbo to do a Remote VE.Configure. To do that I had to unplug the existing 5000. The first part went well, the new 6k5 was recognised instantly. But after a couple of minutes the old 5000 shut down with a “low voltage” alert.

The attached seems to be the explanation. Apparently, after losing VE.Bus communication, the 5000 decided not to use its own voltage sensor and carry on, but to shut down instead “for safety reasons”.

I get that this might be a good idea in case an installer didn’t set up the parameters properly and the default parameters don’t match the battery. But I did set everything up properly and the parameters would have been fine to keep inverting & charging indefintely.

Feature request: allow to opt out from this forced (and in my case totally unnecessary and major nuisance) shutdown.

Add a tick-box “In case of communication loss default back to internal voltage sensor and battery parameters, do not shut down”. Default the tick-box to “off” to not change existing behaviour. When ticking the box, prompt the installer to set up the internal battery parameters via VE.Configure and give a warning to ensure they know the risk they are taking if they don’t do that.

While my scenario (being too cheap to buy an MK3 cable when I have a fully functional Cerbo that can do the job) might be rare, the same issue would happen if the Cerbo hardware fails, or it hangs during a software update. By adding a Cerbo I did want to add more flexibility, precision and communication. I did not want to introduce an additional point of failure that lets me sit in the dark when all the critical hardware (Multiplus II, Battery, MPPTs) is fully functional.

Thanks for considering this :slight_smile:

Cheers,

Peter

image
image995×455 63.4 KB

2

Because it is a safety feature, i don’t agree with the feature request.

Because the BMS exists for a reason. (Actually many)

But there is a workaround.
To work like this with no bms comms interfering, you remove it in dvcc first so the system does not shut down. Restart the ve bus afterwards.

In fact you can still leave it like this if you want monitoring but not control by the bms. Not that I am recommending it. I have seen too many lithium fires to agree with overriding safety.

3

I can’t quite agree on that, because there is no reduction in safety, as long as the voltages inside the MPII are set correctly. And there are plenty of other settings already where wrong settings by an unqualified person can actually compromise safety. It’s not like everything is completely foolproof and this request would open up new ways for disaster.

In my view the benefit of putting a BMS in charge of setting voltages - as long as communication works - is that it will work smoother and is more convenient. Not that it will work safer in that respect.

I.e. the BMS knows when it is done balancing and the requested voltage can be dropped to down to float accordingly. Leaving that to a Multiplus will still work safely, but will either keep voltage high (at absorption level) for too long or it will interrupt balancing. And it is harder to change, requiring VE.Configure again, and a reboot with loss of power for any tiny change, while the BMS can be set up with a smartphone app…

Or DVCC: by watching SOC and voltage, it is easy to reduce DVCC current before the battery actually hits 100%, avoiding the overshoot I have seen before that takes the battery voltage into ‘more stressful’ territory.

In any case, ultimately the BMS is in charge of safety, it can always disconnect the battery cells from the output. :slight_smile:

4

The problem isn’t a problem until there is a problem.

Its when cells aren’t balancing and you have runaways or the bms fails or one that is plummeting faster than others etc.

The total pack voltage is often never the issue.

In any case the solution already exists.
Remove the bms control in DVCC.

Screenshot_2026-08-24-07-48-32-034_com.duckduckgo.mobile.android-edit
Screenshot_2026-08-24-07-48-32-034_com.duckduckgo.mobile.android-edit1080×629 67.3 KB

Screenshot_2026-08-24-07-48-14-819_com.duckduckgo.mobile.android-edit
Screenshot_2026-08-24-07-48-14-819_com.duckduckgo.mobile.android-edit1080×631 119 KB

I and many installers and manufacturers prefer that when comms are lost the system shuts down.
When you have a JK bms and have taken the responsibility for your self, that is a different matter.

5

Yes, and still: the question is whether these scenarios would actually trigger the protection and whether it would help. I don’t think so.

If a BMS fails in its job to arrest a runaway cell, why would it lose communication, allowing the Multiplus to shut down? If it is a catastrophic event, say one that causes the BMS to melt, the 2 minutes it takes for the Multiplus to shut down are way too long, the fire will long be out of control.

Your suggestion to turn off features creates exactly the same situation that you told me is dangerous.

But it also removes any benefit from having a Cerbo. So we are at the point: I can already make the system “dangerous” - by your standards, not mine. But I can’t just make it “dangerous” without losing any benefit the Cerbo offers.

That’s why it is not a solution. :slight_smile:

My request aims to have those useful features used as long as they are available. And default back to the situation we would have without them, when they become unavailable. Be it an unplugged cable or a broken Cerbo.

6

So how would a non sentient item know when the comms disconnect is safe one and when it is not?

This is the problem.

If you have chosen now to disconnect it, you are basically signing a t&c saying you know the risk and are prepared to continue

7

Yes, if I follow the screenshots you’ve posted, I’m doing exactly that too.

Except the result is worse: I would cap any chance for the BMS or the Cerbo to have any say ever. Even if communication actually works.

What I am hoping to get is: if communication works, the BMS and Cerbo DVCC sets the rules. That will be 99% of the time.

The 1% of time that communication is down: go back to what the system would be like if there is no communication:
BMS controlls its cells and disconnects on too low or too high. Multiplus delivers based on pack voltage and current, as per the programmed parameters and still shuts down if actually measured voltage is outside of safe parameters.

I can come up with any number of scenarios where a sudden loss of AC power can cause damage to equipment and people. That’s something you didn’t consider in your scenarios.

10

What I should mention, and I’ve tested this:

After the MPII shuts down, if I turn it off by the little physical switch on the bottom, wait for a few seconds, then turn it back on by switch, it starts right back up and operates based on the parameters configured with VE.Configure. Then later, when communication is restored, it will happily work based on VE.CAN again. No additional reboot required.

So yes, there is an override mechanism that could be used if a Cerbo breaks or is bricked during an update. One that allows anyone, qualified or not, to make that decision. No software programming access required.

But first the power goes off. And if no one is home to toggle that switch, freezers defrost, pumps stop running, …

11

In this % is also the times when for safety you don’t want the system to be powered.

So a 1% use case and then doesn’t make sense to pursue

If that critical should have a fallback system designed for preventing loss of life. I do know of these types have installed systems with this in design.
But then the opposite is also true where comms means loss of life and property and the system should be powered down.

As an FYI on this loss of lofe and critical scenario you mention read the warranty document for Victron

12

No, I want to be powered.

In that 1% of the time when communication stops: In 99% of the cases when communication is interrupted the system would perform just fine when it falls back the hard-coded settings. In the 1% of cases where communication is interrupted because of a genuine fault, 99% of those will be handled by BMS or by the hard-coded settings just fine. In the 1% of cases where some serious fault has caused the communication to stop, well, most of the time the 2 minute delay for the MPII to shut down will let the bad thing happen anyway.

All those are relative probabilities. Multiply them up. You’ll end up with a small fraction of well below 1 in 1 million that the 2-minute shutdown will make a positive difference.

On the other hand you’ll end up with 1 in 100 minus that 1 in 1 million that the forced shutdown causes at least an inconvenience, and at worst something equally bad will happen due to a completely unnecessary loss of AC power.

I’d like to be able to make that choice myself, without throwing away the benefits of having a Cerbo and BMS communication brings most of the time.

Funny that. People install UPS to get through power outages that happen a lot less frequently than that. Of course 1% scenarios are worth pursuing. You found it worth pursuing a 1 in 1 million scenario, only because you’ve decided it is more important to your needs. That’s fine. I’m not asking Victron to remove the default behaviour. I just ask them to allow me to turn this part off without having to dump DVCC and BMS Can to make it happen…

13

How many people, especially DIYers, “install the system properly” and program the devices to use the fallback mode??

Very few.

But if incidents started occurring one after another, people would call it a “crap system” and the company could go out of business in no time, even if the problem was the user’s fault.

That’s why it makes sense to manually disable and re-enable certain functions for situations like these.

14

And this scanario and other interesting/unprofessional methods are the 100% that need to be protected against.

At all times with no bms comms loss issues - switch off dvcc. The communication for monitoring still remains available. Unfortunately with a non sentient item it cannot know when this situation is a bad thing or a ‘nothing to be bothered about’ thing.

So it is an all of nothing choice from this angle. All other angles a system designer and professional installer (who would hopefully be the one handling the more critical installation and scenarios you mention) can provision for.

15

Also worth mentioning that the system cannot just switch from managed to unmanaged, turning dvcc off on its own won’t fix the issue. The whole system needs to be cycled after the change.

16

Yeah. So its a conscious change as it transfers responsibility and liability. Its not as simple as xxx. Victron aren’t the only one that have this as a safety feature, quite a few brands cannot just lose comms and be ok. They all class it as an even that should be attended to, the system shuts down

17

Indeed, the risks are too great. We’ve seen many systems that someone has not properly programmed the multi as the battery “sorts it all out”.
Now default the system to unfriendly parameters when comms is lost, then sit back and wait for the insurance claim :slight_smile:

18

Safety is inconvenient…

19

You all keep ignoring one very simple fact: the first thing a “default” home owner will do when they are in the dark, is what they were told with every single other device that plays up: they will turn it off at the switch and turn it back on.

And then the MPII actually starts up again. And it runs on whatever internal settings it has, creating the exact same situation you all want to avoid.

No, there is absolutely no point for the the MPII to turn itself off when comms are lost.

But there is quite an important point: installers who want a foolproof system have to ensure that each MPPT and each inverter charger is properly programmed to start with. As a fallback. That fallback then works whether someone turns off and back on the switch, or whether it automatically (based on a new setting that is requested here) stays connected in the first place.

20

We’re just going to have to disagree about that. It is unlikely to change until such a time the GX, inverters and mppts become sentient and can make an informed decision about what to do.
Comms loss could be something minor, it could also be something severe, occurring at any number of stages of charge/discharge.
Until then, the user will need to make the necessary manual changes.

Nothing us community members and moderators can do about product engineering anyway.
I would suggest that in an organisation of pretty smart engineers and developers, they would not have made a random decision to implement the failsafe this way if there was a better way of doing it.

21

The system doesn’t need to be sentient, it is sufficient if the person ticking the box is, and makes an informed decision to change one default behavior to another.

What is quite telling is that you too keep ignoring the fact that anyone, with the simple flick of a switch, can override the programming. Making it a flick of the switch after the power went off just combines the nuisance of not having power in the first place with the same outcome.