I recently noticed unstable ESS behavior when the battery SOC is at (or very close to) the Minimum SOC (unless grid fails) setting.
The system constantly switches between discharging and charging -for example, about one second of discharge followed by two seconds of charge, repeatedly. I tried adjusting the obvious settings to influence this behavior, but did not notice any change. All system components are up to date, and the Cerbo GX is running v3.67.
My impression is that when the battery SOC is around the Minimum SOC (unless grid fails) value, the system does not have a clearly defined state. As a result, it appears to bounce between charging and discharging until it can exit this condition (for example, by setting the Minimum SOC value 10% lower).
I do not know the exact internal workings of the ESS control loops, but I would expect a small hysteresis to be implemented to prevent this behavior. Rapid starting and stopping every few seconds is quite unsettling .
Therefore, I am wondering whether this is a known issue or something specific to my system.
Many thanks in advance,
J.B.
System setup / ESS configuration:
Grid metering: 3-phase external meter
Multiphase regulation: Total of all phases
ESS mode: Optimized
Grid setpoint: 150 W
Inverter/charger: MultiPlus-II 48 V (One on L1)
Battery: 15 kWh LiFePO₄
PV inverter connected to AC-out 2 (does not appear to be related to this issue)
Cerbo GX: OS Large installed (no custom flows interfering with ESS reg.)
Can you be specific about what battery you have.
ESS has a hysteresis of ± 3% specifically so that behaviour is stable.
So, what you are seeing has little to do normal behaviour.
It is more likely you have incorrect dynamic cutoff values (set in the assistant), or voltage thresholds that are being exceeded in general inverter settings. Or, the bms is having an issue at low SOC and is triggering this behaviour.
Definitely not a bug, it is an installation or config issue.
You will need to post much more detailed charts and config settings if anyone is going to take a guess at the cause.
Also, if you are using DESS, which is different functionality, that can contribute. I would disable that to troubleshoot.
You also don’t seem to have any solar which is responsible for charging within that ±3% range. Grid is only used to charge beneath the min soc -3% hysteresis.
Thank you for the reply. I do not use Dynamic ESS. I use a 16S / LifePo4 280Ah pack combinec with an JK BMS via CAN (the batterypack is more than capable for the 5K MP2).
Dynamic cut off values are 46V (0.005C) to 45V (2C). Sustain voltage is set to 44.8V. The general inverter setting voltages are DC input shutdown: 44V (restart: 47V).Virtual switches → None
Your issue appears to be using ESS with no solar (at least as far as the system is concerned).
At min SOC ess state 1 is triggered, loads serviced by grid and all PV is used to charge the battery to min SOC +3% when normal service resumes.
Grid will not charge the battery until min soc -3% is hit.
ESS will not behave as intended without solar.
Your PV inverter is not shown on the UI so the system seems unaware it is there, you will need to correct that so ESS can work as designed.
The solar inverter is connected to AC-out 2 (at the moment, there is no solar production, no sun). I would expect the ESS assistant loop to monitor the battery (ESS #1) and, as soon as the state of charge (SOC) reaches the minimum threshold, switch off the inverter and use the grid to supply the loads. Once the power from the grid drops below the grid setpoint, the ESS assistant should restart the control loop, allowing normal operation to resume, but only if the SOC has increased by X%.
I suggest you go through the PV inverter config docs. AC2 should not be used.
The inverter needs to be connected either via Modbus (sunspec) etc or with a dedicated meter set to a PV inverter role.
This is then configured into the ESS assistant and/or GX.
Without that the system has no clue you have a PV inverter, what it is producing etc so there is no control.
For all intents and purposes you have no PV, it is just cancelling out loads on AC OUT.
When setup correctly your PV inverter will appear on the UI and VRM.
I have an ET112 connected to AC-out 2, but since one of the last Cerbo updates, I am unable to get the Cerbo to detect it. The ET112 uses a USB–RS485 connection (it worked for months…).
Since I was not aware that the ESS loops consider the ET112, I will make it a priority to get it detected again.
In my case, I chose to use AC Out-2 for the PV (the 1:1 rule is respected) because I want to be able to switch the PV off if the batteries are full and there is not enough load present. Since the Victron documentation states that this is possible, I did not second-guess this approuch (a relay in the power panel and a NodeRed flow could also achieve the same result). Is there anything I need to consider that is not mentioned in the Victron documentation?
Either way, I will check the ET112, and thank you very much for your help!
I am limited with the PV inverters; they are good, but quite simple microinverters (WiFi-configurable). I use a few of these because the PV panels are spread around the property, so DC strings are not practical or interesting. Until now, this setup has worked very well: the MP2 uses the output frequency to limit the PV inverter power, so they hardly ever need to be switched off by the relay.
Good luck. There have been mixed successes with microinverters, some just don’t respond well to frequency shifting which ESS relies on.
A stable ESS relies on a dependable BMS and good control of solar.
Let us know how it goes.
I managed to fix the connection problem with the ET112 (used to measure solar production from the PV micro-inverters). To keep it brief, it appears that somewhere around firmware version 3.5xx, changes were introduced related to the USB ports and the GPS / VE.Bus modules within Venus OS.
My (original Victron) USB-RS485 converter, which has been used to connect the ET112 to the Cerbo GX since the system was installed, is being actively “hijacked” (claimed) by these two modules. I was unable to release it by any means — even a factory reset of the Cerbo GX did not help. As a workaround, I connected a second USB-RS485 converter, and it worked instantly.
You might assume the original converter was faulty — but that is not the case. It works perfectly fine, as I can read the ET112 Modbus data using the same converter when connected to my laptop. In any case, this part of the problem is now resolved.
Now back to my original issue — the reason I started this topic — the “oscillation” at or around the “Minimum SOC”. This issue does not seem to be fully resolved by enabling solar yield, as clearly shown in the images I took this morning (Minimum SOC is currently set to 75%). The oscillation appears to occur when the SOC is 1–2% above the configured minimum SOC. However, I have the impression that it occurs less frequently, although it still happens a few times per minute.
To ensure this behavior is not related to the solar inverters, I electrically disconnected all solar inverters from the system and monitored it for 5–10 minutes. The problem persisted, allowing me to completely rule out the solar inverter side.
So far, my impression is that injecting the solar yield helps, but it does not eliminate the oscillation entirely.
If anyone has an idea or insight, please let me know.
I ran a test on mine, disabling DC solar at ESS #1. As per the video you can see it sustains a small charge state.
I believe the remainder of your issue is down to the BMS and reporting.
You mentioned you have a JK BMS, so presumably using the serial driver mod or similar?
There is likely a delay or delta in reporting which is affecting the system’s ability to maintain a constant state.
There are many posts on JK which might have some insight, but as mentioned, the BMS is a critical part of the system behaving as expected as the battery is managing charge, not the inverter.
Unfortunately systems with untested/unsupported components can have quirks and they can’t always be fixed.
First of all, thank you very much for taking the time to help me — it is truly appreciated.
The BMS (JK) was not the root cause of the issue, as the model I use supports VE.CAN natively (CAN-bus BMS LV at 500 kbit/s) without requiring any modifications (communication has been stable, with no errors, no dropouts, and consistent high-speed performance,….).
That said, this does not completely rule out BMS involvement in combination of the ESS Loops. So I did a bit of further investigation and noticed that the battery monitor setting was configured to “Automatic.” To eliminate any possibility of Venus OS switching between sources, I changed this setting to “BMS on CAN-bus.”
I’m happy to report that since making this change, there has been no more switching between charging and discharging I will continue to monitor the system over the next few days, but at this point I would say the problem is solved.
Once again, this was an excellent tip from your side and helped steer me in the right direction
Great news.
That is one of the simplest errors that happen, if I had a $ for every time we have suggested that be checked
It looked like a battery monitoring issue, so we got there in the end.
.
I will continue to monitor the system over the next few days, but at this point I would say the problem is solved.
