Open ddurkee-badgermeter opened 4 months ago
I have to ask... Is this using the nuget package?
There's a whole heap of changes to the underlying Bluetooth.windows.cs implementation that enable the filters that I don't believe have been bundled up yet.
The commit is back in march 2024.
Latest NuGet 4.0.37 has a number of code updates added since the last release.
I have the same issue here with the latest NuGet, the filter seems to get applied, but the list within the device chooser is empty. Is there any fix we can work around?
https://github.com/inthehand/32feet/issues/389 This above issue talks about this, but it still does not work for ScanForDevicesAsync on 4.0.36, even though in the linked issue it was marked resolved and this is implemented in 4.0.36.
library: InTheHand.Net.BluetoothLE version 4.0.36. framework: .net 7 target version: 10.0.22621.0 target os: windows application: Console (eventually WPF)
Basically I work for a hardware company that manufactures devices that speak serial or bluetooth. We have already developed a MAUI mobile app to speak to these devices via BLE. Also a desktop app to speak to these devices serially. The new wanted functionality is the switch-swap between the two, Bluetooth on desktop, Serial on mobile.
I have a Service UUID (unique for this device) that certainly connects on Android and iOS BLE connecting in our mobile app, now I'm trying to do the same in Desktop using 32Feet. I'll include my console app that I'm using to connect:
(replacing the unique service GUID with all 0's for the code snippet provided in this issue...)
on RequestDeviceAsync -> the normal Windows bluetooth device list window appears but shows no device was found. So apparantly this filter is being applied but my device just isn't being discovered (despite this being the exact way I do it in the mobile app, set a filter on the scan using the service UUID and now we only see our company devices)
on ScanForDevicesAsync -> just returns ALL BLE devices in range despite the filter. Like the filter isn't even there... which was said to be fixed in this version from the linked issue, as mentioned before.
More information:
After selecting my device from the RequestDeviceAsync window, I'm able to discover services/characteristics with other unique UUIDs for this Bluetooth module. So it's just an issue with RequestDeviceAsync/ScanForDevicesAsync that do not filter based on a correct UUID.