BLE notifications on nRF devices

The way to expose BLE services on nRF devices is to use NRF.setServices (cf. doc).

It is possible to set broadcast: true for broadcasting but not notify: true. The fix to make it available is pretty straightforward:

@ jswrap_bluetooth.c:1420 @ void jswrap_nrf_bluetooth_setServices(JsVar *data) {
       memset(&char_md, 0, sizeof(char_md));
       if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "broadcast", 0)))
         char_md.char_props.broadcast = 1;
       if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "notify", 0)))
         char_md.char_props.notify = 1;
       if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "readable", 0)))
         char_md.char_props.read = 1;
       if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "writable", 0))) {

With the above fix, it is possible to set a characteristic to NOTIFY like so:

NRF.setServices({
  0x0000: {
    0x0001: {
      value : "Hello",
      maxLen : 5,
      readable : true,
      notify : true
    }
  }
});

However, what would be the best way to update the characteristic's value? Calling NRF.setServices repeatedly does not seem to be the way to go.

Yes, I was wondering about that - which is why the code's not in there yet.

Any suggestions?

• We could add an updateServices that updates the values of just the specified services.
  

• NRF.setServices could return an array of objects, so you can do:

  var gatt = NRF.setServices(...);
  gatt[0x0000][0x0001].write("Foo");
  

• Or it could take a callback which contained the specific object:

  NRF.setServices({
  0x0000: {
  0x0001: {
    value : "Hello",
    maxLen : 5,
    readable : true,
    notify : true,
    onCreate : function(handle) {
      // all created now...
      handle.write("Foo");
    }
  }
  }
  });
  

The first solution seems straightforward to me. It would make using the REPL to test value updates very convenient.

Another possibility would be to set value to some observable object and have updates be automatically reflected in the characteristic but it may overly complicate things.
An explicit write seems to be simpler to use and document...

Observable object is a good idea, but I guess it's actually quite an advanced idea if you're just getting started.

Looks like updateServices then - it'll be easier to put in a Blockly block too. I'll create an issue for it.

Not sure when it'll get implemented though - are you just playing around with this or are you trying to put it into a product of your own?

I could have a stab at a pull request if that helps. The nRF SDK has plenty of example code and I should be able to figure it out.

Yes, that'd be great. I guess the worst bit is going to be finding the handles from the UUIDs, but it shouldn't be too hard.

Issue here: https://github.com/espruino/Espruino/iss­ues/915

I'll post further design questions on the issue directly.

Thanks! Yes, that's probably easier