ACCESS - IoT enabled smart lock

ABSTRACT


INTRODUCTION
Applying automation to simple manual tasks is challenging and interesting. People access their households and workplaces frequently every day and there are many problems associated with security and accessibility. Sometimes people are away from their homes or workplace when a visitor arrives and they are not present to let them into the house unless they reach home. Elderly people may face difficulty in walking repeatedly to open doors. Also, when there is a security breach like a theft, it becomes difficult to trace the people who visited the property. Hence, people are in control of their property only when they are physically present near it and they lose this control once they are away from it. In the proposed system "ACCESS", these manual methods are replaced by a mobile application. Users can lock or unlock their doors using this mobile application even when they are not present at home. If we imagine a scenario where a visitor suddenly arrives at the house, normally he would have to contact the owner, and the owner would not be able to help until he reached home. With the proposed solution, the visitor will only have to ring the doorbell and the system will detect the doorbell press and send a notification to the owner along with a photograph of the visitor. Surveillance cameras are used to see who is at the door users can view the visitors and also speak to them through the microphone-speaker provision. The owner can be away from home and still let the visitor in. All lock and unlock operations are logged and users can later check these locks to have a clear idea of who has accessed their property. This is helpful in case of security issues or crimes. On every doorbell press the visitor's photograph is sent to the owner an also stored. This gives a very clear view of all visitors even if they are unknown.
Every lock has a single primary owner and owners can choose to grant this control to any number of users for a time period of their choice and also revoke these access permissions at any time. They are also informed every time another person accesses their locks. It is also ensured that only owners can remotely 178 them a slightly inconvenient choice for this kind of a system. Comparatively, emails are convenient but require separate paid services to be maintained. This increases the cost of implementation. Also, emails may not be checked regularly by users.
There are some systems which involve mobile application based access to door locks as in [18]. Some of these applications connect to the microcontroller via Bluetooth [19] or local area network (LAN) connections, indicating the inability to function remotely. Bluetooth is a two-way connection protocol which requires a method called pairing [20]. In this, both connecting parties must accept and enter the connection. In contrast to this, Bluetooth low energy (BLE) [21] requires lower power since it happens one way. The ACCESS system uses BLE since there is no pairing required, only a single way broadcast of data is sufficient followed by the receiving of this data from the other end. The mobile application of ACCESS requires an internet connection but this is not an additional requirement since all cellphone users today have internet access. All notifications and server communications take place with the help of the phone's internet connection itself. Figure 1 shows the electrical components controlled by a Raspberry Pi [22]. The components are described in the following section.

Hardware and microcontroller
− Solenoid lock and relay -The solenoid lock represents household locks. It is controlled by a relay connected to the Pi. When the user gives a lock or unlock command to the Pi, the relay is switched to push up the head of the solenoid lock (to lock) or bring it down (to unlock). − 4x4 matrix keypad and manual switch -When there is no internet connection, a 4x4 matrix keypad is used to enter a onetime password (OTP) which is generated by the Pi and sent to the owner's mobile application. If someone is inside their home, they can use a switch on the inside of the door to open it, instead of using the app. − OLED display -This is used for displaying the status of the lock, the entered password or any message to the person standing at the door. − Doorbell -When this is pressed, the Pi notifies the owners that a visitor has arrived along with a photograph of the visitor. − Web camera and speaker -The web-camera streams the live video of the visitor to a public URL through the Raspberry Pi as shown in Figure 1. When the user speaks through his mobile application, the audio is streamed back to the Pi and then to the speaker.

Power supply
The Pi needs a power supply of 12V. This can be supplied through the USB or through the generalpurpose input/output (GPIO) pins. The power can be drawn from a power bank, direct plug connection or lithium-ion batteries. All other components have their power inputs connected to the pins of the Pi and can get their power supply from them. Only the solenoid lock used for demonstration requires a 12V power and cannot draw it from the Pi since the maximum output voltage of the Pi is 5V. For the solenoid lock too, we can use a power bank, direct plug or lithium-ion battery separate from the one used for the Pi. These can be connected to the solenoid lock through its positive and negative terminals. Figure 2 explains the system workflow. The user's mobile application (front-end) is developed using a cross platform framework [23] so that it can run on any mobile operating system. The application functions by communicating with the application server (back-end) hosted on the cloud. Two protocols are used in this system -hypertext transfer protocol (HTTP) [24] and message queuing and telemetry (MQTT) [25]. HTTP functions through requests and responses. The user clicks the 'Lock' or 'Unlock' button from his mobile application and an HTTP request is sent to the application server. The server checks with the current lock status from the database to see if the operation is feasible. For example, a 'lock' request on the lock when it is already in 'locked' state will not be executed and the user's mobile application will be notified whether the operation is in progress or already performed.

Working of lock operations -HTTP and MQTT
Following this, MQTT is applied. MQTT involves publishers who send messages to topics and subscribers who await these messages, with a broker to communicate the arrival of these messages. If the requested lock operation can occur, the server publishes the string containing the lock ID and operation to the MQTT topic and the Pi (which is subscribed to the topic) receives this data. Now, the Pi checks if this operation is possible with the state of the lock which it has stored locally. If yes, then the lock is operated on and the lock state is updated. The Pi publishes the entire data to an MQTT topic which triggers a request to the server for updating the data of this operation into the database.

Doorbell detection, web camera and talkback
When a visitor presses the doorbell, the system detects this and triggers a notification to the owner's mobile application. Simultaneously, the system takes snapshots of the visitor and stores them on the cloud for the owner to see. When the owner clicks the notification, he is taken to the screen from where he can switch on the camera to view the visitor live. The web camera captures the video of the visitor and the web camera's inbuilt microphone captures the audio. This web camera feed is streamed onto the local server of the Pi. Reverse secure shell tunneling (or SSH Tunneling) is used to make the webcam server available on a public URL so that it can be seen on the mobile application. On the other hand, the audio from the owner (coming from the mobile application) is received and amplified by the speaker on the door. The server allows full duplex, two-way communication between the mobile application and the Raspberry Pi. Using this, the owner can see the visitor and talk to them like a video call.

User privileges
The mobile application is used for many features other than the basic lock operations. There can be three types of users in the system: − Primary owners -These users have all privileges for a lock. They can perform lock and unlock operations when they are near their locks or even remotely. They can add new locks, edit or delete existing ones. They can also use the webcam and video calling features. They have the privilege to add secondary owners or guests for their locks and set the time for the expiry of the permissions. − Secondary owners -Their permissions are the same as that of the primary owner but they cannot edit or delete locks. For example, in a family either spouse could be the primary owner while the other spouse and children could be the secondary owners. They can also create other secondary owner or guest users. − Guests -They only have locking and unlocking permissions which can be performed only when they are in proximity of the locks. Hence, remote access is not allowed for them. They can use their privileges till the expiry time which the primary or secondary owners fix for their guest accounts.

Bluetooth low energy
Guests are allowed to access their locks only when they are present near the locks. BLE [25] is used to confirm that the user's mobile application is in proximity of the lock. Concepts of Bluetooth and BLE have been widely used for proximity sensing experiments as depicted in [26] through the use of beacons. In the proposed system, the Pi broadcasts a universally unique identifier (BLE UUID) which is scanned by the guest's mobile application when he tries to access the lock. The database is constantly updated with this UUID from the Pi. When the scanned UUID matches that on the database, access is granted. There are many publicly available mobile applications which can scan nearby BLE device UUIDs. Hence it is possible for any guest user to find out the Pi's UUID using such an app and then clone it to pretend to be near the lock when he is actually not. To prevent such spoofing and cloning, the Pi's UUID is changed and regenerated at regular intervals by running cron jobs on the Pi to prevent spoofing and cloning. A normal Bluetooth connection as used in [27] needs both devices to approve of the connection since it involves two-way pairing but in the proposed method BLE is used and it is more efficient for the requirement since the Pi sends out an ID and all nearby devices can capture the ID [28]. The only drawback of BLE is the possibility of cloning which has been solved by the system as well.

Offline access
There may be situations where the system needs to operate without internet, if the internet connection is lost. This offline system contains a keypad and OLED display to enable manual entry of passcodes for lock access [29]. The passcode is generated as an OTP which is sent to the user's mobile application [30]. When the OTP is used, the Pi waits to come back online, and then the new OTP is generated and sent to the user for the next use. The Pi also stores a master code locally and this may be used instead of the OTP. The letter keys on the keypad are used for changing the master code, deleting characters or confirming the entered code string. There is also a switch on the inner side of the door which enables residents to access the door lock manually from inside.

Database
The database instance has been created on cloud and holds data in four tables. It is an Intel AVX, Intel Turbo instance with one single core CPU, 1GB of memory and low to moderate network performance. The tables are as follows: a) Users -Details of all the users who have registered to the application. Primary owners, secondary owners and guests are all users on the application. The data stored in this table are: − Username (primary key), full name and phone number of the user. − Mobile application ID -of the user. When an app is installed, it generates a unique ID for itself and this is needed as an endpoint for sending notifications. If a user has signed in from multiple apps, then all the app IDs are stored. b) Locks -This holds the details of the locks which each owner adds to his account. Each time he adds a new lock from his mobile application, it is added as a row in this

181
− Lock ID (primary key), alias (a name given by the owner for easy identification), address (where the lock is located), username (of the owner who created the lock). − Lock priority -The mobile application allows locks to be marked as a favourite so they can be placed at the top of the list of locks. − BLE UID and media access control (MAC) address of the Pi. − Current lock state -This is updated every time a lock operation is completed and helps in avoiding repetition of operations. c) Access control logs (ACL) -All the secondary and guest users to whom access have been granted. It stores the username, lock ID for which access is given, expiry timestamp of permissions, and user type (guest or secondary). d) Logs -Regular log details of every action that takes place on every lock in the system. This stores the operated lock's lock ID, operating user's username, timestamp of operation, type of operation (lock or unlock), user type (owner, guest or secondary).

Logging and filtering data
The mobile application allows the logs (or history of lock operations) to be viewed by owners and secondary owners. Filtering can be based on the operation type (user can choose to view only locks or only unlocks or both), username of the operating user (to view all the operations done by a user or a selected number of users), user type (to view operations done by only secondary owners or only guests), lock ID (to view operations only for a particular lock). They can also specify a start and end time to view the operations only between particular dates or times. These filters give the users an easy way to quickly view past data and is very helpful in case a security issue has to be investigated.

Authentication and security
The users are authenticated using a cloud authentication service. Each user can only see their own details via the application and hence their details are not accessible by any other user. The database is only accessible by systems on the same network. Hence only the backend server can access it. The database is only accessible by authenticated users and by providing required credentials and passwords. All these measures are taken to secure data and prevent third party access or hacking.
As mentioned in [31], IoT involves a huge amount of data and in every IoT project it is most important to maintain system security. Among security attacks, unauthorized use is very common and the proposed system prevents the possibility of it.

RESULTS AND DISCUSSION
Mobile applications are used in many experiments for smart door locks as in [32], [33] and it is very important to have a good user interface. The proposed system's mobile application is developed in a crossplatform framework so that it can run on all mobile operating systems. The mobile application is successfully developed and deployed, and is completely functional. Figure 3 shows the screens of User's locks (a), Lock operations and webcam options (b) and Logs (c).
Response time experiments: For different parts of the system, experiments were carried out to approximate the time taken (in seconds) for the flow of events to occur. 60 experiments were conducted for three scenarios and Table 1 holds an analysis of the studies.
Experimental conditions: The server is hosted on the cloud, with an instance of Intel AVX (Intel Turbo), with 1 GiB memory and single virtual central processing unit. The network performance of the instance is low to moderate and steady internet connection of 70 to100 Mbps was chosen. Table 1 is made by calculating the average values of all the experiments for every scenario.
Experiments show that the operation which takes maximum time is when a guest user performs a lock/unlock and the user's phone BLE UUID is scanned. Table 2   In the works of [34], the database has been based on NoSQL where data is stored as key value pairs. The proposed system used PostgreSQL which provides SQL relational table structure in which fields can be dictionaries or arrays and hence we cans tore multi-valued data and also key-value pair data. As compared to the results of [34], the proposed system produces faster database results since reading time is optimized due to efficient database structure.
The results show a direct relation between the performance speed and stability of internet connection. On average, every functional module is completed between 1 to 2 seconds. Most reasons of failure are related to internet connectivity which is one dependency of the system to function in online mode. This is also the reason why the offline mechanisms have been included to make sure the system is not dependent on internet for its basic requirement. This also means that the cloud service and tier of service should be chosen very carefully to make sure the server's networking and processing capacities are enough to support smooth functioning. The database also needs to be well chosen because spend of read and write operations depend largely on the database server processing.
Hence, the proposed system is a step towards developing a smart home since IoT is being widely used for smart systems [35], [36]. This project can be improved by the addition of some features. The doorbell detection can be integrated with the doorbell of the house in place of the additional switch. Further, the hardware components can be scaled down to smaller sizes to enhance compactness. A well-designed PCB will make the appearance even better. The application can be made more secure with facial recognition which is the base of the experiment in [37], [38]. There can also be an additional notification process via SMS to ensure the owner is notified even if his internet is not turned on [39]. An interesting addition would be a gesture recognition system for offline access as depicted in [40] through virtual reality methods where lock opening hand gestures can control the locks.

CONCLUSION
The project can be deployed in households, educational institutions and workplaces where people are searching for methods to add speed and convenience to their lifestyles. Any region put under lock and key can use this system. IoT has been used for monitoring sensors and smart homes as depicted in works. The vastest application of the proposed system is that of households since the doors are accessed multiple times on a regular basis and the problem of being away from home when visitors arrive is rather common. Apart from this, machinery, storage cupboards and rooms, and appliances can also be controlled by the same. In the case of a door it is a lock, and in the case of computer systems of machinery it is the power supply. Especially for elderly citizens, a more secure way of monitoring entries and exits to and from the house will prove to be beneficial for their safety. As explained in the paper, the proposed system aims at overcoming the drawbacks of existing system and also aims at making improvements by implementing some new approaches suggested by some of the related works.