Posted at 2017-01-14 by @gfwilliams

In Espruino you just need to split it off into an array of bytes - so take each pair of 2 characters and put 0x in front to tell Espruino that each one is a hex value:

00FF0000 -> [ 0x00, 0xFF, 0x00, 0x00 ]

hope that helps!

Posted at 2017-01-19 by pdominique

Thanks Gordon. I just tried but this does nothing (just displays Done! in the console). If I set the same value using the nrf app, the color is set to red.

I believe the Puck can connect to the device, get the service and characteristic because I don't have any exception but the color is not modified when I write a value to the characteristic.

function setLight() {
  var gatt;
  NRF.connect("AC:E6:4B:06:6F:CD").then(function(g) {
    gatt = g;
    return gatt.getPrimaryService("0000ff02-0000-1000-8000-00805f9b34fb");
  }).then(function(service) {
    return service.getCharacteristic("0000fffc-0000-1000-8000-00805f9b34fb");
  }).then(function(characteristic) {
    characteristic.writeValue([ 0x00, 0xFF, 0x00, 0x00 ]);
  }).then(function() {
    gatt.disconnect();
    console.log("Done!");
  });
}

setLight();

Posted at 2017-01-19 by @gfwilliams

I'm not sure what to suggest there - what you've got looks fine.

Are you sure you've got the right characteristic there?

Posted at 2017-01-19 by pdominique

Yes I checked multiple times. And I don't get any exception so I guess the Puck is able to write the value. If I specify a non-existing characteristic, I do get an exception.

Posted at 2017-01-19 by @gfwilliams

Just checking - do you have up to date firmware on Puck.js (1v91?) - I guess it could help.

You could also try waiting a second with setTimeout before disconnecting. I guess the bulb may fail if it doesn't think it can update the status.

Out of interest, what's the light bulb you're trying to write to?

Posted at 2017-01-19 by pdominique

I just updated the firmware but it didn't change anything. I also tried with a timeout.

Here are the devices I want to control: http://www.playbulb.com/en/playbulb-candle-bluetooth-smart-led-flameless-candle.html
I also have some light bulbs from the same manufacturer. Here's a blog I wrote about the candles a while ago: https://pdominique.wordpress.com/2015/01/02/hacking-playbulb-candles/

Posted at 2017-01-19 by @gfwilliams

Ahh, great! I actually saw that blog post when I was looking around at BLE lightbulbs :)

Really strange though - I've used a few BLE bulb like devices and haven't found one I couldn't control yet. Have you tried reading the characteristic (if it supports it?)

Posted at 2017-01-23 by pdominique

Well actually this is what I get when I use readValue() and stringify it:

console.log("Got:", JSON.stringify(value));

>
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v91 Copyright 2016 G.Williams
>
=undefined
Got: "\x00\x00\xFF\x00"
Done!
> 

Posted at 2017-01-24 by @gfwilliams

And what colour is the light when that happens? I'm wondering if the value has actually been set correctly and hasn't taken effect for some reason, or if it just hasn't set the value at all

Posted at 2017-01-24 by pdominique

I can set the color with the nrf app and readValue returns the right value. But I can't set the color with the Puck for some reason.

Posted at 2017-01-25 by @gfwilliams

Strange - not sure what to suggest I'm afraid.

Do you have any Bluetooth sniffing devices you might be able to use to see if there's a difference in how Espruino writes to the Playbulb?

The only thing I can think is that the Playbulb maybe has the handles for the characteristic in a strange order, and that's confusing Puck.js?

Posted at 2017-01-25 by ChristianW

I just bought me a playbulb, too (because I was curious) and will have a look at it tonight.

What I'd try:
On iOS there is the LightBlue app that can create/clone and simulate any BLE device from service/characteristic perspective.
When I pretend to be a PlayBulb on device A (iOS running lightBlue) I can track what the PlayBulb app on Device B actually sends to do certain things.
(Kind of "man in the middle" debugging)

Posted at 2017-01-25 by pdominique

I don't have a sniffing device but using LightBlue to simulate the candle is a good idea.

Posted at 2017-01-25 by @gfwilliams

Can you run this on your Puck, with the PlayBulb's address? It could take a while to complete.

var gatt;
NRF.connect("c4:be:84:de:a9:ba").then(function(g) {
  gatt = g;
  console.log("Connected - finding services");
  return gatt.getPrimaryServices();
}).then(function(services) {
  print(services);
  console.log("Finding characteristics");
    function sender(resolve, reject) {
      if (services.length) {
        var service = services.shift();
        service.getCharacteristics().then(function(characteristics) {
          console.log("Service "+service.uuid+" => ", characteristics);
          sender(resolve, reject);
        }).catch(reject);
      } else  {
        resolve();
      }
    }
    return new Promise(sender);  
}).then(function() {
  gatt.disconnect();
  console.log("Done! Disconnected.");
});

It should dump what I thinks all the characteristics are - I've just noticed having some trouble grabbing the UUID from one smart bulb (I get "0x0000[vendor]") and the problems could be related?

Posted at 2017-01-25 by pdominique

Here you go:

Connected - finding services
[
  BluetoothRemoteGATTService {
    "uuid": "0x1800",
    "isPrimary": true, "start_handle": 1, "end_handle": 7 },
  BluetoothRemoteGATTService {
    "uuid": "0x1801",
    "isPrimary": true, "start_handle": 8, "end_handle": 8 },
  BluetoothRemoteGATTService {
    "uuid": "0xff02",
    "isPrimary": true, "start_handle": 9, "end_handle": 28 },
  BluetoothRemoteGATTService {
    "uuid": "0x180f",
    "isPrimary": true, "start_handle": 29, "end_handle": 32 },
  BluetoothRemoteGATTService {
    "uuid": "0x180a",
    "isPrimary": true, "start_handle": 33, "end_handle": 65535 }
 ]
Finding characteristics
Service 0x1800 =>  [
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a00",
    "handle_value": 3, "handle_decl": 2 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a01",
    "handle_value": 5, "handle_decl": 4 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a04",
    "handle_value": 7, "handle_decl": 6 }
 ]
Service 0x1801 =>  [  ]
Service 0xff02 =>  [
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a37",
    "handle_value": 11, "handle_decl": 10 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfff8",
    "handle_value": 14, "handle_decl": 13 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfff9",
    "handle_value": 16, "handle_decl": 15 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfffa",
    "handle_value": 18, "handle_decl": 17 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfffb",
    "handle_value": 20, "handle_decl": 19 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfffc",
    "handle_value": 22, "handle_decl": 21 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfffd",
    "handle_value": 24, "handle_decl": 23 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xfffe",
    "handle_value": 26, "handle_decl": 25 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0xffff",
    "handle_value": 28, "handle_decl": 27 }
 ]
Service 0x180f =>  [
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a19",
    "handle_value": 31, "handle_decl": 30 }
 ]
Service 0x180a =>  [
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a25",
    "handle_value": 35, "handle_decl": 34 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a27",
    "handle_value": 37, "handle_decl": 36 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a26",
    "handle_value": 39, "handle_decl": 38 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a28",
    "handle_value": 41, "handle_decl": 40 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a29",
    "handle_value": 43, "handle_decl": 42 },
  BluetoothRemoteGATTCharacteristic {
    "uuid": "0x2a50",
    "handle_value": 45, "handle_decl": 44 }
 ]
Done! Disconnected.

Posted at 2017-01-26 by @gfwilliams

Wow, that all looks totally fine. Sorry - not sure what could be the issue there at all then.

All I can think is that the characteristic you're writing to expects 'Write with Response' when Puck.js only performs a 'Write'? I guess you could check with nRF Connect/LightBlue/etc and see what flags are set on the characteristic

Posted at 2017-01-26 by pdominique

nRF Connect says Read and WriteWithoutResponse.

I tried to simulate the device with LightBlue but the Puck can't connect to the fake device (unhandled exception in promise or something). The official app doesn't seem to work with the fake device either. nRF Connect can connect and write to the characteristic just fine though. I can see the new value being written in the LightBlue app.

Posted at 2017-01-26 by ChristianW

I also tried the simulation. At first the PlayBulb app always crashed.
Then I also entered some (most) of the default values I found in the original PlayBulb (e. g. the version strings).
The app then worked, but I could not find/read any values in LightBlue that were changed.

However, I have just now started testing the puck against the real device.
Will give you an update in a few minutes.

Posted at 2017-01-26 by ChristianW

OK - does not work for me either.

I have not hardcoded the MAC but search for devices with the corresponding service:

function setLight( r, g, b ) {
  var gatt;
  var c;

  console.log( "rgb=", r, g, b );
  NRF.requestDevice(
    {filters:[{services:["FF02"]}]}
  ).then( dev=>{
    console.log( "found", dev.name );
    return dev.gatt.connect();
  }).then( g => {
    console.log( "connected" );
    gatt = g;
    return gatt.getPrimaryService("FF02");
  }).then(function(service) {
    console.log( "service found" );
    return service.getCharacteristic("FFFC");
  }).then(function(characteristic) {
    console.log( "characteristic found" );
    c = characteristic;
    return c.readValue();
  }).then( v => {
    console.log( "value", v );
    return c.writeValue(String.fromCharCode(0,r,g,b));
  }).then( r => {
    console.log( "result", r );
    gatt.disconnect();
    console.log("Done!");
  });
}


var col = 1;

setWatch(
  evt => {
    var long = ( evt.time - evt.lastTime ) > 0.2;
    if( long ) {
      setLight( 0, 0, 0 );
    }
    else {
      col++;
      if( col > 7 ) col = 1;

      console.log( "col", col );
      setLight( 
        col & 1 ? 0xFF : 0, 
        col & 2 ? 0xFF : 0,
        col & 4 ? 0xFF : 0
      );
    }
  },
  BTN,
  { edge: "falling", debounce: 50, repeat: true } 
);

readValue()correctly returns the 4 bytes (white-red-green-blue) I have written with LightBlue to Service FF02 / Characteristic FFFC before.

But writeValue()does not do or return anything.

@gfwilliams: You are right. LightBlue shows WriteWithoutResponse for the Characteristic in question by the way.

Is that something the puck BLE code does not handle yet?

Attachments:

• IMG_8475.PNG
  
• IMG_8474.PNG

Posted at 2017-01-27 by @gfwilliams

I just checked - actually Puck.js does do WriteWithResponse (it doesn't do a simple write).

So I'm not really sure what the issue could be here - I think realistically we're going to need to sniff the BLE traffic while writing with the Puck and with another device, and compare the two

Posted at 2017-02-03 by pdominique

I just ordered a BLE sniffer, I'll see if I can use it to sniff the communication and find out what's wrong.

Posted at 2017-02-03 by @gfwilliams

Great, thanks!

Posted at 2017-02-09 by pdominique

Ok I just sniffed the communication between the nrf app and the candle and then the Puck and the candle. The opcode is definitely different and that seems to be the issue (WriteWithResponse not supported by the candle?).

nrf app Write Request:

Bluetooth Attribute Protocol (0x0004)
Opcode: Write Request (0x52)
Handle: 0x0016
Value: 000000ff

Puck Write Request:

Bluetooth Attribute Protocol (0x0004)
Opcode: Write Request (0x12)
Handle: 0x0016
Value: 00ff0000

Puck Error Response:

Bluetooth Attribute Protocol
Opcode: Error Response (0x01)
Request Opcode in Error: Write Request (0x12)
Handle in Error: 0x0016
Error Code: Write Not Permitted (0x03)

Posted at 2017-02-09 by @gfwilliams

Thanks for checking that - it looks likely that's the issue then.

The opcodes aren't the ones I send to the BLE stack (eg. BLE_GATT_OP_WRITE_REQ vs BLE_GATT_OP_WRITE_CMD) but I suppose it's likely that the Bluetooth stack would use its own enumerations anyway.

If you're able to compile yourself, you could change the opcode used in jsble_central_characteristicWrite and see if it makes any difference.

Otherwise it looks like I need to add code to the BLE_GATTC_EVT_CHAR_DISC_RSP handler to store whether 'write with response' is available for a specific characteristic, and then to check that when writing to see which write should be performed.

I've just filed a bug for it here: espruino/Espruino#1059

Posted at 2017-02-09 by @gfwilliams

Ok, please could you try uploading the attached firmware, and see if that helps?

Attachments:

• espruino_1v91.59_puckjs.hex

Posted at 2017-02-09 by pdominique

Thanks Gordon. How do you upload an hex file? I used nrf toolbox before to update the firmware with a zip file.

Posted at 2017-02-09 by @gfwilliams

Sorry, my mistake - it's this file you need.

Attachments:

• espruino_1v91.60_puckjs.zip

Posted at 2017-02-09 by pdominique

It's working now, thanks Gordon!

Would it be a good idea to have a WriteWithResponse and a WriteWithoutResponse? Might be useful for other devices to have the option.

Posted at 2017-02-10 by @gfwilliams

Great! It should be automatic now - based on what the device reports it can support.

If you absolutely want to force it you can change characteristic.properties.writeWithoutResponse and then do a write :)

Posted at 2017-02-11 by ChristianW

I just tried the new build and it works for me, too.