Hi,
I have a 3-phase VE.Bus system with 3× MultiPlus-II 48/3000 units (L1 Master, L2+L3 Slaves).
The system worked normally until one day. Since then:
Off-grid: all 3 phases invert normally.
Grid connected: only L1 inverts, L2 and L3 stay in passthrough/charging.
AC-setpoint (even −2000 W) affects only L1.
All units show “Inverter ON” and synchronize correctly.
ESS ON/OFF makes no difference.
Multiphase regulation = either “Total of all phases” or “Single phase” → no change in behaviour.
No external 3-phase grid meter installed. Only CT sensors connected to each MultiPlus.
Pylontech battery with DVCC active.
No configuration changes done on the day the issue appeared.
Question:
What conditions must be met for ESS to allow L2 and L3 to invert when the grid is present ?
Do the CT sensors on each MultiPlus-II count as valid per-phase grid measurement for 3-phase ESS, or is a 3-phase grid meter (EM24 / ET340) required now ?
Or it could be some bug in latest inverter FW (> 502, I tried upgrade 510 → 558 same results) ?
I have one another PV setup exactly same with same parameters (but older inverter FW 502) and it works good and inverters running on all phases.
Yes, the ESS Assistant is installed on all three MultiPlus-II units (L1 Master, L2 Slave, L3 Slave).
All units have identical VE.Bus firmware versions and the same set of Assistants.
I also rewrote the configuration to all units again via VEConfigure to be sure – no change.
Still, only L1 inverts when the grid is present, while L2 and L3 stay in passthrough.
In off-grid mode all three units invert normally.
I ran several more tests and the behaviour is consistent:
When I remove all Assistants, the system immediately starts exporting normally on all phases (same as my second PV with identical setup, where everything works).
When I enter parameteres in ESS assistants back with the exact same settings as on the working system, the setup gets stuck again:
– Only inverter #1 works,
– Inverters #2 and #3 stay in passthrough,
– The system always imports from the grid, no export on L2/L3.
CT readings and internal/external measurements are correct.
The issue appears only when Assistants are active.
My goal is to use as much PV production as possible on-site, not export it on a single phase where the load is low.
I need inverter #2 and #3 to operate normally with Assistants enabled, but this currently does not work.
Adding screenshot below - exporting #L1: -758 W when I need #2L: 148 W and #3L: 446 W ?
Did you set up your Multis with the Ve Bus System Configurator? Any error messages here… Rotating field is set to “right.”
Master is set to L1?
No Gridmeater devices… everything via the Multis ?
I analysed the VRM log from 4–6 Aug.
There is no indication of a phase swap in the data — the L2 and L3 power patterns do not exchange, which would normally be visible if the phase order changed.
What the logs do show is that around 5 Aug ~12:00, both L2 and L3 suddenly move into continuous import, while L1 continues exporting. This looks like a logical change in system behaviour (ESS / Assistants / VE.Bus decision), not a physical phase change.
I currently don’t have a MK3, so I can’t check the VE.Bus configuration (incl. phase rotation).
I need to wait until early next week when my colleague brings me the MK3.
Was a firmware update performed… so that the assistants have all disappeared, of course?
Also check the sustain voltages and charging voltages in the other multis.
It often happens that L2 and L3 recharge the battery while the ESS exports on L1…
A firmware update was done here — Multis are now on 510 and GX on 3.66. => With Assistants enabled, L2 and L3 fall into continuous import while L1 keeps exporting. On my second identical PV system setup the Multis are still on 502, with the same Assistants and the same settings, and everything works normally there. So yes, the firmware difference could be relevant.
Regarding voltages: All three Multis have the exact same settings:
Sustain voltage: 52.0 V
Restart voltage (Dynamic cut-off): approx. 52.2 V
Absorption: 54.0 V
Float: 53.4 V
Equalization: disabled
Tail current and absorption time identical on all units
So there is no voltage difference between L1/L2/L3 that could explain why L2 and L3 go into import.
From the VRM log it looks more like a logical ESS/Assistant/VE.Bus behaviour change rather than a charging-voltage mismatch.
I’ll check the VE.Bus configuration with the MK3 at the beginning of next week when I get it.
Sorry for the typo, Steffen – and thanks for the correction.
My setup is also US3000C (15S), so the voltages I listed fit the official Pylontech/Victron profile.
US3000C = 15S (3.2 V × 15 = 48.0 V nominal)
I’ll check the Dynamic Cut-Off once I get the MK3 next week. Or can I check it in Cerbo console ?
Thanks for the reminder — you’re absolutely right
I completely forgot that the full ESS Summary can be downloaded directly from the Assistant settings.
Just checked it again and the values are exactly as expected.
My real values are:
Sustain: 48.0 V
Dynamic Cut-Off: 46.0 / 47.0 / 48.0 / 49.0 V depending on discharge current
Restart: +1.20 V above the cut-off
So sorry for my mistakes and thanks again for pointing me in the right direction.
The voltage thresholds are exactly correct for 15S LiFePO4 (US3000C) — I double-checked the full ESS Summary from the Assistant settings.
The earlier 52 V value was just the actual battery voltage, not the ESS sustain threshold.
See attached image
I’m really curious to see what is causing this issue.
Thanks, Steffen, but I don’t understand why all Dynamic Cut-Off values should be set to 46 V.
For a 15S LiFePO4 (US3000C) system that seems too low, and it also removes the current-based protection (46/47/48/49 V) that Victron normally uses.
Could you explain the reasoning?
These Cut Off Voltages normally were used with the old lead acid batteries … AGM etc. Technologies … There is actually no use for LiFepo… but it will continue to be evaluated in the ESS routine…
You are welcome to use them for yourself, but batteries are now so resilient that these values no longer make sense for normal applications… If you want to overdo it, the BMS from the battery comes into play… This was not the case with lead-acid batteries.
Thanks, Steffen — I understand your point.
For LiFePO4 the battery BMS indeed provides the real protection, so the Dynamic Cut-Off curve is no longer as critical as it was with the old lead-acid/AGM systems.
But if I remember correctly, my second identical 10 kWp PV system with 3 inverters uses exactly the same Assistant setup — and it works perfectly.
So I don’t think the cut-off values are the reason for this behaviour, unless there was some internal change between FW 502 → 510 that affects ESS logic.
That’s why I’m still trying to understand what exactly makes L2 and L3 go into import on this system only.
Could this be related to battery condition, calibration, or BMS behaviour that might differ between the two setups?
That’s definitely not the reason… the voltage shouldn’t drop that far… but I still suspect that something is wrong with the ESS assistants… but you’ll figure it out… we’re working on the problem…
Feel free to reconfigure it… you can do that without MK3 now…
There have been faulty ESS assistants before… they worked after being reinstalled…
I’m surprised that the system doesn’t generate an error code…
Are the multis’ current meters also set to the correct phases… and the rotating field is “R” ?
Just to add one mention — I already removed all Assistants on all three inverters (L1, L2 and L3) and manually re-installed them again using the exact same configuration values that works on my second PV system.
Unfortunately, the behaviour didn’t change: without the Assistants the system works normally in 3-phase, but as soon as I re-enable them, L2 and L3 go back into continuous import.
Yes of course I did not see also any error codes in VRM or in console yet
And the current meters are assigned to the correct phases, and I will double-checked the rotating field once more. But I never met any related warning - as shown here 11. VE.Bus Inverter/charger monitoring
When I have Mk3 i will check it.
I’m still trying to understand what could make this system behave differently compared to the other one with the same setup.
… 
