Duplicating and deduplicating advertising data in detection callback

[dlech]

• bleak version: 0.10.0
• Python version: N/A
• Operating System: All
• BlueZ version (bluetoothctl -v) in case of Linux: N/A

Description

Currently, the behavior of the callback in BleakScanner.register_detection_callback() behaves differently on all of the different platforms.

• On Windows, we receive separate callbacks for each different advertisement type.
• On macOS, advertisements are deduplicated by default but there is an option to disable this. EDIT: macOS 12 seems to have changed the default behavior to call the delegate callback when the RSSI changes.
• BlueZ has a similar option for changing the behavior of duplicate data, but it only affects ManufacturerData and ServiceData.
• In the BlueZ backend, we are currently issuing a callback every time a property changes. This is dominated by the RSSI property which changes many times per second which results in many more callbacks compared to other platforms.

So I would like to propose modifying Bleak to be more consistent across platforms in this regard.

1. Advertising data should be deduplicated by default. This is already the default on macOS and Linux with the exception of the RSSI issue mentioned above.

   • On Linux, we can get closer by ignoring RSSI property changes from BlueZ. However, if we completely ignore the RSSI property changes, we will likely not have a way to tell if a device is actively advertising or not. But we could add some code to only trigger a callback on the first RSSI property change and then only trigger on other property changes after that for a given devices. BlueZ has a new experimental advertisement monitor API. This would be better that the RSSI property check workaround. However, this requires a >= 5.10 Linux kernel, so it will be some time before this is available for most people.
   • On Windows, I am not aware of any built-in deduplicating capabilities, so we would have to implement something to simulate the other platforms. That is, we would need to cache advertisements with types < ScanResponse (there are 4 such types, but I think we should only receive 1 out of the 4 per device). Then wait some time to see if we also get a ScanResponse advertisement. The information from these two advertisements gets combined. The information from these two gets combined and if it is different from the previous data received, a callback is made.

2. If there is need for allowing duplicate advertising data, then a common kwarg option should be added to BleakScanner to allow this on all platforms.

   • On macOS, this would probably be as simple as setting CBCentralManagerScanOptionAllowDuplicatesKey to True.
   • On BlueZ, it would probably be as simple as modifying the DuplicateData option in the call to SetDiscoveryFilter.
   • On Windows, it would probably have to be implemented manually in Bleak unless we can find something in the Windows API docs that I missed.

[dhalbert]

Our experience is that the Linux kernel always deduplicates advertisements. See #235. So it's great about the new experimental API, but I thought that turning off de-duplication via Bluez would not do anything due to the current kernel code. Could you explain if I am misunderstanding? Thanks.

We had been using advertisements to transmit sensor readings UDP-style, and ran into this issue, forcing us to use "raw" hcidump output

[dlech]

I didn't know about the kernel part. I haven't tried changing the setting yet to see what really happens.

[guiserle]

Apologies in advance to bring this issue back to life, but I am not sure if I fully understood the motivation for the changes.

I have an application running on windows and the periodic RSSI report was quite useful to detect what devices where performing advertising and what stopped doing it (I had a timer so if I didn't receive any advertisement packet of a device after XX seconds I assumed that device was no longer advertising).

However now I am trying to port this behavior to linux and I found that I only receive one advertisement report for each device until I stop scan and re-start it again.

Would it be any way to periodically receive advertising reports of devices even if they have already been seen on the scan session?

If there is not I would propose to modify this check so, instead of checking the "first time" a device has been seen, it would check that the last time it was reported was not too close to current moment.

[dlech]

I have an application running on windows and the periodic RSSI report was quite useful

I agree this is useful. Since the default behavior changed in macOS and we removed the "first seen" filter in BlueZ backend in #964 I'm going to go ahead and close this issue as won't fix.

If there is a need for filtering duplicates for performance reasons, we can reconsider.