So, I investigated further and figured out that there were deadlocks when awaiting a few specific methods related to connecting and watching property changes for a device.
To be more specific, calling .Wait() here results in deadlocks:

powered-up/src/SharpBrick.PoweredUp/PoweredUpHost.cs

Line 58 in 9bb4714

onDiscovery(hub).Wait();

To get stuff working, I changed the discovery handler passed to Discover() to a Func returning a Task so it can be awaited, see: https://github.com/vuurbeving/powered-up/blob/cca3e7f81e91f84b2e7b3d846ca7250627831dd8/src/SharpBrick.PoweredUp/Bluetooth/IPoweredUpBluetoothAdapter.cs#L9

The code in my fork now is a complete mess, but... it works (for a single specific test scenario that is). Exact same behavior every time also. I haven't tested the windows bluetooth stack with a async discovery handler yet, maybe that breaks 🙄.

Now to clean this up and get a proper bluez support for this library, I think maybe we should define a proper api surface first, like you mentioned. Due to the very async nature of bluez, dbus and well, bluetooth itself, I'd like the approach to be 100% async. Also we should take care to apply ConfigureAwait properly where needed. Especially when working with a UI.

The only issue I currently have is that for existing devices, using bluez I can get the manufacturerdata (even after the device is disconnected, off and not broadcasting). But after a reboot I cannot get the manufacturerdata, it will fail. So the device will be there as an existing device, but no manufacturer data can be retrieved, so I can't actually properly determine if it's a LWP device or not. To do this, I need to actually connect to the device.
So if I implement the bluez Discover method by returning existing devices first, and subsequently newly discovered devices, this will be an issue, since for an existing device, I do not know for sure if it's a LWP device. The only thing I know about a device at this point is a BT address and a name ('Technic Hub'). To me it seems bad practice to return a list of (could be many!) devices without even knowing if they are actual LWP devices or not. And the alternative to tell the user of the library to use his/her bluetooth adapter only for LWP devices is not acceptable either 😀
Nevermind this, I can get the service UUIDs, even after reboot. It should be safe to rely on this to determine whether a device is a LWP device or not. We do however probably need to be able to deal with non-existing manufacturer data.
Currently it will crash here:

powered-up/src/SharpBrick.PoweredUp/Hubs/HubFactory.cs

Line 18 in 9bb4714

hub.Configure(0x00);

Add Linux Support using D-Bus / bluez #64

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions