There’s been no change in the files actually released in VenusOS by Victron so far.
Even the new v3.54~1 beta release has no change in dynamicess.py or PageSettingsDynamicEss.qml compared to the versions shipped in v3.52 or v3.53.
The Hack will most likely still work out of the box on these versions.
When Victron pushes the new version in VenusOS, the Hack will get an update.
But from what I can see so far, we’re not there yet.
1 Like
Yes, the current version is still working. Didn’t have time by now to update repo / instructions, probably doing this weekend.
Where does the number 16.8 come from?
Hello everyone,
many thanks for the great HACK! With the current version 3.54 I got the feed-in behavior back, today. I think it was due to the wrong suggestion in the solar yield. No solar preview vs. actual yield
It worked very well with the previous versions.
After 2 hours of deactivation of the DESS it seems to work again.
Greetings
Now I tested it several times.
Any scheduled charge was not possible. Nothing happened.
DESS followed his own schedule.
DESS was switched on and a schedule was planned.
Did anyone yet test v3.54 of Cerbo GX? Is the Feed in still a problem or does @dognose Hack still work?
Seems to work just fine on my Venus GX running v3.54
Ok, can confirm The 3.52 Hack still works with 3.54 and sadly is still needed. It immediatly began to feed in again even if SOC was 32% after the Update and without the Hack
From v3.52 to v3.53 and v3.54 the files that are modified by the Hack did not change in VenusOS, so safe to assume the Hack still functions on those versions.
Whenever there’s a new VenusOS release I do a comparison of these files to predict if a change in the Hack is required and I post my predictions in this thread 
1 Like
Can the hack be modified with that?
All AC surpass charging should be treated as solar feed in.
Currently this is not the case and the Dynamic ESS does not take this in account when calculating. This is why i turned off DESS currently.
Hi Dognose, I am experiencing the exact same problem and it seems your solution will work. However i’m trying to understand how to install it. Is there a ready made file that can uploaded to the erkano or do i have to “hack” in and change the code manually. If so can you guide me through that process as i have not done changes like that on the system before
Hello Sparc,
There is no single ready made file but you also don’t need to change the code manually.
Dognose has put the files online and has provided instructions to install them.
First of all you need to enable SSH access to your GX device and set a root password.
Then you need to log in (as root) and follow the instructions in this post.
If you’re running Windows, I recommend the PuTTY SSH client.
For VenusOS versions 3.51 and above (up to 3.54 confirmed working so far), these are the commands you need to run on your GX device after logging in.
Some familiarity with Linux is recommended but not really needed.
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
Good luck,
Bart
2 Likes
I tried the hack for a while now with Venus OS v3.54 and it seems to help to some degree, but not 100%.
Today I noticed a condition where my system had final strategy SCHEDULED_CHARGE_SUPPRESS_FEEDIN and still was feeding 250…300W for several minutes to the grid:
Only when I disabled DESS, it started to charge the battery with max excess power:
My setpoint is +10W, min SoC is 10%, and DESS target SoC was at 17% at the time.
That is the result of some mathematical imprecissions caused by either the presence or absence of ongoing ac-dc conversion with the current hack version.
Trying to calculate a “better” chargerate in this case, but doing so affects the conversions and yields another result.
Also values of acpv which are imprecise or slow updating may impact the precission here.
In general you could say, the moment the math is done and the inverter is instructed with a certain setpoint (and ramps up/down towards it) - it is already eventually outdated.
The higher the overall load and solar the less precise a “0-Setpoint” will be.
Switching dess off then is more precicse, because the normal ess mode does not care about any of the actual values, it just works with the delta towards the configured grid-setpoint.
I’ve been testing two approaches here:
- calculate a better chargerate
- switch the system into ess mode, and let the setpoint handle it.
While the second one yielded better precision, it has drawbacks, if that “switch” between a fixed rate and ess mode is happening to often.
It always caused the chargerate drop to 0 upon switching mode - and this felt worse than accepting some 100 watts imprecission here.
(This situation - “Dess chargerate calculated to low” - is very rare anyway)
Hm, ok, so basically you are saying that with DESS and your hack there is a different, more laggy control loop for the setpoint??? That would be a pity because I have a speedy EM540 and the MP2 is usually adapting very quickly to changing loads. But I have not yet seen any indication of added lag from DESS.
And even if DESS hack would introduce more lag / ramp up / ramp down times, it does not explain what I observed because the mismatch persisted for several minutes as you can see in the following hi-res plot, AC load (green consumption curve, computed from grid meter, battery power, and pv power) was constant for a couple of minutes as well as PV power (blue) and battery power (yellow) the MP2 fed into the grid at a pretty constant rate (red curve) from 13:05 to 13:16 where I switched off DESS et voila: grid meter reporting constant +10W which matches the set point.
And with DESS, right before it started to feed in, it was pretty stable until 13:03.
I don’t know the details of your hack, though, but I want to mention that I have loads on AC-out-1 and also a PV inverter on AC-out-1 in addition to another PV inverter on a different phase than the one where the MP2 is wired to via AC-in. So maybe a sign error somewhere? AC-out-2 is not connected anywhere…)
It’s sunset already, but this snapshot should speak for itself regarding my topology:
In this case - yes. DESS itself either uses a fixed chargerate - or the regular ess way.
When the fixed charge rate is to low, i’m overriding that with a “better value”, but within a 5 second loop of the delegate.
This is a trade off, not very precise, but it still increases the amount of energy gained, compared to sticking to a “too low” fixed chargerate and feeding in.
But actually, i gotta check that. The Strategy “…Surpress_Feedin” should be faking a 0-Feedin restriction and not even mess with the calculated chargerate iirc. Hence, that should lead to almost 0 Feedin. 
If you could post your vrm-side id, i could lookup thinks more precisely and eventually figure out how everything fits together. (The numeric one in your vrm-dashboard url)
Hm… I could imagine that DESS is prescriping a fixed charge rate based on PV forecast and does not account for possibly more irradiation than forecasted
Anyways - here’s my number: 427765 (I just have no idea how it will gain you any access to my dashboard - except if you belong to Victron staff )
Yeah, started to work together with Victron. I’ve checked some things, first of all, yes, the SCHEDULED_CHARGE_SUPPRESS_FEEDIN does not manipulate the chargerate, but just telling the system that feedin is restricted. This usually causes the system to automatically increase the chargerate to avoid feedin.
But in your case, didn’t…
Eventually that has to do with the Inverter on the different phase (Is it L3?). Are you using Multiphase-Regulation for ess or Individual Phase-Mode?
If individual Phase-Mode that would explain it, as the system then desn’t increase it’s charge, as the feedin is happening on another phase.
1 Like
Multiphase Regulation is set to “Total of all phases” because I have a single phase system and an EM540 grid meter and ESS is configured to match the total consumption, i.e. the sum of power consumptions of all phases, to the set point, which is set to +10W. And that usually works. The panels for the L3 PV inverter are faced east and the ones for the L1 PV inverter are faced west so despite some overlap during noon one of these inverters is always in the shadow.
