Hi Wayne,
On Tue, May 31, 2016 at 12:59:20PM +0100, Wayne Keenan wrote:
> Hi,
>
> I have a custom GATT service working with read/write all ok; now I am
> looking at adding notify support.
>
> On my first look thru the newt source my first take was that the app needs
> to cache the GATT registrations in 'gatt_svr_register_cb' to obtain the
> chr_val_handle and also track BLE_GAP_EVENT_CONN events and keep hold of
> the conn_handles's
> so at a later point it can trigger a notification (for one for more
> clients) by calling:
> ble_gattc_notify(uint16_t conn_handle, uint16_t chr_val_handle)
>
>
> My first reaction to that is that I must be wrong as that perhaps too much
> duplicated state in the app.
>
> Is there something simpler like 'ble_send_notify(char_handle, data, len)'
> that will notify all connected clients ?
There are a few ways to send notifications:
1. The stack sends them automatically to subscribed clients when a
characteristic value changes. The client subscribes to notifications
(or indications) for a particular characteristic by writing to the
corresponding client characteristic configuration descriptor (CCCD).
2. The way you don't like :). Call ble_gattc_notify() for each
connection-characteristic pair that needs to be sent. These
notifications are sent "at will": the clients don't need to subscribe
to the characteristic via a write to the CCCD, and the characteristic
value doesn't need to change. As you indicated, the application will
need to keep track of both the connection handles and characteristic
value handles.
3. Somewhat closer to what you are asking for:
int
ble_gattc_notify_custom(uint16_t conn_handle, uint16_t att_handle,
void *attr_data, uint16_t attr_data_len)
The difference between this and option two above is that the
contents of the notification are specified explicitly by the
application rather than read from a characteristic. The attribute
handle need not even map to characteristic (though it probably
should).
The nimble stack hasn't gotten a lot of practical use, so there are
undoubtedly some aspects of the API that are lacking common sense. Now
is the perfect time to make changes to the API while Mynewt is still in
its beta phase, and input like yours is extremely valuable. If you have
the time, I was hoping you could add some more details concerning what
you as an application developer would like to see exposed by the nimble
host.
You mentioned a function which would send a custom notification to all
connected devices. Is this exactly what you are looking for, or were
you just trying to make a compromise with nimble's current API?
An additional facility that the host needs to provide is: a means for
the application to discover who is currently connected. As you
indicated in your email, currently it is up to the application to cache
this information, which is certainly not ideal. This is something that
will need to get added in the next release.
Please don't hesitate to complain about anything else that seems to be
missing from the API :).
Thanks,
Chris
