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 
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)
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.
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!
1 Like
I’ve now thought about this, and how to solve it - and I think the only way to address this, is a user-preference setting. I’ve therefore now modified the UI of the Dynamic ESS Page in cerbo, where a user can set the “Max Target SOC for idle”. (And in the same turn added the Final Strategy Output there):
So, what does this exactly mean?
When there is a roadmap based on target-soc, VRM has a plan, that it should reach a certain soc-level per hour. The Hack will slightly adjust this “strict” behaviour with additional checks that see if there is PV available to charge, or if we may temporary power loads from the battery.
yet, until now, it respected very high soc-targets as requested by vrm and went into idle mode, when a pv-shortage occurs. For my system there is a very high certainity, that if I reach 50% soc during the day - it will be sufficent power stored to make it through the night and reach the next day. So, i’ve set the Max Target SOC for idle to 50% - and that just means, that if the soc is ABOVE 50%, the system will kindly ignore any target-socs requested by vrm, not charging from grid and not going into battery idle anymore.
The Final Strategy then will be “SELFCONSUME_SOC_HIGH”
The value defaults to 100%, meaning the system will follow the target soc of VRM upto 100%, maybe even going into idle mode at 100% or charging from grid at 95%.
Please note, that using a lower value than 100% will basically break the periodic balance-charging, as the system is not aware, if the 100% Target requested is a regular schedule or a VRM-balancing-charge-request. Only workaround possible is to set this value to 100% at days, where battery-balancing is scheduled, or leave it at 100% and omit this part of “enhanced idle-suppression”.
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
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
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_SOC_HIGH:
System is in regular ESS mode, because we have enough soc.
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 Version currently is 2024-11-01 (for 3.50):
2 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?