That would be nice to have in vrm as well.
I Always have the problem, that - until next day prices are available - the system schedules for 20% (min soc) at the end of the day.
Then, it suddenly realizes “Uh, but I would need 45 soc at the end of the day”, has to adjust the roadmap and make some less ideal stuff to catch up, because the very cheap hours have already gone by, while beeing “fine for the 20% target”.
It is a good idea with an extra setting we can help the system.
But what we need is that Dess not start buying and wait until prices are low.
The system is so busy with the SOC-value that it forgets to look at the best price.
+1
I would like this option of a lower treshold for selling too 
Maybe something to add:
Greetings from Finland
3 days old system and learning to use DESS. Battery 280Ah@48V. It is winter in Finland now and the panels are not producing anything. Electricity prices vary greatly so I was hoping there would be limits to charging and/or discharging the battery. For example, the battery is not discharged if the price is below 4 cents/kWh but electricity is saved for the more expensive hours by force. I also wished for a regulation forcing the battery to be fully charged e.g. if the price is below 2 cents/kWh. But good job Victro and I wish a long life to the DESS.
By the way, has Victron thought about a reserve market for electricity
Same “problem” today, the battery is fed into the grid and recharged in the next hour even though there are more expensive hours ahead.
I assume that DESS takes into account the efficiency of the system. Where can I change the efficiency?
Because I have actived blocking of battery discharging to grid, the bigger deal in Trade mode for me is using power from PV instead of using power from grid in case of negative price… https://community.victronenergy.com/t/vrm-feature-announcement-manage-negative-energy-prices-in-dynamic-ess
Better behavior is to use grid and don’t use PV for grid stabilization, extending lifetime of MPPTs/solar panels and better energy bill which should be the goal of Trade mode.
I experience the same problem, DESS sells to much electricity in the evening. When in the evening, night or the morning some device uses more energy than predicted the electricity is bought from the grid while it’s more expensive than when it was sold causing loss.
A configurable dess minimum soc margin of 5 or 10% would be enough to solve this problem.
That’s right, I proposed a second minimum SOC a month ago, but there was no response to this.
Hi all!
In the first version of DESS in BETA, we actually had this. We opted that since DESS already had so many settings to consider, for the first roll out it would not be clear enough what ‘DESS MIN SOC’ would do.
Now that we have advanced settings in Dynamic ESS, and considering that so many of you have a need for it, I will put it back on our roadmap, so we can work on this before the summer.
Thank you all!
Great! It would be cool if there were also a max SOC (or something) to allow a buffer for the days where DESS over-estimates consumption and under-estimates PV. We’ve seen situations where the system ends up inadvertently exporting power because the battery reaches 100% too quickly when self-consuming (while it could have discharged more overnight, but instead reserved power, thinking it would be needed). Not to overcomplicate things.
That is great news! Regarding the implementation, I strongly suggest moving away from the ‘DESS Min SOC’ terminology for this feature. In the Victron ecosystem, ‘Min SOC’ is synonymous with battery protection and discharge floors.
A much clearer name would be ‘FeedIn SOC’ of ‘Trade SOC’. This name immediately identifies the threshold as a ‘gate’ for exporting energy, rather than a safety limit for protecting the battery.
Here is how the ‘ideal’ Green Mode should function using this ‘FeedIn SOC’ limit:
Storage First (Below FeedIn SOC)
The system treats the battery as the absolute priority. If the current SOC is below the user-defined FeedIn SOC (e.g., 90%), all excess solar is routed to the battery. Grid feed-in is disabled. We are not ‘trading’ yet; we are building a buffer for our own security.
Injection Only for ‘True Surplus’
DESS should only plan to sell energy if the forecasted solar yield for the day is mathematically certain to exceed the FeedIn SOC (e.g., a ‘planned SOC’ of 120%).
Strategic Overflow (Above FeedIn SOC)
Once the FeedIn SOC is reached, that extra 30% ‘overflow’ can be injected into the grid during the most financially beneficial timeslots. Crucially, the core buffer (everything below the FeedIn SOC) remains untouched and off the market for the user’s security.
Why this is better than plain ESS
We don’t want to lose the ‘Smart’ capabilities of DESS; we just want to change the priority. We still want DESS to:
Predictively Charge: Use the grid to top up the battery during cheap ‘off-peak’ hours if it sees that tomorrow’s solar won’t reach the FeedIn SOC before the high-price peaks hit.
Predictively Discharge: Use the battery to cover heavy loads during peak-price windows to maximize savings.
Essentially, we want the Predictive Intelligence of DESS combined with the Storage Security of plain ESS. Right now, DESS is too optimistic—it gambles on its own forecast by selling early. A ‘Storage First’ logic using a FeedIn SOC ensures that even if the forecast is wrong or there’s an unexpected load spike, the user has their defined buffer as a hedge.
By making FeedIn SOC a configurable setting, Victron gives the user the power to decide their own balance between ‘Energy Security’ and ‘Trading Efficiency’ based on their local rates and seasonal weather.
I fully agree with this statement and would like to add that from my perspective, which concerns a pure DESS TRADE system without any solar, there is very big issue with the fact that the MinimumSoC setting (no matter the naming even) carries two specific technical functions that are completely unrelated:
This double use has severe limiting consequences for systems that do not have a significantly large secondary energy source such as solar. The scheduler will always plan to oversell down to an ‘end of known price window’ target SoC equal to MinimumSoC, which in practice prohibits the scheduler from taking advantage of trading opportunities.
I believe this dual-use-one-setting function of MinimumSoC has an historical reason related to solar based setups, where indeed it can be (but nut necessarily need to be) a good strategy to aim for an empty battery at the end of the known pricing window. For trade systems without solar this makes absolutely no sense whatsoever.
