Evothings

Using easyble, after calling,

device.enableNotification(MY_UUID,win,fail)

I get notifications on iOS but not on Android. After some searching, it seems as if on android, I have to first enable notifications by writing a bit value to the client characteristic configuration descriptor which I have attempted to do with the following:

var bytes = [0x01,0x00]
device.writeDescriptor(MY_UUID,"00002902-0000-1000-8000-00805f9b34fb",new Uint8Array(bytes),win,fail)

But I still do not get notified on Android. Any ideas?

I did try to read back the descriptor value that I set above with:

device.readDescriptor(MY_UUID,"00002902-0000-1000-8000-00805f9b34fb",win,fail)

which gives: "ReferenceError: value is not defined" inside the easyble code.

Hi.

Did you check which callback is called after
device.writeDescriptor(MY_UUID,"00002902-0000-1000-8000-00805f9b34fb",new Uint8Array(bytes),win,fail) ?
if the fail callback is called what is the error code?

Sorry, i should have included more specifics. The win callback is fired after the call to writeDescriptor, so there is no error on there write though I guess it is possible that I am writing the wrong value.

Neither of the callbacks are fired after the call to enableNotification. I added a log message to the easyble method, so I confirmed I got there, but it seems to be rejected after that. And again, this code is working in iOS, just not on Android.

I actually figured this out. I was originally write [0x01,0x00] to the descriptor based on the following that I found in the actual android BLE java code:

public static final byte[] ENABLE_NOTIFICATION_VALUE = {0x01, 0x00};

It turns out that value is wrong and should be [0x02,0x00]. When i made the change, notifications work as expected.

BONUS: the Reference Error in easyble's readDescriptor looks like a bug. I commented what looks wrong and replaced it as shown below and that also now works:

// evothings.ble.readDescriptor(
// device.deviceHandle,
// descriptor.handle,
// //value,
// function()
// {
// success();
// },
// function(errorCode)
// {
// fail(errorCode);
// });
evothings.ble.readDescriptor(
device.deviceHandle,
descriptor.handle,
success,
fail);

@sjrcgtek

Many thanks for finding this bug! Pushed a fix: https://github.com/evothings/evothings- ... 27d6909dab

Closed this issue: https://github.com/evothings/evothings- ... s/issues/4

Regarding enabling notifications, the plan is to handle this in the native plugin code, here is a related issue:

https://github.com/evothings/cordova-ble/issues/30

I have used new Uint8Array([1,0]) to successfully turn on notifications, do you know why that did not work in your case? My understanding was that this was a standard thing.

Thanks again for the help!

Best regards, Mikael

The spec here: https://developer.bluetooth.org/gatt/de ... ration.xml

would seem to suggest 1,0 for notification and 2,0 for indication, but when it didn't work, I tried setting the other bit out of curiosity and it worked.

I am just diving into BLE at this point, so maybe there is some other reason that I have not figured out yet, but i did find something on stack overflow that indicates the behavior is device specific: http://stackoverflow.com/questions/2090 ... ble-device.

Good to hear that you are pushing the complexity of enabling notifications into the plugin. Even if not there, handling it in easyble would be helpful.

For the sake of completeness, I was finally able to talk to the engineer of the device and it was a misunderstanding on my part. The device was set up specifically to support indications and NOT notifications, so now it makes perfect sense that replacing 1,0 with 2,0 worked in my case. I mistakenly assumed all devices supported both and that it was up to me as the programmer to turn one or the other on.