-
-
Notifications
You must be signed in to change notification settings - Fork 185
Peripheral discovery API comparison
This page compares the APIs for discovering BLE peripherals on different platforms. This includes starting and stopping a scan, getting events for advertisements, and getting information about peripherals the system knows about in some way.
Calling StartDiscovery() on an org.bluez.Adapter1 starts discovery. This appears to be an active scan; there is no way to request a passive scan.
Various options may be set with SetDiscoveryFilter(dict filter), e.g. to filter by service UUID, MAC address or name, or to choose whether duplicate service data and manufacturer-specific data are included. This is set per application but applied system-wide, so if two different applications set different discovery filters then BlueZ will discover peripherals which match either filter and return them to both applications. Thus an application must be prepared to see peripherals it didn't ask for.
BlueZ maintains a set of peripherals which it knows about as D-Bus objects implementing 'org.bluez.Device1`. These may be queried cheaply at any time (without talking to hardware) to get the latest information that BlueZ knows about them. The set of peripherals is system-wide and persistent, so will change in response to other applications using Bluetooth (e.g. starting scans, connecting to devices). It includes not just peripherals which are currently in range, but also those that were discovered at some point in the past, or that have been paired.
There are no events directly corresponding to advertisements, but it is possible to use standard D-Bus interfaces to subscribe to signals for new objects being added (via org.freedesktop.DBus.ObjectManager.InterfacesAdded) or some properties being updated (via org.freedesktop.DBus.Properties.PropertiesChanged).