DESS vampire drain (workaround)

[va13 (Lars Valentin)]

DESS has great potential if it is redesigned and reimplemented.

At the moment it can only be used with @dognose HACK and even there are still many small inconsistencies.

One of these is the self-consumption of the system which is not taken into account. This leads to two bugs.

1. The system gets stuck if the battery charge level falls below the set DESS minimum charge level.

2. The system recharges electricity from the grid at regular intervals to maintain the set DESS minimum state of charge, this happens in 5% steps, e.g. 15% → 20%.

Of course, any storage of electricity is less efficient than direct use. Each system has an individual round trip efficiency, which depends on the size of the system and the user behavior. With a round trip efficiency of 50%, which is not unusual, you need twice as much electricity if you store it in the battery.

In order to work a little more efficiently, I have developed the following workaround: Every 15 minutes, the DESS minimum charge level is adjusted to the current battery charge level, so the system does not charge the battery from grid anymore. This is done via a small shell script, which is started via the crontab.

Here is a screenshot with two days without the workaround and 12 days with the workaround. You can clearly see that almost 5kWh were saved in a two day period (Solar + from grid - Consumption - to grid). The workaround was activated on 16.12.2024. You can also see nightly EV charging at low prices.

You need basic knowledge of the editor “vi”, as well as “ssh” access to the CerboGX and minimal Linux knowledge to implement this.

crontab entry:

root@cerbogx:~# crontab -l
# minute stunde day_of_the_month month day_of_the_week (UTC time)
0,15,30,45 * * * * /home/root/bin/DynamicEss_selfconsume_SOC.sh

helper script:

root@cerbogx:~# cat /home/root/bin/DynamicEss_selfconsume_SOC.sh
#!/bin/bash
### adjust DESS MinimumSocLimit to actual SOC to reflect self consumption of inverters (0,75% per hour in my case)
### this prevents pulling energy from grid to charge battery modulo 5%. (for example charging from 15% to 20%)
### even if charging from grid is disallowed.

   # set SOC below this script works
my_min_SOC=30
   # read Battery SOC and convert to Integer
SOC=`/usr/bin/dbus -y com.victronenergy.system /Dc/Battery/Soc GetValue |awk '{printf ("%.0f" ,$1)}'`
   # read DESS MinimumSocLimit and convert to Integer
min_SOC=`/usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit GetValue |awk '{printf ("%.0f" ,$1)}'`


if [ ${SOC} -gt 2 -a ${SOC} -le ${my_min_SOC} -a ${SOC} -lt ${min_SOC} ] 
then
  # echo "set DynamicEss_MaxTargetSocForIdle to actual battery ${SOC}%"
  /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue ${SOC} >/dev/null
fi

if [ ${SOC} -gt ${my_min_SOC} -a ${min_SOC} -ne ${my_min_SOC} ] 
then
  # echo "set DynamicEss_MaxTargetSocForIdle to ${my_min_SOC}% (reset settings while charging from PV)"
  /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue ${my_min_SOC} >/dev/null
fi

---

my System:
v3.51~3 + @dognose HACK
3x Quattro 48/10000/140-2x100 + cerboGX
go-eCharger with nodeRED PV sureplus charging

[dognose]

Hi,

When the system falls 2% bellow the current target soc, it will attempt to charge back to target soc, yes.

Usually the DESS Schedule adapts and lowers the target soc, whenever it notes a drop due to self-discharge of the batteries, so the soc should stay in the range targetSoc or targetSoc-1 worstcase.

@va13

The system gets stuck if the battery charge level falls below the set DESS minimum charge level.

Could you explain what you mean here? Does this stuck happen at any targetsoc, or just when you reach the ESS #1 - LowSoc Error?

How do you usually resolve this stuck situation, will it resolve autmatically the next morning, or do you need to do something?

Do you have dcpv or only acpv?

[va13 (Lars Valentin)]

@dognose

Could you explain what you mean here? Does this stuck happen at any targetsoc, or just when you reach the ESS #1 - LowSoc Error?

Exactly. When reaching ESS #1 the system is not able to charge the battery with enough energy from PV. Instead the majority of energy is feed to the grid. Either the system stabalizes itself after some time of “slow” charging from PV or manual intervention is required.

I saw this behavior a few times in this forum. One Example: (out of a few)
victron mp2 freeze after low battery alarm

@dognose

Usually the DESS Schedule adapts and lowers the target soc, whenever it notes a drop due to self-discharge of the batteries, so the soc should stay in the range targetSoc or targetSoc-1 worstcase.

That’s not the behavior I think I’m seeing. The system recharges the batteries with power from the mains, although this was explicitly prohibited in the DESS settings. To be more precise: If system reaches targetSoc-1 and if targetSoc-1 modulo 5 equals 0 (e.g. 15% or 20%) the system starts charging from grid.

But my workaround does exactly the behavior you described.

My System has AC-coupled PV connected to critical loads.

[va13 (Lars Valentin)]

Here is another picture of the last 12 days:

Now you can calculate the standby consumption of the 3 Quattro 48/10000/140-2x100 very accurately:

(from grid + Solar - To Grid - Consumption) / 12 days / 24 hours / 3 quattros * 1000
(168+185-39.4-260)/12/24*1000/3 = 62.03 Watt

This corresponds pretty much exactly to the data sheet, i.e. no energy from the grid is temporarily stored in the battery, otherwise the value would be much higher.

[dognose]

Code-wise the charging “back to target soc” happens at any level, as soon as soc = targetsoc -2. Droping bellow one percent is allowed, and that usually would give DESS (the remote side) enough time to lower the current target soc, so the state soc = targetsoc -1 can turn into soc = targetsoc again.

I did encounter situations, where the idle discharge (assume due to peak shaving) was high enough to fall behind 2%, which then resulted in charging - but that happens about once a month for my system.

There is another rule set of ESS (not DESS), which charges the batteries from grid, when they fall 5% bellow minimum soc. (and since we can only set the minimum soc in 5% steps, that equals your observed modulo 5 -charging)

I think the cutting edge for your system may be, that it:

• first, falls bellow targetsoc (which DESS sets to try to avoid ESS #1), and then enters ESS#1, where it does no longer respond to ac-charging requests of DESS and as you don’t have dcpv it is kinda bricked. (DESS can’t do anything anymore)
• finally, falling 5% bellow minimum soc, where the ESS-Protection-Charge from Grid kicks in.

What is your exact minimum soc setting? I’ve now read a bunch of posts, outlining issues with minimum soc settings equal or bellow 10%. Also the configured Cutoff-Voltage of the Inverter seems to start to play a role in this area of soc. Most Posts ended with a resolution of the situation by using a minimum soc >= 15%.

Eventually there are even differences between the quattros and multis that come into play.

[va13 (Lars Valentin)]

@dognose

There is another rule set of ESS (not DESS), which charges the batteries from grid, when they fall 5% bellow minimum soc. (and since we can only set the minimum soc in 5% steps, that equals your observed modulo 5 -charging)

My system loses about 7% in the night so charging kivks in every night.

Before using DESS I used ESS with SOC = 0% since this is no problem for LiFeYPo4, backed up by a bunch of Pb Batteries which kick in under 5% until low Voltage is reached.

Since using DESS I changed SOC and ended up with 30% using my workaround, which should cover at least 5 days of fog, this works like a charm and saves lots of energy (5 kWh/d).

Here a screenshot of the situation fixed by the workaround. DESS feeds the grid, while it should not: