@@ -749,6 +749,32 @@ Pairing and bonding
749749 should show the passkey that was provided in the ``_IRQ_PASSKEY_ACTION `` event
750750 and then respond with either ``0 `` (cancel pairing), or ``1 `` (accept pairing).
751751
752+ .. method :: BLE.gap_indicate_service_changed(conn_handle, handle_start, handle_end, /)
753+
754+ When a client is bonded to a server it will typically cache the results of the discovery
755+ process to speed up future connections. If the services/characteristic handles change on
756+ the server in future a previously-bonded client may not be able to communicate correctly
757+ as it will be using the previously cached handles.
758+ This function can be run on the server to send an indication to the client that handles
759+ have changed and trigger service discovery on the client.
760+
761+ If ``conn_handle `` is None, then all connected devices will be indicated. If CCCD bonding
762+ is supported then any un-connected bonded devices will automatically be indicated the next
763+ time they connect.
764+
765+ The ``handle_start `` and ``handle_end `` arguments can be used to specify the range of
766+ characteristics that have changed, or typically ``handle_start=0x0000, handle_end=0xFFFF ``
767+ will be used to discover all again.
768+
769+ Note: with an iOS client it's been seen that if this function is called greater than ~100ms
770+ after a new connection is established the connection can be dropped, or the characteristics
771+ covered by the declared range will lock up and be no longer readable, so it's important to
772+ send this command within the first few ms after a connection is made.
773+
774+ Alternatively, it appears that if the start and end handles are both set to ``0x0000 ``,
775+ the lock-up doesn't occur regardless of when the call is made. Android clients appear to
776+ accept the null handles as a re-discover all, though the BLE spec makes no mention of this.
777+
752778
753779class UUID
754780----------
0 commit comments