Is it possible that DESS has recently been revising its target soc in half-hour intervals? Due to the situation in Great Britain with half-hourly prices? This should reduce the problem of not reaching the target and the associated recharging from the network. In any case, the price information in the VRM already has a half-hour grid
sollte dieser Fall nicht durch den Hack behoben werden?
TargetSOC > SOC:
Batterie wird geladen - aber nicht mit allem verfĂŒgbaren PV-ĂberschuĂ:
Habe um 13 Uhr begonnen das BEV zu laden, weil gĂŒnstiger StrompreisâŠdaraufhin wurde der TargetSoc vom VRM wohl von vorher 42% auf 86% angehoben und die Batterie wurde nun wĂ€hrend des Ladens des BEV schon mit 2,5kW aus dem Grid geladen. Nach Beenden des BEV-Ladevorgangs wird weiterhin ânurâ mit 2,5kW geladen, obwohl PV-ĂberschuĂ vorhanden ist, der nun eingespeist wird ins GridâŠ
DESS originally planned to charge the battery from the grid for 3 hours from 13:00-16:00. This was done for the first two hours (13:00-15:00), but from 15:00 the system suddenly stopped charging from the mains and discharged the battery!
The schedule for charging the battery was then pushed back by DESS by 1 hour to 16:00-17:00, but again the battery was not charged but discharged!
Since I have the hack running, I suspected it. The whole thing looked like this:
Since I suspected the hack, I deactivated it, i.e. executed the rollback commands. Unfortunately with the same result that the battery is discharged instead, despite the planned charging:
@dognose do you have any explanation for this or is this actually a general DESS problem?
Since the final strategy was âScheduled_Self onsumeâ it was intended by vrm.
I had this last week, where DESS initially scheduled for battery balancing, but when reaching 70%, suddenly switcht to self-consume. By that time, also the message in vrm âSelf consume scheduled for this dayâ was gone, so it was a âchange of planâ by vrm, whatever may cause this.
Today I had this in the opposite way: vrm planed to idle the day at 45%. Since tomorrow is expensive, I decided to charge some kWh today. Suddenly, when reaching 75%, DESS switched to a target sic 100 and displayed the message âscheduled for todayâ in vrm.
So, I guess that there also decissions on the battery-care-charge that may cause postponing this or decide âlateâ to do it today.
Nein, das ist noch nicht im verfĂŒgbaren Hack enthalten. Ich hab mir schon eine Lösung ĂŒberlegt, bei mir auch eingebaut - aber seither die Situation noch nicht erneut gehabt.
Und ich will da nichts âveröffentlichenâ, das auf könnte, sollte, mĂŒsste basiert - erst, wenn ichs positiv testen konnte ^^
Kannst mir ja die Codezeilen mal schreiben / geben, dann teste ich gerne mit.
Bin auf der Bash zu Hause 
GruĂ Ove
Strange behavior !
I had Battery Balancing enabled and noticed it was scheduled at an expensive weekday.
Disabled it and the message promptly went away.
Re-enabled it earlier and today my battery got charged to 100%, at low weekend rate
An observation I made today by chance. Today I had a similar phenomenon to grua, where the system suddenly started to recharge at 6 p.m., even though the price is higher. For work reasons, I was closely monitoring tomorrowâs weather forecast. My regional weather report deteriorated significantly around 5 p.m. Unfortunately, I didnât pay close attention to the solar forecast, but I assume that it played a role, at least for me.
VRM is just right now (8 pm) Also sending me 100% soc schedules - price is highest it could be 
thx god, Selfonsume_Soc_high is kicking in 
(Iâm setting target soc to âââ when switching to Selfconsume_soc_high, just changed this for Screenshot purpose)
(Strategy 0 = TargetSoc)
now, 8:01 pm, vrm switched to self consume (Strategy = 1):
@dognose Did you by any chance work out how to expose âFInalStrategyâ via a custom widget?
I donât think that is possible. Itâs a variable iâve added, and VRM is not aware off. So, most likely wonât be contained in any of the VRM advanced graph source options.
Hack successfully installed. Will observe and report any issues seen. Thanks for the hack @dognose!
Running the hack for a few days. Thought this case would be interesting. One hour grid consumption at highest price level rather than battery. Plan was a 3+ hour solid energy consumption to be battery supported.
Real case is a weekly Sauna always started shortly after 18:00 h on the same day. My expectation would be battery support right from the beginning though with grid consumption following later at lower prices. Pics:
you forgot to post the âinterestingâ graph with the SOC-Forecast from Victron (VRM). I think the BatterySOC was lower than the TargetSOC and so energy is pulled from the gridâŠ
Afaik thatâs no situation where dognoseâs HACK helpsâŠ
My system has been progressively dropping the SOC over the last few weeks. There has been no overnight charging in the off peak period and the system has been relying on the day ahead solar prediction to charge the battery.
Couple of nights ago the battery was at 26% at 0.30AM (start of off peak period) the system did charge 1%. Actual solar that day was nowhere near the predicted 5.5kWh (already low). Battery was very quickly down to 15% and the system was drawing from the grid. Lowered SOC to 5% and we went into the evening drawing from the grid. DESS was still not planning a significant amount of charge overnight. I turned DESS off and used my Node red solar predicting flow to charge the battery to 70% overnight.
Now we are entering winter DESS needs to be much more proactive at keeping a higher SOC. What is the point of having a 12kW battery if DESS is happy to to only be using 3kW. The user ends up with no backup and grid charges.
On the other hand I may have the settings incorrect and in other systems it works fine.
Minimum SOC (unless grid fails) 15%
Green mode (with Hack)
My Max target SOC for idle 90%
Battery cycle costs per kWh set to 0.03 ÂŁ/kWh
may be post this in DESS - Victron Community to get the victron guys awakeâŠ
Thanks
This is more like feedback to dognose as I am running the hack version.
looks to me that the HACK is not addressing your special case.
I think your problem is based on the âbadâ VRM computing of the TargetSOCâŠ
I also think that this has nothing to do with the hack, but with the planning originally carried out by DESS. This should be discussed in a separate thread in the Q&A DESS section.