How to enable notifications for multiple characteristics with BLE.

[stc1988]

I am developing a BleClient for a BLE device with multiple characteristics.
I am trying to enable notifications for multiple characteristics as follows, but onCharacteristicNotificationEnabled is called only for the first one. On the ESP32, it seems necessary to call esp_ble_gattc_write_char_descr after esp_ble_gattc_register_for_notify, but is this related?

class Scanner extends BLEClient {
  ...
  onServices(services: Service[]) {
    services[0]?.discoverAllCharacteristics()
  }
  onCharacteristics(characteristics: Characteristic[]) {
    characteristics.forEach((characteristic) => {
        characteristic.enableNotifications()
    })
  }
  onCharacteristicNotificationEnabled(characteristic: Characteristic) {
    trace(`[characteristicNotificationEnabled]:${characteristic.uuid.toString()}\n`)
  }
   ...
}

[phoddie]

I apologize for being slow to look into this.

On the ESP32, it seems necessary to call esp_ble_gattc_write_char_descr after esp_ble_gattc_register_for_notify, but is this related?

On ESP32, the Moddable SDK uses the NimBLE APIs. This implementation is here in the SDK. The use of esp_ble_gattc_register_for_notify is only in the long deprecated Bluedroid support. (The directory names can be a misleading here).

How can I reproduce the problem you are seeing?

[stc1988]

I’m developing ble client for toio. I think you don't have this device.

Therefore, I’ll set up a BLE server that can notify multiple characteristics and try to verify the issue, so please wait a moment. The implementation on the BLE client side is as I initially described.

[phoddie]

I’m developing ble client for toio. I think you don't have this device.

Cool. I remember Sony's first steps into this kind of product. I didn't realize that they had continued.

Therefore, I’ll set up a BLE server that can notify multiple characteristics and try to verify the issue, so please wait a moment. The implementation on the BLE client side is as I initially described.

Perfect. Thank you!

[phoddie]

These are sample BLE client and server based on heart-rate-server and heart-rate-client.

Where?

[stc1988]

Sorry, I forgot to include the link. Here it i

https://github.com/stc1988/moddable-labs/tree/main/examples/network/ble/multiple_characteristic

[stc1988]

The same phenomenon was also observed with toio.
On the other hand, by changing to a sequential process where the next characteristic’s enableNotifications is called only after receiving onCharacteristicNotificationEnabled, it worked well even with an increase to 10 characteristics.

Here is the code after the change.
https://github.com/stc1988/moddable-labs/blob/9e33ce9442f71beae9d33a9ff1a571601546fe99/examples/network/ble/multiple_characteristic/client/main.js#L37-L61

[phoddie]

Great investigation! So, the problem is mostly configuration. The NimBLE stack must be configured to queue only up to 4 outgoing messages.

I think the pragmatic solution is that the enableNotifications() call should throw when the request fails; today it ignores the returned error. That would tell you that there is a problem, rather than failing silently. Then you can either change the sdkconfig to increase the number of queued requests or change your code to issue the requests serially, as you did above.

An alternate solution is to implement a queue in the Moddable SDK BLE bindings. However, that is a lot of code and complexity that doesn't seem justified here, given that this issue is rare and can be addressed in other ways.

What do you think?

[stc1988]

Thanks for the reply.

I think the pragmatic solution is that the enableNotifications() call should throw when the request fails; today it ignores the returned error. That would tell you that there is a problem, rather than failing silently. Then you can either change the sdkconfig to increase the number of queued requests

If possible, it would be good to make the exception provide the cause clearly and to show how to modify the sdkconfig in documentation.

[phoddie]

I added logging of all NimBLE failure codes to the BLE Client in debug builds. That gives all the information we have about the failure. enableNotifications now throws on failures. Here's the updated code. Please give it a try?

As a rule, we don't include lots of explanation in exceptions because doing so accurately can require quite a bit of code - and misleading guidance can be worse than none. I'm open to suggestions. Perhaps a comment in the C source code where the exception is thrown? That will be visible to developers in xsbug and requires no additional code.