BLE Battery Service: Extra Characteristic

[dev_000]

Hi all,

I am looking for some advice on how to implement a couple of extra characteristics(Related with battery) with the Battery Service apart from the usual Battery Level Characteristic.

What is the best practice to handle such a case? Should I add the extra characteristics to the Battery Service or create new Service with these two characteristics?

If I were to add it to the Battery Service, will it be a violation of the Bluetooth spec for the Battery Service standard?

Again, if I go with adding it to the Battery Service, how would I handle it in terms of the Nordic nRF SDK? Do I go and edit the ble_bas.c and ble_bas.h directly in the SDK folder? Is that a right practice? Or should I recreate with a new .c and .h file with contents from ble_bas.c and ble_bas.h?

[Simonr]

Hi

Our custom BLE service example shows you how to add and implement custom characteristics/services. You could also look at the linked beginner tutorials for more details on either services, characteristics or advertising in that example.

I would recommend adding a new service instead of adding characteristics to the Battery Service, as it's "cleaner" to have custom characteristics within custom services, and not mixing them with already existing services. 

I don't think this would violate the Bluetooth spec. but I'm not 100% sure, so you should check the Bluetooth specification just in case if you decide to go with this solution.

In any case, we do not recommend editing the files within our SDK libraries/drivers, as it makes future support harder if we have to consider multiple files to be the source of errors instead of just edits within main.c, sdk_config.h, and custom files. So please go for new .c and .h files for this approach.

Best regards,

Simon

[dev_000]

Thanks.
I couldnt find information on the spec on whether this will be a violation. Hence thought of asking.
Will go ahead with the extra service.

[cbd]

A custom service is definitely he way to go.

Although the Bluetooth SIG conformance testing and specification documentation for the Battery Service doesn't specifically state that conformance to the specification excludes the inclusion of extra characteristics the fact that the specification states 

"If a device claims conformance to this service, all capabilities indicated as mandatory for this service shall be supported in the specified manner (process-mandatory)."

and that it specifically lists only the Battery Level characteristic (and as mandatory), along with the fact that GATT specification states on services

"To maintain backward compatibility with earlier clients, later versions of a service definition can only add new included services or optional characteristics. Later versions of a service definition are forbidden from changing behaviors from previous versions of the service definition."

it could be argued that the inclusion of extra characteristics is changing the service behaviour which would make your code non-conformant if in future an optional characteristic was added to the Battery Service and ratified by the Bluetooth SIG.