JBD/Overkill BMS CAN bus comms support for inverters

[uksa007]

If I'm not having a blonde moment, it would appear that you are promoting a commercial offering, albeit thinly disguised as a plea for money for development. It appears that you are aiming to get over $3000 to buy new batteries and BMS, via your patreon link?

As far as I can see, none of the code you are promoting on here is available free of charge. Yet, what you are aiming to do is largely covered by existing free github projects.

I'm not an Admin on here, but to me it would appear that this approach doesn't fit with the objectives of the forum. As @Will Prowse states in his guidelines... "Vendors can still post here on the forum, but they cannot promote themselves in any way" and "Keep in mind that we volunteer our time here, because we love electronics and DIY solar projects. The exchange of information on this site is fantastic, and it will always be free for everyone."

Thanks for your comments, I have discussed with the Mods and Will, and they have kindly allowed it.

I'm not commercial, just one guy trying to make something others might find helpful.
It will be released on github like my JK-BMS version is, currently the JBD version is not fully functional and still in Alpha testing.
Many have requested multi BMS support, which requires an addition set of batteries to develop and support, hence the funding goal.

 

[SeaGal]

Thanks for your comments, I have discussed with the Mods and Will, and they have kindly allowed it.

I'm not commercial, just one guy trying to make something others might find helpful.
It will be released on github like my JK-BMS version is, currently the JBD version is not fully functional and still in Alpha testing.
Many have requested multi BMS support, which requires an addition set of batteries to develop and support, hence the funding goal.

Great, cool. I don't see any issue if it is going on github. Thanks for the update. Have done a JBD to CAN integration for my Solis, based on the github projects from @sijones2010 and the one overkill promote, but guess you have already looked at them.

 

[sijones2010]

Thanks for your comments, I have discussed with the Mods and Will, and they have kindly allowed it.

I'm not commercial, just one guy trying to make something others might find helpful.
It will be released on github like my JK-BMS version is, currently the JBD version is not fully functional and still in Alpha testing.
Many have requested multi BMS support, which requires an addition set of batteries to develop and support, hence the funding goal.

You wouldn't need $3000 for it.

Buy the BMS and attach it to your current batteries and then develop against that, I don't see the need for anything else?

 

[uksa007]

Buy the BMS and attach it to your current batteries and then develop against that, I don't see the need for anything else?

That is a disappointing response, without having thought through the complexities involved IMHO.

It would not be accurate for the very reasons why you want have multi BMS communication, the differences between BMS/battery packs!
For example you can't do most of this with one battery pack and a second BMS:

Current in/out of the different packs needs to be added
Voltage differences between packs, if one has been offline, map to inverter.
If cells in one pack are over voltage alarms need to be mapped correctly.
If cells in one pack are under voltage alarms need to be mapped correctly.
If temp in one pack is high alarms need to be mapped correctly.
If temp in one pack is low alarms need to be mapped correctly.
How different SOC and SOH are mapped to the inverter
How Request flag to Enable/Disable: Charge, Discharge, Force charge are mapped to the inverter.

It not as easy as everyone thinks.
In my experience it is best to do things properly or not at all, especially when you are dealing with BMS comms which is essentially a safety system!

 

[SeaGal]

You wouldn't need $3000 for it.

Buy the BMS and attach it to your current batteries and then develop against that, I don't see the need for anything else?

That is a disappointing response, without having thought through the complexities involved IMHO.

If anyone on this forum thinks through the complexities of such a development it would be @sijones2010 - just look at the code he has developed for the benefit of all on here, without begging for donations.

It would not be accurate for the very reasons why you want have multi BMS communication, the differences between BMS/battery packs!
For example you can't do most of this with one battery pack and a second BMS:

Current in/out of the different packs needs to be added
Voltage differences between packs, if one has been offline, map to inverter.
If cells in one pack are over voltage alarms need to be mapped correctly.
If cells in one pack are under voltage alarms need to be mapped correctly.
If temp in one pack is high alarms need to be mapped correctly.
If temp in one pack is low alarms need to be mapped correctly.
How different SOC and SOH are mapped to the inverter
How Request flag to Enable/Disable: Charge, Discharge, Force charge are mapped to the inverter.

It not as easy as everyone thinks.
In my experience it is best to do things properly or not at all, especially when you are dealing with BMS comms which is essentially a safety system!

I disagree. All of the above are achievable and, arguably, better achieved through simulation of input data. When I came to develop my JBD/Overkill to Solis CANBus integration (starting with @sijones2010's code), I created a test harness using the identical API to the Overkill Arduino library. With such a test harness one can then 'simulate' all the conditions that you choose to, safely.

I doubt you will be wanting to actually force real life cells into over voltage and under voltage, over temp and under temp conditions. Hence, as Simon said "I don't see the need for anything else".

 

[uksa007]

If anyone on this forum thinks through the complexities of such a development it would be @sijones2010 - just look at the code he has developed for the benefit of all on here, without begging for donations.


I disagree. All of the above are achievable and, arguably, better achieved through simulation of input data. When I came to develop my JBD/Overkill to Solis CANBus integration (starting with @sijones2010's code), I created a test harness using the identical API to the Overkill Arduino library. With such a test harness one can then 'simulate' all the conditions that you choose to, safely.

I doubt you will be wanting to actually force real life cells into over voltage and under voltage, over temp and under temp conditions. Hence, as Simon said "I don't see the need for anything else".

When you are developing multi BMS support you will find out why it’s important to do it properly and not simulate things.

As far as I can see you haven’t even shared your code and supported others through the process. It is a lot of continuous work.
I have donated 1000’s of hours of my time, is it not enough to satisfy you?

 

[sijones2010]

That is a disappointing response, without having thought through the complexities involved IMHO.

It would not be accurate for the very reasons why you want have multi BMS communication, the differences between BMS/battery packs!
For example you can't do most of this with one battery pack and a second BMS:

Current in/out of the different packs needs to be added
Voltage differences between packs, if one has been offline, map to inverter.
If cells in one pack are over voltage alarms need to be mapped correctly.
If cells in one pack are under voltage alarms need to be mapped correctly.
If temp in one pack is high alarms need to be mapped correctly.
If temp in one pack is low alarms need to be mapped correctly.
How different SOC and SOH are mapped to the inverter
How Request flag to Enable/Disable: Charge, Discharge, Force charge are mapped to the inverter.

It not as easy as everyone thinks.
In my experience it is best to do things properly or not at all, especially when you are dealing with BMS comms which is essentially a safety system!

I take it the disappointment is because I didn't give you the answer you wanted to hear?

Multiple BMS's and Battery packs isn't actually that difficult to do, just don't mix battery types use only one in all the battery packs, I have multiple BMS's and Battery packs for almost a year without issue so I think I know the complexities.

You've given a list of things to consider but really not a problem. You being based on ESPHome makes it easier in some ways as you can simply let ESPHome report which item is the problem rather than trying to tell the inverter, it really doesn't need to know multiple battery packs are connected nor does it care.

• Current in/out of the different packs needs to be added
  • Simple addition of BMS 1 and BMS 2 plus BMS 3 - No issue.
• Voltage differences between packs, if one has been offline, map to inverter.
  • Shouldn't happen, packs should be the same state of charge when connected, only millivolt differences due to cabling, so add all voltages together and divide by total count of BMS to give average - have sensors allowed to report individual voltages on packs.
• If cells in one pack are over voltage alarms need to be mapped correctly.
  • map to CAN overvoltage alarm if you want, but would be better to disable charging and allow balancer time to sort it out, sending alarms over CAN Bus can lead to inverter shut down which means you lose Solar generation as well. Inverter usually have a configuration for overvoltage protection.
• If cells in one pack are under voltage alarms need to be mapped correctly.
  • same as above, better to stop discharge. Inverter alarm should be then lower than this so it doesn't alarm.
• If temp in one pack is high alarms need to be mapped correctly.
  • Stop discharge/charge whilst over limit
• If temp in one pack is low alarms need to be mapped correctly.
  • as above
• How different SOC and SOH are mapped to the inverter
  • You get SOC drift with different BMS's, this would just have to be an average of the connected ones, no perfect method for this. SOH is a false thing, you'll never know the true health, health depends on not just cycles but how the batteries have been treated, charged to 3.65v, kept at a high voltage for a long period, run under 2.5v will kill the amount of cycles you can get. So implementing this would give a false sense of health.
• How Request flag to Enable/Disable: Charge, Discharge, Force charge are mapped to the inverter.
  • Battery packs are tied, so they should be in a similar state, I've not seen BMS's send any flag above over the BMS data - other than PylonTech so I wouldn't be concerned, you can implement functions in ESPHome to give a force charge switch, PylonTech recommends that you don't force charge past 97%, you can also implement the charge/discharge allow over CAN bus in switches and then turn on and off based on alarms from the BMS's.

In my experience it's never good to allow a BMS to disconnect while charging or discharging with a load, it tends to cause a sudden voltage change which will trigger an Inverter alarm and shutdown.

lastly:

• In my experience it is best to do things properly or not at all, especially when you are dealing with BMS comms which is essentially a safety system!
  • BMS is absolutely the safety system for the batteries not software, do not rely on Home Assistant / ESPHome, the BMS should have the settings to keep the batteries within the absolute capability and is the last defence.

Am not criticising you asking for money, I just gave honest feedback on that you wouldn't need it as there are ways to do it without such an investment.

The problem with asking for money is, have you done any proof of concept to know it's feasible? (esp32's have a limit to processing, storage and RAM) What happens if you can't make it work? (How would you feel if you donated and got nothing out of it?) You have to genuinely see it from others point of view, in this case if you can't make it work, you've still got a nice set of batteries out of it.

Sorry if that offends but I have to be honest and that's really genuinely what people will think about.

 

[uksa007]

The problem with asking for money is, have you done any proof of concept to know it's feasible? (esp32's have a limit to processing, storage and RAM) What happens if you can't make it work? (How would you feel if you donated and got nothing out of it?) You have to genuinely see it from others point of view, in this case if you can't make it work, you've still got a nice set of batteries out of it.

You realise I have a fully functional solution for the JK-BMS(single) right?

I have proof of concept Multi BMS code (not optimised in any way), resources are not an issue:
RAM: [= ] 12.9% (used 42236 bytes from 327680 bytes)
Flash: [===== ] 53.9% (used 989101 bytes from 1835008 bytes)

There are lots of moving parts involved in a Multi BMS solution and then you have to support it.
You can only simulate so much, for me I'm not prepared to release and try to support something that I haven't even used in the real world and been able to fully test myself.
I think it's only reasonable and most people will understand that.

In any case this is getting off topic, this thread is about JBD/Overkill BMS CAN comms support for inverters.

 

[jandb]

Hi all,
I tried to connect a my 200A JBD smart-BMS via their own CAN bus adapter to my Victron Cerbo yesterday, and it froze my Victron system completely....
Had to re-initialize the Cerbo with the manufacturers initial Software...

I asked JBD to give me some details on how to work/wire and connect with their CAN bus adapter and it seems to me I did everything as they suggested. So no clue what went wrong.

I asked/received their installation manual and user manual (Can protocol)
I'm not very strong in this (rather not-at-all) but for those who understand the protocol info, see attached.
I'm just a copy-and-do-the-same-thing-guy so some more info on an very basic level would be very much appreciated !
(level of soldering wires together and uploading files is OK )

 

[uksa007]

Hi all,
I tried to connect a my 200A JBD smart-BMS via their own CAN bus adapter to my Victron Cerbo yesterday, and it froze my Victron system completely....
Had to re-initialize the Cerbo with the manufacturers initial Software...

I asked JBD to give me some details on how to work/wire and connect with their CAN bus adapter and it seems to me I did everything as they suggested. So no clue what went wrong.

I asked/received their installation manual and user manual (Can protocol)
I'm not very strong in this (rather not-at-all) but for those who understand the protocol info, see attached.
I'm just a copy-and-do-the-same-thing-guy so some more info on an very basic level would be very much appreciated !
(level of soldering wires together and uploading files is OK )

Their CAN protocol is nothing like Pylon, if it's like JK-BMS they just seem to make their own protocol.

Victron Cerbo supports pylon protocol over the BMS CAN port.
You probably need one of my Hardware Interfaces and firmware, it will communicate with the BMS and use the Pylon CAN protocol that the Cerbo will understand.
I have a kit for Overkill/JBD just haven't got around to documenting it.
Very Similar as the JK-BMS linked above but with JBD connector.

 

[jandb]

For the time being, I work with serial connection via the driver of Louis Van Der Wall on Github. Many thanks to all of them !
After some troubles, I finally managed to upload the driver to my Cerbo GX, and it seems to work that way.

 

[uksa007]

For the time being, I work with serial connection via the driver of Louis Van Der Wall on Github. Many thanks to all of them !
After some troubles, I finally managed to upload the driver to my Cerbo GX, and it seems to work that way.

Cool, let me know if you need anything more advance, my solution has:
It's own charging logic, configurable via it's web server or Home Assistant
Wifi standalone AP or connect to existing WiFi network.
Builtin web server for local management of all BMS data
Ability to turn of and charging/discharging requests to CAN devices
Home assistant integration for detailed monitoring of the BMS and battery
Much more, see the first post.

 

[uksa007]

JBD/Overkill code soon moving to Beta and What you have all been waiting for!

Update:
Multi BMS Alpha code updated.
Update: Alpha V2.16 more info here

I completed and implement the initial design, the data is now combined from the slaves as per the design.
I have made many improvements and made the code more robust, see the above link for more info.

Future plans include adding Multi BMS support for JBD/Overkill so you can mix and match BMS in the one larger pack.

 

[uksa007]

My Hardware interface now supports the JBD/Overkill BMS.

Let me know when ordering you require the JBD/Overkill version.

This has all the hardware/software needed to communicate with BMS and Inverter over CAN bus.
Hand built on a PCB and soldered to the ESP32, bulletproof design for production use.
Don't use modules and Dupont connectors for long term production use, they are for proof of concept and prototyping only, and are prone to fail.

It is a plug and play device, just add power (5v USB)

Update: now available with two RJ45 with Termination disabled for Multi BMS use.

 

[uksa007]

My Hardware interface now supports the JBD/Overkill BMS.
Update: Multi BMS support also available(up to 10 BMS), kit available same link as above.

 

[frickinfrack]

Hi,

Updade: Support now available for JBD/Overkill BMS CAN bus comms for inverters similar to my JK-BMS CAN bus project.
This would also facilitate integration with Home Assistant and control of the battery/inverter remotely see my JK-BMS CAN comms for example:

My Hardware interface now supports the JBD/Overkill BMS.
Let me know when ordering you require the JBD/Overkill version.
Update: Multi BMS support up to 10 BMS also available, kit available.

This has all the hardware/software needed to communicate with BMS and Inverter over CAN bus.
Hand built on a PCB and soldered to the ESP32, bulletproof design for production use.
Don't use modules and Dupont connectors for long term production use, they are for proof of concept and prototyping only, and are prone to fail.

It is a plug and play device, just add power (5v USB)
Now available with two RJ45 with Termination disabled for Multi BMS use.

This will allow your JBD/Overkill BMS to communicate with any inverters that support Goodwe and Pylontech Low voltage batteries via CAN bus (Protocol compatible with Pylontech V1.3 and Goodwe V1.5), this should be most 48V inverters, hybrids etc.

Thought this may help some others who would like inverter comms with their JBD/Overkill BMS.
This enables the following:

Sends over CAN bus to inverter:

• Battery Voltage
• Battery Current (+charge, -discharge)
• State of Charge (SOC)
• State of health (SOH)
• BMS Temperature
• Charging Voltage
• Charging Amps
• Discharge min Voltage
• Battery name
• Alarms: Cell over/under voltage, Charge/discharge over current, High/low Temp, BMS fault
• Charging logic: Complete rework of the charging logic, now charges with constant current(CC) to the absorption voltage, then has an absorption timer (Constant Voltage, user configurable time), with rebulk feature (user configurable offset from absorption voltage).

Note:- Support for only one BMS CAN connection per inverter, see here more info on creating larger capacity packs
Early stages are under way to support multiple BMS, but need funding to purchase additional hardware, please consider supporting my work if you would like to see this functionally, early access code with be made available in the Alpha testers membership once funding goals are reached:


Home Assistant native integration via ESPHome:

• Battery control switches to manage battery remotely
  • Charging request status
  • Absorption voltage (slider)
  • Charging current max (slider)
  • Charging enabled/disabled
  • Discharging enabled/disabled
  • Charging manually (top balancing)
• All BMS sensor values

I'm using it in my production environment which consists of:

• Goodwe GW5000S-BP 5kW inverter
• Goodwe GM3000 3 phase Smart meter cabled back to inverter (you can also use the GM1000 if you have single phase)
• 16 * EVE LF280K batteries in series for nominal 51.2v
• JK-BMS 150A model JK-B2A24S15P
• JK RS485 module (you don't need this if your ESP32 is near the JK-BMS)
• ESP32 model esp32doit-devkit-v1
• TJA1050 CAN bus to TTL module 4.7K resistor for 5V to 3.3v level shift.
• RS485 to TTL module (you don't need this if your ESP32 is near the JK-BMS)
• Various safety devices: Fuse and ZJ Beny125A DC circuit breaker etc.

Additional info will be published to "Be in the know" and above like:

What development is coming soon
Development that has been completed and is in Alpha/Beta testing
Get early access to Alpha/Beta code for testing (in those tiers)
Polls to determine future features etc.
Help fund goals to purchase additional hardware like multiple BMS support

Thanks.

 

[frickinfrack]

Hi, this is exactly what I'm looking for. I just have a couple questions before I drop $$ on this. I just got an EG4 6000XP built by Luxpower and have a 16S JBD BMS. Will this work to allow for communication between the 2? Can this run at the same time as the BT dongle or does it use the same port on the BMS? I also have a 4S JBD BMS in the mix and having that talk to HA or SA would be pretty great as well but is not a deal breaker.

 

[uksa007]

Hi, this is exactly what I'm looking for. I just have a couple questions before I drop $$ on this. I just got an EG4 6000XP built by Luxpower and have a 16S JBD BMS. Will this work to allow for communication between the 2? Can this run at the same time as the BT dongle or does it use the same port on the BMS? I also have a 4S JBD BMS in the mix and having that talk to HA or SA would be pretty great as well but is not a deal breaker.

The EG4 6000XP seems to support Pylon CAN protocol, so I don't see why it wouldn't work.

It uses the UART port that the dongle uses.
Consider the JK-BMS if you want both Bluetooth app and my board connected.

I have replied to your private conversation also.

Regards.

 

[frickinfrack]

The EG4 6000XP seems to support Pylon CAN protocol, so I don't see why it wouldn't work.

It uses the UART port that the dongle uses.
Consider the JK-BMS if you want both Bluetooth app and my board connected.

I have replied to your private conversation also.

Regards.

Thanks!

 

[Savarycabin]

Hi,

Updade: Support now available for JBD/Overkill BMS CAN bus comms for inverters similar to my JK-BMS CAN bus project.
This would also facilitate integration with Home Assistant and control of the battery/inverter remotely see my JK-BMS CAN comms for example:

My Hardware interface now supports the JBD/Overkill BMS.
Let me know when ordering you require the JBD/Overkill version.
Update: Multi BMS support up to 10 BMS also available, kit available.

This has all the hardware/software needed to communicate with BMS and Inverter over CAN bus.
Hand built on a PCB and soldered to the ESP32, bulletproof design for production use.
Don't use modules and Dupont connectors for long term production use, they are for proof of concept and prototyping only, and are prone to fail.

It is a plug and play device, just add power (5v USB)
Now available with two RJ45 with Termination disabled for Multi BMS use.

This will allow your JBD/Overkill BMS to communicate with any inverters that support Goodwe and Pylontech Low voltage batteries via CAN bus (Protocol compatible with Pylontech V1.3 and Goodwe V1.5), this should be most 48V inverters, hybrids etc.

Thought this may help some others who would like inverter comms with their JBD/Overkill BMS.
This enables the following:

Sends over CAN bus to inverter:

• Battery Voltage
• Battery Current (+charge, -discharge)
• State of Charge (SOC)
• State of health (SOH)
• BMS Temperature
• Charging Voltage
• Charging Amps
• Discharge min Voltage
• Battery name
• Alarms: Cell over/under voltage, Charge/discharge over current, High/low Temp, BMS fault
• Charging logic: Complete rework of the charging logic, now charges with constant current(CC) to the absorption voltage, then has an absorption timer (Constant Voltage, user configurable time), with rebulk feature (user configurable offset from absorption voltage).

Note:- Support for only one BMS CAN connection per inverter, see here more info on creating larger capacity packs
Early stages are under way to support multiple BMS, but need funding to purchase additional hardware, please consider supporting my work if you would like to see this functionally, early access code with be made available in the Alpha testers membership once funding goals are reached:


Home Assistant native integration via ESPHome:

• Battery control switches to manage battery remotely
  • Charging request status
  • Absorption voltage (slider)
  • Charging current max (slider)
  • Charging enabled/disabled
  • Discharging enabled/disabled
  • Charging manually (top balancing)
• All BMS sensor values

I'm using it in my production environment which consists of:

• Goodwe GW5000S-BP 5kW inverter
• Goodwe GM3000 3 phase Smart meter cabled back to inverter (you can also use the GM1000 if you have single phase)
• 16 * EVE LF280K batteries in series for nominal 51.2v
• JK-BMS 150A model JK-B2A24S15P
• JK RS485 module (you don't need this if your ESP32 is near the JK-BMS)
• ESP32 model esp32doit-devkit-v1
• TJA1050 CAN bus to TTL module 4.7K resistor for 5V to 3.3v level shift.
• RS485 to TTL module (you don't need this if your ESP32 is near the JK-BMS)
• Various safety devices: Fuse and ZJ Beny125A DC circuit breaker etc.

Additional info will be published to "Be in the know" and above like:

What development is coming soon
Development that has been completed and is in Alpha/Beta testing
Get early access to Alpha/Beta code for testing (in those tiers)
Polls to determine future features etc.
Help fund goals to purchase additional hardware like multiple BMS support

Thanks.

Exciting to see. Will the SOC reading override my shunt as both are connected to my cerbo. I find my shunt often doesn’t match my BMS and want the BMS to be the true reading on my cerbo and used for auto start gen trigger. Thanks