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

Updated README to reflect addition of GATT Appearance(s) #108

Merged
merged 1 commit into from
Jan 12, 2024

Conversation

dinesharjani
Copy link
Collaborator

We added the .json to /v1 but we did not announce it or show it in the README, which is what we guess most people will see or have a chance to discover through.

We added the .json to /v1 but we did not announce it or show it in the README, which is what we guess most people will see or have a chance to discover through.
@dinesharjani dinesharjani added the documentation Improvements or additions to documentation label Jan 12, 2024
@dinesharjani dinesharjani self-assigned this Jan 12, 2024
@dinesharjani dinesharjani merged commit 40745c6 into master Jan 12, 2024
7 checks passed
@dinesharjani dinesharjani deleted the gatt-readme branch January 12, 2024 16:55
@eriklins
Copy link
Contributor

Totally didn't have the README in mind when opening the PR with just the JSON. Thanks for looking into this. The appearance values are mainly referred to as "GAP Appearance" not "GATT Appearance". However, as indicated the new README section appearance refers to both the GAP advert data type as well as the appearance characteristic within the GAP service of the GATT table. Might be better to change the wording from "GAP Appearance" to "GAP/GATT Appearance". But don't want to be picky, fine for me. And thanks again.

@dinesharjani
Copy link
Collaborator Author

That's a good one, I should update it. Also, need to add the schema and add that to the GitHub Action(s).

Also, the values, they don't need to be in hex. They can be human-readable so we can avoid the extra-processing on the side of the API consumer.

@eriklins
Copy link
Contributor

They don't necessarily have to be hex, but they are hex in the original BT SiG document and the original BT SiG YAML file as well as all UUIDs in the other JSON files are hex. So I went for hex for the appearance JSON. Hex might also be slightly more convenient when it comes to composing a 16 bit value from the category and sub-category values by bit-shifting.
Common tools like nRF Connect app show the appearance as hex as well.

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

Successfully merging this pull request may close these issues.

2 participants