seplos_modbus reporting invalid header

[bagges]

First of all, thanks for your awesome projects!

I am using an RS458 adapter with MAX458 chip. I tried to use pins 1/3 and 15/13 for Tx/Rx on an ESP32 dev kit v4. As flow control pin I am using 4/5. I read that you do not recommend those boards with flow control, but I designed a PCB with those and try to get them working before I redesign the PCB ...

My config:

substitutions:
  name: seplos-bms
  device_description: "Monitor a Seplos BMS via RS485"
  external_components_source: github://syssi/esphome-seplos-bms@main

esphome:
  name: ${name}
  comment: ${device_description}
  platform: ESP32
  board: nodemcu-32s
  project:
    name: "syssi.esphome-seplos-bms"
    version: 1.1.0

external_components:
  - source: ${external_components_source}
    refresh: 0s

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

api:
ota:
logger:
  baud_rate: 0
  level: DEBUG

uart:
  id: uart0
  # Please set the default baudrate of your Seplos BMS model here. It's sometimes 19200 baud instead of 9600.
  baud_rate: 19200
  tx_pin: 15
  rx_pin: 13
  # The increased RX buffer size is important because
  # the full BMS response must fit into the buffer
  rx_buffer_size: 384
  debug:
    dummy_receiver: false
    direction: BOTH
    after:
      delimiter: "\r"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);
seplos_modbus:
  id: modbus0
  uart_id: uart0
  rx_timeout: 150ms
  flow_control_pin: 4

seplos_bms:
  id: bms0
  # Dip switch configuration of a single pack setup / address 0x0
  #  8    7    6    5    4    3    2    1
  # off, off, off, off, off, off, off, off
  address: 0x00
  # Known protocol versions: 0x20 (Seplos), 0x26 (Boqiang)
  protocol_version: 0x20
  seplos_modbus_id: modbus0
  update_interval: 10s

I configured debug logging and can see this:

[15:47:43][D][seplos_modbus:163]: Send frame: ~20004642E00200FD37
[15:47:43][D][uart_debug:158]: >>> "~20004642E00200FD37\r"
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][D][uart_debug:158]: <<< "70A6D6003E76D60000703E815C200000076035902CDDD12\r"
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][W][seplos_modbus:086]: Invalid header
[15:47:43][D][uart_debug:158]: <<< "\xFF\xFF~2000460010960000100D990D990D9A0D980D990D990D990D990D980D9A0D9A0D9A0D9B0D9A0D9B0D9A060B640B5D0B620B600B850B5D000015C26D5"
[15:47:53][D][seplos_modbus:163]: Send frame: ~20004642E00200FD37
[15:47:53][D][uart_debug:158]: >>> "~20004642E00200FD37\r"
[15:47:53][W][seplos_modbus:086]: Invalid header
[15:47:53][W][seplos_modbus:086]: Invalid header

Do you have any idea what could be the issue?

[syssi]

Could you enable the debug output of the uart component and provide another log?

[bagges]

did again with debug:

[19:53:40][D][seplos_modbus:163]: Send frame: ~20004642E00200FD37
[19:53:40][D][uart_debug:114]: >>> 7E:32:30:30:30:34:36:34:32:45:30:30:32:30:30:46:44:33:37:0D
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][W][seplos_modbus:086]: Invalid header
[19:53:40][D][uart_debug:114]: <<< 31:30:41:36:44:36:30:30:33:44:36:36:44:36:30:30:30:30:37:30:33:45:38:31:34:42:33:30:30:30:37:30:30:30:30:30:33:35:39:30:32:43:46:44:43:39:41:0D:7E:32:30:30:30:34:36:30:30:31:30:39:36:30:30:30:30:31:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:45:46:30:43:46:30:30:43:46:30:30:43:46:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:46:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:46:30:30:43:46:31:30:36:30:42:35:35:30:42:34:46:30:42:35:34:30:42:35:32:30
[19:53:40][C][mdns:108]: mDNS:
[19:53:40][C][mdns:109]:   Hostname: seplos-bms
[19:53:40][C][ota:093]: Over-The-Air Updates:
[19:53:40][C][ota:094]:   Address: seplos-bms.local:3232
[19:53:40][C][api:138]: API Server:
[19:53:40][C][api:139]:   Address: seplos-bms.local:6053
[19:53:40][C][api:143]:   Using noise encryption: NO
[19:53:40][D][uart_debug:114]: <<< 42:37:42:30:42:35:34:46:43:34:38:31:34:42:34:36:42:37
[19:53:42][D][api:102]: Accepted ::FFFF:192.168.2.75
[19:53:42][D][api.connection:918]: Home Assistant 2023.3.2 (::FFFF:192.168.2.75): Connected successfully
[19:53:50][D][seplos_modbus:163]: Send frame: ~20004642E00200FD37
[19:53:50][D][uart_debug:114]: >>> 7E:32:30:30:30:34:36:34:32:45:30:30:32:30:30:46:44:33:37:0D
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][W][seplos_modbus:086]: Invalid header
[19:53:50][D][uart_debug:114]: <<< 46:30:41:36:44:36:30:30:33:44:36:36:44:36:30:30:30:30:37:30:33:45:38:31:34:42:33:30:30:30:39:30:30:30:30:30:33:35:39:30:32:43:46:44:43:39:39:0D:7E:32:30:30:30:34:36:30:30:31:30:39:36:30:30:30:30:31:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:45:45:30:43:46:31:30:43:46:30:30:43:46:30:30:43:46:30:30:43:45:46:30:43:46:31:30:43:46:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:45:46:30:43:46:31:30:36:30:42:35:35:30:42:34:46:30:42:35:34:30:42:35:32:30
[19:53:50][D][uart_debug:114]: <<< 42:37:42:30:42:35:34:46:43:34:42:31:34:42:33:36:42:37
[19:54:00][D][seplos_modbus:163]: Send frame: ~20004642E00200FD37
[19:54:00][D][uart_debug:114]: >>> 7E:32:30:30:30:34:36:34:32:45:30:30:32:30:30:46:44:33:37:0D
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][W][seplos_modbus:086]: Invalid header
[19:54:00][D][uart_debug:114]: <<< 43:30:41:36:44:36:30:30:33:44:36:36:44:36:30:30:30:30:37:30:33:45:38:31:34:42:33:30:30:30:34:30:30:30:30:30:33:35:39:30:32:43:46:44:43:36:45:0D:7E:32:30:30:30:34:36:30:30:31:30:39:36:30:30:30:30:31:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:45:45:30:43:46:31:30:43:46:30:30:43:46:30:30:43:46:30:30:43:45:46:30:43:46:31:30:43:46:30:30:43:46:30:30:43:46:30:30:43:46:31:30:43:45:46:30:43:46:31:30:36:30:42:35:35:30:42:34:46:30:42:35:34:30:42:35:32:30
[19:54:00][D][uart_debug:114]: <<< 42:37:42:30:42:35:34:46:43:35:39:31:34:42:33:36:42:37

[syssi]

The raw traffic doesn't look good. All responses should start with 0x7e and end with 0x0d. Please make sure you are using the correct baud rate and if you have the chance please replace the rs485 converter just for testing. As soon as we are sure this isn't the root cause we could go back to the flow control module again.

[bagges]

Before I had opened the ticket, I already tried a different RS485 module. After your suggestion I build it on a breadboard with a 3rd module and now it's working like a charm! I put the working module on my pcb and still working. So I had realy two broken modules...

Thanks for the help!

[syssi]

Could you provide the model name of your BMS? I would like to add the BMS to the list of supported models if it's missing.

[bagges]

Part model: 1101-SP76 Software Version: v16.4 Protocol Version v2.0

[bagges]

Unfortunately the problem reappears after adding a second rs485 adapter to the ESP32. Sometimes I can read valid frames but most of the time I got invalid header reports. Could it help to add something like the send_wait_time?

esphome documentation states:

send_wait_time (Optional, Time): Time in milliseconds before a new modbus command is sent if an answer from a previous command is pending. Defaults to 250 ms. If multiple modbus devices are attached increasing this value can help avoiding to to overlapping reads. When 2 devices are sending a command at the same the response read from uart can’t be assigned to the proper design. This value defines the maximum queuing time for a command before it is send anyways.

[syssi]

The send_wait_time parameter won't help here. The setting isn't respected by the modbus component. It's used by the queue of the modbus_controller which isn't in use here.

You have added the second RS485 adapter to a second uart, correct? The implementation requests one telemetry frame per second / per update_interval. There shouldn't be concurrency issues because of the fixed timing. Could you describe your setup in detail? May be I miss something.

[bagges]

I updated the project, you can find the setup and schematic of the pcb here: https://github.com/bagges/deye-esp32-bridge

In a nutshell: 2x RS485 connected to one esp32 dev kit v4. First module reads the data from an deye inverter and the second module should read the data from seplos. Pins module one: 1/3/5, pins module two: 15/13/4

[syssi]

I will provide a more verbose version of the seplos component later the day. Does the Deye inverter part of your setup work flawlessly?

[syssi]

Please change the retrieval of the external component from the main branch to the feature branch:

substitutions:
  external_components_source: github://syssi/esphome-seplos-bms@debug-decoder

Please flash your ESP another time and provide a new log. The "Invalid header" response indicates the rejected byte now. Furthermore another warning is raised if the RX buffer gets cleared due to a timeout (big gaps of silence between two bytes).

[bagges]

I will provide a more verbose version of the seplos component later the day. Does the Deye inverter part of your setup work flawlessly?

Yes I have this running for few weeks without problems.

Here is the log from the debug-decoder branch: esp32-seplos-debug.log

[syssi]

The ESP receives a lot of noise probably because of long wires, bad grounding or bad components. There should be silence on the UART if the BMS doesn't send responses.

[syssi]

I've pushed some additional changes. I would be happy about another log to verify my assumption is correct.

[bagges]

I'll try it later. I also ordered some other rs485 modules (with automatic flow control). Will give them a try too.

[bagges]

New log esp32-seplos-debug-e8fa290.log

[syssi]

Thanks for testing! I am curious about the other rs485 converter (the one without flow control pin).

[bagges]

I'll get back to you. But unfortunately I can only test the adapter without flow control tonight. I really think I have a weird issue with my PCB. Maybe power supply or something...

[syssi]

No rush! Take your time.

[bagges]

I added the RS485 module without flow control pin with some flying cables to the pcb and it is working without problems for now.

[syssi]

May be it gets worse as soon you connect the inverter to the common ground (if there is/was one)?

[bagges]

I have not connected the inverter or bms to common gnd. I will now create some adapter pcb for the other rs485 module... What I also will try is to connect the initial module to 5V. I saw on the details that this is a 5v and not a 3.3v module.

[syssi]

If you power the module with 5V the logic level will be 5V too on the TTL side. The ESP should survive this but keep this in mind.

[syssi]

Let's close this issue for now because I'm pretty sure it cannot be solved software-wise.

[bagges]

@syssi I just want you to know.

I got my new PCBs and I am now using the RS485 with automatic flow control. At first everything worked fine, but after about 12h I got the same issues with "invalid header". Also the RX LED did not turn off at all. Only a full power cycle did solve the issue again for some time. I found out that the RS485 adapter where not terminated by default. I now terminated them by shorten the two small pins next to the B- port. Labeled with R13. Now it is running flawlessly. Hope I do not run in the problem again.

[syssi]

Could you provide a photo to visualize your change? Thanks in advance!

[bagges]

But it did not help,.... During the night the problem occurred again. I am running out of ideas

[syssi]

Did you connect GND of the RS485 side to the BMS or do you use B- & A+ only?

[bagges]

B- and A+ only. Do you have connected both GND from the RS485 to the GND of the BMS?

[syssi]

It's hard to make a good recommendation here: Sometimes it solves issues. Sometimes it brings new issues IMO. ;-)

[bagges]

I have now a stable version running for about 4 days. I changed the power supply. I was previously using an 12V output from the inverter which seems to only provide about 100mA ...