Difference between revisions of "RFID System Software"
m (Adding category)
m (Adding category)
|Line 20:||Line 20:|
Latest revision as of 16:28, 25 March 2013
 Our RFID System Software Summary
We are using the open-access-control software v1.3.2 on the Arduino. This handles storing and editing user info in the EEPROM and handling scanned cards and letting people in and out and logging sensors (like motion sensors) and such. This pretty much covers our needs for controlling the board and is nice and stable when the server dies, or somebody reboots it, or whatever. It's a nice interface for both humans and machines and here mostly I'm talking about software we've set up on the server side.
Any code referred to from here on can be found at the Bloominglabs github.
At first we followed the setup outlined by the shop23b guys on their site for logging. There's a script for logging, and for sending email notification. This is great and it worked for us but as a Python hacker I wanted something in Python instead of in shell scripts, and the business with dealing with the USB connection via minicom and detached screen sessions you can attach to as needed seemed a bit awkward and it seemed there had to be a more straightforward way to handle the communication and allow other processes to communicate with the system (about which, more later). But mostly, as hackers we can't just leave things alone.
 Version 1
For this version I set up everything as per the previous link and wrote an IRC bot that handled the basics of saying 'hi steve' when for example steve badged in. This script got the news about steve badging in by looking at the tail of the log sent to the server via the USB port. This was a bit hacky.
Over time this grew and I (steve) developed a Django site w/ a database backend to manage user and badge info. This was of limited utility because again, info was coming from the RFID system via the tail of the log, and sending info back to the RFID board seemed really daunting what with the business of connecting to the screen session and then release it - easy for humans, for Python scripts (written by me) not so much.
So at this point communication was unidirectional but there was still a lot we could do with it. We had the IRC bot, so the irc bot wrote info to the database so it could be queried about recent activity and provide that info. We discovered a cool site called pushingbox and set up notifications there, which could then be attached (via the Django site) to access and sensor events. So for example I would get an iPhone notification via Prowl when somebody checked in.
 Version 2
To address the business of 2-way communication I looked into changing the serial port interface to a network service. The obvious tool to use for this (given my preference for Python) was the Twisted library. It took a bit of time to 'get' the Twisted library given the asynchronous heavily callback-oriented nature of Twisted but eventually I came up w/ the daemon network service in the rfid_network_server/rfid_proxy.tac file. When it is running it's a proper UNIX daemon and a user (or process) can connect on port 6666 (not Satanic because of the last 6). A program (like doorbot) can communicate via sockets or a network library (like Twisted) instead of dealing with minicom and screen and so on. This version was installed 7/15/2012 and appears to work fine but as with everything it will be enhanced and improved over time. It really opens up the possibilities for the web interface as well.