I'm revisiting this old topic that I got started on a long time ago but had set aside.
Back then I had the Motes reading the key cards and sending the card id to the gateway just fine. The Mote pretty easily interacts with RFID shields using I2C, reads cards and sends the data to the gateway.
The problem I had back then was figuring out how to get the gateway to properly react to the various card IDs. I was hacking away at metrics files but it never seemed like a great fit for the job.
Hence, I set the project aside.
Now I am revisiting it again.. for another project I had created a sms_gateway side-app that would interact with SMS messages through Twilio and let users send sms commands to the gateway for actioning. It was basically a side-loaded app that made socket connections to the real gateway and listened for metrics and sometimes send commands through the socket.
This scenario is very similar. I could quickly replicate the side-loaded app that listens for RFID metrics. I could use this side-load app to have a nedb database of valid card IDs and do a quick lookup. Depending on the result I can send a command back to the gateway to open the door or not. I could also use one of the quick web-ui for the database file to add or delete card ids to manage which cards are enabled.
I'll post the results here shortly.
Plan -
- create a basic RFID UID metric that is just a textified 7 byte hex id.
- use the same sms_gateway framework to build a side-load app that connect to the gateway and listens for RFID metrics.
- In that side-load app, lookup each RFID UID in the nedb and either deny or
- for valid cards, send back a command to the gateway to open the door
- use one of the nedb or mongodb web ui tools to manage the list of valid cards.
Working on the UI for the nedb database that contains Users/RFIDs that the system will authenticate. Finding an easy web UI front-end to nedb isn't going as well as I hoped.
Got a nedb backed data store with an express based web ui running.
I now have a side-loaded app that connects to the gateway.js through a socket. It then listens for metric updates from specified ID with a specified metric of "RFID:0x.......".
The side app then looks that RFID up in the nedb to see if it is enabled. If enabled it then sends a command (through the socket) to another Mote to open the door.
Interesting, I'm watching this space, keep posting ;)
The side apps basically offload some custom processing that doesn't fit well within the standard gateway.js architecture.
There were two use-cases where this side-apps were useful to me and they both simply:
- Make a socket connection to the main gateway.js app and receive metric updates.
- To cut down on the clutter, they filter out metric updates for specific nodes and specific metrics
- They then make custom decisions based on either external stimulus or in reaction to metric events and ....
- Send node messages back to other nodes in response.
My two use-cases are:
- A server that accepts incoming SMS messages and injects a command based on the inbound SMS. My specific scenario is that when SMS messages are received from authorized users, the gate/door/anything opens.
- A server that listens for RFID card IDs and checks them against a database of approved card ids and injects a command to open/unlock/x the door.
I'll get the code cleaned up and post it here and also post a video of the results in action.
For both of these side-apps, I glued various sample code snippets together. I glued together the following snippets
- I took the basic javascript metric processing and socket.io stuff from the gateway index.html file
- I took the basic Twilio SMS processing from the Twilio examples
- I took the nedb web UI to manage my authorized user tables from a github project.