Connecting BMS Batrium via CAN bus to SolarAsssistant

Hello,

I have been operating Batrium for about 8 years. From my point of view, Batrium BMS is a robust and reliable system and I am very satisfied with it.
But I have had a problem with connecting BMS Batrium via CAN bus to SolarAsssistant - on raspberry pi4 for a long time. Both Batrium BMS and SolarAsssistant have a CAN bus interface with battery profiles from Pylontech and I believe that they have them functional for real pylontech batteries. There is no doubt about that. But if I want to connect them and use the original cabling with the SolarAsssistant adapter and other adapters and converters, it does not work. When comparing the transmitted data with ID 0x351,5,6,9,0x35E, I compared their content and the ID at the output of the converters/adapters with the Pylontech standard. The data with their ID generated by BMS Battery corresponds to the Pylontech standard. And the data values ​​corresponded to the real BMS parameters. At the same time, I tried to communicate with the BMS Batrium through the transmitted ID queries in the form 0x4200 8 02 00 00 00 00 00 00 00, where the BMS should respond and send a response in the form 0x7320 8 2D 00 03 0F 90 00 32 00. The BMS ID received it, but did not respond. I saw the communication process on WatchMon Toolkit 2.17.57 on the Pylontech profile.
And now I have a question, whether the Batrium BMS has a specified ID with values, which I insert into the can bus transmitter and the Batrium BMS will respond to me with an ID with a value, e.g. battery status. I now see in the data stream from Batria ID 0x35E 42 61 74 72 69 75 6D 00 (ASCII for “Batrium”), but I need to see that the Batria BMS receives data from SolarAsssistant.
I am also sending a screenshot of my settings “Batrium BMS settings and communication” with the data streams. And I can send “ExtractSetupSnapshot_SYS7389_20250630_193903” via email. Other ideas on how to get it working are welcome.

Use converters and measuring devices:
USB To CAN /RS232 TO CAN Serial Port Converter Adapter 232 CAN Bus Transfer Send (V8.00)
ECAN-101 CAN To Serial Protocol RS485 CANBUS Converter,CDEBYTE
ECAN-U01S CAN To USB Protocol Converter CDSENET
E810-RS-U01 USB To RS485,RS232 TTL Industrial Converter CDSENET
CAN bus USB cable from SolarAsssistant

Use applications for battery control and connection pylontech
SolarAsssistant software version 2025-06-25 beta on
Raspberry Pi 4 Model B Rev 1.5 (rpi64)
BatteryView - 33
XCOM V2.6
MultiSIBControl
ECANTools(4)_0526-23
USB-CAN(V8.00)
WatchMon Toolkit 2.17.57
ICM- profile Pylontech RS485

Fault code, CAN lost

Best regards Lubo

my English is not good

It may be worth checking to see if SA will read it if you set the protocol mode to Victron GX Gateway. I know the Cerbo will read the Batrium if it’s set to Cerbo, Pylontech LV or Project Lychee. Depending on which of those I set the name may change but I get the same parameters in SA. I couldn’t get anything to read on CanBus until I got the Seeed Studio USB to CAN Analyzer Adapter, CAN Bus Converter with USB Cable.

Thank you for your answer and I tested these settings with the following result: Batrium BMS with Victron GX Gateway profile connected once, SolarAssistant recognized the battery name BatriumV, but did not update the battery data. With Pylontech LV profile it connected twice and did not recognize the battery name, but read more battery data, but did not update it. I could not connect with Project Lychee. I made all connections with an adapter similar to yours in the V8 version, but purchased from https://www.aliexpress.com/. It works, but it reports a bizarre value bcdDevice = 81.34 and maybe SolarnAssistant does not understand this and therefore blocks it. I got to this value with “USB devices: Kernel log”.
At the beginning of the testing I wanted to order the original USB to CAN Analyzer Adapter, but Seeed Studio did not want to send it to me from the German warehouse. I had to order it from the China warehouse.

Lubo

Verify you’re reading 120ohms at each end of your CanBus. This behavior is indicative of lack of bus termination.