Motivation

The aim of this project is to build a complete solution for the front door access control, intercommunication, surveillance, and security.
The system is designed to be secure, reliable and with high availability. It is also important to note that the design of this system was hugely influenced by the available hardware, since one of the main requirements is to use ONLY the hardware I had laying around.

The aim of this project is to build a complete solution for the front door access control, intercommunication, surveillance, and security.

Features

Access control :

There are four ways to unlock the door using this system :

RFID: the user can use an RFID tag or any NFC enabled phone
Key-less: when enabled, the door can be unlocked when the user gets close
enough to the door.
Touchpad: each user can have a pattern that he can use as a personal access
code
Face recognition: This feature was removed because it has a lot of issues. (long
response time, low success rates and it represented a big security issue.

GeoFencing

Two types of geo-fences are available for the user:

Key-less geofence: is a fixed radius area (50 meters) around the house, when the
user enters the geofence, a message is sent by LTE to the server instructing it to
turn on the BLE beacon. then the app will start scanning for nearby beacons and
measures the signal strength (RSSI), when a threshold is reached, the door will be
automatically unlocked.
Garage geofence: In the same manner a larger radius fence can be defined to
automatically open the garage door when the user is detected to be driving its car
and heading home. The command is sent over LTE

Surveillance and monitoring

View CCTV camera
Intrusion detection: when armed, the system will detect any intrusion through the front door or the garage door, turns the light on, rings every doorbell in the house and sends a broadcast notification to all the registered clients.
Alarm: if the door is left open for a while, a notification is sent to the user

Intercommunication

The audio/video intercommunication is achieved using the WebRTC framework. Users can initiate a call from their devices. The server will then update the OLED screen, turns on the door light and connect the call to the lobby station.

Events history

Every event is saved on the server. The user can access them using the Android app.

There are three types of events :

Doorbell event
Door state change event
Alarm events

The current version of the app can only view doorbell events. other types of events can be viewed by reading the events log file from the web server.

When Events activity is first loaded, the events of the current day are displayed, the user can use the popup calendar to specify a date interval. The events are then displayed from the newest to the oldest. The state of the event (handled or missed) and the user who handled the event is displayed.

Error handling and auto recovery

The server is capable of detecting errors in the whole system and can take adequate actions to recover from them. (see software section for more details)

Security

The system was designed to prevent, as much as possible, cyber attacks. Here are some possible attacks that the system was designed to prevent :

Side-channel attacks: passwords verification is done on the server and passwords are stored in an encrypted file. The lobby station and the server have two distinct power sources.

BadUSB attacks: if the attacker is determined, he can remove the lobby station and have physical access to the USB port on the server. To prevent any silly attack, udev rules and filters were created to block anything plugged into the USB port that isn’t whitelisted. Also, if the server loses contact with the lobby station it puts itself into panic mode, the only way to recover from that is by connecting to the terminal via ssh and resetting the daemon.

Communication between clients and the server is encrypted using OpenSSL.

System overview

Hardware

As shown in figure -1- the system is composed of two main components: the front panel and the control server. The front panel is connected to the server via a USB link running through the wall.

Lobby Station

The main controller and the Android device are the two major components of the lobby station.

The main controller is a custom board with the atmega328p MCU running @ 8Mhz with 3V3 input supply. The board contains also the capacitive touch controller MPR121, USB-to-UART bridge (FTDI chip) and a DC-DC buck converter. The RFID reader is placed in the bottom left of the station while the OLED display is attached to the top left side. Both modules are connected to the main controller via a shared SPI bus.

The main features of the lobby station are :

Access control
Door bell
Video/Audio intercommunication
User interface

Android device

The Android device is an old Samsung j2 with a broken screen that I had laying around. A working LCD was used temporarily to configure and prepare the device for a headless operation. First I installed a lightweight and debloated ROM, the device was also rooted and developer mode activated.

The Android device acts as a client, and it’s connected to the server via TCP sockets for communication, and USB for configuration and control using ADB.

Control server

The control server is built around a Raspberry Pi 3. It contains all the electronics used for the control and monitoring of the system.

A PWM Fan controller was added later, along with a heatsink to ensure a better cooling after some CPU throttling was experienced during video-streaming tests.

The relay array is used to trigger the electric strike, ring a bell or turn on and off the door light. To add more redundancy, a multiplexer is added so that all these functions can be accessed using at least one of the three methods :

Over the network: using RPi’s outputs, the server can send control signals to the multiplexer.
ZigBee module: using a ZigBee remote controller, the module can control the outputs independently of the RPi or networks state.
Push buttons: physical push buttons are wired directly to the multiplexer. If everything else fails this option will always be viable.

Software

The project is implemented in two modules with a client-server architecture using Sockets to provide communication between them. The server side is running on the Raspberry Pi, the client side is an Android App

The Server :

Written in C++ and Qt, the server is a multi-threaded program responsible for managing and orchestrating every device, service and module in this solution.

The main features of the server are :

User management
Data logging
Error handling
WebRTC signalling
Remote configuration
Device management
BLE beacon
Geofence management

The Daemon :

Running as a Linux service, the daemon is responsible for initializing, starting and monitoring the server and the lobby station. In case of a software problem, the user can send through the app, a soft or hard reset. In case of a soft reset, the daemon will clean up the environment, backup files and restart the server and the firmware of the lobby station.

In extreme cases, a hard reset can be performed. The daemon starts by sending a reset signal to the atmega328 MCU, then sends a reboot command to the Android device via ADB. Then it reboots the Raspberry Pi.

The Clients :

Three Android apps were developed, the lobby station, monitoring and user client app, sharing the same base code with slight modifications for each usecase.

User App: optimized for Doze and Standby modes. it uses “short-polling” TCP sockets, where the client repeats a request for new events in a stream, while the server vends a single or a series of events that happened since the last request. When the system decides to put the device in Doze mode or the app to idle state, Firebase Cloud Messaging (FCM) is used instead.
Monitoring App: offers the same features as the user app with the particularity of it being optimized for high availability and responsiveness. The main process is running as a foreground service, preventing the OS from closing or putting it to the idle state. The other specificity of the lobby app is that it uses TCP sockets to communicate with the server. The sockets are kept alive the whole time, and polled indefinitely for new data.
Lobby station App : designed to be used in headless mode, the app is also running as a sticky foreground service, and implements other particular features, such as, taking a picture of the person ringing the doorbell, uploading it to the server, playing sounds (doorbell,touch,…) and allowing remote configuration of some of its properties (Video quality, FPS, Audio filters, …)

Firmware

The firmware is written using C++ and Arduino’s core library. The bootloader was not used to reduce the memory usage and boot-up time.

To ensure a good responsiveness of the user interface, the touch controller, UART and RFID reader uses interrupt requests (IRQs). The main loop is used mostly to update the OLED screen and play graphical animations. Adafruit GFX library was used and slightly modified to play simple animations.