DESS needs a rework from SCRATCH

After strugling myself with DESS, I finally found (like many others) that an ESS config with minimum SOCs depending on the hour daily, is much more efficient per month that the dumb DESS (at least with a fixed-price per hour daily, with three price periods).

I only hope that this post encourages VICTRON developers on this matter; It will make a real difference with the competition systems if it is fixed, althought I undestand that the only limitations on the correct calculations are the limited system CPU capabilities, but there are still intermediate options that can cope with this limitations, doing a much better work.

Summarizing a lot, Victron’s Dynamic Energy Storage System (DESS) algorithm frequently exhibits counter-intuitive and economically irrational behavior, leading to significant user frustration, as you can see in this forum. This summary outlines the core failures identified in user forums and proposes a robust architectural framework to address them.

Part I: Key Operational Failures

The most common issues reported by users are symptoms of deeper flaws in the DESS control logic:

  1. Unnecessary Grid Imports: The system often buys expensive energy from the grid even when free solar power is available. This is caused by a rigid adherence to pre-calculated hourly State of Charge (SOC) targets, which the algorithm prioritizes over the more logical and economical use of available solar energy.
  2. Inneficient Import and Export calculations: DESS has been observed exporting battery power to the grid when the price is cheap while importing grid power to cover household loads at costly hours (to cope with the calculated SOC by hour). This inefficiency stems from a simplistic control architecture where the export command is a fixed power value, not a dynamic target for the “net grid position”.
  3. Risky Charging Strategy: The system often delays charging the battery from solar power until late in the afternoon. This “procrastination” is a high-risk strategy that relies on a perfect weather forecast; if clouds appear, the user is forced to buy expensive peak-time energy to meet evening needs.
  4. The “Tyranny” of the Hourly Target: The strict, hour-by-hour focus forces illogical decisions. The system will buy from the grid just to meet an hourly SOC target or export valuable energy if a target is met too early. This shows the system is solving 24 independent one-hour problems rather than a single, cohesive 24-hour optimization.

Part II: The Central Problem: Deterministic Planning in an Uncertain World

The root cause of these failures is that the DESS mathematical algorithm is deterministic and fragile. It relies on a single forecast for solar production and energy consumption as if it were a certainty. When reality deviates from the forecast, the system’s behavior becomes illogical.

Part III: Proposed Solution: A Modern Control Architecture

To fix these fundamental issues, a shift to a state-of-the-art control architecture is recommended, based on proven engineering principles.

  1. Adopt a Two-Level Control Architecture: Separate strategic planning from real-time execution.
  • Level 1: Strategic Day-Ahead Planner: This high-level module runs once a day to create an optimal 24-hour “target trajectory” for battery SOC and net grid exchange, based on price, solar, and load forecasts.
  • Level 2: Real-Time Tactical Dispatcher: This low-level controller runs every few minutes. It uses the strategic plan as a guide but makes constant, small adjustments based on actual, real-time measurements of solar production and load. This structure inherently solves the simultaneous import/export problem and provides the flexibility to deviate from hourly targets when it is opportune to do so.
  1. Implement a Model Predictive Control (MPC) Engine: MPC is the industry-standard framework for solving such complex, constrained optimization problems. It uses a “receding horizon” to constantly re-plan, making it robust to disturbances.
  2. Redefine the Objective Function: The MPC’s goal should be to minimize a comprehensive cost function that includes:
  • Grid Energy Cost: The direct financial cost of buying and selling electricity.
  • Deviation Penalties: Soft penalties to keep the system generally aligned with the strategic plan without being rigid.
  • Take into account the battery degradation; cycles are not free (I am not sure if now it is really taken into account).
  1. Manage Uncertainty: Move beyond deterministic forecasts to “Stochastic or Robust MPC”. These advanced methods optimize for a range of probable outcomes or a worst-case scenario, leading to more conservative and reliable decisions. This could be exposed to the user as a simple “Risk Tolerance” slider, replacing the crude “Trade” vs. “Green” mode switch.

By moving from a simple, rule-based system to a robust, two-level MPC architecture, Victron can transform DESS from a source of user frustration into a truly intelligent, reliable, and market-leading energy management system.

Thanks for reading. Written with the investigation help of AI Gemini 2.5 Pro. More details to the complete analysis here: TecnologĂ­a para un progreso sostenible: Un Plan ArquitectĂłnico para la PrĂłxima GeneraciĂłn del Dynamic ESS de Victron: De Fallos HeurĂ­sticos a OptimizaciĂłn Robusta

8 Likes

May I ask, which VenusOS Version your experience is from?

Hi @Ringmaster thank you for your extensive review and ideas!

A lot of what you describe and propose matches our own ambitions, and quite a bit has already been implemented per Venus OS v3.60, released quite recently.

Please give that a try and looking forward to your reactions.

? I’m sure you didn’t want to write nonsense here, but …

You cannot send power to the grid and import it from the grid at the same time. That’s physically impossible.

which doesn’t solve the problem at all, cf. DESS ... sadly even with FW 3.62 still the same stupid and obvious errors

One key problem could be solved in 3.70 (still beta):

Change log
v3.70~6
[…]

  • DESS: Avoid buying from grid after intended discharge

Totally agree, my bad, corrected the point 2 with what I meant.

Certainly, I was on 3.55 when tested DESS, but I will wait to a positive response from users of future versions to try again, as I can see it continues to fail as you have conveniently pointed out.

1 Like

It’s a pleasure to share my experience with the Victron community, thank you too, maybe I will give a try to 3.6 and share results. The promise of the Dynamic ESS (DESS) is fantastic: a smart system that uses weather forecasts and dynamic pricing to optimize your battery usage and deliver significant savings. However, in practice, I found that the DESS algorithm often lacks the intelligence to achieve this successfully. For me, a simple, manual charging schedule has proven far more effective.

The Problem: When “Smart” Isn’t Smart

When I first enabled DESS (on Venus 3.55), I quickly noticed some illogical behaviors:

  1. Wasting Free Weekend Sun: On weekend, with grid power at its cheapest (€0.08/kWh), DESS would charge the battery from the grid and maintain it at 70% SOC (LiFePo4 battery likes 40-50%). This meant that when on monday the sun was at its peak, my system couldn’t absorb the free solar energy and would be forced to export it. The optimal strategy would be to start the day with a lower SOC to maximize solar self-consumption, knowing that grid power is cheap if needed.
  2. Gambling on the Forecast (and Losing): In other instances, DESS would either keep the battery too full, wasting potential solar generation, or let it get dangerously low late in the afternoon. It failed to proactively charge during cheaper mid-day hours, even when the forecast made it obvious the battery wouldn’t have enough power to cover the expensive evening peak (18:00-22:00).

My goal is simple: self-consumption first, and only sell to the grid if there’s a true excess. The DESS logic was failing to deliver this.

My Workaround: A More Reliable Manual Schedule

Ultimately, I found I could achieve better savings by disabling DESS and creating a simple schedule based on my home’s typical consumption patterns:

  • 7:00 - 8:00: Charge the battery to a minimum of 35%. This provides me 15% of battery before the minimum SOC, just enough power to cover our morning usage (high prices until 14:00) before the solar panels start producing.
  • 16:30 - 18:00: Ensure the battery has a minimum SOC of 50%. This is my “bridge,” giving me enough stored energy to get through the expensive evening peak hours without buying from the grid.

Is this system perfect? No. On a very cloudy day, it might not be enough. But for the vast majority of the time, this simple, predictable logic is more profitable than the “dynamic” decisions made by DESS.

The Path Forward: How DESS Could Become Truly Dynamic

The core issue is that DESS seems to be programmed with rigid, mathematical SOC targets for each hour taking into account the forecasted prices and generation/consumption. It needs to be more flexible. Imagine if the system used a true Model Predictive Control (MPC) engine. Instead of just following a static plan, it would constantly re-evaluate its strategy.

For example, it could ask itself every 30 minutes:

“It’s 4:00 PM and my battery is at 30%. Given the forecasted load, solar production, and upcoming price changes, what is the most cost-effective action right now? Should I charge from the grid to prepare for the evening peak? How much energy do I need to bridge the gap until the cheap overnight rates kick in?”

By continuously asking and answering these questions, the system would become truly optimal. It would adapt to any situation—including unexpected high-consumption events like charging an electric car—because it would always be reacting to the current state and the near future forecast. This would transform DESS from a rigid scheduler into the intelligent energy manager we all want it to be.

Also, take into account, for the battery health, try your best to maintain between 30 an 60% for lithium batteries.

My config:

DESS example, here I was watching its behaviour, and based on the predictions, the system maintained a too high SOC; I had to “manually” reduce SOC charging my car from 13 to 14:30 to avoid “wasting” energy to the grid (this comsunption was not forecasted). After other suboptimal behaviours and this, I switched off DESS:

(text translated with Gemini 2.5)

Everything is fine and logical, in words and on paper.
By the way, why are you so hung up on SOC 30-60 for battery health? Who instilled these numbers in you? SOC 50% is recommended for long-term storage without use, more than 7 days. The rest of the time, the lithium battery must cycle, otherwise it simply degrades from inactivity faster than you use it with daily charges and discharges.

UPD: The only correct indicator of the efficiency of any ESS configured for storage/sale is the cost price of kWh and the cost price of each cycle.

2 Likes

Yes, around 50% is perfect, and thinking twice, at 70% is not that bad, you can ignore this sentence. I wanted to point out that keeping the loads so high for no reason doesn’t make sense.

Batteries must operate in their maximum efficient range every day, charging to a maximum of 90–95–100% and discharging to 20%. Then it will be economically successful. The criterion is the price of each cycle.

Dear Matthijs, I updated the Multiplus II yesterday to 3.62. For now it is working ok, but I can see the forecast for tomorrow, and it doesn’t look well (blue line: battery level expected):

Does it mean that the system ignores that I am not interested in selling to grid (As stated on DESS config “Can you sell energy back to the grid”, and I prefer to top batteries, and charge my car with those surpluses?

We will see… and let you know the misbehaviours happening the next days.

Hi David,
I’ve read your comments. I’m involved in testing DESS since the early days 2 years ago and I wont tell you that DESS is 100% perfect. But I’ve installated DESS on over 100 installations and have pretty much expierence. Using the SoC target was not my favorite choice but when you’ve set the right settings for both your battery charging and DESS itself, it runs just fine.
If I found customers complaining it has always to do with incorrect solar forecasting because of incomplete measurements, incorrect consumption forecasting (caused by large consuming devices like EV chargers) as well as wrong SoC measurements. So first correct these and then look into the DESS settings themselves. For instance, you showed a system import setting of 4kW but a battery charge rate of 7 kW. I understand that this might seem logic in from your point of view but DESS makes calculations on these figures and when they can not be met, SoC forecasting is inaccurate. It could calculate the battery SoC for the next hour based on 7kW charging rate but if energy is taken from grid it is ways behind. If you see strange charge and discharge in the same hour it always is related to these DESS settings. So check them and change them, you will get better results.

Greetings, @Hhalewijn

The accuracy of forecasting depends on identifying user patterns using the relevance of the weather. If you build forecasting head-on using formulas, it will never be perfect. In my opinion, the optimal solution for DESS would be to build 3-5 scenarios and check their relevance at intervals of 1 time per 5 minutes taking into account the weather. Something like “What If? Realtime”

1 Like

Warning: I’m adding no useful response to your suggestions, but your post gives me the opportunity to say…

I’m happy that you at least have the option to use ESS with a utility grid. Here in North America, Victron doesn’t allow us any grid interactivity, let alone dynamic ESS. ESS (and its predecessors) have been out for years in Europe and other parts of the world. You are rightfully worried about Victron falling behind competition in your part of the world. In my part of the world, we’d just like Victron to catch up to where the competition was 5-10 years ago.

I’m sorry for the whining, but I will continue to beat this drum until Victron achieves UL1741SB standards so we can at least use ESS on the public grid. Or, until MPV kicks me off the forum :slight_smile:

3 Likes

Dear Harold, I think you meant “Maximum discharge power” of 7 kW, that is the capability of the battery to give power, and for me it is correct. Could you elaborate more?
And the "Maximum charge power is the capability of the battery to charge (With solar and grid this could be meet). Correct me if I am wrong, thank you for your commentary!

If the system works as you say, and it is not taking into account the limits given (import, battery, etc) and so on… no comment.

Another example of misbehaviour. My forecasts are pretty accurate, as I have seen the last weekends, but there is something wrong, or I am missing something, or DESS is simply failing:


Today DESS imported energy to maintain a 100% charge; it is expected a very cloudy day, but with a lot of light comming trhough as you can see for the solar forecast.
I don’t understand why is wasting 4 kW of grid power with such a forecast.
In the energy chart, you can see that solar to grid exports aren’t even considered; they’re not shown at all. Why is this happening? 3.62 is supposed to avoid charging from the grid and then exporting…

No, this is not only physically possible, it is actually the norm in many installations. You feed in a single-phase power supply and draw power from multiple phases. The system simply balances the sums as much as possible. So, it’s normal to feed in power from one phase and draw power from another at the same time.

Thanks Tom for pointing that out, but even if it’s possible, that wasn’t the point of this thread about DESS.

Thanks to @dognose work, incorporated in 3.6.0, my experience of DESS has signficiantly improved as compared to previous version. Give 3.6 a go an then report back, not sure how much value there is in discussing <3.6.0 version DESS behaviour issues.

It’s still not perfect, I think there is still a bit more room to:

  • use setpoint functionality to react more quickly to changes in actual PV/usage.
  • improvements to schedule to discharge later in the day (in case weather changes)

But, these remaining issues only result in minor excess import/export so DESS is much more usable than it was before.