So I guess that you were not happy with current non-beta Venus OS which does something like this (full-day graph, that’s 8h+ at 3.51V):
I now understand how this behaviour is not good for the longevity of the packs, and I’m eager to install the next stable version in this other system 
Yes, the voltage is fine for fully charge and also the cells are well balanced. But I will not keep them for 8h at this level. I charge them much slower and keep them for max 1h at 100% Soc. After that I disable the charger. This is my way and I balance only twice per month. My capacity is high enough. I need around 30 to 40% capacity during summer. If I would need more I would control the charger and batteries in a different way, of course.
A post was split to a new topic: Pylontech voltage increase with feed in
Hi,
since the Beta 15 my System shows as well a behavior I cannot find a explanation for it. The SoC (as metioned on posts above) gets to a maximum of 94% on the Victron display. Therefore mounted the Console Cable of my Pylontechs and tried to get the Values directly from the Pylontechs as well (2xUS5000). The result is as following:
Victor Shows 94%
According to the Pylontechs, the SoC is: 98.9 and 98.5
See graphs below. Is there any explanation for that? During the Day (Charging/Discharging) - the Values does differ as well (around 2%).
I added as well a picture of the cell voltages if that’s important for this question.
Ernst
You have a quite “lazy” cell in the Pylontech 1. That red one…
Either defective or the pack is not well balanced for quite some time.
This may get the aggregated SOC out of sync.
Try to use the system only with Pylontech 2 for a day or two and see if the SOC is in sync.
Also see that the latest beta has an improved algorithm than the beta15
Use the current beta 25.
1 Like
Hi all, I had a quick read of all the responses and wanted to make one comment about an indicated 100% SOC. SOC is always an estimate. Once you are above 3.45V on all your cells, there is less than 1% to be had by charging higher. While the battery reports 99%… it is essentially full. That last bit is of no concern at all, and I would not worry about it if it improves the behaviour in other respects.
2 Likes
Hi Izak @iburger
There is a case here where the user has a 16S battery that identify itself as Pylontech.
If you were to also apply your algorithm to 16S Pylontechs, I believe that will not hurt and will be beneficial for all that are using original or clone 16S Pylontech batteries, because your algo will not do anything but to improve the usage of the battery, even if it’s 16S and you originally assumed that the BMS knows what to do.
Many thanks for your efforts!
1 Like
Is there a particular reason why the Pylons keep charging and discharging with up to ~700W once close to 100% ? It never seems to get any “rest” anymore. I’m on 3.50~30.
Not sure if this is necessarily a bad thing but it does prevent the battery from reaching 100%.
I tried things like “keep batteries charged”, disabling MPPT charger and switching peak shaving back to above min soc but none make any difference.
Once charged to ~98% it claims to be at 52,14v with 3,45low and 3,49high. For now I disabled DESS, MPPT charger, set min SOC to 100% and a discharge limit of zero. Let it sit at 100% for a few hours to see if it continues balancing.
It only took minutes to reach 100% so I guess whatever the reason behind the charging/discharging is it’s probably OK 
when can we expect an officially finished v3.50?
There isn’t a specific date but it is not far away.
You will know when the blog post is released.
1 Like
Thanks @nickdb
I just experienced that same behavior, first time since my previous posts. See the screenshot attached. All 1min datapoints are visible here, showing the +/- 1kW.
Context:
- configured for scheduled charging at night, in 2 steps (85% max at 0h10, then 100% from 2h10 to 7h10, partly shown above)
- this is the first time AC consumption was high enough to prevent SoC to reach 100%: see around 4h30, when SoC dropped from 99% to 96%
- when that consumer stopped at 5h30, charging resumed for ~1/2h, reached 52.2V, oscillated a bit as usual, temporarily reached 100%, but…
- it started to behave weirdly, oscillating voltage and current, which reduced SoC to 99%, and increased CCL from 14A to 88A
- this only stopped at the end of the scheduled charging slot…
It seems like something is resonating in the algorithm. The usual voltage oscillations when reaching 52,2V seem to have, for once, morphed into +/-1kW oscillations…
Now on v3.51
I can provide more context if needed.
I am seeing some interesting charging behaviour on a MP2 + US5000 system recently deployed with 3.50
- MP2 48/3000 in Charger mode (no AC loads)
- A single US5000
- DC only loads (about 40W)
- No SmartShunt, using Plyontech BMS only
- DVCC enabled and all defaults
- ESS assistant NOT in use
Even with a constant AC supply to the MP2 I am seeing the SoC drift from 100% down to 92%. Then something kicks in and SoC rises to 100% briefly before the SoC starts drifting down again.
Use case is a telecom UPS. Only DC loads of about 40W, no solar.
@WhiteCitySolar
Take a look at the CCL while those dips are happening. My US5000’s drops CCL to Zero at 100%, but it will open up again at 99% at just above 50.1V. One difference I can see on your pics is the Cell min/max which is greater than my ~30mV.
This hasn’t changed for me with 3.50.
That drift down is because the DC loads are consuming and the scripts for DVCC has been modified and not compensating anymore for that consumption.
See here: Small omission in beta dvcc.py, maybe? - #2 by iburger
Now, that the charging algo is more mature, maybe @iburger can take into consideration to include back the compensation, as there is no more risk for overvoltage? Thank you!
@alexpescaru
The trouble is that the system doesn’t compensate for DC loads, even if measured by a shunt and allocated as such. As soon as CCL goes to zero a savage sawtooth begins. I gave up and scheduled the DC load away from that Absorb period.
I’ve update my original post to include CCL plot. The battery is quite cold at the moment, something to address separately, but explains the drop in DCL.
@JohnC
Just adding that line I’ve talked about in the previous post to the one quoted is solving the sawtooth behavior.
Or just add a current value proportional with your DC loads in the com.victronenergy.system/Debug/BatteryOperationalLimits/CurrentOffset and you’re good to go without sawtooth.
In fact, this com.victronenergy.system/Debug/BatteryOperationalLimits/CurrentOffset is the way to go if you want to experiment and see if it’s solving the problem, before diving and making modifications to the code.
@alexpescaru
And how would Pylontech look on a warranty claim if they found out that the Victron algorithm had been modified? These things shouldn’t need tweaking by endusers. And as a moderator here I don’t really even want to talk about making changes outside the standard algorithm available to all.
FWIK, if there is a problem, Pylontech is asking for the event and history logs.
And if in the logs there are no SC (short circuits), no UV (under voltages), no OV (over voltages) and no OC (over currents), they will honor the warranty.
Their words, not mine.
But then again, if one is not feeling comfortable with doing this, by all means, one should stay on the safe side.