> On May 8, 2017, at 11:07 AM, Cody P Schafer <dev@xxxxxxxxxx> wrote:
>
>> NAME TYPE SIGNATURE RESULT/VALUE FLAGS
>> .GetAll method s a{sv} -
>
>>
>> BUT… if I try to access as GetAll as you suggest:
>>
>> $ sudo busctl call :1.5 /nic/twigpilot org.freedesktop.DBus.Properties GetAll
>> No such interface 'org.freedesktop.DBus.Properties' on object at path /nic/twigpilot
>
> GetAll takes a string argument which is the interface name. Try:
>
> $ sudo busctl call :1.5 /nic/twigpilot org.freedesktop.DBus.Properties
> GetAll org.bluez.LEAdvertisement1
Argh (pun). I *thought* I had had that query working on Friday and was surprised when I was running it this morning to report that it wouldn’t work. So yes,
$ sudo busctl call :1.5 /nic/twigpilot org.freedesktop.DBus.Properties GetAll s org.bluez.LEAdvertisement1
a{sv} 6 "ServiceData" a{sv} 0 "ServiceUUIDs" as 0 "SolicitUUIDs" as 0 "Type" s "peripheral" "IncludeTxPower" b true "ManufacturerData" a{sv} 0
I *can* do the GetAll() query as Luis asked for. And resolves my intermediate question. But brings me back to the original question which behavior still persists.
As I said, dbus is a relatively new thing for me. I *think* naively that the problem lies somewhere around this call:
bus.register_object('/nic/twigpilot', self, None)
When I look at just simple `busctl` output, I see (amongst others):
$ busctl
NAME PID PROCESS USER CONNECTION UNIT SESSION DESCRIPTION
...
:1.15 1677 python3 root :1.15 serial-getty@xxxxxxxxx…ce - -
...
:1.4 1385 bluetoothd root :1.4 bluetooth.service - -
org.bluez 1385 bluetoothd root :1.4 bluetooth.service - -
In my naive understanding… my python3 has an unnamed connection to the system bus (i.e. :1.15). And the bluetoothd has an unnamed connection at :1.14. But bluetoothd has also set up a repeatably accessible service at org.bluez. My python program has registered an object that has the necessary interfaces at the path /nic/twigpilot, but it hasn’t done anything to tie it in to the org.bluez service. And yet, when I look at the docs https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt…; It describes this object as belonging to the org.bluez service.
pydbus has an API higher up than register_object() called publish() (https://github.com/LEW21/pydbus/blob/master/doc/tutorial.rst#object-publication) which not only places the object at the given path, but also "binds the service to the given bus name”. But if I use that api instead of register_object(), I get the following error
RuntimeError: name already exists on the bus
It could be that I’m barking up the completely wrong tree with this. I do find myself wishing BLE were exposed via a good old fashioned C library or some sort of pseudo file system thing like sysfs. But I’m trying to keep an open mind and hope the value-of-dbus light bulb will trigger soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
