Not sure what you mean by “per system”, but this is what the hint popup says.
system = three 1-phase MP II 5000’s acting in tandem as one 3-phase MP II 15000. With reasonable detuning 12kW if your battery can handle upto 300A. If not then take max Amps from battery times lowest voltage say 48V * 200A = 9600W
Ok, shunt settings seem to be ok. DESS settings are not.
Your discharge power is 4.000 x 1,1 (conversion losses) x 3 = 13,2 kW. Your charge power is 70 (A) x 51,2 (nom. voltage) x 3 = 10,75 kW.
Your charge and discharge current limits can be set in DVCC. In a healthy system it is better not to go above 0,5C so 140 A in your case. These are hard limits in DVCC, in DESS the maximum charge and discharge powers are not.
Now what your inverters are capable of is what I wrote above but since you are limiting in DVCC these are not the max values DESS should count with. So let’s calculate again. Max discharge power is 140 x 51,2 = 7,16 kW. Max charge power is the same. Note that this is what the battery sees, on the AC side it will look different because of your inverting losses.
So if you agree with this 0,5 C try this 7,16 kW setting and let us know how it works out.
Apologies Rik, I’m afraid I don’t understand.
Your discharge power is 4.000 x 1,1 (conversion losses) x 3 = 13,2 kW.
Does this 4000 come from the DESS setting or from about the max discharge for a single 5000VA MP2?
If the latter, my system under DESS discharges with 4000W, not 13kW. Why?
If the former (DESS setting), why is this setting apparently used for discharging, but the corresponding setting for charging isn’t?
With regard to DVCC, I understood you need a supported connection between battery and Cerbo, I don’t have that yet.
The BMS can’t handle 300A, max 200A continues, it says, but I won’t push it that far. But as said before: the system is currently charging with more than 4000W (about 6500W), although it’s discharging with 4000W under DESS.
The 4k is what the MPII 5kVA is capable of. But that is on the AC side and since you have losses the DC side sees 4k x 1,1. You have 3MP’s so that will be 3 x 4k x 1,1 = 13,2 kW.
These settings, both charging and discharging, are only used to calculate a schedule.
DVCC does it’s job independent. It does not need BMS communication.
The 4k is what the MPII 5kVA is capable of. But that is on the AC side and since you have losses the DC side sees 4k x 1,1. You have 3MP’s so that will be 3 x 4k x 1,1 = 13,2 kW.
OK, understood.
These settings, both charging and discharging, are only used to calculate a schedule.
This doesn’t influence the charging profile/current at all? Then why is the system charging at 6500W max with DESS? Where does that (limiting) number come from?
When you look at the picture in your first post you will find the voltage to be around 55,2V I bet that is your absorption voltage isn’t it? Now how can the inverter push more current when the absorption state is reached? It can’t. You bateery is simply not taking more then this.
Absorption voltage for the chargers is set to 56.4V.
I did notice the max charging Amperage is set to 40A though, 40A x 3 = 120A, at about 55-56V is about 6500W. I think we solved that mystery.
Still no idea why it discharges at 4000W max though, perhaps the DESS Battery setting does do something? I’ll experiment with a higher setting…
Edit: oh great, can’t edit settings, it says there’s no real time connection, which there is…
Hello! I noticed similar charging behavior last week on my system. I updated the firmware through remote console and it seems to have corrected it for me. I was on 3.60~72, now updated to 3.70~39.
Have same problem SOC target is incorrect.
Battery size 96kWh and charge limit is 8000W to have a decent efficiency.
See steps of 7,5 minutes where target SOC makes unexpected steps.
There is a technical limitation in play that the DESS execution control process, not sure whether located on the Cerbo GX (VenusOS) or on the VE-Bus device (ESS assistant) has a maximum resolution (precision) of one full (1.0%) percent SoC. See second part of this post:
If the time scale gets smaller the SOC resolution has to be increased (agree).
Do not see technical reasons why an INT can’t become a FLOAT in next firmware.
How to report this imperfection?
That’s the million dollar question right there. The official awnser I presume is to go through the official sales channel. The unofficial awnser is to try and raise awareness on this forum albeit without attracting all too much negative reactions to oneself for being a pain in the #ss.
Unless it’s a contraint from the legacy firmware of the VE-Bus devices themselves and the so called assistants running on top of it. Not that that should be a valid reason not to implement this change, but it would explain a significant amount of relunctance on Victron’s end to be very proactive about it. I’m a bit sorry to already be quite cynical about this, but I do not expect anything to happen in the foreseable future, not until triple digit kWh battery banks are becomming commonplace enough to start generating heaps of noise around this topic here on the forum. I have developped a Node-RED flow as workaround, that basically tracks the should be ‘target SoC for the current time slot’ (as float) and then actively manipulates the actual ‘target SoC for the current time slot’ on the DESS system to be correctly rounded (up or down) to the nearest INT for that timeslot, depending on the actual strategy for that same timeslot to be charging, discharging, selfconsumption or otherwise. But I find as ugly an hack as ugly hacks come.
Hope they see this post and do fix it!
This way I never reach the predicted SOC, simply because in the middle of a 15 minute charge phase the charging stops.
Parameters in ESS settings are all correct.
I’m afraid I already bought myself a reputation for being a problemseeker, but I’d encourage you to try. There’s more details to ity as well, one being SoC% generally being calculated as a linear correlation to consumed Ah’s. For systems such as ours based on Li-NCM chemistry, with an operational voltage range of 3.3V to 4.2V per cel, this leads to significant deviations between the energy per SoC% as well that should be accounted for (and is in our system, by means of a virtual battery with a fixed nominal voltage setpoint and recalculated amperage and SoC% as if the voltage curve is perfectly flat)
I do not understand why they divide the 15 minutes in 2 parts.
And that sometimes the Target SOC in the middle is lower than start and end point (during charging).
Assume this is a rounding error somewhere?
Making only one change every 15 minutes instead 2 would already solve a lot.
Mostly seen during the first quarter of the hour on our systems. Possibly something to do with spreading the load on the backend cloud server calculating new schedules.
Don’t think so, the SOC targets are stored in Venus OS for 48 periods of 15 minutes.
I do see an change every 7,5 minutes and the one in between a 15 minute period is sometimes 1% off and this stops charging or discharging.
Think this are rounding errors 10,49% is rounded 10% 10,50% is rounded 11%, we need a float target SOC!