I’m experiencing some weird HomeKit behavior. While I thought it’s intended that tapping nuki within Home App opens the door this shows to be unwanted in scenes. When I trigger, say, a scene „guten Morgen“ which switches on the right lights and should unlock the door, this scene not only unlocks the door but also opens it.
Siri itself well understands the difference between „Haustür entsperren“ and „Haustür öffnen“!
HomeKit knows only two commands: “secure” and “unsecure” the door.
If you have a Smart Lock with knob on the outside we map the “unsecure” command to “open door” (= Tür öffnen), while it is “unlock” if you have a lever on the outside.
The scene you want to create “unlock my door every morning” is not possible with your setup without also pulling the latch. This is an Apple restriction and not something we have introduced. However, we’re in talks with them in order to find a solution for it.
EDIT: To Siri Shortcuts we expose all of this functions as separate triggers as this is independent of HomeKit. Using them allows you to trigger whatever action you want.
but wouldn’t it be possible to modify these mappings ‘on the fly’? In the app you configure your door as with a knob or with a handle. Isn’t it possible that once you configure it as a knob, then you map the command to unlock instead of open? I also was very surprised by this behaviour. I asked Siri to unlock the door and instead it opened the door. It isn’t mentioned anywhere that Nuki 2.0 behaves this way as far as I know.
Whatever intelligent mapping you put on it, most people would not understand. Many are very happy with the HomeKit solution because they never understood why there are 2 different unlock options at all …
However, we’re happy to listen to suggestions. If you have one for an “on the fly mapping”, let us know.
I understand, but when you have a front door with a knob, which is very common, then you wouldn’t expect it that the door opens when you give it the unlock command. If there’s a knob, then I think it should be configurable how you want homekit to operate when it receives an unlock command: open the door or unlock the door. Or perhaps create two buttons in homekit, one for the lock/unlock action and one for opening the door?
Also, the current implemetation is quite dangerous. When you accidentally tap on the Nuki button in the iOS Home app it immediately executes the operation. So if the door is locked it now opens the door immediately without asking for a confirmation.
I have configured my Nuki 2.0 to have a latch but in Homekit it only unlocks the door, not opens it.
Also in tie NUKI-App itself when i touch the door I only have the “Unlock”-Option. If I also want to use the “Open door” Option I have to assign the swipe left/right-Command in the app because I don’t see the option anywhere else.
I couldn’t agree more with your perspective - the current implementation is indeed dangerous!
From a UX perspective, I find the HomeKit UI for the lock to be very misleading - the “unlocked” icon does not correctly reflect an “unlocked” lock/door, but instead an “open” one - this is a big difference!
I have 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.
From my perspective, the current HomeKit implementation is completely unusable for safety reasons.
@Juergen: 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 included Lock’n’Go here). HomeKit’s “unsecured” reflects Nuki’s “Open Door”, rather than Nuki’s “Unlock”.
Until Apple decides to update their constants, would it be possible for Nuki to change the HomeKit/Nuki mapping? This could enable users 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 would also much rather only unlock my door, instead of opening it, thus preventing an unwanted open door.
The current way of utilizing the unlock method to open the door allows for remote opening via a HomeKit Hub. Changing the behavior prevents that function and forces users to buy a Nuki bridge. I was very happy to see that the current HomeKit way allowed me to ditch the bridge and still have the functionality. Unlocking the door remotely doesn’t make sense to me, but opening it does.
For example if I want to let someone enter the house while I’m at work, I can unlock in the home app or any other HomeKit app and let the person enter the house, but unlocking the lock would be absolutely useless.
I agree that apple should provide an improvement to locks for the European market and door latches, but removing the ability to open the door via HomeKit would make me sad since I would have to re-buy the bridge which I previously owned just for the now unnecessary homebridge plugin.
@baze I hear you as well, and have taken into account your requirements as well - enabling the user to select the preferred HomeKit/Nuki mapping would enable everyone to use both HomeKit, as well as the Nuki App, as preferred.
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”  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.  (only for SmartLock)
unlatchLock : If set to true, a second lock switch is exposed for unlatching the smart lock. (only for SmartLock)
 Also works with Siri, you can ask to unlock devices that are already unlocked.
 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 for the hint, @Locutus73!
The readme at github actually sounds very promising and could indeed help to deliver exactly the requested functionality.
@Juergen, could you please have a look into this to check if the Nuki team can implement this feature request accordingly? From an external perspective, I assume that the required effort should be rather small, especially given the information which @Locutus73 thankfully provided.
So far, unfortunately I still have to keep the HomeKit functionality for my Nuki Smart Lock 2.0 disabled, because the unintended opening (!) of the main door, which can be triggered unintentionally, poses a real security threat. As the HomeKit functionality was the main reason for us to upgrade to version 2.0, this is still a bummer.
Thank you in advance for looking into this topic again!
@thore@Locutus73 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.
Hi, I agree with the fact that the current implementation with Homekit opening the door instead of just unlocking the door is dangerous. I voted for the feature request by @thore and will have to deactivate Homekit until this is fixed. Please make this happen! Thank you!
I agree that the homebridge implementation would be awesome. Lock / Unlock would just behave as expected and if I really want to OPEN the door I would do unlock after unlock again.
Perfect solution would be if apple provided another button / state / action for locks… secure/unsecure state and forceOpen action or something like that that is represented as a button when the lock supports the function