Simple lockaction implementation

So I started to integrate the new simple lock action (0x100) command in my code instead of the lock action (0x000D) which is already running fine for me…

I followed the following scenario which is pretty similar to the lock action command usage described at the end of the API document, just adjusting the command payload structure to the one described in API V.2.1.0.

->Example: Performing unlock with simple lock action

Shared key:
2 (4 Bytes)

1. CL writes Request Data command with Challenge command identifier to USDIO
    a. Unencrypted: 02000000 0100 0400 E804
    b. Encrypted:
    c. CL sends encrypted message
2. SL sends Challenge command via multiple indications on USDIO
     a. CL receives 99C8613A9F6AB6D3FB0399D37AD38C5C003AC139
     b. CL receives B1567BC102000000380028CDCbackground-lightgreen8C08DA47BF32
     c. CL receives 3BF9371EBF068F6D480438563660780A4234D9A2
     d. CL receives 3794E305EE37878874EDE106A0BBFCF5B60E0C2E
     e. CL receives 2BA17248A02B
     f. Decrypted:
3. CL writes Simple Lock Action command with action 0x01 to USDIO
     a. Unencrypted:
        02000000 0100 01 57D95521BEA186B5A9244F025737924C5B7E33592D0614D5F
        6EF2E2F142C6D4B CACF
     b. Encrypted:
c. CL sends encrypted message

4. SL doesn't perform the unlocking logic

Not entirely sure if my payload size at (3.) was correct, so a feedback on it will be very helpful!

To confirm, the unencrypted payload consists of the following …
| 7 bytes | 32 bytes | 2 bytes | = 41 bytes
| Authorization ID + simple lock action command + action | Challenge | CRC16 |

Nuki Firmware version:

Appreciate the help!

Hi Omar,

What’s confusing me is your Auth-ID of 2, which is kind of unlikely for a Smart Lock 2.0, but it seems to work with the “Request Challenge” command.

But you’re sending the Command-ID of the “Simple Lock Action” command in wrong byte order.
0x0100 in little endian would be 0001, so your message (3a) should have been:

02000000 0001 01 57D95521BEA186B5A9244F025737924C5B7E33592D0614D5F

Of course the CRC16 needs to be updated accordingly.


1 Like

Hey Marc,

Just figured out the issue, The challenge was just filled at the payload at a wrong offset (which is different offset than a normal lock action because its a shorter payload).

Side note, the example usage was just filled from the API so yeah possibly it was referenced from Nuki 1.0 but my values are quite different :slight_smile:

Thanks again!