Is your feature request related to a problem? Please describe.

I'm working on the MicroPython binding for BTstack (currently BLE-only). cc @dpgeorge

We have an existing Python API which is currently implemented on top of NimBLE -- http://docs.micropython.org/en/latest/library/ubluetooth.html

The way the API for GATT clients currently behaves for notifications is that the client (in a Python callback) gets an _IRQ_GATTC_NOTIFY or _IRQ_GATTC_INDICATE event for any notifications received. They don't need to explicitly listen for them (although they might have configured the CCCB of course).

In BTstack, there doesn't appear to be a way to achieve this directly. The two closest options are:

• Call gatt_client_listen_for_characteristic_value_updates() for each connection handle and value handle pair.
• Handle the ATT_HANDLE_VALUE_NOTIFICATION directly and duplicate some of the code from gattc_client.c to parse the packet. (Not really a sensible option)

The first option requires that we know the handles, which requires the user to have done a discovery. Additionally, we'd need to manage the gatt_client_notification_t nodes in order to clean up on disconnection via gatt_client_stop_listening_for_characteristic_value_updates. Our bindings don't currently need to track any state for connections. And this would be a behavioural change to our API (although realistically the user should always be doing a discovery).

Describe the solution you'd like
One simple option would be a way to do a single call to gatt_client_listen_for_characteristic_value_updates() with some sort of sentinel "ALL" value for the two handles that would match any incoming notification/indication.

Other options seem more complicated or more code size, e.g. adding more event types, etc. But open to suggestions!

Describe alternatives you've considered
We could add an additional method to our API to allow the user to explicitly listen for notifications for a connection handle and value handle pair. We'd still need the extra state management to stop listening on disconnection. The other disadvantage (to us) would be that we'd have to then implement this for the NimBLE bindings.

Thanks!