Space Entry Project

Current Implementation

A box (the Automatic Deadbolt Mechanism or “ADM”) is attached to the existing deadbolt; the ADM can lock or unlock the deadbolt.

Pressing a button on the ADM will lock the deadbolt after 5 seconds.

An opto-isolated input to the ADM will unlock the deadbolt. The input is a single bit; drive it high for 1 second to unlock the deadbolt. Driving it high for more than 1 second is not recommended (it will make the ADM unlock the deadbolt again and again).

Another opto-isolated one-bit input will lock the deadbolt immediately; drive it high for 1 second to lock the deadbolt.

The ADM supplies two opto-isolated output bits that report the position of the deadbolt, based on two limit switches (“locked” and “unlocked”). A high signal means the deadbolt is at a physical limit; a low signal means the deadbolt is not at a physical limit. The deadbolt might be between the two limits: both bits will be low. If both bits are high, something is broken, since the deadbolt cannot be at both the locked and unlocked positions at the same time.

A door switch supplies another output bit that tells whether the door is open or closed; a low signal means the door is closed.

There is an Access Control Computer (“ACC” – a BeagleBone Black) connected to the deadbolt control and status bits and the door switch bit. It is running Arch Linux ARM and communicates with the ADM via the /sys interface to the GPIO. A simple high-level interface is provided via doord.

BeagleBone Black Info

Only some of the GPIO on the BBB seem available to the Linux kernel. Through experimentation, the following seem usable:

  P8: 7-19,26
  P9: 11-16,21-24,26,27,30,41,42

The board documentation describes how the pins correspond to GPIO numbers.

UPS

A UPS powers the ADM, the ACC, a USB hub attached to the ACC, the DSL modem, and the router. The system can keep running if AC power has failed; it could send a message to notify us of a power failure.

A USB cable connects the UPS to the ACC so that the ACC knows if the power has failed.

Open Issues

(none)

Brainstorming

Feel free to brainstorm ideas here. Unless otherwise specified, lists here are meant to be exhaustive, and not necessarily design goals..!

Authentication Methods

  • RFID
    • Good for longer-term authorizations, e.g. members in good standing.
    • Unlike QR, no visibility of key required, just proximity.
  • QR Code Entry
    • Good for temporary authorizations.
    • Easy to cancel and regenerate in case of loss.
    • Less convenient since requires visibility.
    • Cheaper per key vs RFID.
    • Could be implemented with a Raspberry PI and a webcam example project
  • Facial recognition
  • Thumbprint
  • Electronic manual override
  • Physical manual override
  • Login and unlock via local WiFi
  • Knock code
    • e.g. have to tap a certain rhythm to unlock. Though any means of ‘tapping’ could be possible, e.g. flashing a light, making sounds, etc.
    • probably best for limited time or one-time authentications.
  • USB key entry
    • could be dual-use with dead-drop port
  • Bluetooth pairing

Authorization Types

  • Persistent authorization for e.g. members in good standing
  • One-day/one-time authorization for e.g. guests
  • Dependent on certain conditions, e.g.
    • only in given time frame
    • someone already in the space

Management

  • Authorize an authentication via multiple interfaces
    • IRC
    • Website
    • Kiosk in space

Monitoring

  • Announce entry/exit on IRC
  • Could run a user created script at door open, like on login

Possible data to store:

  • Code
  • Date/Time created, used, expires
  • Created by/for
  • Status (active, expired, revoked)

Relevant external projects