-
-
Notifications
You must be signed in to change notification settings - Fork 125
Device1.GetManufacturerData() fails #163
Comments
I believe there are two issues at play here. The first is that types that have been overridden, don't carry the override through to the access methods, I've created #166 to address this. The second issue is that the property is set to a map with a dbus.Variant instead of interface{}. The type assertion cannot seamlessly do that conversion for us - we would need to recreate the map. I haven't wrapped my head around the codebase enough to understand what the correct solution is for this. As I understand it, one of the following needs to be done:
|
By the way, there is a workaround to this. If you call |
Yes, that’s what I ended up doing. It’s less elegant, though. |
Hi during generation types can be overridden here
Glad to review a PR if you could sort this out. Thank you |
Signed-off-by: deadprogram <[email protected]>
Signed-off-by: deadprogram <[email protected]>
Signed-off-by: deadprogram <[email protected]>
It fails with this panic:
According to the BlueZ DBus API specs, the keys are indeed
uint16
, notstring
:https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt#n249
I don't know if this API changed. Using BlueZ 5.64 on Alpine Linux 3.16
The text was updated successfully, but these errors were encountered: