Thanks, I will take a look; now it is easy to automate it in node-RED with a function with your particular case, with the help of AI. Yesterday I was working on it; there is an evaluation at 4:00 on night to charge the battery setting the neccesary SOC for 3 hours with the consumption and solar forecasts, and actual battery, and during the day it reevaluates every half hour if it is convenient to do little additional charges on cheap hours.
I will test it through the next months, adjusting if neccesary.
Technical summary:
This system uses Node-RED to implement a predictive control strategy for a Victron Multiplus II ESS, with the goal of minimizing grid energy costs.
The controller operates based on the following inputs:
Hourly forecasts for generation (solar_yield_forecast) and consumption (vrm_consumption_fc) obtained via API.
Real-time battery SoC from the Victron system.
A hardcoded Time-of-Use price schedule (Peak, Flat, Off-peak).
The control strategy is divided into two primary modes:
Weekday Strategy
The objective is to cover energy deficits with power purchased during the cheapest (Off-peak) period.
Primary Charge (04:00): A main charge cycle is initiated based on the calculated net energy deficit for the next 24 hours (Total Consumption - Total Solar Production). A MinimumSocLimit is set to charge the required energy from the grid, respecting a dynamic, forecast-based solar margin (5-15%).
Charge Maintenance (04:00-07:00): The system enters a non-interference state (return null) to allow the primary charge to complete without being interrupted by subsequent script executions.
Predictive Adjustment (every 30 min, from 07:00): A simulation algorithm models the batteryās state of charge hour-by-hour until midnight. If the simulation predicts a point where the SoC would fall below the 20% base minimum, it calculates the required energy and sets a new MinimumSocLimit to preemptively charge in the most economical period before the deficit occurs.
Peak Hour Protection: During the most expensive hours, the MinimumSocLimit is forced to 20% to maximize the use of stored energy.
Weekend Strategy
The objective shifts to maximizing direct solar self-consumption.
By default, the MinimumSocLimit is kept at 20% to maximize available battery capacity for free solar charging.
On days with a very low solar forecast (<4 kWh), the MinimumSocLimit is raised to 40% between 10:00 and 17:00 to provide (for battery health) an energy buffer.
Here you can find more info and the json archive, that I will update if there is any improvement: flows.zip (3,9 KB)
What great summary exactly what I found
I use my own algorithm which seems to work a node red routine
Unfortunately this community wonāt let me attach the json file
But good look
Is there plan to make using a new parameter (do not sell when price is less than x ā¬/kwh)?
Yes I know that I can fake that when I enter into my selling price (p-0.1) but then cost calculation will go wrong.
I would like to enter 0,1ā¬/kWh the minimum price DESS can sell (Iām in Geen mode)
I ask because yesterday DESS did something that I did not liked. I have configured my battery cost 0,03ā¬/kWh and it sold when price was 0,0312 and then it somehow bought (I think some internal problem) some back. And together I sold 6,8kWh for 0,2ā¬ and bought 1,2kWh for 0,1ā¬, so gain 0,1ā¬ that is nothing
I assume that it sold because DESS thought that battery will be full next day and it needed some room. But I do not want to sell when I do not get at least 0,1ā¬/kWh. ANd if tomorrow is PV surplus I can always put it somewhere, to the EV or heat the water etc.
I just do not understand DESS decisions.
Yesterday evening at 21 selling price was 0,15ā¬ and it did not sell. And if I looked then todays forecast then it was not going to sell today morning either.
But today waking up I saw that DESS sold at 04 and at 07 when price was 0,016ā¬ and 0,045ā¬.
Why the heck did it sell today when it decides not to sell yesterday with multiple times higher prices.
And if you would introduce a new parameter (do not sell less than x price) this all would have been prevented
I am so glad Iām not the only one complaining. For me the gamble to set Target SoC to Minimum SoC lets me down too many times. Sometimes I use more than usual and minimum SoC kicks in at high prices. Victron should implement a target SoC window between which the dess tries to work, but is not limited to if forecasts are off. My battery reaches 100% SoC daily which is killing for cycle life, yet installers as Venematech call this normal. Ask any cell manufacturer, they say 20-90% gives good cycle life, 30-70% insanely good cycle life. Okay, going over these soft boundaries isnāt very bad or something, but consistently, daily doing this is just not what a DESS system should do.
Non public as far as I know. Iām of the opinion DESS is broken both on a systems level as well as organisational. Victron simply doesnāt have the resource to have their cake and eat it too, meaning: Keep core parts closed source such as the āassistantsā and the 'master scheduler backend a.k.a. the scheduling logic on their (cloud/VRM) computers while at the same time count on the open source/ community participation for field testing and providing actual real life use case requirements and feedback.
Not saying Iām not appreciative, just stating my opinion that weād all be better off if Victron would open source the whole DESS toolchain and focus on facilitating active community participation instead of trying to cling to some āsoftware as a serviceā (saas) strategy thatās neither here or there.
Today is similar situation (like it was yesterday) that it could sell evening but has decided not to, even tomorrow clearly shows that it will be full.
Yesterday it did not sell evening and sold in the next morning with 3x less price.
Will copy screenshot here so I can compare it tomorrw
So it sold for 0,1ā¬ and then bought back energy for 0,05ā¬ (why DESS ā¦ WHY)
What I have read is that 3.7 beta should do something for that behaviour?
@dognose can you explain DESS in this case (look my two previous posts where yesterday evening today night sales were not present)
And as I thought DESS decided to sell in today morning low prices instead of yesterday evening high prices And my battery cost is 0,03ā¬ but it still sold with 0,021ā¬ price at 6AM.
Iām not doing the scheduling, what I would assume here:
Consumption was forecastet high at 1,2,3 (System Overview Graph shows that even for passed hours)
So the system kept the energy in the battery to support āthisā expected consumption.
That consumption didnāt happen, so it decided to sell to grid instead, to empty the battery for the upcoming morning hours.
I always say: Looking back at āhappenedā things and determine that wasnāt ideal is āeasyā - but looking ahead and predicting what would be ideal is the tricky part.
If consumption would have happened as predicted, that plan would have been absolutely okay. But consumption was lower than predicted, so kinda Plan B was used to sell at somewhat ok prices before morning solar kicks in.
But thatās how green mode should work: Focus on cover own consumption, then just sell āat best pricesā whatās left over.
You should rephrase that: There was no energy āwastedā, There was just ālessā optimized profit than there could have been. Never the less still more than with DESS disabled - where you would have entered the morning on probably 70% Soc, leaving only 30% room to charge solar during unfavourable sell-price-hours.
And that is the reason i suggest a new parameter (do not sell less than this āpriceā from battery) then it is in my control. Because some of us do not want to just move energy for practically nothing.
I went to sleep knowing that i have 65% of battery and wake up with only 45% of battery. And I have EV and plenty of water I can dump energy
There are plenty of times when DESS solar forecast is overestimating. And then selling is not justified.
Also why did it sell with lower prices than my battery cost? When battery would be full then letting PV overflow to the grid would be more benefitial in this case
PS! And I saw this coming yesterday when I posted my screenshots. So this is not after analyzis
What brothers me most is that I canāt trust DESS plan at all.
Today morning I looket it and saw that selfconsumption pv to battery and evening sell from battery.
But then at 12:24 I saw that DESS is buying from grid with 6kw of power. That is strange because 7 day forecast is showing more pv than consumption
Here is what DESS did out of the blue and I have " Yes, enable charge* battery from grid restrictions" in weekdays from 7 to 22 Yes, so it ignored that.
I have custom function node in node-red that is gathering all this data from flow and when ādess_reactivestrategyā changes is writing it to text file. Then I can afterwards understand what was these values when reactivestrategy changed.
The info if feed in to first function node from:
com.victronenergy.system (0)
/DynamicEss/ReactiveStrategy
There is also change node that is changing topic to āReactiveā
First function that insures only changes are sent:
var previous = context.get(msg.topic);
//when deploy then it is undefined
if (previous == undefined)
{
// change the same we have right now
context.set(msg.topic,msg.payload);
previous = msg.payload;
node.send({topic: msg.topic, payload: msg.payload});
}
if (msg.payload != previous)
{
context.set(msg.topic,msg.payload);
node.send({topic: msg.topic, payload: msg.payload});
}
return;
second function after 500ms delay
if (msg.topic === 'Reactive') {
// Build a JavaScript object using flow context
let payloadObj = {
dess_strategy: flow.get('dess_strategy'),
dess_reactivestrategy: flow.get('dess_reactivestrategy'),
dess_restrictions: flow.get('dess_restrictions'),
dess_activerestrictions: flow.get('dess_activerestrictions'),
dess_targetsoc: flow.get('dess_targetsoc'),
dess_currentsoc: flow.get('dess_currentsoc'),
dess_gridpower: flow.get('dess_gridpower'),
dess_gridsetpoint: flow.get('dess_gridsetpoint')
};
// Convert object to JSON string
let finaltext = JSON.stringify(payloadObj);
// Get timestamps
let utcTimestamp = new Date().toISOString();
let localTime = new Date().toLocaleString('en-GB', {
timeZone: 'Europe/Tallinn',
hour12: false
});
// Create final payload
msg.payload = `${utcTimestamp} (UTC) - ${localTime} (Local) - ${finaltext}\n`;
return msg;
}
there are these change nodes where I write to flow all the parameter I need
(Dont be confused by that oscillation on the right - itās caused by a switching load (electric oven))
The only gotcha you may run into is that VRM will not show forecasts and schedules on a 15min grid but 60mins. But in practice itās running at 15min intervals as you can see in above where itās charging from grid for a 15min period and also in the following graph where the strategy changes in 15min intervals:
Only the current DESS target SoC looks quite odd to me, itās taken from venus/N/xxxxxxxxxxx/settings/0/Settings/DynamicEss/Schedule/0/Soc and looking into the future, the succeeding target SoCs (Schedule/1/SoC, etc) are the same until 1h later where it jumps.
what are your key performance parameters: battery capacity in kWh, battery power limits, grid power limits, charger/inverter power limits? any solar involved and running dess trade or dess green?
