Multiplus II remains disconnected after grid fail

DIY
, , ,
1

Hello everyone,

I have a new system, installed 2 months ago: Multiplus II 6k5, single phase + AC Coupled Huawei + one Dyness Battery. Everything works fine with one glitch.

The problem is that, after a grid fail the grid remains disconnected indefinitely.

So I am basically draining my battery and staring at the sun :sun:

I am reading the parameters via ModBusTCP from the Victron and plotting charts in Grafana. From these charts I can tell that, after the grid comes back:

  • The voltages are correct at the grid
  • The frequency is correct at the grid, a solid 50.1 Hz
  • Victron continues sending frequency signals to the Huawei on the AC out periodically. I see this as spikes in my charts at some 10-20 seconds interval
    • This is in line with the manual that says, that the frequency shift cannot be maintained when the grid is reconnected because the Multiplus must use the same frequency
  • The grid is NEVER connected. I have waited one hour, two hours and nothing happens

I have found this topic Stuck on Disconnected & Discharging even w/ Grid Meter Showing Power where the user said that they have reverted to a previous version of the GX Firmware and that fixed the issue.

I don’t want to go back to another firmware because I have just bought my Multiplus II and installed the latest firmware.

I have access to the SSH and have / can make traces via dbus-spy and dbus-monitor. From those traces I can see that the grid is “available”, but there is something that periodically tells “ignore the grid”. That something is one of the agents.

I only have a single agent, an ESS through which I configured the AC coupled inverter (the Huawei which holds the solar panels).

I have exhausted all Gen Ai out there looking for a way to debug this thing, so I am reaching out to the community and the the Victron staff.

I repeat: This is repeatable behaviour (pun not intended). I can trigger it, literally with a switch, so I think this is a golden opportunity to find the bug in the ESS / GX / wherever this comes from.

The only way I have found to get out of this “stuck” situation is to go in the HTML interface of the Multiplus and set the mode to “keep batteries charged”. This seems to snap the Multiplus from its dreaming and forces a reconnection to the grid. Once that happens, I switch back to my “Optimized without battery life” and the system is back to normal. But … I cannot be looking at the charts constantly waiting for the fail to happen.

In short:

a) how can I fix this?

b) Victron staff: I am available with any information. Let’s fix this bug.

MultiPlus-II 48/6k5/100-50
FirmwareBuild 3.79 20260826152305
VE.Bus version: 2602560

2

Hi, welcome.

What grid code are you using?
Do you have any automations or assistants loaded?
Do you use any energy/grid meters?

Outside of automations, the decision to connect or disconnect is controlled by the multi and grid code. Very little change has happened to affect this.

The GX doesn’t usually play a part with this - have you tried to disconnect the vebus cable from the GX when you experience the issue?
Does choosing redetect from the GX multiplus menu help?

As a new member, just a reminder to brush up on our guidelines to set the correct expectation:

3

Thanks for the quick reaction!!

Country code: Romania

The GX is integrated in the Multiplus, so no cables there.

However, I did do a reboot of the GX (from the SSH prompt) and that did .. nothing.

I don’t have any other fancy tricks. Only one agent which I configured with the VE Configure 3 and loaded from VRM on the Multiplus.

“Outside of automations, the decision to connect or disconnect is controlled by the multi and grid code. Very little change has happened to affect this.” Yeah, that is what makes me thing that there is some bug somewhere.

It is like: the Multiplus is “waiting” for something to happen, and that “something” never comes.

Oh, and no, no multi-meters, just what the Multiplus itself measures.

4

There should be an internal cable like all GX’s have. Not seen the 4.5 or 6.5 myself, but they should be the same. More of a mission to disconnect, certainly not while it is running.

Please share screenshots of your assistants that are loaded or attach your vrm remote configuration file here. Thanks

5

Try to disconnect the AC OUT (remove the wires).
Not sure about the Romania grid code but with the German grid code a grounding fault at the AC OUT can cause such a behavior.

6

Hi Matthias,

I am not sure I understand. I have a switch on the AC Out, so I could try this, but … how would this solve the bug in the ESS? Like I said, this issue is repeatable and comes back even after I have switched off the Multiplus.

Or, do you mean that the grounding issue could cause this and I should therefore … look for it? In which case, I would appreciate more information. What should I measure?

7

Since this is reproducible, disconnect AC out as a test. Try reproduce the issue again.
If it works and accepts grid, then you likely have an issue as suggested and would need to trace your wiring out.

8

I see. I will do a test tomorrow morning like this:

  1. disconnect the grid briefly.
  2. Wait 15 minutes to be sure that the 900 seconds have elapse as configured in the VE Configure 3
  3. After that, if the grid is not connected, disconnect the AC Out for a minute or two
  4. Wait some more to see if the grid now (either when the AC Out is disconnected, or afterwards)

I will post the results.

9

e.g. If there is a N - PE connection at the AC OUT somewhere the MultiPlus must not connect to the grid.
At last that is the behavior in combination with the German grid code, I don’t know the regulations in Romania.

To test that you have to disconnect the AC OUT completely, not just with a switch, you need to disconnect L, N and PE from the AC OUT terminals.

10

Well, I did the test just now and … after 15 minutes the system came back up. Victron stopped sending the frequency shift messages and the Huawei started generating.

After 5 tests in the past where the system never came back … now it did.

There was no change in the parameters, so I have no idea what caused this.

I will keep an eye on the system and, when I get the chance, will measure the N-PE if it starts acting up again.

Thanks for your quick answers and suggestions. I’ll come back if I have anything new to report.

11

Aaaand, today it did NOT come up after about one hour.

I started a trace with (trace file is attached):

dbus-monitor --system "type='signal'" > /tmp/trace.txt

and I asked Claude.ai to have a look. Below is what it said, maybe this makes sense to someone.
I note the same thing as I did previously: the disconnection seems to be “ordered” by an agent.
If there was any issue with the P-NE connection, I would expect it to “never” connect. But it does connect.
It connected soon after I did my trace. I did not touch any parameters, so I don’t know if this is only a coincidence.
The battery had only reached 99% (for 30 minutes when it reconnected) as there was little demand.

---- AI output when I asked it to investigate the trace file -----

There’s one clear pattern in the trace, though it doesn’t fully explain the problem on its own. Your capture covers about 2.5 minutes of dbus-monitor output.

1. An Assistant keeps forcing “Ignore AC input” on and off

About every 28 seconds the VE.Bus service publishes the same sequence:

t=16.1s  IgnoreAcIn1 = 1, IgnoreAcIn1AssistantsVs = 1, MainsPllLocked = 0
t=20.0s  IgnoreAcIn1 = 0, IgnoreAcIn1AssistantsVs = 0
t=21.3s  MainsPllLocked = 1

It repeats at 43.8 s, 71.9 s, 99.8 s and 128.0 s. The ignore lasts about 4 seconds each time. The IgnoreAcIn1AssistantsVs = 1 flag means this comes from an Assistant inside the MultiPlus, not from the GX device, a digital input or the ESS menu. During each ignore window the unit drops its sync to the grid (PLL unlocked) and only re-locks about 1.2 s after the ignore is released. In RawFlags0 you can see the same thing as bits 8 and 20 switching on (0x11040000 → 0x11140100).

A healthy unit waiting to reconnect shouldn’t do this, so I’d treat it as the main suspect.

2. The switchover countdown expires but doesn’t lead to a connection

SwitchoverInfo/Delay counts down from 57 to 0. The periodic ignores do not reset it. At t=56.9 s it reaches 0, at a moment when the AC input isn’t being ignored and the PLL is locked. It doesn’t close the input relay. Instead it jumps to 127 and starts counting down again, which looks like a longer back-off. So when the timer ran out, some reconnection condition was still not met. The trace doesn’t show which one.

3. Things that look fine

The grid voltage is stable at 242.6–245.5 V, well inside normal limits. The battery is at about 53.3 V and discharging lightly (about 170

trace.zip (46.0 KB)

W load). Max discharge power is about 9.5 kW, so there’s no BMS block. TimeOnInverter is about 7,450 s, so it has actually been off-grid for roughly 2 hours.

12

After some more talking to the Ai, I noticed the “High frequency reconnect value” parameter (see attached picture) which was set to 50.05

However, my grid is constantly (day and night) at 50.1, so I thought maybe this is preventing the re-connection. I have now changed that parameter to 50.2 (which is still well below what the regulations are for Romania). This does not really add up, as … then, the inverter should “never” connect, but … until it works, I am willing to test everything.

The PVs started producing immediately after 15 minutes when I uploaded the configuration file … so I can only hope that this was what was tripping the system.

That’s enough fiddling for today. Hope this was the proper fix.

Changed setting
Changed setting626×490 18.1 KB

13

I have just found the time today to do another test (switched off the grid for a few seconds) and the panels started producing after 15 minutes as configured. This would be the 3rd time that the grid was reconnected properly, so I conclude that it was the 50.05 parameter that was bothering the Multiplus in this situation.

I will mark this as the solution and consider this topic closed.