Olympus: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
No edit summary
Line 2: Line 2:


[[SHED]] grants access to the space when locked, entry for members when opening the space at the start of the day, or late at night.
[[SHED]] grants access to the space when locked, entry for members when opening the space at the start of the day, or late at night.
==How it works==
===Opening the door:===
Tap your authenticated card onto the blue PCB.
===Adding 30 day access:===
An authenticated big M user will first flip the safety toggle switch to the on position. The OLED screen will display "SUDO mode engaged". The new card being given 30 day access must then be held against the RFID scanner. The screen will confirm that access has been given and a QR code to a Google form will be presented. The new user must scan the QR code and enter their name / handle.
===Adding big M member access:===
Adding big M access is the same as 30 day access, however the red push button must be held down during the process. 


==Status==
==Status==
Line 13: Line 23:


===Next steps===
===Next steps===
* people given 30-day access aren't able to change access
* people given 30-day access aren't able to change access ;(


==Intro to development==
==Intro to development==

Revision as of 19:16, 9 November 2023


SHED grants access to the space when locked, entry for members when opening the space at the start of the day, or late at night.

How it works

Opening the door:

Tap your authenticated card onto the blue PCB.

Adding 30 day access:

An authenticated big M user will first flip the safety toggle switch to the on position. The OLED screen will display "SUDO mode engaged". The new card being given 30 day access must then be held against the RFID scanner. The screen will confirm that access has been given and a QR code to a Google form will be presented. The new user must scan the QR code and enter their name / handle.

Adding big M member access:

Adding big M access is the same as 30 day access, however the red push button must be held down during the process.

Status

Done

  • Prototype that scans rfid cards, stores in database, unlocks door.
    • Allows adding new keycards
  • Finish splitting the hardware into "brains" section--secured--and sensors section, lives outside--insecure.
    • Installed.
  • Find way to deliver enough voltage and current to switch solenoid. Tried, not worked: voltage divider (high-resistance) and boost converter and signal-level converter (3.3V - 5V). More in #Rough Notes
    • Fixed by using a TIP120 mosfet, the threshold voltage for switching on the solenoid circuit was lower with this component

Next steps

  • people given 30-day access aren't able to change access ;(

Intro to development

Keeping in mind User:Mcint/Project Derisking:

  • Problem: Needs to fulfill a few purposes. First in the order people might think about them, or naturally state them, before we decompose them into functional requirements, or simple solutions that aim to satisfy multiple naive user specifications (in a creative and minimal way if possible, instead of via extensive requirments).
    • Grant entry to members. When a valid key is presented, only when a valid key is presented, unlock. Grant entry to some users only during open hours.
    • Make addition of new temporary members easy. Make auditing list of people (/keys) with access possible. Make revocation possible.
    • (Possibly report (live)/record (for later review) entry attempts, failed (or also successful).)
    • (no others named, challenge)
  • Solution:
    • Outside
      • RFID Scanner: RFID-RC522. Vsrc, Gnd, 5 pins in use. (1 ethernet cable. 7/8 wires.)
      • Screen. Vsrc, Gnd, +~2 pins in use.
      • Switches, 2. 2 pins indicator, share Vsrc, Gnd. Switch "add user" mode, push-button "member" modifier.
    • Inside
      • RPi. 40 pin. https://pinout.xyz/
      • Secured: in wall-mounted box, or in lockable mailbox "suite 1", or not locked, "suite 2".
    • Connection: 2 ethernet cables.
      • Serve power/ground over both (to support smaller standalone components for testing & debugging).

Software

Rough Notes

Service Commands

# denotes root, so either prefix each command with $ sudo ..., or enter a rooted interactive shell with $ sudo -i before running the rest of the commands.

  • # systemctl status olympus[.service] - shows current status, and the last few lines of logs.
  • # systemctl [start|stop] olympus[.service]
  • # journalctl -eu olympus[.service] - looking at [e]nd of logs, freshest lines, show logs for [u]nit, immediately next argument must be unit name(s).

Switching power / 2023-09-11+

sampling of amazon door lock solenoids reqts
https://www.amazon.com/UHPPOTE-Standard-Electric-Strike-Control/dp/B00V49S418?th=1 Working Voltage: DC12V / Current: 320mA
https://www.amazon.com/Seco-Larm-SD-995C-D3Q/dp/B07G58CS9F Current Draw: 300mA@12VDC, 150nA@24VDC
https://www.amazon.com/UHPPOTE-Standard-Fail-Secure-Fail-Safe-Adjustable/dp/B00V49S2NI Input Voltage: 12VDC; Current: 220mA
  • falstad simulation, with beta from above
    • oh, so 67mA is too low a current to switch it, by factor of 5
    • the gate voltage ~3.8V to trigger, matches
    • err, sorry, too few mA, 12V, about half. it's a plausible range for some solenoid, idk which we have
    • it turns out more drain voltage has no effect on drain-source current, only gate voltage affects drain-source current --- as ..expected / desired
    • I calculated beta of 3 from the data sheet -- i think -- https://datasheetspdf.com/pdf-file/283681/FairchildSemiconductor/IRF520/1
    • it shows over an amp at 3.3v -- we're clearly in the right range
    • maybe the buckboost* converter is current limited, from rpi 500mA limit
      • but the boost converter halves current in exchange for doubling the voltage


Data Model

Users

{
  "0x8800112233": {
    "clearance": "Guests",
    "expire_date": 1697010653135.815,
    "issue_date": 1694418653135.815,
    "exp": "2023-10-11 00:50:53.135815",
    "iss": "2023-09-11 00:50:53.135815",
    "uid": "0x8800112233",
    "user_handle": "j p hacker",
    "mentor": "0x8800112211"
  }
}

Design Requirements

As initially conceived, and in further requests from the space.

  • Members
    • 24 hour access
    • Can add guest users.
  • Associate members (not implemented just yet, Wyatt has an open PR for it)
  • Guests
    • 30 day access, business hours.


We are using RFID to allow access. We would like to associate names with that, eventually excluding users without an associated name.

We plan to report user additions to a public channel, and accesses to the space.

I would like to blind the data file by HMAC'ing the IDs with a private key.

Using

Instructions appear on the screen within 1-5 seconds, explains itself, mostly.

  • Scan RFID, access granted (/denied), door unlocks.
  • Add user: admin user enables "new user" switch, scans admin RFID, scans new user id (with or without "member" intensifier). Added users have immediate access.
    • New members must scan QR code, add name/contact info to google form, and submit for approval.

Managing

  • Firebase database manages the UID, raw from RFID.
  • New users via google form. QR code link, with RFID UID, shown on screen for enrollment.

Wants & Future Directions

  • Blind RFID values read, stored, & shared. Hash (with salt), or HMAC. In database, and uploaded in gForm. (Prevent snooping & spoofing "credentials" - RFID is just ID, no secret / password / challenge.
  • Report additions (blinded / without UIDs) to Discord & Slack (via RSS?).
  • Look into self-hosting database. https://nocodb.com, self-hosting (self-hosted ~Airtable + APIs. Auth handled.)
  • Integrate User:Mcint/Projects/Member system.
Retrieved from "https://wiki.extremist.software/index.php?title=Olympus&oldid=82084"