setEventHandler Not Returning UUID

Just curious, is anyone else seeing the characteristic UUID come back as random characters? I'm using the latest ArduinoBLE 1.2.0 library with an Arduino Nano 33 IoT. I'm using callbacks and when I ask for the properties of the characteristic I see them just fine but when I ask for the UUID I get stange digits or blanks. The setup is this:

void configureCallbacks(void) {

  if (pCharProps & (BLEWrite | BLEWriteWithoutResponse)) {
    pCharacteristic[cIndex].setEventHandler(BLEWritten, handleCallbackEvent);

The characteristic is declared globally and is part of an array of characteristics. The function called is this:

void handleCallbackEvent(BLEDevice central, BLECharacteristic characteristic) {
  Serial.print("Oh boy! 0x");
  Serial.print(, HEX);
  Serial.print(" ");

The debug monitor is something like this:

20:51:11.697 -> Oh boy! 0x12 (G
20:51:58.246 -> Oh boy! 0x28 (G
20:52:14.887 -> Oh boy! 0x2A (G
20:52:19.153 -> Oh boy! 0x2A (G
20:52:28.903 -> Oh boy! 0x1A (G
20:52:37.810 -> Oh boy! 0x2 (G
20:52:44.842 -> Oh boy! 0x2 ⸮T
20:52:51.545 -> Oh boy! 0x2 ⸮T
20:52:55.389 -> Oh boy! 0x2 ⸮T
20:52:59.252 -> Oh boy! 0x2 ⸮T

I know the UUIDs of all of these characteristics. Most of them are 128-bit but one is 16-bit.

I hope this is something simple like a conversion I missed because I want to be able to identify which out of 11 different characteristics is the one firing this event, and I figure the UUID is the best way to do that. Any suggestions are welcome.

Could you please post a complete example? I am happy to help but would prefer modifying your example instead of writing one myself first.

Thank you for your help. The Arduino editor tells me the entire code is 961 lines long, so I will condense it a little: Here is the definition header for the characteristics declared globally:

const byte maxNodeCnt = 16;                     // maximum num. of BLE devices supported
BLECharacteristic pCharacteristic[maxNodeCnt * 4] = {}; // periph. char. table - global

Here is the code that creates the characteristics. It stores them in an array of characteristics for later use. The array is hard-coded for 12 objects (0 - 11):

      BLECharacteristic myCharacteristic(pCharUUID.c_str(), pCharProps, pCharDataLen);
      pCharacteristic[c] = myCharacteristic;

Here is the section of the main loop() that acts like a peripheral (I am going back and forth between scanning and advertisement with delays between both):

  if (devCount > 0 && !initDone) {

    if (initPeripheralAdvertising()) {          // build a GATT profile
      initDone = true;
  central = BLE.central();

Here is the function that is of interest (the second byte of the countDB array value contains decimal 11 and advCount always equals 0, both hard-coded for testing purposes). This function is called once in the main loop then never called again because of the initDone boolean above:

void configureCallbacks(void) {

  byte pCharProps = 0;
  byte cLen = byte((countDB[advCount] & 0x0000FF00) >> 8);

  for (byte ch = 0; ch < cLen; ch++) {

    byte cIndex = advCount + ch;
    byte pCharProps = pCharacteristic[cIndex].properties();

    if (pCharProps & BLERead) {
      pCharacteristic[cIndex].setEventHandler(BLERead, handleCallbackEvent);

Finally, my debug function just to see what’s what:

void handleCallbackEvent(BLEDevice thingOne, BLECharacteristic thingTwo) {
  Serial.print("Oh boy! 0x");
  Serial.print(, HEX);
  Serial.print(" UUID is 0x");

The Arduino editor tells me the entire code is 961 lines long, so I will condense it a little:

Don't worry, you can just add a sketch file if the code is too long. I just want to be able to compile the code, see what happens and then follow the leads.

I apologise - we are part of a project that prohibits us from sharing the entirety of our code in a public forum or with others not connected with our group at this time. I was hoping my problem could be dealt with easily but it seems it will take some investigation into my (poor) coding skills.

I have found a workaround in the meantime which is to detect when the central is connected and then perform an array scan of all the characteristics with the properties that were just activated (read from, written to, subscribed to). It is slow but it seems to work.

I thank you for your offer to help regardless. If I discover the underlying reason why our callback routines are not working I will post back here with an answer.

  • Fred

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.