MQTT API Specification v1.3

Nuki APIs MQTT API
#1

We’re working on a new version of the API specification. It adds one quite cool feature, that has been requested often: a lockActionEvent topic

The Nuki device publishes to this topic a comma separated list whenever a lock action is about to be executed, consisting of:

  • LockAction
  • Trigger
  • Auth-ID
  • Code-ID (Keypad) or 0 (if unknown)
  • Auto-Unlock (0 or 1) or number of button presses (only button & fob actions) or keypad source (code, back key or fingerprint)

Only lock actions that are attempted to be executed are reported. E.g. unsuccessful keypad code entries or lock commands outside of a time window are not published.

Examples of what triggers that you can place on publishes from this topic:

  • React when a specific user did lock/unlock
  • React when a specific user comes home (i.e. auto-unlock was triggered)
  • React when the house is left (i.e. Lock’n’go with the button was executed)
  • Trigger something when the button on the Smart Lock was pressed (with or without lock action)
  • Trigger something when a fob was pressed twice (with or without lock action)
  • Trigger something when a specific keypad code was used

Here is the document as PDF:

20221027 MQTT API.pdf (102.7 KB)

Please have a look and let us know if you have any comments.

3 Likes
Who/What locked/unlocked the smart lock
#2

This would be truly awesome. The MQTT feature would both replace my Nuki Bridge and some Web API logic I now have in place to get the data above. Makes it really worth the upgrade to SL3 Pro.

1 Like
#3

No connection to the mqtt server. After a quick check, i realized the ip range in the documentation.

…resolve to a local IP or a local IP is given as hostname (10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255).

Are you really checking the local ip-ranges in the code? Would this be also in the final released version or?

#4

The initial posting has been updated with the final version 1.3 of the MQTT-API specification.

The full 1.3 scope including the new lockActionEvent is available with todays 3.5.2 beta.

1 Like
#5

Yes & Yes.

#6

This feature should not be just for Pro locks, it should be part of the bridge. I purchased the 3.0, not the 3.0 Pro, because I don’t want the Wi-Fi to be integrated. I believe it would deplete the battery at a faster rate due to the added processing overhead.
I like sustainability, but I’m not yet convinced to have rechargeable batteries for this kind of product.
Besides, the bridge is still required to connect to smart home systems.
The “non-Pro” products are not for free either, so they should also get these kinds of features.

#7

the bridge devices can use bridge api which is also local.

#8

With the Bridge API we cannot trigger something when a specific keypad code was used. We cannot know either if the back key on the keypad was pressed, for the example.

#9

Great addition to the product! Thank you!
Finally I can add automations to disable the alarm on successful keypad entry.

One question though: Is there any way to resolve the AuthID to keypad-users other than trial and error?

#10

Only trial and error for the time beeing.

#11

Hi,
in my opinion, it would be very useful to be able to decide to publish on Mqtt only the locking features and not the unlocking features, for obvious safety reasons.
What do you think?
Thanks