diy solar

diy solar

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

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.
In my case i use esp32-s2 lolin and a tja1050 and it worked smoothly with deye and luxpower without even the 120 Ohm resister. I made prototype and have them work stably in 5 locations for 2 months by now!
1711276930415.png1711276964270.png
 
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!
My suggestion would be to work together, so if you do a fork, submit a pull request so that everybody can benefit (y).

And its also easier for you, instead of always backporting features etc.
 
My suggestion would be to work together, so if you do a fork, submit a pull request so that everybody can benefit (y).

And its also easier for you, instead of always backporting features etc.
Yeah, I will do for sure! because the fork version based on Sleeper85 version posted in Jan and now I come back and discovered a lot of changes. This make I feel a bit of worrying (however, 2 days ago, i build a test device for my 100Ah battery and would like to report the result)! And currently keep working on my own first to test before sharing back to Sleeper85 and Pablo for not annoying them and others! This also the reason for me to raise some points of experience from our community (those are mostly benefited from open forum like this and keep applying into our owned work!)
Many thanks for your advise then!
Best
 
@MrPablo: not sure if it's a bug/feature of the Spreadsheet, but also trying the reverse case (all cells below 3.45V, one sitting even lower), the charge voltage gets REDUCED for the lower cell ...

1711277896167.png

So the charge voltage logic needs to be reviewed carefully in my opinion.

If possible, please let me know if this is an assumption of the spreadsheet or a real issue in the code (y) .
 
@MrPablo: not sure if it's a bug/feature of the Spreadsheet, but also trying the reverse case (all cells below 3.45V, one sitting even lower), the charge voltage gets REDUCED for the lower cell ...

View attachment 204156

So the charge voltage logic needs to be reviewed carefully in my opinion.

If possible, please let me know if this is an assumption of the spreadsheet or a real issue in the code (y) .
The logic of the code means it will proportionally disregard a cell that is lower than the majority of cells.
If you were to add the 'missing' 50mv to the requested CVL, that additional voltage is unlikely to boost the lagging cell. Instead, it's likely that it'll push a higher cell more, potentially exceeding target voltage.

The knee effect is why we can't just sum up the cell difference to target voltage, then add that on top of actual battery voltage.

I think we've already established that this logic is going to be rewritten, but this is expected behaviour in it's current state.

In an ideal world, we'd be running a balance charger where each cell is individually charged, making true per cell management possible.
 
Concerning Current Charge Control, I set it very aggressive to 6.0 even ... that way nothing should be pushed into the battery above 3.45 V

Let's see ... Right now I have battery at 65% but not much sun, mostly clouds, so it's actually getting DISCHARGED :ROFLMAO: .


1711279274556.png
 
The logic of the code means it will proportionally disregard a cell that is lower than the majority of cells.
If you were to add the 'missing' 50mv to the requested CVL, that additional voltage is unlikely to boost the lagging cell. Instead, it's likely that it'll push a higher cell more, potentially exceeding target voltage.

The knee effect is why we can't just sum up the cell difference to target voltage, then add that on top of actual battery voltage.

I think we've already established that this logic is going to be rewritten, but this is expected behaviour in it's current state.
No, you have a fair point (y). The higher cells will likely rise before the lower one can catch up, that's also what I could observe.
 
Damn .. When I am (almost) ready to do some testing, the sun is not shining and the battery is getting discharged :rolleyes:
 
Well I'll try to hook it up anyway. I think I'll leave the BMS_Err_Stop unchecked, as I don't really want my system to trip ...

1711280681882.png
 
@MrPablo : it doesn't appear to be working... Both BLE and Wi-Fi are not working at the moment. At least the Atom S3 Lite is not getting an IP from DHCP server. Only sign that it's on is the fact that the light on the CAN hat is illuminated

Considering this is very similar to syssi code it's definitively unexpected
 
it definitively doesn't say much in the logs. COMPLETELY DIFFERENT than ESP32 devices I am currently using with the syssi code.

With ESP32 it used to produce much more user friendly results. And In DEBUG mode it would list all WiFi networks available, status of the BLE connection, etc.

Not so with the Atom S3 Lite ...

Code:
INFO ESPHome 2024.3.0
INFO Reading configuration esp32-ble-1.17.4.yaml...
INFO Updating https://github.com/syssi/esphome-jk-bms.git@main
INFO Detected timezone 'Europe/Copenhagen'
INFO Generating C++ source...
INFO Compiling app...
Processing jk-bms-bat02 (board: esp32-s3-devkitc-1; framework: espidf; platform: platformio/espressif32@5.4.0)
---------------------------------------------------------------------------------------------------------------------------------------
HARDWARE: ESP32S3 240MHz, 320KB RAM, 8MB Flash
 - framework-espidf @ 3.40406.240122 (4.4.6)
 - tool-cmake @ 3.16.4
 - tool-ninja @ 1.7.1
 - toolchain-esp32ulp @ 2.35.0-20220830
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
 - toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5
Reading CMake configuration...
Dependency Graph
|-- ArduinoJson @ 6.18.5
Compiling .pioenvs/jk-bms-bat02/src/main.o
Linking .pioenvs/jk-bms-bat02/firmware.elf
RAM:   [==        ]  16.3% (used 53552 bytes from 327680 bytes)
Flash: [========  ]  81.5% (used 1495461 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 0x17d310 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 70.01 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)
(number): 1
esptool.py v4.7.0
Serial port /dev/ttyACM0
Connecting...
Chip is ESP32-S3 (QFN56) (revision v0.2)
Features: WiFi, BLE, Embedded Flash 8MB (GD)
Crystal is 40MHz
MAC: 34:b7:da:54:d7:08
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 8MB
Flash will be erased from 0x00010000 to 0x0017dfff...
Flash will be erased from 0x00000000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00009000 to 0x0000afff...
Compressed 1495824 bytes to 940387...
Wrote 1495824 bytes (940387 compressed) at 0x00010000 in 9.8 seconds (effective 1224.1 kbit/s)...
Hash of data verified.
Warning: Image file at 0x0 is protected with a hash checksum, so not changing the flash size setting. Use the --flash_size=keep option instead of --flash_size=8MB in order to remove this warning, or use the --dont-append-digest option for the elf2image command in order to generate an image file without a hash checksum
Compressed 20912 bytes to 13093...
Wrote 20912 bytes (13093 compressed) at 0x00000000 in 0.3 seconds (effective 492.0 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 134...
Wrote 3072 bytes (134 compressed) at 0x00008000 in 0.0 seconds (effective 556.9 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 31...
Wrote 8192 bytes (31 compressed) at 0x00009000 in 0.1 seconds (effective 899.2 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyACM0 with baud rate 115200
[13:59:48]ESP-ROM:esp32s3-20210327
[13:59:48]Build:Mar 27 2021
[13:59:48]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:48]Saved PC:0x400454d5
[13:59:48]SPIWP:0xee
[13:59:48]mode:QIO, clock div:1
[13:59:48]load:0x3fce3808,len:0x1658
[13:59:48]ets_loader.c 78
[13:59:49]ESP-ROM:esp32s3-20210327
[13:59:49]Build:Mar 27 2021
[13:59:49]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:49]Saved PC:0x400454d5
[13:59:49]SPIWP:0xee
[13:59:49]mode:QIO, clock div:1
[13:59:49]load:0x3fce3808,len:0x1658
[13:59:49]ets_loader.c 78
[13:59:50]ESP-ROM:esp32s3-20210327
[13:59:50]Build:Mar 27 2021
[13:59:50]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:50]Saved PC:0x400454d5
[13:59:50]SPIWP:0xee
[13:59:50]mode:QIO, clock div:1
[13:59:50]load:0x3fce3808,len:0x1658
[13:59:50]ets_loader.c 78
[13:59:52]ESP-ROM:esp32s3-20210327
[13:59:52]Build:Mar 27 2021
[13:59:52]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:52]Saved PC:0x400454d5
[13:59:52]SPIWP:0xee
[13:59:52]mode:QIO, clock div:1
[13:59:52]load:0x3fce3808,len:0x1658
[13:59:52]ets_loader.c 78
[13:59:53]ESP-ROM:esp32s3-20210327
[13:59:53]Build:Mar 27 2021
[13:59:53]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:53]Saved PC:0x400454d5
[13:59:53]SPIWP:0xee
[13:59:53]mode:QIO, clock div:1
[13:59:53]load:0x3fce3808,len:0x1658
[13:59:53]ets_loader.c 78
[13:59:54]ESP-ROM:esp32s3-20210327
[13:59:54]Build:Mar 27 2021
[13:59:54]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:54]Saved PC:0x400454d5
[13:59:54]SPIWP:0xee
[13:59:54]mode:QIO, clock div:1
[13:59:54]load:0x3fce3808,len:0x1658
[13:59:54]ets_loader.c 78
[13:59:56]ESP-ROM:esp32s3-20210327
[13:59:56]Build:Mar 27 2021
[13:59:56]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:56]Saved PC:0x400454d5
[13:59:56]SPIWP:0xee
[13:59:56]mode:QIO, clock div:1
[13:59:56]load:0x3fce3808,len:0x1658
[13:59:56]ets_loader.c 78
[13:59:57]ESP-ROM:esp32s3-20210327
[13:59:57]Build:Mar 27 2021
[13:59:57]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:57]Saved PC:0x400454d5
[13:59:57]SPIWP:0xee
[13:59:57]mode:QIO, clock div:1
[13:59:57]load:0x3fce3808,len:0x1658
[13:59:57]ets_loader.c 78
[13:59:58]ESP-ROM:esp32s3-20210327
[13:59:58]Build:Mar 27 2021
[13:59:58]rst:0x7 (TG0WDT_SYS_RST),boot:0x28 (SPI_FAST_FLASH_BOOT)
[13:59:58]Saved PC:0x400454d5
[13:59:58]SPIWP:0xee
[13:59:58]mode:QIO, clock div:1
[13:59:58]load:0x3fce3808,len:0x1658
[13:59:58]ets_loader.c 78

EDIT: By the way, I am also getting this warning during compile. Are you also getting this ?
Code:
Compiling .pioenvs/jk-bms-bat02/src/esphome/components/jk_bms_ble/button/jk_button.o
src/esphome/components/esp32_can/esp32_can.cpp: In member function 'virtual esphome::canbus::Error esphome::esp32_can::ESP32Can::send_message(esphome::canbus::CanFrame*)':
src/esphome/components/esp32_can/esp32_can.cpp:114:3: warning: missing initializer for member 'twai_message_t::data' [-Wmissing-field-initializers]
   };
   ^
 
I don't personally run the S3 lite, but I know there's some ongoing discussion on GitHub at the below link:

As for the warning during compile, I've seen that since last year without issue.
 
I don't personally run the S3 lite, but I know there's some ongoing discussion on GitHub at the below link:

As for the warning during compile, I've seen that since last year without issue.
Alright thanks ... it seems each ESP32 variant had its quirks.

I added the following to the YAML file
YAML:
board_build.flash_mode: dio

I also included this in the YAML file, which was in one of the issues report from syssi code (for ESP32 in this case, not specifically S3):
YAML:
    build_flags:
      - -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768

EDIT: with BOTH these options, when attached to the PC, the boot process looks much similar to the ESP32 before with syssi code. Now I need to recompile with logger: level: INFO (logger: level: DEBUG causes periodic disconnects apparently). Not sure if BOTH options are really necessary. I also had added logger: hardware_uart: USB_SERIAL_JTAG, that I did NOT have with syssi code ...
 
Last edited:
Alright thanks ... it seems each ESP32 variant had its quirks.

I added the following to the YAML file
YAML:
board_build.flash_mode: dio

I also included this in the YAML file, which was in one of the issues report from syssi code (for ESP32 in this case, not specifically S3):
YAML:
    build_flags:
      - -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768

EDIT: with BOTH these options, when attached to the PC, the boot process looks much similar to the ESP32 before with syssi code. Now I need to recompile with logger: level: INFO (logger: level: DEBUG causes periodic disconnects apparently). Not sure if BOTH options are really necessary. I also had added logger: hardware_uart: USB_SERIAL_JTAG, that I did NOT have with syssi code ...

If you reference this file, you can see that USB_SERIAL_JTAG is required to make the S3 lite work correctly when using the wired connection to JK BMS.

The version under development will be more robust when dealing with the many hardware variations.
 

If you reference this file, you can see that USB_SERIAL_JTAG is required to make the S3 lite work correctly when using the wired connection to JK BMS.

The version under development will be more robust when dealing with the many hardware variations.
But I'm using BLE. So maybe it was required, maybe not.

Some weird stuff in Home Assistant though ...
1711287560883.png

I was expecting it to just replace syssi ESP32, but apparently it registered as a new device.

But the Battery is still associated with the old one ...

Do I need to change something on HA or on the MQTT broker to mark this change ?
 
Now I changed my Deye settings to Lithium 00 type (BMS_Err_Stop is NOT set). Didn't trip for now.

Master inverter is however NOT showing "Normal" anymore and Battery SOC is stuck at 100%.

IRC it was mentioned that it can take up to ~ 30 minutes for the CAN communication to be established, correct ?

EDIT 1: of course it's also possible that CAN_H and CAN_L are reversed on the RJ45 connector. I tried to follow the convention for pin 4 & pin 5 but you never know ...

EDIT 2: both the Inverter Charge Current and the BMC Charge Current are currently getting IGNORED. Inverter is still NOT back to "Normal" state. I tried to reduce the charge current on the BMS via the Webserver and it works (but has NO effect)
 
Last edited:
Couple of feature requests please.
1. Wired as well as wireless network connectivity.
2. Bluetooth, RS485, CAN, RS232 connectivity.
3. More than 1 BMS connected to a single ESP device either multiple RS/CAN devices on a bus or several signal converters into different pins on the ESP device.
4. Direct USB to RS/serial/CAN connections to HA unit.

OK sorry I got greedy. :)
 

Attachments

  • IMG_20230201_123721833.jpg
    IMG_20230201_123721833.jpg
    262.3 KB · Views: 6
Nice that the Deye by default goes "full power" even if no BMS communication occurs. Definitively NOT fail-safe.

1711289228788.png
1711289255493.png
 
I have just left the S3 setup alone for now until there is an official YAML file release for it....i too experienced the loop talked about and i don't think its HA as i can flash wireless and the module works as it should do.
 
Back
Top