[BLE] How to notify characteristic change on device

Hi,

I'm trying to reproduce some android BLE code in ConnectIQ : the original application connect to a BLE device as a remote (turn off/on, etc).

I have connected my dongle to the BLE device and activated notifications which is working perfectly : change on device trigger callback function.

I can also read one characteristic and get a bytearray in return.

Now I want to write a request to the characteristic. But when i write the value (one byte), a read call returns the new value which contains the byte I sent and not the bytearray anymore.

And if I change something on the device, a read call returns the bytearray again.

My question is : the only missing thing in my code versus the android one (if I understand well) is that the client seems to call notifyCharacteristicChanged on the server after the write.

I don't know if this is what I'm missing but is it possible to do this in ConnectIQ ?

0 jim_m_58 over 2 years ago

Ok, so you pair, turn on notifications for that characteristic, and you see when that characteristic changes and onCharacteristicChanged is called and then you write to that characteristic. Is onCharacteristicChanged still happening in ciq?

When you write, how are you writing? Your not writing to the descriptor as you do to turn on notifications, correct?

And if you are writing to the characteristic, are you using WRITE_TYPE_WITH_RESPONSE or WRITE_TYPE_DEFAULT?

0 MonkeyKiki over 2 years ago in reply to jim_m_58

Hi Jim and thank you for your help.

Here is what I do precisely :

1. Register a profile with service and characteristic from device -> OK

2. Pair the device -> OK

3. Call getManufacturerSpecificData to get device state -> OK

4. Get service then characteristic then descriptor and activate notification on descriptor with "requestWrite([0x01,0x00]b)" (thanks to you !) -> OK

5. In onDescriptorWrite to chain calls (my code is raw for the moment), call :

var value = StringUtil.convertEncodedString("01", {:fromRepresentation => StringUtil.REPRESENTATION_STRING_HEX, :toRepresentation => StringUtil.REPRESENTATION_BYTE_ARRAY, :encoding => StringUtil.CHAR_ENCODING_UTF8});
_characteristic.requestWrite(value, {:writeType => BluetoothLowEnergy.WRITE_TYPE_DEFAULT});

-> onCharacteristicWrite is called -> seems OK ?

6. Call _characteristic.requestRead();

--> onCharacteristicRead is called : the value has been replaced by "01" which seems normal but it is not what I was expecting

7. Press a button on the device

--> onCharacteristicChanged : the value is back to an array of bytes with good values, as expected

I'm no expert in android bluetooth code but it seems that the android application notifies the device once the characteristic has been written : is it a possible use case ?

0 jim_m_58 over 2 years ago in reply to MonkeyKiki

One thing to remember with CIQ BLE is you need to do your own queue for requests. You can't do two read requests in a row, and need to do the first read and wait for onCharacteristicRead before you do the second request for example

0 MonkeyKiki over 2 years ago in reply to jim_m_58

OK, so it's time to refactor my code .

Thanks for the advice : I will do that and tell you the result

0 jim_m_58 over 2 years ago in reply to MonkeyKiki

You can see how I do the queue here.

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

CommQueue.mc contains the basic logic, then in the ble deligate it handles the next in the queue. It also has timeout logic.

0 MonkeyKiki over 2 years ago in reply to jim_m_58

I have coded queue management based on your example and chained the call but still the same result...

0 jim_m_58 over 2 years ago in reply to MonkeyKiki

Are you sure what you are seeing is what the server end is designed to do? Send back one byte after you do the write? You can check the length of what's seen in onCharacteristicChanged and if it's one byte, ignore it.

0 MonkeyKiki over 2 years ago in reply to jim_m_58

I am not 100% sure but it seems to be how the android app does it.

And this call is supposed to turn on the device and it is not happening so i'm sure I'm missing something