It turns out that Nuki Smart Lock 3.0 does NOT support locks with Priority function like the one I have: Keso 81.K16
Many websites testing SmartLocks only state that Priority function is required, ie the latest tests from Stiftung Warentest.
Problem is that Nuki app only supports locks where keys would turn exactly the same on both sides. In my case they do not turn the same way but I can still use key on the both sides at the same time. When using installation check on Nuki website, it states that my lock is fully compatible as question asked is “Can you unlock the door from the outside when a key is inserted on the inside?” and my lock can do that.
A very simple solution would be to allow user to override state and allow unlocking even when the “smart lock” is in the locked state (which will happen if I used the key on the outside).
Is this something your developers would consider and implement or should I look at the options to return my lock?
Unfortunately there is no simple solution to this, because the Smart Lock can not unlock, when it thinks it is already unlocked. But it can (and will) unlatch (“Tür öffnen”) because this turns the motor until the key is at the maximum position in unlock direction. Still this might not fix the problem that the Smart Locks position sensing is out of sync and a recalibration or position run (done after power off-on) is needed.
If you search the problem for “panic door” you might find some similar posts or feature requests you can vote on, because panic doors have a similar problem.
Thank you very much for the reference. The solution for this could be very simple. You could add a setting where user would indicate that their lock has the “panic/priority” function. In that case if user selects unlock, the Nuki will initiate unlock function even if the lock is in the “unlocked” state. I am a programmer and know that such a feature would not take long to develop.
Such a simple solution would work for all of the users since it would be “opt-in”. Alternatively, you should probably add this information to the “installation check” otherwise more people will be left disappointed when they realise they can’t use the Smart Lock.
There is a hidden feature in the latest Smart Lock 3.0 (Pro) firmware, which you might give a try:
If the Smart Lock 3.0 (Pro) runs a firmware >3.6.9 and debug mode of the Smart Lock is active and a door sensor is paired the Smart Lock goes in state “Undefined” when the door is opened while the Smart Lock thinks it is locked (i.e. the door was opened through a panic function or with a key when a cylinder with priority function is used, where the inner and outer keys are not rotating together).
In state “Undefined” it is still possible to lock / unlock / unlatch the door. Performing a lock command will drive the lock to full locked position in order to recalibrate the internal position sensing of the Smart Lock. In case of an unlatch command, the Smart Lock immediately unlatches the door and repositions itself based on the unlatched position. Unlock commands via BLE and remote unlock commands sent through the specific error dialogue that appears in “Undefined state” within the Nuki App, trigger an unlatch door command. All other unlock commands are denied.
After any of the above lock commands is finished the Smart Lock exits the “Undefined” state and displays the correct state again.
Is this still working? I tried to enable debug mode and the app said “Debug mode enabled”, but I didn’t experience any change. When opening it with the key, I have to re-calibrate. I have a Nuki 4.0 lock.
Actually the Danalock which I also own has this function, called “end-to-end opertation”. If activated, it always assumes the users to be right about their request and uses the torque-sensor to know when it is done.
As the Danalock does not have the luxury of a door-sensor this is all it can do. But a Nuki with a door sensor could try to determine when the door was manually opened by sensor state and “taint” the locking state by itself.
Although, as a hardware programmer myself, I would recommend to add an opt-in to make it behave like the Danalock in case the door sensor turns out to be unreliable. And also to revert to this behavior if an explicit lock or unlock command is issued again when the state is already assumed by the lock. Sometimes you want to make totally sure in what state your doors are.