Yeah, seems to me 2 cells, one slightly bulging, are the two culprits.
That’s hardly pushing it. Most “brand name” BMSes only intervene around 3.7V-3.8V per cell…
To the topic of the serial battery driver for Victron:
I finally managed to get my 4s pack to work. My Daly BMS stopped working after about two days. (do not recommend). Now I have a BMS from LLT.
The driver works like a charm in that it sees the battery with all its parameters.
Unfortunately this seems to kill any other Serial connection. My USB to VE.Direct connections to a MPPT and an Inverter stopped working.
Is this a known issue?
Interesting. Jaibaida BMS starts balancing on 3.2v and gets unhappy at 3.65v. Can change the parms.
Think I’m going to up the specs a bit … see where it leads.
Also a fairly common cut-off. Perhaps I’m being a bit too generic when I say “most” brand names. I should perhaps have said “many” 
I also just realised that Pylontech cuts at 3.6V per cell.
I suppose that in a very badly unbalanced battery, you could be in a situation where most of the cells are at 3.2V and one is at a higher voltage. But below 3.3V you are still very much on the “flat” part of the charge curve, so usually the imbalance only shows up above 3.35V per cell. At least, that’s the worst case I’ve dealt with (3.35V on 15 cells, 3.75V on the 16th one).
1 Like
This should not happen. It could just be that the driver is working through all the USB connections that is taking a bit of time. Or perhaps the device IDs clash.
The serial-starter app does create a log file that should give you an idea of what is happening. When connected to the device using SSH you can find it at /data/logs/serial-starter/current
Thank you very much for your reply.
According to the logs it seems the driver occupies all three USB devices.
@40000000608ec28d37b7929c serstart starting
@40000000608ec28d3902815c INFO: loading config file /etc/venus/serial-starter.conf
@40000000608ec28e1eabad4c INFO: loading config file /data/conf/serial-starter.d
@40000000608fcbd41e744d84 INFO: Create daemontools service dbus-serialbattery.ttyUSB0
@40000000608fcbd52bb78d1c INFO: Create daemontools service dbus-serialbattery.ttyUSB1
@40000000608fcbd71376cbb4 INFO: Create daemontools service dbus-serialbattery.ttyUSB2
@40000000608fcbda2211b3dc INFO: Start service dbus-serialbattery.ttyUSB0
@40000000608fcbdb2eae33f4 INFO: Start service dbus-serialbattery.ttyUSB1
@40000000608fcbdd19f65acc INFO: Start service dbus-serialbattery.ttyUSB2
Edit: I am using very cheap, PL2303 based USB to serial adapters. They might all have the same serial number. Could this be a problem?
Using two of them for the Inverter and MPPT worked flawlessly.
Edit 2: I just confirmed in dmesg: SerialNumber=0 for all of them
@Louisvdw , remember I asked about this some weeks ago… on whether your driver exits properly. Specifically, it needs to use the routines in /opt/victronenergy/serial-starter/run-service.sh and unlock the serial port afterwards (otherwise serial-starter may not continue trying other drivers for the same port).
What you want to see is how it trues them one after the other, eg:
2021-03-30 13:14:32.288045500 INFO: Create daemontools service dbus-cgwacs.ttyUSB1
2021-03-30 13:14:35.112823500 INFO: Start service vedirect-interface.ttyUSB0 once
2021-03-30 13:14:39.103867500 INFO: Start service dbus-cgwacs.ttyUSB1 once
2021-04-06 07:17:42.595871500 INFO: Create daemontools service dbus-fzsonick-48tl.ttyUSB1
2021-04-06 07:17:48.869598500 INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
2021-04-06 07:18:00.346780500 INFO: Create daemontools service dbus-imt-si-rs485tc.ttyUSB1
2021-04-06 07:18:06.670446500 INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
2021-04-06 07:18:14.996953500 INFO: Create daemontools service dbus-modbus-client.serial.ttyUSB1
2021-04-06 07:18:21.207748500 INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
2021-04-06 07:18:28.099118500 INFO: Start service dbus-cgwacs.ttyUSB1 once
2021-04-06 07:18:34.703332500 INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
2021-04-06 07:18:43.135412500 INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
2021-04-06 07:18:50.336511500 INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
2021-04-06 07:18:58.714670500 INFO: Start service dbus-cgwacs.ttyUSB1 once
BTW, if you want to see the date and not the @… tag, pipe it through tai64nlocal, eg:
tai64nlocal < /data/log/serial-starter/current | less
This could be the problem. I’m not sure if you can edit the SerialNumber to be something more unique. Else I suggest you get a better cable/converter.
Yes, and the driver does exit properly.
It does a call to the serial port requesting the hardware version from the BMS.
If it does get a proper response the driver will start the gobject thread and MainLoop.
If it fails, then it just returns and never even get to the MainLoop.
I think that that serial calls get confused because all 3 USB devices use the same serialnumber. And all 3 respond (if they can)
Yes, but does your run script then correctly unlock the serial device? I cannot say for sure of course, I’m just looking at the log and wondering why it seems to stop after trying the battery driver.
What should happen, if you plug in a serial/RS485 cable with nothing on the other end, is it should try the “drivers” one after the other in a never-ending loop.
@plonkster I hear what you are saying, but if the problem is that the driver is not releasing the serial port this would be a problem for all installations.
The run was copied and modify from another driver and is very plain.
#!/bin/sh
exec 2>&1
exec softlimit -d 100000000 -s 1000000 -a 100000000 python /opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py /dev/TTY
Jose had the same problem. The issue was with custom cables that had problematic serial numbers (all the same). The solution was to change the cable serials and names. Or you can swop the cables out with correct cables like the Victron versions.
In this topic below is also an example of how the log looks when it exits correctly.
@lukaswien you might want to read up on how Jose changed the serials and names. Here is the post
The reason why I hammer on this a little bit, is I remember when that particular developer made that change because it broke one of my own scripts (the one starting cgwacs). In my case, the effect was that the grid meter was lost (not re-detected) after a power failure. So I know there is something going on here… potentially
Take a look at the run script for dbus-cgwacs, which in turn calls another shell script (start-cgwacs.sh) which uses some serial-starter shell libraries. Specifically, one of them implements signal handlers that catch the TERM signal and unlocks the serial device. I have a feeling that may make it more dependable.
1 Like
OK, it probably wasn’t cgwacs, but it was something else that also uses the same RS485 cable. It broke the loop and it never “came around” back to cgwacs. It’s been 3-4 years, I cannot remember 
What’s interesting is that it works fine with “pure” VenusOS. Once I install the driver, the cheap cables stop working altogether regardless of whether the Battery is plugged in or not.
Also a fairly common cut-off. Perhaps I’m being a bit too generic when I say “most” brand names. I should perhaps have said “many” I also just realised that Pylontech cuts at 3.6V per cell.
I suppose that in a very badly unbalanced battery, you could be in a situation where most of the cells are at 3.2V and one is at a higher voltage. But below 3.3V you are still very much on the “flat” part of the charge curve, so usually the imbalance only shows up above 3.35V per cell. At least, that’s the worst case I’ve dealt with (3.35V on 15 cells, 3.75V on the 16th one).
@plonkster & @TheTerribleTriplet
I like you to consider Will’s recommendations as to what state of charge to take your battery up to for maximizing longevity:
At a voltage of 3.65V, I think you’re charged up to the high 90%s. (98% I’ve seen if you believe the internet?)
I’ve said it before and I say it again, it is best to live on the flat of that charging curve.
1 Like
Right, @Phil.g00 , with the info below, 16 x 150ah cells, to keep them happy and give them a LONG life.
What would your settings have been:
Battery capacity:
% that Bulk is finished:
Charge Efficiency:
Bulk/Absorb:
Float:
Charge amps:
DC input low voltage shutdown:
DC input low start:
DC low voltage alarm:
At 3.65V you’re above 99% full. I agree with you almost completely. I advise people to aim for 3.45V per cell. That’s JUST towards the edge of the flat before things get out of hand…
The trouble is that many commercial batteries go higher. To live with them, you have to play their game. To make their balancers work properly, you sometimes end up with cells as high as 3.7-3.8V. For a while… until it settles. After that, by all means stay below 3.5V. No need to go any higher than that.
To my mind, the most meaningful parameters are the max charging rate, the typical discharge rate, maximum charging voltage and minimum voltage cutoff.
Bulk/Float voltages distinctions aren’t really useful for Lithium.
Alarm levels are just sensible margins or possibly useful aids to “learn” the behaviour of your cells or your usage patterns. However, if you are not getting any value from your alarms why have them?
The charging/discharging curve and your typical loading/charge rate will dictate the ideal scenario. These curves can be obtained either from the manufacturer or plotted by yourself.
I’ll attach a family of the typical curves, with the obvious caveat that the charge/discharge curves would e specific to your battery.
But let’s analyse this one and for the purposes of this discussion I’m saying the charge curves are identical to the discharge curves, (which is not true) :
I’d use the appropriate charge curve for my charge max charge rate setting to determine the maximum voltage threshold. From a curve like this, let’s say I limit my charging current to 0.33C, (the blue line) then about 3.285V/cell is probably as high as I want to go.
(In reality, I’d expect the charging curves to be ever so slightly elevated from the discharge curves).
Then I’d use the appropriate discharge curve that is my typical load to determine the low voltage cut off. Let’s say 0.2C is my typical discharge rate. I want to stay away from the kneepoint so 3.195V/cell probably as low as I want to go.
This looks too conservative, looking at your manufacturer’s stated voltages of 3.65V and 2.3V respectively. However as translated to these particular curves, the voltage thresholds in this example would yield a useable capacity of about 95% through to 12.5% capacity, which is extreme.
Will Prowse says for longevity it should be more like 75% to 25%, if I recall his video correctly.
My thoughts about balancing not happening below certain thresholds, is the tail shouldn’t wag the dog. Not much of a BMS if you have to knacker your batteries, so the BMS can kick in to supposedly make your batteries last longer.
I wonder what it looks like if you zoom in a bit on the straight line on the left.
My primary motivation for using a lower voltage is stability more than longevity (because I hate support calls). I find that at 3.45V, the cells still readily accept charge current for minutes at a time (so a slightly slow control loop is not a problem), but at 3.65V per cell, it takes mere seconds to overshoot.