-
Notifications
You must be signed in to change notification settings - Fork 214
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
BLE examples replicate a UUID for both service and a characteristic #2583
Comments
We plan to overhaul all the examples including the BLE ones. e.g. something mimicking a real-world device (e.g. a BLE temperature sensor or a HID keyboard) |
Sounds great! I'll keep this ticket open until then, and remove once the new stuff is out. No rush. |
One note on the examples - since the end of tangential :) |
For comparison, Nordic mentions this "LED Button Service" in their BLE tutorial: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/bluetooth/services/lbs.html#lbs-readme It has a service UUID and two characteristics, whose UUIDs are derived from that (differ by one char). |
Bug description
The BLE examples having the same UUID for both service and one characteristic seems like a mistake.
Check these lines:
esp-hal/examples/src/bin/wifi_ble.rs
Line 113 in f81b5f6
esp-hal/examples/src/bin/wifi_embassy_ble.rs
Line 143 in f81b5f6
This works just fine - I don't think the id's of the characteristics vs. their enclosing service really matter - but logically there shouldn't be any connection between the two?
The other characteristics are varied from the same theme, by changing one character. I would suggest to do the same here.
Background about the selection of UUIDs in a StackOverflow answer.
To Reproduce
Observe the links above.
Expected behavior
The BLE samples not only are functional, but also show "intention", i.e. lead the reader in the right direction.
Environment
Does not matter.
The text was updated successfully, but these errors were encountered: