Hi dognose,
Do I understand it correctly that if I use the code from the fork, that when I’m on Green mode, DESS will use your code, and when I’m on Trade mode, DESS will use the original code?
That’s what I would like to inplement.
But the cerbo is not aware of the actual mode.
Hence, the current code is ONLY suitable when you run in Green Mode, as it completly suppresses bat2grid decissions (which are essential for trade mode)
So, only use it when using Green Mode. For Trade Mode, stay with the original file.
Ok, thanks for clearing that up.
Perhaps I will make 2 dynamicess.py files and change them when I change modes, because with winter coming I think Green mode will be less benificial.
1 Like
@dognose, when you make changes to the fork will you post it here please?
Yes, will do. I’m not always upgrading to the latest version at release day, usually about 1-2 weeks later 
Will it also run on Raspberry Pi?
If you run DESS in Green Mode on it, yes.
1 Like
Yes, DESS VRM-Version Green Mode on Raspberry Pi, Venus OS v3.42
I’ll test it!
Sorry to be the blunt elephant in the room, but in all the screenshots I see “FinalStragety” instead of “Strategy”.
Since I can’t seem to find any reference of that typo in the Github file, I can probably assume it was fixed before committing there ?
Yes
1 Like
You can always watch the github project 
1 Like
I’m working on trade-mode fixes. Hopefully, we’ll be able to merge efforts at some point and have an improved file for both scenarios. I’m still testing my changes, but once I’m one I’ll certainly pull @dognose changes locally and work out if they are compatible or how to make them compatible.
3 Likes
I think trade mode is really difficult to fix from the cerbos point of view. If you have the situation, that “soc > target-soc”, you can’t really tell, if that is just a “ahead of plan” due to more solar than expected - or if the schedule actively wants to “sell now”.
Probably would need a grace-range, something like “ok, if difference is greater than 20%, that looks like a intended sell-request”.
Best would be, if the schedule would be marked accordingly by vrm, but that goes beyond the possibilities in the local python file. Could only make a “best guess” there.
Ok, I think the “Idle-Mode” still needs a little bit more tweaking:
VRM says “TargetSoc=100%”, and the battery is at 100% soc. Doesn’t really look like “Green / Optimized” if it therefore enters battery idle mode. Grid prices are cheap, yeah, but in my case still wouldn’t make sence to keep the battery at 100%, it almost could sustain the minimum loads for 48h:
I assume sitting at 100% Battery and pulling from Grid is not what most users would expect in Green Mode - would only make sence, if battery capacity needs to be spend wisely to make it through the night.
Will think about this, probably above 95% soc, there shouldn’t be idling anymore. (Best way would be a user-configurable value, in my case reaching ~ 55% soc would be sufficent, above that the system could ignore target-socs of vrm, without running out of battery till the next morning)
1 Like
Additional PV is less common than reduced PV, but in this scenario any excess goes to the grid and the SoC target is maintained. The schedule is SoC-centric and the grid export that happens in this scenario is a harmless side effect assuming you get paid for export (you wouldn’t be using trade mode otherwise). The pimary issue is when the schedule plans to maintain SoC but the actual PV is less than expected and does not cover loads. In this scenario DESS imports to cover the difference (potentially when import rate is high) rather than allowing SoC to drop a bit lower than the plan and then rescheduling.
There are of course other ways that you could implement the schedule, but the fact that the schedule doesn’t know the actual forcast/consumption ahead of time the SoC-centric approach seems very reasonable to me. The key is ensuring that locally Victron adjusts what actually happens based on both schedule (target SoC/restrictions/flags) and actual consumption and PV, and doesn’t just stick to target SoC.
1 Like
Installed the updated version on my VenusGX today.
So far running good.
As it turns out, there’s a (small) diff between the ‘dynamicess.py’ version originally on my GX and the one from the Victron Github.
@dognose’s version includes that diff so I guess I’m good ?
Let’s see how it runs
Also installed @dognose’s DESS HACK just now on my Raspberry Pi, Venus OS v3.42 . Let’s see
R4 does not affect me, as I have deactivated discharging the battery to grid in the DESS settings:
But I have observed R3 several times and have already described it here in the forum. This behavior is really annoying and is the reason why I very much welcome this DESS HACK!
2 Likes
Installation for Version 3.51, 3.52:
I understand it's 100% my own Risk, and i'm running the right version.
wget https://raw.githubusercontent.com/realdognose/dbus-systemcalc-py/refs/heads/feature/v3.52/delegates/dynamicess.py
wget https://raw.githubusercontent.com/realdognose/dbus-systemcalc-py/refs/heads/feature/v3.52/temp/PageSettingsDynamicEss.qml
test -a /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py || cp /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py
test -a /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml || cp /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml
mv dynamicess.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py
mv PageSettingsDynamicEss.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml
shutdown -r -t 10 now
Installation for Version 3.50:
I understand it's 100% my own Risk, and i'm running the right version.
wget https://raw.githubusercontent.com/realdognose/dbus-systemcalc-py/refs/heads/feature/v3.50/delegates/dynamicess.py
wget https://raw.githubusercontent.com/realdognose/dbus-systemcalc-py/refs/heads/feature/v3.50/temp/PageSettingsDynamicEss.qml
test -a /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py || cp /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py
test -a /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml || cp /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml
mv dynamicess.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py
mv PageSettingsDynamicEss.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml
shutdown -r -t 10 now
Installation for Version 3.41, 3.42:
I understand it's 100% my own Risk, and i'm running the right version.
SSH into the cerbo and run the following lines directly from the terminal. (the last one is a reboot, so don’t worry 
)
wget https://raw.githubusercontent.com/realdognose/dbus-systemcalc-py/91c529a9beca7afd327617e2e2a7da38364919e5/delegates/dynamicess.py
wget https://raw.githubusercontent.com/realdognose/dbus-systemcalc-py/91c529a9beca7afd327617e2e2a7da38364919e5/temp/PageSettingsDynamicEss.qml
test -a /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py || cp /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py
test -a /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml || cp /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml
mv dynamicess.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py
mv PageSettingsDynamicEss.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml
shutdown -r -t 10 now
To verify the changes are active, you can check that the following command returns a value:
dbus -y com.victronenergy.system /DynamicEss/FinalStrategy GetValue
or check the FinalStrategy-Value in the cerbo UI under Settings → ESS → DynamicESS.
Will now be either of
None:
There is no schedule provided, matching the target window.
SCHEDULED_SELFCONSUME:
VRM says “Just use regular ESS mode”.
SCHEDULED_CHARGE:
VRM scheduled a certain soc to reach, may include charging from grid.
SCHEDULED_CHARGE_SUPPRESS_FEEDIN :
If a scheduled charge is resulting in a lower charge-rate than the available solar-surplus, the hack will pretend a 0-Feedin-Restriction upto 90% soc, so the system has to increase it’s battery charge rate.
SELFCONSUME_ACCEPT_CHARGE:
System is in regular ESS mode, because despite any target_soc it noted PV Surplus beeing available.
SELFCONSUME_ACCEPT_DISCHARGE:
System is in regular ESS mode, because even if there is PV shortage, our SOC is ahead of plan, so we can power the loads.
IDLE_MAINTAIN_TARGET_SOC:
System enters battery idle, because it tries to stick to plan and we have not yet reached the “feel-well-value”, we are sitting at targetsoc and there is a PV-shortage.
ADHOC_CHARGE:
A AdHoc Charge Rate has been set, to boost charging upto the set up SoC.
To Rollback any changes, in case there are issues, just run the following commands:
cp /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.backup.py /opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py
cp /opt/victronenergy/gui/qml/PageSettingsDynamicEss.backup.qml /opt/victronenergy/gui/qml/PageSettingsDynamicEss.qml
shutdown -r -t 10 now
That’s it. Current Hack-Version is 2024-11-27 (for 3.51, 3.52):
5 Likes
@dfaber I think Victron has to implement this sooner than later. Because with new firmware update(s) it could ruin the Cerbo UI at this point?