Hiya Chris,
On 31 May 2016 at 16:36, Christopher Collins <[email protected]> wrote: > > > 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). > > I didn't know newt would automatically do that, thanks for letting me know. Because I'm creating a 'ble_gatt_svc_def' at runtime these are the steps I'm having todo to be able to keep hold of the characteristic handle in order to be able to call 'ble_gatts_chr_updated(handle)' to send the notification when needed: 1. When initialising the 'ble_gatt_chr_def' the 'arg' field is set to a marker value. 2. In my 'gatt_svr_register_cb' callback if a ble_gatt_chr_def.arg marker value is found then the 'ctxt->chr_reg.def_handle' is stashed in a global var. 3. (In theory) update the characteristic value 4. Invoke 'ble_gatts_chr_updated(handle)' At step 3 I say in theory because currently I'm not... is it safe to cache the 'union ble_gatt_register_ctxt *ctxt' pointer given as a parameter 'gatt_svr_register_cb' to use later? Being able to call Newt GATT API's like the following would help alleviate steps 1,2 and help with step 3: a) uuit16_t gatt_get_handle_for_chr(serviceUUID, charUUID) b) int gatt_write_chr(uint16_t handle, void* data, uint len, bool sendNotificationIfEnabled); > > 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. > OK, cool. > 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? > Just trying to understand. > > 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. > That could be useful, although it would be convenient if something like API example 'b' above automatically notified all the relevant (connected and subscribed) central devices. > All the best Wayne
