Did zonneplan not switch to 15 minute pricing? That’s interesting.
Nope they didn’t.
When I have selected hourly tariff the graph shows 15 minute te tarrif.
Sorry for the dark screen, night mode is on at my phone.
Update, changing hourly to quarterly saving it and changing it to hourly again solves this issue after a while.
Another issue I see sometimes is when a new hour is started and the soc is a bit lower than the target soc of the new hour dess starts charging. For example I had 42% at 21:59 but for 22:00 43% was scheduled. Probably there was more usage than expected. So dess starts charging but ignores the price of that hour. After about 8 minutes charging dess lowers the target soc to the actual soc and the charging stops.
The root cause lies in the design of the DESS execution process being scheduled SoC driven, not scheduled energy. The effect is compounded by the use of of 4 discreet scheduling timeslots per hour that get updated 8 times per hour from the received schedule, and then by truncation of the schedulers floating point SoC values to int values and finally by a whole bunch of complicated hidden schedule strategy adjustments trying but failing to compensate for all that afterwards. Unnecessary throttling of the inverter during the current timeslot exacerbates the problem even further.
Mismatches between expected versus actual energy/power should be the design principle for the DESS execution process whereas the current process forces you to adjust your settings to try make your system match the expectations to get it to function.
As an alternative to attempting to convince Victron of this design flaw, we coded an execution process wrapper around the VenusOS internal one in Node-RED. Our flow reads the incoming schedules from VRM, constantly calculating and correcting the internal integer SoC targets of the current time slot (using both the schedulers floating precision SoC ánd energy to/from grid/batt values . This bypasses the fixed duration and SoC integer limitations of the DESS execution process. Time dithering the target SoC of current time slot as many times as needed to correctly up or down rounded integer values, taking the time position within the current timeslot into account, effectively results in a continues, scheduled energy driven execution process.
As a result the execution process adheres much better to the scheduled energy values and also prevents the under/overshoots from happening when the scheduler recalculates the forward schedule once or twice per hour and pushing that to the system.
1 Like
That happens when the updated schedule recalibrates to the actual results of the previous hour and gets pushed to the system. The 8 or so minutes before that happens, the internal scheduler still tries to hit the SoC target of the previous schedule already over an hour old and regularly overcompensates to the other direction. This will not happen when the execution process takes the scheduled energy into account when calculating discreet SoC targets for the current timeslot. But it doesn’t, not correctly anyway. A mayor overhaul of the DESS execution process in VenusOS is warranted but very unlikely to happen any time soon.
As indicated above, whereas target SoC as primary parameter works well for the scheduling process, it does not for the execution process. I can understand how this came to be historically, with DESS Green primarily in use to compliment PV ESS systems because marginal PV energy costs are zero. The primary control inputs are instantaneous load and supply power, thus it makes sense to use SoC as the primary control parameter for the forward looking schedule. But for DESS Trade systems the key driver is price volatility, in discrete steps per timeslot. Therefore the optimal execution strategy inherently requires maximum power during (most if not all) buy or sell timeslots. Which requires an energy driven execution process (within the timeslot)
Thank you Jan for your clearly (brief was not what I meant) explanation.
I think when the restriction grid2bat would have been in place, the grid charging would not occur.
So a fast fix for Victron would be to place grid2bat restrictions on time slots where charging from grid is not supposed to happen.
I’m pretty experienced with nodered, but not with adapting dess.
That’s a first. Never been accused of being brief before 
I disagree. In my opinion there already are a stack of fast fixes implemented, each further complicating the process and all together obfuscation the actual root cause. And specifically, you can already set the strategy (and target SoC) for the current (and scheduled) timeslot(s) in Node-RED. And other options to make it do nothing (which is the easy part)
Isn’t what you ask for a GUI extension to set them then? I would agree it to be reasonable you use Node-RED for that instead. You could then use virtual switches as an external control input.
IMHO, a fast fix would be a guideline / flow / documentation on how to do so, officially supplied and supported by Victron.
See exactly the same.
Often 7-8 minutes pass the target soc is 1% different than you would expect and charging or discharging stops.
I think com.victronenergy.settings/DynamicEss/0/SOC is simply sometimes incorrect.
They think this will be solved if SOC target precision is increased in a future beta.
First you have to realize it that com.victronenergy.settings/DynamicEss/index/SOC is part of the venusOS intermediate DESS layer, index from 0 to 47 for 12 hours forward looking scheduling data (to keep DESS running locally in case of VRM DESS or network connection failures)
Every hour (sometimes twice, sometimes less) the VRM DESS scheduler evaluates the actual system performance data, then pushes an updated forward schedule (upto the last timeslot for which prices are known, from start-of-day to end-of-day or to end-of-tomorrow) to venusOS. VenusOS updates the internal 12 hour schedule table you pointed at and trucates the float precision scheduled SoC values to INT SoC (brrr) while at it.
A venusOS DESS process selects the current-index that matches the current quarter of the hour, usually Q1 → index 0, Q2 → index 1, Q3 → index 2, Q4 → index 3, and then for about 7 minutes Q1 → index 4 . Then when the hourly VRM DESS schedule update roll in, it switches back to Q1 → index 0 again.
Depending on the current-index, a copy of the schedule parameters (com.victronenergy.settings/DynamicEss/current-index/parameters-xyz) is made and designated to be the schedulers working set of parameters of the current timeslot. The DESS execution process uses the parameters of the current timeslot, such as the target SoC for the current timeslot, to actively drive the power settings of the inverter (using a lot of not all to well documented edge case logic to try and compensate for all kind of edge case situations where the predicted SoC starts deviating from the actual SoC. You know, the part where reality hits.
Needless to say things can go wrong on several layers, the truncation to INT SoC being the root cause why that edge case logic layer has gotten to be so complicated in the first place. I am still waiting for the devs to see the light on this one, but they will, one day. And then they need to convince management as well that it is worthwhile, to them, to re-design the DESS execution process to relieve it from this core design flaw. That can take a long time, we will see. One thing is for sure, without a continuous reminder from us, it won’t happen, ever.
About that edge case logic, you can use this code in a function node to have a look (feed it with the actual reactivestrategy number). Question is: why do we need 29 state (reactivestrategy) definitions for the DESS execution process, that is how overcomplicating things to compensate for truncating SoC to INT looks like. Not so strange we see so many DESS doesn’t do what it supposed to do topics popping up regularly, this is incomprehensible. What is needed is a proactivestrategy, not a reactive one. And that’s what I build in Node-RED, directly based on the float precision scheduled SoC values and using the other schedule parameters: strategy, restriction settings, energy to/from grid, energy to/from battery and a high precision actual SoC (calculated from consumed Ah) to proactively adjust the INT SoC for current timeslot as and when required. Works much better as this boils down to time-dithering (updates within 900 seconds window) extra precision into the target SoC for the current time-slot. Effectively the execution process runs on an actual SoC adjusted target INT SoC that can be adjusted upto 900 time per 15 minutes (but checking once per 3 minutes increases effective precision by 5x already).
The first step is to use: targetINTSoC(current-index) = Round( actualfloatSoC(now) + scheduledfloatSoC(current-index+1) - scheduledfloatSoC(current-index) ) every time the current-index increases by 1 to the next index (every 15 minutes). This will at least keep DESS aligned to the target energy/power schedule until the hourly adjusted-to-actuals schedule update rolls in. This can be refined with intermediate updates when large PV or load variations drive the actualfloatSoC to be equal to the targetINTSoC before the end of the timeslot, but in our DESS Trade only system that rarely to never happens.
var mapping = {
1: 'SCHEDULED_SELFCONSUME',
2: 'SCHEDULED_CHARGE_ALLOW_GRID',
3: 'SCHEDULED_CHARGE_ENHANCED',
4: 'SELFCONSUME_ACCEPT_CHARGE',
5: 'IDLE_SCHEDULED_FEEDIN',
6: 'SCHEDULED_DISCHARGE',
7: 'SELFCONSUME_ACCEPT_DISCHARGE',
8: 'IDLE_MAINTAIN_SURPLUS',
9: 'IDLE_MAINTAIN_TARGETSOC',
10: 'SCHEDULED_CHARGE_SMOOTH_TRANSITION',
11: 'SCHEDULED_CHARGE_FEEDIN',
12: 'SCHEDULED_CHARGE_NO_GRID',
13: 'SCHEDULED_MINIMUM_DISCHARGE',
14: 'SELFCONSUME_NO_GRID',
15: 'IDLE_NO_OPPORTUNITY',
16: 'UNSCHEDULED_CHARGE_CATCHUP_TARGETSOC',
17: 'SELFCONSUME_INCREASED_DISCHARGE',
18: 'KEEP_BATTERY_CHARGED',
19: 'SCHEDULED_DISCHARGE_SMOOTH_TRANSITION',
20: 'SELF_CONSUME_ACCEPT_BELOW_TSOC',
21: 'IDLE_NO_DISCHARGE_OPPORTUNITY',
92: 'DESS_DISABLED',
93: 'SELFCONSUME_UNEXPECTED_EXCEPTION',
94: 'SELFCONSUME_FAULTY_CHARGERATE',
95: 'UNKNOWN_OPERATING_MODE',
96: 'ESS_LOW_SOC',
97: 'SELFCONSUME_UNMAPPED_STATE',
98: 'SELFCONSUME_UNPREDICTED',
99: 'NO_WINDOW'
};
//msg.payload = msg.payload + ': ' + ( mapping[msg.payload] || 'Unknown' );
msg.reactivestrategy = msg.payload + ': ' + ( mapping[msg.payload] || 'Unknown' );
return msg;
1 Like
I do see these things at 7-8 pas. target jumps from 87 to 85 to jump @7 pass to 86 to jump at 15 pass to 83, absolutely unclear how this happens.
The active target from 8 pass until 15 pass is com.victronenergy.settings/DynamicEss/0/SOC.
You have to build a flow to monitor all the schedules and other parameters in their totality to see what is really happening under the hood.
This week I saw that green mode at v3.70~49 didn’t charge during low tariff for own usage during high tariff while another installation with trade mode did charge.
Green mode :
Trade mode:
Another strange thing today, selling is not profitable but dess sells solar energy anyway while storing it for later usage is far more profitable.
Another strange thing, I edited the hourly tarrifs and I get this price graph 
:
After reinstalling the android app this strange graph was normal again.
Today again a strange dess decision, usage from the battery while price is already low and recharge it just a few hours later. But with losses included it was cheaper to keep the charge and not doing a recharge a few hours later which is more expensive.
VRM id 789337
v3.70~49
Another strange issue, selling is not profitable but dess sells pv power to grid while it is needed in the evening and the next for own usage.
Maybe this behavior is caused by 2 reasons.
- Next day was not available before 13:00.
- Maybe there was more solar expected at 15:00 but the forecast has changed.
This is trade mode, because green mode didn’t charge from grid at low price to cover usage during high price I saw earlier.
Vrm id 719245
V3.70~60
Hi JeroenST,
I read a lot of unhappiness about DESS, and I was disappointed in DESS too!
But since I set all values to the real-world available resources, the system has been serving me very well. All values are now set as they are, and the efficiency is also set to 88% as measured.
If you set the efficiency too low, the system could calculate that it’s more profitable to just let it flow into the grid because of the lower efficiency. I encountered that myself.
In my case I have learnt that all values must be taken into account, and if values are not corresponding to the real world, then the system output isn’t either.
If you put a €0.00 value for the battery, it will do more transfers. If you set it too high, it will do fewer transfers, but it will also let more PV go into the grid if that is more profitable.
At first, I experimented a lot with the prices to manipulate the system because I was sometimes unhappy, but it was eating up my time; I was checking everything with a magnifying glass every possible microsecond.
So, I decided to give the real-world values a try and force myself not to look every microsecond. Now I simply check the results once or twice a day, and it’s doing just fine—better than expected.
Perhaps the system size provides an advantage, eliminating the need to squeeze every electron into a plan and leaving no room for unexpected deviations.
Think of it like driving your car down a very, very narrow road: you don’t have the space to make a miscalculation or even to avoid a small bump in the road, because the margin simply isn’t there.
The power bill has gone down since I started using real-world values. DESS has made approximately 1000 kWh of house usage cost me just €64.07 all-in up to yesterday for November. That’s just €0.06407/kWh all-in! And PV produced 306 kWh up to yesterday for November.
I know… easy talk… the system size is bigger, but the house load is also bigger, meaning there are more kWh’s to compensate for. Lower house loads demand lower kWh compensation, so a smaller system can do its share, but remember that just like a small car, you can’t transport everything at the same time.
1 Like
Complete agreement. I’ve had exactly the same experiences. I’d like to add one more thing. I was sick for a few weeks, had some time, and was able to observe the system closely. The accuracy of the system depends crucially on the forecasts. If the circumstances change—PV production, consumption—the system reacts accordingly. Many decisions then appear wrong in retrospect, but at the time the decision was made, it was perfectly correct. Just like in real life! 
On the other hand, this is precisely the system’s greatest advantage. If PV production is lower than expected, the system reacts in the next hour and looks for the most cost-effective option. If consumption is higher or lower than expected, the system adjusts its schedule for the next hour and searches for the best alternative. Again… many decisions seem wrong in hindsight, but I think the same applies to human decisions when circumstances change.
2 Likes