hi @andrewleech -- I think if I were designing this from scratch I'd do it this way, but unfortunately this is a breaking change to existing code that already explicitly calls gatts_notify after gatts_write (leading to duplicate notifications).

So I think if we're going to merge this we need to make this behavior opt-in, either by an additional argument to gatts_write, or an extra flag on the characteristic.

@jimmo yes the compatibility issue is a significant one. This auto notification also makes it harder to know when an indication will be sent / should be listened for.

The other big issue with this change is I can't find any matching function for btstack - leaving me with a situation where I'd need to manually C code a similar functionality for btstack.... or we can just ditch this and handle it all in aioble instead :-)

I propose we add a optional argument to gatts_write BLE.gatts_write(value_handle, data, [update=False]) which when set will add the call to ble_gatts_chr_updated. Additionally, we add support for storing CCCD in the secret store, which means that as well as remembering subscription state, we also remember pending indications/notifications for peers.

Thinking about what event to raise for this... in the case where there are no subscribers or all subscribers are notify-only, there's no event to raise. For indications, NimBLE does have considerable logic to ensure delivery of the indication, even if a subscribed peer is disconnected it will be sent on next connection, and the pending bit will only be cleared on ack. So this means that the concept of a "update-indication-complete" event is a bit unclear. i.e. in many cases you don't want to be waiting for this to happen. So we'll still raise the _IRQ_GATTS_INDICATE_DONE event when it succeeds, but I don't think it's appropriate for e.g. aioble to be able to await chr.write(..., update=True). @andrewleech @MarceauFillon what do you think?

On btstack, we manage the CCCD ourselves, so we can implement similar functionality to ble_gatts_chr_updated (although it won't be particularly simple).

Just a further thought -- from testing (and reading the NimBLE code), the gatts_notify and gatts_indicate methods completely ignore the subscription state (and do not set the pending bit in the CCCD). So they should stay unchanged, and can be used for the "sending a notification/indication to a known connected peer, with immediate ack event for indicate".

See #7564 for adding send_update=True to gatts_write.

Closed in preference for #7564