BLE Guidance for Services vs Characteristics

I'm building a project using the NANO 33 BLE Sense, but my mind is swimming in BLE and I'm wondering what best practice is for architecture.

The board will eventually control several blocks of neopixels: Block A, Block B, Block C and Block D.

I'm building an app in MIT's App Inventor with 4 pairs of buttons to turn on/off each block of pixels.

But what is best practice for spinning up BLE Services vs. Characteristics?

My current architecture has a main BLEService (ledblocksService), and then I've defined 4 individual BLEByteCharacteristic's, one for each block of LEDs. Each button in the App Inventor simply drops a 1 or 0 to the proper characteristic UUID.

Is this the way Services/Characteristics are supposed to be used? As I figure I could just as easily simply only have one characteristic, to which I write a unique value to control each LED block (0/1 for Block A, 2/3 for Block B, etc).

What criteria do you use to determine if you should use separate Characteristics (or even separate Services)?

This is part philosophical and part technical question. The Bluetooth SiG uses both cases. There are services with multiple characteristics and some characteristics are separated out in applications into their own service. There will be use cases where ether of the choices will be fine and later you might find you chose wrong. :slight_smile:

If you need this to scale in the future it is probably a good idea to ensure you will not create a massive amount of services and characteristics, because this will increase connection time. The client will need to run through a longer GATT service discovery.

On the other side if the LED blocks are logically independent and you can see that you might have product versions with only one block type and others with more or other types, it might make software development a bit easier if you have multiple services.

At the end, make a battle decision now and change your mind later when you need too. :slight_smile: