VRM instance toggles after every reboot

[winfriedp]

dbus-serialbattery 0.14.3 is installed on a Cerbo GX v2.93. My battery is connected from a JK BMS to the Cerbo via an isolated USB to RS485 Converter with a CH340E Chip. Every time I reboot the Cerbo the SerialBattery VRM Instance toggles between 1 and 2. Has anyone ever observed the behavior?

[teefixx]

Hi, I see the same behaviour and I think this issue (#456) is caused by that fact.

[winfriedp]

Thanks for the advice. It is quite possible that this is the same root cause, but what is the root cause? SerialBattery, the connection adapter or Venus OS? I'm afraid only Louis can answer that.

[teefixx]

Just as additional information: I just had the problem, I had to restart my VenusOS

• got new VRM Instances

Tried another reboot and I got the original VRM instances assigned. I think this is by chance...

[DirkReudenbach]

On my Installation it´s changing always between the VRM instance 1-3 after reboot. It‘s even more worth because if connected with Cerbogx and BMS you need to choose ohne BMS as reference. If the instance is changing after reboot - the MPPT will fail with Code67 which results in no charge of the MPPTs. Therefore ím using the Smart Shunt as reference. Maybe Louis can investigate?

[mr-manuel]

Have you all only one BMS or multiple BMS?

1. Could you check, if your serial to USB adapter changes also ID like ttyUSB0 to ttyUSB1?
2. Check with dbus-spy the value under com.victronenergy.settings -> Settings/Devices/serialbattery_zero/ClassAndVrmInstance

This should be the relevant lines to this:

dbus-serialbattery/etc/dbus-serialbattery/dbushelper.py

Lines 42 to 84 in 6471152

	def setup_instance(self):
	# bms_id = self.battery.production if self.battery.production is not None else \
	# self.battery.port[self.battery.port.rfind('/') + 1:]
	bms_id = self.battery.port[self.battery.port.rfind("/") + 1 :]
	path = "/Settings/Devices/serialbattery"
	default_instance = "battery:1"
	settings = {
	"instance": [
	path + "_" + str(bms_id).replace(" ", "_") + "/ClassAndVrmInstance",
	default_instance,
	0,
	0,
	],
	# 'CellVoltageMin': [path + '/CellVoltageMin', 2.8, 0.0, 5.0],
	# 'CellVoltageMax': [path + '/CellVoltageMax', 3.45, 0.0, 5.0],
	# 'CellVoltageFloat': [path + '/CellVoltageFloat', 3.35, 0.0, 5.0],
	# 'VoltageMaxTime': [path + '/VoltageMaxTime', 900, 0, 0],
	# 'VoltageResetSocLimit': [path + '/VoltageResetSocLimit', 90, 0, 100],
	# 'MaxChargeCurrent': [path + '/MaxCurrentCharge', 5, 0.0, 500],
	# 'MaxDischargeCurrent': [path + '/MaxCurrentDischarge', 7, 0.0, 500],
	# 'AllowDynamicChargeCurrent': [path + '/AllowDynamicChargeCurrent', 1, 0, 1],
	# 'AllowDynamicDischargeCurrent': [path + '/AllowDynamicDischargeCurrent', 1, 0, 1],
	# 'AllowDynamicChargeVoltage': [path + '/AllowDynamicChargeVoltage', 0, 0, 1],
	# 'SocLowWarning': [path + '/SocLowWarning', 20, 0, 100],
	# 'SocLowAlarm': [path + '/SocLowAlarm', 10, 0, 100],
	# 'Capacity': [path + '/Capacity', '', 0, 500],
	# 'EnableInvertedCurrent': [path + '/EnableInvertedCurrent', 0, 0, 1],
	# 'CCMSocLimitCharge1': [path + '/CCMSocLimitCharge1', 98, 0, 100],
	# 'CCMSocLimitCharge2': [path + '/CCMSocLimitCharge2', 95, 0, 100],
	# 'CCMSocLimitCharge3': [path + '/CCMSocLimitCharge3', 91, 0, 100],
	# 'CCMSocLimitDischarge1': [path + '/CCMSocLimitDischarge1', 10, 0, 100],
	# 'CCMSocLimitDischarge2': [path + '/CCMSocLimitDischarge2', 20, 0, 100],
	# 'CCMSocLimitDischarge3': [path + '/CCMSocLimitDischarge3', 30, 0, 100],
	# 'CCMCurrentLimitCharge1': [path + '/CCMCurrentLimitCharge1', 5, 0, 100],
	# 'CCMCurrentLimitCharge2': [path + '/CCMCurrentLimitCharge2', '', 0, 100],
	# 'CCMCurrentLimitCharge3': [path + '/CCMCurrentLimitCharge3', '', 0, 100],
	# 'CCMCurrentLimitDischarge1': [path + '/CCMCurrentLimitDischarge1', 5, 0, 100],
	# 'CCMCurrentLimitDischarge2': [path + '/CCMCurrentLimitDischarge2', '', 0, 100],
	# 'CCMCurrentLimitDischarge3': [path + '/CCMCurrentLimitDischarge3', '', 0, 100],
	}
	self.settings = SettingsDevice(get_bus(), settings, self.handle_changed_setting)
	self.battery.role, self.instance = self.get_role_instance()

A possible solution would be to bind the DeviceInstance to the serial number of the BMS, so it also doesn't matter, if you change adapter.

[brunnema]

Hi Guys,
isn't there the Option to chose one criteria by the Listing like the USB port as well? So I had the same issue in an other project where I need to fix this for 3 identical USB Adapters with all the same Serial/ Vendor ID. Using the dedicatd USB port will allways pin a Symlink to the same USB port, disadvantage is that you shouldn't change the Adapter ports on the USB.
BR Martin

[LarsAndersenDenmark]

If using a raspberry, does it matter and improve chances of getting the same vrm instances if you instead of an external usb hub, use an extension usb modul for the raspberry?

For now I have had sufficient ports in my raspberry, but need now an extra for connecting the shunt.

[mr-manuel]

@brunnema could you post here how you did that?

[brunnema]

Hi,
here are brief intros - how to determine a USB device and set it to a dedicated tty connect:

• use these commands for e.g. to determine your USB stuff when connected
  #dmesg | grep usb
  #lsusb

• overview which devices are assigened: ls /dev

• use uadev for the wanted device to get fixed realtion with a symlink lateron
  e.g. #udevadm info -a -n /dev/ttyUSB0

• determine a unique attribute which you can use like Serial, Vendor ID or at least the pluged in USB port (in case there is no unique identify of the device itself)
  e.g. you can quick grap the attr if you know them like this
  #udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1
  #udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1
  or path:
  #udevadm info -a -n /dev/ttyUSB0 | grep '{devpath}' | head -n1

• to dertine this symlink - a seriall file needs to be added or created:
  sudo mcedit /etc/udev/rules.d/99-usb-serial.rules

content should be like this:
SUBSYSTEM=="tty", ATTRS{serial}=="SERIENNUMMER", SYMLINK+="YOURNAME", OWNER="YourUsedOwner"
e.g.
// FTDI-Daly BMS auf USB Steckplatz oben links
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", SYMLINK+="DALY-BMS", OWNER="pi"
save file and reboot

• then you can check if the symlink is available and reference to it instead of using ttyusb0
  ls -la /dev/serial/by-id/
  ls -l /dev/

Hope this help you creating unique and persisting USB relationship
Best Regards Martin

[Besenreiter]

Hello,
my question is because of lack of knowlege about the python code. When I have this unique symlink, where do I put it?? What file do I have to change in what way?
Thanks

[brunnema]

Hi all,
I have a similar questions to avoid thos USB struggeling issue.
Is it possible to run a RS485HAT on the RPI, like the Waveshare 2ch RS485 HAT?
This Board would provide the both RS485 channels as ttysc0 and ttysc1 instead of ttyusbxx
Where can I change the pointer from ttyusb01 to ttysc0 for example to get the BMS run onto a HAT Board.
BR Martin

[mr-manuel]

This works out of the box, since it checks all tty*.

dbus-serialbattery/etc/dbus-serialbattery/service/run

Lines 1 to 3 in 6471152

	#!/bin/sh
	exec 2>&1
	exec /opt/victronenergy/dbus-serialbattery/start-serialbattery.sh TTY

[brunnema]

Thanks Manuel, good news!
Then let me check how to get the board initatet and run. BR Martin

[DirkReudenbach]

@mr-manuel
can I use this for my issue with 2 serial batteries? How do I start this sript?

[mr-manuel]

1. Do you mean with "this" the RS485HAT?
2. You don't need to start the script. Only install the driver as you would normally do.

[mdkeil]

Hello,

how it works with VenusOS 3.x / RPI2 ..I tryed to make some udev-rules for creating new symlinks but "serial battery" further use /dev/ttyUSBX (created by serial starter udev rule?) which are using for setting the VRM Instance ID.. If I set the symlink directly to /dev/ttyUSB0, it will be ignored or overwritten (by serial starter udev rule?)

[Micha854]

@brunnema

Thanks for the tutorial but when I run dbus-spy the devices are still connected via ttyUSB*

don't you have to adjust something on venus here?

example on dbus-spy

com.victronenergy.battery.DALY-BMS

so we would have a really fixed assignment

[brunnema]

Hi Micha,
I still need to swap USB-RS485 towards the Waveshare RS485 HAT.
Sorry, there is a bit of mixture...the Tutorial is only requied in case you want to use multiple USB Sticks/ports to keep them stable linked to the attached Devices (case of reboot, etc).
A syslink is not requieed, cause dbus script scanns all tty* as posted by Manuel.
In Case I want to swap towards waveshare Hat RS485 it will become ttysc0 and ttysc1 available which are dedicated to each if the 2 channles and there is no port fix requierd as it is on USB ports.
BR Martin