For those looking to learn about DESS and Node-RED, I am sharing my hybrid dess trade flow, as-is, very alpha ‘work_in_progress’ but still interesting for those seeking some examples on how to get things done with Node-RED, DESS, VRM-API etcetera. Sorry can’t offer too much help with it but at least I tried to make everything as clean and self explanatory as possible.
To get anything working you will need to import at least ‘node-red-contrib-boolean-logic’ plus whatever is needed to get Node-RED DESS up and running and replace all the ‘null_use_your_own’ id and token stuff.
If I will (ever) find the time to do a full documented version I will start another thread under ‘show my system’, until such time you’ll need to DYOR.
Schedules: Node-RED DESS is leading in setting charging schedules based on its ability to set ‘b_goal_SOC’ (at 100%) and ‘b_goal_hour’ (at 18h) . When Node-RED DESS schedules to charge before VRM DESS does, VRM DESS gets triggered into ‘keep batteries charged’ and ‘battery balancing’.
I really like the boolean libraries, such as ‘node-red-contrib-boolean-logic-ultimate’. Makes it so much easier to conceptualize these workflows. flows (1).zip (2.5 KB)
hardware related stuff will need to be inspected and adjusted of course
no need to get ‘spooked’ by the complexity of the flows, 90% in there is for monitoring, debugging and testing purposes: what I build to learn myself.
purely the functional part will be, in the end, much more compact and streamlined. but as-is this flow comes close to getting full insight & control over both vrm-dess and node-red dess
Over 80% is for monitoring and debugging, the core logic itself is much smaller. I try not to ‘hide’ any flow logic in function nodes or context (flow, global) variables to keep sight of what is going on. It’s a toolkit more than anything else, I keep in mind I want other people to be able to use it as well (when ready to go from alpha to beta testing).
Prices: for buying I include the energy tax, but for sell I leave that out. That is making up for the difference.
I know currently we get tax back while we can still compensate here in NL, but I want to assume we are already passed that…
The plans for ending the ‘saldering’ regulations and the introduction of feed-in fees are primarily affecting fixed price contracts. Dynamic contracts do not work that way, only if your yearly solar production is larger than your yearly consumption (being a net producer to the grid on a yearly basis) you will run into an edge case where the taxes are not reimbursed. Until such moment, sell and buy price are truly equal (on tibber at least).
But my point is more that we are trying to get better results from the DESS algorithm right now, to that goal I suggest to set it up as clean, simple and accurate as possible, work with that until the behaviour is fully understood, and only then add tweaks such as restrictions and custom pricing.
I expect your will see a strong ‘sell to minimum SoC’ bias when you set VRM DESS to Trade mode and actual (equal) buy and sell prices. My flow assumes that sell bias to be present and provides a buy trigger to create a more balanced trade behaviour.
