BLE

NB: This is incomplete. Please expand with quotes and references!

BLE support seems to be from one single driver (driver-go-blecombined) and is not part of the Sphere API (but really should be). A bug / issue with the BLE library means that it needs to run from a single process

Quote from Jon Seymour:

Our current support for flowerpower is bundled into the driver-go-blecombined driver [...]

update: one other thing to keep in mind is that right now, the ble stack needs to be owned by a single process (that process being driver-go-blecombined). If you do want to hack around with the underlying gatt libraries that we are using in a separate process, you will need to stop driver-go-blecombined first.

jon.

And this other quote from Jon:

For now, maintain a version of driver-go-blecombined that does what you need it to do.

Longer term, we will either have to resolve the issues that forced us to go single process or we will have to split ninja BLE drivers into separate parts that communicate with the hardware indirectly via a generic core.

jon.

In order to support newer BLE devices, you'll need BLE descriptors (see this site for example which are messages and data that goes to and comes from BLE devices:

From Elliot

[...] we have full control over BLE. If we have descriptions of the services/characteristics we can talk directly. They just need to provide that (and then we or someone else needs to add it to our BLE driver). [...]

This makes BLE development a little more time consuming, as you have to create a pull request to get your modifications added to the driver, instead of just writing your own driver and publishing it (as you already can with apps and drivers)

The Sphere implements the Generic Attribute Protocol (GATT) as evidenced here and here