Match characteristics based on their flags (read/write/notify/...)

[dossalab]

Some BLE devices expose multiple characteristics with the same UUID but different properties. For example, HID over BLE devices have two characteristics with UUID 0x2A4D:

• one with read + notify flags - input endpoint (keypresses, stick movements)
• one with write-without-response flag - output endpoint (haptics)

Currently the discovery loop matches UUID only, not only that but it re-assigns the characteristic on each match, so only the last discovered characteristic is made available to the user. This makes it impossible to access both endpoints.

After the change, something like this is possible:

#[gatt_client(uuid = "1812")]
pub struct XboxHidServiceClient {
    #[characteristic(uuid = "2a4d", read, notify)]
    pub hid_report: [u8; 16],

    #[characteristic(uuid = "2a4d", write_without_response)]
    pub hid_output_report: [u8; 8],
}

The idea is that if user requests a certain operation flag, it must be presented in props of the matching characteristic.
Also added a small guard to not re-assign chars that already have a handle.

[alexmoon]

Matching on properties isn’t right either. HID devices can have multiple input and output endpoints which will have the same uuid and properties. The builder API is recommended over the macro for these more advanced use cases.

[dossalab]

I'm not saying this is going to fix all possible issues with characteristic discovery, but isn't this still better than the current approach? Are there any possible ramifications?

[alexmoon]

The current approach is easy to understand. If we add complexity it will make it more confusing when it fails. Also, specifically for the HID service, you're going to need more control over other aspects like descriptors than the macro allows. I strongly recommend using the builder API instead of the macro for complex services like HID.

Also, this crate is pretty much in maintenance mode. Future development is happening with the trouble crate.