nimble: Indicating a characteristic will also send indications for other characteristics.
Related to the send_update arg added to ble.gatts_write in #7564.
The following code on a server (with a connected but unsubscribed client) results in the client receiving an indication for both characteristics.
ble.gatts_write(first_char_handle, "value", True) # (1)
ble.gatts_write(second_char_handle, "value", False)
ble.gatts_indicate(conn_handle, second_char_handle) # (2)
I would expect:
- (1) should not be sent to an unsubscribed client.
- (2) should only trigger an indication for
second_char_handle(regardless of subscription state).
It's not obvious to me that this is being caused by modbluetooth.c / modbluetooth_nimble.c, so might need to investigate in NimBLE (or confirm that this is the expected behaviour). I don't see this for notify, only indicate.
extmod/modbluetooth: Add gap_indicate_service_changed.
This function triggers an indication on the GATT service changed characteristic.
The matching change in aioble can be found https://github.com/micropython/micropython-lib/pull/467
Requires extra nimble feature at this stage: https://github.com/apache/mynewt-nimble/pull/1112
I've added some extra notes to the docs to cover some idiosynchacies seen in phone (iOS / android) usage of this feature:
Note: with an iOS client it's been seen that if this function is called greater than ~100ms
after a new connection is established the connection can be dropped, or the characteristics
covered by the declared range will lock up and be no longer readable, so it's important to
send this command within the first few ms after a connection is made.
Alternatively, it appears that if the start and end handles are both set to ``0x0000``,
the lock-up doesn't occur regardless of when the call is made. Android clients appear to
accept the null handles as a re-discover all, though the BLE spec makes no mention of this.