This is green mode.
Yes I understand ‘Dynamic’ in DESS. But if, accodring to the settings, today is a full charge day it should be so dynamic to decide to skip the full charge.
And if it turns out there is more solar than expected , the dynamics could indeed take less intake from grid, but it could still calculate what to do to fill the battery to 100%!
SOC only reached around 64% and it dmped 10% back to the grid between 21:00 and 22:00.
The key to evaluating past decisions is when each decision was made and what the forecasts were at that time. Just yesterday, for health reasons, I had some time to observe the system, as well as 2-3 parallel weather reports. Unfortunately, I didn’t take any screenshots, otherwise it would be easier to explain. At 7 a.m. the weather forecast was poor, and the system planned to charge from the grid for three hours at full load. At 9 a.m. more sun came through the clouds than expected, and at the same time our power consumption was lower than expected, so the system changed its planning and didn’t want to buy any more power. Both decisions were completely correct at the time and based on the forecasts available at the time, and I would have made the same decision myself. At 1 p.m. the game changed completely again. The next day-ahead prices were entered. This changed the forecast period in the 24 hours, and the system started charging energy from the grid for one hour at the most favorable time. Around 8 p.m. something unexpected happened again: one of our BEVs needed a little top-up. The system noticed that it wouldn’t have enough energy overnight and looked for the cheapest way to close this gap. In the end, it drew power for 2-3 hours last night and used it straight away so that it would still have energy in the battery for this morning when prices were highest. The system changed its schedule fundamentally four times in the last 24 hours, each change being the logical consequence of the changed parameters. I personally would have made every decision the same way based on the data. And despite all of this, in retrospect, it would have been cheaper to charge a little more energy from the grid yesterday at lunchtime. Again, assess the system’s decisions at the time they are made and not afterwards. In this specific case, the system had no way of knowing that, contrary to our usual practice, we were charging the BEV again on Sunday evening. We made this decision and the system reacted as expected.
Now, one can criticize the system in some areas. Especially past decisions. Why does the system change its decisions so often that it’s almost impossible to understand? I consider this flexibility to be its greatest advantage, because the parameters are constantly changing. Fundamentally, something would change if the forecasts were more accurate. But can we really do that? Can we forecast fluctuating PV production more accurately? Nature changes quickly. Suddenly, fog rolls in, or a blanket of clouds breaks up regionally. The same applies to consumption. Suddenly, the neighbors announce they’re coming, and the housewife decides to bake a cake. Or, in my specific case, someone needs more power for their BEV at short notice. The DESS can only react to changing parameters; it doesn’t change the parameters.
It is not to criticize, but to inform and hopefully add something that may improve the algorithms.
You had a real unexpected event to top up your EV. Imy case ther was not sucha thing no-one was a thomem so there was only, failry constant, baseload.
But then look at this nights graph and forcast:
My battery is 48kWh, min SOC is 15%. Again it schedules balancing today…
Apparently it can charge the battery to 100% wiht solar but it also seems to get some energy from grid. Already during the night. But why take from grid between 05:00 and 06:00 while and not between 03:00 and 04:00 where price is lower? Same for the expected grid usage between 20:00 and 21:00 with the highest price of the day. I would expext discharge in that hour, but I can understand dleaying that to the have the battery at 100% for a specific period to finish balancing.
If I would expect I need some grid to fill to 100% I would take it from the cheaper hours earlier on the day. That might change off coarse during they when actual status is known and I might reschedule a bit, but I certainly would not schedule grid intake during the most expensive hours…
I have seen sort like behaviour. The battery balancing or ‘periodic full charge override’ PFCO algorithm does not seem to take DESS into account and visa versa. I guess it is a simple countdown timer to the next PFCO day that, on the day it activates, triggers a crude ‘charge to full as fast as possible and keep it there for x hours’ command to DESS that overrides all else.
Regarding morning network usage, I assume that the consumption was slightly higher than calculated and the system only detected it shortly before that time. This is a common criticism that has been mentioned many times. I also think the system should factor in a certain consumption reserve there. How high are your battery cycle costs? It seems to me that the decision between buying, using directly, or selling is made based on too small a difference.
I’ve deactivated the balancing function because it often happens on my system that the battery is balanced automatically. In my opinion, the battery balancing distorts the DESS function if it’s activated too often.
We ended up using Node-RED to time the (de) activation of PFCO to the start (end) of a low price window. It pretty much functions as an alternative to ‘keep batteries charged’ that way, with added benefit that DESS stays on and it’s forecasting stats stay visible in VRM. An observed disadvantage is that DESS will try to chase minimum SoC after disabling PFCO. If not timed well, this can lead to unexpected energy dumping back to the grid right after.
Back to the topic of consumption reserves. I think it would be easy to program the DESS so that it sets the consumption forecast by +5% or +10%. But then we’re having a different discussion. For example, if this reserve is created today and prices are lower tomorrow, then we’re discussing why the DESS is buying so much electricity today even though I don’t need it, or why too little electricity is being sold at the most expensive time. Or the consumption reserve is blocking storage capacity. I’ve been involved for two years now and have been following the discussions with interest. Some topics are much more complex than they appear at first glance.
Al those reports (also in other topice) about ‘strange decisions’ and ‘it is easy to blame DESS after tha fact’ does not help us much understanding what is going on. The topics are full of ifs and buts.
So what may be helpfull is if Victron explains more about the DESS algorithmn. What rules are used, what mathematical models are used, what can we do to influences its behaviour and understand what such adjustments do. I guess it is not a propriety model that needs to be kept secret, isn’t it?
Maybe the explanation exist but I don’t know where to find it…
The question again…how high are your cycle costs?
I wholeheartedly agree. Half if not more of the issues can be summarized as ‘why DESS not do what I expect based on the very short summary given of it’s high level functionality and all assumptions I have had to make to fill in the blanks’. The lack of real insight in DESS’s inner workings does allow (or dare I say provoke) heaps of whisfull thinking, great for marketeers, not so much so for engineers.
I think if you spend some time with the DESS and read the publication, you’ll understand the basic logic behind it. In my opinion, Victron has a significant lead in development compared to other manufacturers. They would be pretty foolish to publish this development and the basic algorithm. You could ask Google or similar providers a similar question 
. No, seriously… I can perfectly understand why Victron doesn’t provide any more detailed information on this.
I have the complete opposite opinion. If Victron’s customer base stops volunteering as free test engineers, their whole DESS development program will grind to a halt.
That may well be true. But the deal is reciprocal. In return, all “test engineers” benefit from the latest developments and don’t have to wait for and pay for new software packages. It’s a deal you can like or dislike. I think the path so far hasn’t been without success. I’m really enjoying being able to participate in this development. Being able to express suggestions and criticism and not being presented with a finished product at the end.
I agree with most, except the ‘secret sauce’ part. I could envision, as a compromise, that Victron open sources the DESS Trade algorithm. I could write a massive wall of words why but the TL;DR is that I believe DESS Green + Solar should best be implemented as a variable adaptation on top of a deterministic DESS Trade Only algorithm.
I’ve set cycle costs to €0.02
I wrote before somewhere that I am convinced the customer base will perpetually be able to come up with new DESS use cases faster then Victron can design, implement and test DESS solutions.
@Sarowe1990, I can understand Vintron may not want to open up the complete ago, nut also sympathise with Jan’s reasoning.
Now there is a lot of uncertaintly among the users what to expect from DESS. And ‘explanations’ for unexpeceted behaviour are in the form of ‘perhapds DESS saw some changes in usage or solar production that could have …’
Maybe one thinh that can be added is some degug logs that explain a bit why it DESS changes the forcasts or decides to suddenly skip balancing.
And maybe create a few more modes instead of just green and trade.
I for one would like to have a mode that minimizes grid intake. So fill the battery with solar, and in the evening predict what next days solar will bring. During the evening/night it then releases energy to an extend it can fill the battery with next day solar till a configurable level.
I prefer to have my batteries to be filled as much as possible after sunset, without taking grid energy. So no real fixed SOC target!
In times (winter) there is not enough solar, grid intake may be needed, but at that time take it from the cheap hours so the battery energy can be used in more expensive hours.
