That is why I will not even contemplate to buy another Daly BMS, or ever run my system with a no-comms setup again.
@GVC quick question, are you using the bluetooth of the Smart Ant bms to pull the data to your pc or are you using the USB converter that they selling now with the new ANT smart BMS?
I like what you did there.
I found this to be quite interesting. Here is a snippet that tells most of what you need to know:
In this study, the degradation of LiFePO4/graphite battery under over-discharge process and its effect on the further cycling stability are investigated. Batteries are over-discharged to 1.5, 1.0, 0.5 or 0.0 V and then cycled 110 times under over-discharge condition. The batteries over-discharged to 0.5 and 0.0 V experience serious irreversible capacity losses of 12.56% and 24.88%, respectively. The same batteries lost 7.79 and 24.46% more capacity after they are further subjected to 110 cycles between 3.65 and 2.0 V at 1C/1C, respectively.
It seems from this paper that down to about 1V doesn’t seem to cause serious damage yet. (Maybe it just takes longer to be damaged at that voltage)
1 Like
I am pulling the data from bluetooth to my rpi4 using a python script that writes the data to Paho mqtt, then to node red.
I have attached the script if you are interested.
SmartAnt_BMS.zip (1.7 KB)
Hi,
Tried connecting my 20S400A Ant BMS to Venus Rasp with a Victron VE.Direct to USB cable, only connected the Ground, Rx & Tx to the BMS.
/data/log/serial-starter/current shows me that the VE.Direct to USB cable is connected to USB1
sadly the bms doesn’t show up in Venus device list, do I miss something ?
@40000000604e1f5408a7dfac serstart starting
@40000000604e1f540936b9fc INFO: loading config file /etc/venus/serial-starter.conf
@40000000604e1f541f5f16fc INFO: loading config file /data/conf/serial-starter.d
@40000000604e1f551e3df374 INFO: Create daemontools service mk2-dbus.ttyUSB0
@40000000604e1f56263f8ac4 INFO: Create daemontools service vedirect-interface.ttyUSB1
@40000000604e1f5807c5ebec INFO: Create daemontools service vedirect-interface.ttyUSB2
@40000000604e1f59260738cc INFO: Create daemontools service vedirect-interface.ttyUSB3
@40000000604e1f5b26516ce4 INFO: Start service mk2-dbus.ttyUSB0
@40000000604e1f5c2a3083a4 INFO: Start service vedirect-interface.ttyUSB1
@40000000604e1f5e0f0c39ec INFO: Start service vedirect-interface.ttyUSB2
@40000000604e1f5f2dfa31ec INFO: Start service vedirect-interface.ttyUSB3
Hi @picard
I am not seeing that the serial driver is started. Which method did you use to install the driver?
I assume you installed the latest v0.9 version. In it there is a script you can run that might help if the autoinstaller did not run correctly.
sh /data/etc/dbus-serialbattery/installrelease.sh
thanks for you’re reply, installed it with a usb-stick and rebooted.
I did a clean install of Venus 2.73 and when I run the script 0.9 I get exact the same message:
root@raspberrypi2:~# sh /data/etc/dbus-serialbattery/installrelease.sh
ln: /opt/victronenergy/dbus-serialbattery/dbus-serialbattery: File exists
ln: /opt/victronenergy/service/dbus-serialbattery: No such file or directory
ln: /opt/victronenergy/service-templates/dbus-serialbattery: No such file or directory
root@raspberrypi2:~#
I get the same … these are all the commands I’ve picked up, to date, to make it work … yeah, I tamper a bit sometimes. Maybe it helps if you “force” it.
There is this command, but it seldom works for me, so I split it with Louis help a long time ago:
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
Step 1: Login tot the Venus/Cerbo, then using this command, see what files are there already:
ls -lh
If there are like venus-data.tar with whatever extension, delete it first like so:
rm venus-data.tar.gz
Step 2: Now run this command, to download it again:
wget https://api.github.com/repos/Louisvdw/dbus-serialbattery/releases/latest grep “venus-data.tar.gz”
Step 3: Now install, re-install it again:
tar -zxf venus-data.tar.gz -C /data
You can then reboot, or, if the driver is on USB1, use as is, or alter to your USB no:
Start the driver manually:
opt/victronenergy/serial-starter/start-tty.sh ttyUSB1
Stop the driver manually - if you ever want to restart it:
/opt/victronenergy/serial-starter/stop-tty.sh ttyUSB1
Or use this command to stop/start the driver - again, IF it is on USB1:
Stop:
svd -d /service/dbus-cgwacs* /service/dbus-serialbattery*
Start - if on USB1:
svc -u /service/dbus-serialbattery.ttyUSB1
Once working, I edit these two files, to set my settings:
nano /data/etc/dbus-serialbattery/utils.py
nano /data/etc/dbus-serialbattery/battery.py
All done directly on the Venus/Cerbo, using Root access.
You can try the steps that @TheTerribleTriplet give. It should show where there is a problem.
It does seem that perhaps there are some missing folders.
Also check all the logs files as per the troubleshoot guide.
Hi, thanks for you’re help
seems that I don’t have the following dir’s:
/opt/victronenergy/service/dbus-serialbattery
/opt/victronenergy/service-templates/dbus-serialbattery
added them by hand, didn’t help
When I do /data/etc/dbus-serialbattery/start-serialbattery.sh ttyUSB0 it gives >
UTC-2021.11.10-11:46:32 Starting dbus-serialbattery.py on ttyUSB0
WARNING:SerialBattery:dbus-serialbattery v0.9
WARNING:SerialBattery:Testing LltJbd
ERROR:SerialBattery:>>> ERROR: No reply - returning
WARNING:SerialBattery:Testing Ant
ERROR:SerialBattery:>>> ERROR: No reply - returning
ERROR:SerialBattery:>>> ERROR: Incorrect Data
WARNING:SerialBattery:Testing Daly
ERROR:SerialBattery:>>> ERROR: No reply - returning
WARNING:SerialBattery:Testing Daly
makes me think that connecting serial to the lcd wires of the Ant BMS is incorrect,
Will buy a Daly BMS with USB<>RS485 cable soon to continue with this project in a few weeks.
Don’t add them by hand. They are symbolic links. rc.local is suppose to create those links for you.
Can you confirm that you have the folder /data/etc/dbus-serialbattery/ and that it has a few *.py files and a /data/etc/dbus-serialbattery/service/ sub folder?
If you do have the subfolder then run this:
sh /data/rc.local
The ANT’s connection is a bit tricky, but it should work. However if you do want to switch to another BMS get anything other than a Daly. The Daly itself have too many issues and although the driver works fine with it, there are better options for the same price if you don’t already own one.
It means there was a reply from the ANT, but not a valid one.
This could be that the RX/TX wires is the wrong way around. Just swop them and try again.
I added the folders so rc.local could make the symbolic links.
which BMS do you advise ? (best in communication and sold with USB<>Serial cable)
I want to let you guys slug it out… cause that’s how you learn and I know nothing about this driver really…
But I didn’t see anyone mention what Venus version he is using. And I see the script attempts to put things in /opt/victronenergy/service, which will only work in 2.80 and later…
So you are using 2.80, right? Not 2.73? 
Ha! We’ve learned too much already @plonkster 
.
OK it makes sense now. This would be on Venus V2.73 or lower and the /opt/victronenergy/service/ does not exist. So those errors should be fine.
@picard I asked the ANT users that help with the development to send me more details and pictures to update the guide in the wiki. If you don’t want to wait for that, you can pic any BMS that the driver support as an alternative. JBD is the best tested and most flexable with settings you can set. JKBMS is a nice option with active balancers and also very capable.
Im using 2.73 at the moment
Also, @Louisvdw, we are making changes to the dbus comms. Instead of sending PropertiesChanged signals on every value change on a path, you can now send/receive an ItemsChanged signal that contains all the changed values in a single dbus message. That significantly cuts down on the overhead.
It is already in velib_python. To use it, you would do something like:
with self._dbusservice as service:
service['/Dc/0/Voltage'] = 54.1
service['/Dc/0/Current'] = 12.2
And whatever you do inside that contextmanager will go out as a single ItemsChanged message. This is not essential yet, at the moment both signals are still supported, but something to start looking in to soon, probably when the next Venus Candidate lands.
Also, I notice that handle_changed_setting will change the DeviceInstance. You are not allowed to change that without disconnecting and reconnecting to dbus.
Probably not the best place to mention these things… but I did glance at the code just now… so might as well
1 Like
OK then you can ignore those 2 errors in the symlinks.
Do you get any /data/log/dbus-serialbattery.ttyUSB0/current log being created?
Saw that my modus communication with Homeassistant has crashed due to changed unit id’s, so no reason not to try 2.80 again tonight 
hope rc.local will run without errors and no “too many symbolic link error” “/service” in the logs that I had earlier.
Bugger me …
The difference between learning and wasting time is a “hairlines breaths” difference as I’ve seen the last 20+ years with development.
Like picking up on v2.80 being one of those saving a ton of wasted effort, no learning … mmm … see *** below … same as you picked up the Carlo and driver fighting in my case.
Respect.
Louis had me make a code change, it seems to be fixed … for the rest.
*** Louis, suggestion, adjust your install notes, state v2.80 or higher is required of the Venus.CCGX, Cerbo, Rpi. No matter that it can be backward compatible … it saves time and effort. Nike … 