Wow that is legit. Google’s github repo If you can allocate some budget to this, I could help try and reproduce the hardware. Not sure if RFID is ideal for us though, since “where employees all have the same kind of RFID badge” doesn’t really describe us.
We can get a budget for this.
There is some momentum growing to move the zing into the front room for a few different reasons, and also some talk happening about how to address unfair use of the machine and get a handle on maintenance schedule and costs - which are becoming an issue.
Could something like this be made to work with a key code, for example, unique to each user?
Betty the user walks over to the laser and punches in her code on a little keypad next to it. Having entered her code, the fan turns on, a quiet air assist pump turns on, and the laser turns on. When Betty is done with her work, she hits a button to end her session. Everything turns off again, and a log entry invisibly is made of how long she used it for.
Admins could check the log if there is a complaint or maintenance is required.
If it works well we might consider another one for the front door at a later time.
To me, the easiest way to accomplish this is not to try and reproduce what Google has done, but rather to use a Raspberry Pi 3 connected by a USB cable to an Arduino wired up to a keypad, and the Pi also connected to an LCD.
The Raspberry Pi makes all the decisions about authorization by listening to input from the Arduino by talking back to a server API (e.g. over HTTPS) that hosts the mappings between users and their identifying code and what it authorizes them to do.
With that in place there are just two other considerations. (1) How does the unit actually prohibit use of the equipment by unauthorized individuals, and (2) How do you physically secure the whole situation?
For the prior consideration, I think the easiest thing to do is to use something like a Power SwitchTail II to cut off power to the unit when it’s not authorized. I say “something like” because I don’t know what the Laser Cutter power requirements are. The PSTII says it can handle a “switching capacity: 15amps @ 120vac” which might be just fine. And you just put some mount points inside the box so that the various electronics and and wiring stay in place.
For the latter consideration, I would advocate putting all the aforementioned electronics, including the plug end of the equipment being put under authorization into a box with a padlock (i.e. one with a key) on it. The main things are (1) someone shouldn’t easily / accidentally be able to gain physical access to what’s in the box, and (2) someone should be able to circumvent the box to supply power to the authorized equipment. Basically I would say you dangle the PSTII out of the box.
Just to summarize / estimate a high level bill of materials for what I proposed above:
$35.00 - Raspberry Pi 3
$8.46 - 16GB microSD card for Pi
$10.00 - Arduino - Just use one that we already have in IG stock
$24.95 - RGB LCD + Pi Interface Hat
$7.50 - 3x4 Matrix Keypad
$25.99 - Power Switchtail 2
$111.90 Electronics Subtotal
Enclosure / Interconnect
$10.00? - A Pad Lock / Bracket
$20.00? - Wood / Glue / Screws
$10.00? - Stain / Paint / Finishing
$1.95 - Jumper Wires (for Arduino to Keypad)
$51.95 Enclosure / Interconnect Subtotal
Take that last part with a grain of salt, building enclosure / wood work is not really my bag. Also consider shipping and taxes. Probably looking at something like $180 in materials ballpark.
I also think interrupting the power supply is a good solution. I would love to see ventilation control and air assist come on with it every time.
I can donate a raspberry pi3 and an SD card. Enclosure materials we probably have most of in the shop unless we want to go with a plastic enclosure or pelican box type solution.
What would it take to get started? I can draw a mock-up and pitch the idea around IG. If the cost to IG comes in under $100 I can approve the spend with just one other officer.
Adafruit also has a 4-way substitute for the power switch tail comparably priced. That could satisfy turning multiple things on / off at authorization events.
A single input signal to switch four outlets: 1 always on + 1 normally on + 2 normally off.
So we could plug the Pi (an by proxy the Arduino) from the always on plug, and three “other things” from the thee other plugs, two of which are “normally off” so if the electronics fail for some reason, the authorized equipment won’t work.
I can place an order today from Adafruit and get reimbursed later if you are cool with it. I have pi and arduino that I can use for development purposes. Here’s a quick system drawing (using draw.io):
There will be some policy work to do but I don’t think that should stop the hardware development.
I need one more officer to approve a spend of up to $100. I emailed them and that may happen soon or maybe in a day or two.
In the meantime, if you want to make the buy IG could reimburse you or I am willing to split the cost if it comes to that.
OK I placed the order from Adafruit for:
Controllable Four Outlet Power Relay Module version 2
RGB Negative 16x2 LCD+Keypad Kit for Raspberry Pi
3x4 Phone-style Matrix Keypad
Female/Male ‘Extension’ Jumper Wire
Will let you know when it arrives, and I can start working on software. I’ll make a GitHub repository for it under IG. https://github.com/ithacagenerator/AuthBox
Just wanted to give a brief update on progress, and elaborate some architecture / design thoughts. I’ve been working on fleshing out the repository and making updates to the server hosting ithacagenerator.org to support the concept.
If you go to ithacagenerator.org/authbox you get an (currently empty) angular app, served up by an express.js, using the existing apache server as a reverse-proxy handling the HTTPS. I’ve also installed mongodb on the same server. So the pipes are basically in place.
Next is to flesh out the “api” routes in the express app:
PUT authorize/:authbox_hash/:user_code triggered by a successful authorization PUT deauthorize/:authbox_hash/:user_code triggered by a successful deauthorization GET authmap/:authbox_hash triggered periodically to get allowed authorization codes
Firmware for Arduino is basically done. Needs to be tested with the actual keypad hardware we’re using, and just using a terminal to emulate the raspberry pi serialport interactions. The stuff I ordered from Adafruit turned up, but I haven’t gotten around to doing anything with it yet.
Haven’t broken ground on the Raspberry Pi software yet, but I’m thinking it will be a node.js appliction which will use npm packages
adafruit-i2c-lcd to interact with the lcd,
serialport to interact with the arduino, and
request to interact with the server. The pi will launch that app using
pm2 process manager, which will also ensure that it gets relaunched automatically if it crashes for some reason. I think the Pi should just poll the server periodically to update a local file of valid unlock codes specifically for that authbox. And when someone successfully authorizes / de-authorizes it posts a message to the server.
All for now, let me know if anything doesn’t make sense.
A quick update, those three routes are implemented and seem to be working as expected. I’m also trying to get mongo-express running on the server, but have hit some snags with it working with a reverse-proxy configuration in apache. I’ll keep tracking that, but it’s non-essential.
So I think I can move on to the Raspberry Pi / Arduino stuff next. As I said before, on the Arduino front, it’s primarily testing / debugging the firmware in isolation (via a terminal). So I think the majority of the remaining work here is on the Pi at this point.
This looks cool.
Hey all, I posted a question to Stack Overflow related to a facet of this project. If you are on Stack Overflow, please upvote it (to get it more attention) and/or contribute answers as you see fit.
OK got that sorted out, making progress on the Angular “management” app.
Soldered together the LCD Plate today (it was a kit). Having a bit of trouble getting it running. Backlight colors are working, but not seeing characters being displayed.
OK LCD is working. I had to do some repairs to the Pi plate, but it seems OK now… Sheesh, that was supposed to “just work.” Anyway, on to the next thing!
Loaded the sketch on an Arduino Uno today wired up the KeyPad and did some testing. Made a very minor bug fix and added some additional feedback and i/o logic for command errors. Seems to work great. The basic idea is that the Arduino does two things:
Anytime a key press event happens on the keypad it outputs the symbol associated with the pressed key as a single ASCII character line over USB serial (i.e. 9600-N-1). That is to say if you press the 5 key, it outputs ‘5’ and a line termination sequence (\r\n).
Anytime a valid authorize message is sent to it, it drives DIG13 high and acknowledges with a single line “authorize” response over USB serial. Anytime a valid lockout message is sent it drives DIG13 low and acknowledges with a single line “lockout” response over USB serial. At power on it drives DIG13 low.
I think that wraps up the Arduino side of things.
Progress continues on the Angular app. I think I’m basically done with the UI / routes for dealing with AuthBox objects. Haven’t yet fleshed out what to display on the detail page for a particular AuthBox, but I’m thinking just a sortable / paginated table of all the Authorization events associated with that AuthBox. That page will also be from where I expect to add / remove Members from the access list for an AuthBox.
Before addressing that page, however, I’m going to move over to the Members section, which will encapsulate the functions for Add / Modify / Delete of Members. In doing that I’ll be fleshing out more of the back-end routes associated with those functions.
In other news, I’ve got a Pi with the LCD plate attached, running a NodeJS program counting up the seconds on my desk, just to make sure there are no up-time issues. So far so good, no problems there.
Add / Modify / Delete for members is implemented now… Next thing to do is to work out and implement the UI for adding / removing a Member from the Authorization List for a given AuthBox, which you should probably be able to do from either the detail page for a Member or the detail page for an AuthBox.
I’ll do that next before displaying the Authorization history of an AuthBox on the AuthBox detail page, and the Authorization History for a Member on the Member detail page.