I’m working on an open source implementation to optimize my home BESS, using state-of-the-art forecasting models, model predictive control, mathematical optimization, and dynamic electricity prices. A first working version is already done.
Out of curiosity I wanted to have a look at Victron’s Dynamic ESS implementation to compare approaches – but after some searching I couldn’t find the actual optimization logic anywhere. The victronenergy/dynamic-ess GitHub repo only seems to contain a Node-RED flow that calls a VRM backend, not the solver itself.
Is the optimization algorithm intentionally closed source, or am I missing something?
Or to put it differently: does anyone know what the optimization algorithm roughly looks like?
Looking at the Node-RED source (victron-dynamic-ess.js), the client simply sends system parameters (battery limits, cycle cost, price formulas, country, target SOC) to https://vrm-dynamic-ess-api.victronenergy.com and receives a pre-computed SOC schedule back — so the actual optimization seem to run entirely on Victron’s backend, which seem to be closed source.
The earlier Python prototype by tfranssen (github.com/tfranssen/dynamic-ess) used a simple “charge if price is below average” heuristic. Does anyone know whether the current VRM backend still uses a similar rule-based approach?
I have little experience with DESS Green mode but from longtime monitoring a high capacity pure DESS TRADE mode system I have quite a clear understanding of what that does, albeit not exactly how. The basics are:
Historical data collection for loads and production (solar)
Building a loads profile heuristic and calculating loads forecast tables
Building a solar capacity heuristic and apply weather forecast scaling of the solar capacity to calculate solar production forecast tables.
The scheduler only needs short term loads and solar forecast tables enough to cover the rolling 'known day-ahead pricing’ window (10 to 36 hours) but from VRM (and API) it can be noticed the tables run a little longer ahead.
Combining the VRM DESS battery/system capacity, costs, power, efficiency, limitations and other settings to calculate a short term (couple of days) energy ‘enveloppe’ translated to (or expressed in) a State of Charge (SoC) ‘enveloppe’.
Importing day-ahead pricing dayly, calculating energy cost/profit based on the set pricing formulas and then run a deterministic (DESS Trade) optimization algorithm to calculate which SoC execution profile that still fits the enveloppe will a) end at MinimumSoC at the end of the known pricing window and b) delivers the highest profit (or lowest loss) based on a four state decision per price window (15m): buy, sell, passthrough, self-consume.
The scheduler seems to run three distinct different update/re-align loops: quarterly, hourly, dayly. Of which the quarterly loop seem erratic for about a week already.
My distinct impression is that the trade optimization algorithm is the least complicated part of it all. Maybe that is different for DESS Green, but for DESS Trade that algorithm seems not very intelligent (some combination of a search tree and what-if analysis) not to say it has serious architectural flaws. A search on my username will show more on that topic.
Hint: If I were to build my own DESS algorithm, I would import the loads and solar forecasting tables via VRM API and run a proprietary trade optimization algorithm against that to calculate the forward SoC scheduling tables. I also would not expect much of a cooperative attitude towards such an endeavor from official or semi-official sources, despite the ‘open source’ branding.
For context: My implementation runs model predictive control every 15 minutes with mixed-integer linear programming, which finds mathematically optimal schedules. I’m planning to do open-source benchmarks against simple heuristics like excess solar charging, or rule-based approaches and maybe also against Victron Dynamic ESS — which is why I was curious about what’s running under the hood on their side.
I’ve been working for a while with my own DESS-like implementation. Why: The current DESS is not really useful if you have zero export abilities. Mostly, it keeps using the grid when I have plenty of PV, and does not discharge the battery even if the forecast totally overlaps any future consumption.
A month ago, I started developing a custom solution that takes control over the whole PV system. This is a workflow:
There is a Host console app that connects via MQTT and subscribe to various topics like PV generation, grid, battery and consumption
It gets updates in real time, packs generated energy and other info into 1m buckets and publishes them to InfluxDB
It also connects to VRM to get PV forecast every hour, progressively updating it, store in 1m bukets in Influx
It gets connected EVCS data and pack it to influx in 1m buckets
If gets weather data for next 24h from Open Meteo API, store in 1m buckets in Influx
You can configure shelly devices (like meters, wall sockets, EM) to get consumption from them as well, all data is also pushed to Influx in 1m bucket. I made ability to specify device role
Gets forecast for grid availability next 24h in my location (hello from Ukraine, yes, I need to take into account how long I will have grid at my house)
So Host is accumulating and storing info in Influx. Ones a day it also creates a ML training dataset from accumulated data from previous day in PostgreSQL
Then I have Python script that grab training dataset from the database (postgres) and train LightGBM model for:
15m consumption forecast
1h consumption forecast
15m SOC forecast
1h SOC forecast
And publish trained models to repository
Then Forecast.Worker (another service) grab these models and make a progressive forecast of consumpton and SOC hourly, recalculating next 24h and next 1h
Based on this data, and various other data I have, I’m now working on Rules engine that will:
Set min SOC
Decide if to charge the car or not
Decide if to turn on Smart Grid on the heat pump
Optimize the maximum SOC at the end of the solar day
Turn off some appliances if there is a risk of low SOC
Provide a recommendation (like “its good idea to run the washing machine as there will be plenty of sun”)
Fow now I’m testing forecast models. I still have not a lot of data to train, so need to invest 1-2 months more into data collection. Now I’m focusing on defining an extendable rules engine.
Many other parts are comparable to my work, but on that I have to work again. 