diy solar

diy solar

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

silverstone said:
EDIT. maybe GPIO35 is not a great idea on the Atom S3 Lite ...

Code: 
WARNING GPIO35 is used by the PSRAM interface on ESP32-S3R8 / ESP32-S3R8V and should be avoided on these models

Maybe GPIO38 which is exposed on the Atom S3 Lite instead ?

Messing with PSRAM seems a bad idea after all ...
Click to expand...
Hi,

on Atom S3 Lite GPIO35 is actually hardwired to RGB led diode through popular WS2812 controller,
here is interesting led esphome test, tested myself and it is working, part of the relevant code:
Code: 
#G35=RGB WS2812C-2020
  - platform: esp32_rmt_led_strip
    rgb_order: GRB
    pin: 35
    num_leds: 4
    # RMT 0 channels will be occupied by IR
    rmt_channel: 1
    chipset: ws2812
    id: led
    name: "Led"
 
@MrPablo: I see you yesterday introduced the "Updated Auto Charge Voltage logic". Is this a separate issue from the "End Of Charge" Logic that I just implemented (backported from you based on your change)? Don't you think it is best to leave the old charge logic and put a selector box there to select the parameter so one can switch between old and new logic (v1 and v2 essentially) ?

EDIT 1: I also opened a PR to clarify a bit better the pinout issues I was facing.

True, it's a different module/unit/etc, but for those not familiar with M5Stack naming convention it's an easy mistake that can be made:
github.com

Adding Configuration Clarification in Atom S3 Config File by luckylinux · Pull Request #36 · Sleeper85/esphome-jk-bms-can

Adding Configuration Clarification between CANBus Unit (SKU: U085) and ATOMIC CANBus Base (SKU: A103). In my case, I couldn't buy the A103 on Digikey so I ended up buying the U085. Of course I disc...
github.com github.com
 
Last edited:
inverter via a TJA1050, TJA1051T or SN65HVD230 CAN bus transceiver.
Click to expand...
These TJA1050 are outputting their pins at Vcc + 0.3 volts? Their supply is 4.75 min so it's always like 5-6volts for data pins?
How is that working with the inverters, some accept that huge range of 3 - 6 volts for the CAN input?

Oh you're hoping on the 4.7k resistor to convert it but recommend the SN65HVD230 if an inverter only receives 3.3v?
What's the reason to bother with the others, since they're cheaper?
 
Last edited:
gotbeans said:
These TJA1050 are outputting their pins at Vcc + 0.3 volts? Their supply is 4.75 min so it's always like 5-6volts for data pins?
How is that working with the inverters, some accept that huge range of 3 - 6 volts for the CAN input?

Oh you're hoping on the 4.7k resistor to convert it but recommend the SN65HVD230 if an inverter only receives 3.3v?
What's the reason to bother with the others, since they're cheaper?
Click to expand...
I ordered a bunch of each from AliExpress. Also MAX485 and MAX3485 for RS485.

In any case, given the cost of the Inverter (each is approx. 3000 EUR), I decided to rather use a Isolated CAN Transceiver, such as the ones recommended.

Cannot sweat 30 EUR or so for a proper solution when the Inverter is 3000 EUR ...

Plus you avoid problems like ground loops / potential reference etc, since CAN_GND is NOT exposed on my inverter.
 
silverstone said:
I ordered a bunch of each from AliExpress. Also MAX485 and MAX3485 for RS485.

In any case, given the cost of the Inverter (each is approx. 3000 EUR), I decided to rather use a Isolated CAN Transceiver, such as the ones recommended.

Cannot sweat 30 EUR or so for a proper solution when the Inverter is 3000 EUR ...

Plus you avoid problems like ground loops / potential reference etc, since CAN_GND is NOT exposed on my inverter.
Click to expand...
Not sure how your answer relates to my question about the voltage output of these chips and the inverters seemingly to accept random voltages
seems your MAX485 has even larger voltage range <__<
 
gotbeans said:
Not sure how your answer relates to my question about the voltage output of these chips and the inverters seemingly to accept random voltages
seems your MAX485 has even larger voltage range <__<
Click to expand...
It's not directly related, agreed, but I just want to point out before people try random stuff because of saving 0.5 EUR or so and potentially damaging a 3000 EUR piece of equipment :).

MAX485 should NOT be used at 3.3V, it's definitively out of spec, some people use it at 3.3V and get away with it. The proper solution is MAX3485 or other 3.3V compliant devices :).
 
gotbeans said:
the common-mode seems to be 3v, in the data sheet
Click to expand...
I don't have direct experience with either.

I just read this and thought ... Maybe better to get the MAX3485 for 3.3V operation:
github.com

Example application with hardware · eModbus eModbus · Discussion #112

Circuit This is an example circuit for the ESP32 side. Keep in mind that biasing resistors (the two 680Ohms resistors) need to be added only once on the entire bus. The terminating resistors have t...
github.com github.com
 
V1.17.5 has been released on GitHub:
github.com

GitHub - Sleeper85/esphome-jk-bms-can

Contribute to Sleeper85/esphome-jk-bms-can development by creating an account on GitHub.
github.com github.com

Changelog:
- Auto Charge Voltage Control function rewritten
- EOC cycle threshold added to reduce premature triggering of float phase

This is a small release whilst we continue to work towards a modular and potentially multiBMS solution.
The Auto Charge Voltage Control function has been rewritten to be both more efficient and more reliable for users with packs suffering higher imbalances. You can find documentation on this feature here.

In addition, an extra threshold has been added to the End of Charge logic, reducing the likelihood of premature charge termination.
By default, both the current and max cell voltage need to meet an automatically calculated threshold for 60 cycles (approximately 60s) - this can be adjusted in the parameters if required.

Finally, a request to any users with feature requests, ongoing issues, etc - please create an issue on GitHub at the following link:
github.com

Issues · Sleeper85/esphome-jk-bms-can

Contribute to Sleeper85/esphome-jk-bms-can development by creating an account on GitHub.
github.com github.com
That makes it much easier for us to track, investigate and resolve queries. Right now, we're at 42 pages on this thread, and it'll only grow from there.
 
Last edited:
silverstone said:
@MrPablo: I see you yesterday introduced the "Updated Auto Charge Voltage logic". Is this a separate issue from the "End Of Charge" Logic that I just implemented (backported from you based on your change)? Don't you think it is best to leave the old charge logic and put a selector box there to select the parameter so one can switch between old and new logic (v1 and v2 essentially) ?

EDIT 1: I also opened a PR to clarify a bit better the pinout issues I was facing.

True, it's a different module/unit/etc, but for those not familiar with M5Stack naming convention it's an easy mistake that can be made:
github.com

Adding Configuration Clarification in Atom S3 Config File by luckylinux · Pull Request #36 · Sleeper85/esphome-jk-bms-can

Adding Configuration Clarification between CANBus Unit (SKU: U085) and ATOMIC CANBus Base (SKU: A103). In my case, I couldn't buy the A103 on Digikey so I ended up buying the U085. Of course I disc...
github.com github.com
Click to expand...

I don't think it's best to leave the old logic in, no.
Supporting two sets of logic is more work, plus testing indicates this solution should work effectively when used in conjunction with Auto Charge Current control.
 
MrPablo said:
V1.17.5 has been released on GitHub:
github.com

GitHub - Sleeper85/esphome-jk-bms-can

Contribute to Sleeper85/esphome-jk-bms-can development by creating an account on GitHub.
github.com github.com

Changelog:
- Auto Charge Voltage Control function rewritten
- EOC cycle threshold added to reduce premature triggering of float phase

This is a small release whilst we continue to work towards a modular and potentially multiBMS solution.
The Auto Charge Voltage Control function has been rewritten to be both more efficient and more reliable for users with packs suffering higher imbalances. You can find documentation on this feature here.

In addition, an extra threshold has been added to the End of Charge logic, reducing the likelihood of premature charge termination.
By default, both the current and max cell voltage need to meet an automatically calculated threshold for 60 cycles (approximately 60s) - this can be adjusted in the parameters if required.

Finally, a request to any users with feature requests, ongoing issues, etc - please create an issue on GitHub at the following link:
github.com

Issues · Sleeper85/esphome-jk-bms-can

Contribute to Sleeper85/esphome-jk-bms-can development by creating an account on GitHub.
github.com github.com
That makes it much easier for us to track, investigate and resolve queries. Right now, we're at 42 pages on this thread, and it'll only grow from there.
Click to expand...
Now I'll have to try to backport the Auto Charge Voltage Control as well :ROFLMAO: .

EDIT 1:
@MrPablo: I probably didn't mention often enough, but THANK YOU (for your help, for the enhancements, for the technical explanations, ...) (y) .

EDIT2:
Actually it wasn't *that* bad to backport the modifications using VSCodium Compare Files Features :).
I forgot I had enabled BMS_Err_Stop, so of course it tried to do OTA update and tripped the whole thing :ROFLMAO:.
 
Last edited:
I just want to say... thanks for all the work by the devs. Been running this since the early UKSA versions, and was sad to see it go closed source. My inverter (Goodwe5048) had some issue where it would just periodically stop charging without BMS feedback, so this whole project fixed a serious issue for me. Super happy to see the project continue.
I am still running V1.15.5 without issue, but my system is well behaved...never any issues with balance. I think my JK soc drifts by about 5% a cycle, but from solar the charging is BMS/voltage based, so it always gets back in sync within a few days (summer here atm). In winter I have some issues as when charging from grid the inverter stops at 100% SOC, but it looks like many of the recent improvements will fix that. Multi BMS would be great (parts for another battery on the boat), but recently I have had a pack built for someone else in P with mine for testing, and they play fairly nice... sure the SOC's diverge at various parts of the charge cycle by up to 10% (EVE in one pack, CATL in the other, CATL >1.5 yrs old, EVE new), but it all evens out in the end!
just wanna say thanks for the hardwork :)
 
silverstone said:
Now I'll have to try to backport the Auto Charge Voltage Control as well :ROFLMAO: .

EDIT 1:
@MrPablo: I probably didn't mention often enough, but THANK YOU (for your help, for the enhancements, for the technical explanations, ...) (y) .

EDIT2:
Actually it wasn't *that* bad to backport the modifications using VSCodium Compare Files Features :).
I forgot I had enabled BMS_Err_Stop, so of course it tried to do OTA update and tripped the whole thing :ROFLMAO:.
Click to expand...
Thanks @silverstone, hopefully the new auto voltage control will make it easier for you to keep your battery balanced.
 
MrPablo said:
Thanks @silverstone, hopefully the new auto voltage control will make it easier for you to keep your battery balanced.
Click to expand...
I just updated the YAML file name and version tag on the build script
github.com

jk-bms-build-helpers/esphome-jk-bms-can/esp32-ble-1.17.5.yaml at main · luckylinux/jk-bms-build-helpers

JK BMS Build Helpers. Contribute to luckylinux/jk-bms-build-helpers development by creating an account on GitHub.
github.com github.com

But I still ran into this "duplicate" host name issue in the sensors -> https://github.com/Sleeper85/esphome-jk-bms-can/issues/38
 
@MrPablo: Unfortunately the new automatic Charge Voltage doesn't work correctly for me.

It's actually extremely aggressive - jumping from 54.9V to 56.0V to 55.1V to 56V

Do you want me to create a separate GitHub issue for this as well ?
 
MrPablo said:
Yes please.
Click to expand...
I'll actually wait a bit now just to not create another issue on GitHub for nothing .... If I set the charge_v_factor_setting to 3.0 it seems somewhat more stable.

I hit OVP 3 times in the last 10 minutes on Battery 02 ...

And of course current control is DISABLED as I don't want to debug interactions between the 2 (it was happening).
 
If you are charging at a higher C rate (which a max of 180A would suggest) then yes, charge_v_factor_setting can be set to be more aggressive.

At the same time, current control is recommended (with default float voltage and a sensible OVPR setting, but we've already gone through that in some detail.
 
MrPablo said:
If you are charging at a higher C rate (which a max of 180A would suggest) then yes, charge_v_factor_setting can be set to be more aggressive.
Click to expand...
Keep in mind 180A (well 200A) is for both batteries: the smart one running the communication with the inverter, and the "dumb" one (only reporting to MQTT/HA).

So it's actually Around 90-100A each.
 
@MrPablo: Actually I take it back. The default value of 2.0 didn't work at all for me (it actually went "full" power and caused cell 11 to hit OVP as usual).

When charge_v_factor = 3.0 instead it seems to work WONDERS.

So ... conclusions ... if there is no BMS communication or the current doesn't taper off when one cell is near OVP, then that will overcharge and recharging the other ones via the active balancer will take forever. Not sure why the overcharged cell comes back A LOT, then needs to rise again though.

Now all of them are above 3.42VDC so it should not take much. So in terms of Ah, it was NOT a huge unbalance:
1711549268542.png


Yesterday I think I brought up the lowest ones from 3.36VDC to 3.39VDC.

I think once the pack will be (re)balanced, it will be much more "normal" (provided that the voltage control works).

I'm still thinking there is something quite off with the active current control, but that's probably because I am forcing a top balance WELL ABOVE float of 53.6 V. Hence I decided to disable it, at least for now.
 
silverstone said:
@MrPablo: Actually I take it back. The default value of 2.0 didn't work at all for me (it actually went "full" power and caused cell 11 to hit OVP as usual).

When charge_v_factor = 3.0 instead it seems to work WONDERS.

So ... conclusions ... if there is no BMS communication or the current doesn't taper off when one cell is near OVP, then that will overcharge and recharging the other ones via the active balancer will take forever. Not sure why the overcharged cell comes back A LOT, then needs to rise again though.

Now all of them are above 3.42VDC so it should not take much. So in terms of Ah, it was NOT a huge unbalance:
View attachment 205074


Yesterday I think I brought up the lowest ones from 3.36VDC to 3.39VDC.

I think once the pack will be (re)balanced, it will be much more "normal" (provided that the voltage control works).

I'm still thinking there is something quite off with the active current control, but that's probably because I am forcing a top balance WELL ABOVE float of 53.6 V. Hence I decided to disable it, at least for now.
Click to expand...
I think I'll open an issue after all. It's "ringing" (oscillating) quite a lot near the top of the charge ... Both the requested charge voltage, the requested battery voltage and the actual charge current :cry:

EDIT 1: Link to Issue https://github.com/Sleeper85/esphome-jk-bms-can/issues/41
 
Last edited:
paulsteigel said:
Hi @silverstone and Mr. Pablo, why dont you try map(maxcellvoltage, UVP-50, UVP + 10, Max_charge_current, 0) I tested with this and it working sound okay! Will test tomorrrow a bit more on this!
Click to expand...
Hi @paulsteigel, the existing auto charge current control does similar to this already.
At the moment, we're working on controlling charge current through dynamically adjusting the requested CVL. That's the more effective way to do it, assuming your inverter regulates CVL properly...
 
You must log in or register to reply here.

Similar threads

X
JK inverter BMS and Voltronic/Phocos Inverter communication
2
Replies
27
Views
685
AshleyL
A
B
JK BMS does not stop/block charging after cel OVP is reached
Replies
8
Views
824
ShirBlackspots
ShirBlackspots
C
How to Flash Atom S3 with EspHome - HA
Replies
19
Views
1K
chaosnature
C
cjdell
JK BMS issues (suspect current sensor faulty) for 48V inverter setup
Replies
4
Views
717
howardvenezolano
H
B
JK BMS CAN info
Replies
4
Views
763
LEumel
L

diy solar

diy solar
Back
Top