Anybody tried new JK BMS with inverter communication support?

[....]

And the results are in... Sadly there is no change in the charging performance with paired with an EG4/Luxpower 6000XP.
Here is the screen capture from Solar Assistant showing the charge behavior this morning.
I didn't bother including the battery SOC graph, it was at 99% this morning and hit 100% at ~8am when the charging cut out.

At 5:45am the sun rose and the PV array began generating power
At 6:15am there was enough solar power to overcome the standby power consumption and charging began.
Charge current begins to increase, and with it battery voltage
At 8:30am the battery SoC hit 100% and the EG4/Luxpower charge logic shut down the charger.
NOTE: The battery voltage is only at 53.7V, a far cry from my target RCV voltage of 55.2! The sun is shining and my batteries are not full, but no charging is happening.
The characteristic chirping behavior of the EG$/Luxpower is clearly visible for the next hour during this period. The charger does kick on for a few minutes but not nearly enough to actually charge the battery
At 9:45am I re-connected my ghost battery and charging resumes as expected. Due to drift in the coulomb counting the battery needs another hour or so of charging to get up to RCV. I will make a followup post after I confirm that the charge controller is still working correctly (battery gets to RCV, then holds for 1 hour, and then drops to RFV) with the ghost battery connected on the new firmware.

For more information about the ghost battery, see the previous posts: it is a JKBMS based battery at 0% SOC which is connected ONLY via RS485 parallel coms (the DC connections are not connected) to trick the JKBMS master into reporting 99% SOC instead of 100 while the charge controller is active.

Overall it is a bummer that this issue is still present. Really I think that JK is in the right here and it is EG4/Luxpower who need to respect the pylontech charge request flag, but support from EG4 has been worse than the support from JK which is really saying something.

 

[ChrisG]

And the results are in... Sadly there is no change in the charging performance with paired with an EG4/Luxpower 6000XP.
Here is the screen capture from Solar Assistant showing the charge behavior this morning.
I didn't bother including the battery SOC graph, it was at 99% this morning and hit 100% at ~8am when the charging cut out.
View attachment 225680
At 5:45am the sun rose and the PV array began generating power
At 6:15am there was enough solar power to overcome the standby power consumption and charging began.
Charge current begins to increase, and with it battery voltage
At 8:30am the battery SoC hit 100% and the EG4/Luxpower charge logic shut down the charger.
NOTE: The battery voltage is only at 53.7V, a far cry from my target RCV voltage of 55.2! The sun is shining and my batteries are not full, but no charging is happening.
The characteristic chirping behavior of the EG$/Luxpower is clearly visible for the next hour during this period. The charger does kick on for a few minutes but not nearly enough to actually charge the battery
At 9:45am I re-connected my ghost battery and charging resumes as expected. Due to drift in the coulomb counting the battery needs another hour or so of charging to get up to RCV. I will make a followup post after I confirm that the charge controller is still working correctly (battery gets to RCV, then holds for 1 hour, and then drops to RFV) with the ghost battery connected on the new firmware.

For more information about the ghost battery, see the previous posts: it is a JKBMS based battery at 0% SOC which is connected ONLY via RS485 parallel coms (the DC connections are not connected) to trick the JKBMS master into reporting 99% SOC instead of 100 while the charge controller is active.

Overall it is a bummer that this issue is still present. Really I think that JK is in the right here and it is EG4/Luxpower who need to respect the pylontech charge request flag, but support from EG4 has been worse than the support from JK which is really saying something.

Does anyone know if the same Lux behavior exists with Seplosv3?

Also wonder what the behavior is with Lux/EG4 and the EG4 batteries

 

[AshleyL]

Don't want to get anyone's hopes up but I upgraded the firmware yesterday. I am using the JK SMA Canbus called FSS which works like Pylontech Plus Canbus to an extra decimal point which could be the reason for my observation.

Currently both batteries are showing as 100% in the JK Win app and the voltage is 55.3V against my target of 55.2V and the SI has stopped charging and the voltage is decaying but the SI is showing the SOC as 99%.

Looking at my data logger the SI shows as being at 99% SOC for last 4 hrs and the voltage got to 55.2V 20 mins ago. I don't data log the JK App but that was probably showing 100% for 4 hrs too.

Which one? The 009 FSS-ConnectingBat??

Inverter is set to luxpower mode and the JKBMS it set to luxpower mode (CAN type 11) as before. All coms seem to work fine, inverter reports correct SOC, battery count, charge limit, etc.

At 8:30am the battery SoC hit 100% and the EG4/Luxpower charge logic shut down the charger.
NOTE: The battery voltage is only at 53.7V, a far cry from my target RCV voltage of 55.2! The sun is shining and my batteries are not full, but no charging is happening.
The characteristic chirping behavior of the EG$/Luxpower is clearly visible for the next hour during this period. The charger does kick on for a few minutes but not nearly enough to actually charge the battery
At 9:45am I re-connected my ghost battery and charging resumes as expected. Due to drift in the coulomb counting the battery needs another hour or so of charging to get up to RCV. I will make a followup post after I confirm that the charge controller is still working correctly (battery gets to RCV, then holds for 1 hour, and then drops to RFV) with the ghost battery connected on the new firmware.

Hmm.....Sad news for the rest of us indeed....

 

[kommando]

Which one? The 009 FSS-ConnectingBat??

Yes, a confusing way of saying SMA Canbus.

When you google fss-connectingbat-ti-en-20w

You get to https://files.sma.de/downloads/FSS-Foerderprogamm-TI-en-20.pdf

Confirming its the Canbus for the SMA SI 8.0H-11

https://us.v-cdn.net/6034073/uploads/1GVSH0OE6WLD/sma-can-protocol-282-29.pdf

Where the footer on every page is FSS-ConnectingBat-TI-en-10 | Version 1.0

 

[AshleyL]

Yes, a confusing way of saying SMA Canbus.

When you google fss-connectingbat-ti-en-20w

You get to https://files.sma.de/downloads/FSS-Foerderprogamm-TI-en-20.pdf

Confirming its the Canbus for the SMA SI 8.0H-11

https://us.v-cdn.net/6034073/uploads/1GVSH0OE6WLD/sma-can-protocol-282-29.pdf

Where the footer on every page is FSS-ConnectingBat-TI-en-10 | Version 1.0

According to your SMA CANbus manual :

State of Charge – SOC: Sunny Island does not calculate the SOC of the battery system but relies on the SOC-Value
sent by the external BMS. This value should be accurately calculated by the external BMS as a lot of system functions
are triggered by the SOC-Value. For example the battery protection mode (see [1], [2]) is triggered by SOC or algorithm
for self consumption increase uses SOC value for the control purposes. Please note that charging of the battery will not
stop according to SOC value (for example at 100%). Only discharging of the battery is stopped by defined SOC-values.
It is expected that the battery provider detailed describes in his manual the definition of the SOC and the accuracy of the
value

Now that explained it.
Well, we who use Axpert, Voltronic, Growatt, EG4/Luxpower AIO inverter ARE DEFINITELY SCREWED with no hope of making use of JK Inverter BMS lithium communication mode. Basically we just spend a premium on a piece of "feature" which we will not be able to utilize

 

[ChrisG]

Now that explained it.
Well, we who use Axpert, Voltronic, Growatt, EG4/Luxpower AIO inverter ARE DEFINITELY SCREWED with no hope of making use of JK Inverter BMS lithium communication mode. Basically we just spend a premium on a piece of "feature" which we will not be able to utilize

Well that sucks. I’m about to pull the trigger on some cases and now might consider SEPLOSv3 which I know has its own challenges.

 

[AshleyL]

Well that sucks. I’m about to pull the trigger on some cases and now might consider SEPLOSv3 which I know has its own challenges.

At least there is no negative drift with SeplosV3 algorithm since it will spend a long time at 99% as per Andy videos on it.........just get the one with 2A active balancer?

 

[kommando]

Now that explained it.
Well, we who use Axpert, Voltronic, Growatt, EG4/Luxpower AIO inverter ARE DEFINITELY SCREWED with no hope of making use of JK Inverter BMS lithium communication mode.

SMA are not cheap. maybe for a reason , mine were 10 years old when I got them so lower cost than a new Chinese inverter but still ultra reliable if lacking in features like needing a Raspberry Pi to get the data out to MQTT. I don't think you can blame JK on this one as Pylontech Canbus is based on SMA Canbus. Do all those inverters use the same basic firmware with slight changes to suit ?

 

[AshleyL]

SMA are not cheap. maybe for a reason , mine were 10 years old when I got them so lower cost than a new Chinese inverter but still ultra reliable if lacking in features like needing a Raspberry Pi to get the data out to MQTT. I don't think you can blame JK on this one as Pylontech Canbus is based on SMA Canbus. Do all those inverters use the same basic firmware with slight changes to suit ?

Growatt SPF models are a bit weird.........these models are rebranded version of Sacolar......which is a rebrand of Voltronic Axpert...double rebrand deja vu?
Personally, I blame both JK and inverter manufacturers. Both of them don't even bother to improve their products and taking account of feedbacks, unless if you are influencer like Andy.

Growatt doesn't do shit because they can't do anything or not willing to modify the algorithm from the Voltronic OEM.
JK doesn't wanna do shit because their products are selling well as no many users will know about the negative SOC % drift issue immediately.

Perhaps the main issue is........both are China based companies with chabuduo 差不多 mentality.
The article https://aeon.co/essays/what-chinese-corner-cutting-reveals-about-modernity mostly highlighted the issue I have with China Chinese 差不多 crap.

 

[ChrisG]

At least there is no negative drift with SeplosV3 algorithm since it will spend a long time at 99% as per Andy videos on it.........just get the one with 2A active balancer?

I wonder if the SEPLOS works as expected with RCV/etc with Lux/Other. Understand the challenge with 100%…ugh. Don’t know which way to go.

 

[kommando]

Copying without understanding and not being bother by the resulting issues is the problem, they think the money saved is compensation enough. There are exceptions, my Solax inverter is fault free and once support realised they had given me the wrong info on setting up frequency shifting to match the SI they did a quick apology and set me straight.

 

[AshleyL]

I wonder if the SEPLOS works as expected with RCV/etc with Lux/Other. Understand the challenge with 100%…ugh. Don’t know which way to go.

It will definitely stop charging the moment SOC 100% status is sent to Lux. Our senior's post above already proven it. The only "feature" of Seplos BMS with Lux inverter, there will be no negative drift and the battery will be fully charged as you use it (positive drift?) daily.

Copying without understanding and not being bother by the resulting issues is the problem, they think the money saved is compensation enough. There are exceptions, my Solax inverter is fault free and once support realised they had given me the wrong info on setting up frequency shifting to match the SI they did a quick apology and set me straight.

Hence, the dreaded chabuduo 差不多 mentality by China based company. Hell, you can even said it is part of the culture.

 

[ChrisG]

It will definitely stop charging the moment SOC 100% status is sent to Lux.

Wonder if the EG4 batteries/bms has the 100% issue. Anyway. Think I’m going call it and buy with SEPLOSv3.
I do think the Lux inverters and probably others are not playing nice with Pylontech. I have a few custom esp32 solutions and with both as soon as 6000xp hits 100% it stops charging.

 

[....]

Here is the update from yesterdays experiment showing the charging behavior of the JK float controller with the ghost battery connected (limits SOC to 99% so the EG4/Luxpower inverter does not shut off charging prematurely).



To recap from before:
At 5:45am the sun rose and the PV array began generating power
At 6:15am there was enough solar power to overcome the standby power consumption and charging began.
Charge current begins to increase, and with it battery voltage
At 8:30am the battery SoC hit 100% and the EG4/Luxpower charge logic shut down the charger.
NOTE: The battery voltage is only at 53.7V, a far cry from my target RCV voltage of 55.2! The sun is shining and my batteries are not full, but no charging is happening.
The characteristic chirping behavior of the EG4/Luxpower is clearly visible for the next hour during this period. The charger does kick on for a few minutes but not nearly enough to actually charge the battery
At 9:45am I re-connected my ghost battery and charging resumes as expected. Due to drift in the coulomb counting the battery needs another hour or so of charging to get up to RCV. I will make a followup post after I confirm that the charge controller is still working correctly (battery gets to RCV, then holds for 1 hour, and then drops to RFV) with the ghost battery connected on the new firmware.

New update:
At 11:00 the battery hits RCV of 55.2V (3.45V/cell), and the charge switches from constant current to constant voltage. Current tapers off to about 1A to maintain the battery at RCV.
At 12:00 the RCV timer (1 hour) expires, and the charge voltage target drops to RFV of 53.6V (3.35V/cell). Current drops to 0 because the battery voltage is above the target charge voltage.
At 13:30 the battery voltage reaches the target RFV. Float charging continues with about 1A floating into the battery to maintain it at RFV. I have RFV set to 6 hours so there is no re-bulk charge.
At 18:30 the panels were shaded and available solar power was insufficient to cover the base load of the system so charging stopped.

It is a bit surprising to me to see such a high standby current (1-2A) to float the battery at RFV of 53.6V (3.35V/cell). Next step would be to check with a current meter to see if it is actually 2A of current flowing as reported by the BMS, my suspicion is that the reading is inaccurate due to the limited resolution of the JKBMS shunt at low current. I did confirm that the pack was fully balanced before the RCV period of the charge was done (so it wasn't balancer operation causing a high standby current) and that the screens were configured for auto-turnoff. The battery current plot is based on the measurements reported by the inverter (for some reason I assumed that SA would plot the current as reported by the BMS, but it is actually the current as reported by the inverter). I confirmed that the JKBMS all report that the current drops to 0, and confirmed with a clampmeter that the actual current flowing into the battery is <100ma (noise floor of meter). Yet another issue to add to the ever growing list of complaints with the EG4/Luxpower inverter: the inverter reports (and front panel shows) 50-100W of power flowing into the battery when in fact there is <5w!

The good news is that the JK charge controller is working exactly as described, and the EG4/Luxpower does correctly interpret the setpoints and set the voltages appropriately. All we need is to sort out this turn-off-the-charge-controller-when-SOC-hits-100%-even-though-the-charge-enable-request-flag-is-set nonsense.

 

[AshleyL]

New update:
At 11:00 the battery hits RCV of 55.2V (3.45V/cell), and the charge switches from constant current to constant voltage. Current tapers off to about 1A to maintain the battery at RCV.
At 12:00 the RCV timer (1 hour) expires, and the charge voltage target drops to RFV of 53.6V (3.35V/cell). Current drops to 0 because the battery voltage is above the target charge voltage.
At 13:30 the battery voltage reaches the target RFV. Float charging continues with about 1A floating into the battery to maintain it at RFV. I have RFV set to 6 hours so there is no re-bulk charge.
At 18:30 the panels were shaded and available solar power was insufficient to cover the base load of the system so charging stopped.

It is a bit surprising to me to see such a high standby current (1-2A) to float the battery at RFV of 53.6V (3.35V/cell). Next step would be to check with a current meter to see if it is actually 2A of current flowing as reported by the BMS, my suspicion is that the reading is inaccurate due to the limited resolution of the JKBMS shunt at low current. I did confirm that the pack was fully balanced before the RCV period of the charge was done (so it wasn't balancer operation causing a high standby current) and that the screens were configured for auto-turnoff. The battery current plot is based on the measurements reported by the inverter (for some reason I assumed that SA would plot the current as reported by the BMS, but it is actually the current as reported by the inverter). I confirmed that the JKBMS all report that the current drops to 0, and confirmed with a clampmeter that the actual current flowing into the battery is <100ma (noise floor of meter). Yet another issue to add to the ever growing list of complaints with the EG4/Luxpower inverter: the inverter reports (and front panel shows) 50-100W of power flowing into the battery when in fact there is <5w!

The good news is that the JK charge controller is working exactly as described, and the EG4/Luxpower does correctly interpret the setpoints and set the voltages appropriately. All we need is to sort out this turn-off-the-charge-controller-when-SOC-hits-100%-even-though-the-charge-enable-request-flag-is-set nonsense.

Argh....at this stage, do guide us on how to prepare/setup a phantom ghost battery with extra jkbms. (in detail?)
I have one extra which supposed to be used as spare. Might as well as use it.

Oh, for your info, that 1-2a current is used for the inverter own internal power consumption.

 

[....]

Argh....at this stage, do guide us on how to prepare/setup a phantom ghost battery with extra jkbms. (in detail?)
I have one extra which supposed to be used as spare. Might as well as use it.

The setup is very simple:
1. Connect batteries as usual (set up addressing, daisy chain the RS485 ports, connect DC cables, etc) and confirm the battery array is working correctly and fully charged.
2. Select the target battery to convert for use as the ghost.
3. Set the capacity of the ghost battery to 2Ahr. This will also reset the SOC of the battery (the JKBMS will estiamte the SOC based on the voltage). The actual SOC does not matter as long as it is not 100%, but I let the system discharge for a few minutes to draw the reported SOC down to 0% (the reported SOC will drop very quickly because the capacity it set so low).
3. Disconnect the DC terminals from the ghost battery. Assuming the ghost battery is built with an isolator/breaker you can simply turn off the main breaker (as long as the BMS stays powered on). It might also work to just leave the 'charge' and 'discharge' toggles turned off in the app. But the key step: leave the RS485 com lines connected and leave the BMS turned on.

The ghost battery will still report its SOC to the JKBMS array, and because it can't charge (the DC line is disconnected) it will never report a 100% SOC so the array will never reach 100% SOC so the inverter will not shut off.

A few tips:
1. I configured my ghost batter to be the last one in the RS485 chain, so if it shuts down or needs to be removed it does not otherwise affect the array.
2. I left the screen completely unplugged to minimize parasitic draw on the battery. Configuring for auto-turnoff would probably also be fine.
3. It will still be necessary to charge the ghost battery occasionally (to make up for the standby power consumption of the BMS). Luckily, if the battery does get discharged to the point that it shuts down, the array will simply return to normal operation. I suppose that is a good reminder to go and recharge the battery (flip the main breaker back on and let the JKBMS parallel module recharge the ghost battery)

I did have an idea to try and use a BMS without a battery connected as the ghost, just powered by the red B+ wire connected to a DC power supply. I am not sure if the low voltage alarms would cause problems with the rest of the array, if they do I suppose one could set up some sort of resistor divider to trick the BMS into thinking there is a battery connected. But at that point it would probably make more sense to move to an ESP32 based solution to fake out the SOC.

Good luck

 

[ChrisG]

At 8:30am the battery SoC hit 100% and the EG4/Luxpower charge logic shut down the charger.

Question, without ghost battery are you seeing not only does charging stop to battery but your surplus of PV can’t be used to power loads and inverter starts drawing from battery?

 

[Steve_S]

SOMETHING DIFFERENT:
Currently, I have set of 3 packs in Parallel with the new JK-PB2A16S20P Hardware V:15
I noticed the other day that 1 pack disabled Charge (it was 100% and BMS stated this even in the "Error Log" Reporting) Other packs were still taking a "tiny bit" yet they were also 100% and cells were "there" voltage wise. I HAD to Investigate of course !

These are 24V/280AH with same BMS. Not currently interconnected (not until I finish the whole bank)
An error is generated because I use only 2 Temp Sensors. Firmware is too stupid to disable the other 2 if in 8S config. (BUG)

The Settings I have that relate to this.
Cell OVP 3.500
VOL Cell Rcv 3.450
SOC 100% 3.449
Cell OVPR 3.448

Simple enough, here's what is happening. I am sending 28.1V (3.512Vpc) to the bank.
BMS sets SOC 100% when the cells reach 3.449
Allows charge to continue until 1 Cell reaches 3.502 and stays there for 60 seconds +/- then turns off charge.
At this point the BMS "LOGS" verbally (into the error log) that the Battery is FULL.
The cells will of course settle a wee bit over time (about 20 mins) to where 1 cell will get below 3.447 and stay there for a bit again and then the charge is turned back on. At which point it tops off and stops again.

I sat & observed 3 packs all go through this cycling process repeatedly and it was all very consistent. Could almost time it to the second.

Unfortunately, the way JK set this up is a bit screwy !
The OVPR must be lower than the SOC 100% and that must be lower than the Cell RCV (part of inverter comms).
NB: All the cells remained below the 0.010V differential.

I tried furtling with the number combos and got the "Data not written" or whatever msg... Really, they ought to put "Value out of Range" or something.

TRICK LEARNED !
I furtled with this for a couple of hours trying to work out how to keep the "cycle" neat as such. Partly because it does take time for the settling and when multiple packs are cycling that that it's "weird" although NOT Harmful in any way. I have ACTIVE Balancing start @ 3.42 and had Balance Trigger Volt 0.010 so I figured try it at 0.005 and "COOL" this actually reduced the cycling and kept the voltages "tight".
Now after I did this I watched very carefully and noted that: The cycling continued for a few minutes BUT after about 15 minutes of that, the cells collectively stayed put and the cycling slowed to maybe once per hour and the cells actually all stayed around 0.003 apart.

With a bit of tweaking on the SCC, this is now working smoother than any previous setups I have done/ tested & beaten upon.

FYI: I do NOT use an AIO. My SCC's are Midnite Solar Classics (no interaction with other gear). I use a Samlex EVO Inverter/Charger (not compatible with JK yet, although I made the introductions between Samlex Engineering & JiKong, never worked out). Maybe because Samlex is Taiwanese ? Who knows.

Bottom Line:
It's important to "know" what the BMS is actually doing independently and how it is logging/reacting to the settings when triggered. For example the BMS setting the SOC state to 100% when it reaches the set SOC-100% Setting Value but NOT triggering the Log Entry that states it is FULL. That "Log Entry" is also the signal sent to an AIO and the only way that gets triggered is when A CELL creeps over the OVP threshold. IMO this is Flawed Logic as cells should never have to reach OVP (whatever it is set to) in order to trigger the "Battery Is Full" msg and send the Stop Charging trigger to an external device.

ADDITIONAL GOTCHA !
As stated, these packs are presently operating "independently" and this is how each is behaving in this situation. With a Master/Slave system as implemented the "Master" pack is BOSS and is responsible for comms to devices. HOW will BOSS react & communicate with several packs in Parallel if not all have triggered the 100% "Battery is Full". Say 3 of 5 have not set that "trigger" msg. WHAT will happen and how is that handled.

?? From my current understanding of the cycle, BOSS will send the final "Battery is Full" message to Device when "IT" has reached that OVP point regardless of the other packs status. When in reality it should register if ANY pack has not reached that threshold so that Charge Input can continue until All Packs in Parallel have reached 100% Battery Full state with the trigger. The SOC-100% value works for "display" purposes but otherwise not so much,.

Ideally, BOSS should not disable charging input if "any" pack in the bank has not achieved 100% Battery Full Trigger. (Apparently only triggered when A cell within a pack reaches OVP). The BMS' are more than capable of disconnecting charge independently and put the pack into "rest" mode while others can take the rest of the charge incoming. This should be the Default because Banks of Batteries never ever charge "exactly the same" because of numerous factors.

Hope it Helps & Good Luck.
Pinging @Nami from JK in case they are even remotely paying attention.

 

[....]

That is an interesting observation of the behavior of your 8s system.
From what I have been able to gather you are experiencing the exact opposite of the issue that we are having with the EG4/Luxpower inverter, which is that the inverter is using the 'for display only' SOC to terminate the charge and not waiting until the pack is actually full.

The JKBMS charge controller is correctly setting the target charge voltage over the pylontech/luxpower CAN protocols, but the inverter is summarily shutting down the charge controller as soon as the SOC reports at 100%.

For what it is worth, when operating in closed loop control with the JKBMS charge controller active the goal is to never reach the 'battery full' state where the charge mosfets are forcefully shut off as you report, that condition would be reserved only for an emergency situation where the pack is being grossly overcharged. Instead the charge controller target voltage/current/status is set over CAN.

Question, without ghost battery are you seeing not only does charging stop to battery but your surplus of PV can’t be used to power loads and inverter starts drawing from battery?

I have not seen the inverter start to draw from grid with the sun shining, but I haven't been watching the battery current draw closely in that state. I don't think I ever saw it draw the battery down below 99% with the sun shining before I added the ghost battery.

 

[kommando]

That is an interesting observation of the behavior of your 8s system.
From what I have been able to gather you are experiencing the exact opposite of the issue that we are having with the EG4/Luxpower inverter, which is that the inverter is using the 'for display only' SOC to terminate the charge and not waiting until the pack is actually full.

The JKBMS charge controller is correctly setting the target charge voltage over the pylontech/luxpower CAN protocols, but the inverter is summarily shutting down the charge controller as soon as the SOC reports at 100%.

For what it is worth, when operating in closed loop control with the JKBMS charge controller active the goal is to never reach the 'battery full' state where the charge mosfets are forcefully shut off as you report, that condition would be reserved only for an emergency situation where the pack is being grossly overcharged. Instead the charge controller target voltage/current/status is set over CAN.



I have not seen the inverter start to draw from grid with the sun shining, but I haven't been watching the battery current draw closely in that state. I don't think I ever saw it draw the battery down below 99% with the sun shining before I added the ghost battery.

Its been 78 days running my first JK PB BMS closed loop with SMA Sunny Island which correctly continues to charge after the calc 100% but stops at Cell RCV and not a single alarm message in all that time.

The only issue I am left with is the SOC drift with the overnight low amps being drawn not being accurately recorded by the JK.

 

[Steve_S]

Its been 78 days running my first JK PB BMS closed loop with SMA Sunny Island which correctly continues to charge after the calc 100% but stops at Cell RCV and not a single alarm message in all that time.

The only issue I am left with is the SOC drift with the overnight low amps being drawn not being accurately recorded by the JK.

Have you updated firmware ? (fireware LMAO that's too cute)

Interestingly, I use a Midnite Solar WizBangJr Smartshunt (similar to Victrons) with the Battery Efficiency setting set to 99%.
With everything dialed in (for offsets etc) it is actually quite accurate, right from 15% to 100% in either direction. Right now it says my Bank is at 96% and charging, I step into the powerhouse & look and all pack displays say 96% as well. Now I have let the bank drop to 5" and did not that the shunt & packs the accuracy begins to diverge below 12%. I do not let my bank get there but I do thrash tests to push edge cases.

 

[kommando]

Have you updated firmware ? (fireware LMAO that's too cute)

Yes, came with 15.10 then most of the time it has been on 15.17 and last couple of days on 15.24.

 

[....]

?? From my current understanding of the cycle, BOSS will send the final "Battery is Full" message to Device when "IT" has reached that OVP point regardless of the other packs status. When in reality it should register if ANY pack has not reached that threshold so that Charge Input can continue until All Packs in Parallel have reached 100% Battery Full state with the trigger. The SOC-100% value works for "display" purposes but otherwise not so much,.

I am not sure about your use case (open loop system), but I think that you are misunderstanding how the JKBMS is intended to operate.
The 'battery is full' error message is a poor Chinese translation for 'battery is overcharged, activate over voltage protection to prevent battery damage'.
I am not sure what you were trying to demonstrate in your test of the OVP protection, from your description it seems to be working fine.


For the closed loop case using CAN communication and the JKBMS charge controller, there is a binary 'enable charge' signal (pylontech CAN address 0x35C bit 7) but in general this is not used to control the charge behavior. Instead the charging is controlled by the 'max charge voltage/current' (pylontech CAN address 0x351) set by the BMS (configured using the RCF, RFV, RCV time, RFV time, etc) which is used to control the charger. This is all explained in the pylontech CAN protocol documents.

For a nice example of this in operation, see @marky0 who has a nice log of his pylontech system in operation at https://diysolarforum.com/threads/pylontech-battery-in-parallel-with-diy-battery.75996/#post-980110

You can see from his data with a genuine pylontech battery array (US5000C) and solis inverter, the inverter 'max charge limit' in grey is reduced as the cell SOC increases, ultimately dropping to 0A at 100% SOC when the battery is fully charged.

The issue we have been facing with the JKBMS in closed loop mode with the EG4/Luxpower inverter (and many other chinese inverters) that the JKBMS reports 100% SOC during the final phases of the charging, and the inverter shuts down the charge controller as soon as it sees 100% SOC reported by the JKBMS (despite setting CAN address 0x35C bit 7 'charge enable' to enabled).


There is an interesting difference between the JKBMS charge controller and the genuine pylontech one:

The genuine pylontech charge algorithm is current based: it tapers the max charge current down slowly above 90% SOC to maintain the battery voltage just below 3.60V/cell, and then calls the battery 100% charged when the required current drops to 0.

The JKBMS charge algorithm is voltage based: It requests maximum charge current right up until the battery reaches RCV, and then holds at a constant voltage (RCV) for a set time (RCV time) during which the current naturally tapers off as the battery finishes charging, then it drops down to RFV (as shown in the plots I posted). This behavior would be fine except that it reports 100% SOC before the battery even gets to RCV, which triggers the inverter to shutdown prematurely.

 

[AshleyL]

For a nice example of this in operation, see @marky0 who has a nice log of his pylontech system in operation at https://diysolarforum.com/threads/pylontech-battery-in-parallel-with-diy-battery.75996/#post-980110

You can see from his data with a genuine pylontech battery array (US5000C) and solis inverter, the inverter 'max charge limit' in grey is reduced as the cell SOC increases, ultimately dropping to 0A at 100% SOC when the battery is fully charged.

The issue we have been facing with the JKBMS in closed loop mode with the EG4/Luxpower inverter (and many other chinese inverters) that the JKBMS reports 100% SOC during the final phases of the charging, and the inverter shuts down the charge controller as soon as it sees 100% SOC reported by the JKBMS (despite setting CAN address 0x35C bit 7 'charge enable' to enabled).


There is an interesting difference between the JKBMS charge controller and the genuine pylontech one:

The genuine pylontech charge algorithm is current based: it tapers the max charge current down slowly above 90% SOC to maintain the battery voltage just below 3.60V/cell, and then calls the battery 100% charged when the required current drops to 0.

The JKBMS charge algorithm is voltage based: It requests maximum charge current right up until the battery reaches RCV, and then holds at a constant voltage (RCV) for a set time (RCV time) during which the current naturally tapers off as the battery finishes charging, then it drops down to RFV (as shown in the plots I posted). This behavior would be fine except that it reports 100% SOC before the battery even gets to RCV, which triggers the inverter to shutdown prematurely.

Basically JK implementation fault?

 

[Steve_S]

I am not sure about your use case (open loop system), but I think that you are misunderstanding how the JKBMS is intended to operate.

These are my observations with 3 Packs, running independently (not connected to anything) and observing the behaviour of the cycling. It wasn't related to Communications externally with any protocol as such. My assumption was for the trigger point for 100%-SOC and when the BMS actually reports (to screen & log) that the "Battery is Full" and not just the indicator that says 100% before that message comes. And noting that when the BMS says in text that "battery is full" it then cuts off Charge Input, regardless if the SOC-100% threshold has been reached.

Simply Put (IMO) The BMS should NOT have to reach OVP to cutoff charging & declare itself "full". You are likely quite correct on the bad translation but still. I my opinion it should Stop Charging when the defined 100% SOC is reached and not later.

Again, these are not interconnected to anything, just running in Stand-Alone mode in parallel.

I don't know what is in the PylonTech/Victron & other stacks. Regardless of that, not everyone will want to or does charge their cells to 3.600, many of us (maybe even the majority) don't go over 3.500Vpc. For example I don't go over 3.475 and won't.

Also in my installation, I have Midnite Classic SCC's, Samlex EVO Inverter and none of that can interact with these BMS' in any case. But a Raspi with Node-Red + a few bits can get the info and store/display it for system monitoring with limited management (pending on device).