Being a small company in a shared office building we soon came to the point that there were not enough keys available (I’m talking about the yale-type keys). So we thought that the door button basically does not much more than closing an electronic circuit – a task that can be easily done by a small chip as well.
Getting started with EDO (Electronic Door Opener)
The requirements are simple, we want to provide a way to enter the office for the growing number of employees without the need of a physical key for everyone. And this is what we came up with:
- A REST endpoint with Node.js
- A very simple web-inferface with Node.js
- Arduino for doing the hardware stuff
- Raspberry Pi as glue
To gain experiences with new stuff and to get along with the limited hardware capacity of the RPi we decided to use Node.js. In the first version we agreed that a simple web-interface would to the job (but keeping RFID or Bluetooth LE in mind). We came up with the following architecture:
- Arduino Nano (Amazon): ~8€; Controls the Relay
- Solid State Relay (Amazon): ~7€ (A/C circuit! MuGFET won’t work); Closes the electronic circuit
- Raspberry Pi: ~40€; Runs the server-software
One could say “Why do we need an Arduino here? RPi has GPIO!”. Well, that’s true but if you boot the RPi, the state of all GPIO port is always HIGH which would open the door! We don’t want to build on the stability of Linux running on a developer board, also DoS’ing the RPi would open the door.
Telling the Arduino to open the door via the relay is achieved by changing the state of the input-pins it is listening on. In its main-loop the Arduino checks if the two input pins have different states (e.g. pin4 –> HIGH, pin 7 –> LOW) and if the states differ from the last iteration. If both conditions are true the relay closes the circuit of the door opener for 750ms – et voilà, the door is open!
While the Arduino runs with 5V, the RPi operates at 3V. But the RPi only sends signals and won’t receive any so no resistor is needed in our setup.
Communicating with the Arduino via Serial-interface was not an option for the following reasons:
- Open a Serial connection, sending a command and closing it leads to a high delay for opening the door (we’ve tested that…)
- Keeping the Serial connection open leads to more complexity (handle connection loss, …)
The old Model B+ we had laying around is just fine for running a Node.js server. Installing Raspbian doesn’t take long and installing Node.js is done with a simple apt-get. A restricted user edo runs our Node.js server and the Homebridge server (see below). A simple bash script uses the gpio-command to switch-over the values of the GPIO ports that eventually opens the door. Be aware that a user has to be part of the gpio-group to control the pins!
To provide a small API to communicate with the Arduino, we set up a Node.js server as follows.
In the first version it should provide two ways to interact with:
1) REST-API (open the door with a simple GET-request)
To implement the REST API we decided in the favor of the express framework. For more information on how to use express with Node.js, check out this blog entry.
2) User Interface (open the door with a click on a button in the web-browser)
Although the first versions’ user interface is basically one button, we wanted to try out a template engine for Node.js.
In our case, it is pug (formerly known as Jade). A more in-depth analysis of this library will be covered in an upcoming blog entry.
The Node.js server really does not much more than executing a bash command, no black magic here.
HomeKit / Homebridge
Just a few words on the Homebridge integration here:
Homebridge is a lightweight NodeJS server you can run on your home network that emulates the iOS HomeKit API. (from the Homebridge readme).
With the SimpleHttpSwitch-plugin we can define a button for HomeKit that calls our REST-endpoint.
(We were just in time with iOS 10 that now ships with an HomeKit App!)
We made the experience that HomeKit != OfficeKit. HomeKit only provides a very basic user-management: the person that pairs with the Homebridge first becomes the (only possible) administrator and can grant or revoke access to other Apple-Ids. That’s it!
Conclusion, Limitations, Further Roadmap
The only security layer at this point is the WiFi-password. The web-interface is not very fancy and we don’t have any other entry points like RFID at the moment. In our internal Backlog there are lot’s of other ideas like a finer role/right management. It would be nice if a privileged user could define access times for users or groups, e.g. “regular employees” can only open the door between 7am and 6pm whereas the managing employees can always open it.
Another thing that I withheld: the person that is the last to leave the office still manually locks the door with his classic key (greetings to our burglary insurance 😉 ) and as a consequence the person that comes in first has to open it this way!