Parallel BMS

[ornolio]

BMS Version 🔄

seplos v.2

Connection Method 🌐

USB-RS485

Problem Description 🤔

Currently many installations have battery packs in parallel each one with its own BMS; in my case 4 packs with 4 Seplos x v.2. BMS RS485 ports of all Seplos are linked by UTP cables in a daisy chain configuration and Seplos switches set accordingly with installation manual in order to address each pack and set the total number of packs in parallel. One end of RS485 cable goes to PC Window APP provided by Seplos through a RS485 to USB converter.
The RS485 connection also provides the Master Seplos BMS with the capability to drive the load distribution among each pack of the parallel.
The App provides either a view of all parameters of each single selected pack by clicking the pack number on the Window screen or a recap of all packs parameters in anoher screen.
Currently it appears the BMS Connector doesn't work in this configuration.
Could you please put an eye on the protocol and see if it would be possible to have this upgrade @bms Connector v. 2? Thank you in advance

Proposed Solution 🛠️

I suspect the Seplos protocol adds some preamble string to identify the total number of packs in parallel and the pack address of following data.

Alternatives Considered 🔄

No response

Additional context 📄

No response

[flip555]

I know pretty much exactly what I need to do to get multiple packs supported but I just get sidetracked too easily!

I'll try and get an update out in the next week or 2, the BMS Connector repo does need a big update to get it inline with a broader project I'm working on

If you are able to would you be able to get me an example of the Communications Log from Battery Monitor with parallel packs on? I only have a single pack so would just be testing against data found on other Github repos.

Thanks

[ornolio]

Thank you so much for your reply. Yes, I believe to be able to provide you tomorrow with a Log of multiple packs communication to the Windows App using its Log option. Best Regards. Pier

[ornolio]

DataRecord_20240201_034205.xls

here You are the data log.

This log file has ben formatted by the Seplos BMS Windows App on a stack of three 1p16s Lifepo4 14kWh packs with Seplos BMS v. 2.

Packs are in daisy chain with UTP-RJ45 cables connected to RS485 ports, one end (Pack1) linked to Windows using a RS485 to USB converter.

BMS 8bit Switches set are: Pack1 10000000, Pack2 0100000; Pack3 11000000

Let me know if you would like some USB Sniffer Log as well. In such a case do you have a windows app to ssuggest to get it ?

Best Regards

[flip555]

Thanks for that!

I have released a version for testing https://github.com/flip555/bms_connector/releases/tag/v1.1.0-TESTING-ONLY

You should be able to update to this by going to HACS > BMS Connector > Redownload > Enable Beta Versions and selecting v1.1.0-TESTING-ONLY

There is quite a bit missing from it, and needs some streamlining but would be great if you could test it before I add in the rest of the data as I'm only able to test my single battery pack. It does seem to work using test data

[ornolio]

Right now I'm far away from the battery stack to reconnect RS485 daisy chain and test new version. I'll do in a few days, next we. Regards. p.

[ornolio]

I'm 1 week late because I've been focused to solve the issue due using 4 USB, sorry.

I'll start tomorrow testing BMS-connector on parallel bms, using a separate Raspi platform.
Thanks.

For your information I've found on Github the attached manual, describing parallel bms com protocol starting at pages 22.
Seplos.bluetooth.protocol.2.pdf

[flip555]

I'm pretty sure parallel won't work with current code from what I've seen on issue #60 - Looks like the main BMS polls the parallel BMS's automatically which all gets dumped into the same serial output (commands and responses) so I need change that part of the code to listen, poll, sort and verify the data before processing/submitting to HA, something I've been playing with today.

That document is very nice, looks like it has complete data tables too some of which I was missing. Bluetooth was something I was looking at so I guess I finally have a starting point for that too.

I do remember 42H is actually 62H in other documents I think it was the pylontech BMS's they're all very similar.

[ornolio]

For sure the Master BMS does poll the slave BMSs and gets all master and slaves data on its own Master RS485 port; I did link it through a single RS485-USB adaptor to a Single USB port of a windows PC running the Seplos Battery Monitor V2.1.8, to view on this app dashboard data of master and slave BMS (see pictures in the case of 1 Master + 1 Slave).
So I put on standby my test, awaiting for your news.
Regards.

[flip555]

Hmm interesting. I've been looking and testing remotely on a paralleled system. It has 3 packs but even listening to the RS485 port just shows pack 1 & 2 - Don't seem to be able to send commands to it though as its all scrolling far too quick.

Your .xls communication log posted before also only shows packs 1, 2 and 3 but was a 4 pack battery.

Those screenshots show Pack 1 & 2 from a 2 pack so I'm even more confused now as its not missing Pack 0 😂

Looks like there was/is a problem with paralleled batteries but watching Andy @ Off Grid Garage it was working like your 2pack and was switching from Pack 0 to Pack 1, then he enabled dip 5 for CAN and it stopped.

Seems to be dip switches and firmware/hardware versions

Could you confirm DIP switch setup on your setup?

Andy seemed to have

1P: 00000000
2P: 10000000

and it worked in Battery Monitor he then changed it to enable CAN for his victron system to

1P: 00001000
2P: 10000000

and it stopped working in battery monitor, I'm just thinking a parallel pack starts with 0x01 when CAN is enabled

I'm thinking you have:

1P: 10001000
2P: 01000000

Or maybe you have automatic dip switch setting enabled?

[ornolio]

Seplos dip switches are very confusing. Depending if you use CAN or not dip switches change, requiring to set dip 5,6,7,8 of first pack to total no. of packs in parallel; in such a case dips 1,2,3,4 starts from 1 instead of 0.

I do not use CAN to communicate with inverter.
Previous Windows monitor screens refers 2 packs, with following dip switches setup:

'10000000'. pack1
'01000000' pack2

tomorrow afternoon I'll be at packs location, so I'll configure the whole 4 packs to get the 4 packs log of windows monitor and test the bms connector behaviour at the same dip switch configuration . as well.

[ornolio]

Attached I'm sending you the log of the Seplos Battery Monitor, using a single RS485-USB and 4 batteries in parallel. Dip configuration are:

'10000000' pack1
'01000000' pack2
'11000000' pack3
'00100000' pack4

No CAN used.
DataRecord_20240303_033049.xls

[ornolio]

Attached are also the screen shots of the Seplos bms monitor. Dip switches config is the same

[ornolio]

I reloaded BMS Connector test 1.1.7 (not found V1.2.0).
Not yet working. See attached screenshots.

[flip555]

Thanks, I think it'll be best to rework it a bit so it adds whichever modbus parts it receives to HA and skips (not errors and exits) when missing a full set of data (42H, 44H, 47H, 51H), then it can poll later if missing/has old data.

In the "BMS Modbus Responses" sensor you should have Attributes tab, this should have the latest modbus responses, for each battery pack so I guess I'm nearly where I need to be.

[ornolio]

Comment rewritten to clarify.

tested with two packs in parallel
set dip switch at:
'10000000' for pack1
'01000000' for pack2
put RS485 cable fron Pack1 to Raspberry 4 usb0

Adding hub:
-set number of pack 2
-set name prefix to 'Pack1'
I get 164 entities. relative to second pack values.

Adding hub:

• set number of pack 1
• set prefix to 'Pack2'
  I get 165 entities (one more) relative to second pack values; same of before.

Entity names result to contain 0x00 in both cases.

[ornolio]

update to v. 1.1.9 test only
having 3 battery packs with seplos version 2
RS485 linked in daisy chain
dip seitches to:
10000000
01000000
11000000
00100000
RS485 if first pack to USB adapter to Raspi4 usb port 0
git the following:

[ornolio]

last 3 pictures on reverse order.