-
Notifications
You must be signed in to change notification settings - Fork 310
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
Unhandled success response from org.bluez.Adapter1.ConnectDevice #806
Comments
Since this feature is behind the
I see what you mean. I suppose the first thing to do would be to read the return value from the |
Thanks for your input! I think your hunch is right - The path returned from
After a bit of searching in the linux-bluetooth mailing list, it seems like this lack of a connection signal may be intended. The developers seems to want to keep this object state internal to the bluetooth daemon. Here's the original patch, and there are a couple of revisions after this. Do you know of a way I can "force" my application to use the other code path of connecting using the |
Bleak should only be calling #713 (comment) suggests that |
I've been playing around with different scanning/connection approaches, and found that I can connect much more reliably when I scan using the So for my immediate use case, I'll stick with this new approach. I agree that
|
Generally, you want to stop scanning whenever possible so you don't drain the battery of any BLE devices in the vicinity. Since the delay in |
This fixes a number of bugs by moving the `BleakClient` state management to the new global BlueZ manager object. - Calling "GetManagedObjects" each time we connected caused performance issues. Fixes #500. - Calling "ConnectDevice" didn't work as expected and has been removed/ Fixes #806. - BleakClient didn't handle "InterfacesRemoved" which resulted in an invalid service dictionary in some cases. Fixes #882.
The fallback to "ConnectDevice" is removed in #902 (along with many other changes). Can you please test? |
0.14.2
Python 3.10.4
bluetoothctl -v
) in case of Linux:bluetoothctl: 5.64
Description
While trying to connect to a BLE device using the
BleakClient.connect
, the bleak library always raises aBleakError
exception saying "Connection was not successful!", but I am able to confirm the connection succeeded otherwise usingbluetoothctl
and the logs on my BLE device.After logging the result of the
org.bluez.Adapter1.ConnectDevice
method, and reviewing the documentation, it seems that this method returns a successful response that is not handled in theBleakClient.connect
method. Instead, the connect method waits for the Connected property to change to true.The DBus client never receives a PropertyChanged notification for the Connected property. I'm not sure if this is normal behavior while using the
ConnectDevice
DBus method, or if this is an issue only I am facing. However, I have confirmed with thebluetoothctl info
command that the device is connected.What I Did
Here's a minimal example to reproduce the issue:
I also added two changes to help with logging while debugging this issue:
self._is_connected
in the hopes that the client just needs to wait a bit for the property to change.Here are the logs from running this example:
After this exception,
bluetoothctl
still confirms that the device is connected:Another strange datapoint is the
bluetoothctl
logs also do not log when the Connected property changes. But when I reset my BLE peripheral, I see a log showing when the Connected property changes to false.Let me know if you need any more information, I'm happy to help in any way.
The text was updated successfully, but these errors were encountered: