RFID door entry system for BuildBrighton

It's been a few weeks where most of our nerd-work has been coding (the app for our electronic board game is starting to look very impressive btw, we're just not quite ready to unveil it yet!). So it was nice to spend a few hours this weekend working on an actual physical project - an RFID door entry system.

At BuildBrighton we've had an explosion of new members in recent months. Not literally of course - we do play with some dangerous equipment and event a few volatile chemicals at times, but it's a metaphorical explosion. We've had lots of new members, all visiting the space, finding out what an amazing place it is, and wanting to join up as members.

Which is all well a good, but has lead to a bit of a problem regarding giving all our new members access in a timely manner. The current process is that new members must be "accepted" by the community (so are on a "trial basis" for a few months) before being nominated as a member, and approved by a director of BuildBrighton.

This process worked fine, when it was a small group with 30-40 members. But as our number approaches 100 members, we're having to review how we give people access to the space (and, for future consideration, how we give members access to different pieces of equipment, once they've been trained and proved their competency with them).

We currently have an RFID-based keyfob door entry system.
It's actually made from our Global Hackerspace Challenge entry, a spelling-owl that used RFID cards to show different words.

In true "hacker" style, we chopped bits out, added bits in, and re-purposed it into something else for our needs. But it's a bit clunky, and key numbers have to be hard-coded into the hardware - so every time a new member wishes to have a key for the 'space, someone has to re-code the hardware to make the new key work. This is no longer proving sufficient for us, so we're moving over to a web-based administration system. So, while we're about it, we're building an entirely new door entry system.

Here's how it works:

• We're using the Wiegand26 RFID reader we trailled about 18 months ago.
• We're also using using one of those ENC28J60 ethernet modules to talk to the BuildBrighton members website.
• And, should the internet go down, we don't want members locked out, so we'll store key credentials locally in a 24C256 eeprom chip onboard
• The whole thing displays information on a simple-to-use 16x2 character LCD

The basic idea is this:

• A keyfob is presented to the reader and the serial number read from it.
• The keyfob number is displayed on the character LCD.
• This is sent (via the ethernet module) to a URL to validate the serial number and the web site returns data to say who the key belongs to
• If data is successfully received from the website, it is stored in the local eeprom chip
• If there is a fault and no data can be received from the 'net, the eeprom is searched, looking for a matching keyfob number. If a match is found in eeprom, the data is read out and handled as if it had just come from the website.
• If the keyfob belongs to a valid user, their name is displayed on the character LCD and a relay is activated to open the door.
• If the serial number is not recognised, a "not recognised" message is displayed in the lower part of the LCD display.

This allows us to quickly and easily add (and, should the never ever arise, to rescind) keyfobs to the door entry system, without having to actually visit the space to re-program the door opening hardware. If a user presents a keyfob that is not recognised, the serial number from it is displayed on the character LCD. The user simply contacts one of the BuildBrighton administrators and tells them their keyfob number.

The admin user can then log into the BuildBrighton members website and activate the keyfob remotely.

Of course, there's always a chance of a mis-match between the 'net and the local eeprom - but this is a problem with any shared data: there needs to be successful contact with the BuildBrighton website for the data to be transferred locally- and the local data only changes when the BB website is successfully contacted. But, given that the system always tries to contact the web server before querying the local eeprom, we feel this gives the best compromise between data integrity and just being able to get into the 'space in the event of a network meltdown. After all, someone still needs to be able to get into the 'space to fix any problems with the internet connection, which could otherwise bar members from entering!