I have been reading a number of BLE books including:
Getting Started with Bluetooth Low Energy
Bluetooth Low Energy: The Developer's Handbook
It is pointless (opinion) to start studying the ESP32 APIs on BLE without first knowing the principles of BLE in abstract. Don't start thinking you can correctly use API for programming BLE unless you can describe GAP, GATT, Services, Characteristics, Descriptions, Attributes, UUIDs and assigned numbers (opinion).
While mapping the theory of BLE in the books to practicals of BLE in the API, what I seem to be missing is the notion of "handles". In the BLE story, it seems that a "handle" is the 16bit identifier for an attribute as known to the GATT server. My model says ...
"We scan for a BLE peripheral using GAP. When found, we now know the BT address of the device. Now we form a GATT connection to it. From there we can search for the services it provides. Having found a service of interest, we can then ask that service for its characteristics ...". And right HERE is where I am losing focus ... If I am understanding correctly, a characteristic is identified by a UUID ... perfect ... no issue with that and using the APIs I can see the UUID. However, there is a second aspect ... called a "handle" ... and when we query a GATT server to ask about its characteristics, we not only "should" be getting the characteristics UUIDs but also their handles ... and ( if my study is close ), we then use those handles to read and write the attributes.
For example (and this is made up) ... If I were to run a BLE scan, I might find a response from a device called "FF:FF:45:19:14:80". I then form a GATT connection to this device and then ask about its services. It might then response:
- UUID: 0x1800
- UUID: 0x180F
- UUID: 0x1802
- UUID: 0x2A06
When I look at the APIs used to manipulate values (esp_ble_gattc_write_char), I see that it takes the connection id to the device (check ... that makes sense), the service uuid and the characteristic uuid ... and no mention of handles. Now ... my *guess* is that internally in the ESP-IDF APIs, the knowledge of handles is being withheld from us and that when we pass in the triple just mentioned, the handles are mapped for us ... however ... that's the area I'd like to hear from others upon ... I feel that ESP-IDF might be helping us here ... but helping us in an opaque manner such that we need some guidance on how to understand the architecture in relationship to BLE study by itself.