I'm using custom profiles.
My device should send some data using indications.
First question, what is correct method to send indication on custom profiles? Should I use CUSTS2_VAL_NTF_REQ(with notification = false in custs_val_ntf_ind_req parameter structure) or CUSTS2_VAL_IND_REQ message?
If I use CUSTS2_VAL_IND_REQ I cannot send indications at all because when request is handled attmdb_get_value(cfg_hdl, &length, &cfg_val) return ATT_ERR_REQUEST_NOT_SUPPORTED = 0x06, but where is even no check for returned value.
If I use CUSTS2_VAL_NTF_REQ I can send indication but have something that looks like a bug.
如果在重新连接之后发生由超时引起的断开，我无法接收指示。
What do I see?
断开后,my task's state is still CUSTS2_BUSY, so I cannot send new indications.
sdk version 6.0.4.326, chip DA14586
Hi ilnur_muham,
The proper way is to pass the CUSTS2_VAL_NTF_REQ with a notification set to false, the other message (CUSTS2_VAL_IND_REQ) is going to be ommited in next releases of the SDK and its obsolete (and not operational). The reason you get this result from the attmdb_get_values is because the SDK passes a wrong handle for the value to be updated. So the proper way is to use the CUSTS2_VAL_NTF_REQ and the notification in false.
Regarding the second issue that you have, the indications require a confirmation from central, so in order to send the next indication the previous one has to be confirmed, apparently since there is no communication (since there is a timeout), the device is still in busy state, waiting to get a confirmation from the client, but apparently it doesn't and stays in busy state, a quick workaround you can try is to set the task in IDLE state upon disconnection with the ke_state_set(task, CUSTS2_IDLE). As far as i can tell this can be a problem upon disconnections as you have mentioned, i informed the SDK team on this.
Thanks MT_dialog
I just want to mention that second issue occurs with notifications too.
My current workaround which seems to be working for me is to add following lines to custs2_cleanup.
struct custs2_env_tag *custs2_env = (struct custs2_env_tag *)env->env;
if(custs2_env->operation != NULL)
{
ke_free(custs2_env->operation);
custs2_env->operation = NULL;
ke_state_set（prf_src_task_get（＆（custs2_env-> prf_env），0），custs2_idle）;
}
Hi ilnur_muham,
I can see the issue that you are reporting regarding the indications, but i am not able to see what you are mentioning regarding the notifications, at least on the peripheral example, when the device is disconnected, you can connect again and the device is going to be able to send notifications again. What causes the issue as far as i can tell are indications only where the device in order for the profile to go back to IDLE state it should get a confirmation from the central device.
Thanks MT_dialog
Is it still true that CUSTSx_VAL_IND_REQ is deprecated as a way to send characteristic indications? I have implemented an indicated characteristic using this message on DA14585, SDK 6.0.6.427, and it seems to be working fine (i.e. it is "operational" contrary to the guidance from MT_Dialog above). It may however be susceptible to the CUSTSx_BUSY bug as noted. Indications in our application are relatively rare so we may not have seen this issue yet.
此外，SDK 6.0.6.427中包含的BLE_APP_ALL_IN_ONE示例使用CUSTS1_VAL_IND_REQ消息来发送user_svc1_long_val_cfg_ind_handler（）函数中的指示。
Hi mkelwood,
In SDK 6.0.6 you are able to use the CUSTS1_VAL_IND_REQ message to send indications. As, you have already mentioned the ble_app_all_in_one example uses this message and the appropriate handler when you receive a CUSTS1_VAL_IND_REQ message. Furthermore, it is highly recommended to use the latest SDK_6.0.8 for the DA14585 device.
Thanks, PM_Dialog