I may have missed a post but can someone help me understand values 2 and 3 for Strategy ? I cannot find any documentation other than 0 and 1.
@dfaber is this related to your plans to move some of the logic from cloud to Cerbo to prevent delays in response to local/unexpected variations ?
@dfaber Any chance you can comment on this new feature ?
I guess you’re running latest beta Venus OS…
The meaning of the static strategy stored within a schedule window is explained here:
But there also is a new reactive strategy now which is more fine-grained than this and determines how the system dynamically reacts to the combination of static schedule and actual live data:
Many thanks! But the comments behind the line items are not as self-explanatory as I had hoped 
And the reactive strategy you have found is currently not available on dbus I think.
Hopefully someday soon documentation will be updated so I can better understand the intention. Being a mixed AC-PV / DC-PV user I have lots of DESS decisions I disagree with. Tuning the decisions with node-red works, but are not always easy as schedule and target soc are only updated hourly.
So I am very anxious to find out how these new plans will effect DESS.
It is! DESS Reactive Strategy Homeassistant Template
And what I can say so far is that the new DESS algorithm works much better than before because it will adapt better to forecast errors and also waste less energy to the grid.
Thanks for that. It would still be a very big help if @dfaber can post draft documentation as without the knowledge above, DESS is behaving very strange.
In the Netherlands we mostly run in trade mode with buy-price=sell-price. This makes the pricing equally important to green mode but the forecast is not very interesting. You either buy or sell and along with it, you charge PV or sell PV. No self consumption ever. No regular ESS.
I noticed last saturday morning and this afternoon that the reactivestrategy was set to values 4 and 13. As a result the system started to charge the battery with PV only to unload it to grid the next hour. But prices were high with only a 5 cent difference. With battery costs set to 4 cents and efficiency to 80% this behaviour results in almost 20% energy losses.
Without the new reactive feature, PV would feed in which is the most economical decision.
@dfaber Upgraded to ~66 and the result is the same as before in trade mode:
The hour after that, by now the morning is well underway:
I created a flow in the early DESS days to ensure DC-PV is always stored in battery by using a dynamic grid feed-in value based on consumption. Backed by a flow to determine DESS buy and sell plans to disable this functionality.
The side effect of this flow is that it luckily also resolves the grid dump once the system has charged out of low-soc.
I guess I will turn it back on as the reactivestrategy functionality seems to be primarily designed for green mode. Is there any chance you can share some documentation or post what you want beta testers to test ? I can imagine more beta testers in trade mode not fancying the rather costly effect of running this beta.
Hi all !
I just found those news strategies and values available through NodeRed & MQTT.
Struggling to understand what is it all about.
Is there anyone able here to explain the meaning of the various strategies & reactive strategies values ?
Thanks
Matt
I use trade mode and have not been able to figure it out yet. From what I have been reading it’s only related to green mode. To fix VRM forecast deficiencies using logic on the Cerbo itself.
For example, forecast says solar delivers 2kWh between 14:00 and 15:00 resulting in SoC increase of 10%. Consumption forecast was correct but solar forecast was incorrect. So target SoC is reached too soon at 14:30 and the sun is still shining.
With DESS, the remaining (probably another 2kWh) solar will feed in to grid. Whereas the correct solution is to continue charging the battery to prevent feed in, possibly having to buy it back later.
The new reactive strategy fixes this locally on the Cerbo. I think…
It is mostly based on this work: [DESS HACK] Unexpected Bat2Grid and Solar-Feedin. (Green Mode)
I’ve been tracking the settings since last weekend.
While I still don’t understand exactly what are the two new strategies, the reactive strategies bring what seems to be a “timely” strategy approach - bringing to the next question: what’s the interest of the “strategy” value ?
Right now the reactive strategy shown surprising reactions, such as changing 3 times its status in a 15 seconds timeframe. We’ll see over time.
The strategy is basically an information on how to “behave” within a certain 15 minute window.
The reactive strategy is what the gx decides to do, to achieve the best possible strategy fullfillment without violating any of the window constraints provided.
It will monitor local solar, consumption, grid and battery values, and as any of these values change, another reactive strategy may be more suitable to achieve the intendet goal.
For example, when the advice is to charge 5% SoC, there may be different reactions based on all parameters available:
All of this may happen within seconds, leading to a different reactive strategy for a few seconds.
Basically the “strategy” is a very compact if-then-else-instruction, and the reactive strategy is the gx following that constraints by continiously monitoring local values.
Any chance the ReactiveStrategy can help me fix my low soc versus MPPT charger issue ? Since Victron removed the individual DESS min soc setting, I have been unable to prevent the DC charging “bounce effect”.
As long as the system is in low-soc condition, all MPPT charging has to go to battery causing the soc to rise above schedule in Trade mode. As soon as it reaches min-soc+3%, the low soc condition will clear and it will start to invert like crazy only to reach low-soc again and start over.
That story repeats itself until you are very lucky and the min-soc +3% happens at the moment VRM is recalculating and takes the current soc as the new idle schedule. Or until DESS has a far higher schedule (Trade mode buy).
I haven’t had a chance to test but my assumption is that with the new reactivestrategy in green mode, this may no longer occur. But in the Netherlands, the use of geen mode will only start early 2027 when the “salderingsregeling” disappears.
What you describe sounds indeed like a undesired behaviour.
We are currently looking into trying to avoid ESS#1 during DESS operation at all, as it also has other undesired side-effects (not charging from grid, when desired) - If it could be avoided, that would basically also resolve your Issue.
Overriding schedule with node-red during those hours. But with pricing and weather in the Netherlands, this is triggering every day for months now.
The flow basically determines the active schedule number 0-7 and if DESS is active and if soc current schedule = minsoc then write current schedule minsoc +2.
Pretty basic but it does the trick.
I use a mix of enphase and victron mppt so I have had this problem for quite some time now.
Whilst you are working on that, can you read from the DESS settings if the user has configured a 15min or a 60min schedule. Based on that you can decide to apply the reactive strategy for smooth transition only once per hour instead of every 15mins.
Or am I misinterpreting the logs and the logic ?
Little bit. The Schedule will always be 15 Minute blocks, even with hourly prices. The “Smooth” reactions are to kick in, whenever target soc is reached a bit early before a window end, to avoid unnecessary charge / discharge interruptions for a short amount of time.
than my system must be responding incorrectly as it stops every 15mins for a little less than a minute. Whereas target soc for the whole hour is set on every 15min schedule. And that target will never be reached in the first 15mins as it is intended to take a full hour.
In trade mode, as a result you loose about 4x45secs =180 secs which equals about 5% of inverting capacity during a 60min sell window.
The system only enters the transition states, if target soc is reached with the last 90 seconds of the window. (Then, it will just keep the current (dis-)chargerate for the remaining time.)
We did not span this further, because when the schedule spontaneously changes, and no more (dis-)charge is required in the next window with the updated schedule received, the deviation would become big.
If your system is reaching targetsoc EARLIR than 90 seconds before window end, it will take a break. In that case, you should lower the battery size configured in VRM a bit:
The reason for reaching target soc early is caused by a too big battery size in VRM. Then, the calculation estimates that the system should discharge for example 5% soc in 15 minutes, but in reality it does discharge 5% in 12min 10 seconds.
Battery Size may be “(apparently) to big” for many reasons: Just wrong; already some degradation happened while the BMS compensates that in the soc reported; non-accurate / linear calculation of the SoC-Value by the BMS, …