I have no arguments against that.
The tricky part is that VRM DESS schedules are, and need to be, pushed (or pulled) regularly, and that new data overwrites the local data.
One argument there could be that VRM DESS shouldn’t overwrite the local copy if that was written by a local script, but that would require gigantic blobs of glue logic to make that work.
Another approach could be to write your override schedule not (only) locally, but (also) to VRM.
That way the fresh copy from VRM won’t overwrite your local copy and it would also make VRM aware that you have your own plans for the schedule.
How to do that ? I have no idea.
That’s not needed because DESS recalculates it’s schedules in the first 7 minutes of the hour anyway to compensate for reality not matching the plan (or it’s bias due to rounding issues)
The most frustrating part (in my use case) is that the Node-RED DESS already has a suitable ‘higher level’ function: b_goal_SOC and b_goal_hour that is not (yet?) available in VRM DESS. I wouldn’t mind switching to Node-RED DESS for that function alone were it not for the announcement of it bring phased out.
One of many ways to get my way anyway (actually the first thing I tried) is to keep setting
com.victronenergy.hub4(0)/Overrides/ForceCharge
to 1 everytime ‘someting somewhere’ resets it to 0. What is then about every 5 seconds. Works like a charm but I shy away from such a low level ‘hack’ because I can’t oversee any ‘unforeseen consequences’, such as ‘flash memory wear’. But if somebody (@dognose ?) could ‘unworry’ me about that I’d like to give it another try.
I mean, there are literally 5 ‘overrides’ defined right there: feedinexcess, forcecharge, maxchargepower, maxdischargepower, and then some other too. That does set expectations.
(I did plough through all the VRM-API custom nodes looking for something to suit our requirements, didn’t expect a manual, did expect some of it to do what it implied)
Anyway that was three months ago, when my workbench contained about 10 nodes, this is what it is now:
If I understood this post correctly, the “Phasing out Node Red DESS” plan only encompasses the ‘victron-dynamic-ess’ node in favor of the all new and improved ‘vrm-api’ node.
The option to steer DESS from Node Red will (and should) remain.
Question remains if/when the new node will have all the features that the old one has, as stated in that topic.
Let’s leave that discussion in that topic 
1 Like
Well, fair enough. Just learned that tibber postponed 15 minute pricing to end of September (at least) instead of rolling it out around right now (with no intentions from Victron Dev Crew to implement 15 minute schedules in Node-RED DESS), there is still some time.
And by the way, its is precisely that ‘victron-dynamic-ess’ node that allows scheduling upper SoC targets, whereas VRM-API is lacking such a feature (actually, the settings are there, just doesn’t work). This may not be all too important for all the solar first, battery next ESS systems (that are more suitably served with lower SoC targets), for us with trade-only-no-solar DESS things are a bit different, we need to target those upper limits. Best is to be able to do both.
In the end I’m convinced we will have a mature and robust VRM based DESS that will suit most use cases ‘out of the box’ with the ability to ‘nudge’ it in various ways into various directions by means of Node-RED flows. I guess that is the argument I am making here: allow Node-RED nodes and/or VRM-API settings a transparent and well defined means/path to claim ‘root access’ to override the DESS master scheduling system. A ‘duo-job’ so to say, not as black and white as ‘who’s master’. Implementation of such an idea need not be too difficult, boils down to allowing Node-RED to set parameters ‘read-only’, preventing VRM-API or DESS to overwrite what is modified through Node-RED explicitly and intentionally. A ‘persistent’ check box in the custom nodes, with a big red ‘void your warranty’ flag, could do.
You could probably just disable DESS to avoid it setting these paths.
1.) Set /Settings/DynamicEss/Mode to 0. That will turn DESS off.
2.) Now - when only ESS is active - nothing should mess with the /Overrides-Paths.
3.) So, you could set:
/Overrides/ForceCharge = 1
/Overrides/MaxDischargePower=-1.0
/Overrides/MaxChargePower=4000
4.) And when you’re done, just set /Settings/DynamicEss/Mode to 1 again, it will take back “control” over the Overrides. (Except the MaxChargePower, DESS is not using that)
There is no harm in writing these paths over and over, they only exist in memory. However turning DESS off while doing so would make sence, not sure how some back-and-forth of these values may be handled in the internal firmware of the multiplus.
LOL, that is precisely what we are trying to avoid. With reason: DESS works very well to figure out the nitty gritty of finding the best (most profitable) scheduling, I don’t want to take control over that, just need to be able to ‘nudge’ the scheduling targets somehow. Best of both worlds.
But thanks for thinking along. More to the point of one of my ‘black spots’: I read some old post about flash memory wear (in context of mqqt / modbus targets?) . That in combination with my still limited knowledge of the venusos/victron/tech platform spooked me away from running regular ‘override’ messages in Node-RED every 5 seconds. By now I start to think that is not something to worry about but I’d rather be safe than sorry. Any ideas what needs to be taken in consideration in this context?
And yes, I am monitoring D-Bus round-trip times, no worries there.
I join you in ‘not reading before writing’, didn’t catch this until just now. Thanks.
1 Like
Could you (@dognose) assist in getting the SoC target rounding bug listed with the devs? The case is quite simple and I have a working workaround (less simple) but I believe it can affect many other systems then just ours, worthwhile looking into.
The bug:
- When charging at full power with DESS, the scheduler consistently underestimates the targeted SoC with exactly one percent (1%).
- This causes repetitive throttling of charge power and re-scheduling.
- The root cause lies in the rounding of the floating point hourly SoC targets to integer quarter hourly SoC targets.
- For discharging these targets are correctly rounded down, for charging they should be rounded up, but are also rounded down. Hence the distorting effect on the scheduling accuracy.
- This should be a oneliner fix IMHO
- The hard part is getting it noticed by the correct dev/team.
PS, if needed pls move this msg to a more suitable location.
I’ve noted that already, but there are a few more steps than just rounding up or down.
The 15 min windows may break a otherwise linear chargerate curve into 4 pieces, worstcase with a +/- 1% soc difference. (3%, 2%, 3%, 2%)
Having the target SoC beeing higher accuracy to allow “2.5%” per window would only resolve that for systems also reporting decimal soc-values. Majority doesn’t.
Didn’t put too much thinking in that now, as other issues are a bit more important, but got that in the back of my head 
1 Like
Yeah I had to solve one ‘end of charge session’ edge case in my ‘override’ flow but other then that the bias towards discharging seems pretty clear to me.
By the way, that charge curve is all but linear with our 12S Li-NCM system running between 40V to 50V. The BMV calcs SoC as an Ah percentage, not actual kWh. Not too much of an issue, especially not for all the LiFePo4 ‘flatten the curve’ systems, at least a full order less of concern, but still.
Once in Node-RED, it’s pretty easy to take the amphours to create your own (higher) precision SoC%. Even with a BMV I still do that.
With a 2000 Ah (90kWh) battery and 0.1Ah precision (consumedAh) that already provides 2,5 digits in percentage (0.005%)
It’s a wonder really how accurate these BMVs are once you know how to drag it out of them.
Anyway. I have a list of issues waiting for the new beta to open. But this one above I think would deserve extra attention due to its wide ranging impact.
EDIT:
Currently I calculate a higher precision SoC based on consumed Ah and use the rounded up integer to compare with the target SoC and adjust that when needed. Next I am going to try a time shift of 15 minutes, shifting next quarter hour’s target SoC to the current quarter. That potentially solves the same issue without needing to bother with the end-of-charge edge case.
