Keycode Access

From Noisebridge
(Difference between revisions)
Jump to: navigation, search
(do-ocratically implemented a possible solution)
Line 19: Line 19:
On Minotaur:
On Minotaur:
/usr/local/share/noisebridge-baron/ - baron script
/usr/local/share/noisebridge-baron/ - baron script, takes arguments --port=/dev/whatever and --codefile=/var/blablabla/codes
/etc/init/baron.conf - jesse's init script
/etc/init/baron.conf - jesse's init script

Revision as of 01:13, 18 February 2012


Contact & Info

Feel free to add yourself here if you plan to work on the project. There will be some email-based discussion and record keeping for this project, and that info will be added here if you just want to lurk and complain.


Current Implementation

Keypad hardware hooked up to Minotaur at /dev/ttyS3 - The fucking doorkeypad is finished

Backend software (

On Minotaur:

/usr/local/share/noisebridge-baron/ - baron script, takes arguments --port=/dev/whatever and --codefile=/var/blablabla/codes

/etc/init/baron.conf - jesse's init script

/usr/local/share/noisebridge-baron/codes.txt - codes file, any line starting with a 4-7 digit number (ignoring whitespace) is interpreted as a valid code, # is used for comments


  • Add an access log of some sort, and switch out stdout debug/error messages for something more useful
  • Add a way to add/remove codes (from Pony?), somehow syncing the file to Minotaur.
  • If you change the way codes are loaded, please ensure it's done in a way that won't interrupt a user in the middle of using the keypad. (So, don't just restart the process.) Currently, it tries to refresh the codes list in a background thread every 30 seconds — if the file is corrupted or missing, it continues with the last good list.
  • Add a "bad" codes list, to block codes from being reused.
  • Add the ability to expire codes - maybe a comment in the codes.txt file?

Keycode System Features

  • Numberpad on front door
  • Database of codes... on pony? With notes? Probably we need a basic schema for what info we do and don't want to log.
    • Tom wants it to be a text file with a pin or rfid code per line and comments delimited by hash marks
  • Logging keycodes (necessary to be able to shut off problem codes)
    • keycodes not formally associated with individuals
    • member keycodes differentiable in some way
    • keep logs for 7 days
    • require 2 users to access logs (cryptographically)
  • Keycode Generation
  • Distribution
    • how to distribute without leaving electronic records associating code with individual?
    • the most paranoid users will not trust the system anyway
  • Disabling keycodes
    • presumably not a feature needed immediately.


There are 3 components to a doorlock system:

  1. A code entry box (physical hardware)
  2. Security controller (computer) (we already have minotaur which controls the doorlatch)
  3. Electronic doorlatch (i.e. buzzer [may be silent])

Commercial door control systems usually have a central controller which is physically located inside the building and cannot be accessed from the entry box. The code entry box is connected to the controller via hard wires (usually serial). The controller can activate the doorlatch via the existing Noisegate relay.

Potential Products

  • Talked to Terry tonight who says he has a friend who has a bunch of access system gear that we could get donated. linuxman2001@gmail -- User:Hurtstotouchfire

Implementation Considerations

  • Should we buy or build the controller?
  • Shannon wants to replace the current keypad system with something fancy
  • Jake thinks we should just add the keypad onto the gate with U-bolts
    • we would need to talk to the landlord to do this (unless we can do it without drilling?)
    • at present, we plan to just add an additional keypad and only replace the button system if the keypad is successful
Personal tools