There is actually a small problem with this at the moment. Things are a bit inconsistent, because normally the selected battery service is used for everything (BMS charge/discharge information, voltage, soc)… but there are many people who use a BMV in order to get a better SOC (because some batteries are particularly poor at doing that job). So now some parts of the system use the info from the first available BMS… others use only the selected battery monitor… this inconsistency has to be fixed.
But doing that will break things for the people who use a secondary source for SOC. So some intuitive smart solution needs to be thought of…
1 Like
I’m all for this.
The BMS softwares interfacing the BMS with the Venus should have the option to select the BMS SOC or the BMV SOC, if there is a BMV.
Reasoning is quite simple: BMV logic and software has been tried and tested for more than a decade, forming the core of the system, and ESS.
If my system saw the low SOC on the BMV and not the incorrect high BMS SOC, I would not have had 250w incoming during peak hours where I could have had 3.9kw incoming, less strain on the batts, recharging them properly, by not relying on incorrect cell volts that the BMS assumed the SOC was.
BMS software is new. BMV is not.
Would this have stopped the cells misbehaving? I bet it would have.
Another idea that I thought of, if a cell pops above say wot a user programmable value of 3.61v, throttle the charge immediately AND drop the average volts, along the line of the new Venus feature to drop overall charge volts in DVCC, so that the BMS can do it’s thing to balance the cells.
And add a Notification on the Venus to some effect of: System throttled due to Cell imbalance or some such.
1 Like
I don’t necessarily agree that the BMV is always better. The BMV literally counts amp-hours. It knows nothing about what is going on inside the battery. A BMS can technically make a much better determination as it can see the per-cell voltages.
But BMSes also make assumptions. One thing they do – I suspect to cut down on support questions (why does it stop at 88% SoC? shakes fist) – is to jump to 100% SoC when a high cell appears. It is fine to do that if the other cells are also moderately full (above 90%), but it becomes problematic when there is a severe imbalance.
Also, BMSes use the same kind of tech as the BMV… it counts amp-hours, using either a HAL-effect sensor or a shunt. And then it does numerical integration, which isn’t 100% mathematically accurate, and the sensor might not have good sensitivity low down, etc etc…
So long story short: SOC is always an estimate. Always. Repeat after me…
A proper BMS will generally get it right most of the time, and you should not need a BMV. The BMV is for people with lead acid batteries. Why should you need to spend more money on another bit of hardware, mmmh?
So this thing where one has to make it configurable… really is a workaround to fix someone else’s problems. But if it was easy, monkey’s would be doing it… so here we are.
I agree with plonkster. And as your BMS does use a shunt it is pretty accurate. You will never get the same values from different devices. There always are differences.
Your problem is that the BMV thinks the battery should be at a different SOC than what the BMS SOC states. They use different assumptions, inputs, and formulas.
The BMS in this case can see each cell. So it knows that cell has reached it’s max (3.5V from your settings) and it is trying to protect your cells.
You have overridden this with the SOC from your BMV which does not know about the individual cells.
Now let’s look at what would have happened if you only had the BMS and used it’s SOC.
Your system would have moved to a high SOC as soon as the first cell reached 3.5V and this would have kicked in the current control logic from my driver which would have limited the charge current. This lower charge current would give the BMS’s balance circuit a chance to try and balance that cell at the 200mA it can balance at.
Instead the BMV’s SOC said it was at 30-40% and the current limit would not have kicked in. Thus the MPPT could push the full 60A or more to the battery and that excited cell just got more excited after the BMS blocked the charge.
SOC is always an estimate …
Having stored data from a BMS that has a shunt and a BMV, both of them always giving an estimated SOC, the BMV estimate appeared to be more consistent in its estimation than the BMS, over months.
So really it boils down to:
- Which one of the two has the most accurate SOC?
- With BMS’es becoming the norm today, which intuitive smart solution will get to the middle ground the fastest?
Ps. Spending a “moerse klomp geld” on any type of battery bank, the % a Smartshunt costs are minuscule IF a BMS can be properly intergrated.
Thought about this. The ONLY problem I see with that is when, not if, when a cell gets out of whack and hits 3.5v prematurely, the rest of the bank still at ±3.3v and needing a couple of hours to get recharged.
In my case, if I had no BMV, I would not have found the problem this fast. the BMS SOC was a total gimmic SOC.
And it is going to happen to others as well.
That is unless one program’s one’s system to the same settings brand names use … problem with that I found when looking around to see what they do, no two brand names have the same settings … for Victron.
The system “throttled” solar production to just the watts the batteries could accept, cause of your software.
I tried to override this and “forced” the system to go expected normal by setting to Keep Charged … only lasted for a few seconds before it dropped from 60amps to >3 amp again, even though BMV sais 30% SOC.
I could not make it use full panel power UNLESS I rebooted the BMS after which it got the correct SOC again and all was normal again … till the cell flew out of whack again.
So the system was protected yes.
Methinks, seeing the Min/Max volts are in the system, that if a cell gets excited, that it would be really cool for the software to drop the charge voltages in DVCC to give the BMS a chance to catch up.
THAT could help a lot towards averting a “fake” SOC caused by a cell going out of whack.
FWIW, the smaller 12v BMS’e we bought, same supplier, does not have a shunt.
Let me absorb all else that was said … I’m trying to see why it is a bad idea to use a BMV that will provide a more accurate SOC, cell imbalances being a separate issue.
In most cases they are going to be very close to one another. The entire “middle” part of the discharge is done by just counting amp-hours. It’s the ends of the spectrum where things differ. The BMS may have logic that resets to 100% based on the highest cell voltage. the BMV in turn has the configured “charged voltage”, “tail current” and “detection time” parameters it uses to reset.
Similarly at the bottom end, the BMV will count down to 0% and (assuming it is wrong) it will just sit there. The BMS on the other hand may have logic saying that the battery is empty only once the lowest cell is at 2.8V. So the BMS could be more accurate on this end.
Furthermore, a BMS could even remember the amount of Ah it got the last time and recalibrate itself (so next time it is more accurate). This number could also be used as a SOH indication. The BMV cannot do that.
Personally I think your BMS is doing just fine. You simply have an abnormal situation with an imbalance, and so it got the estimate wrong this one time based on its internal logic.
1 Like
And I won’t be the last. 
Am running on the BMS SOC since yesterday. Will “walk the talk” for a while, BMV can just sit there recording.
Without dismissing any particular battery, there are some batteries (some BYD models, some BlueNova, a few others) that cannot measure properly below 1A or sometimes 2A. A common problem in electronics, a sensor that can measure large amounts of current may not be able to measure small amounts.
I had a support case a long time ago where someone simply left a Multi at idle on a 4 x BYD bank (this bank could barely sense anything under 8A). Now 8A times roughly 50V is 400W, and the Multi at idle didn’t draw that much so the BMS didn’t even know the battery is being slowly discharged.
The effect was a battery that remained at 100% for days, and then suddenly crashed to 0% and switched off. The customer wanted to know why the Multi suddenly decides to discharge the battery when it has no reason to do so (because on the SOC chart, that is what it looks like). After looking at the data, it turns out the Multi isn’t suddenly using lots of DC current… and that is when the penny finally dropped.
1 Like
In your case if you did not have the BMV, the system would have fixed itself within a week or 2 without you knowing and you would not have any bulging cells. All while you were happily drinking a cup of coffee without a worry 
You would have use a bit more Eskom power though, but that is much less then having to replace a battery cell would cost.
I think the real issue here is how we define the State Of Charge vs. how different systems define SOC.
The BMV was designed for a lead acid battery where you had the total voltage as well as the current flowing in/out to calculate the SOC.
These days the BMS we use for lithiums read individual cell voltages and adds that to the logic as well as current in/out and total voltage. I think this is better and safer.
If a cell imbalance happened in a lead acid it would eventually destroy that hole battery cause you did not know about it.
If you don’t look at the cell values in your SOC calculation then why do you have a BMS? You are treating your lithiums like lead acids.
1 Like
Let me sleep onnit … have to assimilate it all.
@plonkster once all info has been absorbed, to not leave any “confusion” behind, I presume the BMV must be removed OR just disconnected from the Venus?
This option is not enough?
If your Battery monitor is not on Automatic you might need to change that as well. Not sure if the BMV will be removed from the list if you set the monitor to BMV instead of Auto
1 Like
Geez, I saw SerialBattery and took a screenshot!!!
Fixed.
Not auto, set it to BMS, as per updated post.
1 Like
Note: If you change the settings from BMV to BMS SOC, reboot the Venus.
O that bugger no 4 cell … no 3 is the bulging one.
At BMS SOC of 96% load 700w, I can see he needs some TLC - of 'n klap!!!
Discharging to 80%, the recharge back to 100%, till that bugger is sorted. As per a post of Plonkster on another thread: Howzit from muldersdrift - #141 by plonkster
He’s got NO chance … “I’m watching you!”.
1 Like
From watching my own cheap Lithium battery bank for months, I have found the following:
Once a cell reaches about 3.45V at a low charging current, it cannot take much more energy and the voltage will rise quickly if you try to charge it more. At a high charging current the voltage on the terminals of the cell (as measured by the BMS) will be higher due to the internal resistance of the cell, so in that case 3.45V is ok.
If you have a cell going above 3.5V then that cell really is full and even if the other cells are below 3.4V you have to stop charging or charge very slowly to allow the balancing circuit to do it’s thing and bring down the higher cell. It’s no use trying to force it to charge further once any one cell is full, because all you will do is cause a high cell voltage on the full cell and trip the BMS’s protection. I guess it’s also not great for that cell, if this keeps happening.
In my case the BMS that came with my battery is terrible and can’t measure less than 2A. I have 2 batteries (5kWh each) and so together they can’t measure less than 4A (about 200W). Which is a problem because they have some weird logic where the balancing will not happen if they don’t measure any charging current, so I have been manually balancing my cells. I wrote a python script to get all the data from my batteries, including the cell voltages, via RS485 on a PI. I then made a small board for each battery with 16 DIP switches, resistors and LEDs, that I wired across the cells. Then in the afternoon when the batteries are full and the current has tapered down less than the 4A the BMS’s can measure I look at the cell voltages and turn on the switches on any cells that are high. This draws only about 20mA from the high cells, but I leave the switches on until the next afternoon and repeat. This process has gotten my cells pretty well balanced over the last few months, but is a bit of a pain, so I have just finished designing a PCB with a mircrocontroller that will communicate with the BMS (so I don’t need to make it measure 16 voltages very accurately) and I can automate the balancing process and use higher balancing current, as well as generate CAN messages that actually change the voltage and/or current targets depending on the cell voltages.
4 Likes
If you are doing all that effort you might want to check out what they did here. There could be something useful
Thanks, that sounds pretty interesting. I will definitely have a look at their design.
I’m using KiCad already.
It is enough. Even if you leave it on Auto, it will pick the device with the lowest DeviceInstance (in those cases where there is still an inconsistency, as I noted earlier), and the BMV always has a device instance somewhere above 256 (since it is VE.Direct) while the serial driver allocates something quite low as I recall (0 or 1).
Right. A LiFePO4 cell that is highly charged has a high internal resistance (towards charging, not the other way round ). Most batteries have a passive balancer, which means it literally connects a little resistor across that high cell (for short amounts of time) to allow some current to flow PAST that cell (instead of through it). This allows the other cells to continue to charge SLOWLY.
The caveat to this is that 1) you must continue to pass a low charge current through the battery, otherwise the balancer cannot work, 2) that current must be less than the bypass capability of the balancer.
That of course creates a demand for a balancer that can bypass nice large amounts of current, but that is a game of cost vs utility: Once the battery is balanced (two weeks into its life), the larger bypass machinery is almost never used again. Which raises the question: Should I pay more for something I will only use for two weeks? Or just be a bit patient? 
The other option, of course, is an active balancer. That is a DC/DC converter that can suck charge from a high cell and release it into a lower cell. Of course that is more expensive. But it has the advantage that it can balance even if no charge current is flowing into the battery. Much better for systems that use voltage control rather than charge-current control (ie, DC-coupled PV).
1 Like
Just a heads up. The current driver does allocate a device instance ID at 1, but the next big release use the Victron SettingsDevice to allocate the instance ID and that starts at 256 as well.
1 Like