Hi Anton, On Thu, Aug 15, 2024 at 2:30 PM Anton Khirnov <anton@xxxxxxxxxxx> wrote: > > Quoting Luiz Augusto von Dentz (2024-08-15 19:34:41) > > On Thu, Aug 15, 2024 at 1:26 PM Anton Khirnov <anton@xxxxxxxxxxx> wrote: > > > > > Also, the advertisement monitor interface already does almost exactly > > > what I want, except for the fact it forces me to receive advertisements > > > from devices I'm not interested in. > > > > Yeah, I was gonna say that, but this is a vendor extension, > > I don't follow, what exactly is a vendor extension? IIUC in-controller > handling of advertisement monitor or_patterns is a Microsoft extension, > but what I want is just a nontrivial device whitelist, which should be > standard. > > > not really following about forcing you to do anything, or you are > > saying you want to connect rather than parse something on the > > advertisement? It is a little bit hard to give you any advice if you > > are not really explaining what is the use case, > > I wanted to avoid flooding this list with too many unnecessary details, > but seems I went too far :) Sorry. > > I'm writing a data collector for bluetooth weight scales, which I'd like > to run in the background and work automatically without user > interaction. > Advertisement reports for a weight scale contain ServiceData that > indicates whether new measurements are available - when the collector > sees such an advertisement it should connect to the scale and retrieve > the measurements. Ok, enable LL Privacy: https://github.com/bluez/bluez/blob/master/src/main.conf#L139 And register the service UUID via GattProfile: https://github.com/bluez/bluez/blob/master/doc/org.bluez.GattProfile.rst That will get the bdaddr of the peripheral in the allowlist/whitelist... you are welcomed. > So what the collector needs from the bluetooth stack is to monitor > advertisement reports for a given list of devices (the scales it > previously registered with). > The advertisement monitor API almost gives me this, except it always > uses an unfiltered filter policy (as per the block right above the done: > label in hci_update_accept_list_sync()), which means advertisements from > all devices are processed by the kernel and sent to userspace. This is > not a fundamental problem, but it seems wasteful as the controller > should be able to filter just the devices I want. > > > also if you are involving a daemon then perhaps you are not really > > using bluetoothd? > > Just to be clear, I am using bluetoothd (via bleak), but AFAIU the issue > is in the kernel code. > > Thanks, > -- > Anton Khirnov -- Luiz Augusto von Dentz
