Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeouts #6

Open
myself248 opened this issue Sep 4, 2016 · 3 comments
Open

Timeouts #6

myself248 opened this issue Sep 4, 2016 · 3 comments

Comments

@myself248
Copy link

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.)

@danawoodman
Copy link
Member

@myself248 we used a dogged door. How would it relock if dogged?

@madhephaestus
Copy link
Member

So i was thinking this and #5 should be a n "open profile" return packet for a device. The device should pass up its MAC and the card ID, and get back a behavior profile. We might want to start thinking about a data structure plan for the default data:
https://github.com/nation-of-makers/physicalaccess/blob/master/data/defaultdata.xml

I think thats how you define the data content. to be shoved into the databse.

@myself248
Copy link
Author

@danawoodman If it's an electronic door, then dogging can be a software function, simply activating the unlock mechanism continuously.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants