Grid Setpoint is not working for negative values.
When I set ess grid setpoint to 200 watts I see 200 watts of grid usage. But when I set ess grid setpoint to -200 watts de grid usage is around 0.
Dess is active in my setup.
I want a small amount of grid feed of -10 watts because the meter of the utility provider measures about 10 watts when victron measures 0 watts.
I think this happens when bat2grid restriction is in place.
Will the issues with DESS also be solved in this beta?
DESS is mostly a VRM thing, not heavily relying on Venus OS.
All the calculation for DESS is done on the VRM side, the GX device just executes the schedules it receives from VRM.
Thatâs not entirely correct anymore because VenusOS is performing local optimizations too now.
Thatâs why I said itâs mostly VRM 
If my reverse engineering is somewhat correct, VRM side calculates a schedule based on predictions of solar yield, consumption and SoC.
GX side performs some extra checks to make sure the received schedule doesnât contradict with certain parameters.
Somewhere in the linked topic there was already a reply from Victron that the mentioned behavior isnât linked to VenusOS itself.
For Green Mode and for sure Trade Mode thereâs certainly still some room for improvement, but itâs not as easy as it may seem.
When irregular big loads (running an AC or charging my motorbike) come in the picture, the prediction system gets thrown off and then things get really tricky really fast.
An argument could be to provide a âheads upâ system, a notification to the DESS algorithm that a large load is to be expected.
Usually I know in advance when I will be charging my motorbike and for how long, so that load could be easily injected in the DESS calculations.
Running AC is less predictable, unless it runs on a regular schedule - then it will be picked up by DESS.
Then one can argue if all that really needs to be possible with DESS.
There will never be a âone size fits perfect for allâ solution.
For running Trade Mode, the best option would be to keep irregular loads out of it so the system can make optimal use of all predictions.
My own opinion is that running Trade Mode on a consumer connection with consumer grade batteries is simply not worth it, or at least not with the contracts we have here (BE).
But thatâs a personal opinion, to each their own 
I tested this and the behavior has changed. At this moment the scheduled SOC is 100% and the battery is used for consumption when there is not enough PV power on 3.70~6 while on 3.70~5 the grid is used because the scheduled soc of 100% is maintained.
Only downside with the current fix is that the battery is also used while it is more profitable to use the grid and keep the charge for selling a few hours later.
So it might solve the issue of using grid instead of battery when target soc has reached, but it should only be used when itâs more profitable to use the battery instead of grid.
Hi,
it is not a âalways-like-this-fixâ. The behavior you (and others) had was caused by a certain strategy having an âexceptionalâ rule to go idle instead of using battery.
This behaviour has been updated to be âinlineâ with the behaviour the other 3 strategies would show.
So, what happens in this situation now depends on the strategy selection, and ofc. The Scheduler should only select that strategy, when it does make sence.
We will ofc. Monitor this during the beta phase, see if it requires adjustments, or if the strategy selection now needs to be altered a bit as well, as the behaviour slightly changed.
Does that also cover the case where DESS discharges to minimum SoC and the âoptimized with batterylifeâ algo increases the âactive SoC limitâ by 5%, practically always triggering an unwanted (a) charge run the next hour. (a) Unwanted as it is most likely that prices are unfavorable for charging that following hour.
No, not related to that. Actually never heard/read that, so that is something we probably need to look at.
Most likely not well known because there are just a handfull of systems that actually use battery-life along with DESS, because with DESS beeing able to do regular/scheduled balancing thereâs little need for this combination [which mainly is there to ensure batteries reaching 100% one or another day for balancing]
Well, with DESS as-is not yet performing as-required, we (as many others Iâm sure) are exploring the use of whatever means available to make it behave a litte better for our specific needs. What works well for us can be seen as a deliberate balancing act between DESSâs schedule based minimum SoC sell bias and a countering, price-opportunity driven full battery buy bias. The use of âbatterylifeâ helps preventing a slow drift towards an empty battery over the timespan of multiple days and longer. In the bigger picture it is not too bad to pay a small price for that (in the form of a 5% net loss sell-buy cycle once every so many days, or weeks even), but it ainât great to my OCD mind.
Actually I want to use battery life so I always have the maximum electricity available when grid fails but also have the most possible soc to charge pv and sell at high price. In winter time a higher minimum soc is preferred because pv doesnât always cover the energy usage during the day so a higher soc is needed throughout the day to prevent outage.
I am not sure if this is related to this new upgrade, but since a few days the DESS function has working poorly. The other day I noticed I did not see any DESS data in VRM and not possible to see the DESS settings either. It looks good in the Remote Console. And the behaviour of the system is as normal ESS. VRM portal ID if something needs checked: c8df84d34272.
Dess is again discharging during low energy price to grid. The problem is that dess has a target soc of 50% while there is 53% in the battery while it should should charge from excessive solar production.
Not sure if itâs related but yesterday, in trade mode, the battery charged to 100% only to start feeding 11kW back to a charging EV. VRM schedule said to stay at 100% for at least a couple more hours. Quite an expensive decision.
I use MQTT to home assistant to map and log the new reactive strategy values but I have not updated the new ones yet. So for now, the status was called unknown meaning it was apparently new
Checked again but the behavior persists. In trade mode, once DESS has finished charging and has at least a few hours before selling, the new âSELF_CONSUME_ACCEPT_BELOW_TSOCâ kicks in and seems to switch to and from âSELFCONSUME_NO_GRIDâ every few secs/mins. Probably due to consumption whilst the PV inverters are still producing.
Like my earlier message where an EV was charged from battery, in trade mode this is unwanted and rather expensive behavior. I can image various use-cases in green mode, but not in trade mode.
If you could give me your system ID (the numeric one in the url), I could pass that on to the scheduler Team to have a look at it. Trademode does not âreserveâ the battery exclusively for trading, It just creates an overall most profitable schedule.
That however could mean, if it is - monetary - preferable to use bought energy to drive loads and avoid (more expensive) grid-purchase instead, it will do so. That will lower your trading-amount, but overall saves you money on that day.
But thatâs something to look at in detail, without seeing the prices during that time and intended sell-prices later that day, itâs just guessing. However, Seeing SELFCONSUME_NO_GRID as you mentioned, indicates that the scheduler said âPulling from grid NOW is not desiredâ, so battery will be used to account for âmissing solarâ, when loads exceed consumption.
Send you a pn, so you donât have to share your id here.
I live in the Netherlands with a dynamic contract and âsalderingsregelingâ. In fact, sell prices are a little higher than buy prices lately for âZonneplanâ. Therefore, there is never ever a moment in which DESS should decide to self consume from a cost efficiency perspective. Itâs always better to trade.
Please note that this behavior happens the other way around as well. I have lately been observing that DESS decides to charge PV into battery outside of the normal charge plans. In fact, itâs doing that right now (probattery / selfconsume_accept_charge)
I have seen that with the system of a friend as well but itâs never consistent. Or to put it differently; itâs not a guarantee that if I observe it, the other system does the same thing or vice versa.
My sell price with zonneplan is a little higher than my buy price so once the target soc of the latest schedule has reached, there is no need to store excess PV.
Update: This is not an issue, raising the system efficiency to 87% did work, the battery is longer used for self consumption. (0,1827/0,75 = 0,2436 plus battery cost is aproximately 0,2574). So system efficiency is used for charging and for discharaging as far as I can see.
Some strange thing I notice today, the sell price is 0,1827 and the buy price tomorrow morning is 0,2699. Despite that, DESS sells current PV energy to grid for the low sell price and buys electricity for consumption from grid tomorrow morning, while it would be more profitable to charge the current PV energy to battery and use it tomorrow morning.
DESS System Efficiency (/Settings/DynamicEss/SystemEfficiency) is set to 75% (still unclear if this is round trip or one way efficiency Is system efficiency same as roundtrip efficiency) as a test I raised it to 87%, which worked (see update below).
Today:
Tomorrow:
Today at 16:00 charging of battery stopped unfortunately:
Raised efficiency to 87% works:
This will be solved in 2027 as the regulation will stop by then.
