Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SP16S020L16S100A: device communication timed out #58

Open
4 tasks done
ThomasCr opened this issue Sep 30, 2024 · 10 comments
Open
4 tasks done

SP16S020L16S100A: device communication timed out #58

ThomasCr opened this issue Sep 30, 2024 · 10 comments

Comments

@ThomasCr
Copy link

Checklist

  • I have enabled debug logging for my installation.
  • I have filled out the issue template to the best of my ability.
  • This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
  • 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...
@ThomasCr ThomasCr added the bug Something isn't working label Sep 30, 2024
@ThomasCr
Copy link
Author

@ThomasCr
Copy link
Author

This are the two usb sticks I use

image

hci0 is directly connected to my HA installation
hci1 is connectet over usbip

@ThomasCr
Copy link
Author

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}

@patman15
Copy link
Owner

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?

@ThomasCr
Copy link
Author

ThomasCr commented Oct 3, 2024

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.

syssi/esphome-jbd-bms#101

I also uploaded a communication dump there - maybe it provides more information.

@ThomasCr ThomasCr changed the title DWCE00531J-029: device communication timed out SP16S020L16S100A: device communication timed out Oct 3, 2024
@patman15
Copy link
Owner

patman15 commented Oct 3, 2024

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.

@ThomasCr
Copy link
Author

ThomasCr commented Oct 3, 2024

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:

  1. in HA is the BT stick still connected
  2. 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.

@patman15
Copy link
Owner

patman15 commented Oct 4, 2024

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!

@patman15 patman15 added more info needed and removed bug Something isn't working labels Oct 26, 2024
@patman15
Copy link
Owner

patman15 commented Oct 29, 2024

@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? 🖕

@patman15
Copy link
Owner

patman15 commented Nov 1, 2024

Issue fixed (to be confirmed) with v1.7.1.

@patman15 patman15 removed the bug Something isn't working label Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants