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!
Jaime
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!
Jaime
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};
regards,
Marc
hi @marc thanks for the clarification now I see the answer from the nuki, I’ll continue the process, thanks!
Jaime.
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.
Jaime
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.
regards,
Marc
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:
Definition
>>: 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
Br,
Walter
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?
regards,
Marc
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
11: P_ERROR_BAD_AUTHENTICATOR
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
Thanks!
Jaime
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.
regards,
Marc
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!
Regards
Jaime.
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!
Jaime
No I did not.
How is the procedure for that?
regards,
Walter
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!
Jaime.
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);
regards,
Marc
Hi Marc,
it now is working fine.
Problem was subscibing for notification (0x01) instead of indication (0x02)
br,
Walter