The Dess software for some reason does not seem to stop the balancing feature. Is there a specific reason for this?
What are the requirements for Victron to release this again and to start using the battery on trade mode again?
I don’t think this was a schedule-thing.
Just checked your system, and it reported DESS to be disabled until 30 minutes ago and for the past 30 hours.
Then, normal ESS-behaviour applies. Do have configured ESS as “Keep Batteries charged”?
Yes it was a scheduled act, 2 days ago we got our first message that battery balancing from DESS was scheduled. As 2 days ago it wasn’t able to get the batteries to fully charge till 100% it delayed it until yesterday.
edit: When I’m currently looking at my VRM I also can’t see the notification anymore. This doesn’t show up anymore. Last time it properly did this was on the 23rd of Febuary
Yesterday it activated this but it did not disable the battery balancing. Yesterday I changed the interval of this battery balancing from 28 days to 60 days. As the loss of profit was quite substantial. This was done by Me, user “lars” at 18:15, but I did not change any other parameters. Today when i woke up I saw it still was not out of the Battery balancing. As the ESS battery life state still showed keep batteries charged, which I believe is normal behaviour for DESS when it activates the Battery balancing Cycle. I decided to disable this Battery balancing feature at 13:45 as we have already lost an entire day worth of trading. But as the ESS battery life state still did not change. I then manually disabled DESS to ESS to manually change the ESS battery state from “Keep batteries charged” To “External Control” to then change it back to “BL without Battery life” And Then turned back on the DESS. at around 13:57. It now seems like it will start discharging again when prices increase at around 17:00. But I will only now if DESS works like it is intended at 17:00.
As you can see I have not changed the DESS settings at 30 hours ago. This should have been at approximately 9AM. This is when the DESS activated the Battery balancing feature based on the given interval. For some reason this Battery balancing feature did not meet certain requirements for the system to go back to normal DESS.
Same here, looks like a bug in beta firmware for me.
DESS tries to keep the SOC at >= 99% for 3 consecutive hours to consider it “successfull balancing”. I can see your actual soc dropping way bellow this 99% every now and then.
So, that always interrupts the balancing process.
I have no idea, how long DESS will try to achieve balancing, it is a mathematical decission. Sitting at 97% with the need to balance and sacrifice 3 hours of battery usage is almost always preferable over cancelling the attempt and retry tomorrow.
What kind of battery do you use? DVCC? Charge-Voltage Settings? You should investigate, why your battery is not holding a stable 99%+ SoC for the 3 hours the system is instructed to NOT use battery.
Hi, i am using two Dowell iPack 3.3, DVCC on and no voltage limit.
After disabling DESS everything worked as expected, without DESS i have no problem to keep 100% for hours.
Hmm, when DESS is trying to balance the batteries, it should always apply a charge to keep them at 100%. Your graph looks like it sometimes drops down to 96%…
If you could share your site id (the numeric one in the vrm url) I can review if there is a relation to dess about this or not.
Does your system / environment make heavy use of Peak-Shaving? Cause that will take precedence then.
Sure, ID is 503553.
I am not aware of any peak shaving config, sorry.
Thanks for your help.
Are you aware of current issues with price forecast? The data for tomorrow is not valid. DE/Tibber.
Thx, will have a look later.
Hmm, also using Tibber/DE, my prices look correct.
Thanks, my current view of tomorrow:
I’ve now took a look at your balancing issue.
Unfortunately, there was a drop to 98% SoC in every of the 3h windows, where the schedule tried to balance during these 2 days.
I think the core Issue is that for your battery (5.5 kWh) a 2% SoC-Drop is only ~110 Wh. Considering the BMS will already drop to 99%, when it is not “perfectly balanced”, that leaves very few space for short discharge-spikes for whatever reason.
Balancing itself requires the battery to discharge a certain amount of energy, whenever a single cell hits its maximum cell-voltage - and due to the small capacity, that “balancing-discharge” itself seems to be enough to temporary fall bellow 99% SoC - which then makes the scheduler considering this balancing attempt “failed” and makes it retry…
I don’t think there are any options here to resolve this. The small size makes the SoC-Value pretty sensitive towards even small amounts of energy being discharged.