Product name
NUKI Smart Lock 2.0
Summary
Allowing the auto-lock feature of th enight mode being manually timed
Features
The idea is to add atime option which gets available if auto-lock is enabled in night mode. This option allows to specify a time after which the door is automatically locked again, if night mode still active at that time.
As a minimum the control should allow entry of a time frame of 1 to 60 minutes ion 5 minute steps. Better would of course be to have a large range to cover all users needs. At best a free time entry just like th enight-mode itself should be granted.
An additional option (checkbox) should also be granted, which if checked resets the auto-lock delay timer each time the door is opened (if equipped with a sensor).
Development note:
If current time of the unlocking plus the auto-lock time will be later then current night mode end no auto-lock will be scheduled. If free time entry up to 24hours are allowed,iot may happen that the computed auto-lock time will fal into the next day night mode time window. This must of course be handled and no auto-lock scheduled. Note that the same could happen with smaller time ranges allowed for th eauto-lock feature, if the user uses night mode for special purpose for most of the day since start and end times can be freely selected.
The default time frame should be the same used in the current firmeware so there will be no change for existing users.
Reason
When opening the door during night mode there is a reason to do so. If it is only for letting somebody in or out quick auto-lock may be appropriate, but there are other uses which require the auto-lcok to be delayed. In case of a door with an opening handle this might be vital to come back into the house or appartment. But this feature is also usefull with othjer doors for example to void unecessary lock/unlock cycles and their associated battery uage and noise (remember this is called night mode )
Examples
It is impossible to name all use cases as there are so many (partly nemed in the “Reason” section) . In the specific use-case which lead me to sumbit this request it is related to an appartment where the user sometime needs to get out of th eappartment during night-mode for going to the laundry. The door being not far from tthe bedrooms ever unlock/lock cycle is annoying but the user wants to use auto-lcok to be sure not to forget, but would have to delay it for about 15-20 minutes to be sure to be in the appartment again before the auto-lock happens.
The sensor option will prevent that the door closes inadvertently if the user would go out (to the laundry in my example) while the door was not yedt auto-lcoked again
Detailed laundry example:
Night mode: 22:00 - 04:00
Auto-lock delay: 20 minutes
- User goes to laundry at about 03:30 unlocking the door
- Auto-lock is scheduled for 03:50
- User comes back at 03:35
If for example washing machine did not finish yet user may go down again at 03:48.
Without sensor timer reet the door will now lock at 03:50 probably before the user is back. With sensor timer reset the timer would be reset when th edoor is opened at 03:48 and auto-lock would happen at 04:08. This being outside of the current night mode window the lock will simply no tbe scheduled. If end of night mode would be 05:00 instead, auto-lock would of course be scheduled for 04:08 and later probably rescheduled again when th euser comes back to the appartment from th elaundry.
I was initially thinking about counting only every second door opening to reschedule only when “leaving”. But we cannot now if user came or went out, or if somebody actually did go through the door at all (for example user forgot something, clöoses door, and then again to actually leave). So we have to reschedule at each and every door movement.
Other use cases with users possibly being called-out may want to have longer delay time requirements.