When you lock the Lock-Bolt, it will attempt to engage the bolt up to 3 times. If it fails for any reason (i.e. if it binds or jams), it will gently beep and flash the keypad red.
While in practice this seems appropriate, it is a “negative report,” meaning the user needs to wait for those three attempts to fail (several seconds) before they can know if the locking attempt was “not-unsuccessful.” This is not an efficient approach. Consider the normal user expectation and use-case: 1. Request lock by button or fingerprint, 2. Walk away.
With the current programming, the user is forced to inject a step between those two: 1a. Wait several seconds until the lock reports a failed locking attempt OR user decides they have waited long enough that they feel they probably should have heard the negative report by that time and tenuously walk away hoping they waited long enough.
WISHLIST SOLUTION: Immediately upon a successful lock request, report a LONG BEEP+WHITE KEYPAD FLASH to advise user lock was successful. Under normal conditions, this response would occur within about 1.5 seconds, as the user is turning to walk away. In the absence of that “positive report,” the user would be audibly and visually triggered to stop and wait for the negative-report, or eventual positive report.
BENEFIT: Less risk to the user walking away from an insecured lock, and later blaming Wyze for a bad UI being at fault for an avoidable break & enter finding Dirty Mike & The Boys making out on their living room couch. (-The Other Guys, 2010)
Thanks.