Hello,
I attempting to get the advertising data from a commercially available
sensor device using the DBus API.
The sensor device gives different manufacturer data depending if the
event type is ADV_IND or SCAN_RSP, as you can see below in the btmon
output.
With DBus I am subscribing to the InterfacesAdded signal which
triggers when the device has been found. However, it only seems to
give me the information for the SCAN_RSP.
If I subscribe to the PropertiesChanged signal on the device, that is
also only giving the data from the SCAN_RSP event.
How do I access both types of data with the DBus API?
Thanks,
Barry
$ bluetoothctl -v
bluetoothctl: 5.50
btmon output for sensor device:
> HCI Event: LE Meta Event (0x3e) plen 43 #1969 [hci0] 740.157687
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: DC:76:F7:E1:62:E0 (Static)
Data length: 31
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Blue Maestro Limited (307)
Data: 1b640e10010400e701a527f50100
Name (complete): DC76F7E1
RSSI: -44 dBm (0xd4)
> HCI Event: LE Meta Event (0x3e) plen 41 #1970 [hci0] 740.158684
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Random (0x01)
Address: DC:76:F7:E1:62:E0 (Static)
Data length: 29
Company: Blue Maestro Limited (307)
Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
RSSI: -44 dBm (0xd4)
@ MGMT Event: Device Found (0x0012) plen 74
{0x0002} [hci0] 740.158704
LE Address: DC:76:F7:E1:62:E0 (Static)
RSSI: -44 dBm (0xd4)
Flags: 0x00000000
Data length: 60
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Blue Maestro Limited (307)
Data: 1b640e10010400e701a527f50100
Name (complete): DC76F7E1
Company: Blue Maestro Limited (307)
Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
@ MGMT Event: Device Found (0x0012) plen 74
{0x0001} [hci0] 740.158704
LE Address: DC:76:F7:E1:62:E0 (Static)
RSSI: -44 dBm (0xd4)
Flags: 0x00000000
Data length: 60
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Blue Maestro Limited (307)
Data: 1b640e10010400e701a527f50100
Name (complete): DC76F7E1
Company: Blue Maestro Limited (307)
Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
Device information from the InterfacesAdded DBus signal:
{'Adapter': '/org/bluez/hci0',
'Address': 'DC:76:F7:E1:62:E0',
'AddressType': 'random',
'Alias': 'DC76F7E1',
'Blocked': False,
'Connected': False,
'LegacyPairing': False,
'ManufacturerData': {307: [39, 253, 39, 242, 39, 234, 0, 0, 1, 2, 1,
182, 0, 228, 1, 113, 0, 244,1, 140, 0, 0, 0, 0, 0]},
'Name': 'DC76F7E1',
'Paired': False,
'RSSI': -51,
'ServicesResolved': False,
'Trusted': False,
'UUIDs': []}
Looking at the propertiesChanged signal on the device, it is also only
showing the same manufacturer data:
org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
0, 0, 0, 0, 0]}} []
org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
0, 0, 0, 0, 0]}} []
org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
0, 0, 0, 0, 0]}} []
org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
0, 0, 0, 0, 0]}} []
org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
0, 0, 0, 0, 0]}} []
org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
0, 0, 0, 0, 0]}} []
Hi Barry,
> I attempting to get the advertising data from a commercially available
> sensor device using the DBus API.
> The sensor device gives different manufacturer data depending if the
> event type is ADV_IND or SCAN_RSP, as you can see below in the btmon
> output.
>
> With DBus I am subscribing to the InterfacesAdded signal which
> triggers when the device has been found. However, it only seems to
> give me the information for the SCAN_RSP.
> If I subscribe to the PropertiesChanged signal on the device, that is
> also only giving the data from the SCAN_RSP event.
>
> How do I access both types of data with the DBus API?
>
> Thanks,
> Barry
>
> $ bluetoothctl -v
> bluetoothctl: 5.50
>
>
> btmon output for sensor device:
>
>> HCI Event: LE Meta Event (0x3e) plen 43 #1969 [hci0] 740.157687
> LE Advertising Report (0x02)
> Num reports: 1
> Event type: Connectable undirected - ADV_IND (0x00)
> Address type: Random (0x01)
> Address: DC:76:F7:E1:62:E0 (Static)
> Data length: 31
> Flags: 0x06
> LE General Discoverable Mode
> BR/EDR Not Supported
> Company: Blue Maestro Limited (307)
> Data: 1b640e10010400e701a527f50100
> Name (complete): DC76F7E1
> RSSI: -44 dBm (0xd4)
>> HCI Event: LE Meta Event (0x3e) plen 41 #1970 [hci0] 740.158684
> LE Advertising Report (0x02)
> Num reports: 1
> Event type: Scan response - SCAN_RSP (0x04)
> Address type: Random (0x01)
> Address: DC:76:F7:E1:62:E0 (Static)
> Data length: 29
> Company: Blue Maestro Limited (307)
> Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
> RSSI: -44 dBm (0xd4)
> @ MGMT Event: Device Found (0x0012) plen 74
> {0x0002} [hci0] 740.158704
> LE Address: DC:76:F7:E1:62:E0 (Static)
> RSSI: -44 dBm (0xd4)
> Flags: 0x00000000
> Data length: 60
> Flags: 0x06
> LE General Discoverable Mode
> BR/EDR Not Supported
> Company: Blue Maestro Limited (307)
> Data: 1b640e10010400e701a527f50100
> Name (complete): DC76F7E1
> Company: Blue Maestro Limited (307)
> Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
> @ MGMT Event: Device Found (0x0012) plen 74
> {0x0001} [hci0] 740.158704
> LE Address: DC:76:F7:E1:62:E0 (Static)
> RSSI: -44 dBm (0xd4)
> Flags: 0x00000000
> Data length: 60
> Flags: 0x06
> LE General Discoverable Mode
> BR/EDR Not Supported
> Company: Blue Maestro Limited (307)
> Data: 1b640e10010400e701a527f50100
> Name (complete): DC76F7E1
> Company: Blue Maestro Limited (307)
> Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
>
>
> Device information from the InterfacesAdded DBus signal:
>
> {'Adapter': '/org/bluez/hci0',
> 'Address': 'DC:76:F7:E1:62:E0',
> 'AddressType': 'random',
> 'Alias': 'DC76F7E1',
> 'Blocked': False,
> 'Connected': False,
> 'LegacyPairing': False,
> 'ManufacturerData': {307: [39, 253, 39, 242, 39, 234, 0, 0, 1, 2, 1,
> 182, 0, 228, 1, 113, 0, 244,1, 140, 0, 0, 0, 0, 0]},
> 'Name': 'DC76F7E1',
> 'Paired': False,
> 'RSSI': -51,
> 'ServicesResolved': False,
> 'Trusted': False,
> 'UUIDs': []}
>
> Looking at the propertiesChanged signal on the device, it is also only
> showing the same manufacturer data:
> org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> 0, 0, 0, 0, 0]}} []
> org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> 0, 0, 0, 0, 0]}} []
> org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> 0, 0, 0, 0, 0]}} []
> org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> 0, 0, 0, 0, 0]}} []
> org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> 0, 0, 0, 0, 0]}} []
> org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> 0, 0, 0, 0, 0]}} []
this is nasty from the device. So the MGMT event should return the combined data from ADV_IND and SCAN_RSP and as you see we just concat that information coming from the kernel. However when it goes out via D-Bus, it actually gets overwritten and only one is provided.
Now the question is how we represent the same manufacturer data coming once from ADV_IND and second from SCAN_RSP via the D-Bus API. You need to have a look into doc/device-api.txt and the code in src/device.c on how we handle this.
Regards
Marcel
Hi,
Den ons 10 juni 2020 kl 16:00 skrev Marcel Holtmann <[email protected]>:
>
> Hi Barry,
>
> > I attempting to get the advertising data from a commercially available
> > sensor device using the DBus API.
> > The sensor device gives different manufacturer data depending if the
> > event type is ADV_IND or SCAN_RSP, as you can see below in the btmon
> > output.
> >
> > With DBus I am subscribing to the InterfacesAdded signal which
> > triggers when the device has been found. However, it only seems to
> > give me the information for the SCAN_RSP.
> > If I subscribe to the PropertiesChanged signal on the device, that is
> > also only giving the data from the SCAN_RSP event.
> >
> > How do I access both types of data with the DBus API?
> >
> > Thanks,
> > Barry
> >
> > $ bluetoothctl -v
> > bluetoothctl: 5.50
> >
> >
> > btmon output for sensor device:
> >
> >> HCI Event: LE Meta Event (0x3e) plen 43 #1969 [hci0] 740.157687
> > LE Advertising Report (0x02)
> > Num reports: 1
> > Event type: Connectable undirected - ADV_IND (0x00)
> > Address type: Random (0x01)
> > Address: DC:76:F7:E1:62:E0 (Static)
> > Data length: 31
> > Flags: 0x06
> > LE General Discoverable Mode
> > BR/EDR Not Supported
> > Company: Blue Maestro Limited (307)
> > Data: 1b640e10010400e701a527f50100
> > Name (complete): DC76F7E1
> > RSSI: -44 dBm (0xd4)
> >> HCI Event: LE Meta Event (0x3e) plen 41 #1970 [hci0] 740.158684
> > LE Advertising Report (0x02)
> > Num reports: 1
> > Event type: Scan response - SCAN_RSP (0x04)
> > Address type: Random (0x01)
> > Address: DC:76:F7:E1:62:E0 (Static)
> > Data length: 29
> > Company: Blue Maestro Limited (307)
> > Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
> > RSSI: -44 dBm (0xd4)
> > @ MGMT Event: Device Found (0x0012) plen 74
> > {0x0002} [hci0] 740.158704
> > LE Address: DC:76:F7:E1:62:E0 (Static)
> > RSSI: -44 dBm (0xd4)
> > Flags: 0x00000000
> > Data length: 60
> > Flags: 0x06
> > LE General Discoverable Mode
> > BR/EDR Not Supported
> > Company: Blue Maestro Limited (307)
> > Data: 1b640e10010400e701a527f50100
> > Name (complete): DC76F7E1
> > Company: Blue Maestro Limited (307)
> > Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
> > @ MGMT Event: Device Found (0x0012) plen 74
> > {0x0001} [hci0] 740.158704
> > LE Address: DC:76:F7:E1:62:E0 (Static)
> > RSSI: -44 dBm (0xd4)
> > Flags: 0x00000000
> > Data length: 60
> > Flags: 0x06
> > LE General Discoverable Mode
> > BR/EDR Not Supported
> > Company: Blue Maestro Limited (307)
> > Data: 1b640e10010400e701a527f50100
> > Name (complete): DC76F7E1
> > Company: Blue Maestro Limited (307)
> > Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
> >
> >
> > Device information from the InterfacesAdded DBus signal:
> >
> > {'Adapter': '/org/bluez/hci0',
> > 'Address': 'DC:76:F7:E1:62:E0',
> > 'AddressType': 'random',
> > 'Alias': 'DC76F7E1',
> > 'Blocked': False,
> > 'Connected': False,
> > 'LegacyPairing': False,
> > 'ManufacturerData': {307: [39, 253, 39, 242, 39, 234, 0, 0, 1, 2, 1,
> > 182, 0, 228, 1, 113, 0, 244,1, 140, 0, 0, 0, 0, 0]},
> > 'Name': 'DC76F7E1',
> > 'Paired': False,
> > 'RSSI': -51,
> > 'ServicesResolved': False,
> > 'Trusted': False,
> > 'UUIDs': []}
> >
> > Looking at the propertiesChanged signal on the device, it is also only
> > showing the same manufacturer data:
> > org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
> > 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> > 0, 0, 0, 0, 0]}} []
> > org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
> > 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> > 0, 0, 0, 0, 0]}} []
> > org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
> > 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> > 0, 0, 0, 0, 0]}} []
> > org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
> > 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> > 0, 0, 0, 0, 0]}} []
> > org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
> > 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> > 0, 0, 0, 0, 0]}} []
> > org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
> > 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
> > 0, 0, 0, 0, 0]}} []
>
> this is nasty from the device. So the MGMT event should return the combined data from ADV_IND and SCAN_RSP and as you see we just concat that information coming from the kernel. However when it goes out via D-Bus, it actually gets overwritten and only one is provided.
>
> Now the question is how we represent the same manufacturer data coming once from ADV_IND and second from SCAN_RSP via the D-Bus API. You need to have a look into doc/device-api.txt and the code in src/device.c on how we handle this.
>
> Regards
>
> Marcel
>
To me it appears there is a "bug" in the BlueZ API specification.
Manufacturer data is stored as a key-value dictionary, where key is
the manufacturer id and the value is the byte array. But the Bluetooth
Core Specification Supplement explicitly allows more than one
appearance of Manufacturer Specific Data (see the first section in
CSS_v9.pdf), and it does not prohibit more than one record from the
same manufacturer. A correct API would have Manufacturer data as a
key-value dictionary, where the key is the manufacturer id but the
value is an array of byte arrays.
The AdvertisingData experimental API seems to have the same kind of
issue "The Advertising Data of the remote device. Keys are are 8 bits
AD Type followed by data as byte array." But each AD type can appear
more than once and hence the value should be an array of byte arrays.
/Emil
Hi Emil,
>>> I attempting to get the advertising data from a commercially available
>>> sensor device using the DBus API.
>>> The sensor device gives different manufacturer data depending if the
>>> event type is ADV_IND or SCAN_RSP, as you can see below in the btmon
>>> output.
>>>
>>> With DBus I am subscribing to the InterfacesAdded signal which
>>> triggers when the device has been found. However, it only seems to
>>> give me the information for the SCAN_RSP.
>>> If I subscribe to the PropertiesChanged signal on the device, that is
>>> also only giving the data from the SCAN_RSP event.
>>>
>>> How do I access both types of data with the DBus API?
>>>
>>> Thanks,
>>> Barry
>>>
>>> $ bluetoothctl -v
>>> bluetoothctl: 5.50
>>>
>>>
>>> btmon output for sensor device:
>>>
>>>> HCI Event: LE Meta Event (0x3e) plen 43 #1969 [hci0] 740.157687
>>> LE Advertising Report (0x02)
>>> Num reports: 1
>>> Event type: Connectable undirected - ADV_IND (0x00)
>>> Address type: Random (0x01)
>>> Address: DC:76:F7:E1:62:E0 (Static)
>>> Data length: 31
>>> Flags: 0x06
>>> LE General Discoverable Mode
>>> BR/EDR Not Supported
>>> Company: Blue Maestro Limited (307)
>>> Data: 1b640e10010400e701a527f50100
>>> Name (complete): DC76F7E1
>>> RSSI: -44 dBm (0xd4)
>>>> HCI Event: LE Meta Event (0x3e) plen 41 #1970 [hci0] 740.158684
>>> LE Advertising Report (0x02)
>>> Num reports: 1
>>> Event type: Scan response - SCAN_RSP (0x04)
>>> Address type: Random (0x01)
>>> Address: DC:76:F7:E1:62:E0 (Static)
>>> Data length: 29
>>> Company: Blue Maestro Limited (307)
>>> Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
>>> RSSI: -44 dBm (0xd4)
>>> @ MGMT Event: Device Found (0x0012) plen 74
>>> {0x0002} [hci0] 740.158704
>>> LE Address: DC:76:F7:E1:62:E0 (Static)
>>> RSSI: -44 dBm (0xd4)
>>> Flags: 0x00000000
>>> Data length: 60
>>> Flags: 0x06
>>> LE General Discoverable Mode
>>> BR/EDR Not Supported
>>> Company: Blue Maestro Limited (307)
>>> Data: 1b640e10010400e701a527f50100
>>> Name (complete): DC76F7E1
>>> Company: Blue Maestro Limited (307)
>>> Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
>>> @ MGMT Event: Device Found (0x0012) plen 74
>>> {0x0001} [hci0] 740.158704
>>> LE Address: DC:76:F7:E1:62:E0 (Static)
>>> RSSI: -44 dBm (0xd4)
>>> Flags: 0x00000000
>>> Data length: 60
>>> Flags: 0x06
>>> LE General Discoverable Mode
>>> BR/EDR Not Supported
>>> Company: Blue Maestro Limited (307)
>>> Data: 1b640e10010400e701a527f50100
>>> Name (complete): DC76F7E1
>>> Company: Blue Maestro Limited (307)
>>> Data: 27fd27f227ea0000010201b600e4017100f4018c0000000000
>>>
>>>
>>> Device information from the InterfacesAdded DBus signal:
>>>
>>> {'Adapter': '/org/bluez/hci0',
>>> 'Address': 'DC:76:F7:E1:62:E0',
>>> 'AddressType': 'random',
>>> 'Alias': 'DC76F7E1',
>>> 'Blocked': False,
>>> 'Connected': False,
>>> 'LegacyPairing': False,
>>> 'ManufacturerData': {307: [39, 253, 39, 242, 39, 234, 0, 0, 1, 2, 1,
>>> 182, 0, 228, 1, 113, 0, 244,1, 140, 0, 0, 0, 0, 0]},
>>> 'Name': 'DC76F7E1',
>>> 'Paired': False,
>>> 'RSSI': -51,
>>> 'ServicesResolved': False,
>>> 'Trusted': False,
>>> 'UUIDs': []}
>>>
>>> Looking at the propertiesChanged signal on the device, it is also only
>>> showing the same manufacturer data:
>>> org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
>>> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
>>> 0, 0, 0, 0, 0]}} []
>>> org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
>>> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
>>> 0, 0, 0, 0, 0]}} []
>>> org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
>>> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
>>> 0, 0, 0, 0, 0]}} []
>>> org.bluez.Device1 {'RSSI': -45, 'ManufacturerData': {307: [39, 253,
>>> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
>>> 0, 0, 0, 0, 0]}} []
>>> org.bluez.Device1 {'RSSI': -54, 'ManufacturerData': {307: [39, 253,
>>> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
>>> 0, 0, 0, 0, 0]}} []
>>> org.bluez.Device1 {'RSSI': -52, 'ManufacturerData': {307: [39, 253,
>>> 39, 242, 39, 234, 0, 0, 1, 2, 1, 182, 0, 228, 1, 113, 0, 244, 1, 140,
>>> 0, 0, 0, 0, 0]}} []
>>
>> this is nasty from the device. So the MGMT event should return the combined data from ADV_IND and SCAN_RSP and as you see we just concat that information coming from the kernel. However when it goes out via D-Bus, it actually gets overwritten and only one is provided.
>>
>> Now the question is how we represent the same manufacturer data coming once from ADV_IND and second from SCAN_RSP via the D-Bus API. You need to have a look into doc/device-api.txt and the code in src/device.c on how we handle this.
>>
>
> To me it appears there is a "bug" in the BlueZ API specification.
> Manufacturer data is stored as a key-value dictionary, where key is
> the manufacturer id and the value is the byte array. But the Bluetooth
> Core Specification Supplement explicitly allows more than one
> appearance of Manufacturer Specific Data (see the first section in
> CSS_v9.pdf), and it does not prohibit more than one record from the
> same manufacturer. A correct API would have Manufacturer data as a
> key-value dictionary, where the key is the manufacturer id but the
> value is an array of byte arrays.
seems the CSS really allows to have manufacturer specific data more than ones. So yes, we can introduce the value part here as array{array{uint8}}. The client code can easily detect the difference in case we have it multiple times. In case of just a single occurrence it will be still sent as array{uint8}.
Regards
Marcel