RFID Machine Access and Usage Logger for University Labs and Workshops
A final year project that builds RFID power interlocks for machines in university labs, school workshops and makerspaces: a machine only switches on for a student card that has passed the safety induction for it, and every session is logged. Lab staff get a training register, usage reports and fault reports in one web app.
Intermediate
A small team, or one strong student willing to learn something new.2 semesters · 2 to 3 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- An interlock unit per machine that reads a student card and energises the machine only if the card holder is authorised for that machine, with a clear LED and buzzer response.
- Offline authorisation: each unit caches the allowed card list and keeps working when the network or server is down, syncing logs later.
- Session logging of card, start and end time and actual running time from a current sensor, so sessions reflect real use rather than card taps.
- A web app for lab staff to record safety inductions per machine, grant and revoke access, and set expiry dates for training.
- A fault report flow: a student taps a report button on the unit, the machine is locked out, and staff get a notification.
- Usage reports per machine, course and week, useful for maintenance planning and lab booking.
- A trial on at least two machines (for example a drill press and a 3D printer) for three weeks in a real lab.
If you have time left
- A booking calendar that reserves machine time and only accepts the booked student's card in that slot.
- Consumable accounting for 3D printers and laser cutters based on run time.
- A kiosk that shows which machines are free, in use or locked out.
The problem labs have with who uses which machine
University engineering labs, school technology workshops and makerspaces have machines that can injure an untrained user: drill presses, lathes, laser cutters, band saws, soldering stations, even 3D printers left running unattended. Lab rules say only students who have done the safety induction may use a machine, but enforcement relies on a lab attendant watching everyone. Staff also have no idea how much each machine is used, which makes maintenance and budget requests guesswork, and broken machines are often reported late or not at all.
What already exists and the gap
- Fabman is a commercial platform for makerspaces and university workshops that controls machine access from training records and tracks usage, sold as a subscription with its own hardware.
- ACNode by Makerspace Leiden is an open source ESP32-based access system for doors and tools, built for a hobby makerspace.
- Tulane University's makerspace built an RFID system that checks whether a user was trained before a machine can be switched on, a local build rather than a product.
The gap is a system that fits a typical university or school lab: uses existing student cards, works offline, records real machine run time rather than just card taps, and produces reports lab staff and administrators actually need. Subscription tools priced in euros or dollars are hard for many labs to approve.
What you build
- Interlock unit: an ESP32, RFID reader, LEDs, buzzer, a report button, and a contactor in the machine's supply line installed by a qualified electrician.
- Server: MQTT ingestion, access list distribution, session and fault storage.
- Web app: roles for lab staff (manage inductions, access, faults) and students (see their permissions and sessions).
Main flows: student taps card, unit checks its cached list, machine powers on; current sensor measures real running time; student taps out or the unit times out after idle; staff revoke access and every unit updates within a minute.
The technically interesting part
The design has to be safe and correct when the network fails. Access decisions happen on the device using a cached, versioned access list, so you must design how updates propagate, how a revoked card is handled if a unit has been offline, and how logs are buffered and deduplicated. The interlock itself must fail safe: power loss or a firmware crash must leave the machine off, and a machine that is running must not suddenly cut out mid-operation in a way that is dangerous (for a lathe, a controlled stop may be preferable to a card timeout). Present your threat and failure analysis to evaluators alongside the demo.
How to evaluate it
- Time from card tap to machine enabled, measured over at least 200 taps.
- Access list propagation time after a revocation, with the network up and after reconnection.
- Log completeness: sessions recorded against a manual observation log for a full lab day.
- A survey of lab staff and at least 15 students after the trial on usefulness and friction.
Suggested plan
- Month 1: lab visits, rules per machine, card format check, safety review with lab staff.
- Month 2: interlock unit on a low-voltage test load, offline access list.
- Month 3: server, sync protocol and log buffering.
- Month 4: web app for inductions, access and reports.
- Month 5: installation on two machines with an electrician, fault reporting.
- Month 6 to 7: trial, measurements and report.
Path to a product
The first customer is your own department's lab, followed by other universities and school chains with technology workshops. Sell interlock units per machine and a yearly licence per lab for the web app. Makerspaces and fab labs are a second market. The same core fits shared equipment in research labs, such as microscopes and centrifuges, where usage billing between research groups matters.
Scope warning
Do not rewire machines yourself; an electrician installs the contactor. Do not build biometric access or a new student ID system. Do not try to integrate with the university's student information system in the core project; a CSV import of students is enough.
Learn what you need on Sefism
- Fullstack roadmap : building the web app, API and database together.
- System design cheat sheet : caching, sync and eventual consistency in a small real system.
- OWASP ASVS : security requirements for the admin web app that grants access.
- PostgreSQL Documentation : modelling inductions, permissions and sessions.
- Next.js Documentation : a quick path to the staff and student web app.
Get help with this idea
The offline access and fail-safe design are where supervisors will push hardest, so think them through first. If you want a second opinion on scope, hardware choices or how to set up the evaluation before you commit, bring your plan and your bill of materials and we will pressure-test it together. New here? Create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.