The plugin API can be hard to use, and people my not wish to use an add-on API like EasyBLE or Bleat.
Specifically, the plugin API use handles to services, characteristics and descriptors. There is no built-in support for mapping UUIDs to these handles. This can make it hard to work with the plugin API.
Function readAllServiceData provides some support, but services, characteristics and descriptors are stored in arrays, which do not provide mappings. Manually iterating over the arrays is needed to find UUIDs and corresponding handles.
Suggestion:
Return a dictionary from readAllServiceData (or make a new function) that provides mappings.
Also investigate if the deviceHandle/deviceObject could be stored in a structure. Now the developer has to track this manually.
Example of structure:
deviceInfo
deviceObject/deviceHandle
services (dictionary with mapping service UUID --> service object)
characteristics (dictionary with mapping characteristic UUID --> characteristic object)
descriptors (dictionary with mapping descriptor UUID --> descriptor object)
Problem:
The plugin API can be hard to use, and people my not wish to use an add-on API like EasyBLE or Bleat.
Specifically, the plugin API use handles to services, characteristics and descriptors. There is no built-in support for mapping UUIDs to these handles. This can make it hard to work with the plugin API.
Function readAllServiceData provides some support, but services, characteristics and descriptors are stored in arrays, which do not provide mappings. Manually iterating over the arrays is needed to find UUIDs and corresponding handles.
Suggestion:
Return a dictionary from readAllServiceData (or make a new function) that provides mappings.
Also investigate if the deviceHandle/deviceObject could be stored in a structure. Now the developer has to track this manually.
Example of structure: