Hi David,
Mike wrote a good reply, but a few things that were said are based on an
older version of the nimble stack. Thankfully, some parts have improved
since 0.9.0. My response is below.
On Mon, Nov 28, 2016 at 03:42:01PM -0500, David G. Simmons wrote:
[...]
> GATT_SVR_CHR_NEW_ALERT is a 'subscribable' UUID, and I would expect that
>
> case GATT_SVR_CHR_NEW_ALERT:
> if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
> rc = gatt_svr_chr_write(ctxt->om, 0,
> sizeof gatt_svr_new_alert_val,
> gatt_svr_new_alert_val,
> &gatt_svr_new_alert_val_len);
> return rc;
> } else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
> rc = os_mbuf_append(ctxt->om, &gatt_svr_new_alert_val,
> sizeof gatt_svr_new_alert_val);
> return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
> }
>
> would get called when I subscribe to this characteristic. But it does not.
>
> So, if I want to have a subscribable service characteristic, How do I
> implement that, and where does the characteristic value get updated so
> that it is propagated to the connected device (if any)?
As long as you specify one of the BLE_GATT_CHR_F_NOTIFY or
BLE_GATT_CHR_F_INDICATE flags in the characteristic definition, the
characteristic will be subscribable.
When a peer subscribes to a characteristic, the stack signals this event
to the application via the GAP event callback associated with the peer.
When a peer unsubscribes, this is signalled via the same mechanism. For
rationale on why the GAP event callback is used here, see this email:
https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43@%3Cdev.mynewt.apache.org%3E
As Mike indicated, your application tells the stack that a
characteristic's value has changed via the ble_gatts_chr_updated()
function. It is up to the application to actually change the value
prior to calling this function.
If you are not sure which handle is associated with a particular
characteristic, you can perform a lookup by
service-characteristic-UUID-pair using the ble_gatts_find_chr()
function.
Thanks,
Chris
