DESS: Target SOC reached to soon

I just want to know if I am the only one with this “issue”

Since a few weeks I noticed that the target SOC is already reached approx. 15 minutes before the full hour. It happens when charging and discharging the battery and every hour…
I can’t remember if this was always the case.

For example DESS made a plan to dump the energy from my battery to the grid
SOC at 11:00 = 35% target SOC is calculated by VRM at for example 30%.
This target SOC 30% is already reached at 11:45.
So system stops dumping the energy from my battery to the grid and my load is consumed for the next 15 minutes from the grid! Dumping energy is normally done when prices are high so I am consuming for 15 minutes at high prices. This is not good

Anybody else has the same experience?

Same here. I’m not shore if it should help to change settings in DESS max discharge and charge. Dess used that values for calculating, but I had no luck so far.

@Maxs Thanks for your feedback
I also tried to change some ESS/DESS parameters but for now no luck…

I maintain two DESS systems and both have this behavior since let’s say a month

I have the same happening. Doesn’t seem to prioritise the battery usage once the Target SOC is met with the consequences of higher grid costs.

Few things:

  1. If SoC is being reached before the end of the hour then it is possible your actual battery size is smaller than configured battery size or there is an issue with the reported SoC from battery or shunt. You could try configuring slightly smaller battery capacity in DESS to mitigate this.
  2. DESS will speed up discharge if it’s not fast enough to reach target SoC, but it doesn’t slow it down ever if it will reach SoC before the end of the slot. Therefore, the only way to adjust this is by changing the battery capacity.
  3. The import from grid happens once SoC target is reached and DESS switches to an “idle” state where it attempts to maintain the SoC constant. However, this idle mode imports from the grid if there is not enough PV to cover loads! I’m am playing around with a potential fix for this. See: DESS imports from the grid unexpectedly when it rains! - #2 by dfeist. Looks like this is also impacting @enterinner .

@dfeist
Thanks for your suggestions.
Target SOC is also reached to soon when charging. It is always approx 10 minutes before the hour and I noticed that also that the DESS schedule0 is updated approx 5~10 minutes after the full hour… so sometimes “nothing happens” (DESS system is idle) for more than 20 minutes around the full hour…

Will try to reduce the battery capacity even more, since my tested capacity is 31,9kWh and the current DESS settings are 30kWh

I watch the thread of your third point… I hope Victron find the time to look at your patch

I made that observation too but while charging, i.e. target SoC being reached 5…10min earlier than planned.

And one possible explanation is the the calculation of the charging power vs. system losses (which depend on the charging power) vs. SoC calculation errors (which are natural because of the flat charge/discharge curve of LiFePO4 cells and also imperfect cell balance).

And maybe a another cause - at least in my case - might be the calculation of the energy (kWh) in my Pytes batteries which is based on a fixed voltage of 51V multiplied with measured and accumulated Coulomb (aka Ampere seconds). But usually, the voltage is a little higher while charging and a little lower while discharging so a huge error will accumulate when it comes to calculation of energy being transferred to and from the battery and thus also calculation of system efficiency. (My system is AC-coupled, no MPPT, and GX is reporting 419.8kWh discharged energy and 497.5kWh charged in total which is roughly 84% round-trip, but in reality this is more likely around 90…95%)

1 Like

FYI. You can see what the calculated charge rate is by looking at the dbus path com.victronenergy.system/DynamicEss/ChargeRate using dbus-spy if you ssh in (or via modbus tcp register 5403). You can see the calculation used here: dbus-systemcalc-py/delegates/dynamicess.py at master · victronenergy/dbus-systemcalc-py · GitHub

Huh what is this 1.1 factor…

To account for efficiency I beleive. It should really use paramatized value for this though.