search

syssi / esphome-jbd-bms

ESPHome component to monitor and control a Xiaoxiang Battery Management System (JBD-BMS) via UART-TTL or BLE
Apache License 2.0
116 stars 31 forks source link

BMS not respond by charge #4

Closed andrewww173 closed 2 years ago

andrewww173 commented 2 years ago

I really appreciate you for your work! I'm testing it on bms 8S, 24v 50A, and everything works fine, but only in one case - in case of discharge. BMS stops responding and send any data by charging, data is sending only in a discharging mode. I have two esp8266 controllers (one of them is a wemos mini) and two identical bms. The result is the same on each of them 000212

syssi commented 2 years ago

Could you provide some logs? I assume the BMS is connected via software serial and you can use GPIO1/GPIO3 to retrieve the esphome log via USB?

andrewww173 commented 2 years ago

I didn 't understand a little about the usb ) So I have esp 01s and I use GPIO1/GPIO3 connected and below is a small piece of the log . I will be able to send the log during charging tomorrow, there is no sun now) At the moment when the controller does not respond, only one entry is looped in the logs [uart_debug:114]: >>> DD:A5:03:00:FF:FD:77

000212-01 when the connection is lost, I see such logs 000212-02

000212-03 such when it is restored. But during charging, the connection is never restored

000212-04

syssi commented 2 years ago

Could you provide the log samples (like the screenshots) in plaintext? I would like to copy some raw frames for analysis.

Please replace the wire between the BMS and your ESP and try to make it as short as possible.

syssi commented 2 years ago

There is something wrong with your config yaml. The logger component writes per default the log to UART0 (GPIO1/GPIO3). Using the same GPIOs to talk to the BMS isn't a good idea. You have to disable the serial support of the logger by setting baud_rate: 0 or you should attach the BMS to another pair of GPIOs. I recommend using GPIO4 & GPIO5.

andrewww173 commented 2 years ago

I have attached everything in the archive below: bms.zip

andrewww173 commented 2 years ago

looks like when the sun is hiding controllers send actual data (0005656

syssi commented 2 years ago

Please disable the serial output of the logger. May be this is the root cause for the "garbled" connection.

Take a look at this log:

[09:18:52][W][jbd_bms:128]: JbdBms CRC Check failed! F95A != F9FA
[09:18:52][D][uart_debug:114]: <<< DD:03:00:1B:0A:63:FD:D9:10:4E:13:88:00:89:29:7A:00:80:00:00:00:00:26:53:03:08:02:0B:89:0B:7E:F9:FA:77
[09:18:54][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:18:54][D][uart_debug:114]: <<< DD:03:00:1B:0A:61:FD:CD:10:4D:13:88:00:89:29:5A:00:00:00:80:00:00:66:7E:30:98:0B:89:0B:7E:FA:09:77
[09:18:56][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:18:56][D][uart_debug:114]: <<< DD:03:00:1B:0A:62:FE:89:10:4D:13:88:00:89:29:5A:00:00:00:00:00:00:93:D3:03:18:02:7F:FE:61:7F:78:F7
[09:18:58][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:18:58][D][uart_debug:114]: <<< DD:03:00:1B:0A:62:FE:29:10:4D:13:88:00:89:29:5A:00:00:00:80:00:00:26:F3:30:98:FC:4B:0B:7E:FA:AB:77
[09:19:00][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:19:00][D][uart_debug:114]: <<< DD:03:00:1B:0A:64:FE:2D:10:4D:13:88:00:89:29:5A:00:00:00:00:00:00:2E:53:03:08:02:1B:71:E1:D3:A5:77
[09:19:02][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:19:02][D][uart_debug:114]: <<< DD:03:00:1B:0A:62:FE:25:10:4C:13:88:00:89:29:5A:00:00:00:00:00:00:26:F3:03:84:02:61:FE:61:FF:B0:77
[09:19:04][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:19:04][D][uart_debug:114]: <<< DD:03:00:1B:0A:DD:FF:6E:8C:DE:1C:1C:89:29:5A:00:00:00:00:00:00:26:53:E0:98:1B:E2:98:D3:B7:77
[09:19:06][D][uart_debug:114]: >>> DD:A5:03:00:FF:FD:77
[09:19:06][D][uart_debug:114]: <<< DD:03:00:1B:0A:5B:FD:56:10:4C:13:88:00:89:29:5A:00:00:00:00:00:00:26:53:03:08:02:0B:99:61:D7:FE

The component sends the "request battery status" frame:

>>> DD:A5:03:00:FF:FD:77

As response a 34 bytes frame is expected. Starting with 0xDD 0x03 and ending with 0xFE. Inspect the responses of your BMS:

# correct length but invalid checksum
DD:03:00:1B:0A:63:FD:D9:10:4E:13:88:00:89:29:7A:00:80:00:00:00:00:26:53:03:08:02:0B:89:0B:7E:F9:FA:77
# too short, 1 byte missing
DD:03:00:1B:0A:61:FD:CD:10:4D:13:88:00:89:29:5A:00:00:00:80:00:00:66:7E:30:98:0B:89:0B:7E:FA:09:77
# too short, end of frame missing (0x77)
DD:03:00:1B:0A:62:FE:89:10:4D:13:88:00:89:29:5A:00:00:00:00:00:00:93:D3:03:18:02:7F:FE:61:7F:78:F7
# too short, 1 byte missing
DD:03:00:1B:0A:62:FE:29:10:4D:13:88:00:89:29:5A:00:00:00:80:00:00:26:F3:30:98:FC:4B:0B:7E:FA:AB:77
# too short, 1 byte missing
DD:03:00:1B:0A:64:FE:2D:10:4D:13:88:00:89:29:5A:00:00:00:00:00:00:2E:53:03:08:02:1B:71:E1:D3:A5:77
# too short, 1 byte missing
DD:03:00:1B:0A:62:FE:25:10:4C:13:88:00:89:29:5A:00:00:00:00:00:00:26:F3:03:84:02:61:FE:61:FF:B0:77
# too short, 2 bytes missing
DD:03:00:1B:0A:DD:FF:6E:8C:DE:1C:1C:89:29:5A:00:00:00:00:00:00:26:53:E0:98:1B:E2:98:D3:B7:77
# too short, end of frame missing
DD:03:00:1B:0A:5B:FD:56:10:4C:13:88:00:89:29:5A:00:00:00:00:00:00:26:53:03:08:02:0B:99:61:D7:FE
syssi commented 2 years ago

Please disable the serial output of the logger component + flash the new config yaml:

logger:
  baud_rate: 0
andrewww173 commented 2 years ago

The thing is, I've done it before:

000212-05

and what is interesting - all of this bugs like a lost frame or no any response are only in charging mode. in discharge mode serial output is working correct...

syssi commented 2 years ago

Some ideas:

  1. Could you attach the BLE module instead of the ESP and measure the voltage between RX and GND and between TX and GND. I would like to make sure the TTL of your BMS model is 3.3V and not 5V.

  2. If you have a logic analyzer you could monitor the traffic between the BLE module and the BMS. May be the status frame is just a byte shorter because your firmware is a big special.

  3. Please provide some more logs with undecodable traffic. I would like to compare the frames to identify the position of the missing byte. If it's always at the same position it's easy to handle the different behavior.

syssi commented 2 years ago

Could you connect the BMS to GPIO4 and GPIO5 just for testing/comparison?

andrewww173 commented 2 years ago
  1. the voltage between RX - GND and between TX - GND is 3.3V - I checked it
  2. I don't have it...unfortunately
  3. ok, attached ) pay attention at [19:24:08] charging started on this moment and errors started as usual logs_wemos-01_logs (2).txt
  4. there are no such pins on my esp01s. GPIO4 and GPIO5 on wemos d1-mini used for i2c - can they be used for uart?
syssi commented 2 years ago
  1. If you don't have other devices attached to GPIO4 and 5 they can be used at/for the uart component (via software serial). Let's stick to the D1 mini for now. As soon everything is running smooth here we will care about the esp01s.
andrewww173 commented 2 years ago

GPI04/GPIO5 are working as uart (surprise for me :) ) but with the same result. Log is in attachment in [21:35:30] BMS change mode discharge -> charge logs_wemos-01_logs (3).txt

syssi commented 2 years ago

How do you power the Wemos D1 mini? Do you use a step-down converter attached to the battery or do you use a dedicated power supply?

andrewww173 commented 2 years ago

I use a step-down converter attached to the battery. I understand you idea! will try another supply

andrewww173 commented 2 years ago

the errors are a bit different, after changing supply, but whatever no data [21:54:40] change mode discharge -> charge logs_wemos-01_logs (4).txt

syssi commented 2 years ago

The last log looks like bad grounding. Please double check the GND connection between the BMS and the ESP.

syssi commented 2 years ago

TODO: Add "CLRD, Lifepo4 Protection Board, LFP-82460-COMM, 8S 24V 60A" as supported if the issue can be solved.

andrewww173 commented 2 years ago

because is no sun now, I used the charge from my mppt controller,for this test. I suspect that it creates some kind of interference during the charge from the utility. Some of my devices are starting to behave strangely in this mode. It's probably better to test when the sun comes out.

andrewww173 commented 2 years ago

By the way, maybe the mppt controller can somehow affect on the data? noise... interference... I had an idea. I have two 8s builds. I can disconnect one and discharge it a little, and then reassemble it and it will take charge from a more charged battery and see the effect.

syssi commented 2 years ago

Let's move on tomorrow! Have a nice evening!

andrewww173 commented 2 years ago

of course! thank you! Have a nice evening too

syssi commented 2 years ago

I'm pretty sure the issue isn't software related. I would be happy if you can rule out all electrical causes.

This is the worst-worst-case in my opinion: Imagine the microcontroller of the BMS ticks faster on charging and cannot maintain the 9600 baud. I keep my fingers crossed that this is not the case.

andrewww173 commented 2 years ago

I think I've tried everything possible. I tried charging with other sources, used other wires and esp power, in each case, the same result. data "garbled" by charging, or not respond from BMS. .. two different bms behave the same way. But by discharging , everything seems to be fine ) with the same wires

syssi commented 2 years ago

This is sad. Some more ideas:

  1. I could provide a config yaml containing the uart component which writes all incoming traffic to the log + sends the status request every two seconds. So we can rule out this implementation as root cause.

  2. You could attach the BLE module and biggy pack the ESP (RX & GND only). You should see the responses of the BMS again at the log. Let's check these responses are fine or garbled.

  3. There are cheap chinese logic analyzer for around 10€ compatible with sigrok/pulseview (open source). I could provide some instructions how to use these tools to sniff and decode the UART traffic.

syssi commented 2 years ago
  1. Please use this config yaml for the first test scenario: https://raw.githubusercontent.com/syssi/esphome-jbd-bms/main/tests/esp8266-query-data.yaml
  2. Please use this config yaml as dummy receiver at the piggy back scenario: https://raw.githubusercontent.com/syssi/esphome-jbd-bms/main/tests/esp8266-dummy-receiver.yaml
andrewww173 commented 2 years ago

1 item: [14:42:01]- discharge -> charge [14:43:55]- charge - > disgharge logs_wemos-01_logs (6).txt

andrewww173 commented 2 years ago

2 item: [15:02:12] discharge - > charge [15:04:56] charge - > discharge logs_wemos-01_logs (7).txt photo_2022-07-17_15-54-51

syssi commented 2 years ago

Scenario 1: If I concatenate the bytes of three log messages I'm able to reconstruct a full frame:

[14:42:15][D][uart_debug:114]: <<< DD:03:00:1B:0A:88:03:3C:0E:26:13:88:00:A5:29:89:00:08:00:00:00:00:28:48:03:08:02:0B:B5:0B:B4:FA:EA:77
[14:42:21][D][uart_debug:114]: <<< DD:03:00:1B:0A:89:03:44:0E:28:13:88:00:A5:29:89:00:00:00:00:00:00:28:48:03:08:02:0B:B5:0B:B4:FA:E7:77
[14:42:27][D][uart_debug:114]: <<< DD:03:00:1B:0A:8A:03:4C:0E:29:13:88:00:A5:29:89:00:00:00:00:00:00:28:48:03:08:02:0B:B5:0B:B4:FA:DD:77
[14:42:33][D][uart_debug:114]: <<< DD:03:00:1B:0A:8B:03:4F:0E:2A:13:88:00:A5:29:89:00:00:00:00:00:00:28:49:03:08:02:0B:B5:0B:B4:FA:D7:77
[14:42:39][D][uart_debug:114]: <<< DD:03:00:1B:0A:8C:03:58:0E:2C:13:88:00:A5:29:89:00:00:00:00:00:00:28:49:03:08:02:0B:B5:0B:B4:FA:CB:77
[14:43:33][D][uart_debug:114]: <<< DD:03:00:1B:0A:91:03:83:0E:39:13:88:00:A5:29:89:00:00:00:00:00:00:28:49:03:08:02:0B:B6:0B:B5:FA:8C:77

Interpretation: The BMS has trouble to handle an update interval of 2 seconds and it's possible the bytes are delivered in pieces with some delays between each piece. The custom component (jbd implementation) discards data if there is a gap of 50ms. We should increase this interval to be able to receive a frame in multiple pieces with gaps in between.

syssi commented 2 years ago

Scenario 2: I can see the same phenomenon at capture of the bluetooth traffic plus one additional thing: The update interval of the bluetooth module is around 10 seconds if you look to the timestamp:

[15:02:42][D][uart_debug:114]: <<< DD:04:00:10:0D:06:0C:EB:0D:07:0D:09:0D:08:0D:09:0D:09:0D:06:FE:68:77
[15:02:45][D][uart_debug:114]: <<< DD:03:00:1B:0A:69:00:FC:0D:DA:13:88:00:A5:29:89:00:A8:00:00:00:00:28:47:03:08:02:0B:B6:0B:B5:F8:F8:77
[15:02:48][D][uart_debug:114]: <<< DD:03:00:1B:0A:6A:00:FC:0D:DB:13:88:00:A5:29:89:00:A8:00:00:00:00:28:47:03:08:02:0B:B5:0B:B5:F8:F7:77
[15:02:51][D][uart_debug:114]: <<< DD:03:00:1B:0A:6A:01:01:0D:DB:13:88:00:A5:29:89:00:A8:00:00:00:00:28:47:03:08:02:0B:B6:0B:B5:F9:F0:77
[15:02:54][D][uart_debug:114]: <<< DD:03:00:1B:0A:6A:01:05:0D:DB:13:88:00:A5:29:89:00:55:00:00:00:00:28:47:03:08:02:0B:B6:0B:B5:FA:3F:77
[15:03:07][D][uart_debug:114]: <<< DD:04:00:10:0D:08:0C:EE:0D:0A:0D:0B:0D:0B:0D:0B:0D:0C:0D:09:FE:53:77
[15:03:34][D][uart_debug:114]: <<< DD:04:00:10:0D:0A:0C:F0:0D:0C:0D:0F:0D:0E:0D:0D:0D:0E:0D:0B:FE:40:77
[15:03:51][D][uart_debug:114]: <<< DD:03:00:1B:0A:6E:01:01:0D:DF:13:88:00:A5:29:89:00:A8:00:00:00:00:28:47:03:08:02:0B:B5:0B:B5:F9:E9:77
[15:04:00][D][uart_debug:114]: <<< DD:03:00:1B:0A:6F:01:01:0D:E0:13:88:00:A5:29:89:00:55:00:00:00:00:28:47:03:08:02:0B:B5:0B:B4:FA:3B:77
[15:04:11][D][uart_debug:114]: <<< DD:03:00:1B:0A:6F:01:01:0D:E1:13:88:00:A5:29:89:00:55:00:00:00:00:28:47:03:08:02:0B:B5:0B:B4:FA:3A:77
[15:04:18][D][uart_debug:114]: <<< DD:04:00:10:0D:0D:0C:F3:0D:0F:0D:10:0D:0F:0D:10:0D:10:0D:0E:FE:2D:77

Every now and then the cell info frame (0x04) is requested and returned (shorter frames).

andrewww173 commented 2 years ago

I also noticed that the data came in slower during charging

syssi commented 2 years ago

I've pushed a fix. Please update your configuration yaml to:

substitutions:
  external_components_source: github://syssi/esphome-jbd-bms@handle-reluctant-bms-responses

Compile, flash & try again. I hope this improve the situation. Next improvement: Please change the update_interval to 10s.

andrewww173 commented 2 years ago

it looks like you're a genius! The first time I saw positive values here! I continue to test 0005-00

andrewww173 commented 2 years ago

Problem is solved! Thank you so much!!! 0001-

syssi commented 2 years ago

The allowed silence between two bytes is 750ms now instead of 50ms (previously). I would like to reduce the timeout again step by step. Could you do some more testing with different timeouts? Do you need support how to use a local copy of the custom component + make local changes to test different values?

andrewww173 commented 2 years ago

Some more testing for you - of course, no problem! About the support - would be nice

syssi commented 2 years ago

Please use this configuration yaml again: https://raw.githubusercontent.com/syssi/esphome-jbd-bms/main/tests/esp8266-query-data.yaml

I've added a new option (timeout: 100ms). This is the default timeout you have used today at noon already. You remember the response divided into multiple lines? Please increase this timeout step by step (150ms, 200ms, 250ms, ... 750ms) and try to identify the timeout value where the response is presented in a single line. This is the minimum duration/space between two bytes. As soon we know the minimum possible amount we can add some margin (f.e. 50ms). This will be the new default timeout at the jbd_bms component.

andrewww173 commented 2 years ago

OK, I can do it tomorrow when the sun starts charging my batteries )

syssi commented 2 years ago

Please increase the request interval to 10s. I missed to update this parameter at the yaml.

andrewww173 commented 2 years ago

I have done tests, but the results are strange, apparently it takes longer to test. Or try it on the second board. For some reason, most of the requests have no answers with any timeouts. At the same time, with yesterday's firmware, BMS has been working perfectly for more than a day test.zip

syssi commented 2 years ago

This is strange. Take your time! I've changed the feature branch of yesterday and introduced a new parameter called rx_timeout.

jbd_bms:
  rx_timeout: 750ms
syssi commented 2 years ago

It looks like the message cannot be retrieved in a single line / in one piece if the rx_timeout is less then 100ms. I assume 150ms could be a good new default.

syssi commented 2 years ago

I've merged the feature branch into main. Please change your configuration yaml back to:

substitutions:
  external_components_source: github://syssi/esphome-jbd-bms@

And feel free to use the new setting to evaluate / test the behavior of the component with different timeouts:

jbd_bms:
  rx_timeout: 90ms
andrewww173 commented 2 years ago

The result of this changing is in log _substitutions: external_componentssource: github://syssi/esphome-jbd-bms@

logs_wemos-01_upload (19).txt

Look's like everything works as it should. all sensors on the panel are updated at a speed sufficient for normal monitoring. Thank you again for your great work! Now I will deal with your project pipsolar there I also have problems, it seems because of RS232 , data comes, but 99% of them in the form of 0.0000 . But that's another story )

syssi commented 2 years ago

Look's like everything works as it should. all sensors on the panel are updated at a speed sufficient for normal monitoring. Thank you again for your great work! Now I will deal with your project pipsolar there I also have problems, it seems because of RS232 , data comes, but 99% of them in the form of 0.0000 . But that's another story )

Feel free to create an issue at the pipsolar repo if you cannot solve the issue. For now it sounds like a wiring issue.