You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue contains a list of timeout concepts that various nodes may need.
Door node:
Unlock-time: Once the user authenticates to the reader, the door unlocks and this timer starts. If the door has not been opened when the timer expires, it locks again. Typically (5-10 seconds.)
Held-open-alarm-time: Once the door is opened, this timer starts. If the timer expires and the door hasn't been closed yet, an error is logged and optionally something obnoxious starts happening to remind someone to close the door. Perhaps multiple levels, a warning time and an alarm time? (Typically 30-60 seconds.) Perhaps different depending on whether the door was initially opened from the inside (crashbar) or outside (reader)?
Dog-time: Commercial door mechanisms can be "dogged", which is, put into a permanently-unlocked state, typically by using a special key. (Some sites use this for business-hours or open-house or whatever.) But if the dogging key holder leaves and forgets to un-dog the door, it's a problem. So an electronic door should re-lock itself some time (typically 8-12 hours) after a user with dogging permission dogs the door. It may also be helpful to define hours during which the dogging feature cannot be used at all, or hours during which the door unlocks itself without user interaction.
Pinless-time: At sites which have card-and-PIN authentication, the PIN (second factor) is typically used to prevent reuse of stolen/found cards. But it's a hassle. So a tradeoff may be sought, where a user is only required to enter their PIN every so often, and if they enter again during the pinless interval, the door opens from a simple card swipe. (Typically 6-12 hours.)
Tool node:
Not-active-yet timeout: When a user first auths to the node but hasn't activated the tool yet, how long we wait for before logging them out. Set 0 to remain logged in forever until explicit redbutton out.
Has-been-active timeout: When a user has been using the tool but stops, how long we wait before logging them out. Set to 0 to disable timeout, as above.
Pre-timeout warning: If this much time is left before timeout, chirp or blink. Set to 0 to disable.
Extend how many times: To ward off the timeout without having to restart the tool, hit the green pushbutton, up to this many times. (Note: Sense transitions, not state, to avoid wedged-button defeat.)
The text was updated successfully, but these errors were encountered:
This issue contains a list of timeout concepts that various nodes may need.
Door node:
Unlock-time: Once the user authenticates to the reader, the door unlocks and this timer starts. If the door has not been opened when the timer expires, it locks again. Typically (5-10 seconds.)
Held-open-alarm-time: Once the door is opened, this timer starts. If the timer expires and the door hasn't been closed yet, an error is logged and optionally something obnoxious starts happening to remind someone to close the door. Perhaps multiple levels, a warning time and an alarm time? (Typically 30-60 seconds.) Perhaps different depending on whether the door was initially opened from the inside (crashbar) or outside (reader)?
Dog-time: Commercial door mechanisms can be "dogged", which is, put into a permanently-unlocked state, typically by using a special key. (Some sites use this for business-hours or open-house or whatever.) But if the dogging key holder leaves and forgets to un-dog the door, it's a problem. So an electronic door should re-lock itself some time (typically 8-12 hours) after a user with dogging permission dogs the door. It may also be helpful to define hours during which the dogging feature cannot be used at all, or hours during which the door unlocks itself without user interaction.
Pinless-time: At sites which have card-and-PIN authentication, the PIN (second factor) is typically used to prevent reuse of stolen/found cards. But it's a hassle. So a tradeoff may be sought, where a user is only required to enter their PIN every so often, and if they enter again during the pinless interval, the door opens from a simple card swipe. (Typically 6-12 hours.)
Tool node:
Not-active-yet timeout: When a user first auths to the node but hasn't activated the tool yet, how long we wait for before logging them out. Set 0 to remain logged in forever until explicit redbutton out.
Has-been-active timeout: When a user has been using the tool but stops, how long we wait before logging them out. Set to 0 to disable timeout, as above.
Pre-timeout warning: If this much time is left before timeout, chirp or blink. Set to 0 to disable.
Extend how many times: To ward off the timeout without having to restart the tool, hit the green pushbutton, up to this many times. (Note: Sense transitions, not state, to avoid wedged-button defeat.)
The text was updated successfully, but these errors were encountered: