I think some people don’t really understand the basic functions of the DESS AND the configuration parameters. I think once that’s cleared up, we could focus on the real problems. Above is a good example of battery costs. One person defines them down to the last detail and includes a reserve in the guaranteed cycles; another says they don’t calculate battery costs because they’re already there. Simply setting these parameters changes the entire function of the DESS. I gave another example above. The maximum charging parameters specify the maximum power of the MP2, even though the BMS might be halving this power. This is precisely when no schedule or forecast works. Another typical example… the system only ever considers the period in which all parameters are available. This includes the price, and that is only available for the next 24-36 hours. If this understanding is present, I’m convinced that 70-80% of all problems are solved here. And from this point on, you’re right with your analogy of problem finders and solution seekers.
Who is going to clear that up? We are all learning by doing with hardly any in-depth technical documentation worth mentioning. Who is going to write that? The point I am trying to make, and sorry to be so blunt but alas hopefully you forgive me this time, is that you are jumping to a conclusion and providing what you think is the solution, while at the same time not realizing that that can be perceived by the other as unwillingness to listen to their problem.
@jkoljo Could you try to write a clear summary ‘problem definition’ ? The trick is to leave out any assumed ‘solutions’, at most propose a few ‘possible workarounds’. Literally somwthing like: 'the problem is that … when this, then that, when such, such then so, while assumed that it would … because of … reasons etcetera. You will probably quickly find out how hard it is not to sneak in ‘solutions’ as a means of explaining the ‘problem’.
I could as a bare minimum state my problem as:
Our dedicated large capacity DESS Trade only (no solar) system fails to execute reliably on obvious (to a reasonably knowledgeable observer of the price graphs) money making trade opportunities.
And then from there I could dive into what obvious money making opportunities are and when they are missed. When that is done I could reiterate into further detail, until I arrive at the technical level. Once that technical is reached, it starts to make sense to start adding proposed workarounds, but not much earlier.
If I’ve been misunderstood on this point then I’m sorry. I made the same mistakes when I first configured it AND I also assumed different functions when I was starting out. That resulted in a certain learning process. But exactly the same problems occur again and again. These topics have been discussed here a thousand times and I always find it a shame when people just complain and moan instead of reading something here in the forum first and questioning themselves and their settings. As far as the documentation outside of this forum goes, you’re not wrong, but there is a lot of it now and when you read through it afterwards you realize what the problem is. Another phenomenon that I notice again and again is that people no longer read documentation at all and instead pay more attention to some hobby YouTubers. A fundamental problem of our time.
Not to mention ChatGPT, hahaha. Yeah I feel you,… 
Look here for fun and giggles (I deleted my ‘offending’ help): Battery balancer and shunt on 4x12v 200Ah = 48V bank, in series - #12 by rolfroyal
But still, we cannot short-cut the learning curve for others by simply dumping the solution on them. It just doesn’t work that way and in a sence it is also arrogant on our own side, to assume we know better.
I guess the best way to look at it, is to see it as a process of mentoring, in which there are supposed to be no stupid questions.
Then we should introduce a recurrence function here. There are certain topics that simply repeat themselves very frequently. Perhaps I’m a bit more conservative in that regard. When a problem arises, I first start with an error analysis and then investigate whether this error is known. By the way, I really liked your contribution to pure error analysis. The next step is the process of elimination… which it can’t be. Only when the problem has been narrowed down and defined do I turn to someone for help.
Exactly the reason why I advocate for DESS to be a top level category on this forum.
Victron could do us a real favor by providing better technical documentation and/or better support providing us with the tools on this forum to develop that documentation ourselves. I am firmly convinced we already possess all required knowledge amongst ourselves, what is missing is a platform and structure to make that knowledge available and actionable.
And on deeper level I notice an unintended consequence of Victron’s policy to mix/match an open source ESS/VenusOS platform with a closed source DESS scheduler/execution platform. I do not see a future for that combo to thrive but that is a whole different discussion all toghether.
And that’s exactly the point. So far, Victron has been developing the DESS project open source, financed through other projects and a boost to its image. Consider that this only affects a part of Victron’s business. I find some of the comments all the more critical.
You let us participate in a leading storage control project.
DESS is far from open source. The real (scheduling) IP is hiden behind their cloud wall. And it isn’t free either, it is a substantial part of the value proposition for their hardware sales, it completely lacks the required documentation and support to realize a serious implementation without significant engineering cost on the customer’s account and the beta test engineering hours their customers are providing free of charge. And to top it all off, there is no recognition of the value of the ‘training data’ provided by their customers that is not openly available in return.
Open source was certainly the wrong term. You’re right about that, too. Otherwise, there’s no obligation to participate.
You know the expression: “if you are not paying, you are the product”
Not that I am complaining about that, but I do object to the argument that DESS is free and we should all be thankfull for whatever amount of time and effort Victron decides to invest (or not) into it’s support, documentation and development. That is way too one-sided a position in my humble opinion. Surely we recognize that without Victron there would not be DESS, but without the early adapter customer base, there would not be DESS neither. I would be a strong supporter for Victron to open source the full Node-RED DESS scheduler source code base, not in the least for the simple reason they already declared not to invest in any further development (no 15 minute scheduling to name a ‘hot’ topic) and plan to phase-out Node-RED DESS al toghether.
From the Screenshots you shared, the plan “to sell” was always already revised within that particular hour?
So, the scheduler changed it’s mind there on short notice, that is nothing to worry.
3 hours before, it planed to sell 2 hours:
2 hours later, it already planed to only sell 1 hour:
And when that hour came, it already removed a plan to sell:
So, at a first glance, looks normal?
but If you give me your side id (will send you a pn) I can look up more details on that.
Actually, it’s quite obvious why. The battery consumption was significantly higher than originally planned. I didn’t notice this at first glance.
Correct. The issue is that by self consuming the battery before the two sell hours, DESS was able to avoid paying for grid electricity, but by doing that it wasted an opportinity to sell that energy later. It would have been a financially better option to just idle, and reserve energy for selling.
DESS had also planned to charge a bit before the two lucrative selling hours, but did not execute the plan.
So if you rephrase that, what is the actual problem then? DESS not rescheduling in time to secure a near future profitable trade that was already indentified, due to a deviation from forecasted selfconsumption? It is a pity we have no (official) information about the trade algorithm, only a sense that it is based on buying what can be sold profitable later (targeting min SoC), but not selling what can be bought back profitable later (targeting max SoC).
Perhaps. Or alternatively local system (Venus) not doing what VRM requested. For example, VRM had planned an hour of charging, but that never happened. System idled, and eventually VRM rescheduled to give up charging.
Yes at this moment, all kinds of artefacts from the change over to 15m scheduling could very well throw a wrench in the machine too.
Yep. I was able to change my electricity selling contract to 15min pricing. The change took place at midnight about 24 hours ago. I of course adjusted DESS settings to 15min pricing. Today we had a very similar day as the problematic yesterday, and things went perfectly. DESS charged during the night and sold during the expensive evening quarter-hours. See the price and invertercharger power plots below. Perfect execution.
That is auspect to be looked at in detail: When the schedule plans to “charge” in an hour, that plan is suspect to certain forecast values, for example 1000 consumption and 4000 solar will forecast a 3000 Watt charge.
Now, the scheduler can send this charge-instruction with different degrees of “urgency” so to say.
It could range from “If there isn’t enough solar, then pull the missing energy from grid” to “if there isn’t enough solar, then idle or even continue to support loads from the battery”.
So, what is forecasted as a anticipated 3000 Watt Charge may even turn into a discharge into loads, when consumption > solar and the scheduler picks this option.
Ofc. It is not feasible to provide multiple “what-if” graphs, so the energy schedule outlined in VRM is the “expected behaviour, if solar and consumption forecasts match the truth” - it does not mean, that a expected 3 kWh to battery will happen for sure, unless VRM sends a schedule advicing the system to “strictly make that happen”.
But in that case a anticipated 3 kWh solar2battery may turn into 3 kWh grid2battery etc.
Also, it’s possible the other way round: the schedule may outline that 3 kWh grid2battery are expected - but then solar was higher or consumption lower than expected, and 2kWh could be taken from solar2battery.
You’ll then only see 1 kWh grid2battery, but it doesn’t mean the system missed to charge - just the energy flows were different than anticipated.