BLE: Contents of correct response for ESP_GATTS_WRITE_EVT
Posted: Fri Jun 23, 2017 1:13 am
When writing a BLE GATTS server, I am responding to ESP_GATTS_WRITE_EVT which is raised in response to a partner asking to write a new value to the characteristic hosted on my GATTS server. The incoming structure associated with this event includes a flag called "need_rsp" which indicates whether or not my server needs to send a response. In my testing, I am finding that this value is set and hence I need to send a response.
To send a response I invoke esp_ble_gatts_send_response(). One of the parameters of this function is called "rsp" of type "esp_gatt_rsp_t *".
Now the question ...
Semantically, I have received a request from the partner to update the characteristic value and I wish to respond that I have indeed successfully performed that task. When I execute esp_ble_gatts_send_response(), I am supplying the connection id and the transfer_id and hence that should be "sufficient" context to acknowledge the original event. What if anything should I supply for "rsp" in this API?
My choices appear to be:
* NULL - We aren't sending any payload back in the response, only an indication.
* handle - One of the allowable options for "rsp" is a handle which I assume to be the handle of characteristic being updated.
* attr_value - One of the allowable options for "rsp" is a full attribute value ... which if I were to send back would presumably be the new/current value of the characteristic.
Since my goal is to acknowledge the processing of the write request ... it seems that all of the above are "equally" semantically correct ... but what does ESP-IDF / the BLE spec require/suggest that I send back as a response?
To send a response I invoke esp_ble_gatts_send_response(). One of the parameters of this function is called "rsp" of type "esp_gatt_rsp_t *".
Now the question ...
Semantically, I have received a request from the partner to update the characteristic value and I wish to respond that I have indeed successfully performed that task. When I execute esp_ble_gatts_send_response(), I am supplying the connection id and the transfer_id and hence that should be "sufficient" context to acknowledge the original event. What if anything should I supply for "rsp" in this API?
My choices appear to be:
* NULL - We aren't sending any payload back in the response, only an indication.
* handle - One of the allowable options for "rsp" is a handle which I assume to be the handle of characteristic being updated.
* attr_value - One of the allowable options for "rsp" is a full attribute value ... which if I were to send back would presumably be the new/current value of the characteristic.
Since my goal is to acknowledge the processing of the write request ... it seems that all of the above are "equally" semantically correct ... but what does ESP-IDF / the BLE spec require/suggest that I send back as a response?