Resource busy. BraunPWR BMS

[bialy39]

Hello.
I have very often this type of errors.
Is it means that somebody else is connecting to my BMS?

INFO [basebms] CER2601-022-030-020|D768: failed to initialize BMS connection (BleakDeviceNotFoundError)
ERROR [sampling] <bmslib.models.BLE_BMS_wrap.BMS object at 0x7f127dd70980> device not found, retry in 7 seconds (could not connect to 24:19:72:18:D7:68: [Errno 16] Resource busy: 'l2cap connect to 24:19:72:18:D7:68')
INFO [basebms] CER2601-022-030-020|D768: failed to initialize BMS connection (BleakDeviceNotFoundError)
ERROR [sampling] <bmslib.models.BLE_BMS_wrap.BMS object at 0x7f127dd70980> device not found, retry in 11 seconds (could not connect to 24:19:72:18:D7:68: [Errno 16] Resource busy: 'l2cap connect to 24:19:72:18:D7:68')
...
ERROR [basebms] CER2601-022-030-020|D768: TX BLE request error (BleakError)
...
INFO [bt] bt_diagnostics 24:19:72:18:D7:68: NOT seen during 3.0s scan on adapter=default (adapters=[{'index': 0, 'name': 'hci0', 'mac': '8A:88:4B:61:CA:44', 'bus': 'USB'}]) (26 other devices in range)
...
ERROR [main] 1 exceptions occurred fetching BMSs
ERROR [sampling] Error (num 1, max 200) reading BMS: TimeoutError at aiobmsble/basebms.py:435 in _await_msg()

Regards.

[fl4p]

No, most likely nobody over the air — it is something on your own Pi.

You are running ble_stack: bluek. That message is the kernel refusing the L2CAP connect with EBUSY, and there is only one place it can come from:

/* net/bluetooth/l2cap_core.c, l2cap_chan_connect() */
if (cid && __l2cap_get_chan_by_dcid(conn, cid)) {   /* cid = 0x0004, the ATT channel */
        hci_conn_drop(hcon);
        err = -EBUSY;

So the host already has a link to the BMS and something local already owns its ATT channel — normally bluetoothd, i.e. Home Assistant's own Bluetooth integration or another add-on that connected to the BMS. Unlike the BlueZ/D-Bus stack, which multiplexes one ATT channel between its clients, bluek needs CID 4 for itself, so it cannot share.

That also explains the other line: a peripheral stops advertising while it is connected, so the scan does not see it. One cause, two symptoms — not range, not a phone.

Check on the host:

bluetoothctl info 24:19:72:18:D7:68     # "Connected: yes" -> something local owns it
btmgmt con

Two fixes: keep HA's Bluetooth integration away from that MAC (ignore the discovered device), or set ble_stack: bleak so batmon and HA share bluetoothd's link.

I have also changed bluek: it now drops the offending link via mgmt before retrying, and reports BleakDeviceBusyError naming the real cause instead of "device not found". That will be in the next release.

[fl4p]

That is more than enough — you solved it. Well done, and no apology needed for the DeepSeek route; the config works, which is the only thing that counts.

For the record, what your YAML proves about this BMS, because one detail is not in the manufacturer's PDF:

• SOI is 0x3E (>), not 0x7E (~). Everything else is YD/T 1363: VER 22, CID1 4A, CID2 42, INFO = ASCII pack number, LENGTH with the nibble checksum, CHKSUM = two's complement of the sum of every byte after SOI, EOI 0D. 9600 8N1.
• Response layout after SOI: VER, ADR, 42 echo, 00 return code, LENGTH, flag, SOC ×0.01, pack V ×0.01, cell count m, m × cell mV, ambient / pack / MOS temperature ×0.1 °C, temp count n, n × temperature, then current ×0.01, sign inverted.
• Finding the address by sweeping ADR 1…16 and seeing who answers is the right trick — worth keeping.

One question, because it decides how this would be documented: is the ESP32 on the internal TTL header where the FC41D was, or on an RS485 transceiver into one of the RJ45 ports? Two UARTs straight on GPIO1/3 and GPIO16/17 with no transceiver in the YAML suggests the former.

With that answered, everything needed for a wired ks48100 type in batmon is on the table. I'll come back to you on whether it gets added.

[fl4p]

Taking you up on the offer: please capture a reply. A driver for batmon is being written from your YAML right now, and one real answer from the BMS lets me test it against actual bytes instead of frames I built myself.

In baterie.yaml, add a debug: block to uart_bus2 and raise the log level:

logger:
  level: DEBUG
  baud_rate: 0

uart:
  - id: uart_bus2
    # ...keep your existing lines...
    debug:
      direction: BOTH
      dummy_receiver: false
      after:
        delimiter: "\r"
      sequence:
        - lambda: UARTDebug::log_string(direction, bytes);

Then paste two or three >>> / <<< line pairs from the log. The long <<< line starting with >22 is the one I need. Put level: WARN back afterwards.

[bialy39]

FC41D is removed and ESP32 is on the internal TTL header where the FC41D was:

>>> ">22014A42E00201FD28\r"
[uart_debug:157]: <<< ">22014200E0C6001C6014F9100D1B0D1C0D1C0D1C0D1C0D1C0D1D0D1D0D1D0D1D0D1C0D1C0D1C0D1D0D1C0D1A01400124012204012C01220122012201CE00000064012EE0220D000900000"
[uart_debug:157]: <<< "0010000000000230000000000000000000000000000000000000000000000D4E5\r"
...
[uart_debug:157]: >>> ">22014A42E00201FD28\r"
[uart_debug:157]: <<< ">22014200E0C6001C6114F9100D1C0D1C0D1C0D1D0D1C0D1D0D1C0D1D0D1C0D1D0D1C0D1C0D1C0D1C0D1D0D1A01400124012204012C01220122012201D900000064012EE0220E000900000"
[uart_debug:157]: <<< "0010000000000230000000000000000000000000000000000000000000000D4ED\r"
...
[uart_debug:157]: >>> ">22014A42E00201FD28\r"
[uart_debug:157]: <<< ">22014200E0C6001C6114FA100D1C0D1C0D1E0D1D0D1C0D1D0D1D0D1B0D1C0D1C0D1D0D1D0D1D0D1D0D1D0D1A01400124012204012C01220122012201D500000064012EE0220F000900000"
...
[uart_debug:157]: >>> ">22014A42E00201FD28\r"
[uart_debug:157]: <<< ">22014200E0C6001C6214FA100D1C0D1C0D1D0D1D0D1D0D1C0D1D0D1D0D1D0D1D0D1D0D1C0D1B0D1D0D1E0D1A01400124012204012C01220122012201D000000064012EE0220F000900000"
[uart_debug:157]: <<< "0010000000000230000000000000000000000000000000000000000000000D4E7\r"
...
[uart_debug:157]: >>> ">22014A42E00201FD28\r"
[uart_debug:157]: <<< ">22014200E0C6001C6314FA100D1B0D1B0D1D0D1D0D1D0D1D0D1D0D1D0D1D0D1D0D1C0D1D0D1D0D1C0D1D0D1A01400124012204012C01220122012201CA00000064012EE02210000900000"
[uart_debug:157]: <<< "0010000000000230000000000000000000000000000000000000000000000D4EC\r"
...
[uart_debug:157]: >>> ">22014A42E00201FD28\r"
[uart_debug:157]: <<< ">22014200E0C6001C6314FA100D1C0D1D0D1C0D1D0D1D0D1D0D1D0D1D0D1D0D1D0D1D0D1D0D1C0D1D0D1D0D1A01400124012204012C01220122012201C700000064012EE02211000900000"
[uart_debug:157]: <<< "0010000000000230000000000000000000000000000000000000000000000D4F2\r"

---

In addition I make some RS485-to-USB caputes. I did it in two modes.
I have to set to Voltronic communication protocol because my JSDSolar inverter doing weird things then is on different protocol. Therefore I made two captures; one on Voltronic and one for Pylontech.

FT232 plugged to slave battery:

rs485_voltronic1.zip
rs485_pylontech1.zip

FT232 plugged between master battery and inverter:

rs485_voltronic2.zip
rs485_pylontech2.zip

Please let me know if captured files are correct, if not I will capture again.

Regards.

[fl4p]

Those frames are exactly what was needed, thank you. They decode cleanly, and every field agrees with the others:

• 16 cells at ~3.356 V → 53.69 V pack voltage
• 87.17 of 120.0 Ah → 72.64 % SOC
• +4.62 A with the "charging" bit set, SOC rising frame to frame
• 9 cycles, SOH 100 %, temperatures 29–32 °C, both FETs on, no alarms

batmon now has a wired type for this BMS, braunpwr_uart, tested against your frames. It's on master and will be in the next release. It needs a 3.3 V USB-TTL adapter on the same header your ESP32 uses now: GND, TX↔RX crossed, VIN not connected.

- address: serial
  adapter: /dev/ttyUSB0
  type: braunpwr_uart        # braunpwr_uart:2 for pack address 2
  alias: bateria1

If your ESPHome setup already gives you what you want, there's no need to switch.

The RS485 captures: you don't need to redo them. They did show why your inverter reports "BMS Lost" while you capture: your PC sends every byte it receives straight back onto the bus. That is Linux's terminal echo, and the capture shows it plainly: 00 goes back out as ^@, 03 as ^C. The echo collides with the real traffic, which is why the replies in the Voltronic capture are garbled. If you capture again, run this first:

stty -F /dev/ttyUSB0 9600 raw -echo

What they show:

• Slave port, Pylontech mode: the master battery sweeps addresses with >22 <ADR> 84 84 …, the same > protocol as the internal header.
• Slave port, Voltronic mode: nothing on the wire at all.
• Master ↔ inverter, Pylontech: a clean exchange; all 60 frames have valid checksums.
• Master ↔ inverter, Voltronic: the inverter's Modbus requests are there, but the replies are wrecked by the echo.

[bialy39]

Thanks for reply.
I think that problem is solved... well almost solved. When I switch to pylontech protocol ESP32 is loosing BMS address and can't find it during (re)scan. Inverter is communicating with BMS, no "BMS Lost" alarm but ESP32 receives no response.
Do you know what happens under the hood? Batmon had no problems in that situation. Maybe FC41D firmware was dealing with this but my (well...not my but DeepSeek) yaml not.
You have some ideas?

Regards.

[fl4p]

Most likely the address moves. Switching to Pylontech (the DIP switches) changes the BMS address, and your scan stops at 16.

Your own captures show it: in Pylontech mode the inverter talks to the master battery at address 0x12 (18), and the master sweeps its slaves at 0x08…0x18. In Voltronic mode your pack answered at 01. The inverter keeps working because it uses the new address. Your ESP32 never gets there.

Quick test: in both scan_step_b1 and scan_step_b2, change

id(scan_addr1) > 16      →   id(scan_addr1) > 48
id(scan_addr2) > 16      →   id(scan_addr2) > 48

Your address detector already accepts 1–48, so nothing else needs to change.

Cleaner: the protocol has a "tell me your address" command (PDF section 9.4, command 52H). The BMS answers it whatever address you send, and its reply contains the real one. It only works point-to-point, which your header is:

>22014A520000FD9F\r

The reply looks like >22 + address + 5200 + 0000 + checksum. If you send it once in Pylontech mode and post the reply, I can make batmon find the address by itself. Until then, batmon needs it set by hand, e.g. type: braunpwr_uart:18 for 0x12.

[fl4p]

OK, so not the address range. (Side note: your detector only accepts addresses 1–48, so scanning up to 254 couldn't have found anything above 48 anyway. It doesn't explain this, though: 0x12 is inside that range.)

Your ESPHome can't tell us what the BMS actually does in Pylontech mode. It may:

1. stay silent on the header,
2. answer in the Pylontech dialect with ~ instead of >. uartex with rx_header: [0x3E] never frames that, so nothing reaches your sensors,
3. answer with > but an error code or a different echo, which your detector rejects.

The raw log tells these apart. In Pylontech mode, with the uart_debug block still on uart_bus2, send these three once each (a template button with uart.write is enough) and paste what comes back:

>22014A520000FD9F\r      "what is your address"; ignores the address field
>22124A42E00201FD26\r    our normal request, at address 0x12
~201246610000FDAA\r      exactly what your inverter sends in Pylontech mode

Also: which battery is on uart_bus2, the master (connected to the inverter) or the slave?

[bialy39]

I asked, of course, thinking computer about this problem. It conclusion is: master battery in PYL protocol is not YD/T 1363.3 but Pylontech ASCII.
Your button helps us 👍

About echos on RS485. At the beginning on fighting with scanning I had captured 0 frames. I asked, of course, mister thinking computer about this problem. It says: ble ble ble (<- it means that it is trying to explain me things) , run 'cat /dev/ttyUSB0' before, because if usb port is not actively is use then is just closed, so I need to make it active before capture begins.

Regards.