Scheduled 4 soc is active from 12:00 until your system has contact with DESS server and a new scheduler is calculated.
From that moment Scheduled 0 soc is the active one until 12:15.
The Scheduled 0 soc is sometimes wrong (caused by rounding issues).
And this than triggers unexpected charging or discharging.
This is what I thinks happens.
Again Thank you for your analysis and then from me to you the advice to do so.
So please, psssst stop being noisy, ok?
Just clean up your end, all of it. I did mine already. Stop debating, start deleting. Once the post between us are deleted, they will disappear after a little while. But takes two to tango. Between you starting this.
And this single closing post, all posts in between are yours and blocking actual removal.
In my case, itâs not schedule 0 which is in error, but schedule 4.
Ok?
You can reprogram them in node red and I did that to figure out what target soc was the active one.
From 12:00 until 12:08 it seems to be schedule 4 and after server contact it was schedule 0 until 12:15 after that schedule 1 is the active one for 15 minutes.
Schedule seems also be overwritten twice every 15 minutes,âŚ
Hi guys, I keep seeing people climbing the same discovery / learning curve me and others went through. Wouldnât it be a better plan to try to centralized whatâs already known instead? If anybody is willing to work on the documentation of it, Iâd be happy to share what we know plus some handy tools as well.
1 Like
I think everyone that investigates this issue goes through the same learning curve by getting to know how dess works and finally understanding whatâs going wrong.
The ultimate solution would be that Victron solves this issue that is here for some time already.
Hopefully our input makes them aware about the importance and the root cause for solving this issue.
Ok, that could be a work around, but I wait for a final solution.
Maybe it would be nice when Victron explains how the community can report a bug!
And where we can find a list of known bugs.
Now we donât know if the bug is noticed and if they are working at a solution.
What I do understand is that the target Soc will get a higher resolution in the future, nice especially when you have 100kWh or more storage, but will this also fix the imperfection we see?
I real donât understand how hard it can be to make a scheduler without rounding issues.
Is this open source so that we can fix it ourself?
1 Like
The issue I experience is not from rounding I think, but from a schedule that doesnât match the actual soc when starting at x:00 and matches again after an update at x:07. The solution is that the schedule is recalculated at x:59 for the next hour instead of 7 minutes to late.
From my own experience with a custom optimizer, it would even be better if the schedule was recalculated every 15 minutes. I hardly see strange behaviour, even if thereâs a big gap between prediction and reality.
That would indeed improve, but still there could be unwanted behavior every 15 minutes instead of every hour if the source of the problem (tsoc not matching actual soc when no charge/discharge is planned) isnât solved.
Ah, yes of course. I also take the current SoC from MQTT instead of the API because I found it to lag too much to be useful. The internal Victron system probably also uses the (potentially outdated) API value.
Another strange issue I see today.
Itâs not profitable to charge battery from pv power and it is also not planned.
But unfortunately victron is charging battery instead of selling to grid.
The issue started at 10:00 and continues, so this is not the scheduler lag issue.
Why donât we get any updates on this ongoing issue?
Tests are finished but they have issues with Node Red compatibility, will still take some time,âŚ
Hopefully next beta will fix the issues.
Dis see some strange DESS behaviors last days, maybe they are already testing?
I hope so, some updates could clear the fog around this.
I have just noticed exactly the same, target SOC is now 0, while Active SOC Limit is 25%. Current SOC is 53%
This coincides with a change in the cost of imports from the grid from a cheap to a very expensive rate, so I donât want any import from the grid.
Is this the correct behaviour?
