Fail to create a user on Nuki 1.0 smartlock

Nuki APIs Bluetooth API
#1

Hi,

I have a sample example that runs on esp32 microcontroller which connects successfully to Nuki 2.0 smart lock, creates a user (pair) and locks the smart lock successfully without any issues.

but the same code fails to create a user when it connects to Nuki 1.0 smart lock.

The code belongs to my employer so unfortunately, I can’t share snippets of it. But the logic is straight forward.

  • Scan for the pairing service and connect to the first device that advertise such service.
  • Register for notify and enable indications
  • Write request data command with the public key and follow the logic explained in the api description

for nuki 2.0 it goes on without any issues.

for nuki 1.0 (fw version 1.8.1) i receive the shared key from the smart lock then the corresponding indication

12 00 ff 00 00 b6 9e
then it disconnect.

any help where i can start looking ?

Thanks

#2

@Stephan would appreciate your help :slight_smile:

#3

There should be no difference for Smart Lock 1.0 and 2.0.

Maybe @marc can help if you share some more details with him.

1 Like
#4

This is a error response and FF means “Unknown” error.

But to really look into this I would need a dump of the whole communication.

#5

Hey @marc

Thanks for the quick reply…

Here is the communication back and forth, let me know if it’s not clear enough!

  + Client sends Pairing command 
  Write: : 01 00 03 00 27 a7

 + Nuki sends indication values of 
  03 00 2c ac 74 26 8f 85 94 88 71 e9 19 b7 0a c5 97 3e ef 95
 
+ Nuki sends indication values of 
   4e 5d 23 f9 a7 79 17 71 24 fe 91 34 c6 65 ad 4e

   ***Public Key Received***

+ Client sends 
 03 00 52 5e d4 41 4e 1b 3e  cc d5 01 d4  f3 b2 ed
 04 e4  bf ad  8a b6 78 21 27 ca  7e 1a  95 39 60 a7
 6c  7f   53 25 

+ Nuki sends indication values of 
 12 00 ff 00 00 b6 9e

+ Nuki disconnects from the client

#6

Hi Omar,

The communication looks ok.

One difference between the two Smart Lock generations that might affect you is the allowed MTU size.
Smart Lock 1.0 is using a maximum MTU size of 23. Therefore any message longer than 20 bytes needs to be sent via a “Write Long” request instead of a regular “Write” request.
As your first message (shorter than 20 bytes) is correctly handled and the second one (longer than 20 bytes) fails, this might be the reason.

regards,
Marc

1 Like
#7

Hi Marc,

appreciate the feedback, gonna have a look on it !

#8

@marc
Ok after checking up the code again … the MTU was one issue!

I made sure I’m using write long to send chunked messages > 20 bytes … yet I’m still receiving the exact same error code "12 00 ff 00 00 b6 9e "

Extracted communication is down below :

  • ESP32 sends “01 00 03 00 27 a7”
  • ESP32 receives chunked indications ( 20 +16 = 36 bytes ) of “03 00 04 a1 03 c0 4b 26 01 1e 6a 43 9e 62 47 47 5e bd 46 1b” and "cf 3c 12 82 84 a2 4f c7 83 72 4b 26 9c 10 1c 6f " as the nuki’s public key .
  • ESP32 sends chuked messages (20 + 16 = 36 bytes ) of “03 00 8d a4 d1 dd f1 66 d8 64 c1 93 24 9f 55 c7 3a af f4 6e” and "5a ed 42 89 2f 2c cf ee bd 34 94 4b a3 05 e4 d1 " as the public key payload.
  • ESP32 receives indications of 7 bytes "12 00 ff 00 00 b6 9e " as an unkown error code.

Any idea where is the main issue, again knowing that it runs fine on Nuki 2.0.

#9

Please make also sure, that the ESP32 is also using the MTU size of 23.
Otherwise the ESP32 will still send one “Write Long” request containing the full payload instead of chunks of 20.

To test if the MTU size really is the problem, please try the Smart Lock beta 1.9.1 that has been released on Thursday.
This beta allows a bigger MTU size of 247 (same as Smart Lock 2.0).
If it still is not working with that beta, the reason must be something else.
Just send me your Smart Lock ID via DM and I’ll unlock the beta for it.

  • ESP32 sends chuked messages (20 + 16 = 36 bytes ) of “ 03 00 8d a4 d1 dd f1 66 d8 64 c1 93 24 9f 55 c7 3a af f4 6e ” and "5a ed 42 89 2f 2c cf ee bd 34 94 4b a3 05 e4 d1 " as the public key payload.

You’re not creating the chunks (splitting the outgoing message) yourself are you?

regards,
Marc

1 Like
#10

Just for reference, smart-lock right now is 1.8.1.

I made sure that on the client side the MTU is set to 23 as well but made no difference!

For the chunks or the splitting messages, im using those api functions from espressif that pass an additional term of offset ( with prepare_write( ) ) and execute_write( ) :
esp_ble_gattc_prepare_write(…)
esp_ble_gattc_execute_write(…)

waiting to try to beta version and confirm how did it go…

Thank you,
Omar

#11

I could confirm that the issue resolved with Firmware version 1.9.1 and everything is running smoothly as expected.

Thanks @marc for your support!

#12

Hi Omar,

Great to hear :+1:

So it is the smaller MTU size that is causing the issue.
If you want to support Smart Locks with older firmware versions as well you would need to find out how to handle that on the ESP32 correctly.
Do you have the possibility to dump the low level BLE communication of the ESP32?

regards,
Marc

1 Like
#13

Supporting old firmwares ( aka MTU of 23 ) is also on my plans but not at the moment honestly, i will come back to you with updates on the actual state once i work on it. it might be a bug in the esp32 framework as well.

Speaking of which … Do you have expected release date for firmware 1.9.1 ?

Best!