Say for example you have an embedded peripheral BLE device which has a single BLE service with some characteristics and the initialisation order is always the same (service is added, then characteristic A is added, then B and so on).
In my local testing, the handles passed to the central from the peripheral always appear to be the same. For example, the service has always been 0x000c, characteristic A 0x000d, etc.
This is the case even on disconnect/reconnect as well.
Looking at the Bluetooth documentation, I found this about attribute handles:
3.2.2 Attribute handle
An attribute handle is a 16-bit value that is assigned by each server to its own
attributes to allow a client to reference those attributes. An attribute handle
shall not be reused while an ATT bearer exists between a client and its server.Attribute handles on any given server shall have unique, non-zero values. Attri-
butes are ordered by attribute handle.An attribute handle of value 0x0000 is reserved for future use. An attribute han-
dle of value 0xFFFF is known as the maximum attribute handle.Note: Attributes can be added or removed while an ATT bearer is active, how-
ever, an attribute that has been removed cannot be replaced by another attri-
bute with the same handle while an ATT bearer is active.
With this in mind, does Bluetooth allow clients/central to force the server/peripheral to re-initialise their services and characteristics?
Or is it safe to assume that once my user code initialised the services and characteristics, they will always have the same handles?
Best Answer
Yes.
You can tell by the presence of the "Service Changed" characteristic in the Generic Attribute service. This way the peripherial can tell the central when to re-run discovery.