I think why it doesn’t work like it did 3 months ago is the pressure from countries
We had a chunk of -ve pricing over the weekend so I enabled the Battery Balancing to kick the system into using as much as possible. It looks like the configured SoC also limits the Battery Balancing mode - mine is set to 70%, and the balancer didn’t manage to get over that level. It also looks like it causes some odd looking oscillations - perhaps constantly topping up the battery?
I’ll probably try and use the Hack’s new Ad-Hoc charge mode in future - I’m not a fan of these many charging oscillations.
Inspired by this thread (Is system efficiency same as roundtrip efficiency), I calculated the poor efficiency of my over powered system (3x quattro 10k) for a roundtrip to approx. 60% and told the system to use this number for calculations:
/usr/bin/dbus -y com.victronenergy.settings /Settings/DynamicEss/SystemEfficiency SetValue 59.9
My one-way efficiency is about 77.4% which means I have to put almost 1.3 kWh of energy into the battery to store 1kWh. So I modified @dognose HACK:
diff 3.50/dynamicess.py va13/dynamicess.py
--- 3.50/dynamicess.py
+++ va13/dynamicess.py
@@ -528,7 +528,7 @@
try:
# a Watt is a Joule-second, a Wh is 3600 joules.
# Capacity is kWh, so multiply by 100, percentage needs division by 100, therefore 36000.
- chargerate = round(1.1 * (percentage * self.capacity * 36000) / abs((end - now).total_seconds()))
+ chargerate = round(1.3 * (percentage * self.capacity * 36000) / abs((end - now).total_seconds()))
self.chargerate = chargerate if self.chargerate is None else max(self.chargerate, chargerate)
self.prevsoc = self.soc
except ZeroDivisionError:
Once a week on every sunday energy is cheap (usually), so I decided to charge my battery on sunday and use it evently spreaded over the week. To realise this I installed a crontab:
59 1 * * 0 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 99 >/dev/null
59 1 * * 1 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 84 >/dev/null
59 1 * * 2 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 69 >/dev/null
59 1 * * 3 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 54 >/dev/null
59 1 * * 4 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 39 >/dev/null
59 1 * * 5 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 24 >/dev/null
59 1 * * 6 /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue 9 >/dev/null
And finally DESS (green mode) seams to work (at least for me):
to-do: @dfaber Victron should subtract EVCS and headpump consumption from Total consumption for better forecast quality.
2 Likes
Update to previous post:
System buys energy at times of low prices which is perfect, but there is not enough energy to reach daylight and system uses grid. This might be improved by buying more energy. In my case, i try to lower Settings/DynamicEss/SystemEfficiency by 10% from 59.9 to 53.9. I’am exited if this does the trick.
Hi,
yes, this is outlined here:
(probably lost somewhere in not reading 179 posts 
)
In the current version there is little to do about this - but I am working on getting things sorted, so that the system won’t show any unexpected idle, even if that artifical limit is removed again.
Or to clearify:
I’m going to remove that. The intention was to be able to say “70% soc is enough for me, above that, don’t force any charge, please” - but it is causing more issues with the roadmap than it actually helps.
Such a value would need to be implemented on VRM / DESS side, so the actual Roadmap does account for this - and not be a local limit that interfers with what VRM / DESS is expecting to happen.
3 Likes
Thanks for that, I re-read the posts again last night and did spot your clear warning this time round! I don’t use Balancing mode normally, I just wanted to make maximum use of the negative rates. In my head this setting was to do with accepting bonus PV charge; ll try setting it back to 100% as it doesn’t sound like it does whatever I was thinking it did when I first set it 
1 Like
I’ve created a branch for Version 3.51 and 3.52 where the SELFCONSUME_SOC_HIGH was removed.
It caused some Issues of “peaky / spiky” charges, when target soc and max colided. (Changing flow direction on every percent, i.e. 69, 70, 69, 70, …)
The Soc value now is exclusively for Adhoc Charging.
Install Links:
3 Likes
As usual: big thanks for the updated version !
*sends virtual beer to dognose*
1 Like
I tried your hack on Ekrano GX, version v3.52.
Unfortunately, no luck for me.
What exactly doesn’t work ?
The hack is specifically targeted at users running DESS in Green Mode, and only that.
Other forms of (D)ESS are not supported.
At this stage, the (UI part of the) hack doesn’t work yet with GUI-v2, only with v1.
I am running DESS in Green mode.
The script runs fine and the Ekrano reboots.
After reboot, in settings, ESS, Dynamic ESS, the HACK menu is not shown.
That would mean that either:
- You did something wrong
- The Ekrano somehow has a different inner working than other GX devices.
Can you paste the output of ls -la /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py and ls -la /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml ?
The hack install method in dognose’s last post lacks proper formatting, if you copy pasted from that something may have gone wrong.
If you scroll waaaaaaaaaaay up to the top of this thread, you’ll find the properly formatted install instructions that you can try.
The Hack is correctly installed on your Ekrano.
Values in the DESS menu will differ for each system as they are either calculated by your system or to be set by yourself (such as the AdHoc Target SOC).
The hack version info is one line below the Final Strategy, use the arrow buttons to navigate down in the menu and you’ll see it.
Don’t expect dramatic results from running the hack, it’s effects will be rather small.
Mainly it prevents grid feed-in when there’s excess solar but still room left in the battery for charging, and less grid buy when consumption is higher then estimated but there’s spare energy in the battery.
1 Like
Just checked - it is all good formatted.
What is bad, is the post where I link to the install-post. When you click the “I understand…” directly from the preview, it’s truncated.
1 Like
Hi,
Can’t you change the openingpost en put there the link(s) to update/install?
I am running my system (v3.52) in green mode with dognose’s hack as well but have just modus status and target SOC without a value (just a dash).
I double checked like Bart Champagne said the files which was fine. Does anybody has a glue what I might have done wrong?
Please check in gui1.
The screen you show is gui2. The hack is not compatible with gui2.
1 Like
Like @marssomers said and like I explicitely mentioned in an earlier post: the hack GUI part only works in GUI v1, not (yet) in GUI v2.
1 Like
Hello
The hack works very well, but if I understand correctly, selling back to the grid is completely disabled.
This is fine for the winter, but in the summer I have more solar than consumption and want to sell this too much in the evening/morning to the grid.
Is it possible to add an on/off switch for the hack with a schedule?
Then I can only run the hack during the day in the summer.
During the day the benefits of the hack and evening/morning the possibility to sell to the grid.