Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow service data advertisement for peripherals #406

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

chadrockey
Copy link
Contributor

The Android version of the NRF Wifi Provisioning app expects Service Data instead of typical advertised service UUIDs.

https://github.com/NordicSemiconductor/Android-nRF-Wi-Fi-Provisioner/blob/0094211ae252745dbd9b7805fb0e41ebd0f91cc6/app/src/main/java/no/nordicsemi/android/wifi/provisioning/scanner/ProvisioningData.kt#L56

Because their UUID is the full 128 bits, the advertisement fails to publish because it won't fit. As far as I can tell, if you publish service data, LightBlue and NRFConnect all still see the service, so having service data should supercede the service advertisements.

I believe this is the most straightforward and user friendly way to do this. I had also considered a "bluez_peripheral" like function call, but it doesn't seem needed right now.

advert = Advertisement(name, [], 0, 0, serviceData={WIFI_COMMISSION_SERVICE_UUID:bytes([0x02, 0x00, 0x00, 0x00])}) await advert.register(bus, adapter)

@ukBaz
Copy link
Owner

ukBaz commented Feb 4, 2024

Apologies for taking so long to get to this.

Do you have an example of the calling of the new Peripheral with advertising service data?
I'd like to see how you envisage it being used as I'm not sure if it following the complexity guidelines

Passing in detailed service data information at a "level 10" interface feels like people would have to know a bit about how advertisements are created.
My intention when I was creating the library was that in situations like this where people wanted to be more sophisticated with what they were doing, they would drop down to the "level 100" apis.

I also think that there are a number of people that would be interested in being able to attach a Raspberry Pi to a WiFi network via Bluetooth, so I could see that this specific application could be shipped with "level 1" API.

If we do agree that putting this in the Peripheral code is correct, I would also like to discuss if having it as part of "publish()" is correct.
I'm also confused by your use of await in the text above. I associate that with the asyncio event loop and not the event loop used by BlueZ.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants