bluez-rs / bluez-async Goto Github PK

It could be useful to add the modalias to AdapterInfo, probably in a decoded form. This could be used to implement deviceplug/btleplug#138.

Hi,
Is there a reason why all the OrgBluezDevice1 properties are not implemented in bluez-async DeviceInfo struct (like class or icon) ?
These properties are available in device1.rs

Please add support for:
hadess/bluez@ecd604b

Added in 5.62

If you create multiple event streams, e.g. by calling session.event_stream().await? more than once, the second (and presumably subsequent) ones don't work until the previous one is dropped. This is the cause of deviceplug/btleplug#165.

Hey, I was checking out mijia-homie and running into issues setting it up--seemingly no devices are being found by the bluez-async scan at all (never mind whether they're the thermometers).

After some debugging, I've figured they get culled out in DeviceInfo::from_properties, specifically when we try to read the WakeAllowed field from the properties map. Looking at the devices in gdbus I see the property declared but without a value under devices: readwrite b WakeAllowed; (which is to say, it's not an ancient bluez version predating the field existing or so)

I searched around but couldn't really find any indication on whether some fields are mandatory and others optional. The network/bluetooth controller on this laptop is apparently Qualcomm QCA6390, if it somehow turns out to depend on controller hardware...

Simply changing to device_properties.wake_allowed().unwrap_or(false) seems to work fine (and would probably be a sensible default).

Add a way to check whether bluetooth is currently on.
Something equivalent to:

bluetoothctl show
Controller ...
...
Powered: no/yes

I want to be able to alert the user when they are trying to use my program without Bluetooth enabled.

I'm using bluez-async through btleplug and bluez-async is by far the biggest crate in my project because of all its dependencies. I recognize that some of these dependencies are absolutely necessary (dbus, futures), but I don't think that serde or serde-xml-rs are required for every use of this crate. Would it be possible to put serde functionality behind a feature flag so that bluez-async's dependencies can be limited as needed?

maybe zbus would be good? It's async, doesn't depend on any C library, so can be cross-compiled easily.

While building bluez-async v0.5.1, I encountered the following errors:
error[E0432]: unresolved import 'tokio::task::JoinError'
error[E0425]: cannot find function 'spawn' in crate 'tokio'

After inspecting the cargo.toml I found that in tokio v1.0.1, which is used by the most recent bluez-async, both the import and the function specified by the errors require the feature 'rt'. However, this function is only under the dev-dependencies for tokio, causing both errors:

[dependencies.tokio] version = "1.0.1"

[dev-dependencies.tokio] version = "1.0.1" features = ["macros", "rt", "rt-multi-thread", "time"]

How to fix:
Specify 'rt' as a feature with tokio, under the normal dependencies.

(This is my first time opening an issue on GitHub, and I didn't find any guidelines for creating an issue, so please leave constructive feedback if possible.)