UUID is shown by Nuki Smart lock that we do not understand

Nuki APIs Bluetooth API
#1

Hi,

An update of our Nuki ESP32 BLE library caused some issues with users. We have been able to solve this but while troubleshooting we have been seeing strange behaviour for 1 user.

He has a Nuki Smart Lock V3, running fw version 3.4.10.

We are seeing a, to me unknown, UUID “01601cf5f0d430060001000102ed9b91” advertising from the Nuki Smart lock.

We are logging the following format:
time > BT address sending data | UUID we are expecting (the keyturner service UUID) | the UUID that is advertising

13:28:59.506 > 54:d2:72:c3:35:c5 | a92ee200-5501-11e4-916c-0800200c9a66 | 01601cf5f0d430060001000102ed9b91
13:29:00.530 > 54:d2:72:c3:35:c5 | a92ee200-5501-11e4-916c-0800200c9a66 | a92ee200550111e4916c0800200c9a66
13:29:00.540 > [786648][D][NukiBle.cpp:225] onResult(): Nuki Advertising: Name: Nuki_33C335C5, Address: 54:d2:72:c3:35:c5, manufacturer data: 4c000215a92ee200550111e4916c0800200c9a6633c335c5c8
13:29:00.556 > [786661][D][NukiBle.cpp:237] onResult(): iBeacon ID: 004C Major: 13251 Minor: 13765 UUID: a92ee200-5501-11e4-916c-0800200c9a66 Power: -56
13:29:00.567 >

The first line contains UUID “01601cf5f0d430060001000102ed9b91” which is unknown to me.
The second line is what is the “normal” keyturner service uuid

We have been unsuccessful in reproducing this (except for this one user).
User tried to eliminated the possibility that this is coming from other devices by turning off BT on laptop and phones and trying it on a different location but no result.

Do you recognize this UUID?
If yes is this new and what is the functionality?

Thx,
Jeroen

#3

Hi Jeroen,

This advertisement might be related to Apple HomeKit.
These advertisements start with the same first bytes as iBeacon messages.

Example iBeacon message:

image
image1080×667 89.7 KB

Example HomeKit message:

image
image1080×451 76.3 KB

best,
Marc

#4

Hi Marc,

thx for looking into this.

I do not really understand with what you mean with “These advertisements start with the same first bytes as iBeacon messages.” I do not see any similarities in your screenshots. Could you elaborate a bit more? Or are you referring to my logging in the first post? it might be a bit confusing but the “UUID we are expecting (the keyturner service UUID)” comes from a define within the code and has nothing to do with what we receive it was merely to show to the user what he should receive.

And what looks strange to me is that in your screenshots both “complete local name” are the same for the ibeacon comming from the nuki smart lock and from the apple home kit?

thx,
Jeroen

#5

Hi Jeroen,

Sorry, here are screenshots containing the complete raw messages.

iBeacon:

image
image941×674 90.1 KB

HomeKit:

image
image940×724 105 KB

Both are type 0xFF (= manufacturer data) but differ in length (22 vs. 26).
The first bytes of the manufacturer data are 0x4C00 (= apple) in both cases but the rest differs.

When HomeKit is enabled, the Smart Lock sends out the necessary HomeKit advertisings additional to the regular advertisings. And they share the local name, yes.

best,
Marc

#6

awesomefast nightly reply :slight_smile:

But the apple homekit UUID is not the UUID as we are seeing. Isn’t this always the same UUID for communication with the Apple HomeKit?

I just read there are also other integrations like Alexa and google, this works the same way and also not fixed UUID’s?

#7

Hi Jeroen,

Point is, it is not a UUID in this case but specific data for Apple HomeKit that will differ per device and also per state and some other factors.
The UUID is only part of the iBeacon payload.

I assume you’re just taking a specific range of bytes out of the advertising payload and handle this as UUID. If so, you should check if it is an iBeacon first (Type 2 by Apple as shown in my first screenshots).

As HomeKit is the only integration that is done via BLE, this is the only one that affects advertising.

best,
Marc

#8

Hi Marc,

We indeed compare a part of the data received (pHex) with what we expect and if it is not what we expect we set a bool (isKeyTurnerUUID ) which en/disables further processing.

for (int i = 0; i < len; i++) {
  if (serviceUUID[i + offset] == '-') {
    ++offset;
    --len;
  }

  if (pHex[i + 8] != serviceUUID.at(i + offset)) {
    isKeyTurnerUUID = false;
  }
}

We will look into your suggestion and implement it.

Awesome help!! Thank you very much.

Jeroen