SP16S020L16S100A: device communication timed out
Checklist
- [X] I have enabled debug logging for my installation.
- [X] I have filled out the issue template to the best of my ability.
- [X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
- [X] This issue is not a duplicate issue of any previous issue.
Describe the issue
I am also new to the integration and most time, I get the error "DWCE00531J-029: device communication timed out" My Stick is near the BMS, to I hope it is not a wireless problem. Also there is a special constellation, because the stick I use is connected to a raspberry-pi close to the BMS and at least is connected to my HA installation with usbip.
I also tested to deleted the device in the integration and could find it again. But at least the same error pops up.
Reproduction steps
how I already told, I mostly always get this error.
Debug logs
I will upload the logfile. Github complains about a too long body...
This are the two usb sticks I use
hci0 is directly connected to my HA installation hci1 is connectet over usbip
I the logfile we can also see, that the integration uses this hci1 device, when we look at the source definition:
2024-09-30 09:18:11.413 DEBUG (MainThread) [custom_components.bms_ble] device data: {'name': 'DWCE00531J-029', 'address': '10:A5:62:23:B8:B5', 'rssi': -127, 'manufacturer_data': {}, 'service_data': {}, 'service_uuids': ['00001800-0000-1000-8000-00805f9b34fb', '00001801-0000-1000-8000-00805f9b34fb', '0000180a-0000-1000-8000-00805f9b34fb', '0000ff00-0000-1000-8000-00805f9b34fb', '00010203-0405-0607-0809-0a0b0c0d1912'], 'source': '00:E0:12:37:43:91', 'advertisement': AdvertisementData(local_name='DWCE00531J-029', service_uuids=['00001800-0000-1000-8000-00805f9b34fb', '00001801-0000-1000-8000-00805f9b34fb', '0000180a-0000-1000-8000-00805f9b34fb', '0000ff00-0000-1000-8000-00805f9b34fb', '00010203-0405-0607-0809-0a0b0c0d1912'], rssi=-127), 'device': BLEDevice(10:A5:62:23:B8:B5, DWCE00531J-029), 'connectable': True, 'time': 35937.157562589, 'tx_power': None}
Hi! I have checked the log (thanks for providing) and it's definitely no BT issue. I can see the BMS flooding the integration with answers. It responds with 30 times the same message for unknown reason. I don't know why it behaves that strange. According to the specification there should be one answer per one request. Is there a way to reset the BMS?
Is there a way to reset the BMS? I dont think so. It think it is related to the BMS Firmware Version.
It is a Vatrer Power 51.2v 100ah LiFePo4 battery - the BMS should be Jiabaida / JBD SP16S020
Informations from Overkill Solar App: Manufacturer: ZJDY Firmware Version: 6.2 Device Name: SP16S020L16S100A
In the meantime, I also tested with EspHome-JBD-BMS-Project and is works also somehow better. I get almost all Data, but not all.
https://github.com/syssi/esphome-jbd-bms/issues/101
I also uploaded a communication dump there - maybe it provides more information.
Well as said, the integration does receive all data, the BMS just sends it 30 times instead of once. So parsing is messed up because there is some protocol issue. I could work around it, but the actual problem is the repetitive transmission which makes no sense and will drain battery and block othe Bluetooth devices ... The specifications I know don't allow that behaviour. Nevertheless, I'll have a look at the communication dump.
Hi, I just want to reported back - I think it has something todo with the usbip connection.
I just bought me a other USB-BT stick (Cambridge Silicon Radio (CSR) -based adapter), which was recommended from the HA bluethooth integration docs.
I also saw, that the Realtek had reset problems, and I thought that those are the described problems from the HA BT Docs. I reactivated your add-on and tested with the new stick - got once a connection and than the adapter or connection "crashes" and newer comes back to life. Only option which heals the stick is to shutdown the raspberry on the server side (where the usb stick is) and power it up again.
On the server / adapter side:
[Okt 4 00:33] usbip-host 1-1.4: recv a header, 0
[ +0,000465] usbip-host 1-1.4: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection
[ +0,000039] usbip-host 1-1.4: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection
[ +0,000021] usbip-host 1-1.4: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection
[ +0,199812] usbip-host 1-1.4: reset full-speed USB device number 5 using dwc_otg
[ +0,237097] usbip-host 1-1.4: device reset
[ +0,160923] usbip-host 1-1.4: stub up
[ +0,380773] usbip-host 1-1.4: endpoint 0 is stalled
[ +0,003789] usbip-host 1-1.4: endpoint 0 is stalled
[ +0,003470] usbip-host 1-1.4: endpoint 0 is stalled
[ +3,416785] usbip-host 1-1.4: unlinked by a call to usb_unlink_urb()
[ +0,019511] usbip-host 1-1.4: unlinked by a call to usb_unlink_urb()
[ +0,005588] usbip-host 1-1.4: unlinked by a call to usb_unlink_urb()
on the client side:
[Oct 4 00:33] vhci_hcd: connection closed
[ +0.000058] vhci_hcd: stop threads
[ +0.000002] vhci_hcd: release socket
[ +0.000004] vhci_hcd: disconnect device
[ +0.000016] usb 3-1: USB disconnect, device number 19
[ +0.660333] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(3)
[ +0.000005] vhci_hcd vhci_hcd.0: devid(65541) speed(2) speed_str(full-speed)
[ +0.000007] vhci_hcd vhci_hcd.0: Device attached
[ +0.168128] vhci_hcd: vhci_device speed not set
[ +0.052046] usb 3-1: new full-speed USB device number 20 using vhci_hcd
[ +0.073990] vhci_hcd: vhci_device speed not set
[ +0.052966] usb 3-1: SetAddress Request (20) to port 0
[ +0.042290] usb 3-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[ +0.000004] usb 3-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ +0.000002] usb 3-1: Product: CSR8510 A10
[ +0.022525] Bluetooth: hci1: CSR: Setting up dongle with HCI ver=6 rev=22bb
[ +0.000007] Bluetooth: hci1: LMP ver=6 subver=22bb; manufacturer=10
[ +0.709834] Bluetooth: MGMT ver 1.22
[ +2.668072] vhci_hcd: unlink->seqnum 12203342
[ +0.000005] vhci_hcd: urb->status -104
[ +0.019092] vhci_hcd: unlink->seqnum 12203343
[ +0.000004] vhci_hcd: urb->status -104
[ +0.005522] vhci_hcd: unlink->seqnum 12203344
[ +0.000003] vhci_hcd: urb->status -104
I think maybe the different kernel version / distibutions dont work well together - dont know.
But I think there is no option for me, when the usbip connection is not working.
EDIT:
after researching more, I am not sure any more... that was also the point where I reported the issure: because:
- in HA is the BT stick still connected
- and I can connect to the BMS from the usbip client (where HA is running)
thomas@zentrale:~$ bluetoothctl connect 10:A5:62:23:B8:B5
Attempting to connect to 10:A5:62:23:B8:B5
Connection successful
maybe we just close the issue - I am mostly happy with the ESP - I mean I don't wanted to use any extra ESP, because I already have that raspberry pi there... but at least, when I need it, it runs better (with more details and the option to switch discharge on/off) with the Esphome project.
maybe we just close the issue
That's up to you. I would be interested of I have an issue in the protocol implementation, although I can't think of any reason that would lead to a multiplication of messages, especially because I compared the protocol implementations l, but you never know ...
I reactivated your add-on and tested with the new stick - got once a connection and than the adapter or connection "crashes" and newer comes back to life. Only option which heals the stick is to shutdown the raspberry on the server side (where the usb stick is) and power it up again.
The integration uses the provided BT stack of Home Assistant so there is no modification by me. Thus, I would still suspect a BT stack issue in lower levels. Are you using a HASS installation (or could you try one?) or a different installation method of Home Assistant?
So, depends on your motivation on how to proceed, either way thanks for reporting back and giving some hints in case somebody else suffers the same issue!
@ThomasCr I think by accident I stumbled over the problem you described and currently I'm able to reproduce it. Will let you know if I can fix it, maybe you are willing to test a fix? :middle_finger:
Issue fixed (to be confirmed) with v1.7.1.
This issue is stale because it has been open 32 days with no activity. Remove stale label or comment or this will be closed in 8 days.
This issue was closed because it has been stalled for 8 days with no activity.