当我们完成ESP32和blufi的连接之后，也就是完成了服务（0xffff）和特性(0xff01,0xff02)的设置之后,我们就要开始进行交互（不理解的可以看一看上一篇文章）。
小编对于蓝牙协议栈也没有很深入的了解，也可能有更多方式解决此问题。此处只是分享自己的一些小踩坑经验。
对于ESP32的gatt交互，其实接收消息都是由统一的ESP_GATTS_WRITE_EVT事件接口进行处理，因此我们能直接拿到最终数据，然后对数据处理即可。我们主要需要关心的是如何发送。于是我们查找接口，发现发送接口很多，无从下手。
面对如此多的发送接口，我们很难下手，然后到网上找一下解决方法。找到了这些方法
- ESP32开发路程蓝牙篇——BLE(GATT)，修改设备名称，添加characteristic，发送数据，接收数据_esp_ble_gatts_set_attr_value-CSDN博客
- ESP32学习笔记（30）——BLE GATT服务端自定义服务和特征_ble_svc_gatt_handler_Leung_ManWah的博客-CSDN博客
- ESP32-C3 学习测试 蓝牙 篇（七、GATT 数据通信 — 发送自定义数据）_esp-at实现gatt通信-CSDN博客
看了这些文章之后，发现大佬们都有自己不同的看法。然后我就一一照抄了一下都没能实现想要的结果。
此时我总结了一下发现：我的目的是手机发消息给设备，设备回复，而大佬们讲的方法都是手机主动去读取，因此和我的功能产生了冲突。于是我不再将上报函数放在ESP_GATTS_READ_EVT回调事件中，转而将需要转发的函数接口放在了ESP_GATTS_WRITE_EVT事件中，处理完数据后进行回复。这时候又到了试错环节，将几个函数又连续的放进去测试。终于，在不报错的情况下，找到函数接口esp_ble_gatts_send_indicate可以不报错的上报数据成功。于是确定了函数接口。
此时，我们利用其和bluFi进行通信，发现还是不行。通信也通了，收发也能收发了，但是还是无法通信，怎么办呢，我们找到blufi的demo，利用蓝牙助手调试对比一下。
经过对比，原来是我们开始时多了一条上报。但是研究了上报消息内容后发现，这个位置上报这条消息是不会影响通信的才对。但是鉴于找不到其他方法解决此问题，我们还是决定一试，没想到过了。（有人发现是什么原因可以发出来讨论）
此时此刻通信即可完成，ACK也可以正确回复，但是，我们只是运气好才走到了这一步。我们再回看乐鑫的官方文档：
此时我们发现，作为设备，需要用FF01作为接收方，发送要使用FF02。该怎么确定ff01还是ff02呢，我们对函数接口还是要进行分析。
怎么查看参数怎么使用呢，那就是抄一个呗。
esp_ble_gatts_send_indicate(gatts_if, param->write.conn_id, gl_profile_tab[PROFILE_A_APP_ID].char_handle,//向 GATT 客户端发送指示或通知。
sizeof(notify_data), notify_data, true);// 是否需要确认。false是不需要确认
从上述代码可知最后一个参数为是否需要回复，对于blufi好像无效，我们就随便填一个false,再往前两位是数据和数据大小，我们填充自己需要的数据即可。之后剩余3个参数是比较难确定的参数，gatts_if：GATT 服务器访问接口为服务器访问接口，和服务相关联，因为每一个服务对应同一个回调函数，因此一个函数中的gatts_if我们不需要修改。之后是连接id： param->write.conn_id，每个连接会建立一个连接id,因此我们将收到的连接id塞回去就可以了。还剩最后一个参数，也就是最重要的一个：attr_handle属性句柄。这个属性句柄就是和FF01和FF02相关的，如果我们只用一个服务，我们就用该服务完成收发，因此哪个发下来的消息我们就回给哪个，因此可以填入：param->write.handle。但是，明显这样是不符合我们的需求的，因为我们收到的是FF01的句柄消息，我们需要给ff02回复。此时我们想到了FF02的句柄也是我们所写，因此就比较好确定了。因为ff02在ff01之后定义，所以数组内的char_handle此时此刻为FF02的属性句柄，这就好办多了，gl_profile_tab[PROFILE_A_APP_ID].char_handle。（其他属性回复也按照此方法设置）。
那我们如何确定自己发送的属性确实成功了呢？我们只需要将属性特征值的能力限制了即可，就是让他只支持读或者写，这样的话写错了句柄就会报错。
至此，blufi和gatts services DEMO 的交互设计完成。