Certainly a feature request, but it really is needed information to help authenticate that you're dealing with the correct device and/or let the user know when it is wandering out of range.

Having the RSSI only while scanning makes it difficult, because there can me many, many devices (at least in my office there are >20). Hoping this can sneak into the next release (or a beta?).

Happy to test!

Have just added this in my repo.
First I wanted to introduce the API to the GATT instance, but it also worked with the existing static NRF object, so I left it for now.
The changes are minimal.
What do you think?

Great! I'm a bit of a NOOB; can you give me a quick example of usage? And how I can test it out?

The branch is not reviewed, merged or released yet, so you have to build it first and flash it to your device.

Then when you are connected to another peripheral, just do:

NRF.setRSSIHandler(function(rssi) { console.log(rssi); });

like when you are the peripheral yourself.

Documentation: http://www.espruino.com/Reference#l_NRF_setRSSIHandler

If it's for the puck.js I just compiled it (do not have the devices at hand, so you may test on your own risk):
espruino_1v91.2685_puckjs.zip

How to flash the ZIP to your puck is documented here:
http://www.espruino.com/Puck.js -> Firmware Updates

Is it possible to have both?
Indeed - I have not considered this.
From the way it is implemented currently you would get the RSSI from the connection where you are the central (because this is the handle that is checked finally and overrides the other one).

For the future there are two options:
a) keep the API and put something in the callback to tell both cases apart
b) have a different API and callback for both sides

I think b) would be more elegant, since the RSSI with you being central is actually bound to the connection object.
There is no such thing when you are peripheral, so the NRF-global-object approach is sufficient.

Thanks for the commit - as @billsalt says a separate API call might be better though. While your approach would work well, I guess it could be confusing if someone was having success using it for a peripheral connection but then started a central connection and it suddenly changed what it did.

I guess we could add the central API call to the BluetoothDevice object just in case >1 central was ever supported (I don't think it would be given RAM constraints) - but then that's a non-Web Bluetooth compatible addition.

I guess maybe setRSSIHandler(function) for peripheral and setCentralRSSIHandler(BluetoothDevice, function) for central? One function could do both but I guess it might be confusing

OK - thanks for the feedback.
I was going to add it to BluetoothRemoteGATTServer but I could also change that to setCentralRSSIHandler() like you proposed.

Question: should I just assume there is only one central (global m_central_conn_handle) or do something with the handle of the object?

It's tricky, BluetoothRemoteGATTServer would be the obvious place, but then it's not following the Web Bluetooth spec. Actually yeah, just add it in there as setRSSIHandler - maybe just make a note in the comments that it's Espruino-specific :)

Just assume one central and use m_central_conn_handle - it's what everything else does, so trying to handle multiple connections would require everything to change anyway :)

Thanks!

hi @gfwilliams and @Whizzard -- what's the status of this? I'm at the point where I'd like to try it out. I'll want to get it compiled for the nRF52830 dev board (PCA10040).

Thanks!
Bill

Fixed with https://github.com/espruino/Espruino/pull/1148/files

@gfwilliams thanks Gordon! Is this v1.92 or a new experimental build? Trying to understand the versioning/build process for espruino.

It'll be in an experimental build, until 1v93... http://www.espruino.com/binaries/travis/master/