BLE: Contents of correct response for ESP_GATTS_WRITE_EVT

[kolban]

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?

[ESP_Island]

Hi, Kolban

Please refer to function example_write_event_env in “gatt server” example (IDF 2.1) to know more about how to process “write event” packets.

If you have received a “write request” packet, what you need to send just only “write response”, so “conn id” and “transfer id” is sufficient and parameter “rsp” can be set to NULL.

There is another case that you might have received a “prepare write request” (if param->write.is_prep == TRUE), you need to build a packet of “Prepare write response” to respond to it. In this case, parameter “rsp” should be set to the “prepare write reponse” packet.

Example “gatt server” inherits the design of Bluedroid. So user needs to respond to gatt packet by themselves, which is complex for beginners. We have designed another method to create gatt service and attributes by building attribute table, which allows the user to respond all gatt packets by stack automatically. We recommend customers to use this method to realize gatt server. You can find it in example “gatt_server_service_table”.

[aalvarez]

Hi ESP_Island, I'm trying to get working the example gatt_server_service_table without luck.
I do not understand which is the handle parameter value that I need to use when I call esp_ble_gatts_set_attr_value in a separate task.

Could you help me with that?

Regards

[mh-dev]

You need to create a mapping between your characteristic and the handle in the ESP_GATTS_CREAT_ATTR_TAB_EVT event.
The indices in param->add_attr_tab.handles[index] are the same that you passed with esp_ble_gatts_create_attr_tab.