I’ve not used the device you have - but there are two sections named “all” - is it worth merging them or deleting the first [all] section?
good point Stuart, although I’m pretty sure venusOS is happy to read as many such sections, every time I reinstall/upgrade there are such sections and things seem to work till the time I bother to connect and check…
hmmmm. i got now one board working. BUT I HAVE NOT CHANGE ANYTHING.
this makes me crazy…
what i did:
- situation as before
- unplugged (first power, then can) the controller (lets say n°2)
- plugged the can hat to the controller n°1
- plugged in the usb and changed wlan with the putty
- switched on the can bus in the diybms
interestingly the Venus shows now “ERROR-ACTIVE”
result!
you do have to reboot the lot everytime you change something (imho)
try different on off procedures to make sure it’s going to work after an unexpected reboot/restart.
1 Like
Well, either Stuarts Video has a failure or the boards lettering.
I have finally got one board to work in the way, stuart connected it in the video.
Pin 8 to Hi and Pin 7 to Low which is in fact Hi to Low and Low to Hi… as per the Canbus manual from Victron.
@vas it seems like, that the two not working boards have 0.7 Ohm between the 5V Port GND and the GND of the Can Port. While the other Board has OL (open line)
Hello Vassilis. My name is Detlev and I live in Germany (Speyer). You got the DIYBMS running on the Raspberry with Venus OS. Could you tell me the steps and the materials once. Gladly also to my email: [email protected]
Greetings Detlev
hi Detlev,
I’d rather reply here so:
A. others can read later on and solve similar issues
B. other forum members can also help. I don’t consider myself an expert on the topic by any stretch of imagination!
I’m using a raspberry pi HAT AND an PEAK USB canbus. One is running the NMEA2000 comms to the victron the other is running the diyBMS comms to the victron.
Either should work.
Cheapest HAT I could find at the time was the WAVESHARE one. The PEAK ones I had bought 15yrs ago believe it or not and were never used…
Tell us what you have and we can go from there.
cheers
V.
Hello, my dears.
I got it to work now too. After I mounted the Waveshare Hat it worked immediately, only nothing came via USB. Thank you to everyone who has dedicated themselves to this topic.
Has anyone actually tried to display a 2nd battery in Venus OS? Is that possible ?
Greetings Detlev
well done Detlev in joining the club!
My system now has a MultiplusII, a BMV700 and the diyBMS. I can choose which one to show on the screen (obvious option is to select diyBMS and since I have my old lead acid bank in parallel to the LiFePO4, BMV700 shows overall data. You can see all of them in the settings screen, but not in one of the main graphic screens, there you can only have 1 bank showing.
V.
Hello Stuard,
I understand why CVL is better than CCL! But the DIYBMS reduce the current to a specific value, if the battery need balancing, right?
What I also do not understand: In the Victron setup I enter the total voltage of the battery, would it not be better if overvoltage of a single cell is reported to the Victron system?
1 Like
there us something else i want to report.
It would be good to have a timer for those rules to be delayed. In case CCL limit incase of a cell over voltage, the victron system immediately reduces the charge current correctly, but as the call recovers in seconds, the CCL will be deactivated again. This results in a constat on/off cycle.
I have used the diybms shunt to measure the battery. the victron shunt is now used as a dc system power meter.
in case of a active CCL, the victron system reduces not the general current to the dc system an battery instead it just reduces the current flowing the the battery. (Not tested yet!)
Good points, I’m halfway through my battery install so will have time to tweak the victron/pylontech code to add more features soon.
No worries. Had my first holiday with your diybms and victron. Perfect match! Great work!
I’d like to chip in with my 2¢ here.
Current limitation doesn’t work well, or at all, when you’re charged up and start balancing, Victron regards the current limit as a rough guideline but as soon as you also pull lots of current via the inverter (so solar generated 100A and your inverter takes 99A, leaving 1A for the battery) there’s no guarantee that the current to the battery will be low enough for the balancer to handle, given that current measurements are maybe 2% accurate in one direction or another. I should know, I posted a change request to make these CC limits safer: if you look at the code you’ll notice that there’s a 5% safety margin which is applied inconsistently, dbus-systemcalc-py/delegates/dvcc.py line 430 or thereabouts. This change was rejected. Bottom line: Use CVL for safeguarding your battery.
Regarding CVL. I’ve experimented with various algorithms in my BMS code and the following seems to be reasonable:
- Identify the cell with the highest voltage. This cell is X volts below 3.6V (or whatever you use as the top voltage).
- The max CV which the BMS should send to the Victron system is the battery pack’s voltage plus the “discounted” difference between each cell’s voltage and 3.6V. “Discounted” means that if a cell is at 3.6-X, you add X. If it’s at or below 3.6 - 1.5*X, you add nothing. In between you do a linear interpolation.
Here’s a simple example why this makes sense. Assume that you have a two-cell battery with one cell at 3.5V and the other at 3.4V. The max CV of this battery should be 7.0V because the LiFePo4 charge curve is such that soon enough, one cell will be at 3.59 and the other will be at 3.41 or thereabouts. At this point current to the battery must stop until your balancer removes enough charge from the 3.6V cell; basic physics tells us that current stops when voltages are equal, so any CC limits (which you’ll still want to set of course) and the accuracy thereof won’t matter.
The factor 1.5 is my best guess right now. I started off with 2 but that turned out to be somewhat too high for the 3.55 top cell voltage I’m using. Also I didn’t yet check whether something more intelligent than simple linear interpolation might improve things. “Improve” here means that as a reasonably-well-balanced battery progresses to getting fully charged, the max CV as determined by this algorithm doesn’t change much.
YMMV and all that.
NB, when the system is idle(!) your BMS’s measurement of the battery pack voltage should be equal to whatever the rest of the Victron system says the voltage is. If it’s not, this won’t work.
Hi Stuart,
thanks for for this valuable piece of the Victron specification. Could you tell me from which document this is? I didn’t find anything similar on the web. Thanks.
Regards
Benjamin
Hi Vassilas, have you got any experience in pushing data gathered with signalk to influxdb 2.x?
I cant put my finger on how to achieve that…
Maarten,
my rpi3B+ running VenusOS (now 2.91) with signalk and node-red was originally setup a year ago and it’s been v.robust and pretty straight forward.
I’m pushing data from the rpi to my work server running Win Server where I wanted to install standalone s/w and configure it properly. Didn’t like the idea of running docker on my system. At the time I could only install influxdb 1.6 (or whatever that was, definitely NOT 2.0) but affects venus->influxDB connection on one simple setting, so no big deal.
For sure you need the Large version of OS (pretty obvious really) and once everything is running, you need to enable SignalK and then go to venus.local:3000/ to enter the signalK config, install signalk-to-influxdb (lately called influxDB writer or something) and configure it. Obvs in order to do so, you must have the influxDB running properly with a DB, configured passwds, etc on a remote computer.
so if you want to be a bit more specific on what you need I’ll try to help.
cheers
V.
It’s from a document victron sent me, which I think was sent in confidence so i can’t publicly share it.
Well i have got a pi3b+ running venusos 2.91 large, i have a bluesolar chargecontroller attached with a diy ve.direct cable, which works. Venus sees the chargecontroller allright. In signalk i got the venusos plugin configured and running. Signalk sees the data coming in.
My influxdb 2.0.8 server is running and working with designated buckets and tokens. I got it running with data going from my diybms controller allright (but i fried the controller and waiting for spareparts, so no data going in at the moment).
After downlaoding a plugin to push data from signalk to influxdb2 and rebooting i filled in some of the fields(simular to that in the diybms controller, but a different bucket) i get some errors…
So i am not sure if i need to make additional configurations…because i have not done anymore settings than decribed above…
Well, the Victron paper’s explanation on why CCL doesn’t work is interesting but somewhat disingenious. You can tell the Multi(s) to pull 150A and you can tell the solar chargers to deliver 150A, thus simple physics tells us that no current is going to the battery, so what’s the problem?
The real reason why CCL won’t work is that current measurement is not an exact science, thus if both are 1% off (in the “wrong” direction) 3A will be going into the battery. This is not a good idea if one cell is at 3.65V and your passive balancer can only discharge 1A.
While voltage measurement also isn’t an exact science, they are usually more exact than currents. Also, voltage is much more stable, as charge current varies with sunlight and discharge current varies with AC load. Thus it’s far easier to fix a measurement problem by comparing the Multi’s and the BMS’s idea of the DC voltage and applying a correction factor if necessary, than it would be with current.