Cross your fingers yes!!!
@SchonRichtig there is a new build which should solve the issue where this driver disables other components. Now you should not need any sleep functions.
Just update to the latest release (v0.4)
curl -s https://api.github.com/repos/Louisvdw/dbus-serialbattery/releases/latest | grep "browser_download_url.*gz" | cut -d : -f 2,3 | tr -d \" | wget -O venus-data.tar.gz -qi - | tar -zxf venus-data.tar.gz -C /data
There is a new beta build v0.5beta* for the initial Daly BMS integration for those that want to test it and give feedback.
This build should work for both the RS485 and UART connection, update the battery SOC, voltage and current in the GX device.
Download the venus-data.tar.gz from the latest beta and FTP it to your GX/pi.
Extract using tar -zxf venus-data.tar.gz -C /data
Reboot and let me know if it works.
Those small 4cell Daly BMS seems to be running a different protocol, so I don’t expect them to work.
Thanks,
now it works without delay.
1 Like
Great work on the whole project it’s what I wanted to see.
Question,
1- Where did you get these BMS Charge & Discharge Limits values?
2- Can we edit them?
Thanks for your time, Mike
1 Like
The short answer is that I had to pick some values that should be useful but safe(mostly).
Yes you can edit them. Lowering is very easy in DVCC. Making them higher currently involves editing the code and any update will erase your changes.
See point 7 under How to install for more details:
Hi,
Since I installed Serial Battery Driver I loss Carlo Gavazzi ET112 Connection (RS485 Victron Cable)… When I restart Cerbo or plug the RS485 to USB cable into Cerbo I get 3 times green blink on cable but after that only red blink on RS485 Interface.
There will be 2 log files to check.
/data/log/serial-starter/current to see if the ET112 is picked up and started.
And then the log file for that port for the ET112
/data/log/cgwacs.ttyUSB0/current where ttyUSB0 will be your USB port.
What does sometimes happen is that the ports move when you plug in a new USB device. So the old USB0 becomes USB1 or USB2 becomes USB3. In this case the previous port config that is stored in the GX is not valid anymore, but if you give it a while it recover itself.
What I can say is that the driver for the Carlo devices is initialised first and the serial battery driver last, so by the time the serial battery driver is tested all other drivers failed before.
1 Like
Hi @Louisvdw
Have you gotten around to seeing what happens on the Venus with 2 or more BMS’s connected to it?
I have not been able to install my new BMS yet. 
Work is interfering with my hobbies
Hello Louisvdw,
Thanks for the serial battery driver.
In the VRM-Online-Portal there is a ‘Battery Mid-point voltage’ widget.
With an even number of cells this funktion would give anyone a warning, if one half of a Battery is much different from the other.
E.g. cells which are drifting, begin to fail.
Is there a chance to implement this funktion or is it implamented already and I can’t find it?
Adding to that … IF that could be done, and an imbalance is detected, exceeding a set parameter, then drop the charge/discharge amps immediately.
Goes a HUGE way towards letting the BMS catch up with balancing.
Hi @seepv
That is a graph created for the BMV. It (only) has a midpoint.
But I guess I could populate that as well. Seems like it might be a valuable graph 
Ticket created. Subscribe to it if you want notifications.
1 Like
If you have this and the battery is only 50% it might sort itself out by the time you get to 80%. Or would you drop the amps at 50% as well?
I see where you are coming from … good catch!
Take my case, if I knew there was a huge difference between the highest and lowest cells, say like >0.1v, it would have been awesome. A user-defined value.
For when I saw my HUGE imbalance, I used DVCC to drop the max amps to give the BMS a bit of help.
We are talking the same thing?
The midpoint from the BMV will normally be if you have 2x 12V lead acids to give you the 24V (for a 24V system). The total battery might be 24.5V, but the one 12V can read 11V and the other one 13.5V which would show a problem.
We should be able to make this work for a Lithium battery as well, calculating all the cell voltages for the first half of the cells and comparing that to the second half. You still get just the halfway voltage and diviation.
This is not something for each cell. For that you will use the BMS Min/Max Voltage graph. That is more detailed (per cell vs per half the battery) and that is already populated.
I’d think that’s what the CellImbalance alarm is for (/Alarms/CellImbalance on dbus).
I agree. Makes much more sense.
This is such a cool project.
I am really battling to get the driver working despite trying the different install methods and going through the troubleshooting section.
It seems that the the driver is not starting against a USB port, but I am new to this, and could be missing something obvious. Please help.
Some background to what I have tried:
This seems to download it ok
wget https://github.com/Louisvdw/dbus-serialbattery/releases/download/v0.5/venus-data.tar.gz
This gave no feedback, so unsure whether it ran or not
tar -zxf venus-data.tar.gz -C /data
No sign of dbus-serialbattery.ttyUSB0, which should show here, I gather
root@beaglebone:~# tail -f /data/log/serial-starter/current
@400000006128bdac3587c9ec INFO: Start service gps-dbus.ttyUSB0 once
@400000006128bdb614e0f68c INFO: Start service vedirect-interface.ttyUSB0 once
@400000006128bdbb2a7f43cc INFO: Start service dbus-cgwacs.ttyUSB0 once
@400000006128bdbf015a7d2c INFO: Start service dbus-fzsonick-48tl.ttyUSB0 once
@400000006128bdc41606a624 INFO: Start service dbus-imt-si-rs485tc.ttyUSB0 once
@400000006128bdc729b350dc INFO: Start service gps-dbus.ttyUSB0 once
ls /data/log/ reveals nothing with dbus-serialbattery
Seems that relevant files are present
root@beaglebone:~# ls /data/etc/dbus-serialbattery
LICENSE dbushelper.py
README.md lltjbd.py
battery.py service
daly.py start-serialbattery.sh
dbus-serialbattery utils.py
dbus-serialbattery.py
root@beaglebone:~#
This is on a Venus GX and I updated the firmware between most of the attempts, using a flash drive, so that there was a clean version of VenusOS
The RS485-USB converter is from Victron and I know it works because I plugged it into my PC and received BMS data there.
Any ideas what could be missing?
@Tom, have you restarted the GX after you installed the driver?
If the files exist then the tar command completed successfully. But the service that starts the serial drivers would already be running and not know about the new stuff. The easiest would be to do a restart.
Edit: just to clarify. If you put the venus file on a USB then the GX does all this for you. But for the manual download and extract that you mention you have to restart the service. Restarting the GX is the easiest way to do that.
1 Like
Also, please note that in Venus 2.80, the rootfs is now read-only. To install the service, you need to remount it rw (which you can do with the script /opt/victronenergy/swupdate-scripts/remount-rw.sh), and then the service needs to be installed in /opt/victronenergy/service instead (which is overlayed onto /service at bootup, but reset to original at each boot).
You didn’t say what Venus version you are using, but if you are strugling with 2.80, go back to 2.72 and get it working there first.
3 Likes