added BleakDeviceNotFoundError

[jochenjagers]

This is a first draft for BleakDeviceNotFoundError as discussed in https://github.com/hbldh/bleak/issues/527

[jochenjagers]

I basically only replace the BleakErrors with device not found messages by BleakDeviceNotFoundError But this covers not all functions/backends yet.

CoreBluetooth:

• [x] connect
• [ ] ~~pair~~ ("Pairing is not available in Core Bluetooth.")
• [ ] ~~unpair~~ ("Pairing is not available in Core Bluetooth.")

WinRT:

• [x] connect
• [ ] ~~pair~~ (Pair is not possible without connect at the moment)
• [x] unpair

BlueZ:

• [x] connect
• [ ] ~~pair~~ (Pair is not possible without connect at the moment)
• [ ] ~~unpair~~ ("Unpairing is seemingly unavailable in the BlueZ DBus API at the moment.")

p4android:

• [ ] connect
• [ ] pair
• [ ] ~~unpair~~ ("Unpairing is seemingly unavailable in the Android API at the moment.")

The Android backend does not have a check for the availability of the device yet.

[jochenjagers]

For Android the documentation is ambiguous. On the one hand: https://developer.android.com/guide/topics/connectivity/bluetooth/connect-gatt-server

The service will first call getRemoteDevice() on the BluetoothAdapter to access the device. If the adapter is unable to find a device with that address, getRemoteDevice() throws an IllegalArgumentException.

On the other hand: https://developer.android.com/reference/android/bluetooth/BluetoothAdapter#getRemoteDevice(java.lang.String)

A BluetoothDevice will always be returned for a valid hardware address, even if this adapter has never seen that device.

[dlech]

For Android the documentation is ambiguous.

It sounds like we shouldn't worry about it on android then.

[dlech]

In the connect methods, in addition to the optional scanner not finding the device,

...

I'm not sure what it would be in the other backends, so I guess we will have to do some experimentation to find out.

I suppose it could be the case that the non-BlueZ backends actually allow connecting to a device without having ever "seen" it before, in which case I guess there isn't an extra case to handle.

(As a side note, BlueZ has an Adapter1.ConnectDevice experimental method that in theory could be used to do the same, but we removed it recently because it doesn't seem to work as expected).

[jochenjagers]

From my point of view this is ready to merge now.

[dlech]

Thanks for updating!

[jochenjagers]

Thanks for updating!

Thanks for your fast and constructive feedback.