Right way to keep a central up to date with infrequently changing peripheral data item

[riceman0]

So we are creating a peripheral with a characteristic meant to keep the central synced with the state of our peripheral.  The peripheral is running all the time, could be ON/OFF/DISABLED/FAULT.  Whenever the state changes (which isnt that often), we update the characteristic with a call to sd_ble_gatts_hvx (which actually returns nonzero if not connected).  We have the properties set to notify.

I think this is incorrect if we want the central to know the value immediately after connection, and if it hasn't changed on the peripheral in a while.  Off the top of my head, maybe we want the characteristic to also have the "read" property set, and the central do an explict "Read" right after connection?  Or is this done implicitly by BLE or the SoftDevice somehow, an event with the value generated for us?

Also on the peripheral side is keeping the characteristic up to date with sd_ble_gatts_hvx  all the time when not connected the right thing to do?  This does seem to fail when we are not connected.  Or right after connect should we do an update, which will notify the central?  (So it doesn't need a "Read")  Or is this also done implicitly somehow if we configure it correctly?

Sorry, these are big questions.  I'm just suddenly realizing that this data item is quite different (rare updates) than the data streams I've created before.

[Hung Bui]

Hi Chris, 

You can update the value of the characteristic using the sd_ble_gatts_hvx () even when it's not connected. Here is the quote from the description of the function :

* @note The local attribute value may be updated even if an outgoing packet is not sent to the peer due to an error during execution.
* The Attribute Table has been updated if one of the following error codes is returned: @ref NRF_ERROR_INVALID_STATE, @ref NRF_ERROR_BUSY,
* @ref NRF_ERROR_FORBIDDEN, @ref BLE_ERROR_GATTS_SYS_ATTR_MISSING and @ref NRF_ERROR_RESOURCES.
* The caller can check whether the value has been updated by looking at the contents of *(@ref ble_gatts_hvx_params_t::p_len).

Both of your options of either do a read at the beginning of the connection or do a notification instead are both good. The option to do a read is preferred in my opinion because you don't have to implement any code on the peripheral side. You only need to allow read permission to the characteristic. The task to read should be done on the central side.