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
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?
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?
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.
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.
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.
