I have commercial battery packs with PACE BMS, and I have DIY batteries with JK BMS. I connect all of them on a common busbar. I would like the best solution to get info on each pack, and to provide required info to Sunsynk 5kW inverter.  What would you suggest.

I have thought of:

1) Connecting all to SolarAssistant but apparently it can only communicate using one protocol at this time. It may be on a future development roadmap to be able to select multiple different BMS's, and combine them all into SolarAssistant.

2) I thought of installing a Victron Smart Shunt and connect to SolarAssistant. I would lose sight of individual packs but at least I can get single voltage, SOC, Amps from it, and it can report that to Sunsynk. I would need to setup sunsynk as AGM based on Voltage for charge settings.

Any other options, or comments about the above two would be appreciated.

 

 

 

SA doesn't present the info to the inverter anyway so your use of AGM or LIB would depend on the BMS - but as you say they're mixed so irrelevant

So this is mostly a visibility exercise in Solar Assistant,are your banks the same capacity and voltage?

Use a Victron Smart shunt. Setup the batteries conservatively in terms of voltage. Make sure you have a good think about the cable lengths into the Busbar & monitor the batteries individually. 

If any battery is offline etc the Shunt won't reach full SoC as long as the ah capacity is setup correctly. SA does support Victron. 

If you want direct Comms you can also use one of the batteries to provide such to the Inverter. The SoCs of each battery should be vaguely the same regardless of their capacity etc. The Comms with the inverter has no clue of the other batteries & the Charge limit & discharge limits will never be reached as there are more batteries in the pack that will be able to absorb the stress together. So basically this is a messy but best way in my opinion. 

I have almost the exact same challenge at a site next week. I need to integrate 4 different batteries of the same brand but different capacities. The BMSs are compatible but not when different capacities are involved. I will post this in the Showcase section next week. 

I had the opportunity to use a smart shunt but not required in my case. 

The Golden rule is that never loose sight that these are still just batteries, don't get bogged down by Comms & Concentrate on the science as if you were working with Lead acids ( Wire lengths same into the bus) 

@BritishRacingGreen

On 2023/07/29 at 10:10 AM, PsyWulf said:

SA doesn't present the info to the inverter anyway so your use of AGM or LIB would depend on the BMS - but as you say they're mixed so irrelevant

So this is mostly a visibility exercise in Solar Assistant,are your banks the same capacity and voltage?

I must have been naive... I truly thought that SA would be able to present the battery SOC, Voltage etc to Sunsynk as if It was the BMS. SOC is important because the inverter uses it in the timer, and presumably to stop charging.  Back to the drawing board.

 

Is it possible to get Smart shunt SOC into sunsynk inverter? 

23 hours ago, Steve87 said:

If you want direct Comms you can also use one of the batteries to provide such to the Inverter. The SoCs of each battery should be vaguely the same regardless of their capacity etc. The Comms with the inverter has no clue of the other batteries & the Charge limit & discharge limits will never be reached as there are more batteries in the pack that will be able to absorb the stress together. So basically this is a messy but best way in my opinion. 

I have almost the exact same challenge at a site next week. I need to integrate 4 different batteries of the same brand but different capacities. The BMSs are compatible but not when different capacities are involved. I will post this in the Showcase section next week. 

I had the opportunity to use a smart shunt but not required in my case. 

The Golden rule is that never loose sight that these are still just batteries, don't get bogged down by Comms & Concentrate on the science as if you were working with Lead acids ( Wire lengths same into the bus) 

I was hoping that it would be possible to get a more accurate SOC and bank voltage to the inverter via the smartshunt, or from the smartshunt via solar assistant to the inverter. Is either possible?

 

If not I can see why you are suggesting to just use one of your packs to communicate to the inverter (just the 'master'). Just to report voltage and SOC. The other batteries don't even have to be comms connected as slaves, just the master would do. So based on that SOC the inverter can make it's decisions re. the timer.

Edited July 30, 20233 yr by gimme_power

2 minutes ago, gimme_power said:

was hoping that it would be possible to get a more accurate SOC and bank voltage to the inverter via the smartshunt, or from the smartshunt via solar assistant to the inverter. Is either possible?

I think that @BritishRacingGreencan assist you with this. I have paralleled a multitude of batteries of different capacities. They will current share according to their capacity. The SoC of each pack will match vaguely & within 5% of each other. Very crucial to get the wire lengths all 100% the same length into the Busbar is the trick. 

The last part of your post tells me you see the logic. Who cares if the Discharge limit is 100A & you have a 8kW or even a 12kW Sunsynk. The Discharge limit will not be reached. I know that a lot of people are caught up in the romance of Inverter & battery comms. If you look very deep into the subject you will find that the Comms are very primitive in nature & provide protection for the battery. You are quite correct the System mode timer makes the SoC crucial for it's use. 

Different banks or capacities will have +-5% equal SoCs it's just the Current value that varies. I have a FreedomWon 10/8 in parallel with a LFP 6kWh DIY pack with direct comms to a Kodak OG7.2. in this same arrangement I have had added another 5kWh Livoltek pack. 

The smart shunt will be a good addition & that can be plugged into the Solar Assistant using a VE-Direct to USB into the Pi. The Comms of the battery of your choice can be plugged in the inverter. The SA can be setup to use the VE comms so that you can view & monitor the SoC of the entire pack & get good stats. The Sunsynk can remain on Lithium Battery Comms & these two portals can run side by side all that is required which is annoying is the manipulation of the Battery connection on the settings page. 

The VE stats will always be available even if Battery Comms direct to the Sunsynk is your default choice. Remember the Shunt will be your watch dog as to overall bank health. 

Many ppl will benefit from such an arrangement because batteries & their manufacturers come & go & honestly nothing prevents you from mixing and matching. It's a battery first before it's a smart communicating device. 

Some fundamentals that I think you will already know is that only parallel batteries of the same SoC & series value. So if paralleling get all the individual batteries to the same SoC & voltage. When you connect them allow them an opportunity to settle down so after paralleling them let them equalize in voltage and amps for a period of 5-10mins before just making use of them with the inverter. Have separate means of isolation via a battery breaker etc. So smaller sized breakers leading to the larger breaker or fuse. This way even if a BMS is protecting an individual battery the others won't be damaged by the larger power demand if it was left alone to deliver let's say 250A. Your switch gear is the protection, not just the BMS. Don't rely on a BMS for overcurrent protection. 

4 hours ago, gimme_power said:

I must have been naive... I truly thought that SA would be able to present the battery SOC, Voltage etc to Sunsynk as if It was the BMS. SOC is important because the inverter uses it in the timer, and presumably to stop charging.  Back to the drawing board.

 

Is it possible to get Smart shunt SOC into sunsynk inverter? 

Comms isn't the be-all and end-all,and few devices(if any) exist that can re-emulate BMS SOC from disparate sources or change source/destination protocols (Like cloudlink can do for hubble)

That said solar assistant can manage the SoC over time limits similarly to time-of-use settings without the charge source switching. Or run it in voltage mode that just estimates the SoC pretty decently anyway

@gimme_power , @PsyWulf , apologies for slow response .  I do have a RS485 to can bus gateway to  entertain JBD BMS RS485 to SunSynk . However , adding an additional RS485 for a second BMS , even a third , is possible.  Given that the Pace and JK bms has protocol  information to work by , it is possible to  concentrate the metrics in order to create a single virtual BMS communicating to the Sunsysnk . However , the Sunsunk will see a single but accurate aggregate of the SOC's , it will not display individual SOC's .

I have made the hardware and software open-source , although I have not constituted a licence yet , but it is free to build for all intent & purpose  . However , I will not be able to build these units myself , so if you are interested in doing that yourself , I can help with the software. Currently there is one member that is building one in Durban , so we busy ironing out  bill of material , schematics etc.

The source code will also be made available , should a member be able to support it himself/herself .

3 minutes ago, BritishRacingGreen said:

@gimme_power , @PsyWulf , apologies for slow response .  I do have a RS485 to can bus gateway to  entertain JBD BMS RS485 to SunSynk . However , adding an additional RS485 for a second BMS , even a third , is possible.  Given that the Pace and JK bms has protocol  information to work by , it is possible to  concentrate the metrics in order to create a single virtual BMS communicating to the Sunsysnk . However , the Sunsunk will see a single but accurate aggregate of the SOC's , it will not display individual SOC's .

I have made the hardware and software open-source , although I have not constituted a licence yet , but it is free to build for all intent & purpose  . However , I will not be able to build these units myself , so if you are interested in doing that yourself , I can help with the software. Currently there is one member that is building one in Durban , so we busy ironing out  bill of material , schematics etc.

The source code will also be made available , should a member be able to support it himself/herself .

Attached is a schematic copy  of the current design :

 

BRG_BMS_gateway_1xB.pdf

 

I think it doesn't get simpler than this , apart from the isolated dc-dc power supply , which in any case is a low cost MornSun module. I have never worked out a bill total , but will be surprised if this goes beyond R300-00 , excluding enclosure .

22 minutes ago, BritishRacingGreen said:

@gimme_power , @PsyWulf , apologies for slow response .  I do have a RS485 to can bus gateway to  entertain JBD BMS RS485 to SunSynk . However , adding an additional RS485 for a second BMS , even a third , is possible.  Given that the Pace and JK bms has protocol  information to work by , it is possible to  concentrate the metrics in order to create a single virtual BMS communicating to the Sunsysnk . However , the Sunsunk will see a single but accurate aggregate of the SOC's , it will not display individual SOC's .

Yeah I suspected it would be possible if not likely - thanks for confirming. Just not much in commercial units as it's a niche thing. Great job though,that might be worth a buildup and Article on something like Hackaday.

1 hour ago, BritishRacingGreen said:

@gimme_power , @PsyWulf , apologies for slow response .  I do have a RS485 to can bus gateway to  entertain JBD BMS RS485 to SunSynk . However , adding an additional RS485 for a second BMS , even a third , is possible.  Given that the Pace and JK bms has protocol  information to work by , it is possible to  concentrate the metrics in order to create a single virtual BMS communicating to the Sunsysnk . However , the Sunsunk will see a single but accurate aggregate of the SOC's , it will not display individual SOC's .

I have made the hardware and software open-source , although I have not constituted a licence yet , but it is free to build for all intent & purpose  . However , I will not be able to build these units myself , so if you are interested in doing that yourself , I can help with the software. Currently there is one member that is building one in Durban , so we busy ironing out  bill of material , schematics etc.

The source code will also be made available , should a member be able to support it himself/herself .

Well that is exactly what would be required. I am also not the person that can build something like that. Someone in these threads could make a few bob by building them so let's see. Maybe even the guys from solar assistant.  Anyway, good show.

Had a comment from SolarAssistant that they have a feature on the medium term development roadmap that could see the Victron Smart Shunt present as a BMS in Sunsynk.... Now that would be a fantastic feature. No official commitment but at least there is hope

On 2023/07/30 at 7:41 AM, BritishRacingGreen said:

Attached is a schematic copy  of the current design :

 

BRG_BMS_gateway_1xB.pdf 100.05 kB · 16 downloads

 

I think it doesn't get simpler than this , apart from the isolated dc-dc power supply , which in any case is a low cost MornSun module. I have never worked out a bill total , but will be surprised if this goes beyond R300-00 , excluding enclosure .

Any updates on your project for the JK BMS? I am wondering if this would enable me to connect both of my JK bms to my LV6548 Cluster. Right now I have a single smartshunt for SA SoC, but I am not using the JKBMS comms at all. 

 

Thanks in advance

On 2023/07/30 at 1:12 PM, Steve87 said:

I think that @BritishRacingGreencan assist you with this. I have paralleled a multitude of batteries of different capacities. They will current share according to their capacity. The SoC of each pack will match vaguely & within 5% of each other. Very crucial to get the wire lengths all 100% the same length into the Busbar is the trick. 

The last part of your post tells me you see the logic. Who cares if the Discharge limit is 100A & you have a 8kW or even a 12kW Sunsynk. The Discharge limit will not be reached. I know that a lot of people are caught up in the romance of Inverter & battery comms. If you look very deep into the subject you will find that the Comms are very primitive in nature & provide protection for the battery. You are quite correct the System mode timer makes the SoC crucial for it's use. 

Different banks or capacities will have +-5% equal SoCs it's just the Current value that varies. I have a FreedomWon 10/8 in parallel with a LFP 6kWh DIY pack with direct comms to a Kodak OG7.2. in this same arrangement I have had added another 5kWh Livoltek pack. 

The smart shunt will be a good addition & that can be plugged into the Solar Assistant using a VE-Direct to USB into the Pi. The Comms of the battery of your choice can be plugged in the inverter. The SA can be setup to use the VE comms so that you can view & monitor the SoC of the entire pack & get good stats. The Sunsynk can remain on Lithium Battery Comms & these two portals can run side by side all that is required which is annoying is the manipulation of the Battery connection on the settings page. 

The VE stats will always be available even if Battery Comms direct to the Sunsynk is your default choice. Remember the Shunt will be your watch dog as to overall bank health. 

Many ppl will benefit from such an arrangement because batteries & their manufacturers come & go & honestly nothing prevents you from mixing and matching. It's a battery first before it's a smart communicating device. 

Some fundamentals that I think you will already know is that only parallel batteries of the same SoC & series value. So if paralleling get all the individual batteries to the same SoC & voltage. When you connect them allow them an opportunity to settle down so after paralleling them let them equalize in voltage and amps for a period of 5-10mins before just making use of them with the inverter. Have separate means of isolation via a battery breaker etc. So smaller sized breakers leading to the larger breaker or fuse. This way even if a BMS is protecting an individual battery the others won't be damaged by the larger power demand if it was left alone to deliver let's say 250A. Your switch gear is the protection, not just the BMS. Don't rely on a BMS for overcurrent protection. 

@Steve87 - I agree with you.  Only question I have is, "what data" is being communicated to the SunSynk as an example.  If the SS only "needs" and therefore reads: "Voltage", which it will get from the voltage across the common busbar, and "SOC" (from one of the batteries, in my case, also a FW 10/8) - then, it should be all good to go.  the SOC (and voltage) will just fall slower.....

Do you know if there is any other data that could cause an issue?  Eg.  my battery pack is 20kwh (400ah) - but FW 10/8 will report 200ah.  And, what about "current" - I dont think so, but, just wonder if additional data sent could cause an issue?

Edited January 9, 20251 yr by MikeP

Hi Mike, 

This is purely through observation of my own solar lab setup & from paralleling FreedomWons of different capacities: 

The only thing the BMS is sending the inverters is % SoC, CCL, DCL & alarms. Besides that the Sunsynk & for that matter any other inverter doesn't make heads or tails of anything else. Ok in the ATESS it also shares the Max & Min cell voltage & temps. 

But you can setup anything on Comms in the chain & then DC couple more on the same DC bus & as long as you can verify the batteries are working well & on & moving together there won't be any problems at all. 

I have paired 2 x 10/8s with 2 x 15/12s to this day they all working well with their respective master & slaves & keep the same SoC values. This is paired with 2 x Deye 12kW machines...Been in operation for close to 15 months without issue. 

Edited January 9, 20251 yr by Steve87

4 hours ago, MikeP said:

@Steve87 - I agree with you.  Only question I have is, "what data" is being communicated to the SunSynk as an example.  If the SS only "needs" and therefore reads: "Voltage", which it will get from the voltage across the common busbar, and "SOC" (from one of the batteries, in my case, also a FW 10/8) - then, it should be all good to go.  the SOC (and voltage) will just fall slower.....

Do you know if there is any other data that could cause an issue?  Eg.  my battery pack is 20kwh (400ah) - but FW 10/8 will report 200ah.  And, what about "current" - I dont think so, but, just wonder if additional data sent could cause an issue?

While there are no standardized designs among lithium battery systems, my experience suggests that Pylontech has significantly influenced many OEMs in their philosophy of BMS (Battery Management System) communications. Moreover, the Pylontech protocol is directly compatible with those of several other manufacturers.

A detailed protocol exists for use by the so-called "upper computer" (e.g., your laptop) to configure and monitor detailed metrics of a specific battery pack in your array. This protocol typically uses RS485 communication rather than CANbus. The primary reason is that laptops are more RS485-friendly due to the readily available connection dongles, while CANbus requires specialized adapters. Historically, neither batteries nor inverters supported CANbus. As a result, the same management protocol was also utilized by inverters to extract relevant metrics. However, this approach is highly inefficient because the inverter needs to implement the entire "bloated" management protocol, only to extract a subset of relevant data.

This is where CANbus comes in. Pylontech introduced CANbus support, among other features, to provide a "clean" interface for inverters. The CANbus protocol only supports the essential metrics required by the inverter. For example, the inverter does not need details about the number of parallel packs or the energy capacity of each one. Instead, it treats the system as a single virtual pack.

The BMS-to-inverter protocol typically includes the following:

1. Absolute Maximum Charge Voltage: The maximum voltage that the inverter must not exceed during charging.

2. Absolute Maximum Charge Current: The maximum charge current that the inverter must adhere to.

3. Optional Absolute Maximum Discharge Current: The maximum discharge current the inverter may obey. Some inverters struggle to limit battery discharge during large load surges, relying on a brief forgiveness period before the BMS activates protection. Whether or not the inverter complies with this limit is less critical, as the BMS will intervene if necessary.

4. State of Charge (SOC): The overall SOC of the virtual pack as a single averaged value. The pack master is responsible for calculating this value based on the SOC and capacity of its slaves. While SOC is not essential for primary charging functions, it serves as a convenience metric for higher-level features, such as timer-based scheduling.

5. Optional Additional Metrics: When deemed appropriate, the BMS may send additional metrics via CANbus, such as maximum/minimum cell voltages or temperatures. Typically, inverters will read and silently drop or ignore these metrics without forwarding them to parent-level functions.