Final_Report_-_Smart_Door_Lock

More people are looking for smart home security solutions such as keyfree locks, biometric fingerprint locks and smart locks that work with Amazon Alexa or that can be controlled by an app. KLS Locks are experienced in installing smart home security products and can advise you on their suitability for your own property.
About KLS Locks

KLS Locks is a local Orpington locksmith also covering Chislehurst, Swanley, Petts Wood, Bromley, St Mary Cray, St Paul’s Cray, Sidcup, Beckenham, Penge, Crystal Palace, South Norwood and Sydenham.
smart locks lock replacement Door user Lock system Door Lock Raspberry Pi app
MQP MXC - 0580 
 
 
Smart Door Lock 
 
 
 
MAJOR QUALIFYING PROJECT 
Submitted to the Faculty of  
WORCESTER POLYTECHNIC INSTITUTE 
in partial fulfillment of the requirements for the  
Degree in Bachelor of Science 
 
 
 
Authors:                                                                                                                                  
 
Aleksander IBRO 
Augusto WONG 
Mario ZYLA 
 
 
 
 
April 28, 2019 
 
 
 
 
 
 
 
 
 
 
This report represents work of WPI undergraduate students submitted to the faculty as 
evidence of a degree requirement. WPI routinely publishes these reports on its web site 
without editorial or peer review. For more information about the projects program at 
WPI, see http://www.wpi.edu/Academics/Projects. 
Project Advisors: 
 
Michael CIARALDI 
Maqsood MUGHAL 
 
 
i 
 
 
 
 
Abstract 
Smart Door Lock 
Major Qualifying Project 
 
The goals of this project were to build  a modern, easy-to-use, smart 
door lock that allows for accessible unlocking and adds convenience, 
utility, and security to your home. It allows users to open their door 
remotely via the accompanying Smart Lock mobile app, or hands-free  
by using face recognition via a camera mounted on the door. The system 
was made up of three major components, including a cloud back-end, 
an on-board logical unit, and a mobile application. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ii 
 
 
 
 
 
Acknowledgments 
 
We thank our MQP advisors professors Michael Ciaraldi and Maqsood 
Mughal for guiding us throughout the project, and for their great 
flexibility on agreeing to make this project an actual MQP. 
 
 
 
iii 
Executive Summary 
The goal of this project was to provide an easy and convenient method for unlocking a front door 
by removing the need for the old-fashioned key. We start by evaluating the need for such a system 
by sending a survey and analyzing the results. We follow the Software Development Life Cycle 
to set the project objectives and implement the design. The project has three main components: 
a Raspberry Pi, a cloud backend, and a mobile application. The Raspberry Pi is attached to the 
door and is responsible for controlling a servo motor, a camera, and an actuator. Users can open 
the door by either tapping a button on the mobile app, or just by approaching the door. When a 
user is within a certain radius, a PIR sensor detects them, and activates the camera. The 
Raspberry Pi then sends an image of the user at the door to the backend server.  
 
The server is a Python Flask application hosted in Azure Cloud Services. It seamlessly runs a 
face recognition library, which compares each image sent by the Raspberry Pi with images 
already uploaded in the Cloud. If the face recognition algorithm identifies a face in that image, it 
automatically sends a positive response to the Raspberry Pi, which in turn activates the actuator 
and opens the door. The Azure backend is also responsible for serving requests coming from the 
mobile application, like storing images of users’ faces, tapping a button to open the door, or saving 
each user’s personal information. Azure App Services is a feature of Azure, which makes it easy 
to quickly deploy a cloud application.  
 
The Smart Lock app is the forefront of the system, providing an intuitive User Interface. From this 
app, users can not only manage their accounts, but also add friends and family by simply providing 
their names and photos of their faces. Once a friend is added, the face recognition library will be 
able to identify them, and, if provided with access by the user, automatically unlock the door via 
the Raspberry Pi. To make sure that you don’t have unexpected guests, you can pick the days 
and times that your friends can get in. You can also opt in for a push notification that will let you 
know whenever someone is at the door. From the Smart Lock app, users have access to a 
livestream of their front door. This feature allows users to let their guests in with a simple tap of a 
button, even if these guests haven’t been added beforehand. Furthermore, users can keep track 
of everyone using the system with a dedicated view that shows every action performed on the 
door, including the time and day of the action, as well as the person performing it. 
 
Our project integrates a board computer like the Raspberry Pi, a Cloud backend provided by 
Microsoft’s Azure, and a mobile application built in Swift. These three components come together 
to create a seamless and convenient way for you and your family to control the doors of your 
home. Now you don’t have to worry about losing your key, getting locked out, or having your 
hands full with groceries, because the Smart Lock system has you covered. 
 
 
 
 
 
 
 
iv 
Table of Contents 
Abstract 
i	
Acknowledgments 
ii	
Executive Summary 
iii	
Table of Contents 
iv	
List of Figures 
vi	
List of Tables 
vii	
1	 Background 
1	
1.1	
Internet of Things 
1	
1.2	
Access Control Credentials and Readers 
1	
1.2.1	 Keypads 
2	
1.2.2	 Access Cards and Card Readers 
2	
1.2.3	 Biometric readers 
2	
1.3	
Smart Door Locks 
3	
1.3.1	 August Door Locks 
3	
1.3.2	 Kwikset Kevo Locks 
4	
2	 Methodology 
5	
2.1	
Introduction 
5	
2.2	 Why We are Choosing this Strategy 
5	
2.3	
Requirements Gathering 
5	
2.3.1	 Survey 
6	
2.4	
Analysis 
6	
2.5	
Design 
6	
2.5.1	 Platform Choice - Mobile Websites vs. Mobile Applications 
7	
2.5.2	 Platform Choice - iOS vs. Android 
7	
2.5.3	 Platform Choice - Raspberry Pi vs. Arduino 
8	
2.5.4	 Platform Choice - Motion Sensor Ultrasonic vs PIR 
10	
2.5.4.1	 Ultrasonic Sensor 
10	
2.5.4.2	 PIR Sensor 
10	
2.5.5	 Platform Choice - Actuator 
11	
2.5.5.1	 Pneumatic Actuators 
11	
2.5.5.2	 Hydraulic Actuators 
12	
 
v 
2.5.5.3	 Electric Actuators 
12	
2.5.6	 System and Object Design 
13	
2.5.6.1	 UML Class Diagrams 
13	
2.5.6.2	 Components Diagrams 
14	
2.5.6.3	 State Machine Diagrams 
14	
2.6	
Implementation and Testing 
15	
2.6.1	 First Component - Smart Lock App 
16	
2.6.2	 Second Component - Raspberry Pi 
17	
2.6.3	 Third Component - Cloud Backend 
19	
2.6.3.1	 Azure Virtual Machine (VM) in the Cloud 
19	
2.6.3.2	 Azure SQL Database 
20	
2.6.3.3	 Azure App Services 
21	
2.6.3.4	 Google’s Firebase Authentication 
21	
3	 Results and Conclusions 
22	
3.1	
Future Work 
22	
Appendix A: User Manual 
23	
Getting Started 
23	
Adjust your Settings: Account Tab 
23	
Who is at the door: Home Tab 
24	
Add Friends: Guests Tab 
25	
Add Admins: Guests Tab 
26	
Check who has been at your door: Activity Tab 
27	
Appendix B: User Stories 
28	
Appendix C: Survey Results 
29	
Bibliography 
31	
 
 
 
 
 
vi 
List of Figures 
 
Figure 1.1 Keypad Access Reader ..................................................................................2	
Figure 1.2 Card Reader ...................................................................................................2	
Figure 1.3 Biometric Reader ............................................................................................2	
Figure 1.4 Activity View for August App ...........................................................................3	
Figure 1.5 August Door Mount .........................................................................................3	
Figure 1.6 Kwikset Kevo Lock ..........................................................................................4	
Figure 2.1 Software Development Life Cycle Phases ......................................................5	
Figure 2.2 High-level class diagram of the Smart Lock main objects .............................13	
Figure 2.3 Components Diagram ...................................................................................14	
Figure 2.4 State Machine Diagram for the Smart Lock system mounted on the door ....15	
Figure 2.5 The three main components of the Door Lock System .................................16	
Figure 2.6 Electrical Schematic of the Smart Door Lock device ....................................18	
Figure 2.7 The “upload_image” route that runs in the Flask server when an image is 
sent from RPi .................................................................................................................20	
Figure 2.8 Entity Relation Diagram for the app ..............................................................20	
Figure 2.9 Comparison of adding a new Friend to the DB using the Flask Server (left) 
and using the App Services (right). The Flask server code (bottom left) is completely 
gone after migrating to App services..............................................................................21	
Figure 3.1 Smart Door Lock system mounted on a mockup door ..................................22	
 
 
 
 
 
 
 
 
 
 
 
vii 
List of Tables 
 
Table 2-1 Comparison between a website and a mobile app [11] ...................................7	
Table 2-2 A Comparison of React Native Pros and Cons [12] .........................................8	
Table 2-3 A comparison between Raspberry Pi and Arduino Uno [13] ............................9	
Table 2-4 A comparison between an ultrasonic and a PIR sensor ................................11	
Table 2-5 A comparison among a pneumatic, hydraulic, and electric actuators ............12	
Table 2-6 Smart Lock App features submitted in proposal. Underlined features were not 
implemented ..................................................................................................................16	
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 
1 Background 
In this chapter, we begin by introducing the Internet of Things, continuing with a discussion of the 
inclination people have shown toward IoT devices, and how different door access control systems 
have adhered to or missed the population’s needs. We show examples of some products 
designed to offer a much needed convenience to door lock systems.  
1.1 
Internet of Things 
In the last few years, the Internet of Things (IoT) has attracted attention from both academic and 
industrial worlds. IoT is a concept describing a vision in which everyday objects are connected to 
the Internet, are identified, and communicate with other devices [1]. These interconnected devices 
are referred to as smart devices. Each of these smart devices is a physical component with 
communication functionality, possessing a unique identifier, some basic computing capabilities 
and a way to react to different physical phenomena around them [2]. From a global IoT market 
perspective, the population of IoT devices will reach about 26 billion by 2020, up from only 900 
million in 2009 [2]. 
 
The most common examples of smart devices are wearables like watches. Smart watches such 
as the Apple Watch and Fitbit have penetrated the market not very long ago. Such devices have 
also entered our homes with products such as Amazon Echo, a voice assistant, which users can 
talk with to play music, provide weather, and control other IoT devices. A less common example 
can be seen in Barcelona, where the city has implemented some IoT initiatives that have helped 
enhance smart parking [3]. 
  
An exponential growth is expected for the IoT market and an increasing number of smart devices 
show the inclination of the industry toward offering these interconnected solutions to increase 
convenience, but also the high adoption rate of the population [4].  
1.2 Access Control Credentials and Readers 
We have researched a few access control methods that are currently being used around the 
world. In this section, we will explain three of the most prevalent types, focusing on their 
advantages and disadvantages. 
 
2 
1.2.1 Keypads 
The most basic types of ID readers are keypads, based on simple 
twelve-digit keypads, containing the numbers 0-9 and a * and # sign 
[5], shown in figure 1.1. These types of access control locks are very 
simple and cheap, and over time they have advanced to include some 
more secure functionality, like scrambling the LED number keys on 
the keyboard so that others who can detect the gesture and 
movement wouldn’t be able to use it. The main disadvantage include 
people’s need to share the code, like with package or food delivery or 
friends. If people share this code, you can’t really know how many 
people have access or  who accessed the keypad at what time.  
 
1.2.2 Access Cards and Card Readers 
There are a number of different card reader types. Some 
common ones include magnetic stripes, barcode, etc. 
Magnetic stripe cards have a magnetic band laminated to the 
back of the card [5]. The card can contain a code, which 
serves for identification, the person’s name, and other useful 
data, although only the ID code is commonly encoded.  
ID cards are effective, simple to build, and cheap, but they 
are very easy to duplicate. Other types of ID cards work in a 
very similar way to magnetic stripe cards.  
 
1.2.3 Biometric readers 
Any device that reads the identity of a person by comparing some 
attribute of their physiological being or behavioral traits against a sample 
database is called a Biometric Reader [5]. Some common biometric 
readers include facial recognition, fingerprint, and iris recognition. 
Advantages of biometric readers include increased security and 
convenience of not carrying a key or card. Disadvantages include the 
need to enroll users in a database by providing sufficient samples of 
user’s face (for facial recognition) or fingerprint (for fingerprint scanners). 
Some modern day inconveniences include users who try to fool these 
systems. A common example is how facial recognition systems can be 
fooled by high-quality photos of user’s face, even without the user being 
present [6]. 
 
Figure 1.1 Keypad 
Access Reader 
Figure 1.2 Card Reader 
Figure 1.3 Biometric 
Reader 
 
3 
1.3 Smart Door Locks 
The idea behind the modern day smart locks is to unify the functionality provided by convenient 
and secure access control methods with the convenience of internet connectivity and remote 
control. There are a few products on the market that offer these systems and we will talk about 
two of them, once again focusing on the features they offer and potential disadvantages, as these 
products will serve as inspiration for our actual product implementation. 
1.3.1 August Door Locks 
PCMag has rated the August door locks as one of the best smart door lock systems [7].They offer 
a mobile application, where you can check an history of the activity, like who locked or unlocked 
it at different times, shown in Figure 1.4.  From the mobile app, you can also  
                     
 
grant unlimited digital keys to different friends. The hardware installed on the door, shown in figure 
1.5 can also indicate whether the door is completely closed or not. Different versions with a range 
of prices are offered. Some of the higher-end versions include a camera for users to see who is 
at the front door and whether they want to unlock the door for them. Whomever you share the 
Figure 1.4 Activity View 
for August App 
Figure 1.5 August Door Mount 
 
4 
code with needs to have the mobile application in order for the sensor in the lock to detect them 
when they are close [8]. 
1.3.2 Kwikset Kevo Locks 
Kevo locks, shown in figure 1.6, are another 
brand of door locks highly rated by PCMag 
[7]. They offer similar features, but to unlock 
the door they use a     digital keypad. Each 
user has its own access                          
code, so the lock’s accompanying mobile 
application can give a history of the lock’s 
activity. For friends or temporary users 
needing to access the house, you can easily 
send a new access code and assign the time 
period for the temporary user to access the 
lock [9].Since every user needs to use an 
access code to unlock the door, you can’t 
unlock via proximity to your phone. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figure 1.6 Kwikset Kevo Lock 
 
5 
2 Methodology 
2.1 
Introduction 
The main goal of this project was to design and build a door lock system that allows users to 
unlock a door via face recognition, through a camera implanted on the door. In this methods 
chapter, we will discuss how we detailed the process of implementing this mechanism. We started 
our research by confirming the need of potential users for such a system and then followed a 
modified version of the Software Development Life Cycle (SDLC) approach to design and build a 
door lock system. 
2.2 Why We are Choosing this Strategy 
SDLC is a strategy that is used to ensure that products that are developed, are optimized for their 
users, based on a set of requirements. It is a very common strategy in software development 
projects. SDLC involves several steps shown in Figure 2.1: Requirements Gathering, Analysis, 
System Design, Object Design, Testing, and Implementation. Each step ensures that the 
developers are ready for the next one and the approach tries to minimize the development time 
by having predefined expectations for each step. By following this process, the developers ensure 
that their finished product actually meets and addresses the needs of their users.  
2.3 Requirements Gathering 
The objective of this step is to obtain information about the potential need for such a door lock 
system as described in Section 2.1. Before we designed a solution to an acknowledged problem, 
we needed to know the specifics of user behaviors, which would especially help in designing the 
Figure 2.1 Software Development Life Cycle Phases 
 
6 
features of our mobile application. Our background research indicated that smart locks are 
becoming a trend, but there is little research into: 
1. What is the most common nuisance of all the traditional door lock systems 
2. Whether people are ready to switch to a digital smart lock, completely controlled by their 
smartphones and with authentication based on facial recognition 
2.3.1 Survey 
Most of the motivation behind this project came from our own experience with traditional door 
locks and their inadaptability to the changing habits of modern time. Our first step involved 
discovering if others share the same experience with their door locks and inquiring about other 
potential issues that we had missed. The best way to get a quick idea into a potential problem 
was to survey people of our age about their habits. This provided some quick feedback which 
helped with the initial system and mobile application design. It also helped us in choosing a 
development platform: smartphone vs. computer vs. tablet; iOS vs. Android; etc. 
 
The results from the 123 responses of our initial survey were very useful. The full scope of the 
answers can be found in Appendix C. Here were four of the most important observations: 
1. Around 90% of people needed to physically go to the door whenever they had a visitor 
2. A smartphone was people’s preferred way to possibly unlock a door remotely 
3. 50% of the people surveyed always or often find themselves with their hands full while 
trying to reach for the key to open a door 
4. Around 65% of the people surveyed used an iOS device as their primary mobile device 
2.4 Analysis 
During analysis, developers aim to produce a model of the system that is correct, complete, 
consistent, and unambiguous [10]. From the initial survey we created user stories, use cases, and 
UI mockups that we then discussed with the team and project advisors. A complete set of user 
stories can be found in Appendix B. During the analysis phase, we ensured that there was no lack 
of understanding particular needs or possible features of the system we were building. 
Furthermore, by prioritizing requirements, we needed to create a scope of the project that should 
consider what we could build in the available time. Our analysis included: 
1. a set of user stories created from requirement gatherings that will later turned into 
features of the application 
2. Use cases, describing the system functionality from the user’s point of view 
3. UI Mockups, describing how each feature will look like on a screen 
2.5 Design 
This step of the Software Development Life Cycle process is concerned with the methodology 
behind creating an effective platform that is useful and appealing to our target population. This 
section starts with comparing a few software platforms and our reasoning on deciding to develop 
a mobile application for iOS, our reasoning for choosing Raspberry Pi as our on-board logical unit, 
and the methodology behind turning the system requirements into small building blocks.  
 
7 
2.5.1 Platform Choice - Mobile Websites vs. Mobile Applications 
Websites and mobile applications are the two main ways of delivering a digital platform to a target 
audience. Before we started to design our features based on the needs of the surveyed 
community, we needed to decide on the most effective and useful platform for the targeted users. 
Table 2.1 gives a summarized comparison between these two basic methods. 
 
Table 2-1 Comparison between a website and a mobile app [11] 
Website 
Mobile App 
+ Easier to develop, websites are 
compatible across devices.  
- More variability in development, because 
of different phone systems, types and 
operating system versions.  
+ Easier to maintain. 
- Difficult to maintain, because of 
manufacturer’s constant system 
upgrades. 
+ 
Instantly available, by providing the URL. 
- Need download from respective 
application store first.  
+ Broader reach because they are instantly 
available and compatible across devices.   
+ Personalization - If target users have 
personal information and usage, then 
an app offers better experience, 
including push notifications 
 
- No push notifications 
+ Push notifications for real-time user 
response and information 
- Less integration with specific device 
resources.  
+ Easier access to device resources, like 
GPS or camera sensors.  
- Relies on an active internet connection.  
+ Offline access. 
 
 
Table 2.1 offers a good summary of the most important advantages and disadvantages of each 
method, but we could only make a decision by factoring in our system interactions. For example, 
having interactive push notifications is necessary for our needs, so that the user can easily see 
who is at the door and open it with a single tap. Furthermore, easier access to device resources, 
like GPS and camera, is integral to our needs. The bolded points in the table above are the ones 
that helped us ultimately make the choice between a website and a mobile application.  
2.5.2 Platform Choice - iOS vs. Android 
A very important development decision was whether to create an app for an iOS or Android 
platform. There are software solutions that provide the ability to write and maintain a single code 
base for both iOS and Android. React Native is such a tool. We have compiled a list of pros and 
cons for using React. 
 
 
8 
Table 2-2 A Comparison of React Native Pros and Cons [12] 
React Native Pros 
React Native Cons 
+ Mostly write a single code base 
- 
Still need to maintain parts of Objective-C 
(iOS) and Java (Android) code base, as 
not everything translates properly 
+ React uses JavaScript, which is fast and 
popular 
- 
Lack of documentation, as it is a young 
platform 
+ Uses Native modules whenever it can, 
which translates into fast and seamless 
experience 
- 
Lack of third-party community-built 
components, which cannot be guaranteed 
to work in next OS releases 
+ Great for quick UI design 
- 
Still in development: Instability, 
compatibility issues, and errors 
 
Although we wanted both an Android and iOS app, as that would increase our product’s exposure 
and the speed of adoption, if it ever goes to market, React Native did not sound like a safe choice, 
considering especially our lack of experience with the tool and all the potential instabilities, 
particularly with third-party component integration. As we can’t develop our app for both platforms, 
we made sure to include a question on the survey about what platform each of our respondents 
uses. The mobile OS with the most votes was iOS and that is why iOS is our platform of choice.   
2.5.3 Platform Choice - Raspberry Pi vs. Arduino 
For the purposes of our systems, a computational device is required. This device needed to fulfill 
a series of requirements, which we divided in three separate categories, Development, Network 
connectivity, and physical ports. Each of the following conditions have been defined based on the 
system that makes the features of our platform possible with the most convenient development 
environment.  
The three development requirements that we looked into were as below: 
● Ability to run a scripting language 
● Extensive community support 
● Availability of documentation 
 
The development requirements were essential to successfully achieve the project goals in time 
and to create a platform that can be easily maintained. A device that uses a scripting language 
such as Python will allow the integration of multiple subsystems that are required in our product. 
Having to work with cloud systems, a camera and different types of motors, makes a scripting 
language the most favorable choice. Because this device will be the controller for almost every 
component in our platform, good documentation and support will make the development 
significantly easier. 
The three Network and Connectivity requirements that we looked into were as below: 
● On-board WiFi connectivity 
● On-board Bluetooth connectivity 
● Ethernet connectivity  
 
9 
 
Because the system needed to connect to cloud services to process the authentication of a user 
and their device, as well as video streaming, network and wireless connectivity stand at the core 
of our product requirements.   
The two I/O ports that we thought of as crucial were as below: 
● A port for the camera connection 
● Ports for motor connection 
 
With the implementation of camera to provide a live feed of the door view and motors to operate 
the lock and the door itself, the computing device needed to be able to operate all the hardware 
that make these functionalities possible.  
 
After determining the requirements for the computational device, a market and specifications 
research was conducted. A few products from popular providers such as Raspberry Pi and 
Arduino were taken into consideration. Table 2.3 offers a side-by-side comparison between the 
specifications of the most popular microcontrollers in the market.  
 
Table 2-3 A comparison between Raspberry Pi and Arduino Uno [13] 
Raspberry Pi 3 
Arduino Uno 
 
 
Stronger and quicker processor, multitasking 
available 
Can run one code at a time, so can't multitask 
activities, slower speed 
Built in Ethernet port, Wi-Fi and Bluetooth 
capability 
No internet connectivity (requires shield or module) 
 
OS can be switched easily, scripting language 
used (Python) 
Bigger learning curve since it uses C/C++ language 
and need outside sources 
Audio output, Camera port, USB ports, HDMI 
output included 
Requires shields to implement most of the I/O 
devices 
 
10 
Requires installation of programs to get simple 
actions going 
Easier to connect to analog sensors, motors and 
other electronic components 
 
From the comparison of the features offered from the Raspberry Pi and the Arduino boards, we 
determined that the Raspberry Pi, unlike the Arduino, is more suitable for projects that involve 
several functionalities at the same time, need easy access to the internet, and need media 
accessibility. On one hand, the Arduino fits better in projects that require easy reads from sensors 
and have to do operations based on the data, while being able to communicate easily with a 
variety of motors or machine parts. However, this board does require extensions in the form of 
shields, to expand on features that are required to accomplish this project. Therefore, the 
Raspberry Pi was the most suitable board for our system. 
2.5.4 Platform Choice - Motion Sensor Ultrasonic vs PIR 
To automate the operation of the door lock system a motion sensor is required. The sensor is 
used to detect any activity that will be happening in front of the door, like a person approaching 
it. Therefore, the sensor required has to be able to detect movements within a reasonable 
controlled area. The detection range needs to be limited to prevent the system from being 
triggered by background activity.  
2.5.4.1 Ultrasonic Sensor 
An ultrasonic sensor is generally used to measure the distance of an object using sound waves. 
The sensor consists of a transmitter and receiver pair. The distance can be measured by taking 
into account the elapsed time between the sound wave being generated and the sound wave 
bouncing back to the receiver [14]. 
2.5.4.2 PIR Sensor 
Passive Infrared Sensors are made of pyroelectric sensors, which can detect levels of infrared 
radiation. Everything radiates some low level of radiation. However, the hotter the object is, the 
more radiation is emitted. The sensor in a motion detector is split in two halves in order to detect 
change between the two. The two halves work with each other by cancelling out normal IR levels 
in the background. When one half detects more IR radiation than the other, the output will swing 
high or low, therefore detecting motion . The heat released of the human body is enough to trigger 
this sensor, making it one of the most commonly used in security and lighting appliances [15].  
 
Table 2.4 provides a side by side comparison between the Ultrasonic and PIR sensors. By 
comparing the characteristics of each sensor type it was determined that the PIR sensor is more 
suitable for our product because of its higher accuracy in the types of environment it will be 
exposed to, as well as the wider detection angle.  
 
 
 
 
11 
Table 2-4 A comparison between an ultrasonic and a PIR sensor 
Type 
Ultrasonic 
PIR 
Image 
 
 
Range 
2-400 cm 
2.2 m 
Angle 
30 degrees 
90 degrees for 1 m/s  
44 degrees 0.5 m/s 
Type of Info 
Time that can be converted to distance HIGH, LOW 
Price ($) 
3.95 
12.62 
 
2.5.5 Platform Choice - Actuator 
The implementation of such a door lock system involved some mechanical engineering in order 
to make the door adaptable for people with disabilities and to offer the feature of fully opening and 
closing the door via commands from the mobile application, or just by approaching, i.e. hands-
free. In order to achieve this functionality, we used an actuator. There are many different types of 
actuators and during the design phase of the project we decided which one is the most appropriate 
for our needs. Table 2.5 offers an overview of the advantages and disadvantages of each type of 
actuator we considered: pneumatic, hydraulic, and electric actuators. 
2.5.5.1 Pneumatic Actuators 
Pneumatic Actuators consist of a piston inside a hollow cylinder. Pressure from an external 
compressor moves the piston inside. With increasing pressure, a linear force is created that 
makes the cylinder move along the axis of the piston. The piston is then returned to its original 
position by either a spring or fluid being supplied to the other side of the piston [16]. 
 
12 
2.5.5.2 Hydraulic Actuators 
Hydraulic actuators consist of a cylinder or fluid motor that uses hydraulic power to facilitate 
mechanical operation. These are similar in operation to pneumatic actuators, but an 
incompressible liquid from a pump moves the cylinder [16]. 
2.5.5.3 Electric Actuators 
Electric actuators convert electrical energy into torque. Usually, their inside mechanism is 
constructed out of an electric motor that turns a lead screw. When the screw rotates, the nuts get 
driven along the threads. The nut moves depending on the direction the screw rotates [16].  
 
Table 2-5 A comparison among a pneumatic, hydraulic, and electric actuators 
Pneumatic 
Hydraulic 
Electric 
+ Simple and precise: a 
small pressure change 
can enable considerable 
forces (citation) 
+ High force, 25 times 
greater than pneumatic 
cylinders of equal size 
+ Precise and quiet: they 
generate linear motion 
within +/- 0.000315 
inches 
+ From ½ to 8 inches, with 
forces from 30-7500 lb 
+ Efficient, can hold force 
and torque constant 
without supplying more 
pressure 
+ Development: can be 
networked and 
reprogrammed quickly. 
Immediate feedback for 
diagnostics 
+ Cost effective ($50-
%150) 
 
 
- 
Low efficiency due to air 
pressure losses and air 
compression. Additional 
regulators and valves 
may be needed, raising 
the costs.  
- 
Leakage: this type will 
leak fluid, leading to 
maintenance issues  
- Difficulty holding a 
locked position 
- Maintenance: 
compressed air usually 
gets contaminated 
- Complex: they need 
many companion parts, 
including fluid reservoir, 
motors, pumps, release 
valves etc. 
- 
Expensive, price range 
from $150-$2000 
 
 
Table 2.5 offers an overview on the main advantages and disadvantages that we considered 
when picking our actuator. Based on our initial studies of the system model, we chose an electric 
actuator, as we believed it to be the right one for our use, particularly because of its very easy 
development setup and connection to our electrical components of the door lock system. 
 
13 
2.5.6 System and Object Design 
During this step, the analysis of requirements, as explained in section 2.4, are turned into well-
defined parts of the software. The goal of this step was to give the team all the resources needed 
to start implementing the system. The products of this step included a few different kinds of 
diagrams, which built upon the previously defined User Stories, Use Cases, and UI Mockups.  
2.5.6.1 UML Class Diagrams 
Class diagrams follow a clean object-oriented approach to software development [17], by clearly 
showing the classes of the system, their interrelationships, and the operations and attributes of 
the classes. We created a class diagram for the mobile application, which indicated the different 
objects of a Door Lock: Users, Administrators, Friends of each user, and a representation of the 
Door Lock itself. The high-level class diagram of our system is shown in Figure 2.2. It shows the 
most important objects in our mobile app: User, Friend, Smart Lock, and Activity. It also shows 
the relationships among these objects, e.g each User can add many Friends and each SmartLock 
can have many Activities associated with it. 
 
 
Figure 2.2 High-level class diagram of the Smart Lock main objects 
 
14 
2.5.6.2 Components Diagrams 
With the Components Diagrams the team could see the interrelations among all the components 
of our system: Door Lock, the on-board logical unit mounted on the door; Mobile App, running on 
a mobile device connected to the Internet; the Cloud: an OS running our software, which is 
responsible for authenticating faces and sending commands from the Mobile App to the on-board 
unit. An initial ideation of such a diagram is shown in Figure 2.3. 
 
 
2.5.6.3 State Machine Diagrams 
State Diagrams are particularly useful for complex components who can’t fully be represented in 
a Class Diagram. UML state machine diagrams depict the various states that an object may be in 
and the transitions between those states [18]. For our system, we are going to build a state 
machine diagram that indicates the different states of our on-board logical unit, which will run an 
algorithm that controls the state of the door based on commands from the mobile app or presence 
of a person next to the door. An initial ideation of a state machine diagram is shown in Figure 2.4. 
Figure 2.3 Components Diagram 
 
15 
 
2.6 
Implementation and Testing 
After Requirements Gathering, Analysis, and Design, there is the Implementation phase. In this 
step, the deliverable product was implemented. For the software part of our system, during this 
step, we translated the solution domain into source code, which included implementing the 
attributes and methods of each object and integrating all the objects such that they function as a 
single system [10]. For the hardware part of the system, during this step we implemented the 
state diagrams on a Raspberry Pi and connected the unit to the Cloud and paired it with a mobile 
application, from which it will receive commands. For the mechanical engineering part of our 
system, we used an electric actuator, modified it according to our needs by using 3D printed parts 
and installed it on a simple made-up door. This step took into account all previous design 
decisions we had made in precedent steps: tools like programming languages and face 
recognition software, platforms like mobile operating systems, and hardware choices like the on-
board logical unit. Most of these design choices should not be changing in this step, although 
minor improvements were needed. Whenever we had to change a considerable amount of the 
previously defined models, then we reiterated through all the steps of SDLC. In this section, we 
talk about the implementation of each of the three main components of our system, shown in 
Figure 2.5. We conclude with a subsection on how we connected all these components together. 
Figure 2.4 State Machine Diagram for the Smart Lock system mounted on the door 
 
16 
An important part of this section is our discussion on what changed from the submitted proposal 
and the reason behind the change. 
 
  
2.6.1 First Component - Smart Lock App 
Table 2.6 shows a set of features that we wanted the Smart Lock app to support. The “Must Have” 
column shows a set of features that we submitted on our project proposal. The column marked 
all the features that we deemed important at the beginning and that were very important for our 
application to have. The “Good to Have” features were also submitted in the proposal and the 
column marks all the features that we would implemented if time permitted. We underline all the 
features that we were not able to implement due to time constraints. 
 
Table 2-6 Smart Lock App features submitted in proposal. Underlined features were not implemented 
Must Have 
Good to Have 
Common UI/UX patterns, used in similar apps 
(familiar application design, for high 
adaptability) 
 
User personal account, including verification 
email and alternative sign up with a Facebook 
or Google account 
Support for Admin level - admin users can 
add/remove other normal access users 
Open/Close and Lock/Unlock door 
commands 
 
Livestream of the camera in the door lock 
Speaker and Microphone - for communication 
with different visitors while they are at the 
door 
Figure 2.5 The three main components of the Door Lock System 
 
17 
Activity History - a list of events/commands 
accessible by the user 
 
Support for one Door Lock Device 
Multiple “Smart Door Lock” devices - ability to 
add multiple door locks to the same profile, 
for different doors inside the same residence 
or other residences 
Friends - list of people with moderate access, 
as defined by the user 
 
Push Notifications - informational notifications 
about people being at the door 
Ability to open/close and lock/unlock doors 
right from the notification, without opening the 
app 
 
Table 2.6 clearly indicates that were able to implement all the “Must Have” features, while also 
providing support for Admin level, a “Good To Have features”. For a detailed description of what 
each features does and how to use it, see the Smart Lock User Manual in Appendix X. In the User 
Manual, we also provide screenshots of the app indicating each feature. 
 
As our survey indicated (Appendix C), 65% of our surveyed population indicated that they use an 
iOS device, which is why we chose iOS as our mobile platform, as explained in Section 2.5.2. 
The app was developed in Swift 4, using the XCode development environment. For the full mobile 
app code, see Appendix D. 
2.6.2 Second Component - Raspberry Pi 
The Raspberry Pi was our on-board logical unit of choice, as explained in Section 2.5.3. The RPi 
is responsible for the below functionalities: 
 
1. Control the servo motor and actuator via commands coming from the mobile app 
2. Check the PIR sensor for movement and using the camera to snap a picture of the person 
who is at the door, whenever one is detected 
3. Send the picture to the Cloud and receive response: if a positive one, control the servo 
and actuator to unlock and open the door 
4. Easily connect to an available Wi-Fi connection in a user-friendly way 
 
Figure 2.6 shows how each electrical component is connected with the RPi. 
 
 
18 
 
Figure 2.6 Electrical Schematic of the Smart Door Lock device 
An important issue that we faced while working with the Raspberry Pi was finding a user-friendly 
way to get the Raspberry Pi connected to a certain user’s home Wi-Fi connection. We solved this 
by designing the RPi in such a way that whenever it started for the first time, it would try to connect 
to a mobile device via Bluetooth. On the phone’s side, the Berrylan app (cite Berrylan) would 
make sure to detect the open Bluetooth connection. Once a user connects to the RPi’s Bluetooth 
using BerryLan, which is easily available in the App Store, the user can manually choose their 
SSID and type in their home Wi-Fi password, which in turn get sent to the Raspberry Pi. Once 
the RPi connects to the provided SSID, it shuts down the Bluetooth connection and starts 
communicating with the Azure Cloud. For a closer look at how BerryLan connects the RPI to Wi-
Fi, see the Smart Lock User Manual in Appendix A. 
 
In order to satisfy all of the objectives above, we wrote a Flask server in Python which starts just 
in the moment the Raspberry Pi turns on. The Flask Server activates all of the components. The 
way a Flask server is written in Python is by providing different “routes”. To hide the dynamic IP 
changes, we used a service called No-IP (cite no-ip), which let us assign a hostname to the RPI. 
Throughout the project, instead of using the IP address for requests sent to the RPi, we used that 
assigned hostname. Each route in a Flask server corresponds to the appendix of each URL. For 
example, in a request sent to RPi with the URL “http://doorlockmqpboard.ddns.net/open_door” 
the “open_door” route, with the Python function that follows it, will run. For the full Flask server 
 
19 
code running on the RPi, see Appendix D. The routes are called from the Smart Lock app via the 
respective buttons to unlock and open the door. 
 
The PIR sensor on the Raspberry Pi is always active. It is facing the outside of the door and it 
waits to detect a close-range movement. Once the movement is detected, the PIR sensor delays 
any other execution, until the person has stopped moving. At that point, the camera takes a 
snapshot and sends the image to the Cloud VM, another Flask server with a specific URL. The 
Cloud responds back with either a negative identification, i.e the person is not added to the system 
and the face wasn’t recognized, or a positive identification, i.e. the person is known and the 
system should let them in.  
 
If we detect a positive response, then the RPi activates the servo to unlock the door and right 
after that it activates the actuator to fully open the door. Once the door is opened, after an 
adjustable delay, the door automatically closes and locks when it has fully done so. 
2.6.3 Third Component - Cloud Backend 
For our cloud services provider we chose Microsoft’s Azure. The Azure backend was made up of 
three different parts: the Virtual Machine in the cloud, the SQL database, and the App Services 
platform, and we discuss each part in detail in the following sections. For user login and account 
management, we used Google’s Firebase Authentication. 
2.6.3.1 Azure Virtual Machine (VM) in the Cloud 
The first step into building our backend was to create a Linux VM hosted by Azure in the Cloud. 
We created the Linux VM using Azure’s default parameters. This VM was designed to be an 
always running system, and once it starts, it hosts a Flask server. This Flask server is set up 
similarly to the one in the Raspberry Pi (see Section 2.6.2), but the routes look different and they 
provide different functions. The main responsibility of this Flask server is to run the face 
recognition software and identify each picture uploaded by the Raspberry Pi of the person who is 
at the door, by comparing it to all the other pictures uploaded in the system. 
 
Whenever a user logs in, the app contacts the Flask server and grabs all the pictures of a user’s 
added friends and loads them into the app. These pictures are stored locally in the VM. 
 
Whenever the Flask server gets a request from the Raspberry Pi, it compares the pictures to all 
the ones added for the requesting device, and it sends back a positive message if it can identify 
the user in the picture, or a negative one if it cannot identify a user’s face. The Flask server is also 
responsible for sending a push notification to the user’s logged in and paired with the specific 
device. The push notifications can let users know that someone is at the door. Figure 2.7 shows 
the complete workflow of the “upload_image” route of this Flask server, which is the main route 
that serves the Raspberry Pi. 
 
20 
 
2.6.3.2 Azure SQL Database 
Another Azure service that we use is the provided SQL database. All of the information for the 
class objects, i.e. User, Admin, Friend, and Activity is stored in the SQL database, excluding 
Compare to 
uploaded 
images 
Image coming 
from RPi 
Face 
recognized 
Send positive message to RPi 
Send push notification with name of 
person: “Mario is at the door” 
Send negative message to RPi 
Send push notification with no name: 
“Someone is at the door” 
Face unrecognized 
Negative message to RPi, no push 
notification 
No face in the image 
Figure 2.7 The “upload_image” route that runs in the Flask server when an image is sent from RPi 
Figure 2.8 Entity Relation Diagram for the app 
 
21 
pictures, which are stored locally in the VM. Figure 2.8 shows an ERD of the database we 
implemented. 
2.6.3.3 Azure App Services 
App Services is an Azure tool that offers a backend for mobile apps, allowing quick development 
and deployment [19]. Initially, our cloud backend was provided by the Flask server, over HTTP 
requests to the SQL database. We realized this was very slow and not secure, as the it was over 
HTTP, which is why we migrated to Azure App Services. This allowed a quick connection via a 
token from the app to the SQL DB, thus avoiding request handling by the Flask server. Figure 2.9 
shows the difference in the requests between requests being handled by the Flask server and 
requests being handled by App Services. 
2.6.3.4 Google’s Firebase Authentication 
We wanted to provide the users of the Smart Lock app with an efficient and secure way to create 
and access their accounts. Google Firebase offers authentication services and provides a secure 
way, which avoids the need for us to write code for password management. It also offers users 
the ability to stay logged into the app and not have to log in every time they launch the app. 
 
 
Figure 2.9 Comparison of adding a new Friend to 
the DB using the Flask Server (left) and using the 
App Services (right). The Flask server code (bottom 
left) is completely gone after migrating to App 
services. 
 
22 
3 Results and Conclusions 
Our MQP team successfully implemented a Smart Door Lock system with a seamless integration 
of a cloud backend, an on-board logical unit like the Raspberry Pi, and a user-friendly mobile 
application. All of the features initially proposed, except for a Facebook login, were implemented 
and tested, including some extra ones, as explained in Section 3.6. We made sure that the 
requests and users’ information is secure by using Microsoft’s Cloud and their App Services tool. 
We were able to build a mockup as a door system, using some wooden platforms and WPI’s 3D 
printers. Figure 4.1 shows an image of the finished Smart Lock system mounted on the mentioned 
platform.  
 
 
3.1 Future Work 
Limited by the available time and the complexity of integrating all three components of our system, 
we were not able to implement most of the proposed “Good to Have” features, as shown in Table 
3.6. Out of all “Good to Have” features, we believe that the most important one to be implemented 
in the future is adding support for multiple Smart Lock systems. Although our backend is set up 
for this support, the mobile app and the Raspberry Pi Flask server do not support such a feature.  
 
Another major feature would be the addition of a microphone and speaker on the outside of the 
door, right next to the camera. This feature would allow visitors to communicate with users, in 
cases when they don’t recognize the person visiting.  
 
Figure 3.1 Smart Door Lock system mounted on a mockup door 
 
23 
Appendix A: User Manual 
Getting Started 
In order to use the application you will need to  first create an Account. 
1) Click the “SIGN UP” button 
2) Fill all the required information, and click the “SUBMIT” button. 
3) Check your email inbox for a verification email in order verify your email address 
 
 
Adjust your Settings: Account Tab 
 
Once you have created an Account and you have successfully login, you should update your 
Account picture in order for the door lock system to recognize you when you are at the door. This 
can be easily done in the Account tabs, which is the leftmost tab, by clicking on the temporary 
image and then taking a picture of yourself. At the Account tab, you can also update your name, 
email address and password. Lastly, you will be able to sign out from the application, by clicking 
the “SIGN OUT” button. 
1. Click on the leftmost tab in order to access your Account information 
2. Click on the temporary Image in order to update your profile image 
3. You can click on Name, Email, or Change Password to update your information as 
needed 
4.  Click on the “SIGN OUT” button to sign out 
 
 
24 
 
 
Who is at the door: Home Tab 
At the Home Tab, the second left most tab, you will be able to see useful information with regards 
of your door system. At the top left corner, you will be able to see the current status of the door. 
Furthemore, If someone is at the door, you can click on the “Live” button, at the top right corner, 
in order to get a livestream from the door and thus see who is at the door. Once you are ready 
you can click on the “UNLOCK DOOR” button, and then click on the “OPEN DOOR” button to let 
someone inside. Once your friend is inside the house, you can click on the “LOCK DOOR” button 
and lastly the “CLOSE DOOR” to properly close the door system.  
 
1. Click on the “LIVE” button to get a livestream from the door.  
2. Click on the “OPEN DOOR” button to activate the actuator and open the door 
a. Then you will be able to click on the “CLOSE DOOR” button to activate the 
actuator and close the door 
3. Click on the “UNLOCK DOOR” button to turn the servo clockwise and unlock the door 
a. Then you will be able to click on the “LOCK DOOR” button to turn the servo 
counter-clockwise and lock the door 
 
 
25 
 
 
Add Friends: Guests Tab 
 
At the Guests tab, the second right most tab, you will be able to see and add new friends. These 
friends will have access to your door system on the selected days, from saturday to sunday, and 
you can decide if you would like to receive push notification from each of them. When you create 
a friend, make sure to take a good picture of their faces in order to guarantee that the door system 
will be able to recognize your friend when needed. As of now, there are no limits with regards on 
how many friends a user can have, so feel free to add as many as you want! You will be able to 
update your friend’s information by simply clicking a friend. Lastly, you can delete friends by simply 
swiping left on the desired friend to be deleted.  
 
1. Click on the “+” Button 
2. Click on the “FRIEND” option 
3. Fill the “New Friend” required information: Full Name, Access days, and profile picture 
4. Click on “SAVE” button to add your new friend.  
a. You can always click the “X” button to not add the friend.  
 
 
26 
 
Add Admins: Guests Tab 
 
At the Guests tab, you will also be able to see all the Admins for your door system by clicking on 
the “ADMINS” Button at the top of the screen. Admins are users who have an account with the 
Smart Lock APP. These admins, once added, can add new friends and request to delete other 
admin’s friends. These added friends, will have access to your door system as explained before. 
In order to add a new admin you will simply need to know their names in order to look them up in 
the database. Lastly, you can delete admins by simply swiping left on the desired admin to be 
deleted. 
 
1. Click on the “+” Button 
2. Click on the “ADMIN” option 
3. Click on the Search Bar and start typing the admin’s name 
4. Once you have found your desired admin click on the name and then click “OK” 
 
 
 
27 
 
 
 
 
 
Check who has been at your door: Activity Tab 
 
At the Activity Tab, the right most tab, you will be able to see a 
timeline with information about who was granted access to your door 
system, if you let someone inside, and if someone was outside the 
door. All of them with their respective time and date of the event.  
 
 
 
 
 
 
 
 
 
 
 
 
28 
Appendix B: User Stories 
 
During the Requirements Analysis phase, we created user stories which in the Implementation 
phase turned into application features, as explained in sections 3.4 and 3.6. Below we list the 
main user stories that we created: 
 
● As a User, I want to see a livestream from the door system so that I know who is outside 
● As a User, I want to see a list of my Friends, so that I know who has has access 
● As a User, I want to specify which day my Friend has access. 
● As a User, I want to be able to change my Friend’s name 
● As a User, I want to add new people on my list of friends so that they can get in 
● As a user, I want the door to unlock/open for people I know so that I don’t have to move 
and they can get in 
● As a User, I want to unlock/open the door remotely with my phone so that my invitees 
can get in 
● As a User, I want to lock/close the door remotely so that I don’t have to move to 
lock/close the door 
● As a User, I want to edit the different types of notifications I receive, so that I am always 
informed 
● As a User, I want to edit notifications for each friend 
● As a User, I want to delete a friend 
● As a User, I want to see the status of my door, so that I know if it is unlocked/locked or 
open/closed 
● As a User, I want to be able to log in with my credentials 
● As a User, I want to sign up, so that I can have a new account for my Smart Lock App 
● As a User, I want to edit the information of my account. 
● As a User, I want to see the activity for my Smart Lock 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
29 
Appendix C: Survey Results 
 
At the beginning of the project, we sent a survey to our friends, WPI students and faculty, to 
determine the need for the system we were about to create. We received 123 responses and we 
have shown those results in this Appendix.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
30 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
31 
Bibliography 
 
[1]  G. Fortino, A. Guerrieri and W. Russo, Middlewares for Smart Objects and Smart 
Environments: Overview and Comparison, Springer, Cham, 2014.  
[2]  C.-L. Hsu and J. C.-C. Lin, "An empirical examination of consumer adoption of Internet of 
Things services: Network externalities and concern for information privacy perspectives," 
Computers in Human Behavior, vol. 62, 2016.  
[3]  L. Adler, "Data-Smart City Solutions," Harvard Kennedy School, 18 February 2016. 
[Online]. Available: https://datasmart.ash.harvard.edu/news/article/how-smart-city-
barcelona-brought-the-internet-of-things-to-life-789. [Accessed 03 April 2019]. 
[4]  L. Columbus, "Forbes," Forbes, 6 June 2018. [Online]. Available: 
https://www.forbes.com/sites/louiscolumbus/2018/06/06/10-charts-that-will-challenge-your-
perspective-of-iots-growth/#7b0e28d33ecc. [Accessed 3 April 2019]. 
[5]  T. P. Norman, Electronic access control, Amsterdam: Butterworth-Heinemann, 2012.  
[6]  J. Stern, "iPhone X Review: How We Tested (and Tricked) FaceID," Wall Street Journal, 
31 October 2017. [Online]. Available: https://www.wsj.com/articles/iphone-x-how-we-
tested-and-tricked-faceid-1509465766. [Accessed 4 April 2019]. 
[7]  J. R. Delaney, "The Best Smart Locks for 2019," PCMag, 15 April 2019. [Online]. 
Available: https://www.pcmag.com/article/344336/the-best-smart-locks. [Accessed 18 April 
2019]. 
[8]  "August," August, [Online]. Available: https://august.com. [Accessed 3 April 2019]. 
[9]  "Kwikset," Kwikset, [Online]. Available: https://www.kwikset.com. [Accessed 3 April 2019]. 
[10]  B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering Using UML, Patterns, 
and Java, Pearson, 2009.  
[11]  M. Zyla, C. Dickson-Burke, D. Kim and A. Karet, "Developing a Mobile Application to 
Reduce Risks for Runaway Youth in Bangkok, Thailand," March 2018. [Online]. Available: 
https://digitalcommons.wpi.edu/iqp-all/2232/. [Accessed 3 April 2019]. 
[12]  "The Good and the Bad of ReactJS and React Native," altexsoft, 10 September 2018. 
[Online]. Available: https://www.altexsoft.com/blog/engineering/the-good-and-the-bad-of-
reactjs-and-react-native/#pros%20of%20react%20native. [Accessed 3 April 2019]. 
[13]  "Differences Between Raspberry Pi 3 vs Arduino," EDUCBA, [Online]. Available: 
https://www.educba.com/raspberry-pi-3-vs-arduino/. [Accessed 3 April 2019]. 
[14]  "What is an Ultrasonic Sensor?," Keyence, [Online]. Available: 
https://www.keyence.com/ss/products/sensor/sensorbasics/ultrasonic/info/. [Accessed 3 
April 2019]. 
[15]  "Passive infrared sensor," Wikipedia, [Online]. Available: 
https://en.wikipedia.org/wiki/Passive_infrared_sensor. [Accessed 20 March 2019]. 
[16]  "What’s the Difference Between Pneumatic, Hydraulic, and Electrical Actuators?," 
MachineDesign, 16 April 2015. [Online]. Available: https://www.machinedesign.com/linear-
 
32 
motion/what-s-difference-between-pneumatic-hydraulic-and-electrical-actuators. 
[Accessed 15 April 2019]. 
[17]  "UML 2 Class Diagrams: An Agile Introduction," AgileModeling, [Online]. Available: 
http://agilemodeling.com/artifacts/classDiagram.htm. [Accessed 20 March 2019]. 
[18]  "UML 2 State Machine Diagrams: An Agile Introduction," Agile Modeling, [Online]. 
Available: http://agilemodeling.com/artifacts/stateMachineDiagram.htm. [Accessed 20 
March 2019]. 
[19]  "Azure App Service," Microsoft, [Online]. Available: https://azure.microsoft.com/en-
us/services/app-service/. [Accessed 20 March 2019].