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

[silverstone]

and i believe my maths is right becos the voltage is constant - there should really only be a .510 difference between the 2 BMS's

It does NOT matter. SOC is determined based on coulomb counting (measurement of current & integration over time).

Voltage measurement is NOT an accurate method to evaluate the SOC of a Lithium Battery (let alone if you have some load / current flowing !). Maybe a bit better for Li-Ion, but if you are still in the "flat" part of the SOC/voltage characteristic, a very small voltage difference corresponds to a HUGE SOC difference.

That SOC is reset to 100% (or 99%) if all your cells reach a target voltage & your current goes below the tail current. Similar to Victrom Smartshunt I guess.

So, if your SOC resets to 100% after a full charge, are you sure:
- You did NOT underestimate the capacity ?
- You did NOT set voltages that are too low for absorbtion / bulk ?

I notice a 5% deviation of SOC between my batteries, even though they reset approx. every day (minus the unbalance of battery 02 of course). That could also be to the different version of the JK BMS that is used, inaccuracies in the current measurement of the JK BMS (coulomb counting ...), one cell being lower capacity than the other and thus hitting OVP / UVP earlier etc.

Or also my temporary cabling, causing some current sharing unbalance. The list is big ...

 

[chaosnature]

It was the esphome command 'esphome run ESP32_LFP_Wire_jk-bms-can.yaml' that generated the ERROR resolving IP address of jk-bms-can.local. Is it connected to WIFI?

Other then that I have not used any esphome commands.

I tried 5 different type-c to USB cable's, not sure any of them have data support though so I guess heading over to a store and pick up a data specific type-c cable is my next move

I am very sure it is not cable friend - i have the same issue with S3 - last i heard its a GPIO conflict, how true that is i dont know
bottom line is i cannot flash these yaml code into the module, i can however flash Wifi and Bluetooth sample and also using M5Burner.exe to flash S3 samples work

i have the screen ESP S3 module and the screen totally went off after flashing certain yaml...almost like the firmware bricks the module

# Edit

and it loops

 

[chaosnature]

It does NOT matter. SOC is determined based on coulomb counting (measurement of current & integration over time).

Voltage measurement is NOT an accurate method to evaluate the SOC of a Lithium Battery (let alone if you have some load / current flowing !). Maybe a bit better for Li-Ion, but if you are still in the "flat" part of the SOC/voltage characteristic, a very small voltage difference corresponds to a HUGE SOC difference.

That SOC is reset to 100% (or 99%) if all your cells reach a target voltage & your current goes below the tail current. Similar to Victrom Smartshunt I guess.

So, if your SOC resets to 100% after a full charge, are you sure:
- You did NOT underestimate the capacity ?
- You did NOT set voltages that are too low for absorbtion / bulk ?

I notice a 5% deviation of SOC between my batteries, even though they reset approx. every day (minus the unbalance of battery 02 of course). That could also be to the different version of the JK BMS that is used, inaccuracies in the current measurement of the JK BMS (coulomb counting ...), one cell being lower capacity than the other and thus hitting OVP / UVP earlier etc.

Or also my temporary cabling, causing some current sharing unbalance. The list is big ...

- You did NOT underestimate the capacity ? I have tried different Capacity after setting the capacity from the Datasheet same - i have since left it to the capacity defined by the original Growatt datasheet.

- You did NOT set voltages that are too low for absorbtion / bulk ? - this one i dont understand fully so can comment yet - i used tried the original Bulk and Absorbtion settings that cam with the yaml script, , eventually had to increase the float and the bulk though as it was stopping charge at 88 %

- Or also my temporary cabling, causing some current sharing unbalance. The list is big ... - I have ruled this one out, my cabling are o.k i believe

 

[silverstone]

I am very sure it is not cable friend - i have the same issue with S3 - last i heard its a GPIO conflict, how true that is i dont know
bottom line is i cannot flash these yaml code into the module, i can however flash Wifi and Bluetooth sample and also using M5Burner.exe to flash S3 samples work

i have the screen ESP S3 module and the screen totally went off after flashing certain yaml...almost like the firmware bricks the module

# Edit

and it loops

No problems with flashing using USB on Linux. Flashing over OTA very unreliable though. Weird difference ...

 

[RostadKatt]

I am very sure it is not cable friend - i have the same issue with S3 - last i heard its a GPIO conflict, how true that is i dont know
bottom line is i cannot flash these yaml code into the module, i can however flash Wifi and Bluetooth sample and also using M5Burner.exe to flash S3 samples work

i have the screen ESP S3 module and the screen totally went off after flashing certain yaml...almost like the firmware bricks the module

# Edit

and it loops

Aah, that might save me a trip to the store.. Where you able to get this working with the bms from Windows eventually? Or do I have to install Linux here?

Appreciate all the assistance!

 

[chaosnature]

.

 

[RostadKatt]

Managed to get a cable that will communicate with the Atom s3 lite, problem now is the esphome command creates a esp32 firmware image, not a esp32s3 image. Can I somewhat easily edit the yaml to make a esp32s3 image instead?

 

[silverstone]

Managed to get a cable that will communicate with the Atom s3 lite, problem now is the esphome command creates a esp32 firmware image, not a esp32s3 image. Can I somewhat easily edit the yaml to make a esp32s3 image instead?

So it was really a cable issue ? Wow ... 5 times unlucky ...

About the ESP32 / ESP32s3 it's all about the config.

For the Atom S3 Lite I have:

esphome:
  name: ${name}
  platformio_options:
    board_build.flash_mode: dio
    build_flags:
      - -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768
  comment: ${device_description}
  project:
    name: !secret project_name
    version: !secret project_version
  on_boot:
    then:
      - switch.turn_on: can_switch_charging
      - switch.turn_on: can_switch_discharging
      - switch.turn_on: can_switch_float
      - switch.turn_on: can_switch_auto_charge_current
      - switch.turn_on: can_switch_auto_discharge_current
      - switch.turn_on: can_switch_auto_charge_voltage

# +--------------------------------------+
# | ESP32 settings                       |
# +--------------------------------------+
# For a stable Bluetooth connection keep the "esp-idf" framework
esp32:
  board: esp32-s3-devkitc-1
  variant: esp32s3
  framework:
    type: esp-idf

Note the board, variant, and be sure to include also the

 platformio_options:
    board_build.flash_mode: dio
    build_flags:
      - -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768

Otherwise you might experience flashing issues (dio) and/or runtime issues (stack).

This is my complete config if interested: https://github.com/luckylinux/jk-bm...main/esphome-jk-bms-can/esp32-ble-1.17.5.yaml

But it's heavily modified from the original (but I'm trying to keep up to date with it).

I should move that file to the proper repo that I forked though. Work for another day ...

 

[RostadKatt]

So it was really a cable issue ? Wow ... 5 times unlucky ...

About the ESP32 / ESP32s3 it's all about the config.

For the Atom S3 Lite I have:

Seems like i managed to flash this finally. Off to soldering some pins and test this!

Thanks!

 

[paulsteigel]

- You did NOT underestimate the capacity ? I have tried different Capacity after setting the capacity from the Datasheet same - i have since left it to the capacity defined by the original Growatt datasheet.

- You did NOT set voltages that are too low for absorbtion / bulk ? - this one i dont understand fully so can comment yet - i used tried the original Bulk and Absorbtion settings that cam with the yaml script, , eventually had to increase the float and the bulk though as it was stopping charge at 88 %

- Or also my temporary cabling, causing some current sharing unbalance. The list is big ... - I have ruled this one out, my cabling are o.k i believe

Hi,
I think we should not debate on SOC issue any more, It can be solved already:
+ If JK SOC reported 100% at 3.35 or somewhat too low (less than 3.4 while charging) >> it need to keep charging, it can still absorb: in my case, I report to Inverter 98% (Sleeper85 use 99%) as Inverter sometime stop charging at 99%. and it can take remarkably more energy and SOC will reset at 100% at the new energy level!
+ If JK SOC report 0-10% at 3.2V or higher or suddenly drop to 0 in no where. This need a refreshing discharge. Keep discharging till voltage drop to 3.1V (with moderate discharge current) and then charge to full (as closer to 3.45 as better).
This is how I did and we will not have to touch the jk Bluetooth app anymore.
Best

 

[Sleeper85]

Hi,
I think we should not debate on SOC issue any more, It can be solved already:
+ If JK SOC reported 100% at 3.35 or somewhat too low (less than 3.4 while charging) >> it need to keep charging, it can still obsorpt: i my case, I report to Inverter 98% (Sleeper85 use 99%) as Inverter sometime stop charging at 99%. and it can take remarkably more enegy.
+ If JK SOC report 0-10% at 3.2V or higher or suddenly drop to 0 in no where. This need a refreshing discharge. Keep discharging till voltage drop to 3.1V (with moderate discharge current) and then charge to full (as closer to 3.45 as better).
This is how I did and we will not have to touch the jk bluetooth app anymore.
Best

I'm putting this on my todo list. For information, I compared the soc of a JK-BMS 8S with a shunt for 30 days and the curves follow each other closely with just a few percent difference. I can send graphics tomorrow. I calibrate all JK-BMS for correct measurement with stable 5A.

 

[shvm]

Inverter use SOC but not Voltage to regulate its charging/discharging process.

But, there is an option to use Voltage instead of SOC to specify charge/discharge parameters. I have been using it for months now as I speak.



I think you're wasting efforts trying to solve a problem that never existed in the first place.

 

[shvm]

I am sure a compromise can be reached between yourself and MrPablo to integrate the proposed changes into the latest version; as it does make sense, the case you are putting forward....

From what I understand personally, the charging logic implementation is pretty much information complete.
There is not much that we have changed in the charging logic in the last two months.
The project has moved on to tackling the multi-bms problem instead.
The AutoCVL features are really just protections measures to prevent Cell OVP alarms in very unbalanced packs.

Where we are actually experiencing issues currently is regarding how BMS's handle cell balancing and how to ensure convergent cell balancing. And that requires the charging logic to dictate when balancing takes place.
Unfortunately, this is something that is not in our hands. Unless, JK decide to roll out a firmware update that is.
This is really the hurdle we are facing in order to release a truly, plug, play, configure once and forget system.

On the plus side,
The hard working guys have already managed to push changes to the current dev branch. The code has now been nicely separated into modules. Needless to say, the charging logic has also been separated. My recommendation is to start from there.
All in all, It is easier now to maintain a separate charging implementation if so desired.
I fail to see the need personally, but at the same time, feel free to tweak things. It is Open Source after all.

again hard to tell with my limited coding knowledge

Coding knowledge is not a necessity in order to contribute to the project. Fundamental and experimentally rooted understanding is of primary importance. You can not be a coder and still contribute with feature suggestions, bugs squashing, testing, wiki/documentation/video/tutorials and much more.

 

[silverstone]

From what I understand personally, the charging logic implementation is pretty much information complete.
There is not much that we have changed in the charging logic in the last two months.
The project has moved on to tackling the multi-bms problem instead.
The AutoCVL features are really just protections measures to prevent Cell OVP alarms in very unbalanced packs.

Where we are actually experiencing issues currently is regarding how BMS's handle cell balancing and how to ensure convergent cell balancing. And that requires the charging logic to dictate when balancing takes place.
Unfortunately, this is something that is not in our hands. Unless, JK decide to roll out a firmware update that is.
This is really the hurdle we are facing in order to release a truly, plug, play, configure once and forget system.

On the plus side,
The hard working guys have already managed to push changes to the current dev branch. The code has now been nicely separated into modules. Needless to say, the charging logic has also been separated. My recommendation is to start from there.
All in all, It is easier now to maintain a separate charging implementation if so desired.
I fail to see the need personally, but at the same time, feel free to tweak things. It is Open Source after all.


Coding knowledge is not a necessity in order to contribute to the project. Fundamental and experimentally rooted understanding is of primary importance. You can not be a coder and still contribute with feature suggestions, bugs squashing, testing, wiki/documentation/video/tutorials and much more.

To be honest yesterday I tried to convert an existing GitHub Project for Deye Esphome to a more modular approach in order to read / set some Deye Inverter Settings and monitor the Inverter Solar Production / Battery Consumption / AC Load / etc.

Took like 4 hours to do and I added a ton of registers as well.

I'm quite code friendly (although definitively NOT ESPHome and C++ it has been a long time since I coded it) but it's not rocket science.

You mainly need Copy-paste examples/templates, adapt to your needs, Google whenever you find issues and most likely than not, somebody has already [tried to] address it . It's not rocket science at all.

And the "packages" feature of ESPHome is definitively welcome. It's basically an "include" with "merge the root of this file into this file".
Just been using the very simple basics for now though:

esphome-for-deye/esphome-config-common.yaml at main · luckylinux/esphome-for-deye

Esphome component for Deye 3 phase inverters for Home Assistant - luckylinux/esphome-for-deye

github.com

I still need to test all the registers I added though, so there is where most of the work is. The devil is in the detail.

Just because ESPHome compiles, it does NOT mean that it does what you want (or what you think you want) .

@shvm: Not sure what you meant about "The project has moved on to tackling the multi-bms problem instead.". There is still no expected date for it. I just saw a commit about multi BMS YAML mentioning the PVBrain2 but not sure how far it is really.

@Sleeper85 , @Der_Hannes, @MrPablo: Where can we follow about the development status actually ?

 

[paulsteigel]

But, there is an option to use Voltage instead of SOC to specify charge/discharge parameters. I have been using it for months now as I speak.

View attachment 206677

I think you're wasting efforts trying to solve a problem that never existed in the first place.

I understood your points: Lux has problem working with Voltage when setting battery as lion. It does not behave as configured such as to discharge in defined time (if setting charge base on time and SOC or Voltage with time range of 7AM-5PM, AC charge current to 0). To activate the discharge defined time (i.e 5PM - 7AM) I have to Change to SOC and apply and change back to Voltage. But if discharge is set for SOC it will start discharging automatically from 5PM to 7AM without problem. This has been raised to Lux tech team and they share that issue with us and recommend me to set battery in Lead acid mode to fully have "control by voltage feature".
Lux seems to be a bit illogical in defining the relationship of parameters on both web and mobile app interface.
For example: When AC charge is disabled you can not set start charge volt and end charge volt. Similarly applied to discharge.
Anyway, each of us have different view on the issue we are facing. Thanks for your sharing.
Best,
Ngoc

 

[Sleeper85]

GitHub - Sleeper85/esphome-jk-bms-can at development

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

github.com

There is no roadmap with a clear vision of the progress of the project.

I currently work in the development branch.
Attention ! It hasn't been tested yet! I do not advise you to use it. But if you want to look at the code or test it you can.

Yesterday I added a first multi-bms code for the connection of several BMS in UART or BLE on the same ESP32 as will be done with the PVbrain2 board (ESP32-S3).

This code could work with a classic ESP32 board (max 3 UARTs). Concerning the maximum number of BLE connections it depends on the board, a classic ESP32 supports 2 BMS without problems.

The next step would be a master-slave multi-bms code connected by a can bus in the same way as the Peter Board.

 

[silverstone]

GitHub - Sleeper85/esphome-jk-bms-can at development

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

github.com

There is no roadmap with a clear vision of the progress of the project.

I currently work in the development branch.
Attention ! It hasn't been tested yet! I do not advise you to use it. But if you want to look at the code or test it you can.

Yesterday I added a first multi-bms code for the connection of several BMS in UART or BLE on the same ESP32 as will be done with the PVbrain2 board (ESP32-S3).

This code could work with a classic ESP32 board (max 3 UARTs). Concerning the maximum number of BLE connections it depends on the board, a classic ESP32 supports 2 BMS without problems.

The next step would be a master-slave multi-bms code connected by a can bus in the same way as the Peter Board.

So the MQTT solution by @Der_Hannes was just a temporary fix for his use case ? It's not the way forward ?

RS485 or CAN for multiple (inter) BMS communication could be nice, but I don't have much experience using those protocols.

I guess it's just a matter of setting up several registers on the master controller (the one talking with the Inverter) say up to 32 registers sets (for up to 32 batteries) where each register contains ALL the data that is being sent out by the slaves (so each register set is actually maybe 99 registers to store all cell voltages, current, power, energy, etc).

 

[shvm]

There is no roadmap with a clear vision of the progress of the project.

Exactly, providing any sort of timeline would only hurt the quality of the project.

 

[Sleeper85]

The code in development is not finished, there are parts of the code still to be finalized and tested. I think it's not a good idea to leave comments here regarding this code. Maybe we need to create a dedicated topic for beta testers. To discuss.

 

[silverstone]

The code in development is not finished, there are parts of the code still to be finalized and tested. I think it's not a good idea to leave comments here regarding this code. Maybe we need to create a dedicated topic for beta testers. To discuss.

Fair enough. I'd just like to work together.

Because otherwise I'd have to do my own fork and do all the back/forward port which isn't really easy or useful.

It's like reinventing the wheel 10 times. Why should it be done ?

But I'm not a mind reader, so it would be nice to have some regular updates on how you are planning to go forward etc. I don't know how you communicate with @Der_Hannes or @MrPablo but I'd like to be part of the beta testers / developers discussion.