We currently have a few really profitable selling hours here and there, typically in the evening. As PV starts getting lower towards the winter, DESS is sometimes unable to get the charge it expects during the day. If it planned to sell-discharge to zero, the selling can be cut short because the battery runs out of charge.
I think DESS Trade mode should plan to have some buffer, like 5-10%. It’s not really good for the battery to fully discharge it anyway, so why does DESS Trade specifically aim for that when it could aim for some buffer?
That is because (VRM) DESS Trade targets minimum SoC at the end of the known price schedule. More than not this is not a profitable strategy.
There are workarounds, none of them very satisfactory. Node-RED DESS has a function to instruct the scheduler to target an additional SoC at a specific hour of the the day. We use that ability to run a Node-RED DESS schedule parallel to the VRM DESS schedule and added decision logic when to force our DESS Trade (only) system to charge. Works well but still a hack. Unfortunately Victron refuses to engage in a dialog regarding this issue. Use search for many many more details.
Tried all the same with DESS over time. With each new firmware. But there is not that one single fix to it. DESS will continue to act silly for many users, unless Victron one day may understand that their whole DESS approach has to be questioned. For me, many of the problems could be solved if Victron would give us a bunch of new settings. Some like “dont use grid if < SOC x”, “ use grid to battery only when price(time) is between this and that”, etc. p.p. But again: for me it looks like they are fixing and extending a piece of software that never was designed well.
My impression is that Victron is staring itself blind on the most complicated to predict use case of Solar in DESS Green mode.
Seems to me that Victron is so invested into getting that to work that they simply cannot take a step back from all the efforts that went into that to regain sight on the issues at the top of the requirements specification tree, the functional and performance requirements for DESS as a whole from the customers perspective.
As a systems engineering professional (1) it is saddening and to some extend frustrating to see a ‘full fledged sunk cost fallacy’ with pinch of ‘not invented here syndrome’, in effect to a point where it now has become a ‘social risk’ on this very forum to point out that ‘the emperor wears no clothes’.
(1) https://www.incose.org/
I don’t even care anymore for any extra functions that can reliably be implemented by ourselves with Node-RED. My ‘beef’ (for the lack of a better word) with VRM DESS is fully reduced to the single one issue that cannot be solved post scheduler in Node-RED: A pre scheduler function to instruct the VRM DESS scheduler to accept ‘user specified’ SoC% targets.
I have yet to learn why this is such an issue with VRM DESS when Node-RED DESS is happily capable of doing precisely that by setting b_goal_SOC and b_goal_hour. A cynical mind wonders whether that has anything to do with the complexity and lock in of design choices of the DESS Green mode scheduler. Unfortunately that part (the scheduler logic and design) of DESS is not open source or otherwise available for analysis . Why is that Victron?
We went the other way: running a Node-RED DESS scheduler (with that b_goal function set to target full batteries at dinnertime dayly) parallel to the VRM DESS scheduler. From there on the problem got reduced to a very well manageable boolean logic decision tree under what conditions which scheduler ('s schedule) takes precedence for the next hour. That solved all other problems in a deterministic way.
On a higher abstraction level I think it would be a very promising solution to create a two tier general DESS scheduler. A first tier ‘deterministic’ scheduler set up to optimize a trade only schedule based only on (known) dynamic price forecast, a second tier ‘uncertainty’ scheduler that creates hourly SoC target delta’s to be superimposed on those of the trade scheduler.
But well, how am I to bypass the ‘not invented here syndrome’ issue without access to the actual scheduler source code? That’s the hill I stranded on in this whole DESS saga.
That ‘bunch of settings’ can be implemented in Node-RED, I’d advise to use the boolean logic ultimate nodes to implement a well structured desicion tree for that otherwise you will soon get lost in your own ability to overthink and overcomplicate your own solutions as I did at first. It took multiple refactoring rounds to clean our post-scheduler decision logic up to a point where I succeeded to understand my own ‘yesterdays’ thinking.
You can set min-SOC with VRM-API. The problem with that is that this effectively ‘hyjacks’ the min-SOC function from the scheduler that then fails to schedule for discharging below the set minimum SoC in the future. What is needed aside a (reasonably constant) minimum SoC parameter, is a target SoC or a maximum SoC for the scheduler (to target, duh) at a (specified) time before scheduling towards the minimum SoC afterwards.
Having both a minimum SoC ánd a maximum target SoC (at sometime in the near future) allows for the scheduler to calculate both sides of the trade equation: buy low, sell high.
Exactly my impression! I’m always hoping that someone publishes a Node-Red implemented system, that takes over the DESS functions itself. With Victron ESS fully controled from there, on a high level. I know similar behaviour from other (even OSS) software projects, where some developers block some bold feature requests for no apparent reasons, for years. Maybe its time to open a Thread that is about user solutions to better control ESS? Or is there already some external solution published you would see as the current best practice? In addition, the solar forecast that Victron uses, so often doesn’t fit reality. And again, its about quite simple things: Repeatedly i see it on rainy days: Victron forecast is about as if it will be a normal, partly sunny, partly cloudy day. But the normal local weather forecast already yesterday gave strong weather warnings of heavy rain for hours. This is so often not included in the “Victron weather”. So my additonal target would be to include a better forecast system.
I was well on my way to publish my solution until I hit a brick wall concerning the phasing out of the b_goal_SoC and b_goal_hour function for VRM DESS. It just seems not worth my time and attention to (have to) reverse engineer the (Victron proprietary) VRM DESS scheduler, just to port that function from Node-RED DESS to VRM DESS
You can do a search for my request to make DESS a top level category for better visibility and structure. If Victron is willing to support a community effort to improve on DESS ourselves, I’d be willing to reconsider putting more effort into that again.
VRM Dashboard page, settings button in top right-hand corner for manual setting of minimum SoC
Cerbo GX screen or app: setting button top left corner
But for all non static / conditional uses of a variable minimum SoC to steer DESS behaviour (what I strongly discourage), you’ll need to design and build the logic to do so with, in which case Node-RED+ VRM-API or other Victron nodes probably your best bet.
Again, minimum SoC already has a well defined function, overriding that function in an attempt to make DESS behave the way you want, completely messes up the DESS scheduler. In which case you are better off not using the DESS scheduler at all and focus on implementing your own basic charge/discharge scheduler in Node-RED and then add use case specific logic to switch between the DESS scheduler and your own scheduler whenever the conditions for one or the other are met. That’s what we did, albeit with an added hack that our homebrew scheduler is actually running the Node-RED DESS scheduler in parallel to the VRM DESS scheduler.
