Dynamic reading of BLE characteristic?

Robin - thanks for your reply.

I don't think those links covered it, though thanks for pointing them out.

To try to explain a bit better what I was meaning:

The pixl.js wireless temperature example above has a line 'setInterval(updateBT, 6000);' so updateBT() reads the temperature every 6 seconds, and updates the advertising packet. This is all you can do with advertising, as advertising doesn't know if anything is actually listening - it just broadcasts - like a TV station that keeps broadcasting even if nobody is watching the channel - it doesn't know. But doing this uses battery - and we're wasting battery taking temperature readings that nobody might ever want.

If my understanding is correct when using GATT services and attributes the model is different - the phone must actively send a packet to the Puck to ask "Please tell me the value of this attribute of the temperature service". This normally returns the value field specified in nrf.setServices via a packet which is sent from the puck to the phone.

Say (for example) we were developing a thermometer and we wanted the Puck battery to last as long as we could. This thermometer might be in a remote location, and is hardly ever used.

Ideally, the puck would do nothing but periodically wake the radio to receive and see if there is a phone there talking to it. Normally there isn't, so it just sleeps all the time and uses little battery. It doesn't need read the temperature in all this time so it doesn't, and saves battery.

Now say the user goes to the remote place to use this rather contrived thermometer. They get out their phone and connect to the Puck. The phone does its Bluetooth thing and sends the "Send me the value for this service and this attribute" packet to the Puck.

The Puck hears the packet and only then does it actually need to read the temperature. "Finally! At last! Someone is interested in my temperature!" So it calls some sort of 'onRead' callback or something. This callback does the work of reading the temperature, and sends back the value to the phone via another packet.

The user is done so the Puck has a good long sleep again, not ever needing to read the temperature again until the user comes back, and just sipping power from the battery as a result.

I hope this slightly contrived example illustrates better the sort of thing I'm getting it. I'm not trying to do anything new against the code I posted - just curious as it seemed like a way which would optimise battery life but couldn't figure it out. I don't actually have a need for this, but always like to learn a better way.

My point of "what if my function took a long time to execute": I don't think setInterval() would work here. I know BLE has connection intervals and things so that packets must be sent at the correct time. I was thinking that maybe the reason you can't do a read from a user 'onRead' callback (as I'm asking for here) might be that it could mess with the timing - if my callback took a long time it might mess up the timing and cause the Bluetooth stack to crash, or the phone to be upset if it didn't get a quick reply.

I don't think it's setScan either - the Puck already wakes up to service the request so I don't think I need to mess around with that.

I feel I've written a bit of a tome here - but hopefully my convoluted story illustrates better what I was trying to get at!