If you don’t mind please refer to the link below for the use case. And for the dates I can be short: everyday that presents enough price volatility to make trading profitable. If I would have to point to a single key factor, it is the fact that we run a dedicated large capacity DESS Trade only system. No Solar, No other loads, just trading price volatility. As a trading strategy this cannot be executed correctly with only a ‘sell to min SoC’ biased algorithm, that is only half of the solution. There needs to be a ‘buy to max SoC’ biased algorith in place as well to enable trading the other half of the ‘profit making’ strategy.
I believe the reason that this seems to have disappeared of the radar (if it ever has been on there to begin with) lies in the reality that the popularity of Solar installations far precedes the development of adding (large) battery capacity and the developement of ESS and then DESS.
With solar power production (in kWh per day) initially far exceeding battery capacities I can understand that most systems were served reasonably well with only a ‘sell to min SoC’ bias algo. But times have changed, as our system demonstrates, our battery capacity allows almost a full day of contineous selling (not realistic just to illustrate size), our system usually tries to optimize buy and sell strategies runing over multiple days upto a full week to capture the most profitable price differences.
In context thereof, not having any (official) means to introduce a buy bias to the scheduler, without abusing all kinds of other settings that should really be left alone to function as intended, such as minimum SoC itself, is the core of the problem we encouter when developing and optimizing our trade systems.
Hope that explains it a bit better, ask me anything if you need more details. On when it works, when not, what we tried, how we forced it to work with our hybrid systems etcetera.
In summary, without a means to bias the scheduler to buy energy (within the ‘known prices’ time schedule), it will always plan to deplete the battery al the way down to minimum SoC at the end of the known price schedule, and therefore quite predictably miss any and all low price buying opportunities for which it cannot yet see the selling opportunity (because that opportunity lies beyongd the known price schedule). Therefore the system once charged up to what it knows it can sell within the known price schedule, will refuse to charge up further even during ridiculously cheap or even negative price levels. The system as-is has no ability to take into account the very predictable reality that there will be profitable sell opportunities the next day just as well. And then by the time the new dayly price schedule rolls in, early in the afternoon, many many hours of profitable buying opportunities will have been left unused all morning of the current day.
The workaround we used the last half year with substantial succes was to run the Node-RED DESS scheduler in parralel with the (active) VRM DESS scheduler. And by setting the Node-RED DESS scheduler to target full battery at dinnertime, it provided a very usefull alternative target SoC schedule long before the next day pricing came rolling in. From there it only took some clever decision logic (that also looked at absolute price levels as a secondary decision criterium) to enable a charge overide flow (temporarily setting VRM-DESS to ‘balance battery’ that day via VRM-API call) until the next day prices became available, at which point we could disable the ‘battery balance’ again and let VRM-DESS do its own thing again until next morning. Once we had the secondary price criterium tuned in reasonably well, this systems has been performing near perfect right upto this weeks changeover to 15 minute pricing, but that’s an issue we can solve.