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.
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
No, you can’t. The app has a setting where it will ask to confirm whether you really want to open the door if you are far away. So the developers thought about this in the app itself, but dropped the ball in homekit. Why?
It makes perfect sense. Why it wouldn’t? It will cover both latch and non-latch users.
This is not a solution, I cannot turn of the latch setting in the app, since I have latch on the door. I want nuki to open the door for me, but not accidentally when accessing homekit remotely.
Now this is just coming up with ridiculous workaround for a feature that is missing. Again, why are you defending this, I don’t understand?
Because this feature request only exists because homekit lacks of a state to pull the latch. Thus the actual problem is homekit, not nuki.
From a developer point of view they would now need to make a workaround that also doesnt even handle all cases needed. Because of this, as a product developer, I would not implement it. As simple as that.
Now, since I am the developer of the first homebridge plugin homebridge-nukiio since the beginning of nuki I am quite aware of all the needs. But the lack in homekit is the main problem. In my plugin I therefore add two locks for a single Nuki, one for alway pulling the latch (can be disabled) and one for only unlocking the door.
Only this way you can currently match all needs. Thats why I not use Nuki Homekit Implementation but my plugin
So you just confirmed everything I said - current Homekit integration, as done by Nuki, is useless. And, even though there might be some limitations by homekit, Nuki devs could make it work - as you, said, they could expose two locks for single Nuki. Or have a setting in the Nuki app and control the action directly in the lock, as I suggested. They just decided not to do anything about it, and that is the fact.
That is such an odd argument to make - yes, and the same way what is not useless for someone is not automatically useful for somebody else. See? It goes both ways. It is not just me, it is all the users with a knob who want to use Nuki with HomeKit, they are all exposed to this critical bug.
This is just not true. There are ways how to work around this and they have been discussed already in multiple threads. You have full control what Nuki will do when it receives signal to “Open door” from HomeKit. The lock itself could have a setting in the Nuki app that defines what to do when lock is triggered from HomeKit - open door or just unlock. As simple as that. There are other ways also, but this one seems like a no brainier.
Echo what was said. Its definitely an important feature missing on HomeKit side, but the fact that Nuki for years doesn’t do anything about it does not make Nuki look great in users side.
For those with latch in the door its really a miss.
In HomeKit it’s extremely easy to accidentally press unlock button and have your house left open. major security risk, as there is no confirmation that user is really intending to open the door.
Use-cases for separate unlock and open are totally valid. When I come home from outside, I want it to open, not just unlock. And I will usually enter immediately. So I make all automations around “open” function.
However when I am inside home I don’t need “open”, I need just “unlock”. Because there is a door handle on the inside of the door that I can easily pull to open the door. But there is no such door handle on the outside.
Hence the difference. So when I am inside all my automations, be it unlock the door in the morning, or unlock the door when I switch on lobby lights, all around “unlock” and not around “open”. In this case “unlock” is much better because when I am inside the house I may not need to go out immediately, and don’t want my door open wide open, just be ready for me to pull the door handle and go out.
If HomeKit is not supporting this, Nuki could easily go around it until HomeKit changes its spec. I like the proposal in the Homebridge plugin of temporarily showing two Nuki locks for those users with latch where using one will do lock/unlock and using the other will do lock/open on the same doorlock. This can then enable all needed automations for both very valid “unlock” and “open” needs.
I really hope Nuki will finally listen to its users and not just bounce us off to Apple. Be better than Apple.
It has been mentioned several times in this thread:
Apple has strict certification guidelines for locks. Nuki has to adhere to this guidelines and therefore it is not possible to apply the same “tricks” the homebridge plugins apply in order to overcome the bad UI and lack of functionality of HomeKit for European locks.
This has nothing to do with not listening or caring about users. We do care and we do talk to Apple about this and it is not Nuki that does not care about Europe …
I read through the article and I was wondering whether the following might be acceptable under the HomeKit integration guidelines:
Assuming: Unlock and unlatch actions are tracked by the Nuki lock. The last state is always known by the lock.
first HomeKit unlock command only unlocks the lock (unless current state unlocked, see below)
a second unlock command through HomeKit (with optional adjustable delay, tracked by Nuki or the lock) unlatches the door
locking with HomeKit always locks the door
This could ideally be a setting in the Nuki app to chose the behavior: HomeKit settings: „require additional unlock to unlatch“.
From an apple HomeKit point of view the smart lock locks and unlocks the door - no difference to the current lock and command behavior. Since automatic locking is an option from the Nuki side already.
If this would solve the issue many of your customers (me included) would be very happy.
If this doesn’t work or I missed a section regarding this, please apologize.
I just testet it with apple HomeKit.
HomeKit doesn’t care what the previous state was or is, you can easily send another unlock command even if the current state is unlocked.
I am sure same goes for the lock command.
If you want to test it, you have to activate it with voice prompts rather than the slider. So at least with Siri the option in the app would solve it.
I don’t know whether anyone uses the home slider anyway.
Maybe this helps to enable the option.
I’d like to disagree! The use case of opening the door (as in “unlatch”) is already covered by the Nuki app, including all auto-unlock features and I’m sure that most people are happy to do things that way. However, Apple Home is much more suited for the OPPOSITE use case of automatically LOCKING the door (i.e. when the last person left the home). As many people already pointed out, having the Nuki Device as-is in Apple Home introduces a severe security risk that outweighs the benefits of having an auto-lock feature.
This whole issue is now almost 5 years old and the explanations I heard from Nuki come mostly down to underestimating the intelligence of their user base than making an actual argument.