In this blog we will continue our understanding toward BlueZ to set the property in Adapter1 interface in continuation to our Get Property sample. As DBUS based applications can be accessed by any number of clients, modification a property needs to be informed to all the clients. In DBUS this can be done using signals.
So in this example we will also watch for the modification of a property which we change in our sample.
Code:
Signal Subscription:
To get the notification/signal before we change the property we must subscribe for the signal which we want with a callback function. To brief, from DBUS specification we have,
- PropertiesChanged – in org.freedesktop.DBus.Properties interface, which will be emitted whenever there is a change in property value.
- InterfacesAdded and InterfacesAdded – in org.freedesktop.DBus.ObjectManager interface, which will be emitted whenever a new interface/object path is added or removed for a service. We will examine this signal in details in for Bluetooth scanning blog.
In our case, we are be subscribing to PropertiesChanged signal using g_dbus_connection_signal_subscribe. In which we need to specify the following,
sender – Service of interest, org.bluez in our case
interface name – org.freedesktop.DBus.Properties. Bluez5 follows latest DBUS specification, i.e
org.freedesktop.DBus.Properties – Is the common interface which needs to be used by any objects paths for handling the properties. For example, /org/bluez/hci0 is the object paths for HCI0 bluetooth adapter which can have following interfaces,
- org.bluez.Adapter1
- org.bluez.GattManager1
- org.bluez.LEAdvertisingManager1
- org.bluez.Media1
- org.bluez.NetworkServer1
- org.freedesktop.DBus.Properties
org.freedesktop.DBus.Properties is designed in a such a way to handle properties of all the interfaces of an object path. So “org.freedesktop.DBus.Properties” will be present in all the object paths. To access the property for an interface, one must specify the interface name and property name.
org.freedesktop.DBus.Properties provides three generic methods,
- Get (interface name, property name) – Input: {ss} Output: {v}
- GetAll (interface name) – Input: {s} Output: a{sv}
- Set (interface name, property name, property value) – Input: {ssv} Output: None
Refer DBUS specification for more details.
member – “PropertiesChanged” i.e the signal of interest
We have also filters and flags along with object path to limit/narrow down the signal for our client application (will be covered in future blog).
Set property:
To set the property, as stated above we are using “Set” method in “org.freedesktop.DBus.Properties” interface i.e {ssv} as argument,
s – interface name : org.bluez.Adapter1
s – property name : Powered
v – value as variant
We are toggling the power state i.e switching the Bluetooth Adapter “on” and “off”.
Jumping back to signal handling:
Looking back in signal handler, the output format is “(sa{sv}as)“. Here,
s – Interface name in which the property is changed
a{sv} – Array of properties which are changed and it’s new value.
as – Invalidated property (which we will examine in our future blog in detail), not needed for this example.
By parsing the property array we will be able to identify the property which are changed, here we are straight comparing against the property name and printing it.
For the ease of understanding, the program’s main loop is exited after getting the power off notification in signal handling.
dbus-send:
Same way as stated in our previous blogs, setting the property and watching for the change in also possible using dbus-send. To set the Powered property, use the following
dbus-send –system –print-reply –dest=org.bluez /org/bluez/hci0 org.freedesktop.DBus.Properties.Set string:”org.bluez.Adapter1″ string:”Powered” variant:boolean:true
Signal can be monitored in dbus-send using,
dbus-monitor –system “type=signal,path=’path=/org/bluez/hci0′,interface=’org.freedesktop.DBus.Properties'”
2 Comments