may be daylight time saving problem…may be fixed on sunday 
Does this Hack work on beta vrm 3.50~38?
no, look here:
1 Like
I don’t know if it might work with the beta.
I only have a “production” system, so not running betas on it, can’t test.
On regular realeses I will verify the changes within 1 or 2 weeks and eventually make some adjustments when required.
1 Like
könnte gut klappen.
Wenn ich mir die dynamicess.py der v3.50~39 ansehe, ist die bis auf eine Zeile mit der v3.41 identisch:
einfach mal probieren - Da Du vor dem Überschreiben der Datei ja ein Backup der originalen Version machst, könntest Du ja jederzeit zurückgehen auf die Auslieferungsversion…
Ich habe den HACK heute morgen unter v3.50~38 in Betrieb genommen und ich bin schwer begeistert. Soweit ich das beurteilen kann funktioniert es recht gut, insbesondere funktioniert meine PV Überschuß Ladung der E-Autos noch einwandfrei.
2 Likes
I’ve been running the hack and have been very happy with the results. Until this week when there has been no wind or sun to speak of here. Obviously I’m not consistent enough in my usage, so the prediction for target SOC has often missed and I’ve ended up at minimum SOC running off the expensive grid.
It’s not an issue of the hack, more of the scheduler I guess, but I was wondering if there was some further hacking that could be done to apply something like a targetMinSOC, so instead of the schedule ‘aiming’ for the ESS minSOC it could aim for something a bit higher up and leave me with some extra juice to play with! What do you think?
1 Like
Yes, DESS is indeed creating a very conservative schedule regarding “charging from grid”.
It’s basically only charging what it’s expecting to need - and some unpredictable consumptions may interfer with that plan.
I am thinking about this as well, but adressing it would need more changes than just some slight intra-hour behaviour-changes.
Just adding some extra % to each target soc also won’t be sufficent, that would require a very detailed exception ruling for the times where it is “fine” to go bellow the intendet targetsoc. (Else it would just kinda offset the energy shortage and operate on 80-50% rather than on 50-20%)
2 Likes
I have already brought up the idea here and would like to repeat it again. I would advocate the introduction of an “all-in price”. A particularly low price below which not only the requirements of the next time interval are charged, but the entire available storage capacity
I’ve just noted that 3.50 is available now.
I will look at it this evening and see, if the hack can be applied “as is” or if it needs some slight adjustments.
1 Like
I’ve now updated to 3.50 and merged the hack with the new dess delegate file.
Installation-Instructions added in this post:
Tiny Feature added as well:
Under Settings → ESS → Dynamic ESS you’ll now find the setting Adhoc Charge Rate - this is just a simple way to force the battery to charge, when desired.
For example, sometimes the DESS schedule is quite conservative, but I know, that this evening my wife will enable the Dishwasher of Discharge, the Washingmachine of Wattwaste and the Dryer of Depletion - all at the same time.
In this case, I just want to charge some extra kWh in cheap hours, which this tiny setting allows me to do:
Simply specify the Adoc Charge Rate you want to use, and it will charge upto the configurable Soc-Level - and then reset the Charge Rate to 0 and return to normal behaviour:
3 Likes
Thanks for the new version.
Just in time before I was able to ask why there is no target SoC available in my DESS.
SoC is at 50%, Max target SoC for idle is set to 65% nur still no charging planed.
Hope the new option will help.
First of all, thanks again for your great work!
But I don’t quite understand the text quoted above: what exactly do you mean by the “configurable SOC level”?
If I understood correctly (below text is subject to changes and doesn’t hold any certain information or warranties. If it contains errors, please let me know) :
You can instruct your system to charge the batteries up to “Max Target SOC for idle and Adhoc Charge” percentage*, at “Adhoc Charge Rate”.
This way, you can command to pre-charge the batteries (preferably during cheap hours) up to the defined amount of SoC %, to anticipate a large load later that day.
(Driving an electric motorcycle, I greatly appreciate this option, thank you @dognose !)
* : the screenshot of dognose doesn’t have the updated text yet, but it’s there.
The “Max Target SOC for idle and Adhoc Charge” setting allows you to set a max SoC % that the system will use before the battery goes to idle mode.
Typically this is 100% but if you feel more comfortable running at a lower value (to spare your batteries, or when you’re expecting regular solar overproduction), you can set a lower value there.
(Personally, I’m running “Max Target SoC” at the default 100%, so the bi-weekly charge to 100% works and because I have too little solar to reach 100% these days otherwise.)
So DESS tries to keep my SoC at “%”, to anticipate my upcoming loads. Let’s say 64%.
On occasion (when I know I’ll need to recharge my electric motorcycle at high price times) I’d like to precharge my batteries another 20% to anticipate this higher consumption.
To do this, I’d change the “Max Target SoC for Idle” to 84% (20% higher than the system target value of 64% needed) and set the “Adhoc Charge Rate” to a charge rate reasonable to attain that higher SoC during the time when prices are low.
When this higher SoC is reached, I’d need to update the “Max Target SoC” back to 100% to resume normal operation.
Hope this helps (and is correct).
Bart
1 Like
Exactly.
No Game-Changer, but quite nice to have every now and then. 
1 Like
all right, thanks!
after the update to v3.50 I was briefly unsure whether the hack would still work, because the new GUI doesn’t show it:
But the old GUI does
Yes, i’ve already updated the files required for the new ui - but it doesn’t show up.
It seems like the new ui is referencing qmls from within a packaged binary - so just modifying the qmls is no longer sufficent.
Need to play around with that to figure it out.
Or we should try to convince Victron merging your hack into the next version of Venus OS. 
7 Likes
Hallo @dognose,
die neue Version 3.5 ist Klasse und das manuelle “AdHock” Laden funktioniert wunschgemäß.
Ich hätte 2 Wünsche:
-
Könntest du noch die Möglichkeit integrieren, dass man dieses Adhock aus der CLI anstossen kann? Parameter wären Ladestärke in Watt und Ziel SOC des Speichers, also z.B.
script 3000 90 -
Autoupdate
Leider überschreibt Victron bei Gelegenheit den Code. Ein
script selfupdatewürde es vereinfachen, den Hack wider zu aktivieren (und auf den neusten Stand zu bringen (was bedeutet, dass ein Teil des Scriptes auf dem ESSverbleiben muüsste bei einem Update - falls das überhaupt möglich ist.)
Alternativ könnte ich auch ein Shell script ersrtellen, dass alle Schritte per remote SSH Aufruf ausführt.
Wäre dies machbar?
Liebe Grüße
Bfo