Interface to access all advert rssi values received (refactoring Bermuda)

[agittins]

Greetings...

I would like to re-work how Bermuda processes BLE advertisements, and wanted to open a discussion about whether some API changes might offer the most efficient means of doing that, and express my willingness to chip in (or stand by in wonder).

I would like to be able to work with the timestamp and rssi of each advertisement received, for each distinct mac, from each scanner. This would allow bermuda to make better, faster decisions by applying its filtering/smoothing to more rssi values instead of being limited to a single value per update, which currently runs each second.

The actual processing of results would still happen on the update loop, as this seems to give an acceptable latency for most purposes, and gives a conveniently centralised place to skip cycles if processing times start to get too high.

One option might be for Bermuda to be able to register a callback for every received advert, but if the overhead of doing this is unacceptable, perhaps an interface where it could request "received timestamp/rssi tuples since timestamp" or similar could work.

I'm willing to entertain any ideas you might have on what could work efficiently, or if Bermuda would benefit from being restructured in some way (like using a separate thread to do its processing, or consuming adverts via a stream/pipe, publishing a cython lib as a dependency etc). I'm willing to spend the time to learn the methods that will work well - sometimes the trick is just knowing what they might be in the first place!

I've got some questions about the other aspects of how I interface with the bluetooth backend, but I think the first step is to work out some efficient options for consuming the advert rssi's, and I'll be able to ask better questions after I have a handle and direction on that, I think.

Happy of course to work on creating a PR to implement any changes required, or to benefit from someone else's implementation. I'd likely need a moderate amount of guidance in the former case, but I'm not shy about doing the required reading either.

[bdraco]

One option might be for Bermuda to be able to register a callback for every received advert, but if the overhead of doing this is unacceptable, perhaps an interface where it could request "received timestamp/rssi tuples since timestamp" or similar could work.

I think this is possible but I need to finish #219 first before I could think about how to do that. We could structure it so only users who have the callbacks registered would have to pay the performance penalty of having them delivered in the hot path. The check to see if we have any callbacks could be implemented in Cython so its cheap. It would probably end up at the very top of

habluetooth/src/habluetooth/manager.py

Line 494 in 341ca8e

def scanner_adv_received(self, service_info: BluetoothServiceInfoBleak) -> None:

[agittins]

That sounds very promising, thanks! I think that would probably solve my needs very neatly and sounds like a good general solution for other potential users.

I'll let you percolate the idea in the background for a bit while you sort out other stuff and we can go from there - let me know if you want any further context otherwise I'll sit tight :-)