ESP32 Forum

There is a BLE function called esp_ble_gatts_add_char() which registers a new characteristic with a previously created BLE service. As I study this API, I find myself puzzled by the existence of a parameter called "char_value".

See the API ref here: http://esp-idf.readthedocs.io/en/latest ... _control_t

This parameter seems to supply a value for the characteristic. Which, in and of itself seems logical ... if we are going to be a BLE server and a peer asks us for the data, we should have it available to return ... but wait ... my understanding of the architecture is that if a peer client asks us for the value of a characteristics then we will receive an ESP_GATTS_READ_EVT and our event handler is then responsible for returning the value. This seems to say I have a big old hole in my understanding. If we (the programmer) are responsible for returning the current characteristic value on a read request, why would we ever need to pass in a value to the attribute registration function?

Thank you kind sir. That is a perfect response and a delightful new understanding on my part that there is even more function in ESP-IDF stack that I had ever assumed. Wonderful.

This now begs a follow on question ... if I set auto_rsp to ESP_GATT_RSP_BY_APP then does that mean that I can supply a null pointer to a call to esp_ble_gatts_add_char() for the "char_value" parameter? My gut would assume "yes" since if we are declaring that we are going to handle requests for characteristics values in application logic, then there should be no need to tell the environment about any potential values. However, I'm wrong more than I'm right so I like to check.

Yes I think so