What is the latest Venus version that is recommended to be used with the driver problem-free?
The last comments speak about V2.73, but is this related to problems with specific hw setup (having BMV together with the BMS rs485) or there are other issues?
VenusOS firmware V2.73 is the best option to use if you have anything other than Raspberry Pi4.
If you have a Pi4 then stay with 1 BMS for now.
I have a BMV and a BMS, no problem.
The only problem I have is when there is LS with v2.80+, when LS is over, the ET112 is “lost” on my sold Venus and the new Cerbo. Have figured out how to get it back for the next LS event, but if I’m not at home it is a huge issue. The matter has been reported and is being looked at.
Multiple BMS’es on the same Pi / Venus/ Cerbo, the issue comes in which BMS SOC to use? Also a known matter for finding a solution for that.
Otherwise, quite a solid driver if I may say so.
Will use it again once the LS + ET112 + V2.80 or higher has been resolved. Till then I’m running off the BMV for the SOC.
Has anyone tried it with new versions higher than 2.80? 2.86 or 2.90 for example and they work with two usb devices like dms and bmv?
2.73 is still the best option for mutiple devices.
Someone mentioned that 2.90 (currently in beta) works with 2 BMS, but from my tests that did not work.
BMS + BMV works fine on my site. BMV never goes off like the Carlo.
And if there is no Carlo in the system, no problem either.
It is only the Carlo Gavazzi that gets “lost” on versions after 2.73 when LS is over. During LS the Carlo goes off. After LS it comes back on. As it cannot then reconnect to the Venus OS, for whatever programmatical reason, the system is left without a grid reference.
Currently, I and a few others, run without the driver on our systems whilst patiently waiting for the issue to be found and resolved. Till then we use the BMV which gives a fairly accurate SOC IF the cells are in balance.
It’s because the startup script for your BMS driver messes up the hardware-detection system built into Venus. The hardware detection system sits in a loop, trying different hardware drivers until one sticks. The protocol is that any driver you insert into the loop must gracefully exit and then unlock the serial port to make it available again to the next driver in the list.
For whatever reason, the serial-BMS screws something up. So the Energy Meter service dies (because the meter loses power) and the hardware detection loop then attempts to run the serial-BMS driver on the same port. That fails… and then it is basically stuck there forever, never looping around and coming back to the energy meter driver again.
He knows. But it’s been rather hard to debug I understand…
I’m at the point where I might have to create a dummy driver with nothing excet that it just exists to see if that helps.
I’m doing an exit the same as all the other drivers in the GX.
What is strage is that it seems that the tty devices gets crossed wired. So it might not even be the code.
Arrgggg… 
@Louisvdw , the trick is in serial-starter. Before it starts a service, it calls lock_tty (look in /opt/victronenergy/serial-starter/functions.sh), which creates a marker in /var/lock/serial-starter. That indicates that the port is being handled.
If your service cannot handle the port, it should terminate, and then remove the marker file (by calling unlock_tty). The standard start-stop machinery does this by installing a TRAP that calls cleanup on exit, look in run-service.sh in the same directory.
Periodically, serial-starter attempts to start a service on everything in /dev/serial-starter/ (where udev drops a symlink), unless that service is locked.
Usually, the missing step is that people forget to unlock the tty (or the script crashes before it gets to that line). Which is why using a TRAP works so well.
But in your case it seems the driver itself holds on to the tty (of a cgwacs meter) and doesn’t exit… I have no idea why that happens. It confuses the heck even out of me…
Is it a reasonable assumption that with a bit of elbow grease I could make it work reasonably well with pylontech over console port (instead of using modbus for pylontech which venus OS currently supports)?
I’ve been toying with the idea of getting around with setting up venus OS on a pi but the hassle of sourcing a modbus HAT etc. keeps making me avoid it; I wouldn’t mind spending a bit of time playing around with this though.
You don’t really need a HAT, a simple USB adapter would work. @plonkster mentioned which chipsets are supported in another thread…
If you’re going to rewrite the driver to talk to pylontech over their console port, you would need only some kind of FTDi-based USB-serial cable, correctly crimped to the console port. But CAN-hats are cheap… why would you hurt yourself like that? 
Already have the serial cable as its needed for firmware updates etc.; but yes you have a point maybe its better to get a CAN-hat, didn’t realise they were available locally for that cheap TBH
You can save R30 off at Micro Robotics
It’s possible, but for a low price like that not worth the effort I think.
Yeah think I’ll just get the HAT
One of my other reasons to not use modbus was to keep the gpio pins open for other devices, but I guess its not that important.
Hi,
thanks very much for your work on BMS it help many users i see and i have to go this way but need to clarify some details.
I have 2 batts 16S 105Ah and 135Ah. Both batts have Daly Smart 300A (BT + UART and RS485 connectors) in package BT connected to UART and RS485 - USB cable.
The Victron side is Cerbo GX. Is there a guide how to connect both BMS to GX to monitor both batteries? Thanks
You mean R2.15? (R199.95 vs R197.80, both incl) 
it was R170 at the time I quoted. You snooze you looze 
