Makerspace AuthBox on Github?


very cool.


More progress on the Angular app. I’ve successfully implemented the ability to add / remove authorized members from an Authbox Detail page. Used the $pull and $addToSet mongo operators on the Express side of things, which was kind of interesting. I think the thing I should do next on the Angular app is implement the access history data table on the Authbox detail page as that will be more immediately useful, and also will basically complete that page. From there I’ll move over to the Member detail page which will be very similar in nature to the Authbox Detail page.

On a side note, @Elliot_Wells mentioned to me that a nice-to-have feature would be an automatic timeout function. The way it would work is that you’d have to “press enter” on the keypad periodically to stay authorized otherwise after a period of time without a “keep authorized” action by a user, it would automatically de-authorize. We could also use the RGB backlight on the LCD to warn that timeout is soon. And of course, the timeout would be configured through the Angular management app. We should certainly prove out basic functionality first though.


I took a couple days off working on the project but got re-engaged for a bit this evening on the Angular project. I implemented a paginated table for the AuthBox detail page to display the authorization history. Seems to be working, using skip/limit scheme on the Mongo database, which apparently will be a performance bottleneck at some point, but not worried about that right now. Wound up going down a deep dark rabbit hole with some subtlety of the Angular Material data table examples that I got through thanks to this github issue. Good times.

Next thing I’m going to do is the analogy for Member detail that gives the view of what a member has access to and their access history (i.e. across AuthBoxes), whereas the AuthBox detail provides a history of all accesses specifically to that AuthBox, and tells you who (currently) has access to it.


This is really cool. Can’t wait to see it…


OK, I think I’ve finished implementing the Member access history functionality, so I think the Angular app is good enough for now. Will iterate on it later to add analytics and other features.

On to the Raspberry Pi software next. Once that’s working satisfactorily I think we can actually put the physical stuff together and see how well it works.


I’m friends with the fellow who maintains the Manchester (NH) Makerspace auth system. I could ask him for details. It uses RFID. Much handier than a keypad.

They have it on a UPS and the member database is downloaded to the Raspberry Pi, so you can get in even if there is no power and no Internet.


Hi @Russell_Nelson, thanks for the feedback! It never hurts to hear what others are doing. Two things I want to point out in response:

  1. I don’t intend for the authorization system to rely on an internet connection to operate. It would, of course, rely on an internet connection to synchronize it’s access code database with the server. But once it’s got a database, it could grant access without seeking permission from the server, and it could queue authorization records for eventual reporting back to the server if an internet connection is lacking. All that logic will reside on the Raspberry Pi.

  2. I think what I am implementing should be extensible to using RFID tags as well. In fact I have a bunch of RFID tags and a tag reader from Sparkfun that I bought a couple of years ago with that intent, but the project never gained any traction until now. The only change to the system concept would be a different Arduino program (i.e. talking to an RFID reader instead of a keypad).Heck, the Raspberry Pi 3 has four USB ports, so we could ostensibly support both types of input at once. That being said, Initial deployment, to limit complexity, and hash out other technical issues, will be to just use a keypad with personal identification codes. We can always make it fancier later. I just want to avoid letting the project get derailed by too much feature creep before it demonstrates some fielded utility.


Made a bunch of progress today scaffolding out the structure of the Raspberry Pi application code. Still a bunch to do there, but it’s on the right track. Next I’ll fill out the placeholder functions with real implementations, bringing in the relevant packages as needed.

I’ll also need to build an SD card image with Raspian, Node, PM2, and Mongo installed on it, which should be no big deal. In fact I probably already have one that will serve the purpose. I’ll keep at it, but won’t have much free time to work on it this weekend.

Question to anyone reading this. Do you know of something like a “GitHub for SD card images” where I can put the (e.g. 16GB) SD card image once it’s properly baselined (obviously sanitized of Wi-Fi passwords and such)? Otherwise, I guess we’ll just keep a master copy in a drawer or something.


Random side note, @Elliot_Wells , I noticed in the meeting minutes “Possibly prototype 24 hour access” and thought to myself, an instance of the AuthBox could easily support that concept. Replace “Laser Cutter” with “Thing That pushes the push bar on a door inside the space when AC power is turned on” and you’ve basically got it, right? Couple that with an RFID reader as I described in my response to @Russell_Nelson above, and you don’t even have to worry about making the AuthBox keypad accessible from outside the space…



I had sort of imagined a timeline something like this:

-keypad authbox on laser (Testing the stack)

-RFID support for laser (test our RFID skillz and issue some tags etc)

-Roll out RFID tags to some portion of the membership

-Add RFID authbox on exterior door.

I we end up moving, that last step could happen when we get keys to that other space.


Can we host images on our Digital Ocean Server for FTP access?


Short answer, yes of course. Lets talk about it on email, chat, or f2f. Setting up and enabling an ftp server on the same server that hosts discourse or on the server that hosts the wordpress and wiki sites would be pretty straightforward.


Wow, it’s been 8 days since my last progress update… sorry, things got busy at work this week. The “snow day” gave me a bit time to get back into the swing of things though and I made some good progress today.

I’ve now got my laptop (playing the role of the Raspberry Pi here) connected to an Arduino running the KeyPad sketch and connected to a KeyPad and I’m able to punch keys on the keypad and have the program running on the Pi keep track of the pass code, including using the * key for backspace during data entry, and # to submit the code for authorization. Also if you hit * after authorization it logs you out, and if you hit any other key while authorized it extends your time (recall the idle lockout feature). That’s all in the code that I committed to GitHub earlier today.

Next up is to put this on an actual Raspberry Pi and implement the LCD behaviors which are stubbed out in the code currently. I’m also stubbing out the API calls to the server, so those also need to be implemented. Once those two things are done, I think this is basically ready for showtime (or at least securing the whole electronics payload in a box and doing some preliminary physical testing IRL). Pretty excited!

Here’s what I’m thinking for LCD behaviors.

  • If no user is currently authorized, the LCD backlight is red and it says “ENTER CODE” on the first line of text. As you interact with the keypad the second line of text shows the number of characters you’ve entered as asterisks.
  • If you hit # and you enter an invalid code for that equipment, the LCD goes yellow for two seconds, then goes back to red. The entered code is cleared, and you’re back to square one.
  • if you hit # and you enter a valid code, the LCD backlight goes green and power is supplied to the equipment. The LCD says “AUTHORIZED” on the first line, and if we want to be fancy it can put the authorized user’s name on the second line.
  • if you are under one minute until idle de-authorization, the LCD backlight toggles between red and green at 2Hz, displayed text doesn’t change.

I think that about covers it… suggestions welcome as always.


Quick update, as of the last commit, I’ve just demonstrated that an Authbox can synchronize with the server, and that I can log authorizations and de-authorizations back to the server. So I have a Pi connected to an Arduino connected to a KeyPad, and it’s all interacting with the Server to log authorization events.

Last big step before we can start doing physical integration and testing is to implement the LCD stuff. Moving on to that now.


Exciting news, I think it’s ready. I got the LCD functioning as I described. I put a countdown to timeout on the second line when the box is authorized rather than displaying the authorized user’s name or something. So I think we are ready to put the electronics in an actual box and see how it works in real life…


Super nice gizmo. Definitely opens up some possibilities.


I spent some time today on slightly generalizing the access codes concept so that a given member can have more than one access code. The rationale behind this is to open up the possibility of having more than one “method” of authorization. The two that we’ve kicked around on this thread are Key Pad entry, which is currently already working, and RFID, which is not yet working, but which I think is actually a pretty short stretch to get working from where things stand now (like just an Arduino sketch would need to be written and wired up to an RFID reader, I think). This is starting to feel pretty real at this point, I’m super happy with how it’s turning out.

I’ve heard from a couple of people that, in addition to the blinking colored backlight of the LCD, adding a buzzer to give some audio feedback of imminent timeout (within one minute of configured expiry) could be a useful enhancement. Again that would be pretty straightforward, either as another Arduino function hanging off the Pi, or shoehorned into one of the access code Arduinos. The Pi could just “broadcast” serial command like ‘buzzeron’ and ‘buzzeroff’, similar to what it already does to ‘authorize’ and ‘deauthorize’. Probably to keep the concerns separate, I would just throw another Arduino at the problem.


I ordered one of these Seeedstudio 125kHz RFID readers to try out. It ill arrive on Friday, but it looks like it should work as another input method.

I also ordered one of these Adafruit Piezo buzzers to try out, also arriving on Friday. So I’ll try and find some time to integrate these capabilities this weekend sometime if I get a chance.

In the meantime, I think the main thing standing between where things are at the moment and a practical deployment trial is an enclosure design that we can mount all these electronics within. I’m also going to acquire a lockable thermostat cover, we can modify to allow a power cord (but not its plug) to pass through with the cover closed. This would be for the equipment side of the power connection, e.g. mounted onto the laser cutter, so that you can’t trivially defeat the AuthBox by supplying power by using a different power cable.


I can put a prototype enclosure together this evening (or another time) at IG if you want to delegate that.


Cool I’ll bring down the electronics payload for sizing purposes a little before 7p.