Giters

muka / go-bluetooth

Golang bluetooth client based on bluez DBus interfaces

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Device1.GetManufacturerData() fails

fazalmajid opened this issue · comments

commented

It fails with this panic:

2022/06/23 19:33:39 new event: 1 &{/org/bluez/hci0/dev_5B_85_EF_47_EC_5D 1} &{0xc00019bfe0 <nil> <nil> <nil> 0xc0001da000 <nil>}
panic: interface conversion: interface {} is map[uint16]dbus.Variant, not map[string]interface {}

goroutine 38 [running]:
github.com/muka/go-bluetooth/bluez/profile/device.(*Device1).GetManufacturerData(0xc0000edf78?)
	/home/majid/go/pkg/mod/github.com/muka/go-bluetooth@v0.0.0-20220604035144-0b043d86dc03/bluez/profile/device/gen_Device1.go:422 +0x7c
main.stream(0xc0000d80c0?)
	/home/majid/thass/thass.go:78 +0x15c
created by main.main
	/home/majid/thass/thass.go:114 +0x2b7

According to the BlueZ DBus API specs, the keys are indeed uint16, not string:

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

commented

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:

  • The template needs to be modified with some smarts to recreate a new interface{} map
  • The value needs to be coerced to an interface{} when the property is set
commented

By 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.

commented

Yes, that’s what I ended up doing. It’s less elegant, though.

commented

Hi during generation types can be overridden here

Glad to review a PR if you could sort this out. Thank you