Open fazalmajid opened 2 years ago
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:
interface{}
mapinterface{}
when the property is setBy the way, there is a workaround to this. If you call GetProperty
and specify ManufacturerData
instead of using the ManufacturerData()
API you will get an interface back that you can pull the data from.
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
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