Make HomeKit/Nuki mapping selectable to enable users to trigger the “Unlock” command to the Nuki Smart Lock 2.0 instead of triggering the “Open Door” command

Product name

Nuki Smart Lock 2.0


Following up on the discussion at HomeKit unlock command opens door

With Nuki’s current HomeKit implementation, using Apple’s Home app on both iOS and macOS, or alternative apps which make use of HomeKit (such as Eve System’s Eve app), switching the lock to “unlocked” immediately triggers the Nuki Smart Lock 2.0 to open (!) the door, instead of unlocking (!) it.
This current implementation is very misleading from a UI perspective, and potentially very dangerous for the user, as it can quickly lead to an unwanted open door. Especially when remotely triggered, the door can not be closed anymore, leaving it wide open for everybody!
Therefor, Nuki’s HomeKit implementation should be changed to be more secure for the user. The user should be able to select the preferred Nuki/HomeKit mapping in order to really just unlock the door, instead of opening it right away. This would much better mirror the current behavior of the Nuki App, which differentiates between locked, unlocked, opened (or even more).


First of all, it is obvious that Apple needs to update their currently available HomeKit Lock constants (for details please see “Reason” below) - until then, please make the preferred HomeKit/Nuki mapping user selectable within the Nuki iOS app settings.

As a user, using the HomeKit funtionality (for instance via Apple’s Home App on iOS or macOS), I want it to trigger the “Unlock” command to the Nuki Smart Lock 2.0, instead of triggering the “Open Door” command. As part of daily routines, I only want to unlock my door instead of opening it, thus preventing an unwanted open door.

The values which are currently possible to be used with HomeKit do not completely mirror the states which Nuki knows (Unlock, Lock, Open Door - I do not include Lock’n’Go here). HomeKit’s “unsecured” reflects Nuki’s “Open Door”, rather than Nuki’s “Unlock”!


The current HomeKit implementation is unusable for safety reasons, even worse, it is dangerous as it is likely to lead to an unintentionally opened door and therefor needs to be changed!

From a UX perspective, the HomeKit UI for the lock (showing a closed lock for “locked”, and an opened lock for “unlocked”) is very misleading for the user. The “unlocked” icon does not correctly reflect an “unlocked” lock/door, but instead an “open” one - for a home door, this can be huge difference!

HomeKit so far only knows certain few lock mechanism states (see for details), this is obviously a limitation which Apple needs to overcome. From my perspective, the currently possible values for the state of a lock mechanism are not enough and need to be updated with additional possible values. Please also do contact Apple to request additional lock mechanism states, in order to better cater for user requirements.

I have so far disabled the HomeKit functionality now as I do not want anyone (myself included) to unintentionally open the door lock operated by NUKI, and am very unhappy with that, as the HomeKit integration was the reason to spend the additional money and update to the Smart Lock 2.0.


I would like to use this feature as a setting in the Nuki App on iOS:
Settings / Administration / Activate HomeKit --> when this switch is enabled, I want to be able to specify whether I want to allow HomeKit to trigger the Nuki Smart Lock 2.0 to either:

  • unlock, but do not unlatch the lock, respectively the door (map Nuki’s Lock Action 0x01 unlock to Apple’s HomeKit Lock Mechanism State HMCharactericticValueLockMechanismStateSecured)
  • open and unlatch the lock, respectively the door (map Nuki’s Lock Action 0x03 unlatch to Apple’s HomeKit Lock Mechanism State HMCharactericticValueLockMechanismStateSecured)

This feature request is only relevant for doors with knob on the outside. For doors with a handle on the outside, HomeKit already only locks & unlocks the door and never pulls the latch.

Sorry for the double post (see HomeKit unlock command opens door), but yesterday I hadn’t enough rights to post here and I think this thread is more relevant, so…

I think an implementation just like the one in homebridge-nuki plugin would be perfect; see:

unlatchFromLockedToUnlocked : If set to true, the door is unlatched when you switch from “locked” to “unlocked” in the Home app. If set to false, the door is just unlocked when you switch from “locked” to “unlocked” in the Home app. (only for SmartLock)

unlatchFromUnlockedToUnlocked : If set to true, the door is unlatched when you switch from “unlocked” to “unlocked” [1] in the Home app (this move is valid and works in the Home app, just hold down the switch, swipe it to “locked” and then “unlocked” without releasing your finger - do not release the finger until you reached the “unlocked” position again). If set to false, nothing is done when you switch from “unlocked” to “unlocked” in the Home app. [2] (only for SmartLock)

unlatchLock : If set to true, a second lock switch is exposed for unlatching the smart lock. (only for SmartLock)

[1] Also works with Siri, you can ask to unlock devices that are already unlocked.

[2] If you use this mode of operation, the separate unlatchLock is not really necessary. Use unlatchFromLockedToUnlocked: true , unlatchFromUnlockedToUnlocked: true and unlatchLock: false to mimic the HomeKit behavior of the lock.

Thank you in advance.

This doesnt make sense either and is as insecure as the current solution as automations may trigger an unlock twice and so the door will be open, too. Only solution is the workaround both hombridge-nukio and homebridge-nuki use and expose a second lock for unlatching. Only this allows you to use the locks in automations and manual triggers securely.

Probably you didn’t read my post: I quoted and linked exactly homebridge-nuki wiki, with its implementation offering both the “double unlock to unlatch” and the separate “unlatch lock accessory”, with distinct options in order to let the user to choose whatever they want. Personally, I think the main offender here is the risk of accidentally clicking an item in the home app or in command center and the second lock exposes this risk as the main one… it’s matter or organizing stuff… I would use both the “double unlock” feature for the main lock exposed in control center, not using it in any opening automation, and a secondary “unlatch lock”, not in the home favorites, so difficult to reach, used in a single scene/automation, again not in home favorites, specific for opening the door.
Anyway with homebridge-nuki implementation you can enable and disable whatever you want.


1 Like

@Locutus73 I did read your post, but from user point of view a “double unlock to unlatch” is kind of weird. After all this discussion here and at homebridge-nuki I decided to add a feature to my plugin homebridge-nukiio and for me this is the most practical way of implementing it. Now, if you set usesDoorLatch=true in my plugin you will get two locks. One that locks and unlocks without pulling the latch and one that is always displayed as locked an will always pull the latch if unlocked. So far so good. Now I thought about this discussion and I didn’t want to add an option to prevent unlatch globally. Instead I decided to add a switch to the lock where you can dis-/allow unlatching. I think this is a pretty smart solution as you can now change the behavior based on scenes/automations. For example, you can disallow unlatching based on location or time. Most of the time, unlatching is only needed if you are in front of the door. But in some cases you still need to unlatch if you are not at home. Both is possible using this solution and maybe Nuki can implement some similar smart solution.

The switch for enabling/disabling unlatching is a good idea too… a sort of virtual door bolt.
Anyway IMHO the best solution (but I like fiddling and customizing stuff, other end users may want simpler solutions) would be one based on many enabling/disabling options, allowing all possible behaviours. So something like:
unlatchFromLockedToUnlocked enabling/disabling current standard behaviour
unlatchFromUnlockedToUnlocked enabling/disabling the double unlock to unlatch
unlatchLock (or usesDoorLatch with your naming) enabling/disabling the secondary unlatch lock
and why not
virtualBolt enabling/disabling an additional switch or lock for preventing unlatching at all

This way each user could deeply customize the behaviour at their will.
By the way, maybe it’s better having a lock and not a switch for the unlatch disabling function, since switches can be activated while the phone is locked.


Don’t forget that, whatever you propose, needs to be clear to the average Joe (and his wife and kids) and needs Apples approval.

1 Like

I think you can already do this using automations/scenes/shortcuts without adding the other two options. For the switch I decided not to use a lock since I think switching it is no security risk, other than actually executing a lock action that opens a door.

That is why Apple should implement something for latches. Then its deeply integrated. Until then I think making it possible to use any Nuki action with Shortcuts in iOS 13 will be the solution for now.

I agree: something that I really love of my (very short) experience with Nuki so far is that, just using few easy steps, it automagically configures itself for the average Joe, but it exposes all the options needed for a deep customization for any advanced user. The same should apply to these options if implemented: Nuki should autoconfigure itself in a reasonable configuration for HomeKit (probably just one simple lock like right now), letting advanced users to further customize the behaviour.

Thank you in advance.

I might be very wrong, but I think Nuki actions with Shortcuts would only make shortcuts activate Nuki native app actions… this isn’t a workaround for the HomeKit shortcomings, since it would require either being near the lock or using a Nuki Bridge.
I don’t want to use a Nuki Bridge, I want the remote control of my lock being handled only by Apple cloud/security, so I’d like to have one or more HomeKit lock exposing all the features and making difficult to accidentally unlatch the door.


Valid point to use homekit only. Thats why I still have Lock v1 and the bridge and of course my plugin. Now with shortcuts being able to use Homekit some complex shortcuts are possible, like „on shortcut unlock my door if it is locked otherwise unlatch it“ :wink:

Elaborating this point further… as stated before I’d like to have all options, but if you want to reduce them to the bare minimum for end user friendliness, I think we should have at least just one additional option: Enable unlatch lock default value false.
When false we get a single HomeKit lock behaving just like now.
When true the current lock would lock and unlock the door, without unlatching and we get the secondary unlatch lock that just unlatches (and says unlocked for the few seconds the door is actually unlatched).
We should also get a HomeKit contact sensor as described here: HomeKit Contact Sensor



Please implement that feature request! I also want that HomeKit only unlocks the door when I press unlock!! Currently it is opening, which is dangerous!!!

Just make 2 HomeKit behaviors between everyone can choose: Unlock and Open OR only Unlock. Why is this so hard? I thin John, his kids and even Apple will understand that!

How can one control nuki in iOS 13 shortcuts for now? I can not find the nuki app in the shortcuts app and when I do control the nuki lock by the Home app in the shortcuts app, then I also see only lock or unlock and no other options. So what do you mean?


Isn’t it easy to just expose 2 different locks to homekit? Instead of 1 button, you will have 2 buttons on the home app.
You can make it so they have different names and their behavior can be adjusted from the app.
You can also integrate the door sensor to this setup for getting better data from the door state.
The only issue is, you have to press two buttons on the homekit to fully open the door if it is in the locked state. (First Unlock then Open)
At least until Apple resolves this functionality on their end.
I was browsing the market for a homekit enabled smart lock. I was really envious of August Smart locks. Then I found Nuki. I was just about to buy 10+ units for my apartment and office and saw this thread. For now, I will just wait until this issue resolves.


It would be wonderful because if just pressing the button opens the door, it would be a double verification

I would really like to see this feature implemented.

Yes it would be even more elegant if Apple did the right thing (by distinguishing between locked and open) but HomeKit doesn’t get developed very fast.

Right now I keep the lock in HomeKit but worry about an accidental remote unlock, which would actually open the front door (since it’s a door knob setup).

As I stated in my comment here:

If noone is home, your home/apartment would just stay open until you would be able to get someone there to close the door for you, which could be a very long time!

I do think this is a very dangerous flaw in nuki’s homekit integration and can’t believe this wasn’t addressed in almost 3 years? Even the nuki app itself has an option to double-check whether you really want to open the door if you are not in the vicinity.

This renders the HomeKit integration on nuki completely useless in my opinion.


I’ve recently become a Nuki Smart Lock 3.0 Pro user and came across the very issue discussed here. From my perspective as a developer and a user who relies heavily on HomeKit for home automation, I find the current HomeKit implementation both misleading and potentially dangerous, especially for doors with outside knobs.

  • HomeKit’s “unsecured” should reflect Nuki’s “Unlock,” not “Open Door.” These are not the same, especially for doors with external knobs.

  • This potentially lowers the security level, as triggering an “Unlock” action could inadvertently open the door, leaving the home vulnerable.

HomeKit’s API terms and Nuki’s actions need to be in sync. An ‘unsecured’ state in HomeKit shouldn’t translate to a door literally being wide open. This is a flawed implementation that needs immediate attention.
Until Apple updates HomeKit constants, allowing users to define their preferred mapping between Nuki and HomeKit actions within the Nuki iOS app can be a good temporary fix.

The current situation has led me to reconsider the supposed ‘smartness’ of my smart lock, questioning whether it’s enhancing or diminishing my home’s security. I hope Nuki will promptly address these significant issues.

1 Like