I have a small test installation that I am currently testing out dynamic ESS. The installation has been running for a few months. Apart from the “balance everyday” issue that has been reported to have been addressed, I am also facing another more troublesome issue:
Every “tomorrow’s” dESS schedule seems stellar; fully on trade mode, while the max battery SoC is planned for around 60-70% (I have disabled battery balancing). However, as time goes by, the scheduler reschedules for less trading on every run, plus a higher battery SoC, resulting in way less trading than expected, while the battery hits 100% SoC for many hours, meaning lost production. Why does this happen?
Attaching screenshots in a way that I hope make the issue super obvious.
Further info:
VRM Portal ID b827ebb27155
Venus OS V3.67 large, public
DESS in trade mode
You’ve configured grid limits of 600W (export) and 432W (import)
You have a 12.6 kWh battery.
That is an issue:
in the 3.67, the “smallest” charge / discharge instruction that could be issued is full numbers, i.e. 1%-resolution, per 15 minutes.
That is for your battery size: 126Wh per 15 Minutes or a charge rate of 504W.
So, the charge rate your system would REQUIRE to achieve a +1% - would exceed your configured Grid-Import limit.
Now, your Soc is reported in decimal precision. That means, whenever the scheduler “sees” a difference of like 0,8% beeing required for a certain slot, it considers it feasible and schedules for charging, but when your soc reports at a full integer value, it doesn’t schedule charging, because it “can’t break your grid” by issuing a +1%. So, wehter you see charging or not actually happening is fully dependent on the soc value beeing reported short before that window becomes active.
And this coincidently leads to a lot of aborted charges: The first window of a day may be a +0,5%. Feasible. But then your soc is ending at a “full number”. And the next window then would be a +1%, which is NOT feasible due to grid limits…
You should give that system bigger grid-capabilities to have more “room” for scheduling different charge rates.
This “issue” became an issue with the switch to 15 minutes - before that, the 1% limitation was hourly, hence only “25% of an issue”. In an upcoming beta, DESS will support decimal-target-socs to resolve this issue, given the system itself is capable to handle decimal targets, i.e. having its own soc decimal as well.
Unfortunately, I wasn’t able to comprehend your reply. Maybe I’m just too tired for the day. I’ll give it another try later. However, decimals often mess things up, so I’ve updated everything to round numbers for now, just to see if anything changes for the better…
That’ll help “a bit”, but most important is to raise your configured grid limit in the vrm dess settings, so it does allow higher chargerates that allow higher targets to appear possible for the scheduler and beeing send to your device.
My personal recommendation would be to allow at least 2% in 15min, as in some situations the local system will ignore a 1% change.
So, for a 12.6 kWh Battery, use minimum setting of 12600 / 100 * 4 * 2 = 1008W. More doesn’t hurt if the battery / inverter / grid can do it.
My test system is based on a Multiplus 24/800. I’ve used its actual limits on the dESS configuration. Wouldn’t setting unachievable limits mess the scheduling even more?
In any case, most bothering is the fact that the batteries stay at 100% for far too long under sunshine, and not the micro-management of trading. That’s what my tech-savvy clients will whine about.
Unachievable settings aren’t usually a good thing for the consistency of the schedule, that is absolutely right.
But for the time being, there are two options:
Have the scheduler assume your system can’t do the required 1% charge and cancel some charge schedules some seconds after they start.
Have the scheduler assume your system can do 2%, send out a unachievable instruction and have the system charging at it’s maximum rate, but falling behind schedule a bit.
Both not ideal for a test system to see how it works, but a real system to trade won’t have charge rate limits like that.
You should change the settings you have provided:
You did:
Export/Import Limit => Inverter Values
Battery Rates => Battery Values.
You should do:
Export / Import Limit => What your GRID-Connection can actually handle
Battery Rates => Min(Inverter, Battery)
Why?
DESS tries to not blow your grid-connection. So, whenever it expects high consumption, it will only use the “remaining” import power for charging. Thus, If you set a Import-Power of only 432W - having a 200W consumption forecasted will make the scheduler believe it could only charge 232W from grid at the same time which severly impacts the scheduling as well.
If I am not terribly mistaken, we were supposed to enter the “weakest link” 's max capability on the “Export/Import Limit” fields, that’s why I had set it like that. The weakest link on my system was the 24/800 Multiplus inverter. Now that I am visiting the dESS settings again, seems you are correct, I only read about the grid limit.
However, you ask that I enter the minimum of inverter or battery in the “Battery Rates” fields. However, I don’t see any mention to an inverter on that settings’ part.
In any case, since I am using a Victron inverter that’s also connected to the GX device and all its settings are known to the system, shouldn’t dESS automatically take its limitations into account?
The Inverter knows its limits - neither does the GX nor VRM (unless configured where required).
The wording “Battery Charge Rate” in VRM is a bit misleading. It is not about the technical possible rate of the battery - but more the weakest link of the inverter/battery combination as you described.
Think of VRM as an external energy-consultant - it doesn’t really care about details, all that matters (for this setting) is: how much can it push into your battery or get out
Updating my the dynamic ESS settings for my system, as per @dognose’s instructions did not help. The system behavior is exactly the same, SoC gets to almost 100% every day, with the battery not being fully utilized.
I will try 3.70~61 for a few days and report back.
Even on the latest betas, which supposedly address the resolution issue (percentage-wise and time-wise) of the scheduler, as soon as there is lots of sun available, the system still keeps the battery at 100%, exporting only what’s currently being produced, not using the capacity at all, and in general doesn’t work as intended.
I’m not sure yet that it’s due to the small size limits of my test system, or it’s just the dESS that’s not working properly. But it doesn’t.
