Bluer lack of filtering support

[Taha-Firoz]

Right now we have bluez-async and bluer, since I've already written hundred of lines worth of code with btleplug I'm sure I'll be much more comfortable with bluez-async however I want something more objective in terms of features to help me decide.

The biggest issue with bluer for me right now is the lack of filtering, currently you have to iterate through each device through the discovered stream and await each device property individually. I seems like it'll be a lot of latency to the entire process of filtering and selecting the device. It does however have an option called register_gatt_profile and states

By registering this type of object an application effectively indicates support for a specific GATT profile and requests automatic connections to be established to devices supporting it.

How would one know whether such a device has connected automatically, would you need to query device.is_connected for each device? it may be my lack of experience but it seems like bluer has a lot of added latency.

My question is that is this something similar to what bluez-async does with it's services filter but also includes automatic connections.

Also they state that Device properties are queried asynchronously and may not be available yet when a DeviceAdded event occurs. Does bluez-async do something similar or does it wait until a device has it's data ready entirely.

[surban]

Do you mean the discovery filter?

It is currently not exposed in BlueR, but even if it was, you would still have to do filtering of the discovered devices as the underlying bluetoothd does not provide any guarantee that the filter is indeed applied, i.e. it may have been merged with another, more general filter set by another application. This is the reason why BlueR is currently not exposing the discovery filter.

I would assume that checking is_connected is the right way to check if a connection has been established when using GATT profiles. However, note that BlueR is just a front-end to bluetoothd and all connection logic is handled by it.

In general bluez-async and BlueR will behave very similar, since they are both calling functions of the Bluetooth daemon and do not implement any connection handling themselves. Also note that all await calls are due to D-Bus calls to the Bluetooth daemon and this does not imply that any radio exchange takes place. Thus response latency will be very low, even if you iterate over all discovered devices.

[Taha-Firoz]

Thank you for that clarification.

Can you also tell me if I keep a trusted, connected device object and the device goes out of range, will the device object remain valid. I'm asking because the device object requires just an address to be initialized so it doesn't seem like the object should be invalidated in case the a device goes out of range and comes back again (which would automatically reconnect since it's trusted).

[surban]

The device object will remain valid, but I cannot say for certain if it will automatically reconnect. Again, this is handled by bluetoothd and I haven't seen any behavior explicitly documented for that case.

[Taha-Firoz]

Apparently that's whats documented if a device is specified as trusted it should technically auto connect. I noticed in the services method it waits for services to resolve explicitly via self.wait_for_services_resolved().await?;, why should you check is_services_resolved then.

[surban]

I don't know your use case. Maybe you are connecting to multiple devices simultaneously and don't want a delay to occur when calling the services method. If you have a simple use case, you can just follow the GATT examples from the repository.

[Taha-Firoz]

Yup thank you I've gotten everything going, I'll make a separate discussion for any more questions.