Product name
Nuki Opener
Summary
Nuki Opener must change the order in which it executes actions to improve user experience.
Features
The order of execution when detecting someone ringing the bell must be:
- Start timer for “delay”
- Send notification/callback
- Make sound on Nuki Opener
- If timer for delay has passed, open the door
Currently, it’s like this:
- Start timer for “delay”
- If timer for delay has passed, open the door
- Make sound on Nuki Opener
- Send notification/callback
Reason
- Currently, all actions (Ring, Open, Notify, Callbacks…) are waiting for A) the configured delay to pass and B) the door open command to end. There is no reasonable justification for Sound, Notification and Callback to have to wait until the delay and the door open tasks are completed. This results in enormous delays when RTO is used in connection with a longer delay and a long opening duration. I would classify this as a bug because there’s no justification for it. These tasks are constant length and should happen before opening the door.
- Ideally, Nuki Opener should be able to fire Open, Sound, Notification and Callbacks simultaneously and instantaneously. I understand it is probably not possible due to the hardware and the actions happen sequentially. Therefore a lot of thought and consideration must be given to which action is fired first. I’m not sure that Nuki has got this right. Changing the order to what I suggested above ensures that users are immediately notified when the bell rings (before the door opens, this is a security and convenience aspect), then Notifications should fire because they take longest to deliver. Only then should the opener open the door if the delay has passed. If you use a loop to check if the delay has elapsed, then record the ring timestamp as first action and then move immediately to the other tasks and only when done, or if there’s a timeout, check the timestamp/timer and open the door.
Examples
- I have to set the opening duration to 10 seconds because I have two doors controlled by the same intercom that need to be crossed. Additionally I need a delay of 5 seconds because the first door is a bit further from the ringer. Changing the order allows me to hear early when guests arrive even if RTO is active. Currently, if they are fast, they might be waiting in front of the apartment before the Opener even sounded the bell. And it takes even longer for Callback or Notifications to arrive.
- I use HomeKit Bell Notifications to hear in the whole flat whether someone was ringing. Because Notifications are delayed at least 15 seconds in my setup above, and then on average again for about 8-10 seconds in 1.6.0, it takes about 30 seconds until I hear the door when in the living room. That’s enough to miss some of the less patient delivery guys.
- The case for accessibility: Some users I know use Nuki and have hearing impairments. Being able to set a scene in Homekit that is visual to replace the bell is a big selling point for Nuki. Notifications on iOS also help a lot. The delays completely break the accessibility benefit for Nuki. What good is a doorbell if it only alerts you when the person ringing has already left.
While I didn’t find any specific feature request for this here, I’ve asked around and the sluggishness of notifications is one of the main criticisms of Nuki Opener I hear from colleagues and friends. This is basically fixing 80% of the issue simply by changing the order in which Opener does things. Not reinventing the wheel, just changing the procedural order and cutting off immeasurable amounts of aggravating delay.