diy solar

diy solar

JK-BMS-CAN with new Cut-Off Charging Logic (open-source)

Thanks for the response, I can add your two systems to the list.

Can you confirm for me that with Solis you use the 'AoBo' battery type with the 'SMA' protocol?

With Sofar, do you need to select a special battery mode in your inverter? Are you using the 'PYLON 1.2' or 'PYLON +' protocol?

Solis is connected to an Atom S3 Lite supervising via BLE two Li-ion battery packs (2x JK-PB*), is this correct?

Sofar is connected to an Atom S3 (display) supervising via BLE two Li-ion battery packs (2x JK-B), is this correct?

On which inverter did you have to add the 120 Ohm resistor?
Can you confirm for me that with Solis you use the 'AoBo' battery type with the 'SMA' protocol
- Yes Confirmed
With Sofar, do you need to select a special battery mode in your inverter? Are you using the 'PYLON 1.2' or 'PYLON +' protocol?

- It's currently on Pylon, but I remember it worked on General and Default settings.
It seems , as long as the Inverter detects the JKBMS then you solution detects the Batt.

Solis is connected to an Atom S3 Lite supervising via BLE two Li-ion battery packs (2x JK-PB*), is this correct? -
-Correct
2x JK-B2A24S15P (Power BMS)

Sofar is connected to an Atom S3 (display) supervising via BLE two Li-ion battery packs (2x JK-B), is this correct?
-Correct
2x JK-PB2A16S15P (Inverter BMS)

On which inverter did you have to add the 120 Ohm resistor?
- On the Sofar Inverter

Thanks again @Sleeper85 , @MrPablo, and others....
 
@Sleeper85
  • Inverter brand: Growatt
  • Inverter model: SPF 5000 ES
  • Inverter Battery mode: SBU
  • BMS model: 2x JK PB2A16S20P
  • BMS link: BLE
  • ESP32 board: M5Stack AtomS3
  • CAN name: Pylon 1.2
  • CAN protocol: Pylon / Pylon 1.2
  • CAN board: M5Stack CAN Unit ca-is3050g
  • Multi-BMS: yes
  • Remarks: Best solution for the incomplete/wrong protocols implementation on JK Inverter BMSes and some inverters.
  • Wishes:
    1. I wish that all the entities from JK PB RS485 version will be implemented to BLE version to make it more JK PB friendly ;)
    2. I wish that multi bms logic will be updated - so if you turn off charging on one of the BMSes than it should subtract requested charge current from smart bms
    3. I wish some way to expand the BLE system to more than 3 devices - maybe some ESP32 interconnections?
      Let's say we have 6 JK PB BMSes - so 2 ESP32 will be used, one of the ESP32 will be CAN connected to inverter and 2 ESP32 should talk to each other.
My only Wish

- some intelligence added to link Average voltage to State of Charge Indication, the Average voltage never lies but the SoC does, they tend to show inaccurate percentage and line up by themself sometimes...
Or maybe one click calibration button added - so one can write Automation in HA to periodically trigger that button to recaliberate.


if I want to know how much juice I have left on my battery I always look at the average voltage reading first, rarely believe what the SoC tells me.

I tried calibrating it was fine for some days...then back to divorcing each other gain but not massively
 
If this works with Atom lite/Can adapter, id rather give that a shot as it’s cleaner to build compared to esp32 with mcp2515. I’ll just take my system offline for a few hours, split my pack from 2p16s to two 1p16s and add in another non-inverter JK.

To be honest I don't own an Atom Lite, I guess with just 2 BMS connected via UART this should work. Do not enable the web server as it consumes a lot of memory and could cause problems, reboot.

The problem with the Atom solution is that there are few GPIOs available.

It is possible to use two UARTs but it will be necessary to solder two wires (there are holes next to the pins to do this) on the Atomic CAN base to connect to GPIOs 23 and 33 in addition to 26 and 32.

1718802062602.png
 
My only Wish

- some intelligence added to link Average voltage to State of Charge Indication, the Average voltage never lies but the SoC does, they tend to show inaccurate percentage and line up by themself sometimes...
Or maybe one click calibration button added - so one can write Automation in HA to periodically trigger that button to recaliberate.


if I want to know how much juice I have left on my battery I always look at the average voltage reading first, rarely believe what the SoC tells me.

I tried calibrating it was fine for some days...then back to divorcing each other gain but not massively

Regarding this point I think that adding a measuring shunt would be better. The shunt could provide voltage, amps, power as well as the SoC ( @kommando ).

This is next on my list, Victron and Junctek shunt support.
 
I wish that all the entities from JK PB RS485 version will be implemented to BLE version to make it more JK PB friendly ;)

The RS485 component for JK-PB* developed by @txubelaxu is quite recent, I suppose it will be improved in the future.
In any case, this is a question to ask @txubelaxu on GitHub.

I wish some way to expand the BLE system to more than 3 devices - maybe some ESP32 interconnections?
Let's say we have 6 JK PB BMSes - so 2 ESP32 will be used, one of the ESP32 will be CAN connected to inverter and 2 ESP32 should talk to each other.

This multi-bms version is a first step, I did it like this for the PVbrain2 PCB supporting up to 15 UARTs with an ESP32-S3.

@MrPablo @Der_Hannes @shvm The other people who discussed the multi-BMS version with me would like to propose a master-slave solution like the Peter Board with one ESP32 per BMS. The ESP32s would be connected together on an internal CAN bus. The current multi-BMS version is already ready for this future master-slave solution.

That said, I think a dedicated PCB with an ESP32-S3, 7 UARTs and several CAN bus outputs could be another solution.
 
This is normally already the case if you receive BMS information from BLE. See the answer I posted yesterday.

But it is not updating life. Only during ESP start or restart these values are updated. When you turn off charging in HA the requested charge current not update.
 
Last edited:
But it is not updating life. Only during ESP start or restart these values are updated. When you turn off charging in HA the requested charge current not update.

I can confirm that it works for me with the JK-B* series BMS.

When you deactivate the Charging switch in HA is it really turned OFF in the BMS?

Perhaps this is a problem with the JK-PB* series and BLE, in which case you would have to open a bug in the syssi GitHub.
 
I can confirm that it works for me with the JK-B* series BMS.

When you deactivate the Charging switch in HA is it really turned OFF in the BMS?

Perhaps this is a problem with the JK-PB* series and BLE, in which case you would have to open a bug in the syssi GitHub.
Yes, I hear the "bip" on BMS and I see it on BMS LCD :) Another thing is that when I turn off charging on both my batteries than ESP is loosing connetion to CANbus, HA and shows 2% SOC - that's weird as discharging is on. Like you said, maybe it's only BLE PB series problems.
 
Last edited:
Yes, I hear the "bip" on BMS and I see it on BMS LCD :) Another thing is that when I turn off charging on both my batteries than ESP is loosing connetion to CANbus, HA and shows 2% SOC - that's weird as discharging is on. Like you said, maybe it's only BLE PB series problems.

If the charging switch is OFF in the BMS, it is strange that the charging current reduction does not occur for you.

Concerning the fact that the canbus links stop and that the soc is at 2%, that comes from my code. I will improve this. I think that the charging switch should no longer be part of the conditions for the combination of BMS but only reduce the charging current.
 
Concerning the fact that the canbus links stop and that the soc is at 2%, that comes from my code. I will improve this. I think that the charging switch should no longer be part of the conditions for the combination of BMS but only reduce the charging current.
That will be great.
 

diy solar

diy solar
Back
Top