Some questions around Bluetooth Server

[espruino-discuss]

Posted at 2017-11-29 by JumJum

During port of Bluetooth for ESP32 some questions came up. Hopefully there is not too much "it helps if you can read" ;-)

• why do we use writable instead of writeable ? It took three coffee during test to recognize the missing e.
• the only event for a service is onWrite. Is there a reason not to use onRead ? I've added this during test for ESP32
• is there an option to define type of value for "mySpecialService" ? This can be done with a descriptor, but how would I define in javascript ? NRF connect supports byte, uint, text and some others.
• how would I define writeable for value only, and not for description ?
• how would I read or write value of a characteristic?

[espruino-discuss]

Posted at 2017-11-30 by @gfwilliams

why do we use writable instead of writeable ? It took three coffee during test to recognize the missing e.

I don't know - but going by Google results, writable is about 4x more popular than writeable, so it seems like a good one to use. Maybe writable is an americanism?

the only event for a service is onWrite. Is there a reason not to use onRead ? I've added this during test for ESP32

Can we detect that? If so we could add it - although there haven't been any requests for that functionality :)

is there an option to define type of value for "mySpecialService" ? This can be done with a descriptor, but how would I define in javascript ? NRF connect supports byte, uint, text and some others.

Do you have an example? I assumed all you could define (that was actually exported via BLE) was the length and UUID.

how would I define writeable for value only, and not for description ?

I'm not sure I understand. You can't specify a description at the moment as far as I know.

how would I read or write value of a characteristic?

A characteristic that you defined? You can't read it as far as I know (I don't think I can get that info from the Nordic softdevice), but you can use NRF.updateServices to update them. Ideally I guess it'd return a BluetoothGATTCharacteristic or something, but it's hard to do that while also allowing the user to specify data with a simple { .. }.

---

Posted at 2017-11-30 by JumJum

Thanks for the feedback, it gave me something to think about. I'm still, and will be for next time, in the steep part of learning curve. Please see my comments.

• oh, writable is indeed an americanism, have been in the States for more than 20 times, and never heard this. Never stop learning.....
• looks like nRF does not support an read-event :-(
• take a look to https://www.bluetooth.com/specifications/assigned-numbers/format-types and https://www.bluetooth.com/specifications/assigned-numbers/units. I've no idea, how important/helpful this is, or could be. Found it by working through some sources for ESP32.
• I tried this {0xBBCC : { 0x1358 : { value : "Hello", readable : true, description:"bbcc 1358" } } } and took a closer look with nRF Connect. There is a list of descriptors with 1 entry. read this description and you will get the description "bbcc 1358". According to the arrows in nRF connect, both read and write are supported for this descriptor. I would prefer to support read only.
• For ESP32 value is stored, let me say, somewhere. Right now I use hiddenRoot for this. In READ-Event I read the value and copy/send it in a response. Therefore, it is easy to write functions to read and write the value in hiddenRoot. As far as I understand, for nRF everything is stored inside only.

---

Posted at 2017-12-01 by @gfwilliams

assigned numbers

Thanks - in fact it looks like they can be set for Nordic chips as well with p_char_pf. Personally I wouldn't implement it yet though... Nobody has asked for it, and I wonder whether it's really used very much.

description:"bbcc 1358"

Ahh, I stand corrected! It looks like this was something that got added in a PR by Uri, so I must have missed it!

writable

Yes, I totally agree. I don't think there's ever a reason it should be writable?

Looking at the code, char_md.char_ext_props.wr_aux is Writing the Characteristic User Description descriptor permitted. - but it should be set to 0 already (because we memset the whole struct to zero and then don't touch char_ext_props).

Perhaps it isn't actually writable? It's just that there's no way for it to indicate that, so a write attempt will fail?

for nRF everything is stored inside only

Ahh, right - yes, that makes things a lot more flexible. I think for now it's best not to expose that extra functionality though, in order to keep everything as similar as possible between the two? After all, it's not like people seem to asking for the ability to read as it's pretty easy to keep track of the current value.

---

Posted at 2017-12-01 by JumJum

Sometimes, I would like to have the option using onRead. This would help to read/calculate/whatever this value, only if somebody(the client) asks for it.
Anyway, since nRF does not support this in an easy way, I'll remove it from ESP32 port.

Only way to set a new value I know about is nrf.updateServices, correct ?
And the only way to read a value after being written by client is to keep track with onWrite, correct ?

Description is always writable as far as I can see. Puck.js ignores writing a description. It could be done on ESP32, but I don't see a reason doing that.
I'll keep it similiar to Puck.js and last not least its less work for me ;-)

---

Posted at 2017-12-01 by @gfwilliams

Only way to set a new value I know about is nrf.updateServices, correct ?

And the only way to read a value after being written by client is to keep track with onWrite, correct ?

Yes, that's right - on both counts. Personally I'd have thought that getting JavaScript to supply the value on demand might be quite difficult given the time it might take to execute?