Interest in your RFID system from Vic Makerspace

Hey there Dallas Makerspace!
I’m Liam, a member of the Victoria Makerspace up in BC, Canada. I am one of the members in charge of planning/designing/building an RFID Tool interlock system for our space. I am still very early days on the project and mostly reviewing available hardware although I have some hardware to prototype with.

As I understand the Dallas Makerspace has one of these systems functioning in the wild (at least a perusal of your wiki and talk forum leads me to believe so). This type of project seems to have died on the vine at several other makerspaces so I was wondering if any of the members who help maintain your system or built it would be willing to chat with me. It would be very helpful if I can get a feel for what we might be getting ourselves into and how I can avoid creating new problems for our makerspace.

Any time, guidance, or pointers would be very much appreciated.



Calling @hon1nbo and @yashsedai who probably know the most about this.

1 Like

We’re still in the adoption phase ourselves, we have three RFID systems in use within our community, I’ll tag the relevant people for each and give a my opinion on them.

  • Open Source DMS Created system in use in the automotive area. This was created by a couple memebers who were displeased with DMS having to rely on a company to provide an essential service to the makerspace and also there being privacy concerns with the route the vendor uses to integrate with the makerspace (full LDAP, so they have more information about members than we prefer generally). This method uses python to query an internal API we developed and maintain that actually tracks back to our Windows AD which is how member’s access is tracked (through AD groups). @TBJK designed the industrial hardware aspect of it, and @hon1nbo has taken over the software design and is the chair of the committee currently utilizing it the most (automotive)

  • The Machine Shop’s HAAS RFID: This system has been pretty bullet-proof, but isn’t attached to our AD and requires some manual addition and subtraction of badge numbers to be added with some perl scripts. Those scripts are on the wiki, and the system works great except for not really being networked. We’ve had it running on the HAAS for a few years, and it’s still blowing and going. The member who worked on the software is no longer I member (I think they moved away) but they still sometimes drop by talk, so they might comment if they so feel led.

  • The Woodshop’s closed-source system. This system has operated OK for us, the main issue being when there’s downtime we rely on a vendor who doesn’t always share out 24/7/365 aspect. Like many other things that are under vendor control it’s always a “prove to me that what you are experiencing is OUR fault, and then we’ll help you fix it” which tends to rub makers the wrong way. I’d avoid getting into bed with a vendor on something so critical as tool access, but if your makerspace doesn’t have the ability to maintain your own system, it could work. For me personally, I haven’t used any tools that require this RFID because of the privacy implications and the vendor of course needing to maintain logs and identity of users which sits wrong with me. I believe the vendor (and also member, and previous board member) is @Robert_Davidson

What type of account management system do you have? That might help lead you one way or another.

Disclaimer: I helped write some of the early prototyping code for the open source option, but I have since moved on to other volunteering activities.


For the open source solution, this is the GitHub repo:

We’re using an rPi with a PiHat relay / IO shield. This is combined with a USB RFID reader for our EM4100 system.
It has two ways of communicating with our systems: one is an API call to our MakerManager instance, which is the glue that ties together WHMCS and AD ( github: ) and the other is a call to a small web server running on the domain which talks with Active Directory (a powershell script pulls the directory, formats the relevant info as JSON, and serves the JSON file to callers with the proper API key). The secondary option is nice since the controller can be configured to cache the JSON output, which allows for operation even when the network goes down.
On the rPis we additionally setup a static web server that can view log data, so when someone does something abusive an admin can pull whomever it was that badged it on.

The boxes control a contactor (sized for whatever equipment is being driven with a low voltage control line), the low voltage transformer and breaker for the rPi and PiHat, and an RGB LED to indicate status (standby, badge in successful, bad read/network error, and badge rejected). A current sensor measures draw from the load, and can shut off the interlock after a period of electrical inactivity (IIRC the default in the source is 5 minutes of no load).

I don’t think we have the hardware info digitized but that’s on the TODO list.



Hi Liam,

As Malcom said DMS has a few methods.

I can talk about my solution

It is a SaaS solution where you purchase our custom hardware.

Ultimately as a user you get access to a web interface and you configure all of your equipment there at the site and it provides you a lot of reporting around utilization and audit history.

We also can support custom integrations if you already have a learning management system or a database of users.

If you would like PM me and I can give you a tour of the site. (If you can’t PM just let me know here and I can send you my cell.)

Ultimately a lot of it depends on your makerspace and what direction you want to go I picked the commercial path because it’s what I know and I believe it offers the most value to makerspaces that can’t support a custom solution.

Finally, if you want to just talk about pro’s and cons of hardware or software methods I can help with that as well at the end of the day I believe having access control on equipment is incredibly valuable and I am around to support you guys for whatever direction you want to go.



I will definitely take a closer look at the relevant wiki pages.
As for our member management system we are currently using Wild Apricot which has been just like your experience with your closed source system :grimacing:
We are looking to abandon that ship as fast as is reasonable. So on the one hand we’re rather flexible in that regard and on the other it is a disconcertingly open ended question from a project management point of view.
Disclaimer of my own: I am the hardware person on point for the project not so much the software (& we don’t yet have a specific individual nailed down. Early days). I am however on this “full-time” since the Victoria Makerspace managed to finagle this project into counting as a co-op term work for me (just finish my first year electronics & electrical engineering program). So software advice is still welcome I just might not fully grasp it right away (but I will eventually or I’ll wrangle one of our members who does).
I’ve link this thread on my own project thread (mostly just review of available hardware atm) on the Victoria Makerspace discourse. So it is possible some of our folks might find their way over here organically.


Oh wonderful, I will take a look at that repo and see about finding one of our own members to help me understand it (see above disclaimer). Thank you!
What pushed you towards using Pi’s vs other SoCs? I am currently leaning towards ESPs either 8266’s or 32’s.
Likewise with the EM4100? We’re considering going with 13.56MHz MiFARE since its ubiquitous and cheap. We already have 125kHz cards that control our front door which is implemented by the Techpark we’re located in. I am told by some folks that took at stab at this projects years before me that the readers used by the park’s system are too expensive to be a practicle option for us. I’ve not fully verified this myself but I’m thinking if that is the case slapping a 13.56MHz sticker on our access card should allow for unified access.
Not that its an overwhelming issue for us but we are definitely hoping to have the ability to revoke individual access should we need to.


I’ve seen the PM you sent me and I will get back to you within today (I am unfortunately juggling chasing my college’s co-op people at the moment as well).


Microsoft (or Linux’s) Active Directory (or OpenLDAP) can be really handy as you’ll pretty much always have members that know how to manage a Domain Controller. Downside is licensing if you can’t get it donated.

Our goal was to be as hardware agnostic as possible, so that the software could be extended as parts go EOL or don’t exactly suit the system in question. You might not need contactors and big beefy relays to lock a cabinet with a solenoid. Some systems might need current monitoring for a timeout, because cutting power could be dangerous, some systems tolerate sudden power loss just fine etc.

The Pi was chosen because it’s not scary sounding to the membership lol. Most people know what one is, and while they aren’t exactly industrial grade, they’re reliable enough. The reason we didn’t go 8266 or 32 was that we wanted something that could do wifi and/or ethernet. Our wifi infrastructure is good, but may not be able to support all of our equipment in the long term with people using it for other things as well. Having a physical port we can run an ethernet drop to is really nice. Also, for speed of prototyping and development, it’s really nice to have a full linux hardware stack for a web server, or just installing python etc. Using a Pi means we can swap to pretty much any single board computer and as long as we can GPIO a relay we’re in good shape.


Another reason for the pis is we use them in house for so many other things (signage, interactive touchscreens, thin client workstations, etc) we have a bunch sitting on-hand, and support parts for them.

On the logic side I actually like the ESP version of the system that @malcolmputer helped build as a prototype, but it wasn’t versatile enough in the first version and we needed items ready to go. I’d like to see our codebase able to support both builds (on one hand the easy to throw together Pi setup with tons of spare parts, on the other the ESP system that can be a smaller box for simpler things like cabinets etc).

As for EM4100 versus MiFare, cost and handiness. The mifare chips cost more at the time, and the EM4100 equipment was all cheap. Nice thing about the 125kHz is it’s been around so long that so much tech supports it and the basic wiegand implementation. But in terms of hardware for the badge choices whatever you can support getting equipment for reliably within budget, as most nowadays have keyboard entry support for things like the kiosks we built.


The bullet-proof comment made me smile. I’m glad it’s still working!

I’m still in DFW, just no longer a member.


Alright so after several days of co-op admin silliness and spelunking the official Espressif documentation/codebase for the 8266’s I am leaning more in the direction of the 32. Getting the official sdk functional was more painful than I anticipated and I still don’t have it totally playing nice with VSCode. The Arduino code base for it does seem to workout of the box but a lot of Arduino libraries (even ones marked for ESP compatibility) don’t appear to feed the watchdog timer. The 8266 git repo suggests that Espressif is looking to unify the 8266 rtos sdk with the ESP_IDF which I presume will mean chaos for the various other frameworks riding atop it?

Now that I’m forming a clearer picture of just how complex this relatively simple system can get I am wondering how much maintenance overhead y’all have with the open source system? Individual systems crashing or getting weird from power outages? Members cards not working when they should? Other intuitive weirdness?

An RFID un/lockable cabinet was mentioned earlier in the thread but I am a little unclear if this is something y’all have in service? This idea has been floated for our electronics area where we have lots of smaller but none the less expensive tools we want to keep track of. For some “bigger small” tools like scopes, solder stations, and such I figure locking them into a switchable power bar will suffice but things like our god multimeter, or fancier iron tips can’t be controlled that way.

As an aside, I started using ESP32’s with the Arduino Code base inside VSCode to make my life a bit easier. It takes a little tweaking to get all Intellisense working etc., but a few details here: Maybe Consider Using Visual Studio Code for Arduino Development?

1 Like

Again I used Mongoose OS which is a commercial solution due to the issues I had early on as well as I need a solid/secure OTA process.

The ESP’s will blow if you give them over-voltage them so you have to do a lot to clean the power from optical isolators to snubbers. Primarily because they are generally installed on high inductive loads which are not exactly the greatest spot to live for a microprocessor.

As far as crashing and power outages you have to build for that in your hardware/software design.

Members cards are a wild card we had some of the injectable RFID badges which needed some tweaked logic. On some of the commercial sites, I have had to do some tweaks for site codes, etc.

I would say you have a few options you can move some of the logic to the reader especially in high-security environments for makerspaces it really depends on the RFID badges you use and reader but you will have to start dealing with all sorts of variations from leading 0’s to different encodings.