Git Product home page Git Product logo

makerspace-auth's Introduction

Summary

Sample controller box

We started this project with two goals in mind, for Google makerspaces where employees all have the same kind of RFID badge:

  1. Only people authorized (trained) should be able to use dangerous tools
  2. We'd like to have reliable access logs for even non-dangerous tools

Organization

docs/
  Documentation on the project to include contributions on tool connectivity.
software/
  The Python client that runs on a Pi.
hardware/
  The custom Pi hat we use to interact with buttons and a power switch tail.

Contributing

We welcome contributions, especially ones that make this more useful to other makerspaces. We'd like this to be a generic solution wherever possible.

makerspace-auth's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

makerspace-auth's Issues

Consider dropping py2 compatbility

At some point this should go 3.6+ instead of keeping py2 compatibility. This mostly means being able to use unittest.mock and removing compat.py but also means fewer things to keep track of.

Update README.md - photos, better sourcing info

Filing this to assign to myself:

Planning to update README.md with a more representative photo of the Authbox, more context around the design decisions, links to related projects like FATT, and optional part numbers for ordering complete kits from a manufacturer.

Security Policy violation Binary Artifacts

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

  • hardware/pi-hat-1/ms_auth_breakout-cache.lib
  • hardware/pi-hat-1/ms_auth_breakout.lib

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.


Allstar has been installed on all Google managed GitHub orgs. Policies are gradually being rolled out and enforced by the GOSST and OSPO teams. Learn more at http://go/allstar

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Electrical improvements to pi-hat board

I've had some ideas about electrical and layout improvements to the pi-hat board:

  1. All the empty space on the board should be converted into a ground plane with additional ground traces running in-between the signal traces. One benefit is that less etchant gets consumed during the manufacture process because less copper has to be removed. The other benefit is improved EMI protection. I've heard one anecdotal report that if the authbox is brought close enough to a GAST air pump, the Raspberry Pi may spontaneously reboot. No idea if that was caused by the pi-hat board, but we do have long signal traces that can potentially act as an antenna.

  2. Add room for a debouncing capacitor between each Bn_LOGIC line and GND. The board still works without them thanks to the GPIO.add_event_detect(... bouncetime=150) we have in software, but that's just a simple delay. If you hold the button down longer than 150ms and release it, it will register as a 2nd press due to bounce caused by opening button contacts. There's no need for separate resistors since we enable internal pull-ups in the Raspberry Pi for the Bn_LOGIC lines.

Consider migration to Open/Common Parts Library

When attempting to source the materials for the board as well as collaborate on revisions it would be nice to consider the use of the common parts library.

Pros:
This would allow users to easily access datasheets, compare compatible devices, and check on the life cycle of parts.

Cons:
I personally am not an expert in Eagle so I'm note sure if there are any easy ways to handle updating these devices so this could mean a non-trivial amount of work in swapping parts.

Fix module overloading for python2 on Raspbian

One other change that I think is worth making: In authbox/__init__.py we have logic to replace RPi.GPIO on the import path with a fake if the real one is missing. But if you try running unit tests outside of venv, on Raspbian, and with Python2, then the real GPIO is already installed by default and it prevents unit tests from working.

Now that tests are in their own module, I think authbox/tests/__init__.py should instead do the fake RPi.GPIO replacement unconditionally.

A higher level design question though is how do we want to handle this kind of dependency injection going forward? We're doing it globally for GPIO, but via __init__() for fake queue/timer. We could also have each unit test patch the module under test.

Originally posted by @thvortex in #36 (comment)

Document piezo buzzer connection

The spacing on the pins isn't right for the part on the BOM; also lacks a resistor or some other driver since it's not self-oscillating.

Chore: Update for python3

As Python 2 is still on schedule for deprecation on January 1st, 2020 (and we are approximately 6 months away from that date) community users will need to upgrade to Python 3.

The first version of Raspbian released (Wheezy) contained Python 2.7 which simplifies the process quite a bit. As Raspbian Buster is still defaulting to Python 2 (despite it's release just a few days ago) there is likely value in using the mechanisms provided by future.

Let's capture a list of TODOs and run through any proposals around the work, to capture a way for community collaboration (if there is interest).

Inquiry: Hookup of additional devices

I''m currently thinking through a personal need as well trying to be a bit more forward thinking.

Originally, I was going to make the suggestion of exposing UART via a 4 pin connector.

Then I realized that the pins for SPI0, I2C, and UART are all unpopulated. Is there an opinion on whether the strategy is to stack boards, use a pass through header, or potentially expose any of these pins via a header in the future?

Convert PCB to KiCad, Tag New Version

Since starting this board, we've moved most of our effort/libraries/automation to kicad. We should convert the board to make it more easily to make changes an export the BOM.

Document use of pins to create a "case open" switch.

Similar to older PC cases, we should evaluate a way to provide feedback to the Raspberry PI to know if the case it is in has been opened. At the same time, this largely predicates other things like:

  • constant power
  • stable storage

Similarly the "right" way to do this in the world of distributed systems is more along the lines of endpoint monitoring so that you know if/when the endpoint goes offline.

Thoughts?

RPi.GPIO module is unmaintained and incompatible with latest Raspberry Pi OS

The software uses the RPi.GPIO module to access the GPIOs. This module seems unmaintained, the last release 0.7.1 was on Feb 2022.

One known issue is that this module uses a deprecated sysfs interface which has been removed in the latest version of Raspberry Pi OS.

This is causing the code to not work anymore on that version, due to RuntimeError: Failed to add edge detection, when the code tries to register an event-driven handler for GPIO changes through that deprecated sysfs interface.

It seems like this interface has been deprecated since 2015 and is undergoing a slow death since then. We should migrate away from it ASAP.

Today, it is still possible to do an installation by selecting the "Legacy" version of the OS, but, at some point, these changes will trickle down to the Legacy version, and then the code will not work anymore on any supported OS version, which will introduce a variety of difficulties for the users, from security vulnerabilities to the unavailability of repositories.

As such, the project needs to start migrating to another GPIO library, or to access the GPIOs in a different way.

One possible option is to use the gpio-key dtoverlay (which will create input devices for each key), and gpio-led dtoverlay (which will create a kernel-level, sysfs-accessible LED device). These options are well supported and modern, but require some changes in the code. Unclear how the buzzer should be accessed, maybe through the audremap dtoverlay (this requires a PCB change and a BOM change, but would allow playing sounds directly instead of just being able to beep).

Another option is to use gpiod, but the dtoverlay approach seems more elegant and flexible.

Either way, this needs to start soon, before users are locked out of using the code in currently supported distributions.

The purpose of this issue is to track progress in this area.

C2 capacitor sizing

The C2 filter capacitor is specified by part number C3216JB1E476M160AC is flagged by the manfucaturer "Not for use in new designs".

For a ceramic capacitor of that high of a voltage/capacitance it seems that its a pretty niche part.

Sticking in a 1206 footprint it appears that one can go as high as 33µF when sticking to 12v or 47µF if the voltage can drop to 10v.

Are there any suggestions for replacement parts?

v1.0 Errata: R5 Removal

Background

The intention behind J5 was to have two input pins to support a 3-position switch using software-configurable pullups (B5 and B6). After initial investigation for outputs (called L* in schematic), we determined that physical pin 7 was pulled HIGH on boot, and didn't want relays accidentally triggering before the Python code could start. The four pins we use that are pulled HIGH in default device tree, we included a stronger pulldown resistor, regardless of whether they were intended for input or output.

The problem

The stronger hardware pulldown in tag:v1.0 (R5, 1k) fights with the software pullup (guessing about 5.6k), resulting in a max 0.5V which is still considered LOW. Looking at the physical boards, this could have been a problem as early as tag:v0.3, but the pulldown was only 10k in my locally-built v0.3 and v0.4 boards.

Resolution

Desolder R5

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.