Seplos Inter Battery Communications (RS485)

[illysky]

Hi, I have a two battery systems Hope 3.3KWh (Growatt) and a DIY with Seplos 200A 16S with my Sunsynk 8.8KW Inverter

I have my DIY/Seplos and Hope batteries in parallel, but only DIY/Seplos is communicating with Inverter, so the inverter doesn't see Hope (yes I know not ideal). As you may know, Hope battery is a bit of a pain, as you have to keep feeding it a CAN frame to keep it alive, which I have RPi doing that, and sending metrics back to my dashboard.

I would like my inverter to know about the Hope battery, and act accordingly if anything goes wrong with it, The plan is to take the CAN frames from Hope (it can only do CAN!), as well as send the keep-alive frame, reformat the data into Seplos slave frames and transmit them when requested to the Master Seplos BMS in my DIY Battery over RS485, the data will hopefully be aggregated with the master's data and sent to Inverter over that CAN, - yes I know wtf right? Its the cleanest method I can think of... so TL,DR a Hope CAN to Seplos RS485 converter.

I have a RP2040 using Pio CANBUS library receive the frames from Hope (and send the keep alive) this works good. I am currently working on the RS485 side of things but there isn't much documentation on the Inter-battery communication protocol. I've analysed the packets, and its is very similar to the BMS to Inverter RS485 protocol. With the DIPs set to 1 slave pack, the Master BMS sends out:

"~2001465A0000FD9D"

20 - Version
01 - Address
46 - CID1 Battery Type
5A - CID2 Not Documented!!
0000 - No Size
FD9D - Checksum

So in order to understand what the master is expecting, I used my PC to send the same command to the master (with address as 0 and checksum adjusted):

"~2000465A0000FD9E"

And surprisingly it responded (even though its a master) with:

"~2000465AC04000010D670D230BC60BC10394155758B559D803DB156200110000000003018082F03C"

I've figured most of it out through observations, but stuck on two parts I am not sure of.

# ~ <SOI>
# 20 <Version>
# 00 <Address>
# 46 <CID1> Battery
# 5A <CID2> This should be a response code, but they echo 0x5A
# C040 <Length>
# 00 <Data Flag>
# 01 <Command Group>
# 0D67 <CellV Highest> 0.01V
# 0D23 <CellV Lowest> 0.01V
# 0BC6 <Temp Highest> -0.1 Kelvin
# 0BC1 <Temp Lowest> -0.1 Kelvin
# 0394 <Current> 0.01A
# 1557 <Pack Voltage> 0.01V
# 58B5 <Residual Cap> 0.01Ah
# 59D8 <Full Cap> 0.01Ah
# 03DB <SoC> 0.1%
# 1562 <Port Voltage> 0.01V
# 001100000000 <------- Alarm codes? (probably because I had OV pack and cell warning at this point)
# 03018082 <------ Status Codes?
# F03C <Checksum>
# \n <EOF>

I would be grateful If anyone has information on the Slave to Master Comms, or can help me figure these last bits out. 0x5A is not a CID2 I can find anywhere, and the return CID is echoed not a proper response code. I will keep going and post pack if I figure it out for anyone interested.

I've be happy to share the code and parts list on here when I am done to can make your own if you need.

Hardware all on Amazon
RP2040 PICO,
CAN Transceiver
RS485 to UART CONVERTER
2x RJ45 Breakouts.

Thanks

Dominic

 

[SeaGal]

The plan is to take the CAN frames from Hope (it can only do CAN!), as well as send the keep-alive frame, reformat the data into Seplos slave frames and transmit them when requested to the Master Seplos BMS in my DIY Battery over RS485, the data will hopefully be aggregated with the master's data and sent to Inverter over that CAN

Having built a CAN bus interface for my DIY battery pack to Solis inverter, I would have approached your issue differently in order to avoid having to decode the proprietary Seplos RS485 interfaces and hoping it will aggregate the data for you. Maybe I have overlooked something, but I would have taken the CANBus output from each of the battery packs, done the aggregation in my own code on an RPi/ESP32 and then sent the aggregated CAN frames to the inverter.

Anyway, with regard to your questions, are we assuming that the Seplos RS485 is modbus RTU?

If so, then, I'd say the packet that the Master is sending is:-

20 - Version Slave Address
01 - Address Read Coils Function
46 - CID1 Battery Type
5A - CID2 Not Documented!!
465A - Register Address
0000 - No Size (which is strange - would have expected 1)
FD9D - Checksum

If that is correct, then in the response, the 465A is the register address and C040 is the data.

CO40 doesn't sound likely as the length as that would represent nearly 50,000 bytes = 25,000 registers?