a new uart protocol for a Daly Smart 150A BMS?

[russt]

I just tried connecting a UART to my DALY Smart BMS, and things didn't work, so I started debugging the signals with a logic analyzer. It looks to me like there might be a new protocol being used? All the open source implementations I've seen have 0xA5 as a start byte and a request packet length of 13 bytes, whereas when I eavesdrop on the communication between the bluetooth dongle and the BMS what I see is a start byte of 0xD2 and a request packet length of 8 bytes.

It feels very strange to me! Has anyone seen something similar?

The BMS I'm trying to talk to is this one (amazon link https://www.amazon.com/gp/product/B0CXTBS7VH):
DALY Smart 16S BMS 48V with WiFi Module and CAN 485 Communication Protection Board for LifePO4 Lithium Battery Pack(16S 48V Smart BMS+RS485+CAN+WiFi Module，150A)
battery serial number 20240523
software version: 11_240518_K00T
SN code: 226JD150403780
Firmware Version: 3.3.0

When looking at the bluetooth dongle traffic in the logic analyzer I see requests that look like these:

# d2 03 00 80 00 29 96 5f
# d2 03 00 00 00 3e d7 b9
# d2 03 00 a9 00 20 87 91
# d2 03 00 c9 00 03 c6 56
# d2 03 00 cc 00 02 17 97
# d2 03 00 3e 00 09 f7 a3
# d2 03 00 57 00 0c e7 bc
# d2 03 00 d7 00 01 27 91

and I see much longer strings of data coming back. I can also replicate this without the dongle, by programming an esp32s2 to send a "d2 03 00 00 00 3e d7 b9" request, and I get back a longer string of bytes that seems similar to what I see with the dongle.

If I look at the traffic when connected to an esp32s2 running esphome and the daly_bms component, I can see that the esp32 is sending out requests with the "a5" start byte, but I can't see any response from the BMS.

I've asked Daly about this, but haven't gotten a response yet. Thought I'd also ask here, as you all seem to have a hotbed of diy innovation going on

 

[russt]

So as an update to this, it turns out that the Daly BMS is communicating using the modbus protocol, which is totally separate from the RS485 and CAN bus protocols. Daly tech support came through for me and gave me pretty complete documentation on the protocol, which I translated into English using google translate and am attaching here.

As a really nice side benefit, esphome has great support for the modbus protocol. Using their modbus components, I can interface to the BMS without doing any programming at all (well, barely any ).

 

[russt]

Here is the esphome configuration that I'm using... hope it helps anyone who runs into something similar.

### the main esphome configuration file, leaving out everything except the modbus specific sections
uart:
  - id: uart_1
    baud_rate: 9600
    tx_pin: GPIO7
    rx_pin: GPIO9
    debug:
      direction: BOTH
      dummy_receiver: true
      after:
         timeout: 100ms
      sequence:
        - lambda: UARTDebug::log_hex(direction, bytes, ' ');

modbus:
  - id: modbus_client
    uart_id: uart_1

modbus_controller:
- id: modbus_device
  address: 0xd2
  modbus_id: modbus_client
  #setup_priority: -10
  update_interval: 10s
 
sensor:
  -platform: modbus_controller
    modbus_controller_id: modbus_device
    name: cell1
    register_type: holding
    address: 0x00
    unit_of_measurement: "V"
    value_type: U_WORD
    accuracy_decimals: 3
    lambda: return .001 * (float)x;

  -platform: modbus_controller
    modbus_controller_id: modbus_device
    name: temperature1
    register_type: holding
    address: 0x20
    unit_of_measurement: "C"
    value_type: U_WORD
    accuracy_decimals: 0
    lambda: return x-40

  -platform: modbus_controller
    modbus_controller_id: modbus_device
    name: voltage
    register_type: holding
    address: 0x28
    unit_of_measurement: "V"
    value_type: U_WORD
    accuracy_decimals: 1
    lambda: return .1 * (float)x;

  -platform: modbus_controller
    modbus_controller_id: modbus_device
    name: current
    register_type: holding
    address: 0x29
    unit_of_measurement: "A"
    value_type: U_WORD
    accuracy_decimals: 1
    lambda: return .1 * (float)x;

  -platform: modbus_controller
    modbus_controller_id: modbus_device
    name: faultBitmap1
    register_type: holding
    address: 0x3a
    unit_of_measurement: ""
    value_type: U_WORD