Open furgerf opened 5 months ago
Thank you for the very good debug information as this allowed me to quickly narrow down the issue.
One of the recognised issues with dbus-python is that it "guesses" at types. It is guessing at INT32
wrapped as a VARIANT
. My assumption is that somewhere in the stack there is a better job being done on checking if that is the signature for the property is correct. And of course it isn't. It should be a UINT32
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt?h=5.53#n283
The quick fix is to set the dbus type when setting the property e.g.
adapter.discoverabletimeout = dbus.UInt32(130, variant_level=1)
Longer term, it is to go through the code and update the property setters. For this particular property it would need to go from:
@discoverabletimeout.setter
def discoverabletimeout(self, new_timeout):
self.adapter_props.Set(constants.ADAPTER_INTERFACE,
'DiscoverableTimeout', new_timeout)
to
@discoverabletimeout.setter
def discoverabletimeout(self, new_timeout):
dbus_value = dbus.UInt32(new_timeout, variant_level=1)
self.adapter_props.Set(constants.ADAPTER_INTERFACE,
'DiscoverableTimeout', dbus_value)
Great that works, thanks!
I'm able to read out the current
DiscoverableTimeout
on an instance ofAdapter
but when I try to write it, I get the following exception:This is the default value, I can change it using
bluetoothctl
and the adapter instance correctly returns the modified value:There's nothing in
bluetoothctl
orjournalctl
but I see the following withbusctl monitor org.bluez
:Using bluezero 0.8.0 with bluez 5.53, running in a snap on UbuntuCore.