[JK-PB RS485] Restarting after a few minutes (2min aprox), starting, and restarting again after a few minutes...

txubelaxu commented 3 weeks ago

Using 2 x JK-PB via RS485 (mode 2) Using Victron Cerbo GX + 2xMultiplus II (in parallel)

[20:38:30][I][canbus:717]: send can_id: 0x377 [ASCII] Max temperature sensor ID : 102
[20:38:30][I][canbus:718]: send can_id: 0x377 hex: 31 30 32 0 0 0 0 0
[20:38:30][D][canbus:035]: send standard id=0x377 rtr=FALSE size=8
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Errors Bitmask Alarm': Received new state 0.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Errors Bitmask Warning': Received new state 0.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 BMS in alarm': Received new state 0.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Total Voltage (Ø)': Received new state 53.080002
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Current (Σ)': Received new state -3.674000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Power (Σ)': Received new state -195.015823
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 SoC (Ø)': Received new state 86.500000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Capacity Remaining (Σ)': Received new state 525.609009
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Max Charge current (Σ)': Received new state 120.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Max Discharge Current (Σ)': Received new state 144.000015
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Charging Cycles (Ø)': Received new state 17.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Balance Trigger Voltage (MAX)': Received new state 0.005000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Min Cell Voltage': Received new state 3.316000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Min Voltage Cell': Received new state 111.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Max Cell Voltage': Received new state 3.319000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Max Voltage Cell': Received new state 202.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Cell OVP (MIN)': Received new state 3.610000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Cell OVPR (MIN)': Received new state 3.448000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Cell UVPR (MAX)': Received new state 2.650000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Min temperature': Received new state 25.300001
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Min temperature sensor': Received new state 201.000000
[20:38:30][V][sensor:043]: 'yambms Smart BMS 1 Max temperature': Received new state 25.800001
WARNING yambms @ 172.26.1.217: Connection error occurred: [Errno 104] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for yambms @ 172.26.1.217

txubelaxu commented 3 weeks ago

[20:44:02][D][sensor:094]: 'esp32_uptime_sec': Sending state 117.40500 s with 0 decimals of accuracy
[20:44:02][D][jk_rs485_sniffer:522]: ..........................................
[20:44:02][V][jk_rs485_sniffer:526]: Buffer before number 1:    55.AA.EB.90.02.05.F6.0C.F6.0C.F5.0C.F4.0C.F5.0C.F5.0C.F4.0C.F5.0C.F6.0C.F6.0C.F6.0C.F6.0C.F6.0C.F5.0C.F5.0C.F4.0C.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.FF.FF.00.00.F5.0C.02.00.00.0F.51.00.4E.00.50.00.4B.00.4C.00.4E.00.51.00.5B.00.5E.00.4A.00.4D.00.4A.00.4D.00.4D.00.53.00.52.00.00.00.00.00.00.00.00.00 (120)
[20:44:02][V][jk_rs485_sniffer:528]: Response:            5:
[20:44:02][D][jk_rs485_sniffer:522]: ..........................................
[20:44:02][V][jk_rs485_sniffer:526]: Buffer before number 1:    55.AA.EB.90.02.05.F6.0C.F6.0C.F5.0C.F4.0C.F5.0C.F5.0C.F4.0C.F5.0C.F6.0C.F6.0C.F6.0C.F6.0C.F6.0C.F5.0C.F5.0C.F4.0C.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.FF.FF.00.00.F5.0C.02.00.00.0F.51.00.4E.00.50.00.4B.00.4C.00.4E.00.51.00.5B.00.5E.00.4A.00.4D.00.4A.00.4D.00.4D.00.53.00.52.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.06.01.00.00.00.00.52.CF.00.00.4B.7E.01.00.CC.F8.FF.FF.FE.00.01.01.00.00.00.00.00.00.00.57.BB.07.04.00.80.A3.04.00.10.00.00.00.50.26.4D.00.64.00.00.00.EB.B0.95.01.01.01.00.00.00.00.00.00.00.00.00.00.00.00.00.00.FF.00.01.00.00.00.9A.03.00.00.05.00.60.54.3F.40.00.00.00.00.BB.14.00.00.00.01.01.01.00.06.00.00.50.43.04.00.00.00.00.00.06.01.FD.00.07.01.9A.03.D8.01.1C.09.BB.00.00.00.80.51.01.00.00.00.00.00.00.00.00.00.00.00.00.00.00.FE.FF.7F.DD.2F.01.01.B0.07.00.00.00.BE.01.10.16.20.00.01.04.4B (308)
[20:44:02][D][jk_rs485_sniffer:797]: ###############################Sequence found SIZE: 308
[20:44:02][D][jk_rs485_sniffer:856]: Frame received from SLAVE (type: 0x02, 309 bytes) 01 address
[20:44:02][D][jk_rs485_bms:527]: This BMS address is: 1  and address received 1 ==> WORKING (frame type:2)
[20:44:02][I][jk_rs485_bms:575]: Decoding cell info frame.... [ADDRESS: 01] 309 bytes received
[20:44:02][V][sensor:043]: 'yambms JK-BMS-1 cell voltage 01': Received new state 3.318000
[20:44:02][D][sensor:094]: 'yambms JK-BMS-1 cell voltage 01': Sending state 3.31800 V with 3 decimals of accuracy
[20:44:02][V][sensor:043]: 'yambms JK-BMS-1 cell resistance 01': Received new state 0.081000
[20:44:02][D][sensor:094]: 'yambms JK-BMS-1 cell resistance 01': Sending state 0.08100 Ω with 3 decimals of accuracy
[20:44:02][V][sensor:043]: 'yambms JK-BMS-1 cell voltage 02': Received new state 3.318000
[20:44:02][D][sensor:094]: 'yambms JK-BMS-1 cell voltage 02': Sending state 3.31800 V with 3 decimals of accuracy
[20:44:02][V][sensor:043]: 'yambms JK-BMS-1 cell resistance 02': Received new state 0.078000
[20:44:02][D][sensor:094]: 'yambms JK-BMS-1 cell resistance 02': Sending state 0.07800 Ω with 3 decimals of accuracy
WARNING yambms @ 172.26.1.217: Connection error occurred: [Errno 104] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for yambms @ 172.26.1.217
WARNING Disconnected from API
^CWARNING Can't connect to ESPHome API for yambms @ 172.26.1.217: Error while starting connection: Starting connection cancelled (APIConnectionCancelledError)
INFO Trying to connect to yambms @ 172.26.1.217 in the background

txubelaxu commented 3 weeks ago

Another issue(?) is that CCL=0.0A ??

txubelaxu commented 3 weeks ago

[21:04:47][V][text_sensor:013]: 'yambms Smart BMS 1 Alarm': Received new state NoAlarm
[21:04:47][D][text_sensor:064]: 'yambms Smart BMS 1 Alarm': Sending state 'NoAlarm'
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 Battery SoC': Received new state 86.000000
[21:04:47][I][canbus:646]: send can_id: 0x373 hex: f6 c f9 c 2a 1 2a 1
[21:04:47][D][canbus:035]: send standard id=0x373 rtr=FALSE size=8
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 Installed Battery Capacity (Σ)': Received new state 608.000000
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 Cell Count (Σ)': Received new state 32.000000
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 Shunt count': Received new state 0.000000
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 Battery SoH': Received new state 100.000000
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 Requested Discharge Current': Received new state 50.900002
[21:04:47][V][sensor:043]: 'yambms Smart BMS 1 BMS count': Received new state 2.000000
[21:04:47][I][jk_rs485_sniffer:461]: POOLING NEXT AVAILABLE... [address:0x01] @ 2 [2252,12017,5666]
[21:04:47][V][jk_rs485_sniffer:346]: MESSAGE REQUEST TO SEND>>: 01.10.16.20.00.01.02.00.00.D6.F1 (11)
[21:04:47][I][canbus:663]: send can_id: 0x374 [ASCII] Min cell voltage ID : 116
[21:04:47][I][canbus:664]: send can_id: 0x374 hex: 31 31 36 0 0 0 0 0
WARNING yambms @ 172.26.1.217: Connection error occurred: [Errno 104] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for yambms @ 172.26.1.217
WARNING Disconnected from API
INFO Successfully connected to yambms @ 172.26.1.217 in 0.466s
INFO Successful handshake with yambms @ 172.26.1.217 in 0.018s

txubelaxu commented 3 weeks ago

I have moved back again to jk-bms-can v1.4.2 I have been making a lot of tests but cannot move to yambms version. I do not know why, but it is more stable for me.

Sleeper85 commented 3 weeks ago

Seems to be a problem between your ESP32 and Home Assistant (API).

I have YamBMS 1.4.5 users with Victron and it's been stable for almost 1 month without reboot.

goldserve commented 3 weeks ago

@txubelaxu Can you get some serial logs and not logs via HA and ip? What features are enabled in your config. Can you post it up?

txubelaxu commented 3 weeks ago

Thanks for your fast answer. The problem appears at esphome::jk_rs485_bms::JkRS485Bms::publishstate(esphome::sensor::Sensor*, float) at esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_bms/jk_rs485_bms.cpp:1603

So, the problem is here:

void JkRS485Bms::publish_state_(sensor::Sensor *sensor, float value) {
  if (sensor == nullptr)
    return;

  sensor->publish_state(value);
}

I do not why this error is appearing now and not before. I am debugging now.

I have some logs:

[09:42:40]
[09:42:47][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (63 ms).
[09:42:47][W][component:238]: Components should block for at most 30 ms.
[09:42:48][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (58 ms).
[09:42:48][W][component:238]: Components should block for at most 30 ms.
[09:42:49]Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.
[09:42:49]
[09:42:49]Core  1 register dump:
[09:42:49]PC      : 0x4201519e  PS      : 0x00060c30  A0      : 0x8200c480  A1      : 0x3fcf6aa0  
WARNING Decoded 0x4201519e: esphome::sensor::Sensor::publish_state(float) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/sensor/sensor.cpp:40
[09:42:49]A2      : 0x0001450c  A3      : 0x4054ed92  A4      : 0x00000000  A5      : 0x00000000  
[09:42:49]A6      : 0x00000001  A7      : 0x3fc9e5c8  A8      : 0x820151cd  A9      : 0x3fcf6a70  
[09:42:49]A10     : 0x3fcceb48  A11     : 0x3fcceb48  A12     : 0x9f800000  A13     : 0x53bf0000  
[09:42:49]A14     : 0x00001800  A15     : 0x00004003  SAR     : 0x0000001d  EXCCAUSE: 0x0000001d  
[09:42:49]EXCVADDR: 0x00014534  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0xffffffff  
[09:42:49]
[09:42:49]
[09:42:49]Backtrace: 0x4201519b:0x3fcf6aa0 0x4200c47d:0x3fcf6ad0 0x4200d388:0x3fcf6af0 0x4200dec6:0x3fcf6b60 0x4200defd:0x3fcf6b80 0x4200ebb5:0x3fcf6ba0 0x4200ec94:0x3fcf6bd0 0x4200edc2:0x3fcf6c00 0x420c5d3d:0x3fcf6c20 0x420c5dd9:0x3fcf6c40 0x4201b281:0x3fcf6c60 0x4201fec2:0x3fcf6c90 0x4200a82e:0x3fcf6cb0
WARNING Found stack trace! Trying to decode it
WARNING Decoded 0x4201519b: esphome::sensor::Sensor::publish_state(float) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/sensor/sensor.cpp:39
WARNING Decoded 0x4200c47d: esphome::jk_rs485_bms::JkRS485Bms::publish_state_(esphome::sensor::Sensor*, float) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_bms/jk_rs485_bms.cpp:1603
WARNING Decoded 0x4200d388: esphome::jk_rs485_bms::JkRS485Bms::decode_jk02_cell_info_(std::vector<unsigned char, std::allocator<unsigned char> > const&) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_bms/jk_rs485_bms.cpp:651 (discriminator 2)
WARNING Decoded 0x4200dec6: esphome::jk_rs485_bms::JkRS485Bms::on_jk_rs485_sniffer_data(unsigned char const&, unsigned char const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_bms/jk_rs485_bms.cpp:540
 (inlined by) esphome::jk_rs485_bms::JkRS485Bms::on_jk_rs485_sniffer_data(unsigned char const&, unsigned char const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_bms/jk_rs485_bms.cpp:513
WARNING Decoded 0x4200defd: non-virtual thunk to esphome::jk_rs485_bms::JkRS485Bms::on_jk_rs485_sniffer_data(unsigned char const&, unsigned char const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
WARNING Decoded 0x4200ebb5: esphome::jk_rs485_sniffer::JkRS485Sniffer::manage_rx_buffer_() at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_sniffer/jk_rs485_sniffer.cpp:861 (discriminator 2)
WARNING Decoded 0x4200ec94: esphome::jk_rs485_sniffer::JkRS485Sniffer::loop() at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/jk_rs485_sniffer/jk_rs485_sniffer.cpp:527
WARNING Decoded 0x4200edc2: non-virtual thunk to esphome::jk_rs485_sniffer::JkRS485Sniffer::loop()
WARNING Decoded 0x420c5d3d: esphome::Component::call_loop() at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/core/component.cpp:77
WARNING Decoded 0x420c5dd9: esphome::Component::call() at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/core/component.cpp:104
WARNING Decoded 0x4201b281: esphome::Application::loop() at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/core/application.cpp:74 (discriminator 2)
WARNING Decoded 0x4201fec2: loop() at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/packages/yambms/yambms.yaml:794
WARNING Decoded 0x4200a82e: esphome::loop_task(void*) at /home/github/txubelaxu/20241016/esphome-yambms/.esphome/build/yambms/src/esphome/components/esp32/core.cpp:69 (discriminator 1)
[09:42:50]
[09:42:50]
[09:42:50]
[09:42:50]
[09:42:50]ELF file SHA256: 3b633c489b54fe75
[09:42:50]
[09:42:50]Rebooting...
[09:42:50]ESP-ROM:esp32s3-20210327
[09:42:50]Build:Mar 27 2021
[09:42:50]rst:0xc (RTC_SW_CPU_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)
[09:42:50]Saved PC:0x4003b6bd
[09:42:50]SPIWP:0xee
[09:42:50]mode:DIO, clock div:1
[09:42:50]load:0x3fce3808,len:0x16c4
[09:42:50]load:0x403c9700,len:0xbc0
[09:42:50]load:0x403cc700,len:0x2e90
[09:42:50]entry 0x403c9950
[09:42:50]I (24) boot: ESP-IDF 4.4.8 2nd stage bootloader
[09:42:50]I (24) boot: compile time 09:36:12
[09:42:50]I (24) boot: Multicore bootloader
[09:42:50]I (26) boot: chip revision: v0.2
[09:42:50]I (30) boot.esp32s3: Boot SPI Speed : 80MHz
[09:42:50]I (35) boot.esp32s3: SPI Mode       : DIO
[09:42:50]I (39) boot.esp32s3: SPI Flash Size : 16MB
[09:42:50]I (44) boot: Enabling RNG early entropy source...
[09:42:50]I (50) boot: Partition Table:
[09:42:50]I (53) boot: ## Label            Usage          Type ST Offset   Length
[09:42:50]I (60) boot:  0 otadata          OTA data         01 00 00009000 00002000
[09:42:50]I (68) boot:  1 phy_init         RF data          01 01 0000b000 00001000
[09:42:50]I (75) boot:  2 app0             OTA app          00 10 00010000 007c0000
[09:42:50]I (83) boot:  3 app1             OTA app          00 11 007d0000 007c0000
[09:42:50]I (90) boot:  4 nvs              WiFi data        01 02 00f90000 0006d000
[09:42:50]I (98) boot: End of partition table
[09:42:50]I (102) esp_image: segment 0: paddr=00010020 vaddr=3c0d0020 size=2f1b4h (192948) map
[09:42:50]I (145) esp_image: segment 1: paddr=0003f1dc vaddr=3fc98d40 size=00e3ch (  3644) load
[09:42:50]I (146) esp_image: segment 2: paddr=00040020 vaddr=42000020 size=cb850h (833616) map
[09:42:50]I (301) esp_image: segment 3: paddr=0010b878 vaddr=3fc99b7c size=032ach ( 12972) load
[09:42:50]I (304) esp_image: segment 4: paddr=0010eb2c vaddr=40374000 size=14d40h ( 85312) load
[09:42:50]I (334) boot: Loaded app from partition at offset 0x10000
[09:42:50]I (334) boot: Disabling RNG early entropy source...
[09:42:50]I (335) cpu_start: Multicore app
[09:42:50]I (338) opi psram: vendor id : 0x0d (AP)
[09:42:50]I (343) opi psram: dev id    : 0x02 (generation 3)
[09:42:50]I (348) opi psram: density   : 0x03 (64 Mbit)
[09:42:50]I (353) opi psram: good-die  : 0x01 (Pass)
[09:42:50]I (358) opi psram: Latency   : 0x01 (Fixed)
[09:42:50]I (363) opi psram: VCC       : 0x01 (3V)
[09:42:50]I (367) opi psram: SRF       : 0x01 (Fast Refresh)
[09:42:50]I (373) opi psram: BurstType : 0x01 (Hybrid Wrap)
[09:42:50]I (378) opi psram: BurstLen  : 0x01 (32 Byte)
[09:42:50]I (383) opi psram: Readlatency  : 0x02 (10 cycles@Fixed)
[09:42:50]I (389) opi psram: DriveStrength: 0x00 (1/1)
[09:42:50]I (395) MSPI Timing: PSRAM timing tuning index: 5
[09:42:50]I (400) spiram: Found 64MBit SPI RAM device
[09:42:50]I (404) spiram: SPI RAM mode: sram 80m
[09:42:50]I (409) spiram: PSRAM initialized, cache is in normal (1-core) mode.
[09:42:50]I (416) cpu_start: Pro cpu up.
[09:42:50]I (420) cpu_start: Starting app cpu, entry point is 0x40377054
[09:42:50]I (408) cpu_start: App cpu up.
[09:42:50]I (852) spiram: SPI SRAM memory test OK
[09:42:50]I (861) cpu_start: Pro cpu start user code
[09:42:50]I (861) cpu_start: cpu freq: 160000000
[09:42:50]I (861) cpu_start: Application information:
[09:42:50]I (862) cpu_start: Project name:     yambms
[09:42:50]I (862) cpu_start: App version:      2024.10.0
[09:42:50]I (862) cpu_start: Compile time:     Nov  4 2024 09:33:31
[09:42:50]I (862) cpu_start: ELF file SHA256:  3b633c489b54fe75...
[09:42:50]I (863) cpu_start: ESP-IDF:          4.4.8
[09:42:50]I (863) cpu_start: Min chip rev:     v0.0
[09:42:50]I (863) cpu_start: Max chip rev:     v0.99 
[09:42:50]I (863) cpu_start: Chip rev:         v0.2
[09:42:50]I (863) heap_init: Initializing. RAM available for dynamic allocation:
[09:42:50]I (864) heap_init: At 3FCA1EF8 len 00047818 (286 KiB): D/IRAM
[09:42:50]I (864) heap_init: At 3FCE9710 len 00005724 (21 KiB): STACK/DIRAM
[09:42:50]I (864) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
[09:42:50]I (865) heap_init: At 600FE000 len 00002000 (8 KiB): RTCRAM
[09:42:50]I (865) spiram: Adding pool of 8192K of external SPI memory to heap allocator
[09:42:50]I (866) spi_flash: detected chip: generic
[09:42:50]I (866) spi_flash: flash io: dio
[09:42:50]I (867) sleep: Configure to isolate all GPIO pins in sleep state
[09:42:50]I (868) sleep: Enable automatic switching of GPIO sleep configuration
[09:42:50]I (868) cpu_start: Starting scheduler on PRO CPU.
[09:42:50]I (0) cpu_start: Starting scheduler on APP CPU.

Sleeper85 commented 3 weeks ago

@txubelaxu

A user reported this problem to me last week and I wasn't sure if it was normal or not because I don't have a JK-PB...

I have 2 JK-PB connected by RS485 served on ESP32.
I got often jk_rs485_sniffer and interval runtimes longer than 30ms, e.g.:
[16:18:13][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (816 ms).
[16:18:14][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (818 ms).
[16:18:15][W][component:237]: Component interval took a long time for an operation (278 ms).
[16:18:16][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (337 ms).
[16:18:17][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (336 ms).
[16:18:19][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (830 ms).
[16:18:21][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (829 ms).
[16:18:25][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (778 ms).
[16:18:25][W][component:237]: Component interval took a long time for an operation (286 ms).
[16:18:28][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (778 ms).
[16:18:29][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (304 ms).
[16:18:30][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (304 ms).
[16:18:32][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (768 ms).
[16:18:34][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (769 ms).
[16:18:36][W][component:237]: Component interval took a long time for an operation (240 ms).
[16:18:39][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (769 ms).

txubelaxu commented 3 weeks ago

@txubelaxu

A user reported this problem to me last week and I wasn't sure if it was normal or not because I don't have a JK-PB...

I have 2 JK-PB connected by RS485 served on ESP32.
I got often jk_rs485_sniffer and interval runtimes longer than 30ms, e.g.:
[16:18:13][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (816 ms).
[16:18:14][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (818 ms).
[16:18:15][W][component:237]: Component interval took a long time for an operation (278 ms).
[16:18:16][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (337 ms).
[16:18:17][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (336 ms).
[16:18:19][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (830 ms).
[16:18:21][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (829 ms).
[16:18:25][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (778 ms).
[16:18:25][W][component:237]: Component interval took a long time for an operation (286 ms).
[16:18:28][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (778 ms).
[16:18:29][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (304 ms).
[16:18:30][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (304 ms).
[16:18:32][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (768 ms).
[16:18:34][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (769 ms).
[16:18:36][W][component:237]: Component interval took a long time for an operation (240 ms).
[16:18:39][W][component:237]: Component jk_rs485_sniffer took a long time for an operation (769 ms).

well... the code should be optimized, of course, but I do not think it should be a very important problem. Do those times cause a problem in the system behaviour?

txubelaxu commented 3 weeks ago

The features enabled in my config are the same in yambms and jk-bms-can config:

# Updated : 2024.10.03
# Version : 1.4.5
# GitHub  : https://github.com/Sleeper85/esphome-yambms

# YamBMS ( Yet another multi-BMS Merging Solution ) v. Txubelaxu

# This YAML is free software: you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation, either version 3
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/gpl.html>.

substitutions:
  name: yambms

# Don't forget to configure your WiFi credentials in the secrets.yaml file
#
# If needed, configure a static IP here
# wifi:
#   manual_ip:
#     static_ip: 192.168.0.85
#     gateway: 192.168.0.1
#     subnet: 255.255.255.0
#     dns1: 8.8.8.8
#     dns2: 8.8.4.4

logger:
  level: DEBUG #WARN  # VERBOSE # DEBUG / INFO / WARN
  #tx_buffer_size: 1024

ota:
  platform: esphome

# Please use the native `api` component instead of the `mqtt` section.
# If you use Home Assistant, the native API is more lightweight.
# If there is no HA server connected to this API, the ESP32 reboots every 15 minutes to try to resolve the problem.
# If you don't use Home Assistant please uncomment the "reboot_timeout: 0s" option.
api:
  reboot_timeout: 0s

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  domain: !secret domain

captive_portal:

# If you don't want to use ESPHome's native API you can use MQTT instead.
# In this case don't forget to remove the 'api:' section.
# mqtt:
#  broker: !secret mqtt_host
#  username: !secret mqtt_username
#  password: !secret mqtt_password
#  id: mqtt_client

# Please note that enabling this component will take up a lot of memory and may decrease
# stability and be the cause of reboot depending on the capabilities of the board used.
#web_server:
#  port: 80
#  log: false
#  ota: false
##web_server:
##  local: true
##  port: 80
##  auth:
##     username: !secret web_server_user
##     password: !secret web_server_password

# +--------------------------------------+
# | Packages                             |
# +--------------------------------------+
packages:
  # Board : uncomment your board
  # device_board: !include packages/board/board_esp32-devkit-v1.yaml
  # device_board: !include packages/board/board_esp32-s3-devkitc-1.yaml
  device_board: !include packages/board/board_esp32-s3-devkitc-1.yaml

  # device_board: !include
  #   file: packages/board/board_atom-s3-display.yaml
  #   vars:
  #     yambms_id: 'yambms1'
  #     canbus_id: 'canbus1'

  device_base: !include packages/base/device_base.yaml

#  shunt1: !include
#     file: packages/shunt/shunt_victron_smartshunt.yaml # shunt_junctek_khf.yaml
#     vars:
#       # YamBMS ID
#       yambms_id: 'yambms1'
#       # Shunt vars
#       shunt_id: '1' # must be a number
#       shunt_name: 'Shunt 1'
#       shunt_update_interval: '3s'
#       shunt_combine_interval: '1s'
#       shunt_uart_id: uart_esp_0

  # The sniffer represents the ESP node connected to the JK-BMS PB RS485 bus
  # If address 0x00 is not detected on the RS485 bus, the sniffer will act directly as a master BMS (mode 2, max 15 BMS)

  # sniffer1: !include
  #   file: packages/bms/bms_JK-PB_RS485_sniffer_talk_pin.yaml
  #   vars:
  #     sniffer_id: 'sniffer1'
  #     sniffer_protocol: 'JK02_32S'
  #     sniffer_uart_id: 'uart_esp_1'
  #     sniffer_talk_pin: 8 # ESP32: 4, ESP32-S3: 8, ESP32-C3: 10

  # The sniffer represents the ESP node connected to the JK-BMS PB RS485 bus
  # If address 0x00 is not detected on the RS485 bus, the sniffer will act directly as a master BMS (mode 2, max 15 BMS)
  sniffer1: !include
    file: packages/bms/bms_JK-PB_RS485_sniffer_talk_pin.yaml     #packages/bms/bms_JK-PB_RS485_sniffer.yaml
    vars:
      sniffer_id: 'sniffer1'
      sniffer_protocol: 'JK02_32S'
      sniffer_uart_id: 'uart_esp_1'
      sniffer_talk_pin: GPIO4 ##8 # ESP32: 4, ESP32-S3: 8, ESP32-C3: 10

  # Mode2 : configure the DIP switches of your BMS from 0x01 to 0x0F (don't use the 0x00 address, maximum 15 BMS)
  bms1: !include
    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
    vars:
      # YamBMS ID
      yambms_id: 'yambms1'
      # Sniffer ID
      sniffer_id: 'sniffer1'
      # BMS vars
      bms_id: '1' # must be a number
      bms_name: 'JK-BMS-1'
      bms_rs485_address: '0x01' # BMS 1 DIP switch
      bms_update_interval: '3s' # going below '3s' can cause problems
      bms_combine_interval: '1s'

  bms2: !include
    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
    vars:
      # YamBMS ID
      yambms_id: 'yambms1'
      # Sniffer ID
      sniffer_id: 'sniffer1'
      # BMS vars
      bms_id: '2' # must be a number
      bms_name: 'JK-BMS-2'
      bms_rs485_address: '0x02' # BMS 2 DIP switch
      bms_update_interval: '3s' # going below '3s' can cause problems
      bms_combine_interval: '1s'

#  bms3: !include
#    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
#    vars:
#      # YamBMS ID
#      yambms_id: 'yambms1'
#      # Sniffer ID
#      sniffer_id: 'sniffer1'
#      # BMS vars
#      bms_id: '3' # must be a number
#      bms_name: 'JK-BMS 3'
#      bms_rs485_address: '0x03' # BMS 3 DIP switch
#      bms_update_interval: '3s' # going below '3s' can cause problems
#      bms_combine_interval: '1s'
#
#  bms4: !include
#    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
#    vars:
#      # YamBMS ID
#      yambms_id: 'yambms1'
#      # Sniffer ID
#      sniffer_id: 'sniffer1'
#      # BMS vars
#      bms_id: '4' # must be a number
#      bms_name: 'JK-BMS 4'
#      bms_rs485_address: '0x04' # BMS 4 DIP switch
#      bms_update_interval: '3s' # going below '3s' can cause problems
#      bms_combine_interval: '1s'
#  
#  bms5: !include
#    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
#    vars:
#      # YamBMS ID
#      yambms_id: 'yambms1'
#      # Sniffer ID
#      sniffer_id: 'sniffer1'
#      # BMS vars
#      bms_id: '5' # must be a number
#      bms_name: 'JK-BMS 5'
#      bms_rs485_address: '0x05' # BMS 5 DIP switch
#      bms_update_interval: '3s' # going below '3s' can cause problems
#      bms_combine_interval: '1s'
#
#  bms6: !include
#    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
#    vars:
#      # YamBMS ID
#      yambms_id: 'yambms1'
#      # Sniffer ID
#      sniffer_id: 'sniffer1'
#      # BMS vars
#      bms_id: '6' # must be a number
#      bms_name: 'JK-BMS 6'
#      bms_rs485_address: '0x06' # BMS 6 DIP switch
#      bms_update_interval: '3s' # going below '3s' can cause problems
#      bms_combine_interval: '1s'
#
#  bms7: !include
#    file: packages/bms/bms_JK-PB_RS485_bms_full.yaml
#    vars:
#      # YamBMS ID
#      yambms_id: 'yambms1'
#      # Sniffer ID
#      sniffer_id: 'sniffer1'
#      # BMS vars
#      bms_id: '7' # must be a number
#      bms_name: 'JK-BMS 7'
#      bms_rs485_address: '0x07' # BMS 7 DIP switch
#      bms_update_interval: '3s' # going below '3s' can cause problems
#      bms_combine_interval: '1s'

  yambms1: !include
    file: packages/yambms/yambms.yaml
    vars:
      # Please read the cut-off charging logic README to understand how the YamBMS works
      yambms_id: 'yambms1'
      yambms_name: 'Smart BMS 1'
      yambms_update_interval: '1s'
      # Input numbers can be displayed as a slider or an input box, options are 'slider' or 'box'.
      yambms_input_number_mode: 'slider'
      # Please check and fill in the options below correctly according to your battery chemistry and number of cells in series.
      # These parameters are important and used for charging logic.
      # Battery Chemistry
      yambms_battery_chemistry: '1' # 1-LFP | 2-Li-ion | 3-LTO
      # Number of cells in series
      yambms_cell_count: '16'
      # Bulk / Absorption Voltage : corresponds to the Bulk voltage that will be used to charge the battery. (LFP : 55.2V = 3.45V/Cell for 16S battery)
      yambms_bulk_v: '55.2'
      # Float Voltage : corresponds to the voltage at which the battery would be maintained at the end of charge. (LFP : 53.6V = 3.35V/Cell for 16S battery)
      yambms_float_v: '53.6'
      # Rebulk voltage, voltage from which a new Bulk charge can start. (LFP : 52.8V = 3.3V/Cell for 16S battery)
      yambms_rebulk_v: '52.8'
      # Maximum time in minutes that the cut-off step can last before charging is complete
      # If your cells are properly balanced this step ends at the fastest after the `cut-off timer`
      # This timer can be deactivated with a switch
      yambms_eoc_timer: '30'
      # Time in seconds during which the end of charge conditions must be respected (cut-off + cells not equalizing)
      yambms_cutoff_timer: '60'
      # Maximum charging cycles is used to calculate the battey SOH, LF280K v3 =8000.0, LF280K v2 =6000.0, LF280=3000.0 (decimal is required)
      yambms_max_cycles: '6000.0'

  canbus1: !include
    file: packages/yambms/yambms_canbus.yaml
    vars:
      # YamBMS ID
      yambms_id: 'yambms1'
      # CANBUS vars
      canbus_id: 'canbus1'
      canbus_name: 'CANBUS 1'
      canbus_node_id: 'canbus_node1'
      canbus_light_id: 'esp_light'
      # The CANBUS link will be considered down if no response from the inverter (ID 0x305) for 5s
      # The Deye inverter sends the ACK (can_id 0x305) only when it receives the can_id 0x356
      canbus_link_timer: '5'

# +--------------------------------------+
# | DEBUG ( logger level must be DEBUG ) |
# +--------------------------------------+

  # device_debug: !include
  #   file: packages/base/device_debug_ESP32.yaml
  #   vars:
  #     debug_name: 'Debug'
  #     debug_update_interval: '5s'

Sleeper85 commented 3 weeks ago

@txubelaxu

well... the code should be optimized, of course, but I do not think it should be a very important problem. Do those times cause a problem in the system behaviour?

I don't know if this is a big problem or not, my BMS are JK-B and I have never tested your RS485 component.

800ms delays are getting long. YamBMS users with your component seem happy so I guess it works well for them.

Extract from the esphome doc.

Sleeper85 commented 3 weeks ago

@txubelaxu

What version of esphome are you using?

If you compile only your component alone without YamBMS, do you have the same problem?

There are several users who use YamBMS 1.4.5 with your RS485 component and their configuration is stable for several days without reboot.

So I think the problem may not come from your code or my code, maybe it happens with a certain version of ESPhome or some other external factor?

txubelaxu commented 3 weeks ago

If I use only my code, or my code inside jk-bms-can version, everything is OK. It only happens with yambms code. I am getting crazy. lol

I am using Version: 2024.10.0 esphome version.

The error is something that I cannot understand. Sometimes, when code calls to update sensor value of the 3rd cell, then it reboots. The value of the sensor is correct. But inside the function--> void JkRS485Bms::publishstate(sensor::Sensor *sensor, float value), the use of the "sensor" object creates the crash.

I am going on the debugging.

Sleeper85 commented 3 weeks ago

In your board_esp32-s3-devkitc-1.yaml file can you increase the size of rx_buffer_size to 1024 please?

uart:
  # UART 1
  - id: uart_esp_1
    tx_pin: 17
    rx_pin: 18
    baud_rate: 115200
    rx_buffer_size: 1024

goldserve commented 3 weeks ago

If you enable the debugging and # file: packages/base/device_debug_ESP32.yaml, how much heap space do you have available initially?

txubelaxu commented 2 weeks ago

@Sleeper85: I have tried with rx_buffer_size: 1024, and 2048 as well. But same results. @goldserve: I have tried to see how much heap space I have available initially:

INFO Successfully connected to yambms @ 172.26.1.217 in 0.059s INFO Successful handshake with yambms @ 172.26.1.217 in 0.023s [18:09:40][D][sensor:094]: 'yambms Debug Heap free': Sending state 102244.00000 B with 0 decimals of accuracy [18:09:40][D][sensor:094]: 'yambms Debug Loop time': Sending state 1127.00000 ms with 0 decimals of accuracy [18:09:40][D][sensor:094]: 'yambms Debug Heap max block': Sending state 83968.00000 B with 0 decimals of accuracy [18:09:44][D][sensor:094]: 'yambms Debug Heap free (%)': Sending state 31.20239 % with 2 decimals of accuracy [18:09:44][D][sensor:094]: 'yambms Debug Heap max block (%)': Sending state 25.62500 % with 2 decimals of accuracy [18:09:45][D][sensor:094]: 'yambms Debug Heap free': Sending state 103784.00000 B with 0 decimals of accuracy [18:09:45][D][sensor:094]: 'yambms Debug Loop time': Sending state 115.00000 ms with 0 decimals of accuracy [18:09:45][D][sensor:094]: 'yambms Debug Heap max block': Sending state 88064.00000 B with 0 decimals of accuracy [18:09:49][D][sensor:094]: 'yambms Debug Heap free (%)': Sending state 31.67236 % with 2 decimals of accuracy [18:09:49][D][sensor:094]: 'yambms Debug Heap max block (%)': Sending state 26.87500 % with 2 decimals of accuracy [18:10:24][D][sensor:094]: 'yambms Debug Heap free': Sending state 104240.00000 B with 0 decimals of accuracy [18:10:24][D][sensor:094]: 'yambms Debug Loop time': Sending state 122.00000 ms with 0 decimals of accuracy [18:10:24][D][sensor:094]: 'yambms Debug Heap max block': Sending state 86016.00000 B with 0 decimals of accuracy [18:10:25][D][sensor:094]: 'yambms Debug Heap max block (%)': Sending state 26.25000 % with 2 decimals of accuracy

I am trying to vreate a custom sensor component to avoid the issue.

txubelaxu commented 2 weeks ago

Well, I see that the problem dissapears if I comment two lines of my code (jk_rs485_bms.cpp file):

    this->publish_state_(this->cells_[i].cell_voltage_sensor_, cell_voltage);
    this->publish_state_(this->cells_[i].cell_resistance_sensor_, cell_resistance);

YAMBMS version: Without those 2 lines, it has been working for 2 hours with no problem. With those 2 lines, it crashes each 3 minutes.

JK-BMS-CAN (developer branch): With those lines it is working well for days.

I am getting crazy analyzing this error. I do not know how to avoid the problem.

Sleeper85 commented 2 weeks ago

Well, I see that the problem dissapears if I comment two lines of my code (jk_rs485_bms.cpp file):
    this->publish_state_(this->cells_[i].cell_voltage_sensor_, cell_voltage);
    this->publish_state_(this->cells_[i].cell_resistance_sensor_, cell_resistance);
YAMBMS version: Without those 2 lines, it has been working for 2 hours with no problem. With those 2 lines, it crashes each 3 minutes.

JK-BMS-CAN (developer branch): With those lines it is working well for days.

I am getting crazy analyzing this error. I do not know how to avoid the problem.

Strange, these sensors are not used in the YamBMS code. I don't understand why there would be a crash related to the publication of these sensors...

The only information used about the cells are the sensors below:

bms${bms_id}_max_cell_voltage
bms${bms_id}_min_cell_voltage
bms${bms_id}_max_voltage_cell
bms${bms_id}_min_voltage_cell
bms${bms_id}_cell_ovpr
bms${bms_id}_cell_uvpr

txubelaxu commented 2 weeks ago

Yes, but those values are used to show the cell tables in HA Dashboards, so they are needed.

The problem is about the Voltage in the cell number 3 (i=2) of BMS at address 0x01 If I avoid to publishing the voltage of that cell then... everything works ok!!!. lol

The voltage value of that cell is correct. Something wrong in the code with only the voltage of only that cell???? lol

      ESP_LOGD(TAG, "[ADDRESS: %02X]  %02d --> V: %fV",this->address_,i, cell_voltage);
      if(this->address_==1 && i==2){
      } else {
        this->publish_state_(this->cells_[i].cell_voltage_sensor_, cell_voltage);
      }
      ESP_LOGD(TAG, "                  --> R: %fohm",cell_resistance);
      this->publish_state_(this->cells_[i].cell_resistance_sensor_, cell_resistance);

The values of that cell are correct:

[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  00 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.081000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  01 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.078000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  02 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.080000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  03 --> V: 3.319000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.075000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  04 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.076000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  05 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.078000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  06 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.081000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  07 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.091000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  08 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.094000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  09 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.074000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  10 --> V: 3.319000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.077000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  11 --> V: 3.319000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.074000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  12 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.077000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  13 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.077000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  14 --> V: 3.320000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.083000ohm
[00:07:31][D][jk_rs485_bms:690]: [ADDRESS: 01]  15 --> V: 3.319000V
[00:07:31][D][jk_rs485_bms:695]:                   --> R: 0.082000ohm

          ( >_<)
          <(  )>
          /    \

txubelaxu commented 2 weeks ago

Very mysterious. Without updating that sensor status (voltage of 3th cell of the BMS 0x01) the system is stable for more than 16 hours now.

Sleeper85 commented 2 weeks ago

Very mysterious. Without updating that sensor status (voltage of 3th cell of the BMS 0x01) the system is stable for more than 16 hours now.

And I can also confirm that other people use YamBMS 1.4.5 with your JK RS485 component including @Widget4145 with 7x JK-PB and he doesn't have this problem...

Sleeper85 commented 2 weeks ago

Some details:

One of the changes with YamBMS 1.4.5 that may have had an impact on the JK RS485 component is to have set an rx_buffer_size to 512 by default instead of 1000. I did this to reduce the number of YAML files.

This had been tested and validated by @widget4145 who uses 7x JK-PB.

But another user with 2x JK-PB and an Atom S3 also had reboot issues and he changed the rx_buffer_size to 1000. Since then he says everything is stable for him.

uart:
  # UART 0 : USB UART port used for ESP32 flashing and logs, can be released if necessary (tx_pin: 43, rx_pin: 44)
  # UART 1
  - id: uart_esp_1
    tx_pin: 17
    rx_pin: 18
    baud_rate: 115200
    rx_buffer_size: 512
  # UART 2
  - id: uart_esp_2
    tx_pin: 15
    rx_pin: 16
    baud_rate: 115200
    rx_buffer_size: 512

txubelaxu commented 2 weeks ago

I have tested with 512 and the problem is still present. I am thinking about the possibility that ESP32 is joking me... lol

Sleeper85 commented 2 weeks ago

You have to try with 1000.

txubelaxu commented 2 weeks ago

I have tried with 512, 1000, 1024 and 2048 and the problem is still present.

If I use only esphome-jk-bms (without esphome-yambms) it works ok for me.

txubelaxu commented 2 weeks ago

This line breaks the code and reboots the ESP32 when address is 0x01 and i=2: this->publishstate(this->cells_[i].cell_voltagesensor, cell_voltage);

I know, as well, that if I change cell_voltage by a fix value (3.317 for example), the line does break the code as well.

So, the problem is about writting into the sensor: this->cells[2].cell_voltage_sensor__ with a value

Sleeper85 commented 2 weeks ago

What ESP32 model are you using?

How many BMS?

Try to reduce the number of sensors, you can remove all the binary_sensors of type alarm. Try to keep the minimum necessary with the cell voltages. It may be a memory problem...

txubelaxu commented 2 weeks ago

Model: ESP32-S3-DevKitC-1 (Flash: 16M ; PSRAM: 8M) I have 2 BMSs It works with "full" config OK if I comment the publication of the 3th cell (i=2) of first BMS (0x01)

The ESP32-S3 is very big (I think) to manage:

Linking .pioenvs/yambms/firmware.elf
RAM:   [=         ]   7.1% (used 37328 bytes from 524288 bytes)
Flash: [==        ]  16.6% (used 1346501 bytes from 8126464 bytes)
Building .pioenvs/yambms/firmware.bin

If I stop the Home Assistant service (to avoid requests), the problem is not solved. If I comment next lines the problem is not solved:


    cell_voltage_01:
      name: "${name} ${bms_name} cell voltage 01"
    cell_voltage_02:
      name: "${name} ${bms_name} cell voltage 02"
    #cell_voltage_03:
    #  name: "${name} ${bms_name} cell voltage 03"
    cell_voltage_04:
      name: "${name} ${bms_name} cell voltage 04"
    cell_voltage_05:
      name: "${name} ${bms_name} cell voltage 05"

Only if I avoid the publication of that sensor, the problem is solved.

I am doing thousands of tests. I am still working.

The main problem of this testing is that each time the ESP32 reboots, the Victron system enter in a "bad situation" and the relays "jump", so I have the system isolated from the house to testing:

txubelaxu commented 2 weeks ago

A clean compilation did not solve the problem.

I have made a lot of tests and I could not solve the problem, because I cannot understand it. But, I managed to avoid the problem, defining a new array (cellsinfo_) that I use in my code for NOTHING. Yes, I know that it is very crazy, but the 3th cell now is monitored and the system does not reboot now.

These are the lines:

  struct CellInformation {
    sensor::Sensor *cell_voltage_sensor_; 
    sensor::Sensor *cell_resistance_sensor_; 
  };
  struct Temperature {
    sensor::Sensor *temperature_sensor_{nullptr};
  };

  //IF I insert follow array of 4 elements (despite it is not used at all), the "0x01 address 3th cell voltage' problem goes away
  CellInfo cellsinfo_[4];
  CellInfo cells_[32];

Sleeper85 commented 2 weeks ago

Well, I don't know what to tell you.

Maybe a BMS component specialist like @syssi could help you find/understand what's going on?

txubelaxu commented 2 weeks ago

Yes, we need a MASTER of UNIVERSE knowing level to understand the cause of the problem.

Althought the problem has been avoided, it is still there. I do not know if it is sleeping or it has gone forever.

At this moment it has gone for me for now.

txubelaxu commented 1 week ago

Working atable for 1d 13h

Sleeper85 / esphome-yambms

[JK-PB RS485] Restarting after a few minutes (2min aprox), starting, and restarting again after a few minutes... #4