Using a Raspberry Pi running Android Things, I have created an authentication back-end service using Firebase Realtime Database and a generic keypad with RFID tags. The keypad is set into reader mode which passes data to the Raspberry Pi using the Weigand 26 protocol. The user is identified as an access key in Firebase and is either allowed access or denied based on rules stored in Firebase. There is an Android app available that allows provisioning of access keys as well as other functions such as opening the door, creating new PINs, provisioning new RFID tags, and setting your access key's "boom music". Using the public Spotify API, users can select a 30 second clip of music to play when they are authenticated into the system. I have also created a web admin portal using Polymer. This is still a work in progress but is fully functional as it is being currently used in my office.
BackgroundAccess control systems come in two varieties - overpriced or too generic. Even the overpriced systems don't have all of the functionality that you might want. The generic systems are nice because you can build your own and choose which parts you want. However, these can be very confusing and difficult wire up and still don't provide all of the functionality for your needs. My goal is to create a modular access control system, using generic parts along with Android Things, to build a premium platform and connected experience.
HardwareThe hardware is pretty simple. The brains of the whole operation is a Raspberry Pi (or NXP board) running Android Things controlling a relay switch. The Android Things board isn't just outputting, but receiving input too. The RFID keypad has a built-in microcontroller and relay in it, but it can all be bypassed and put into 'reader' mode, which sends a Wiegand 26 signal down two wires. The data is passed to the Pi and sent off to the cloud for authentication.
The Android app has many features and functions. Users login with their access key and are presented with features pertained to their level of access. For example, if a user is an admin, they will have more control than a user that just has temporary credentials. Below is a list of features/functions for each level of access:
Admin: Usually the owner(s) of a company or household.
- Has the ability to create new Access Keys for their specified location.
- Can provision new tags for their specified location and attach them to a different Access Key (of same location)
- Can provision new pin for their specified location and attach them to a different Access Key (of same location)
- Can provision new temp pin for their location
- Can enable/disable Access Keys for their location
- Can create their own pins
- Can provision their own tags
- Can apply boom music
- Can view logs
- Can open door
User: Usually the employees of the company or friends/neighbors of a household
- Can create new pin for their location
- Can apply boom music for their own access key
- Can open door
Temp: A time sensitive access key
Can open door
The mobile app currently supports the above features. Future improvements include integrations. Integrations include weather, gmail, and calendar, along with a webhook to use for other existing applications (ex - turn on coffee pot via a connected switch when a certain user enters the building for the first time that morning)
As stated previously, there is more to this system than just a keypad. Open API's allow other systems to securely integrate into JARVIS. Here is an example of an Amazon Dash Button integration:
FutureThe end goal of this project is to provide a website where users can design their own access control system, customizing it to fit their needs and providing custom build and installation instructions.
Comments