question

@alferz I very much doubt it is an issue with the usbserial driver. The reason for the difference is the kernel itself. So you cannot copy the usbserial driver from one to the other and expect it to work.

You have not shared any details on the make and model of the rs485 adapter you have, or the chipset it is based on. VenusOS has a means of detecting devices on certain RS485 adapters, for some specific chipsets, through the serial-starter scripts deployed into udev and other parts of the VenusOS to detect what is on the RS485 connection and start the respective service.

I suspect what is happening is that two systems are trying to open the RS485 bus and creating conflict. VenusOS itself may be opening the RS485 interface and trying to detect the service, as well as NodeJBD and/or jbdtools. I suspect that the VenusOS is holding the ports open, creating a problem for your other code.

A search of the web for serial-starter and venusOS will provide a lot of useful background information. One in particular might be this link. If my hypothesis is correct, you need to stop VenusOS from opening the RS485 interface, allowing your code to have full access to the interface.

Do note however that VenusOS is what is referred to as an embedded operating system. While it is based on a linux kernel, it is not a fully fledged desktop OS. It has been modified and developed to do just one job, managing and reporting on a Victron eco system of energy storage and power management. You will therefore find that components you expect to be there are either not or are cut down with limited functionality. One such component is apt, which will not work particularly well as VenusOS has it's own opkg package manager and combining apt with VenusOS could cause dependancy issues with regards to base libraries.

Regarding installing the VenusOS packages on Raspbian. I suspect some people may have managed it, but it will be a lot of work, trial and error and no-one that I am aware of has any documentation.

@Bathnm -- I dont know what I would have done without your post, thank you for your expertise. That link was not coming up after a great deal of Googling this problem. Your hypothesis proved correct, and simply ignoring /dev/ttyUSB0 using

/opt/victronenergy/serial-starter/stop-tty.sh ttyUSB0

did the trick -- causing serial-starter to stop polling the port and opening it up for jbdtools, node-jbd or even a quick python script to poll the BMS with ease. The second method of adding an ignore line to /etc/udev/rules.d/serial-starter.rules was even better because it is permanent and also avoids blocking other ttyUSB dev's like the MK3-USB which may change ttyUSB#'s in my testing. With that method you can block by the unique model ID of the device you don't want serial-start'd.

My RS-485 to USB adapter is a WaveShare FT232RL which shows up as an ftdi_sio compatible device just like the MK3-USB does, I imagine any /dev/ttyUSB* device would have this same issue.

Thanks again!