DESS ... sadly even with FW 3.62 still the same stupid and obvious errors

[woody888]

Why on earth is victron not able to remove the most obvious strange misbehaviour out of DESS that is annoying for many month now???
Besides some improvements over the recent months, there are obvious errors in the DESS code that prevent it from properly working, making it still pretty useless.

*) frequently the system buys very expensive power from the grid and stops drawing from the battery, especially on higher consumption like charging the car, sometimes even at peak prices, despite a pretty full battery. This misbehaviour even happens during the night in a scenario where the next day is expected to offer plenty of cheap or even free power from the grid and strong solar production is expected, and yet is suddenly stops using the battery and drawing from the grid at peak prices, and as this is not crazy enough it sells battery power later to the grid at a much lower price.
There is no scenario where this would make sense, this is an obvious error - PLEASE FIX THAT, THAT COSTS A LOT OF MONEY !!!
Only way to stop this stupid behaviour is to disable DESS, then the battery is used immediately for own consumption as it should be.

*) even if DESS behaves in an expected way following its prognosed schedule, sometimes for no noticeable reason the system stops for 5 to 10 minutes doing nothing, and continues after that with what it did before… this is nonsense and should not happen!

It seems the system does stick way too much to it’s calculated schedule, and completely mishandles changes in consumption like plugging in a car. Covering own consumption as much as possible by battery must have absolute priority instead of following some schedule to sell power to the grid.

*) On another system with pretty stable consumption curve over many weeks, and a power pricing that offers cheap to free energy prices during noon almost every day, the system charges the batteries only half for no good reason, that leads to buying expensive power during the night at high prices,…WTF ??
Why did he stop charging batteries that are barely half full, which would cover all consumption during the night?

*) still no option to limit selling power to the grid, at least in green mode the system should only sell power to the grid if prices are very high and it is pretty sure that the SOC is high enough to cover the night.

[Diessel]

I watching this situation for a long time, and more others too.
I’ve only one answer to this question.

@woody888

Why…???

@woody888

PLEASE FIX THAT, THAT COSTS A LOT OF MONEY !!!

That’s why.
It costs a lot of money to you, but not to Victron.

[dognose]

@woody888

On another system with pretty stable consumption curve over many weeks, and a power pricing that offers cheap to free energy prices during noon almost every day, the system charges the batteries only half for no good reason, that leads to buying expensive power during the night at high prices,…WTF ??
Why did he stop charging batteries that are barely half full, which would cover all consumption during the night?

If you could give me the VRM Id (numeric one in the VRM url), I could have a look, if this is technical or schedule related.

Schedule related:
The schedule only charges from Grid, what it expects to be necessary through the night. So, any consumption above forecast would not be covered. DESS won’t just buy a random amount, when grid is cheap (cause buying is always costing money), it will just buy, what it predicts to be needed additionally.

However that depends on the accuracy of the forecast, and if the user tends to do unforecasted consumption.

Technical:
The scheduler is fed with configuration, such as a maximum chargerate. On some systems, local restrictions (Current, heat, BMS, charge Voltage) are not setup in a way to allow this rate. So, it may happen, that the energy which the Scheduler plans to buy in 2 hours cannot be bought in 2 hours. That either leads to defered, more expensive charging in the 3rd hour - or to not enough energy beeing bought, when that 3rd hour is too expensive.

@woody888

sometimes for no noticeable reason the system stops for 5 to 10 minutes doing nothing,

The reason is most likely that the target soc for the given window has been reached earlier than calculated.

That may be caused by too high consumption, less solar than assumed - but another common usecase is, that the battery size in VRM is configured too large*. Then, the scheduler would assume to need 5% SoC for a certain hour, but the system already used up that 5% after 45 minutes.

(*too large could mean: Used a vendor optimistic value instead of nominal capacity, have batteries that already degraded, have the SoC of the BMS not beeing accurate towards the actual energy amount beeing used)

Yet, this is something we now adressed and should be part of the next 3.70-beta.

[UpCycleElectric (Jan)]

Aside the importance of having the system performance parameters set as accurately as possible, there seem to be a recurring issue with the DESS algorithm(s) not being aligned with what is generally being expected from them. Could you elaborate a little more about the current and future development plans to improve upon the current Green and Trade modes? And has or will Victron consider adding additional DESS modes based on community requests/requirements, possibly supporting an open source effort to do such a thing even?

[dognose]

I’m not aware of any new modes or future integrations.

We are continiously monitoring user feedback, system-scheduling and system-reaction and derrive improvements on (frequently) occuring issues, yet, rolling out even tiny changes affects several thausand systems, so need to be tested well, before even beeing part of a beta.

The DESS algorithm follows a very strict mathematical model - it may not always be easy to figure out why certain decissions are made, but Expectation/Behaviour missmatch usually comes from wrong expectation.

Also keep in Mind, that the DESS-Scheduler has to make decissions BEFORE any moment in time. Looking back at yesterdays graph and spot 3 unideal behaviours is easy - but try to look at tomorrows graph and try to schedule your soc with a 1%-precission

[UpCycleElectric (Jan)]

@dognose

Also keep in Mind, that the DESS-Scheduler has to make decissions BEFORE any moment in time

That, is absolutely understood.

Still I’d argue that Victron bit off a little more than it can chew by shielding off two and only two DESS algorithm models behind a cloud wall that’s unsurmountable to climb by most of their clientele, whilst otherwise positioning itself as the industry’s open source champion. The shear volume of variation in thinkable DESS strategic use cases would, imho truly, make a very strong case (not to say a no-brainer) to steer the higher level DESS model/strategy developments towards the (wisdom of the) crowd, not her own proprietary cloud.

For inspiration on this very topic:

Ref: Tesla’s Open-Source Patent Strategy | by Keyur Ramoliya | Medium

PS, point in case: why isn’t there even any development in sight of creating an opportunity for already up-and-running Victron DESS operators to participate (collectively) in the 2 or 5 minute grid unbalance energy market? Not to be confused with the hourly or soon to be quarter hourly dynamic forward pricing energy market? The Victron DESS hardware platform is surely capable of serving that market already, so where is the software platform plan to facilitate such a forward looking strategy? Is Victron going to leave that up to a handful of proprietary energy brokers locking their customers in to their proprietary inverter and battery (storage capacity) hardware solutions?

[heinzi00]

I have still the issue with FW 3.62 that batterie sell to grid.
Today 18:03

a little bit later 18:17

[UpCycleElectric (Jan)]

Maybe have a look at what some of us are trying to do about that ourselves :

Another Strange DESS behaviour

Why do have such large differences set in sell and but price? I think that can really skew DESS of track (unless that is really what your energy provider charges and pays) . I have seen some people set an offset on purpose but that can much better be done by increasing the battery cost itself. Also, what are your b_goal_SOC and b_goal_hour settings? I can’t really put my finger on it but I think you need to revisit your basic power and capacity setting to make sure those are as accurate for …

UpCycle Hybrid DESS Trade

I uploaded a cleaned up version of my DESS price schedule logic here: Another Strange DESS behaviour - #26 by UpCycleElectric [image] AND [image]

[dognose]

@heinzi00

I have still the issue with FW 3.62 that batterie sell to grid.

Do you have a battery2grid restriction that should not allow this to happen, or why is that an issue?

Or do you just expect something different to happen for that moment in time?

[heinzi00]

That might have been poorly phrased from my side. The timing wasn’t very well chosen — electricity was sold from the battery, and shortly afterward, the battery had to be recharged at a higher electricity price. Unfortunately, too often electricity from my battery is fed into the grid, and as a result, there isn’t enough power left in the battery at night, so I have to buy additional electricity.

[jkoljo]

This failure to support self consumption at night is a major issue for me as well. At the moment I use only ESS because it ends up saving me more money.

Our bathroom floor heating seems to be one troublemaker for DESS. It’s a 1-2kWh 0.8kW load that occurs 1-3 times a day, at totally random times. If it happens during the night, DESS usually did not reserve energy for it.

[B51-technician (SunMachinist)]

Maybe there is a need for an alternative (additional) DESS green mode, or maybe more an ESS with a second power source - cheap grid. At least from my observation and reading through the DESS posts, that might be a solution for many customers struggeling with DESS for different reasons and switching back to ESS.

DESS - alternative Green Mode (ESS with cheap grid buying)?

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…

I was also using DESS in my system and switched to ESS as soon as the sun took over in March.

[heinzi00]

The issue exists every day, that DESS sell Battery to grid and afterwards I have to buy expensive energy from grid in the morning.
It looks like many other users have exactly the same problem.

Below you will find screenshots were you see that DESS sell batt2grid and in the morning the system have to buy from grid.

27.06.2025

28.06.2025

29.06.2025

30.06.2025

01.07.2025

[heinzi00]

It’s happening again.

The strange thing is, that it plans to buy energy on next day in the morning!

Can someone explain me the logic behind this?

[Diessel]

This is explained very simply: - An imperfect forecasting algorithm.
For correctly to work batt2grid, it’s necessary to optimize the evaluation of the SOC residues before the start of PV generation.

UPD:

IMHO: - I think batt2grid is possible during peak hours with high prices if:

The residual SOC is able to provide self consumption (based on the history of the previous 7-10 days) + minimum SOC before the start of PV generation.
&
The next day of PV generation can provide the target SOC + self consumption.

If this condition is met, such problems will not arise.

[matthiasu (Matthias Urlichs)]

@Diessel

This is explained very simply: - An imperfect forecasting algorithm.

That doesn’t really explain the above comment

@heinzi00

I have still the issue with FW 3.62 that batterie sell to grid.

Seriously, the thing isn’t imperfect, it’s (still) broken. Which is somewhat strange IMHO, since writing a model for an LP solver (LP=Linear Programming) like ORTools that keeps your battery charged and optimizes for €€€ is not rocket science. I did that two years ago (still haven’t gotten around to updating it to current Venus unfortunately).

[dognose]

Yes, that is about right. DESS calculates the - what you call - residual SoC and only sells down to that value.

So, as a consequence, any imprecession in the forecast (or unforseen consumption) will cause that value to be insufficient and cause some Grid pull during the night.

It is a “edge case” resulting of trying to maximize profit by only keeping as little energy as assumed to be needed in the battery, even when running Green-Mode.

The Issue is beeing actively looked at, meanwhile an option could be to set a battery2grid restriction for the evening hours to avoid energy beeing sold from the battery to grid, reserving the battery for self-consumption only.

Another workaround may be to reduce the maximum discharge power in the DESS settings, so that the amount of energy that could be sold to grid can be minimized. I.e. if you usually have 3 hours where DESS would sell for profit, and only want to sell a maximum of 15 kWh, just set a maximum dischargerate of ~5kW.

[Diessel]

I know well how things are not only with you, but also with your competitors.
Today, no one has an ideal software solution.
Accuracy can be achieved by installing additional automation.
But this requires large budgets and large capacity of the ESS.
I’m an engineer and design LV/HV systems up to 500 kW and ESS up to 2.5 MW.

Just keeping watching on you all, this helps to make decisions in projects about what to offer to the customer.

[heinzi00]

@dognose thanks for your feedback

@dognose

Another workaround may be to reduce the maximum discharge power in the DESS settings, so that the amount of energy that could be sold to grid can be minimized. I.e. if you usually have 3 hours where DESS would sell for profit, and only want to sell a maximum of 15 kWh, just set a maximum dischargerate of ~5kW.

I already applied this solution yesterday, but sometimes it results in my Fronius being limited.

@dognose

Yes, that is about right. DESS calculates the - what you call - residual SoC and only sells down to that value.

When the system starts selling batt2grid, it sets the SoC to 0%. Only after some time does it reset the SoC to a higher value and then start buying energy from the grid again. This will repeated several times.

I know it’s not easy to find a perfect solution for all systems, but the current one is really not good.

If you what you can monitor my victron system.

My current system looks like this:
3x Victron MP2 5000
1x CerboGX
1x RS450/100 (no modules are currently connected)
2x Gobel GP-SR1-PC200 15kWh (LiFePO4 51.2V/280Ah)
1x Fronius Symo 5.0-3-M on ACOut I (PV 4,830 kWp)

[heinzi00]

@heinzi00

@dognose

Another workaround may be to reduce the maximum discharge power in the DESS settings, so that the amount of energy that could be sold to grid can be minimized. I.e. if you usually have 3 hours where DESS would sell for profit, and only want to sell a maximum of 15 kWh, just set a maximum dischargerate of ~5kW.

I already applied this solution yesterday, but sometimes it results in my Fronius being limited.

Now I have the case that victron limited my Fronius.
DESS calculated a SoC of 63%

When this SoC is reached, Victron limits my Fronius instead of selling to the grid.