Not recieving information from Nuki

Hi all, recently I can send messages to nuki for the authentication but there’s no reply from nuki. The only reply that I saw is when the payload sent has error i,e: bad crc. We setup a handler that is listen for data when the pairing characteristics sent any but, as I said before, when data is sent correctly I don’t see any response, anybody can share some lights on these, thanks all!


Hi all, continue with the process of authorization of my app with the nuki I sent the first message depict in the help

uint8_t firstMessage[] = {0x00,0x01,0x00,0x03,0x27,0xA7};

but has no answer from the nuki, opposite when I changed the payload of the first message array then the nuki answer with error notification 12:00:FD:01:00:E7:C3 , but no clue why with the correct message I have no answer from the nuki.

Any advice is welcome, thanks!


Hi Jaime,

Please note, that the data has to be sent little endian.
So the message sent should look like this:

uint8_t firstMessage[] = {0x01,0x00,0x03,0x00,0x27,0xA7};


hi @marc thanks for the clarification now I see the answer from the nuki, I’ll continue the process, thanks!


Hi @marc can I ask you what are the possible values for this two fields in the authorization data payload:

ID Type: The type of the ID to be authorized.0 … App1 … Bridge2 … Fob3 …Keypad.
App-ID/Bridge-ID/Fob-ID: The ID of the Nuki App, Nuki Bridge or Nuki Fob to be authorized.

I don’t know if there’s stablished values for these or do I need to define random values, for example this is what I’ll think that are the proper values:

ID Type: App1
App-Id: Fob

Thanks for your support.

Hi Jaime,

If you provide Fob as Type, the Smart Lock will treat your authorization as a Fob and e.g. the app won’t show you settings for remote access, as the fob never communicates through the Bridge.

The App-ID/Bridge-ID/Fob-ID is used by the Smart Lock to detect multiple pairings by the same device. So if you e.q. provide 12 as ID and later create another pairing with ID 12 the previous one will be overwritten.
To avoid this, you may either provide 0 as ID or a random value.


Hi @marc thanks for your response, I´ll continue with this integration.


Hi Marc,

I have a similar problem - No response from NUKI.

Within Wireshark protocol I can see a response byte 0x13.
0x13 is an error code, this tells that the maximum number of users is reached.
There are only 6 users registered.

Here is a short summary of the situation:

>>: send to NUKI
<<: receive from NUKI

NUKI State:
Ring is fully shinning (button >5sec pressed)
BLE connect successful

char-write-req 00 8b 01 00 03 00 27 a7

wireshark BT ATT Protocol
>>: 128b000100030027a7
<<: 13

wireshark full HEX stream:
>>: 0240000d0009000400128b000100030027a7
<<: 02402005000100040013



Hi Walter,

This is your outgoing message in wiresharks format:

Op-Code | Handle |    Value
   12   |  8b00  | 0100030027a7

12 means “Write Request”

Your incoming message 13 is just the “Write Response” sent by the Bluetooth stack to confirm the successful write operation.
So this is no message from the Smart Lock.

Did you subscribe for indications on the characteristic before sending your outgoing message?


Hi @marc I have this error and I don’t know if I understand well the message can you help me to confirm it please:

Error: 12 00 11 1E 00 FA 05

12 00: ERROR
1E 00: here will be the command that was sent at the time of the error but I was sending authorization data
FA 05: CRC calc


Hi Jaime,

It tells you, you’re sending a bad authenticator at the “Authorization ID confirmation” step.
If you send me the whole communication during the pairing including the keypair your side has created I can further analyze this.


Hi @marc thanks for your response, let me review a little bit how I generate the authorization data and I’ll post my findings, thanks!


Hi @marc this is what I sent

#####idType : 02
#####appId : 85 80 80 d4
#####appName : 74 65 73 74 61 70 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#####appNonce : 49 65 c7 fe f7 c3 20 0d 79 3d 80 8e d6 cb 02 cb 79 aa 38 eb cf c4 f0 eb 43 7d f4 fc 92 fc fd 50
#####chNonce : 16 d2 06 6d a3 18 79 38 bf 71 87 5f 91 5e a2 31 85 5b 5e ed 3d 70 89 56 02 1c e9 5c 85 72 62 bc

#####authenticator msg : c3 ec d1 db 8b 1b 87 86 61 88 8a 0f 07 c5 75 c9 77 5b eb 0f fc 6d 73 6e 8a 4e 79 f2 8e 24 d1 f9

#####message data 0: 06 00 c3 ec d1 db 8b 1b 87 86 61 88 8a 0f 07 c5 75 c9 77 5b eb 0f fc 6d 73 6e 8a 4e 79 f2 8e 24 d1 f9 02 85 80 80 d4 74 65 73 74 61 70 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 65 c7 fe f7 c3 20 0d 79 3d 80 8e d6 cb 02 cb 79 aa 38 eb cf c4 f0 eb 43 7d f4 fc 92 fc fd 50 da 11

and the error is 12 00 11 1E 00 FA 05

Thanks for your assistance on these!

No I did not.
How is the procedure for that?



Hi @marc I just resolve the issue, the error was from my side inserting in the wrong order (big endian) the appId, I just resend the correct message and recieve the data for Authorization-Id, thanks for your support!


That depends on the BLE client you’re using but in general you need to write 0x0200 to the characteristics descriptor with the handle 0x2902.

e.g. if you’re using ESP32 within Arduino IDE and you already have a

BLERemoteCharacteristic *remoteChar;

you just need to call

remoteChar->registerForNotify(notifyCallback, false);


Hi Marc,

it now is working fine.
Problem was subscibing for notification (0x01) instead of indication (0x02)