On my installation I have “Can you sell to the grid ?” set to “Yes” in DESS, because otherwise the Sell price isn’t graphed.
The “Maximum Export Power” is set to 0 kW however and obviously I’m running in Green mode.
VenusOS version is v3.55 stable and I’m also running The Hack of @dognose
Today at 15:00 my batteries were full and at 17:00 injection price became positive again.
When I randomly checked VRM around 17:20 I was very surprised to see my system was injecting the excess DC Solar into the grid, even though this is disabled in VRM/DESS and ESS settings on the GX (“DC-Coupled PV, feed in excess” is set to No).
This system only has DC coupled PV and should never inject to the grid.
When I turned off DESS, the injection stopped.
If I turn DESS back on again, the system starts injecting the surplus to the grid again.
Seems like a bad DESS schedule.
Other people seeing the same phenomenon ?
For reference: this installation’s VRM ID is 169594.
Today, 3.60 was released, it contains various changes for DESS, also a stricter handling of the DESS configured limits. (They are no longer only taken into account for schedule generation, but also re-evaluated locally in realtime)
You could check, if that resolves your unexpected Feedin-Issues.
Do you have a grid meter and set the export amps in peak shaving to 5 to further try and lock down the export while having selling turned on just for your graph data?
Can you maybe shed some light on the changes to the DESS algorithm and the options there are now that were previously enabled by your Hack ?
“No bat2grid” and Scheduled Charge come to mind.
Basically the Issues my hack was addressing are resolved and the communication with vrm is more detailed/flexible now.
The - what I called it - Adhoc Charging however is not there. But the VRM Team has also made significant improvements in the scheduling, I didn’t had the need to manually invoke a charge since a long time.
The Adhoc Charge came in handy when I wanted to precharge my home battery at low grid prices so they’d be full enough to charge my electric motorcycle at night.
This happens at irregular days, so virtually impossible to predict.
Adhoc Charge also came in handy during the hours grid prices were negative (disable solar and just pull from the grid at those hours :-), which doesn’t seem to occur anymore the past few weeks (I suspect the grid company has connected a large battery site themselves).
Something I’ve built (with Node Red) a while back is what I called a “Grid = Load” function.
Basically it’s something I (manually) enable/schedule when grid prices are (almost) as low as my battery cycle cost, or lower.
What it does is in the name: it matches the grid setpoint in the GX with my actual consumption load so all consumption comes purely from the grid (while keeping peak shaving active) and all PV energy goes into the battery for consumption later, when grid prices are high.
I’ll test how the latter function interacts with the new ESS and if it’s even still needed.
“Some day, when I have spare time” [TM] I might update my functions to properly interact with the DESS schedules.
I’ve been using DESS since more than a year, yet very often swiched it off for some hours, since it was doing weird things. Yesterday I upgraded my RPI Venus GX to 3.60 hoping the §14a improvements stop this. I perceived no real change.
What bugs me most, is that it is discharging the battery into the grid to prepare for next day. In principle this is great, yet then it draws from the grid in the early morning hours, e.g. 4.2kWh for yesterday and today - this cost me more than 1€, propagated to the year over 150€, which I could spend much better. My 35kWh battery is dimensioned to take me through the summer without needing the grid, which works perfectly if I turn of DESS and set the grid-setpoint to something like 120W.
I would expect the DESS to keep some reserve in the battery to NOT draw from the grid. If necessary avoid solar charging in the morning hours to preserve charging capacity to avoid feed-in when negative EPEX grid prices (gross < 18ct/kWh from my provider). Weird that it even feeds from battery into the grid in the morning hours, while also charging the battery.
There seems to be something rather off with DESS it seems.
Today my system again exported solar surplus to the grid when my battery was full, even though I explicitly configured that this should never happen.
The “Can you sell to the grid” setting is enabled only so I can see the injection price.
If I turn it off, the injection price isn’t displayed.
Export power is set to 0 and export is disabled on the GX as well.
And yet, the system exported to the grid today.
There’s only an MPPT in this system and no AC coupled PV so I’d expect the system to simply throttle down the MPPT to remain at the grid setpoint.
At this stage I’ve simply disabled DESS due to a “too much ■■■■* and not enough shovels” situation where I have no time or desire to babysit Yet Another Buggy System.
*: too much work, bugs and defects, far more than just in my Victron systems.
And yes, this makes me cranky and have a bad temper.
Does anybody have a clue why DESS is screwing up ?
Always rounding down the hourly SoC target (real number) from the API to quater hourly integer targets. Especially when charging the system always throttles down towards the end of the quarter hour, misses its hourly target, followed by a repeated hourly rescheduling. On discharge it can lead to overdischarging followed by a recharge right after the last discharge hour. things get worse with ‘optimized with batterylife’ when the lower limit is hit and Min-Soc increases by 5% that gets recharged asap.
Always targeting Min-Soc at midnight (this day till prices come in, next day thereafter, with DESS trade at least) while it would be much better to target a high, nearly full target, around dinnertime
Related: no means to ‘reserve’ (sell) capacity for hours beyond the ‘known’ price schedule.
Waiting about 7 minutes beyond the whole hour to update the quarter hourly schedules.
This all makes DESS constantly chasing it’s own tail, initially I thought it helped to increase the power settings by 10% or more even but that’s the horse behind the cart as they say.
PS, I’m testing ways to fix above points with a Node-RED flow, works reasonably well especially w.r.t. those rounding issues to enable much better accuracy in (predictive) scheduling and therewith reduction of all kinds of scheduling ‘artifacts’ (at the end of a charge or discharge ‘run’ foremost). Otherwise said: better precision in rounding the hourly to quarter hourly targets gives better acccuracy in scheduling what should work for both Trade and Green mode. On our ‘trade-only’ system above listed issues are not ‘masked’ by the added complexity of solar (and consumption) forecasting and solving them therefore more notably critical for a good functioning setup.
I’m too new to DESS to have worked with the dognose hack but from Node-RED DESS I learned it has a useful b-goal_SOC and b_goal_hours setting. I’m using those to trigger ‘battery balancing’ on and off in VRM DESS which I assume mimickes this Adhoc Charge setting. I tried other ways such as the ‘keep batteries charged’ setting and even constantly overriding the ‘forcecharge’ setting to 1 (on) but switching battery balancing on/off (based on the Node-RED schedule running in parallel with VRM DESS) adds the advantage that the effect on the schedule forecast is visible in VRM and leaves most of the system operating ‘normally’ which is better from a systems design perspective.
It happened again today by the way.
Seems like DESS is ignoring my 0 kW export power setting and the setting that DC coupled PV surplus should not be injected.
If I set the DESS “Can you sell energy back to the grid?” value to “No”, the system behaves correctly - but then I no longer see the injection price graph.
Requesting it via the VRM API returns a value of 0, so that doesn’t work either.
When you set Feedin to enabled in DESS, that (currently) takes precedence over local ESS Settings.
We are internally discussing if it should be that way, or the other way round.
On one hand, local settings are “closer”, so should win.
On the other side, DESS is not ESS, setting and releasing Feedin-Allowance is a crucial part of the strategy, when it comes down to negative prices - so DESS settings need precedence to make this happen.
If you are not allowed to feedin, then don’t tell DESS you are allowed
I have a comparable situation: I want to force DESS to charge (or discharge) at maximum power (for one or more full hours) but the option that ‘just works’ (keep batteries charged) disables the VRM forecasting charts. I ended up creating a schedule override flow that sets current hour schedules and keeps track when dess changes them back, so it can reapply the required schedules when needed: on the hour, on the quarter hour and once in between, about 8 times per hour total. This way DESS can still do DESS and VRM updates hourly to realign with the new SoC.
That works but I keep wondering whether I am missing some option somewhere that makes all that not needed. Maybe I’ll try if I can intercept the schedules directly from VRM and use VRM-API to patch those hour by hour but I can’t figure out (yet) what, where and how dess is driving the ‘master’ scheduler.
Right, using “Keep Batteries charged” will drive DESS into an “Off/Error-State” (There’s nothing to dessify, if batteries shall not be touched), and when DESS is off, VRM won’t display the DESS graphs.
Hi, thanks for replying - that does explain a lot.
In the discussion on which FeedIn restriction setting should “win”, how about “the most restrictive”, be that local or DESS ?
It makes perfect sense that DESS restricts FeedIn in case of negative injection prices, local setting to allow FeedIn should be overruled then.
At the same time, local setting to not allow FeedIn (like in my case) shouldn’t be overridden by remote DESS to enable FeedIn.
Well, that’s what I think
Maybe what bothers me most is that I set a 0 kW export limit in DESS and it ends up being ignored.
Maybe/probably a value of 0 is interpreted as “do whatever you like” ?
Thinking out loud here: grey out certain options in the ESS menu if they’re overridden by DESS ?
Or a precedence toggle between “Off”, “Manual / $value” and “Auto - DESS” ?
A message like “Local settings can be overridden by DESS” in the local ESS menu, or in the DESS manual, would provide a lot of explanation.
Not to point blame but the DESS manual could do with an update.
Considering the amount of development that’s been ongoing on Venus OS 3.60 and DESS it’s understandable that the manual lags a bit - otherwise it would need to be rewritten every week.
But if no big changes are coming in the near future… *hint*
Well, maybe I’m allowed to but I don’t want to ?
(Grid voltage high but still within tolerances for example)
That kind of feels like an argument on who’s making the best decision on what to do when, which kind of defeats the purpose of using DESS.
I understand the desire for wanting to override DESS and then my approach would be the same as yours: override the schedules.
That’s about what is most likely the best approach, even though it would require the user to configure Feedin in 2 Locations (local and VRM) to make it actually happen.
I’d argue that a Node-RED flow should always be able to ‘overtake/override’ DESS in the now without having to shutdown DESS altoghether.
I’d love to see some binary options in VRM-API such as: charge (discharge) this hour or in your situation limit feed-in. I expected that to be possible and to some extend it is, but that ‘master scheduler’ keeps resetting schedules back to the ‘regular DESS’. Anyway, I settled for making it an endurance race: by monitoring the input nodes my flows now ‘reset the reset’
