Multiplus2 Low Voltage Alarm

Hello

I have set up a three-phase system with 3x MultiPlus 5000 units.

Unfortunately, I keep having the problem that a Low Voltage alarm is sporadically displayed.

About once or twice a month, at different times and with different loads. For example, this error once occurred at 2 a.m., when hardly any electricity was being consumed.

Similar to what happened to Andi from Offgrid Garage:

My setup:

3x MultiPlus 5000 units

1x Raspberry Pi 4 with Venus OS v3.80-39

7x LiFe batteries with a total of 2715 Ah — 4 of them are Seplos batteries with 320 Ah each (connected via CAN)

1x Victron Power In

1x Victron Distributor

1x Fronius Symo 5k, controlled via Modbus TCP.

Epever plugin by mr-manuel from GitHub

EV Charger plugin by mr-manuel from GitHub

A few other “small” controls via Node-RED, but not involving the DC voltage.

In addition, I switch off the AC-in relays of the MultiPlus via a relay (generator function). This allows me to operate in island mode above a certain SOC value.

The MPs are connected with 75 mm² cables, with all six cables being the same length.

1x SmartShunt via USB — VE.Direct

What I have already tried:

I replaced the USB CAN adapter with a CAN HAT => no success

I checked the SmartShunt connections and connected the + cable directly to the Distributor’s positive busbar => no success.

I adjusted the voltages in VE.Direct => no success

I disconnected the Vsense cables from the MultiPlus => no success

I checked the screws and tightened them again to 20 Nm.

Under System Settings / Batteries, I set the battery monitor to the Seplos BMS instead of the shunt => no success.

I connected the MK3 interface to a different USB port => I only did this today.

At 15:154 today, it happened again:

However, the VRM Portal has not reported any error or alarm since 1 July 2026.

The MultiPlus is currently running firmware v558, but v563 is already available.

I have also attached my VE Configure file, of course:

Bernisoft_d83add0e7290_inst_ttyUSB1_Interfaces_Mk2_Tunnel.rvms (9.4 KB)

Could anyone here perhaps help me?

hello,

i just disabled it because it isn’t triggered only by undervoltage!

bye

What did you disable?


@Xbass L2 and L3 have different settings in the inverter and the ESS Assistant.

Your problem does not appear to be the voltage, but rather that you are losing the connection to the BMS, which is also causing a “Low battery” message.

the low-battery warning

Hello

@d_ferdi do you mean this?

I’ve already tried that, unfortunately without success.

I disabled this today to test it, because I noticed that when I unplugged the MK3 USB cable and then plugged it back into a USB 3.0 port, the inverters immediately switched back on.

Could communication via the MK3 interface be causing a problem?

@M_Lange I’ll take another look at the configuration of L2 and L3 tomorrow. I thought they weren’t relevant for the ESS, since L1 (Main MP) has the assistant and controls everything there, but no problem, I’ll adjust it.

The BMS lost alarm was on 1 July 2026, and that’s when I switched from:

to CAN HAT:

I haven’t had the BMS error since then.

What I’ve just noticed in the log:

858501_0_Bernisoft_log_20260803-1401_to_20260803-1705.csv (80.5 KB)

timestamp,Gateway [0],Gateway [0],Gateway [0],Gateway [0],Gateway [0],…

2026-08-03 15:28:41,29,Not active,Off,…

changed to:

2026-08-03 15:29:10,1,Not available,Off…

Could there be something wrong with my MK3?

Many thanks

Bernhard

Second addendum:

Apparently my time in PuTTY is two hours behind, but never mind:

Because I had the “Not available” entry in the log at 15:29:10 => so in the shell it was around 13:29

With dmesg -T I get the system logs:

[Mon Aug 3 13:28:20 2026] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Aug 3 13:28:20 2026] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Aug 3 13:28:20 2026] ftdi_sio ttyUSB2: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Aug 3 13:28:20 2026] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Aug 3 13:28:20 2026] usb 1-1.2: USB disconnect, device number 38
[Mon Aug 3 13:28:20 2026] usb 1-1.2: ch341_read_int_callback - usb_submit_urb failed: -19
[Mon Aug 3 13:28:20 2026] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[Mon Aug 3 13:28:20 2026] ch341 1-1.2:1.0: device disconnected
[Mon Aug 3 13:28:20 2026] usb 1-1.2: new full-speed USB device number 39 using xhci_hcd
[Mon Aug 3 13:28:21 2026] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[Mon Aug 3 13:28:21 2026] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[Mon Aug 3 13:28:21 2026] usb 1-1.2: Product: USB Serial
[Mon Aug 3 13:28:21 2026] ch341 1-1.2:1.0: ch341-uart converter detected
[Mon Aug 3 13:28:21 2026] usb 1-1.2: ch341-uart converter now attached to ttyUSB0

and so on with the error messages, but when I then used USB 3.0

[Mon Aug 3 13:58:47 2026] usb 1-1.2: new full-speed USB device number 41 using xhci_hcd
[Mon Aug 3 13:58:47 2026] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[Mon Aug 3 13:58:47 2026] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Mon Aug 3 13:58:47 2026] usb 1-1.2: Product: VE Direct cable
[Mon Aug 3 13:58:47 2026] usb 1-1.2: Manufacturer: VictronEnergy BV
[Mon Aug 3 13:58:47 2026] usb 1-1.2: SerialNumber: VEACZTVL
[Mon Aug 3 13:58:47 2026] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[Mon Aug 3 13:58:47 2026] usb 1-1.2: Detected FT-X
[Mon Aug 3 13:58:47 2026] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[Mon Aug 3 13:58:50 2026] usb 1-1.1: new full-speed USB device number 42 using xhci_hcd
[Mon Aug 3 13:58:50 2026] usb 1-1.1: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[Mon Aug 3 13:58:50 2026] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Mon Aug 3 13:58:50 2026] usb 1-1.1: Product: MK3-USB Interface
[Mon Aug 3 13:58:50 2026] usb 1-1.1: Manufacturer: VictronEnergy
[Mon Aug 3 13:58:50 2026] usb 1-1.1: SerialNumber: HQ2509HEUTN
[Mon Aug 3 13:58:51 2026] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
[Mon Aug 3 13:58:51 2026] usb 1-1.1: Detected FT-X
[Mon Aug 3 13:58:51 2026] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB1

Perhaps I should look into this direction.

The dmesg excerpt looks to me very much like a USB/serial dropout, rather than primarily a genuine battery-voltage issue: at 13:28:20, several URBs stop at once, followed by usb disconnect, and then the adapters are enumerated again. This also matches the timing of your Gateway Not available.

I would therefore start by narrowing things down there:

  1. temporarily unplug everything unnecessary from the Pi’s USB ports and run only the MK3 and the battery connection that is actually required
  2. if a hub is involved, test with and without the powered hub, preferably using a good power supply for the Raspberry Pi
  3. deliberately assign the MK3, VE.Direct and CH341 adapter to fixed ports and, after an event, check whether the ttyUSB assignments have changed
  4. at the same time, run dmesg -T -w or journalctl -f and compare the next alarm with the VRM timestamp

If switching to the USB 3 port stops the dropouts, that would already be a very strong indication of an issue with the port, hub, power supply or adapter, rather than with the VEConfigure low-voltage parameters. I would only touch the firmware once the USB side is stable and the error still recurs.

Hello

@busbum I have the same suspicion.

The Pi4 is powered via a PoE HAT:

so that shouldn’t be a problem.

I’ve put the MK3 and VE Direct on USB 3.0 for now.

CH341 was a BLE proxy for Home Assistant. I plugged that into the Pi next to it (a Pi in kiosk mode for the display).

I’ll keep an eye on it.

Many thanks

Bernhard

hello,

the Venus OS has to send the power-on command when an MK2/3 is connected, otherwise the Multi stays off. However, it is only sent once the configuration software is started.

bye

Hello

As of today, no more errors—everything is running as it should :wink:

Kind regards

Bernhard