diy solar

diy solar

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

agree - very strange. Have you checked if one terminal of the cell is getting warmer/hotter than the others?
Also checked torque?
No. No.

It was torqued properly with a Wrench and digital Torque scale/indicator, so torque value should be fine. That was done approx 6 months ago.

And I doubt I'd see anything at 10a-20a near the top of the curve. There just aren't *that* many losses at such low current.

Torque wise, one thing that made me unhappy was that the studs were quite short, so I could only use the busbar + the provided flange nuts, not the proper flat washer + conical washer + nut as I would normally otherwise.

EDIT 1:
Not sure how much that translates into capacity difference between cells. Maybe it's only 1Ah maybe 5Ah (0.3%-2%) ...

But battery 01 definitively behaves much more consistently.

Battery 02 was unbalanced from the very start (cell 01 or 16 was on much lower voltage at the beginning, since it came from an older batch, since the original was leaking electrolyte and had to throw it away), but properly slowly ramped up the voltage 0.1V on the whole pack little by little over 36 hours. Then all cells were at 3.6V (back when I had the OVP set to 3.60V / 3.65V).

That was described in my other thread here: https://diysolarforum.com/threads/j...d-also-current-power-measurement.79913/page-3 (you can see a bit the voltage evolution, current was very small, but not in those pictures I believe)

You can see how battery 01 has all cells rising together, while battery 02 had some strange push-pull-pull back-push going on, even though it ultimately converges.
1711263177157.png


At first I thought it was BMS leads wrongly connected, but that would result in instability, not (although slowly) convergence. What was even more surprising was that one cell (turquoise ?) is the first to rise, then goes down a lot, then it's the last to come back ...

This was me raising the voltage 0.1V by 0.1V approx at a rate of 0.1V/hour pr 0.1V/2 hours using a programmable charger (Emerson / Vertiv R48).

But I believe part of the problem is that while the balancer discharges the highest cell, the charger recharges it, that's why it takes SO MUCH LONGER than if the charger (or inverter voltage) would just "back off a little". In that case, as stated in this thread here, I got from 3.55VDC to 3.42VDC in like 180 seconds only (charging disabled from BMS). Lowering the Charger voltage below pack voltage would effectively do the same thing (if PV is sufficient, battery will NOT be discharged).

EDIT 2:
@MrPablo: this is also related to what I was telling you before. It's NOT actually only the tolerances (on BMS and on Inverter) about the voltage measurement, it's also the fact that the voltage needs to be lower in order to give some headroom for the balancer to work without getting counter-acted by the Charger/Inverter.

Because say you are at 54.4 VDC on the Battery Pack (reported by BMS and measured with a multimeter) and 54.4 VDC on the Inverter/Charger (reported by Inverter/Charger and measured with a multimeter). As soon as the JK BMS will start discharging the highest voltage cell, the Inverter/Charger will recharge the pack, based on (54.4 VDC - delta_v_absorbed_by_balancer - 54.4 VDC) / ESR = - delta_v_absorbed_by_balancer / 0.005 Ohm or so ...

So while the JK BMS discharges the highest cell and before it recharges the lowest, you need to ensure that the Charger/Inverter voltage is AT LEAST delta_v_absorbed_by_balancer below the pack voltage. For every cycle of balance effectively ... You can probably calculate this dynamically based on the JK BMS supercapacitor capacitance value and battery capacity and voltage status. Otherwise you kinda get a capacitor multiplier / charge pump going on there (or a "very small" boost converter effectively, discharge highest cell, Inverter/Charge recharges it, JK recharges lowest cell).

EDIT 3:
And I am not so sure that the "Current Charge Control" of 0A works effectively. Again, tolerance measurements here as well on the Inverter Side (0A is very small compared to 240A nominal, so measurement offset / error can be significant with respect to "real" 0A). I set my parameters to Current Curve Factor 1 - End of Curve = 4.00 and Current Curve Factor 1 - Curve Shape = 1.80. It needs to be quite aggressive, in my case at least.

EDIT 4: On Battery 02, it could also be a case of "Balancer Induced Unbalance". Battery 02 was reporting approx. 0.7V HIGHER on pack/battery level (NOT a diode :ROFLMAO: ) than Battery 01 or the Multimeter (again on pack/battery level, i.e. 16 cells !). Battery 01 was also off by 0.1V (again on pack/battery level, i.e. 16 cells !), but nowhere Battery 02.

So you could say that it effectively started balancing at 3.45V - (0.7V/16 cells) = 3.406 V / cell. Well below the charge knee curve. So it probably created quite a bit of unbalance. I have since then calibrated the voltage reading (at NO LOAD !) and also lowered the OVP and OVPR values, since now the safety margin became smaller. But IIRC I have not "top balanced" the system after the voltage offset calibration (you can see in the attached picture there is still approx 0.05V / cell difference between Battery 01 and Battery 02).

EDIT 5: @MrPablo Maybe I can just set this to a NEGATIVE value, so that when Charge voltage is getting reduced by the ESP32, then the inverter will in effect stay a bit LOWER than the battery pack

# Inverter offset, allows you to correct the inverter charging voltage
inverter_offset_v: "-0.1"
 
Last edited:
By the way, esphome doesn't support OTA with the esp-idf framework. What are you using in order to get OTA running ? And what are the implications / side effects ?

 
Last edited:
By the way, esphome doesn't support OTA with the esp-idf framework. What are you using in order to get OTA running ? And what are the implications / side effects ?

There is a developing component named ota_http by @Olivier. I tested and worked but with a lot of effort! Wireguard can be ok with a bit of learning curve but I proposed Olivier to move on an automated firmware over mqtt and hopefully he will do!
 
There is a developing component named ota_http by @Olivier. I tested and worked but with a lot of effort! Wireguard can be ok with a bit of learning curve but I proposed Olivier to move on an automated firmware over mqtt and hopefully he will do!
Right now I just enabled the OTA component. I will anyway need to modify /etc/hosts (GNU/Linux) since the DNS isn't really working at the moment.

I don't like too much that the OTA password is transmitted plaintext and no encryption/SSL/TLS takes places. Regardless if it's the ota: section, the ota_http: section or the webserver: section.

Granted I need to firewall down my garage (right now it's just doing ip_forwarding to my main LAN so I can access stuff). But security wise it's an absolute no-go.

EDIT 1: when trying to enable the webserver (mainly for debugging purposes), I am getting some errors:
Code:
...
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_esp_idf.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_libretiny.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_pico_w.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/application.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/component.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/component_iterator.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/controller.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/entity_base.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/helpers.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/log.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/ring_buffer.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/scheduler.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/string_ref.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/util.o
Compiling .pioenvs/jk-bms-bat02/src/main.o
Linking .pioenvs/jk-bms-bat02/firmware.elf
/root/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pioenvs/jk-bms-bat02/src/main.o:(.literal._Z5setupv+0xd38): undefined reference to `esphome::web_server::WebServer::WebServer(esphome::web_server_base::WebServerBase*)'
/root/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pioenvs/jk-bms-bat02/src/main.o: in function `setup()':
/root/ESPHome/esphome-jk-bms-can-1.17.4/.esphome/build/jk-bms-bat02/src/main.cpp:579: undefined reference to `esphome::web_server::WebServer::WebServer(esphome::web_server_base::WebServerBase*)'
collect2: error: ld returned 1 exit status
*** [.pioenvs/jk-bms-bat02/firmware.elf] Error 1
========================================================================================= [FAILED] Took 41.70 seconds =========================================================================================

YAML relevant section:
YAML:
web_server:
  port: 80
  version: 2 # Version 1 displays as a table. Version 2 uses web components and has more functionality. Defaults to 2.
  log: true
  local: true # No internet/intranet required on the clients (all assets are inlined, compressed and served from flash)
  include_internal: true # Whether internal entities should be displayed on the web interface. Defaults to false
  ota: false
  auth:
    username: !secret web_server_username
    password: !secret web_server_password
 
By the way, esphome doesn't support OTA with the esp-idf framework. What are you using in order to get OTA running ? And what are the implications / side effects ?

where did you got the info that esp-idf does not support ota?
Im using both on all of my devices and it works out of the box without any problems and without any fancy or creepy stuff needed to be done.
 
Weird ... Now it seems to be working, both with WebServer v1 and v2.

Code:
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/helpers.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/log.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/ring_buffer.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/scheduler.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/string_ref.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/util.o
Compiling .pioenvs/jk-bms-bat02/src/main.o
Linking .pioenvs/jk-bms-bat02/firmware.elf
RAM:   [==        ]  15.7% (used 51552 bytes from 327680 bytes)
Flash: [========  ]  77.4% (used 1420913 bytes from 1835008 bytes)
Building .pioenvs/jk-bms-bat02/firmware.bin
Creating esp32s3 image...
Successfully created esp32s3 image.
esp32_create_combined_bin([".pioenvs/jk-bms-bat02/firmware.bin"], [".pioenvs/jk-bms-bat02/firmware.elf"])
Wrote 0x16afe0 bytes to file /root/ESPHome/esphome-jk-bms-can-1.17.4/.esphome/build/jk-bms-bat02/.pioenvs/jk-bms-bat02/firmware-factory.bin, ready to flash to offset 0x0
========================================================================================= [SUCCESS] Took 39.09 seconds =========================================================================================
INFO Successfully compiled program.
Found multiple options for uploading, please choose one:
  [1] /dev/ttyACM0 (USB JTAG/serial debug unit)
  [2] Over The Air (jk-bms-bat02.solar.stefano.home)

The "fix" was to set:
YAML:
esp32:
  board: {{board}}
  variant: {{variant}}
  framework:
    type: esp-idf
    version: latest

Let it fail with esp-idf framework 3.50102.240122, then roll back to
YAML:
esp32:
  board: {{board}}
  variant: {{variant}}
  framework:
    type: esp-idf

Build again.

Then it succeeds for some weird reason.
 
Weird ... Now it seems to be working, both with WebServer v1 and v2.

Code:
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/helpers.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/log.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/ring_buffer.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/scheduler.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/string_ref.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/util.o
Compiling .pioenvs/jk-bms-bat02/src/main.o
Linking .pioenvs/jk-bms-bat02/firmware.elf
RAM:   [==        ]  15.7% (used 51552 bytes from 327680 bytes)
Flash: [========  ]  77.4% (used 1420913 bytes from 1835008 bytes)
Building .pioenvs/jk-bms-bat02/firmware.bin
Creating esp32s3 image...
Successfully created esp32s3 image.
esp32_create_combined_bin([".pioenvs/jk-bms-bat02/firmware.bin"], [".pioenvs/jk-bms-bat02/firmware.elf"])
Wrote 0x16afe0 bytes to file /root/ESPHome/esphome-jk-bms-can-1.17.4/.esphome/build/jk-bms-bat02/.pioenvs/jk-bms-bat02/firmware-factory.bin, ready to flash to offset 0x0
========================================================================================= [SUCCESS] Took 39.09 seconds =========================================================================================
INFO Successfully compiled program.
Found multiple options for uploading, please choose one:
  [1] /dev/ttyACM0 (USB JTAG/serial debug unit)
  [2] Over The Air (jk-bms-bat02.solar.stefano.home)

The "fix" was to set:
YAML:
esp32:
  board: {{board}}
  variant: {{variant}}
  framework:
    type: esp-idf
    version: latest

Let it fail with esp-idf framework 3.50102.240122, then roll back to
YAML:
esp32:
  board: {{board}}
  variant: {{variant}}
  framework:
    type: esp-idf

Build again.

Then it succeeds for some weird reason.
Perhaps you needed to build clean files, but worked around it with that approach?
 
where did you got the info that esp-idf does not support ota?
Im using both on all of my devices and it works out of the box without any problems and without any fancy or creepy stuff needed to be done.
In that page I linked, on the "web_server" component (https://esphome.io/components/web_server.html)
1711273494882.png

The web_server: ... ota: section apparently is NOT supported by the esp-idf framework.

The ota: section should be supported
YAML:
ota:
  safe_mode: true
  password: !secret ota_password
  on_begin:
    then:
      - lambda: id(enable_bluetooth_connection).turn_off();
      - logger.log: "BLE shutdown for flashing"


EDIT 1:
While this OTA part is NOT supported according to the docs:
YAML:
web_server:
  port: 80
  version: 2 # Version 1 displays as a table. Version 2 uses web components and has more functionality. Defaults to 2.
  log: true
  local: true # NOT SUPPORTED IN VERSION 1 - No internet/intranet required on the clients (all assets are inlined, compressed and served from flash)
  include_internal: true # Whether internal entities should be displayed on the web interface. Defaults to false
  #css_include: "v1/www.css"  # v1
  #css_url: ""                # v1
  #js_include: "v1/www.js"    # v1
  #js_url: ""                 # v1
  #css_include: ""             # v2
  css_url: ""                 # v2
  js_include: "v2/www.js"     # v2
  js_url: ""                  # v2
  ota: false                  # <------------------ This is NOT supported by the esp-idf framework according to ESPHome Documentation
  auth:
    username: !secret web_server_username
    password: !secret web_server_password
 
Right now I just enabled the OTA component. I will anyway need to modify /etc/hosts (GNU/Linux) since the DNS isn't really working at the moment.

I don't like too much that the OTA password is transmitted plaintext and no encryption/SSL/TLS takes places. Regardless if it's the ota: section, the ota_http: section or the webserver: section.

Granted I need to firewall down my garage (right now it's just doing ip_forwarding to my main LAN so I can access stuff). But security wise it's an absolute no-go.

EDIT 1: when trying to enable the webserver (mainly for debugging purposes), I am getting some errors:
Code:
...
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_esp_idf.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_libretiny.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_pico_w.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/application.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/component.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/component_iterator.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/controller.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/entity_base.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/helpers.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/log.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/ring_buffer.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/scheduler.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/string_ref.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/util.o
Compiling .pioenvs/jk-bms-bat02/src/main.o
Linking .pioenvs/jk-bms-bat02/firmware.elf
/root/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pioenvs/jk-bms-bat02/src/main.o:(.literal._Z5setupv+0xd38): undefined reference to `esphome::web_server::WebServer::WebServer(esphome::web_server_base::WebServerBase*)'
/root/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pioenvs/jk-bms-bat02/src/main.o: in function `setup()':
/root/ESPHome/esphome-jk-bms-can-1.17.4/.esphome/build/jk-bms-bat02/src/main.cpp:579: undefined reference to `esphome::web_server::WebServer::WebServer(esphome::web_server_base::WebServerBase*)'
collect2: error: ld returned 1 exit status
*** [.pioenvs/jk-bms-bat02/firmware.elf] Error 1
========================================================================================= [FAILED] Took 41.70 seconds =========================================================================================

YAML relevant section:
YAML:
web_server:
  port: 80
  version: 2 # Version 1 displays as a table. Version 2 uses web components and has more functionality. Defaults to 2.
  log: true
  local: true # No internet/intranet required on the clients (all assets are inlined, compressed and served from flash)
  include_internal: true # Whether internal entities should be displayed on the web interface. Defaults to false
  ota: false
  auth:
    username: !secret web_server_username
    password: !secret web_server_password
I´m using web_server too for debugging, but without log, OTA

This is the OTA component i´m talking about:

this is also in included on the GH repo and should work fine - if that does not work for your LAN setup, maybe consider using a fixed IP for the ESP would help - does your esps shows as online in the ESPhome dashboard?

regarding your compile error: Just clean the buildfiles and it will compile :)
 
Right now I just enabled the OTA component. I will anyway need to modify /etc/hosts (GNU/Linux) since the DNS isn't really working at the moment.

I don't like too much that the OTA password is transmitted plaintext and no encryption/SSL/TLS takes places. Regardless if it's the ota: section, the ota_http: section or the webserver: section.

Granted I need to firewall down my garage (right now it's just doing ip_forwarding to my main LAN so I can access stuff). But security wise it's an absolute no-go.

EDIT 1: when trying to enable the webserver (mainly for debugging purposes), I am getting some errors:
Code:
...
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_esp_idf.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_libretiny.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/wifi/wifi_component_pico_w.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/application.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/component.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/component_iterator.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/controller.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/entity_base.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/helpers.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/log.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/ring_buffer.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/scheduler.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/string_ref.o
Compiling .pioenvs/jk-bms-bat02/src/esphome/core/util.o
Compiling .pioenvs/jk-bms-bat02/src/main.o
Linking .pioenvs/jk-bms-bat02/firmware.elf
/root/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pioenvs/jk-bms-bat02/src/main.o:(.literal._Z5setupv+0xd38): undefined reference to `esphome::web_server::WebServer::WebServer(esphome::web_server_base::WebServerBase*)'
/root/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pioenvs/jk-bms-bat02/src/main.o: in function `setup()':
/root/ESPHome/esphome-jk-bms-can-1.17.4/.esphome/build/jk-bms-bat02/src/main.cpp:579: undefined reference to `esphome::web_server::WebServer::WebServer(esphome::web_server_base::WebServerBase*)'
collect2: error: ld returned 1 exit status
*** [.pioenvs/jk-bms-bat02/firmware.elf] Error 1
========================================================================================= [FAILED] Took 41.70 seconds =========================================================================================

YAML relevant section:
YAML:
web_server:
  port: 80
  version: 2 # Version 1 displays as a table. Version 2 uses web components and has more functionality. Defaults to 2.
  log: true
  local: true # No internet/intranet required on the clients (all assets are inlined, compressed and served from flash)
  include_internal: true # Whether internal entities should be displayed on the web interface. Defaults to false
  ota: false
  auth:
    username: !secret web_server_username
    password: !secret web_server_password
It might be not relating to yours writing but for my case with 3 devices in 3 different places, hundred of km away from each other, I have 2 options:
1. Using OTA with 2 options:
+ Using NAT (i.e 8266:public to 8266: internal) at the router of each site on 8266 or whatever port specified for the internal Esphome: This work for months already but requires a bit of configuring; Esphome device connect to HA via mqtt;
With this option I will have to use the use_address in the Wifi section. (use_address: [no ip dyn]);
+ using ota_http: a bit of problem to generate firmware (in legacy format), md5 hash and post to a webserver. I myself post it to my HA with additional web server installed via root ssh.
2. Using wireguard: installing wireguard is abit difficult but also worked!
Currently, I propose Olivier and his team to modify his ota_http to allow firmware update over the mqtt protocol (this can be best as it is easy and can be fully automated via the esphome's Install command) but they seems to be reluctantly to do so!

Regarding the improvement of charging, I am working on modifying Sleeper85 code (the old version) on 0x355 and 0x351 to simply focus on:
+ Create a script to handle the charging/discharging check using cell voltage (min/max) and check point set by user (such as 3.2 - 3.45) to start reducing charging current when max cell voltage is closing to 3.45 or OVP slider value set by user. Similarly will be applied for UVP. I prefer to use map() or PID to fine tune charging current.
+ On SOC reporting: stick to 99% (regardless JK SOC is 100 already) until 3.45 or max check point on OVP is reached. The same logic shall be applied while discharging: if voltage fall below 3.2 or checkpoint set by user while JK SOC is greater than the cutoff value for inverter, it will still set SOC to the cut off value to stop discharging. If SOC is fall below the Cutoff value but Cell minimum voltage is still greater than 3.2 or OVP value, it will report SOC of 1 point higher than the Cutoff value. By doing this, JK will reset its SOC to the nearly acceptable value.
Best
Ngoc
 
It might be not relating to yours writing but for my case with 3 devices in 3 different places, hundred of km away from each other, I have 2 options:
1. Using OTA with 2 options:
+ Using NAT (i.e 8266:public to 8266: internal) at the router of each site on 8266 or whatever port specified for the internal Esphome: This work for months already but requires a bit of configuring; Esphome device connect to HA via mqtt;
With this option I will have to use the use_address in the Wifi section. (use_address: [no ip dyn]);
+ using ota_http: a bit of problem to generate firmware (in legacy format), md5 hash and post to a webserver. I myself post it to my HA with additional web server installed via root ssh.
2. Using wireguard: installing wireguard is abit difficult but also worked!
Currently, I propose Olivier and his team to modify his ota_http to allow firmware update over the mqtt protocol (this can be best as it is easy and can be fully automated via the esphome's Install command) but they seems to be reluctantly to do so!

Regarding the improvement of charging, I am working on modifying Sleeper85 code (the old version) on 0x355 and 0x351 to simply focus on:
+ Create a script to handle the charging/discharging check using cell voltage (min/max) and check point set by user (such as 3.2 - 3.45) to start reducing charging current when max cell voltage is closing to 3.45 or OVP slider value set by user. Similarly will be applied for UVP. I prefer to use map() or PID to fine tune charging current.
+ On SOC reporting: stick to 99% (regardless JK SOC is 100 already) until 3.45 or max check point on OVP is reached. The same logic shall be applied while discharging: if voltage fall below 3.2 or checkpoint set by user while JK SOC is greater than the cutoff value for inverter, it will still set SOC to the cut off value to stop discharging. If SOC is fall below the Cutoff value but Cell minimum voltage is still greater than 3.2 or OVP value, it will report SOC of 1 point higher than the Cutoff value. By doing this, JK will reset its SOC to the nearly acceptable value.
Best
Ngoc

For your first modification about charging current, you can achieve the same result by setting
Current Curve Factor 1 - End of Curve = 4.00 or 5.00
Current Curve Factor 1 - Curve Shape = 1.80

1711274166275.png

For SOC reporting, it should be done similarly to what Victron Smartshunt behaves:
- Voltage > 55.2 V (or whatever bulk is set)
- Current < 0.5% or something like that (Tail current is very small)
- Time when both true: > 10 min or so

If these conditions are met, SOC shall be set to 100%.

About undervoltage and SOC reporting, be careful ... you don't want to report 0% all of a sudden just because you have a transient voltage drop due to a load step.
 
It was torqued properly with a Wrench and digital Torque scale/indicator, so torque value should be fine. That was done approx 6 months ago.

And I doubt I'd see anything at 10a-20a near the top of the curve. There just aren't *that* many losses at such low current.
if one terminal has a higher resistant, there will be burned more energy during the charging cycle at higher currents - and that energy is then missing on that cell - so i would suggest (just to be sure) checking the temps and torgue again. But maybe its just a bad cell there.

Torque wise, one thing that made me unhappy was that the studs were quite short, so I could only use the busbar + the provided flange nuts, not the proper flat washer + conical washer + nut as I would normally otherwise.
i hade the same problem on one pack i had to rework for a friend - i used some normal nuts which have only half of the hight from normal nuts to use washers and springwashers on top of the busbars - that worked out great so far :)

Overall your curves are really weird - wil have a look on your other thread the next days
 
if one terminal has a higher resistant, there will be burned more energy during the charging cycle at higher currents - and that energy is then missing on that cell - so i would suggest (just to be sure) checking the temps and torgue again. But maybe its just a bad cell there.


i hade the same problem on one pack i had to rework for a friend - i used some normal nuts which have only half of the hight from normal nuts to use washers and springwashers on top of the busbars - that worked out great so far :)

Overall your curves are really weird - wil have a look on your other thread the next days
I'm a bit skeptical but everything can be. I'm also human :ROFLMAO: .

- Terminals were properly cleaned with red scotchbrite
- Terminals were cleaned with isopropyl alcohol
- Applied generous amount of MG Chem 842 Graphite Conductive Paste
- Busbars were cleaned with isopropyl alcohol
- Torqued to the required torque setting (cannot remember now, these studs cannot take much, maybe was it 3.0Nm or 3.5Nm ???)

Agreed that the curves look very weird.

But what is the alternative ? That pack is in operation right now ... Worst, the two batteries are in the same enclosure so maintenance is an absolute nightmare.

Save a few EUR on the box, complicated everything else 🥴.

If it's a bad cell and it needs to be replaced, I think it's a whole battery transpant into the new battery v02 boxes (wooden boxes), with only one battery per box, and adding a NEEY active balancer + Victron Smartshunt on each battery.
 
It might be not relating to yours writing but for my case with 3 devices in 3 different places, hundred of km away from each other, I have 2 options:
1. Using OTA with 2 options:
+ Using NAT (i.e 8266:public to 8266: internal) at the router of each site on 8266 or whatever port specified for the internal Esphome: This work for months already but requires a bit of configuring; Esphome device connect to HA via mqtt;
With this option I will have to use the use_address in the Wifi section. (use_address: [no ip dyn]);
+ using ota_http: a bit of problem to generate firmware (in legacy format), md5 hash and post to a webserver. I myself post it to my HA with additional web server installed via root ssh.
2. Using wireguard: installing wireguard is abit difficult but also worked!
Currently, I propose Olivier and his team to modify his ota_http to allow firmware update over the mqtt protocol (this can be best as it is easy and can be fully automated via the esphome's Install command) but they seems to be reluctantly to do so!

Regarding the improvement of charging, I am working on modifying Sleeper85 code (the old version) on 0x355 and 0x351 to simply focus on:
+ Create a script to handle the charging/discharging check using cell voltage (min/max) and check point set by user (such as 3.2 - 3.45) to start reducing charging current when max cell voltage is closing to 3.45 or OVP slider value set by user. Similarly will be applied for UVP. I prefer to use map() or PID to fine tune charging current.
+ On SOC reporting: stick to 99% (regardless JK SOC is 100 already) until 3.45 or max check point on OVP is reached. The same logic shall be applied while discharging: if voltage fall below 3.2 or checkpoint set by user while JK SOC is greater than the cutoff value for inverter, it will still set SOC to the cut off value to stop discharging. If SOC is fall below the Cutoff value but Cell minimum voltage is still greater than 3.2 or OVP value, it will report SOC of 1 point higher than the Cutoff value. By doing this, JK will reset its SOC to the nearly acceptable value.
Best
Ngoc
About the OTA/NAT/Wireguard .... Couldn't you also simply have a OpenWRT / Turris / Custom router and do it from there ?

Like SSH/Wireguard into the router, then do the OTA from there to the ESP32 ?

Or you don't have access to that router and/or it's not an "open" one (cannot do advanced stuff) ?
 
I´m using web_server too for debugging, but without log, OTA

This is the OTA component i´m talking about:

this is also in included on the GH repo and should work fine - if that does not work for your LAN setup, maybe consider using a fixed IP for the ESP would help - does your esps shows as online in the ESPhome dashboard?

regarding your compile error: Just clean the buildfiles and it will compile :)
I updated my script to ask the user, at the end, in case of errors, if he wants to clean + try again.
Thanks for the suggestion.
Here is the updated file:

(lines 75-81)

Bash:
# Manage errors & try again
echo -e "In case of errors, it is suggested to run: esphome clean.\n"
read -p "Do you want to clean the build files & try build again: [Y/N] " tryagain
echo -e "\n"

# Clean build files and try again ?
if [ "$tryagain" == "Y" ] || [ "$tryagain" == "y" ]
then
   # Run clean & try again"
   esphome clean $esphomeconfig
   esphome run $esphomeconfig
fi
 
By the way, where (if anything) do you put the included CAN Termination Resistor that is delivered together with the M5Stack CANBus Unit (CA-IS3050G) / SKU: U085 ?
 
By the way, where (if anything) do you put the included CAN Termination Resistor that is delivered together with the M5Stack CANBus Unit (CA-IS3050G) / SKU: U085 ?
As it's a bus with the inverter at one end, ESP32 at the other (for now at least), put the 120ohm resistor across the high and low on the ESP32.

That will properly terminate the bus, reducing errors.
 
About the OTA/NAT/Wireguard .... Couldn't you also simply have a OpenWRT / Turris / Custom router and do it from there ?

Like SSH/Wireguard into the router, then do the OTA from there to the ESP32 ?

Or you don't have access to that router and/or it's not an "open" one (cannot do advanced stuff) ?
They are all ISP routers and they only support NAT. Anyway, this trick is still worked for now! no worry Silverstone. I only run 6 of inverter in places and they are connected to my HA at my home. What I am trying to achieve is getting the high capacity battery be charge properly and I found Sleeper85 yaml (the old version) is mostly acceptable to the moment with little modification comparing to Uksa007 or someone else. And I decided to stop here to focus on the approach that Sleeper85, Mr.Pablo and other is talking on this topic to help it better fitting our needs!
 
As it's a bus with the inverter at one end, ESP32 at the other (for now at least), put the 120ohm resistor across the high and low on the ESP32.

That will properly terminate the bus, reducing errors.
Alright, thanks. I was wondering the ESP32 had its own integrated already and the resistor was for the Deye :ROFLMAO: .
 
Back
Top