Dear Victron developers,
I read almost all posts regarding DESS and I completely understand the complexity of forecasts. We always know better after a day is gone. It’s much harder to know what might happen the day before. 100% agree. Whatever algorithm is chosen, it could always be right or wrong in particular cases like unusual consumption.
Nevertheless, there seems to be a pattern in many feedback posts. From my observation, there’s a wish for a kind of “alternative green mode”. Or maybe it’s more ESS with a second power source: Cheap grid.
I personally would go for such a mode and if I understood many of the feedback posts correctly, such a new additional mode could act like that:
- Step away from the strict math calculation for a target SOC in such a new mode.
- Charge battery to 80% (or more) either on own PV or cheap grid costs in case PV is not getting the battery to 80% (or more).
- This would eliminate in many cases unexpected buying on high costs from grid
- I know, the downside would be potentially: Increased battery cycles and some energy loss in unnecessary battery storage or AC/DC/AC conversion. But having enough battery can be seen as additional benefit in case of power outages for the ones choosing this mode.
Should be less complex as DESS but meet the need of many DESS/ESS users.
1 Like
For our trade only system (no solar) the current VRM DESS algorithm is missing a significant part of the profitable trade opportunities. I can’t speak towards Green mode as I lack the experience but for Trade mode the culprit seems to be the fixed strategy of targeting Min-Soc at the end of the known pricing schedule.
Based on the assumptions below, I created a Node-RED flow that allows us to temporarily force the system into ‘periodic full charge override’ (PFCO) based on a combination of parameters.
Assumptions:
- VRM DESS always targets minimum SoC at end of the known price schedule
- Scheduled SoC targets do not work while running VRM DESS
- Significant low price buying opportunities occur (and are missed) early day before new prices roll in
- There are no plans known to enable scheduled SoC targets for DESS
Workaround:
- Run Node-RED DESS in Trade mode parallel (but not active, DESS mode stays on 1 : auto)
- Set a high to target SoC around dinner time in Node-RED DESS, while keeping the other settings identical to VRM DESS
- Poll Node-RED DESS hourly to see if it tries to charge the battery to achieve that SoC target, and create a charge signal based on that.
- Combine the charge signal with other preconditions, price related foremost (on dynamic price contracts) to create a charge override signal
- Force VRM DESS into PFCO only during the hours that the charge override signal is on/high/true.
For our system this delivers the desired the behaviour with the least possible interference with VRM DESS during the other hours of the day.
I think this approach could be useful as well for people running VRM DESS in Green mode as well but can’t test that because we cannot (yet) add solar to our system.
With the basic components of our Node-RED flow now working reasonably, my current challenge is to come up with the (dynamic) price based logic that gets combined with the Node-RED DESS Trade signal as additional condition for activating PFCO. Here an example of the ‘work in progress’ on that:
@UpCycleElectric , I am always impressed about those Node-RED initiatives to improve DESS or to implement an own algorithm. No doubt, great ideas and great job.
However, my post and suggestion had a different goal: an additional, alternative, Victron (D)ESS mode with focus on ESS + cheap grid. To avoid the known DESS grid imports at times with high tariffs.
Without the need to install Node-RED + own scripts and with full Victron support.
As good as custom Node-RED modifications would be, I assume that Victron support would be lost. Something I do not want, at least for my system.
Maybe another, extra, post would be good to dig deeper into your solution for those who want to go down the Node-RED road with own algorithms.
I was under the impression that using Node-RED is supported albeit with caveat that the end user carries responsibility for not making obvious unwise modifications. As my flow only toggles the PFCO switch on and off, I assume that to be safe.
But yes, additional or improved VRM DESS mode’s are preferred if and when they come available. Hopefully some functionality now implemented in Node-RED will then become obsolete and unnecessary.
