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.
As HomeKit so far only knows certain few lock mechanism states (see https://developer.apple.com/documentation/homekit/hmcharacteristicvaluelockmechanismstate
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.
@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.
Yes, that would be possible and might make it into a future FW update. If you want to push it you could open a feature request https://developer.nuki.io/c/feature-requests and start collection votes for it.
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” [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 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
The HomeKit Standard did not change and still offers only “unlocked” and “locked” states and “unlock” and “lock” actions.
Therefore also the “mapping” that Nuki does, did not change.
A manual override of the mapped function is still not possible within the Nuki settings.
The Homebridge plugins offer custom functionality (i.e. expose a second lock for the latch) and thus more flexibility which Nuki itself can not provide due to Apples strict certification guidelines.
Why is nuki then not mapped to the “unlock” action? On doors with latch, that means exactly that - unlock command, not open door command. Doors with latch have different commands for lock, unlock and open door, as confirmed by Stephan above. If what you are saying is that nuki is mapped to “open door” on “unlock” action, why is the mapping not “unlock” to “unlock”?
To me, this sounds like a bug on Nuki side and I can’t believe this is still an issue 3 years later? It’s exposing the lock in an unpredictable way and is, as multiple people stated, dangerous. When using HomeKit remotely, one could open their home door while on vacation overseas by simply tapping on the nuki icon by mistake.
This is simply not true. Apple provides only two states, yes, but you introduced the mapping, which is what is causing issues, not HomeKit.
Because people with a latch would not be able to enter the building anymore, which is the primary use case of mounting a Smart Lock at all.
If you don‘t need the unlatch function you can simply change the door configuration in the Smart Lock administration which will also change the HomeKit mapping.
It is an restriction by apple. Apple only has „unlock“ which in Apple/USA terms is to have your home unsafe as usually you can open the door from outside if not locked. Same is now for nuki when using a latch
That’s my whole point - it should be configurable. As a user, I should be able to specify if pressing the button in homekit opens the door or just unlocks it. Problem solved, will work for any combination of latch/handle.
There is no restriction. Apple exposes two states, locked and unlocked. You are misinterpreting the second state. In other words, it could also be on and off. As a user, I want to be able to specify what ON and OFF does, when I press that button in homekit. And to me unlock != open the door.
Again, allowing homekit to open the door wide open remotely, without any check and confirmation is A HUGE SECURITY ISSUE. You can accidentally tap on the button in homekit and it will open the door to your house, no questions asked, even if you are 1000 kilometers away. Are you really defending this functionality as correct?
Yes. Its with any App that can open the door. You can even accedently hit unlatch in the nuki app.
As @Juergen said, just configure the door to not use unlatch and you cannot unlatch it accedently in homekit or nuki app. It makes no sense to me to have a different setting between nuki app and homekit.
You could move the lock tile is in an extra room in homekit to avoid your issue.
I signed up just to voice the need to be able to configure what the HomeKit action does.
It is extremely easy to hit the HomeKit button once to open the door from 1000 km away with no way of closing it again. If you’re in the Nuki app, you have to do this with intention. It is at least significantly less likely you do this accidentally. It’s a valid point, but not good enough.
I would like to be able to unlock and lock the door remotely, at least having the choice for which one is used means everyone is happy
