[BUG] Double DeviceInstance ID on dbus for CAN BMS

[LykkeGit]

Describe the bug I'm operating a Cerbo GX with two BMS's (SIMP BMS) plus a smartshunt.

After FW upgrade from 2.XX to 3.18 only one battery BMS is visible in Node Red (..and MQTT it apperas), but both battery BMSs are visible in the local Consol. Both were visible in all former FW version (2 series) since installed two years ago.

When debugging a Node Red BMS voltage node, it outputs voltage from both SIMP BMS installations mixed.

To Reproduce Steps to reproduce the behavior:

1. Using node '...'
2. Click on '....'
3. See error

Expected behavior It was expected that both BMSs are visible in Node Red and MQTT. A clear and concise description of what you expected to happen.

Screenshots

Flow If applicable, add a flow to help explain your problem.

Hardware (please complete the following information):

• Hardware: [e.g. Cerbo GX, Ekrano, Raspberry Pi] Cerbo GX and 2x SIMP BMS

Software (please complete the following information):

• node-red-contrib-victron version: 3.02
• Venus OS version: 3.18 and 3.20

Additional context FYI: After update from Venus 2.xx to 3.18, all Victron Node Red nodes had to be reselected. Even so, some nodes seems to not work properly. Will build from scratch again

[dirkjanfaber]

I haven't worked with SIM BMS'es before, so it is slightly harder to reproduce. Am I correct that the BMS'es are CAN connected? If you look at the device details via the Remote Console, do they both have the ID 512? I think that might be the causing only one of them to show up. I would have expected them to each have their own unique ID, but I will have to check with a colleague to be sure.

My screenshot is of another CAN based BMS, but you get the idea.

[LykkeGit]

Yes, both unfortunatly have VRM instance "512"...

[mpvader]

Izak will be able to tell you more @dirkjanfaber , but I expect that in many ways - this hardcoded 512 instance being one of them - Venus OS is designed around expecting only one canbus bms to be connected.

Also DVCC works only for one canbus bms.

in case multiple strings of batteries, + BMSes, are used for parallel redundancy of the battery pack, we’ve always told the battery/BMS maker to solve that on their side; and then provide one total set of data to Venus OS.

as opposed to having multiple BMSes, and then requiring Venus OS to combine the data into one set of instructions towards the inverter/chargers and rest of power electronics.

[mpvader]

Ps. Changing all that won’t be on the roadmap soon

[LykkeGit]

Ps. Changing all that won’t be on the roadmap soon

Sorry to learn that, I did use the Node Red implementation to add an extra layer of security to the battery not handled by DVCC. I don't think they will update the BMS FW, so I may just have to try and roll back to Venus 2.90 and wait for a suitable Venus update.

[dirkjanfaber]

Well, there might be an alternative for you to consider. You might be able to get the needed info via modbus too by using the node-red-contrib-victron-modbus node.

Btw it could very well be that that solution suffers from the same problem.

[LykkeGit]

I tried out the modbus node, and while it works very well, it seems only possible to get data from the one battery BMS. I can also see in remote console, that it is no longer possible to selece both SIMP BMS instances for DVCC. I guess I will have to roll back to 2.90 to be able to use data from both BMS's.

[mpvader]

One warning, since the word safety is used: safety really up to the BMS/Battery. It needs to have a contactor that disconnects the system when necessary.

Venus OS, DVCC, and Node-RED should be no part of that. Some control which improves things is ok; but making the real basic safety features (which for lithium batteries should include a contactor) depend on complex systems like Venus OS is not a good idea.