Timeout Error #1359
Comments
|
Is this still a problem using the |
|
Sorry, I haven't tried it in the |
|
Yes, this problem still occurs with the Logs Wireshark Logs |
|
I don't see any problem here. Since there is nothing in the program to keep the device connected, it connects and disconnects as expected. If you replace |
|
I'm sorry that the above code caused you misunderstanding. After my debugging, the program did not run to the pass code line but directly stuck. Here's my new example, which works fine on Linux: |
|
Where does the new program get stuck? Do you have logs for it? |
|
It's still stuck in the same place, and it doesn't raise a Timeout Error. Logs |
|
If I comment out the exception caught by try BaseException at line 728 in /bleak/winrt/client.py/, it throws a Timeout Error. The exceptions are as follows: |
That is really strange. If you hit ctrl+c when it is stuck on What is the stack trace? It seems like the Is the issue reproducible on a different computer? |
|
Yes, I tried another Windows device and it had the same problem I am running the code in debug mode. The |
|
Do both computers have the same Bluetooth chip and driver version and Windows version? What happens if you make the timeout longer? |
|
The wireshark logs show that the device is never responding to a read request of Peripheral Preferred Connection Parameters attribute. So that would explain why Windows might be locking up waiting for the device to respond. If you have control over the firmware on the device, you could try fixing this attribute. |
dlech
added
Backend: WinRT
|
I was having the same problem. And finally found a solution. When I first encountered this problem, I thought it would be easier to solve it if I stopped using python and redeveloped with UWP's C# API. However, I found a similar stuck problem occurs in UWP, too. Debugging firmware of Windows 10 device driver is a very daunting task. So I returned from the UWP C# environment to the python interpreter environment, typed "py -m pdb my_script.py" and tried a step run. However, the step execution does not cause the stuck phenomenon. I wondered if some subtle timing was affecting it. I came across this page through an Internet search and saw "max_pdu_size_changed_handler: 23" at the end of the log data, which I thought looked familiar. My log was also stuck near the same event. I traced that the event occurs when power is turned down by power saving feature of BLE device and communication is interrupted from BLE device. So I set up an experimental environment in which the BLE device would power down for a short period of time. The debugging target is the client.py file of the BLEAK library. The location of the file differs depending on the installation environment, but at my place it was installed here. ~/AppData/Local/Programs/Python/Python311/Lib/site-packages/bleak/backends/winrt/client.py And after trying the phenomenon several times, and after some broken communication, I found that the place where the service component is disposed of gets stuck. And it doesn't get stuck on step execution. So I added a wait time just before disposing, and it no longer occur the problem. In my case, the wait time was about 60 msec, so I added a 100 msec wait time to give it a little extra time. Around line 476 (depending on version) Around line 745 (depending on version) In conclusion, this debugging showed that a hold time (or keep-alive time) of more than 60 msec is required from unsolicited disconnection event to GattDeviceService.close(). I was able to avoid the stuck problem by modifying the python BLEAK client source code, but this seems to be a usage issue of Windows' GATT (GattDeviceService class) and not the device driver's issue nor the device firmware's issue. |
It appears that GattDeviceService.Close() can hang forever under certain circumstances. This change adds a 0.1 second delay before closing services to see if that helps. Fixes: #1359
It appears that GattDeviceService.Close() can hang forever under certain circumstances. This change adds a 0.1 second delay before closing services to see if that helps. Fixes: #1359
bluetoothctl -v) in case of Linux:Description
Please understand that I am writing using a translation tool.
I represented the searched Bluetooth device in a list box and tried to connect to the device by selecting it. However, processes stuck in bleak= > 0.20.0, and timeout in bleak==0.19.5
What I Did
This code is a part of the whole code.
Logs
Wireshark Logs
log.zip
The text was updated successfully, but these errors were encountered: