This blog is the continuation of list controllers using HCI interface, to cover the same use case using DBUS interface provided by Bluez. We will be using the “GetManagedObjects” methid to get the list of Bluetooth controllers.
Using GDBUS Proxy:
If Bluetooth service is not running, you can start it using,
systemctl start bluetooth
As described in the in Bluez Blog D-Bus ObjectManager section, one should use “GetManagedObjects” method provided by the “org.freedesktop.DBus.ObjectManager” interface to get list of available Bluetooth controllers by filtering the interface name againt “Adapter1“. Here in our examples, after obtaining the object paths, we are using the “org.freedesktop.DBus.Properties.Get” method in “org.bluez.Adapter1” interface to get the Name and MAC address of the Bluetooth controllers. When more then one Bluetooth controller is found, this example will list the Name and Address for all the controllers.
Similarly one can use the same method to get all the other properties of the controller (will be in next blog).
We can use dbus-send to explore the same information. Try the below command.
dbus-send --system --print-reply --type=method_call --dest='org.bluez' '/' org.freedesktop.DBus.ObjectManager.GetManagedObjects
One should be cautious when using GDBUS proxy based implementation in real application, because
- If the service provider (Bluez in this case) is disappeared/crashed/restarted, then our proxy connection will be invalidated (in dangling state)
- This can even happen when “StopWhenUnneeded=yes” option is specified in systemd service file “Unit” section.
- Using such danging proxy will result in Segmentation fault.
To avoid such cases, one should watch “InterfacesRemoved” and “InterfacesAdded” generated on the “org.freedesktop.DBus.ObjectManager” interface to update the proxy to service path/name.