DeviceWatcher does not expose BTLE service UUIDs in its DeviceInformation.Properties() : C++/winRT

[brianreinhold]

Given that one cannot connect to a device using the data from the AdvertisementWatcher, one turns to the DeviceWatcher. However, there is no way to intelligently filter the responses to work with all devices that support standard profiles. When creating the watcher, one can only specify a single UUID in the aqsfilter, so one cannot filter to handle all BTLE devices following the health standard profiles. It is also not possible to filter the response (discovered DeviceInformation) if one sets the aqsfilter to all BTLE devices as the properties are NULL.

Microsoft was clearly not thinking about standards in the design of their BTLE APIs. Profile service UUIDs are the same for all manufactures that make standard thermometers or heart rates monitors or BP monitors. Device names and BT addresses require out-of-band knowledge.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6c57c086-3015-37b6-5318-b90a8e1fc0ba
• Version Independent ID: 94556012-dcdd-1dde-c8e5-147e1d05d5c0
• Content: Bluetooth GATT Client - Windows UWP applications
• Content Source: windows-apps-src/devices-sensors/gatt-client.md
• Product: uwp
• Technology: peripherals-sensors-and-power
• GitHub Login: @eliotcowley
• Microsoft Alias: elcowle

[jevansaks]

Let's consolidate all the discussion into https://github.com/Microsoft/Windows-universal-samples/issues/1089 and re-open these issues when that concludes.

[FrankGorgenyi]

Hi Jevan,

I work on the Bluetooth team for the Windows Core OS. We own the APIs under Windows.Devices.Bluetooth. and I helped with the design for Windows.Devices.Enumeration. long ago so I am sure we can help.

We are dealing with some other escalations right now and we're a small team. I'll get to you later tonight or tomorrow.

Thanks, Fg