01 / START WITH A DEVICE
Tell us what you own.
Search the device index first. If your model is missing, open an issue with the device’s brand, model, what it measures or controls, and what you want to do with it.
You don’t need to write code to make a useful report. If a related protocol already exists, let us know how your model behaves.
Suggest a device02 / DOCUMENT THE CONVERSATION
A capture helps answer the hard questions.
A Bluetooth capture of the maker’s app talking to the device can reveal steps that static reading misses. An Android HCI snoop log is a useful starting point.
Include the operation you captured, model and firmware if known, and the sequence of actions in the app. Remove personal identifiers or unrelated traffic before sharing a capture.
Protocol notes should record what was observed, what is inferred, and what is still open.
03 / MAKE IT REUSABLE
A small library with a clear manual.
Register exact models and their evidence in catalog/protocols/<protocol>.json in open-ble-hub. The website reads the published catalog. New libraries live in packages/openble-<protocol>. Keep protocol parsing and command construction independent of the Bluetooth stack.
- Protocol code under the shared
openblenamespace. - Tests built from captured packets.
- Notes for services, characteristics, handshakes, and packet layouts.
- A README, license, and package metadata following an existing library.
04 / PUT IT TO WORK
A library can lead to many applications.
Add a front-end to an existing hub when it fits, or build a new app for a different use. A protocol library and a hub integration are separate contributions.
Development setup & pull requests