Espruino BLE on Puck.js - know when a central has read from a characteristic

In Espruino on a Puck.js, I want to implement a BLE application that works as follows:

• Puck.js running as BLE peripheral
  
• Central, an iOS app, is not connected to Puck yet
  
• Puck button presses add a value to a FIFO queue in the Puck
  
• Central connects to Puck
  
• Each time the central reads from the characteristic, the next queue entry is read
  
• When there are no more queue entries, the characteristic returns a "no more entries" value such as an EoF
  
  

I have not found an onRead event in the NRF.setServices properties (like the onWrite that is available) or any event in Espruino that I can use to implement the above logic. Am I missing something in the docs that might allow this? Is there an approach I can use with Espruino? I could write to the characteristic to remove the queue entry in the Puck but I'd like to avoid doing this. I'm not looking for a workaround, just a method of knowing, in the Espruino code, when a characteristic is being or was read.

Edit 1: I understand that the Nordic SoftDevice does not provide an API to check if a characteristic has been read but there is a security event that I can watch so am wondering if I set up the characteristic in such a way that I'll get a security event on every read. I've tried the combinations supported according to the Espruino hardware reference but still luck on getting the security event on read to fire.

Thanks

Larry

what about notification? central subscribes to notifications from characteristics, each button press fires notification with new value, central gets it when it happens without a need to ask at random moment by reading it

and if you really need it queued and received later you can trigger sending notification from queue by writing. this can result in same amount of traffic as reading the value also means sending ble packet to puck and getting the result value back

Edit: in fact this might be more efficient if you have more entries accumulated in the queue, by triggering notification by write you can then send more entries from queue via notifications at once (based e.g. on value written). this is less traffic/faster than reading values one by one

Hi! As @fanoush says having a write to trigger a notification is probably the best bet.

Puck.js doesn't provide any onRead event, and as you say the softdevice doesn't appear to provide an event which we could hook onto. For the security event, do you mean BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST ? I'm not sure if you could actually rely on that to happen for every read?

This approach could work. Thanks. The puck may be accumulating events when not connected to the central and if there is nothing queued up in the Puck then I turn off the Puck's radio. When there is something, the Puck will start advertising, central will connect and write causing the Puck to batch up what's in the queue and notify central. Central writes, and if nothing left in queue, Puck goes to sleep again.

I think so, if I could require authorization on every read then I could use this to know if a read is happening. Not sure how to configure security in Espruino to make this happen and if I would receive an NRF.on('security' event - that was the hope.

Edit: I don't see a JS event being fired for BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST in https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c around line 1355 but I'm not that familiar with the Espruino source.

Not sure how to configure security in Espruino to make this happen and if I would receive an NRF.on('security' event - that was the hope

I'm not sure either to be honest, and I don't think you'd get a security event for that. I'd imagine that probably once the device had been authorized that would be it though - otherwise writes to secure endpoints would end up running significantly slower than to insecure ones.