HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY

SCHOOL OF MECHANICAL ENGINEERING

GRADUATION THESIS

An IoT-Based Smart Home System

LE VU DUC HUNG
[email protected]

NGUYEN DAC LONG

[email protected]

TRUONG QUOC VIET

[email protected]

NGUYEN DO DUY TUNG

[email protected]

Supervisor: Dr. Cao Xuan Binh

Major: Mechatronics

School: Mechanical Engineering

Hanoi, 24/06/2024
 HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY
SCHOOL OF MECHANICAL ENGINEERING

GRADUATION THESIS

An IoT-Based Smart Home System

LE VU DUC HUNG
[email protected]

NGUYEN DAC LONG

[email protected]

TRUONG QUOC VIET

[email protected]

NGUYEN DO DUY TUNG

[email protected]

Supervisor: Dr. Cao Xuan Binh

Major: Mechatronics

School: Mechanical Engineering

Hanoi, 24/06/2024
 ACKNOWLEDGMENTS

We would like to extend our sincerest thanks to Dr. Cao Xuan Binh, who provided
us with the best conditions to complete this project. He also offered feedback, pointed
out the limitations that needed to be addressed, and gave us advice on future development
directions. Additionally, we would like to thank the esteemed faculty members of the
School of Mechanical Engineering in general and the Department of Mechatronics in
particular for equipping us with valuable foundational knowledge throughout our time at
the university.

i
 PREFACE

Issues addressed
• Solving the problem of wireless connectivity between devices and between users
and products.

• Ensure safety and provide an alert method in case of risk.

• Implementing security methods to access the house, control access time, and lock
the door when needed.

• Using the MQTT protocol to solve the wireless connectivity problem between mod-
ules.

Tools Used
• Hardware: Raspberry Pi 4 embedded computer, ESP32 microcontroller module,
AS608 fingerprint module, 4x4 keypad, 1602 LCD, Sim GA6-B module, DHT22
temperature and humidity sensor, MQ2 smoke sensor module, relay, light bulbs,
fuses, push buttons, 5V and 12V power adapters.

• Software: NodeJS and C++, Docker, Cloudflare.

Knowledge Acquired
• Real-Time Operating Systems (RTOS)

• Developing applications using NodeJS

• Communication protocals: MQTT, UART

• Containerization technology

• Managing communication between sensors

iii
 TABLE OF CONTENTS

ACKNOWLEDGMENTS i

LIST OF FIGURES xii

LIST OF TABLES xiii

CHAPTER 1. INTRODUCTION 1
1.1 Overview of Smart Homes and IoT . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Design Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

CHAPTER 2: OVERVIEW OF THE SYSTEM AND TECHNOLOGIES

USED IN SMART HOME SYSTEMS 5
2.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 System Structure Diagram and Functions . . . . . . . . . . . . . . . . 7
2.2.1 System Structure . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 System Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Processors used in the system . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 ESP32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Raspberry Pi 4B . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Technologies and protocols used . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 MQTT Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.3 UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
 2.4.4 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.6 Cloudflare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

CHAPTER 3: HARDWARE SYSTEM DESIGN FOR SMART HOME 29

3.1 Hardware System Components . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Fire Alarm Block . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Temperature and Humidity Block . . . . . . . . . . . . . . . . 32
3.1.3 Electrical Device Control Block . . . . . . . . . . . . . . . . . 34
3.1.4 Password Entry Block . . . . . . . . . . . . . . . . . . . . . . 35
3.1.5 Display Block . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.6 AS608 Fingerprint Sensor . . . . . . . . . . . . . . . . . . . . 36
3.1.7 LY – 03 Electromagnetic Lock . . . . . . . . . . . . . . . . . . 37
3.1.8 PIR HC-SR501 motion sensor . . . . . . . . . . . . . . . . . . 38
3.1.9 SIM GA6-B Mini Module . . . . . . . . . . . . . . . . . . . . 39
3.2 System Control Circuit Design . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Door Lock Control Block . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Room Control Block . . . . . . . . . . . . . . . . . . . . . . . 42
3.3 Firmware System Design . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Smart Door Lock Block . . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Environmental Monitoring Block (Temperature, Humidity, Gas,
CO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.3 Alarm and Fire Detection Block . . . . . . . . . . . . . . . . . 53
3.3.4 Device Control Block . . . . . . . . . . . . . . . . . . . . . . . 55

CHAPTER 4: DEVELOPING SOFTWARE SYSTEM FOR SMART HOME

CONTROL 57
4.1 Building a Database System Using SQLite . . . . . . . . . . . . . . . . 57
4.1.1 Overview of SQLite . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2 Database Design for Control Systems . . . . . . . . . . . . . . 58
4.2 Smart Home containerization using Docker . . . . . . . . . . . . . . . 63

vi
 4.2.1 Benefits of using Docker in Smart Home . . . . . . . . . . . . 63
4.2.2 Deploy Smart Home with Docker . . . . . . . . . . . . . . . . 64
4.3 Control System Features . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1 Initialization Process upon System Startup . . . . . . . . . . . . 65
4.3.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.3 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.5 Setup camera . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.6 Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.7 Scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.8 User Interface on mobile . . . . . . . . . . . . . . . . . . . . . 77

CHAPTER 5: CONCLUSIONS 81
5.1 Achieved Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Future Development Directions of the Project . . . . . . . . . . . . . . 81
 LIST OF FIGURES

Figure 2.1 System architecture overview. . . . . . . . . . . . . . . . . . . . 5

Figure 2.2 ESP32 Microcontroller. . . . . . . . . . . . . . . . . . . . . . . 9
Figure 2.3 Raspberry Pi 4 and peripheral blocks. . . . . . . . . . . . . . . 10
Figure 2.4 Real Time OS Model. . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 2.5 Task states in RTOS. . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 2.6 RTOS scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 2.7 Publish/Subscribe model of MQTT. . . . . . . . . . . . . . . . . 15
Figure 2.8 Operating mechanism of Pub/Sub model in MQTT. . . . . . . . 16
Figure 2.9 UART Communication Model. . . . . . . . . . . . . . . . . . . 18
Figure 2.10 Data Exchange in UART. . . . . . . . . . . . . . . . . . . . . . 19
Figure 2.11 Data Packet Structure. . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 2.12 UART Transmit receives parallel data from the data bus. . . . . . 20
Figure 2.13 UART Transmit adds start bit, parity bit, and stop bit to the data
frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 2.14 Packet transmission process. . . . . . . . . . . . . . . . . . . . 21
Figure 2.15 UART receive removes some bits from the data frame. . . . . . . 21
Figure 2.16 Data is sent to the data bus. . . . . . . . . . . . . . . . . . . . . 22
Figure 2.17 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 2.18 Docker architecture and components . . . . . . . . . . . . . . . 25
Figure 3.1 Structure of MQ2 sensor. . . . . . . . . . . . . . . . . . . . . . 29
Figure 3.2 Structure of the sensor element. . . . . . . . . . . . . . . . . . . 30
Figure 3.3 MQ2 sensor module. . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 3.4 Fire sensor module. . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 3.5 Fire alarm speakers and sirens. . . . . . . . . . . . . . . . . . . 32
Figure 3.6 DHT22 sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 3.7 Relay 5V 10A SRD 05VDC-SL-C . . . . . . . . . . . . . . . . 34
Figure 3.8 12x12x7.3mm physical push buttons . . . . . . . . . . . . . . . 34

ix
Figure 3.9 Structure of the 4x4 keypad matrix . . . . . . . . . . . . . . . . 35
Figure 3.10 LCD1602 module and I2C module . . . . . . . . . . . . . . . . 35
Figure 3.11 AS608 fingerprint sensor module . . . . . . . . . . . . . . . . . 36
Figure 3.12 LY-03 electromagnetic lock . . . . . . . . . . . . . . . . . . . . 37
Figure 3.13 PIR HC-SR501 motion sensor . . . . . . . . . . . . . . . . . . 38
Figure 3.14 SIM GA6-B Mini Module . . . . . . . . . . . . . . . . . . . . . 39
Figure 3.15 Schematic diagram of the door lock block . . . . . . . . . . . . 40
Figure 3.16 Bottom view of the PCB of the door lock block . . . . . . . . . 41
Figure 3.17 Top view of the PCB of the door lock block . . . . . . . . . . . 41
Figure 3.18 Schematic diagram of the room control circuit . . . . . . . . . . 42
Figure 3.19 Bottom view of the PCB of the room control block . . . . . . . . 42
Figure 3.20 Top view of the PCB of the room control block . . . . . . . . . . 43
Figure 3.21 System Diagram of the Firmware for the Door Lock Unit . . . . 45
Figure 3.22 UART Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 3.23 Keyboard Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 3.24 Fingerprint Flowcharts . . . . . . . . . . . . . . . . . . . . . . 47
Figure 3.25 Fingerprint Management Task . . . . . . . . . . . . . . . . . . . 48
Figure 3.26 Password Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 3.27 Communication Task . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 3.28 Air quality measure diagram . . . . . . . . . . . . . . . . . . . 51
Figure 3.29 Sensor initialization pulse . . . . . . . . . . . . . . . . . . . . . 52
Figure 3.30 Data representation pulse . . . . . . . . . . . . . . . . . . . . . 53
Figure 3.31 Fire Alarm Block . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 3.32 Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 4.1 User Account Database . . . . . . . . . . . . . . . . . . . . . . 58
Figure 4.2 Dashboard Table . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 4.3 Device Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 4.4 House Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 4.5 Room Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

x
Figure 4.6 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 4.7 Dockerfile for building Smart Home container . . . . . . . . . . 64
Figure 4.8 YAML file for using and configuring Smart Home container . . 64
Figure 4.9 Startup progress . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 4.10 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 4.11 Weather Forcast . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 4.12 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 4.13 Devices in room . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 4.14 Chart Configuration . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 4.15 Example charts which display sensor and temperate data . . . . . 69
Figure 4.16 Set up MQTT Broker . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 4.17 MQTT Device setting . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 4.18 Bluetooth in Smart Home . . . . . . . . . . . . . . . . . . . . . 70
Figure 4.19 Camera Setting . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 4.20 Using chat bot to process user’s request . . . . . . . . . . . . . . 72
Figure 4.21 Scene system in Smart Home . . . . . . . . . . . . . . . . . . . 72
Figure 4.22 Add a trigger block to run the scene on every week day morning. 73
Figure 4.23 Add the turn on switch action (required device to be connected
via switch feature) and add a wait action for 30 minutes. . . . . . . . . . 73
Figure 4.24 Finally add a turn off switches action. . . . . . . . . . . . . . . 74
Figure 4.25 Add a trigger to check gas data for every 5 seconds. . . . . . . . 74
Figure 4.26 Get both CO and LPG data. . . . . . . . . . . . . . . . . . . . . 75
Figure 4.27 Only continue action if the CO and LPG data is higher than some
value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 4.28 Send the alarm message to user via both Chat and Telegram. . . 76
Figure 4.29 Alarm Message . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 4.30 UI example on mobile . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4.31 UI example on mobile . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4.32 UI example on mobile . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 4.33 UI example on mobile . . . . . . . . . . . . . . . . . . . . . . . 78

xi
Figure 4.34 UI example on mobile . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 4.35 UI example on mobile . . . . . . . . . . . . . . . . . . . . . . . 79

xii
 LIST OF TABLES

Table 2.1 Characteristics of UART Communication . . . . . . . . . . . . . 18

Table 3.1 Technical specifications of the MQ2 sensor. . . . . . . . . . . . . 31
Table 3.2 Technical specifications of the DHT22 sensor . . . . . . . . . . . 33
Table 3.3 Technical specifications of the LY – 03 electromagnetic lock . . . 37
Table 3.4 Technical specifications of the PIR HC-SR501 motion sensor . . 38
Table 3.5 Technical specifications of the SIM GA6-B Mini Module . . . . . 40

xiii
 CHAPTER 1. INTRODUCTION

1.1 Overview of Smart Homes and IoT

1.1.1 Problem Statement
In today’s 4.0 era, the rapid development of the internet has led to daily demands
such as controlling and managing a home remotely without physically interacting with
switches or door locks, making it possible to do so from bed or even outdoors. Addi-
tionally, recent news reports and media have shown that fires occur frequently and cause
severe consequences, including many fatalities. Therefore, early fire, gas detection and
warning are extremely important and necessary to prevent undesirable outcomes. This
project focuses on building an embedded system to control a smart home and provide
the earliest possible warnings.

1.1.2 Project Objectives

Design a control system for a smart home that includes
• A system at the door to control access, and also open/close the door and turn on/off
the lights, fans ...

• A system on each floor to monitor temperature and humidity, control electrical

devices, and detect fires, gas.

• A central control system to manage and store all information from other systems
and report to the user almost immediately when a fire occurs.

• An app for controlling the system via phone, web browser, display with a scene
action system that user can customize according to their needs.

1.1.3 Tasks
Mechanical Design
Design the enclosure and install devices in a logical space.

Control Circuit Design

• Calculate the number of necessary I/O ports and check compatibility between pe-
ripheral devices to select an appropriate central controller for each room.

• Select a door access control module.

• Choose high-accuracy temperature and humidity sensors.

1
 • Select high-accuracy smoke sensors.

• Choose a device to act as the central controller (gateway).

• Select devices capable of alerting users (alarms, phones, etc.).

• Design a suitable power supply circuit.

• Establish wiring diagrams for devices, connect hardware, test circuits, and ensure
circuit stability.

Control Software Design

• Select an appropriate wireless communication method.

• Choose a suitable operating system for the system.

• Design the connection method between the microcontroller and sensor modules.

• Ensure the fire alarm response is as fast as possible from the moment a fire is
detected.

• Design web server for system.

1.1.4 Scope
The project applies knowledge of electrical-electronics, mechanics, and program-
ming learned in school to complete a product. Due to limited execution time, this project
will focus mainly on algorithm design, control programming to design the system and
user interface. The product can be practically applied to control household devices and
provide warning alerts.

1.2 Design Approach

Smart homes are a broad topic with many issues to address. Depending on the
homeowner’s usage purposes, an important part of the smart home system is the control
and monitoring system.
Previously, smart homes existed only in imagination and movies. Thanks to con-
tinuous advancements in science and technology, smart home solutions are becoming
more diverse and convenient for users.
Initially, smart homes had remote control devices within the house to serve some
human needs. Next came the automation of devices within the house, allowing them
to adjust automatically according to the environment and user preferences. Following
that, with the development and spread of the internet, solutions emerged to connect and

2
control home devices through the internet, adding features like safety systems and energy
usage calculations. This allows homeowners to control devices from afar, not just within
the confines of the house.
Security is also a top priority, as internet connectivity increases the risk of hacking
and system takeover. Homeowners can use private passwords to log into the system and
house through methods such as passcodes or fingerprint security. Additionally, remote
fire hazard alerts can warn homeowners even when they are not home, helping prevent
and mitigate serious consequences of fires, including loss of life and property.
Currently, in Vietnam, smart home solutions with control and monitoring systems
via the internet remain popular and continue to develop, as they fit current technolog-
ical capabilities and economic conditions. Our group finds this topic suitable for our
Mechatronics major. Therefore, a control system for a smart home have been chosen to
design using internet-connected control and monitoring systems, specifically via Wi-Fi,
in a model smart home including a door and two bedrooms with basic functions such as:
door control (open/close), storing and displaying entry logs, fire monitoring and alerts,
temperature and humidity control in rooms, a scene system that user can customize ac-
cording to their need and controlling 220V electrical devices in the house. The model
will be controlled via a web interface on a phone or a central control screen placed in
the living room.

3
 CHAPTER 2: OVERVIEW OF THE SYSTEM AND
TECHNOLOGIES USED IN SMART HOME SYSTEMS

2.1 System Overview

Figure 2.1 System architecture overview.

Through extensive research and study, our group has developed an advanced Smart
Home system model. This model allows users to interact with and control various de-
vices in their home using either a phone application or a control panel. The device states
are synchronized in real-time, ensuring that any change made via the phone application
or control panel is immediately reflected across all connected devices.

User Interaction and Device Control

Users can seamlessly interact with the Smart Home system through a user-friendly
application on their smartphones or a dedicated control panel installed in their home.
These interfaces provide an intuitive way to monitor and control devices such as lights,
thermostats, security cameras, and more. The real-time synchronization ensures that
when a user turns on a light using the phone application, the state change is instantly
visible on the control panel and vice versa. This bidirectional communication enhances
the user experience by providing immediate feedback and control.

5
Data Exchange and Synchronization
At the heart of the Smart Home system is a robust data exchange mechanism. De-
vice states and commands are communicated bidirectionally between the devices and the
central controller. The controller, in turn, communicates with a NodeJS server container
running inside a Raspberry Pi. This setup provides a compact yet powerful platform for
managing the Smart Home ecosystem.

Communication Protocols
To facilitate efficient and reliable data exchange, the system employs two primary
protocols: UART (Universal Asynchronous Receiver-Transmitter) and MQTT (Message
Queuing Telemetry Transport)

• UART: This protocol is used for direct serial communication between the controller
and the devices. It is ideal for low-latency, high-reliability connections required for
real-time control.

• MQTT: MQTT is a lightweight, publish-subscribe network protocol that is well-

suited for IoT applications. It enables scalable and flexible communication between
the devices and the server, allowing for efficient data transfer and command execu-
tion.

Controller and RTOS

The system utilizes ESP32 control chips, which are equipped with a real-time op-
erating system (RTOS). The RTOS ensures that tasks are executed with precise timing
and reliability, which is crucial for maintaining the synchronization and responsiveness
of the Smart Home system. The ESP32 chips are responsible for managing the devices,
processing commands, and communicating with the central controller.

Secure Remote Control

In addition to local network control, the Smart Home system offers secure remote
access, allowing users to control their home devices from anywhere in the world. To
achieve this, Cloudflare services are leveraged, which provide a secure and reliable
means of exposing the server to external networks. By using Cloudflare, the risks as-
sociated with direct exposure to the internet are minimized, which contain potential
cyber-attacks and unauthorized access.

6
2.2 System Structure Diagram and Functions
2.2.1 System Structure
Basic model consisting of
• A door control unit.

• Two control units for 2 rooms.

• A central control unit and control panel placed in the living room.

2.2.2 Functions
With the criteria for a smart home in Vietnam, a smart home was selected functions
to create the following conveniences
• Turn lights, TV, and fans on and off using switches or a phone

• Room temperature and humidity notification system

• Automatic fire and gas leak detection system, which reports to the homeowner even
when they are not at home

• Entry and exit control system that records the times the door is opened and closed

• A scene system that user can customize according to their needs

2.2.3 System Diagram

Based on the general model presented above, the system is broken down into the fol-
lowing parts
• Hardware devices

• Control application

• Cloud

7
2.2.3.1 Hardware Devices

For the in-house installation, it is divided into three smaller units: central control
unit, floor control units, and door control unit.

• Central Control Unit

– Processing unit: Raspberry Pi 4

– Control screen: 7-inch touchscreen

• Entry and Exit Control Unit

– Processing unit: ESP32

– Password input unit

* 4x4 keypad matrix

* 1602 LCD
* I2C LCD module
– LY-03 Door lock
– AS608 Fingerprint module

• Room Control Unit

– Processing unit: ESP32

– Temperature and humidity unit: DHT22
– Fire alarm unit: MQ2 sensor, siren
– Power-consuming devices: 220V wire will be used for sockets so users can plug
in any standard household appliances like lights, rice cookers, refrigerators, etc.

2.2.3.2 Control Application

For the control application, a robust web server using Node.js was developed, lever-
aging its scalability and asynchronous capabilities. This server was meticulously crafted
to handle the complexities of our smart home system, ensuring smooth operation and
reliable performance. To enhance deployment efficiency and maintain system integrity,
Docker technology was employed, allowing us to encapsulate the server environment and
dependencies. This Dockerized setup runs seamlessly on a Raspberry Pi 4, optimizing
resource utilization and facilitating remote management of our smart home functionali-
ties.

8
2.2.3.3 Cloud

For our cloud operations, Cloudflare services are used extensively to bolster the
security of our smart home system. By leveraging Cloudflare, robust measures are im-
plemented to protect against potential vulnerabilities that can arise when our server is
exposed outside the local network. This proactive approach ensures comprehensive se-
curity for our smart home infrastructure, safeguarding it from external threats and ensur-
ing peace of mind for users.

2.3 Processors used in the system

2.3.1 ESP32
This is a smart home system with fire, gas leak alarm function, where timely de-
tection and fire notification are crucial and must be immediately effective. Therefore,
the control unit must be designed to meet real-time execution with high priority, prior-
itizing microcontrollers that support real-time operating systems (RTOS). Additionally,
as a smart home system, communication and control methods must be wireless. Given
these conditions, the ESP 32 microcontroller was chosen.

Figure 2.2 ESP32 Microcontroller.

ESP32 is a 32-bit microcontroller with the following specifications

• Powerful configuration with 2 cores.

• Clock speed up to 160MHz-240MHz.

• 448Kb ROM.

9
 • 4MB Flash.

• 520KB SRAM, 520KB built-in SRAM.

• Supports various peripherals like ADC, SPI, UART, I2C, PWM, etc.

• Supports 802.11 standard (Wi-Fi 2.4GHz), Bluetooth v4.2 BR/EDR, and BLE for
interaction with devices like phones and computers.

• Integrated Deep Sleep mode to reduce power consumption, suitable for IoT projects.

• In this project, code deployment is clarified using the ESP-IDF framework sup-
ported by the manufacturer, which includes RTOS integration.

2.3.2 Raspberry Pi 4B
Raspberry Pi 4B is the latest product in the Raspberry Pi embedded computer
series, launched in late June 2019. The configuration of Raspberry Pi 4B features the
Broadcom BCM2711 chip, Cortex-A72 (ARM v8) 4-core 64-bit processor running at
1.5GHz, making it the fastest processor in this line of embedded computers to date. This
version of Raspberry Pi supports two micro-HDMI ports, 2 USB 2.0 ports, and 2 USB
3.0 ports, IEEE 802.11ac Wi-Fi with Dual-Band 2.4GHz and 5GHz, Bluetooth 5.0, high-
speed Ethernet port (Gigabit Ethernet), and Power over Ethernet (PoE) support, making
it widely used in embedded and IoT projects.

Figure 2.3 Raspberry Pi 4 and peripheral blocks.

10
• Processor: Broadcom BCM2711, Cortex-A72 (ARM v8) 64-bit SoC with 1.5GHz
processing speed.

• Memory: 1GB/2GB/4GB LPDDR4-3200 SDRAM.

• Network communication: 2.4GHz and 5GHz IEEE 802.11ac Wireless LAN, Blue-
tooth 5.0, BLE, high-speed Ethernet (Gigabit Ethernet).

• Data I/O: 40 GPIO pins (GPIO/SPI/I2C/UART/PWM), 2 USB 2.0 ports, 2 USB 3.0
ports.

• Video and Audio: 2 micro-HDMI ports, MIPI DSI Display port, MIPI CSI Camera
port, Stereo Audio and Composite Video 4-pin.

• Multimedia: H.265/H.264 Decode, H.264 Encode, OpenGL ES 3.0.

• Storage: MicroSD card.

• Power supply: 5VDC/3A USB-C port, 5VDC on GPIO pin, PoE (requires PoE
HAT).

11
2.4 Technologies and protocols used
2.4.1 RTOS
For a system including a fire alarm function, real-time requirements are crucial to
ensure timely notifications and mitigate unnecessary risks. RTOS (Real-Time Operating
System) allows your applications to run multitask and meet deadlines in real-time. Note
that meeting deadlines does not necessarily mean being fast; it means being accurate
and timely. RTOS is also applied in large-scale projects requiring multitasking with
stringent time constraints, telecommunications and IoT applications, medical devices,
and safety-critical systems like automobiles. Unlike conventional operating systems like
Windows, Android, iOS, etc., which host multiple applications and features and require
startup time when opening applications, RTOS is designed for specific tasks, executing
tasks within precise time frames, isolating and handling errors swiftly.

Figure 2.4 Real Time OS Model.

RTOS is typically divided into three main types:

• Hard RTOS: These operating systems always ensure tasks are completed within a
specific, defined timeframe without error.

• Soft RTOS: These operating systems allow some flexibility in meeting task dead-
lines within permissible limits, as long as deadlines are met.

• Firm RTOS: These operating systems also have specific time limits with highest
accuracy, ensuring tasks are always successful even if deadlines are exceeded.

12
Basic functions of RTOS:
• Scheduler: Each task in the Scheduler has three default states:

• Ready to run: The task is ready to run when it has all the resources it needs to start.

• Running: The task is currently executing.

• Blocked: This is the state where tasks that do not have enough resources to process
are put on hold.

Figure 2.5 Task states in RTOS.

RTOS Services: These include services such as:

• Interrupt handling services.

• Time services.

• Device management services.

• Memory management services.

• I/O services.

13
Messaging. These messages are used to exchange information between tasks, includ-
ing:
• Semaphores: Synchronize access rights to shared resources.

• Event flags: Synchronize operations requiring coordination among multiple tasks.

• Mailboxes, Pipes, Message queues: Manage messages that have been sent and re-
ceived between tasks.

Figure 2.6 RTOS scheduler.

In addition, real-time operating systems have other advantages such as:

• High stability and reliability, so they can operate for long periods without requiring
significant human intervention.

• Better performance with lower memory consumption, so they do not excessively

consume resources or RAM.

• RTOS is nearly error-free, and if errors occur, they are easier to detect. Small size
and low cost.

2.4.2 MQTT Protocol

MQTT (Message Queue Telemetry Transport) is a lightweight network protocol
operating on the publish-subscribe mechanism according to ISO standard (ISO/IEC
20922) and OASIS for transmitting messages between devices. This protocol operates
on the TCP/IP platform and is designed for data transmission to remote devices, small
controllers with limited resources, or applications with limited network bandwidth.

14
Characteristics of the MQTT Protocol
• Uses the Pub/Sub message model to provide one-way distributed messaging, sepa-
rate from the application part.

• Message transmission is immediate, regardless of the content being transmitted.

• Uses TCP/IP as the underlying protocol.

• There are three reliability levels for data transmission (Quality of Service - QoS):

– QoS 0: Broker/client sends data only once, and the sending process is con-
firmed by the TCP/IP protocol alone.
– QoS 1: Broker/client sends data with at least one confirmation from the other
end, meaning there may be more than one confirmation that data has been
received.
– QoS 2: Broker/client ensures that when data is sent, the receiving end only
receives it once, a process that must go through 4 handshakes.

• The data envelope for transmission is small and minimized to reduce the load on
the transmission line.

Publish/Subscriber model in MQTT protocol

High-level architecture of MQTT consists of 2 main parts: Broker and Clients.

• Broker: Considered the hub, it is the convergence point for all connections from
clients. The main task of the broker is to receive messages from publishers, queue
them, and then forward them to a specific address. The secondary task of the broker
is to handle additional communication processes such as message security, message
storage, logs, etc.

• Client: Divided into 2 groups: publishers and subscribers. Clients are software
components operating on edge devices, designed to operate flexibly (lightweight).
Clients perform at least one of two tasks: publish messages to a specific topic or
subscribe to receive messages from a topic.

Figure 2.7 Publish/Subscribe model of MQTT.

15
Characteristics of the Pub/Sub model
• Space decoupling.

• Time decoupling.

• Synchronization decoupling.

Operational mechanism of MQTT protocol

A MQTT session is divided into four phases: connection, authentication, commu-
nication, and termination.

• Phase 1 - Connection: The client starts by establishing a Transmission Control

Protocol/Internet Protocol (TCP/IP) connection to the broker using a standard port
or a custom port defined by broker developers.

• Phase 2 - Authentication: The standard ports are 1883 for unencrypted communi-
cation and 8883 for encrypted communication - using Secure Socket Layer (SSL) /
Transport Layer Security (TLS). During SSL/TLS communication, the client needs
to authenticate and verify the server.

• Phase 3 - Communication: Subsequently, the Client will send a message to the

broker if it is a Publisher or receive a message from the broker if it is a Subscriber.
This connection process is maintained until the connection is terminated.

• Phase 4 - Termination: After termination to be able to transfer MQTT, repeat all the
above steps.

Figure 2.8 Operating mechanism of Pub/Sub model in MQTT.

16
MQTT Bridge
MQTT Bridge is a feature of MQTT Broker that allows MQTT Brokers to connect
and exchange data with each other. To use this feature, a minimum of 2 Brokers is
required, where any Broker is configured as a Bridge. When configuring MQTT bridge,
attention should be paid to the following parameters:

• address: address of the broker to be connected.

• bridge protocol version: version of the MQTT protocol currently in use by both
brokers.

• topic: this part defines 3 parameters: the name of the topic exchanged between 2
brokers, the direction of exchange (one-way or two-way), and the corresponding
qos.

2.4.3 UART
2.4.3.1 Introduction to UART Communication

Communication protocols play a crucial role in organizing communication be-

tween devices. They are designed in various ways based on system requirements, and
these protocols have specific rules standardized between devices to successfully transmit
data.
Embedded systems, microcontrollers, and computers mostly use UART as a type of
hardware communication protocol between devices. Among the existing communication
protocols, UART uses only two wires for transmission and reception. Although widely
used as a hardware communication protocol, it is not always fully optimized. Proper im-
plementation of the frame transmission protocol is often overlooked when using UART
modules within microcontrollers.
By definition, UART is a hardware communication protocol that uses asynchronous
serial communication with configurable speed. Asynchronous means there is no clock
signal to synchronize the outgoing bits from the transmitting device to the receiving
device.

17
 Figure 2.9 UART Communication Model.

The two wires each UART device uses to transmit data are:

• Transmitter (Tx).

• Receiver (Rx).

UART transmits data asynchronously, meaning there is no clock signal to syn-

chronize the output of bits from the transmitting UART to the sampling of bits by the
receiving UART. Instead of a clock signal, UART adds start and stop bits to the data
packet being transmitted. These bits determine the beginning and end points of the data
packet for the UART receiver to know when to start reading the bits.
When UART receives, it detects a start bit, begins reading bits at a specific fre-
quency called baud rate. Baud rate is the measure of data transmission speed, expressed
in bits per second (bps). Both UARTs must operate at the same baud rate. The transmis-
sion speed between UART transmit and receive can only deviate by about 10% before
the timing of the bits becomes too skewed.

Table 2.1 Characteristics of UART Communication

Characteristic Details
Number of wires used 2
Transmission speeds 9600, 19200, 38400, 57600, 115200, 230400, ...
Transmission method Asynchronous
Serial or parallel transmission? Serial transmission
Maximum master devices 1
Maximum slave devices 1

18
2.4.3.2 Operation of UART Communication

UART will transmit received data from a data bus. The data bus is used to send
data to UART by another device such as CPU, memory, or microcontroller. Data is
transferred from the data bus to UART in parallel form. After UART transmit receives
parallel data from the data bus, it adds a start bit, a parity bit, and a stop bit, creating
a data packet. Next, the data packet is serially output bit by bit at the Tx pin. UART
receive reads the data packet bit by bit at its Rx pin. UART receive then converts the
data back to parallel form and removes the start, parity, and stop bits. Finally, UART
receive transfers the data packet in parallel with the data bus at the receive end.

Figure 2.10 Data Exchange in UART.

Data transmitted via UART is grouped into packets. Each packet contains 1 start
bit, 5 to 9 data bits (depending on UART), an optional parity bit, and 1 or 2 stop bits.

Figure 2.11 Data Packet Structure.

Start bit:
The UART data transmission line is usually kept at a high voltage level when it
is not transmitting data. To start transmitting data, UART will pull the transmission
line from a high level to a low level in 1 clock cycle. When UART receive detects the
high-to-low voltage transition, it read bits in the data frame at the transmission speed.

19
Data Frame:
The data frame contains the actual data being transmitted. It can be as long as 5
bits to 8 bits if using parity bit. If not using parity bit, the data frame can be up to 9 bits.
In most cases, data is transmitted with the least significant bit (LSB) first.

Parity Bit:
Parity bit describes the even or odd nature of a number. The parity bit is a way for
UART receive to know if any data has changed during the transmission process. The bit
can be changed by electromagnetic radiation, mismatched transmission speed, or long-
distance data transmission. After UART receive reads the data frame, it will count the
number of bits with a value of 1 and check if the total is even or odd. If the parity bit is 0
(even parity), the total number of bits with a value of 1 in the data frame must always be
an even number. If the parity bit is 1 (odd parity), the total number of bits with a value
of 1 in the data frame is an odd number. When the parity bit matches the data, UART
knows that the transmission process is error-free. But if the parity bit is 0 and the total
is odd, or the parity bit is 1 and the total is even, UART knows that the bits in the data
frame have changed.

Stop Bit:
To signal the end of the data packet, UART sends will control the transmission line
from low voltage to high voltage in at least two bit periods. Steps of UART transmission:

• Step 1: UART transmit receives parallel data from the data bus: The data will be
parallel at the input. Then it will be converted to serial to transmit on the TX wire.
The baud rate is set in advance in the configuration section.

Figure 2.12 UART Transmit receives parallel data from the data bus.

20
 • Step 2: UART transmit adds start bit, parity bit, and (stop) bits to the data frame

Figure 2.13 UART Transmit adds start bit, parity bit, and stop bit to the data frame.

• Step 3: The entire packet is serially transmitted from UART transmit to UART
receive. UART receive samples the data line at the configured transmission speed.

Figure 2.14 Packet transmission process.

• Step 4: UART receive removes start bit, parity bit, and stop bits from the data frame:

Figure 2.15 UART receive removes some bits from the data frame.

• Step 5: UART receive converts serial data back to parallel and sends it to the data
bus at the receiving end.

21
 Figure 2.16 Data is sent to the data bus.

2.4.3.3 Advantages and disadvantages of UART communication

• Advantages:

– Uses only two wires

– No need for a clock signal
– Has a parity bit to allow error checking
– The structure of the data packet can be changed
– The method is clearly documented and widely used

• Disadvantages:

– The maximum frame size is limited to 9 bits

– Does not support multiple slaves or multiple master systems
– The transmission speed of each UART must be within 10% of each other

22
2.4.4 Node.js
Node.js is a runtime environment that allows developers to run JavaScript code
outside of a web browser. It is built on Chrome’s V8 JavaScript engine and is designed
to be lightweight, efficient, and scalable for building server-side applications. Node.js
uses an event-driven, non-blocking I/O model, making it ideal for real-time applications
that need to handle a large number of simultaneous connections.

Figure 2.17 Node.js

2.4.4.1 Introduction to Node.js

Node.js plays a crucial role in modern web development, facilitating the creation
of robust, scalable network applications. It utilizes JavaScript as its primary program-
ming language, extending its capabilities beyond the traditional browser environment.
Developers can leverage Node.js to build backend services, APIs, and even full-stack
web applications.

2.4.4.2 Node.js Architecture

Node.js operates on a single-threaded event loop, which allows it to handle asyn-

chronous operations efficiently. This architecture makes it possible to handle multiple
client requests concurrently without spawning new threads for each request, thereby con-
serving system resources and improving scalability.

2.4.4.3 How Node.js Works

23
 Node.js applications are built around modules, which are reusable blocks of code
that encapsulate related functionality. These modules can be easily imported and used
within a Node.js application, fostering code reusability and maintainability. Addition-
ally, Node.js provides a rich ecosystem of third-party packages through npm (Node Pack-
age Manager), enabling developers to extend the functionality of their applications ef-
fortlessly.

2.4.4.4 Advantages and Disadvantages of Node.js

Advantages:
• Scalability: Node.js is well-suited for handling concurrent requests, making it scal-
able for applications with high traffic.

• Performance: Its non-blocking I/O model ensures efficient handling of I/O opera-
tions, resulting in fast response times.

• Rich Ecosystem: Node.js benefits from a vast library of open-source packages avail-
able via npm, enhancing developer productivity.

Disadvantages:
• Single-threaded Nature: While advantageous for many scenarios, Node.js’ single-
threaded model can become a limitation for CPU-intensive tasks.

• Callback Hell: Asynchronous programming in Node.js often involves nesting call-

backs, which can lead to complex and hard-to-maintain code.

2.4.4.5 Use Cases of Node.js

Node.js is particularly well-suited for:

• Real-time Applications: Such as chat applications, online gaming platforms, and

collaboration tools that require instant data exchange.

• APIs and Microservices: Providing backend services that interact with various
clients and third-party services.

• Full-Stack Development: Enabling developers to use JavaScript both on the fron-

tend (with frameworks like React or Angular) and the backend (with Node.js) for
unified development.

24
2.4.5 Docker
Docker is a platform that enables developers to develop, deploy, and run appli-
cations in containers. Containers allow developers to package an application with all
its dependencies into a standardized unit for software development. Docker provides
an efficient and lightweight alternative to virtual machines, offering consistency across
different environments and simplifying the deployment process.

2.4.5.1 Introduction to Docker

Docker has revolutionized the way applications are deployed and managed by in-
troducing containerization. Containers encapsulate an application and its dependencies
into a single package, ensuring that it runs consistently across different computing en-
vironments. Docker utilizes Dockerfiles and Docker Compose to define and manage
container configurations and multi-container applications.

2.4.5.2 Docker Architecture and Components

Figure 2.18 Docker architecture and components

At its core, Docker uses a client-server architecture. The Docker client communi-
cates with the Docker daemon, which manages Docker objects such as images, contain-
ers, networks, and volumes. Docker images serve as the blueprint for containers, while
Docker registries store and distribute Docker images. Key components include Docker
Engine, Docker CLI, Docker Compose, and Docker Hub.

25
2.4.5.3 How Docker Works

Docker containers are lightweight, portable, and self-sufficient, containing every-

thing needed to run an application: code, runtime, system tools, libraries, and settings.
Docker enables developers to build, ship, and run applications swiftly across various en-
vironments—from development laptops to production servers—without worrying about
differences in infrastructure.

2.4.5.4 Advantages and Disadvantages of Docker

Advantages:
• Consistency: Docker containers ensure consistency between development, staging,
and production environments, reducing deployment issues.

• Isolation: Containers isolate applications from each other and from the underlying
infrastructure, enhancing security and resource management.

• Scalability: Docker’s lightweight nature and ease of deployment make it ideal for
scaling applications horizontally.

Disadvantages:
• Learning Curve: Docker introduces new concepts and commands that developers
and operators need to learn and understand.

• Resource Overhead: While containers are lightweight compared to virtual ma-

chines, managing a large number of containers can still incur overhead.

• Complex Networking: Docker networking can be complex, especially in multi-host

and microservices architectures.

2.4.5.5 Use Cases of Docker

Docker is widely used for:

• Microservices Architecture: Breaking down applications into smaller, manageable

services deployed in containers.

• Continuous Integration/Continuous Deployment (CI/CD): Automating the build,

test, and deployment processes for applications.

• Development Environments: Creating reproducible development environments for

teams using Docker-compose and Dockerfile.

26
2.4.6 Cloudflare
Cloudflare is a global content delivery network (CDN), cybersecurity, and internet
security company that provides a range of services to improve the security and perfor-
mance of websites and internet services. It offers solutions such as CDN caching, DDoS
protection, secure DNS services, and more, catering to both small businesses and large
enterprises.

2.4.6.1 How Cloudflare Works

Cloudflare operates by routing website traffic through its global network. It optimizes
delivery by caching content, ensuring fast load times and reducing server load. Security
features analyze incoming traffic, filtering out malicious requests and protecting against
various types of cyber threats, including bot traffic and application-layer attacks.

2.4.6.2 Advantages and Disadvantages of Cloudflare

Advantages:
• Improved Performance: Speeds up website loading times through CDN caching and
optimized routing.

• Enhanced Security: Protects against DDoS attacks, secures DNS, and provides
SSL/TLS encryption.

• Scalability: Scales seamlessly to handle traffic spikes and growing user bases. Dis-
advantages:.

Disadvantages:
• Costs: Advanced features may incur costs, depending on usage and subscription
plans.

• Relying on a third-party service like Cloudflare means potential service disruptions

if there are issues with their network.

27
 CHAPTER 3: HARDWARE AND FIRMWARE SYSTEM
DESIGN FOR SMART HOME

3.1 Hardware System Components

3.1.1 Fire Alarm Block
3.1.1.1 MQ2 sensor

For the fire alarm block, the problem is to detect signs of a fire quickly. Here,
MQ2 sensor was chosen for project, a very popular sensor for fire alarm systems in
smart homes today.
The MQ2 sensor is a type of MOS (Metal Oxide Semiconductor) sensor, operating
based on the change in resistance of the sensor material when exposed to various gases.

Figure 3.1 Structure of MQ2 sensor.

The sensor element is connected with 6 pins forming a star-shaped structure, where
2 H pins are responsible for heating the sensor element and are linked together by a
Nickel Chromium coil - a famous conductive alloy. The other four signal wires (A
and B) are connected to the outermost layer of the sensor element, allowing current to
pass through the sensor element. The sensor element is composed of aluminum oxide
(Al2O3) with a tin oxide (SnO2) coating. Tin oxide is the most important material
because it is sensitive to flammable gases.

29
 Figure 3.2 Structure of the sensor element.

Additionally, the ceramic substrate helps increase heating efficiency and ensures
the sensor area is continuously heated to the working temperature. When the SnO2
semiconductor layer is heated to the working temperature, oxygen is absorbed on its
surface. In clean air, electrons from the tin oxide conduction band are attracted to oxygen
molecules, resulting in a depletion of charge just below the surface of the SnO2 particles.
Consequently, the SnO2 film has high resistance, obstructing the current. However,
when the oxygen decreases, electrons are released into the tin oxide layer, allowing the
current to flow freely through the sensor.

Figure 3.3 MQ2 sensor module.

30
 The MQ2 sensor module includes 2 power pins (VCC and GND) and 2 signal
pins (D0 and A0). It can output both binary signals (0,1) for the presence of gases and
analog signals for their concentration in the air through pin A0. The higher the gas
concentration, the higher the output voltage from pin A0 and vice versa. Additionally,
the module includes a potentiometer to adjust the sensitivity of the D0 digital output,
enabling the setting of a threshold where, if exceeded, pin D0 will output a low signal
(0). The MQ2 sensor module operates at a voltage range from 3.3V to 5V, consuming
about 800mW. It can detect gases such as LPG, smoke, alcohol, propane, hydrogen,
methane, and carbon monoxide in the range of 200 to 10000 ppm.

Table 3.1 Technical specifications of the MQ2 sensor.

Characteristic Details
Operating Voltage 3.3 V - 5V
Power Consumption < 800 mW
Sensor Resistance 10 kΩ − 60lΩ
Concentration Range 200 - 10000 ppm

3.1.1.2 Fire sensor and alarm

To ensure reliability, a fire sensor module has been chosen. The fire sensor module
is crucial in safety and firefighting applications. With an operating voltage from 3.3V
to 5V, a current consumption of 15mA, providing digital output signals of 3.3V to 5V
depending on the power supply or analog output, the module can easily detect fire and
flame light. The sensor’s detection angle is about 60 degrees, allowing it to monitor a
wide range.

Figure 3.4 Fire sensor module.

31
 Advantages of the Fire Sensor Module:

• High sensitivity: The module can detect flames from a distance and in low-light
conditions.

• Easy integration: The module provides both digital (Digital) and analog (Analog)
signals, making it easy to integrate into control systems.

• Adjustable detection distance: You can adjust the detection distance by turning the
adjustment screw on the module. This helps customize the flame detection distance
according to the application’s needs.

• Diverse applications: The fire sensor module is often used in firefighting robots,
fire alarm systems, and other safety applications.

With the ability to detect fire and flexibility in application, the fire sensor module
becomes a useful tool for protecting and ensuring safety in applications.
Moreover, to notify homeowners and those around them, adding alarm speakers
and sirens is essential for early fire detection and locating the fire, thus reducing the
consequences of fire and explosion.

Figure 3.5 Fire alarm speakers and sirens.

3.1.2 Temperature and Humidity Block

The temperature and humidity block provides users with environmental tempera-
ture and humidity data within the house. Currently, there are two types of temperature
and humidity sensors, DHT11 and DHT22, which are quite popular. Among them, the
DHT22 sensor offers higher reliability and accuracy.

32
 Figure 3.6 DHT22 sensor.

The DHT22 sensor includes 4 pins, with 2 power pins (VCC and GND), a Data pin
for communication between the microcontroller and the sensor, and the remaining NC
pin is not connected.

Table 3.2 Technical specifications of the DHT22 sensor

Characteristic Details
Model DHT22
Power supply 3.3 - 6V DC
Output signal digital signal via single-bus
Sensing element Polymer capacitor
Operating range humidity 0-100%RH; temperature -108̃0 Celsius
Accuracy humidity ±2%RH(±5%RH);temperature0.5Celsius
Resolution or sensitivity humidity 0.1%RH; temperature 0.1 Celsius
Repeatability humidity ±1%RH;temperature ± 0.2Celsius
Humidity hysteresis ±0.3%RH
Long-term Stability ±0.5%RH/year
Sensing period Average: 2s
Interchangeability fully interchangeable
Dimensions small size 14*18*5.5 mm; big size 22*28*5 mm

33
3.1.3 Electrical Device Control Block
The aim is to control the on/off state of electrical devices consuming the standard
220V household current. Therefore, 5V relays will be used to connect to two personal
outlets so the homeowner can control any device (light bulbs, electric fans, phone charg-
ers, etc.) within the allowed power range.

Figure 3.7 Relay 5V 10A SRD 05VDC-SL-C

Technical specifications: Voltage – maximum switching current: 250 VAC – 10A.

Control voltage: 5V. To control the relay switching through the microcontroller, through
the microcontroller with dimensions 12x12x7.3mm push buttons.

Figure 3.8 12x12x7.3mm physical push buttons

34
3.1.4 Password Entry Block
For the password block, the product needs an easy and convenient method for user
interaction to authenticate and open the door. Therefore, a 4x4 keypad matrix is used for
password entry.

Figure 3.9 Structure of the 4x4 keypad matrix

The 4x4 keypad matrix uses 8 IO pins to communicate with the microcontroller,
recognizing input characters.

3.1.5 Display Block

To allow user interaction with devices, the LCD1602 module is used to combine
with the I2C module to display information such as temperature, humidity, entered pass-
words, and instructions during fingerprint registration.

Figure 3.10 LCD1602 module and I2C module

If only the LCD1602 module is used, 8 IO pins are needed to communicate with
the microcontroller. However, when combined with the I2C module, only 2 IO pins
(SDA and SCL) are required, significantly saving the number of pins used.

35
3.1.6 AS608 Fingerprint Sensor
The AS608 is a popular and powerful fingerprint storage module. It has a robust
32-bit Arm Cortex M architecture with a 4KB cache, a working frequency of 144MHz,
512KB flash, and 128KB RAM, equipped with USB 2.0 and UART interfaces for easy
connection with various microcontrollers.

Figure 3.11 AS608 fingerprint sensor module

With characteristics such as an operating voltage range from 3.6V to 6V, a current
consumption of about 120mA-150mA, and a UART protocol suitable for most current
microcontrollers, the fingerprint recognition time is less than 1 second, the storage ca-
pacity is large enough to store up to 162 fingerprints, and the fingerprints are stored in
Flash memory, ensuring they are not lost during unexpected power outages. All these
features meet the design requirements of a low-power consumption fingerprint recog-
nition module, simple communication, large storage space, and retention of fingerprint
data during power outages.

36
3.1.7 LY – 03 Electromagnetic Lock
The electromagnetic lock operates similarly to a traditional door lock but uses a
solenoid to electrically activate the locking mechanism. This technology is widely uti-
lized in various applications, including smart homes, room doors, warehouses, cabinets,
and more. The LY-03 electromagnetic lock, specifically, relies on a 12VDC power sup-
ply. It is designed to be normally closed, meaning the door remains locked when the
solenoid is not energized. This lock is known for its good quality and high durability,
making it a reliable choice for securing different types of entry points. Its robust con-
struction ensures long-lasting performance, providing an effective and efficient solution
for modern security needs.

Table 3.3 Technical specifications of the LY – 03 electromagnetic lock

Characteristic Details
Material Stainless Steel
Operating Voltage 12 VDC
Working Current 0.8 A
Power 9.6 W
Power Supply Requirement 12V, 1A
Dimensions 55mm x 38mm x 23mm
Weight 150g

Figure 3.12 LY-03 electromagnetic lock

37
3.1.8 PIR HC-SR501 motion sensor
Additionally, to be able to detect people or moving objects, enhancing the security
of the system, the PIR HC-SR501 motion sensor module is used to detect the movement
of objects that emit infrared radiation (humans, animals, heat-emitting objects, etc.).
The sensor’s sensitivity can be adjusted to limit the detection distance and the intensity
of the desired object’s radiation. Moreover, the sensor can also adjust the delay time
(how long the signal is held after activation) through the built-in potentiometer. The PIR
HC-SR501 motion sensor module features a high-quality sensor, lens, and circuit board
for the highest sensitivity and durability.

Figure 3.13 PIR HC-SR501 motion sensor

Table 3.4 Technical specifications of the PIR HC-SR501 motion sensor

Characteristic Details
Detection range 360-degree cone angle, maximum distance of 6m
Operating temperature 32-122 °F (0-50 °C)
Operating voltage DC 3.8V – 5V
Current consumption ≤ 50µA
Signal duration 30 seconds, adjustable by potentiometer
Sensitivity adjustable by potentiometer Yes
Mode L Yes

38
3.1.9 SIM GA6-B Mini Module

Figure 3.14 SIM GA6-B Mini Module

To meet the requirements of a smart home system capable of fire alarms, it is

essential to ensure that alerts reach homeowners even under weak network conditions
and when they are not connected to the internet. The SIM GA6-B Mini Module is an
ideal solution for this need. This module supports GSM communication, allowing it to
send alerts via calls or text messages regardless of the homeowner’s internet connection
status. Main functions of the SIM GA6-B Mini Module:

• Supports 4 GSM bands: GSM850MHz, EGSM900MHz, DCS1800MHz, PCS1900MHz

• Supports GPRS class 10

• Make/receive calls, send/receive messages

• Has speaker and mic pins for direct calling

• Fully controlled via UART interface with AT command set via URX and UTX pins

• Uses microSIM

39
 Table 3.5 Technical specifications of the SIM GA6-B Mini Module

Characteristic Details
Operating frequency quad-band network, 850/900/1800/1900MHz
Operating voltage 4.5 5.5VDC
Operating current max 2A
Sleep current 5mA
Micro SIM card support on the board Yes
Interface communication TTL serial port
Transmission speed 115200bps, can also be set by AT command
Logic interface voltage 3.3V
Antenna Frequency 780MHz 960MHz, 1710MHz 2170MHz
Antenna gain +2.0 ± 0.7 dBi @ 880 MHz, +2.0 ± 0.7 dBi @ 1800 MHz
S.WR ≤ 2.0@2100MHz 2500MHz
Output impedance 50 Ω

3.2 System Control Circuit Design

3.2.1 Door Lock Control Block

Figure 3.15 Schematic diagram of the door lock block

40
Figure 3.16 Bottom view of the PCB of the door lock block

Figure 3.17 Top view of the PCB of the door lock block

41
3.2.2 Room Control Block

Figure 3.18 Schematic diagram of the room control circuit

Figure 3.19 Bottom view of the PCB of the room control block

42
Figure 3.20 Top view of the PCB of the room control block

43
3.3 Firmware System Design
3.3.1 Smart Door Lock Block
3.3.1.1 Objectives

The goal of the automatic door lock unit is to provide a smart and convenient
security solution for the home. This system helps protect the home from external threats
by automatically and flexibly controlling the locking/unlocking of doors. The specific
objectives of the automatic door lock unit include:

• Security Protection: The automatic door lock system must ensure the safety of the
home by allowing only authorized individuals to unlock the door. This helps prevent
unauthorized intrusions.

• User Convenience: The system must be easy to use, allowing users to unlock the
door through various methods such as mobile apps, RFID cards, or passcodes.

• Automation: The system needs to be able to automatically lock/unlock the door

based on specific scenarios such as when the user leaves or approaches the door, or
according to a preset schedule.

• Communication with the Central System: The door lock system must be able to
communicate with the smart home central system to provide information and re-
ceive remote control commands.

• Durability and Reliability: The system design must ensure long-term stable op-
eration, withstand various environmental conditions, and have security measures
against external attacks.

By achieving these objectives, the automatic door lock unit will contribute to a
comprehensive smart home system, enhancing security and providing maximum conve-
nience for users.

3.3.1.2 Processes Design

Initialization
The system will first initialize the necessary modules and peripherals such as flash
memory, UART, Wi-Fi, GPIO, and the operating system tasks.

44
 Figure 3.21 System Diagram of the Firmware for the Door Lock Unit

Task Management
Two main tasks run almost in parallel, with other tasks in a waiting state until an
event triggers them.

• UART Task: The UART task is responsible for managing data communication with
the fingerprint sensor module. This includes reading incoming data, transmitting
commands and data, and parsing received information.

Figure 3.22 UART Task

45
• Keyboard Task: The keyboard task scans the keypad to check if any key is pressed.
If a key is pressed, it performs the corresponding function, such as sending an event
to the password task or writing to the password buffer.

Figure 3.23 Keyboard Task

46
 • Fingerprint Task: This task reads and transmits data to the fingerprint sensor mod-
ule via the UART task to capture images from the sensor, then compares them with
registered fingerprints or registers new fingerprints.

(a) Flowchart of Fingerprint Registra- (b) Flowchart of Verification Process

tion

Figure 3.24 Fingerprint Flowcharts

47
 Figure 3.25 Fingerprint Management Task

• Password Task: This task checks if the entered password matches the setup pass-
word or changes the password.

Figure 3.26 Password Task

48
 • LCD Task: This task displays information such as whether the entered password is
correct, whether the password was successfully changed, or whether the fingerprint
has been registered.

• Communication Task: This task communicates and sends data to the web.

Figure 3.27 Communication Task

3.3.1.3 Operational Steps

Unlocking with Keypad:

• Press the ’*’ key.

• Enter the password.

• Press the ’#’ key.

Changing the Password with Keypad:

• Press and hold the ’*’ key for 3 seconds.

• Enter the old password

• Press the ’#’ key.

• Enter the new password

• Press the ’#’ key.

• Re-enter the new password

• Press the ’#’ key.

49
Unlocking with Fingerprint:
• Place your finger on the sensor.

• Wait for the door to unlock.

Registering a New Fingerprint:

• Press and hold the ’#’ key.

• Enter the correct password

• Press the ’#’ key.

• Place the finger to be registered on the sensor and wait until the screen displays
success.

To delete all registered fingerprints:

• Press and hold the “D” button until the LCD displays “put your finger.”

• Place a registered fingerprint on the sensor.

• Press the “D” button again until the LCD shows “delete All.”

To delete a specific registered fingerprint:

• Press and hold the “C” button until the LCD displays “put your finger.”

• Place the fingerprint you want to delete on the sensor.

• Press and hold the “C” button once more.

Check the Number of Registered Fingerprints:

• Press and hold the ’B’ button.

50
3.3.2 Environmental Monitoring Block (Temperature, Humidity, Gas, CO)
3.3.2.1 Objectives

The objective of the environmental monitoring unit is to provide crucial informa-

tion about indoor environmental conditions and issue early warnings in case of incidents,
thereby protecting the health and safety of residents. The specific objectives of this unit
include:

• Environmental Monitoring: The system must accurately measure environmental

parameters such as temperature, humidity, and gas concentration. This information
helps users control and maintain a comfortable and safe living environment.

• Communication with the Central System: The monitoring and fire alarm system
must be able to communicate with the smart home central system to provide data
and receive remote control commands. This creates a comprehensive monitoring
and protection system.

• Durability and Reliability: The system must ensure stable and accurate operation
under all environmental conditions. Sensors and devices need to be designed to
withstand environmental impacts and operate reliably over a long period.

• By achieving these objectives, the temperature, humidity, gas, and fire alarm mon-
itoring unit will play a crucial role in enhancing the quality of life and ensuring the
safety of residents in a smart home.

3.3.2.2 Processes Design

Figure 3.28 Air quality measure diagram

51
 The two main sensors of the unit are the DHT22 and MQ2. Below are the program
reading data from DHT22:

• Initialization:

Figure 3.29 Sensor initialization pulse

The red line represents the signal from the microcontroller, while the blue line indi-
cates the signal from the DHT22 sensor. To initialize the sensor, the microcontroller
must pull the data line LOW for at least 18 ms. This step ensures that the DHT22
recognizes the start signal from the microcontroller. After holding the data line
LOW for the required duration, the microcontroller should then pull the data line
HIGH for approximately 20-40 µs. Upon receiving this start signal, the DHT22
will acknowledge by first pulling the data line LOW for 80 µs. Immediately after
this, the DHT22 will pull the data line HIGH for another 80 µs. This sequence of
signals from the DHT22, transitioning from LOW to HIGH, confirming that the
sensor is now ready to transmit data to the microcontroller.

– Set the pin (data) as output.

– Pull the pin low and wait for 18 ms.
– Pull the pin high and wait for 20-40 µs.
– Release the pin by setting it as input.

DHT22 will now send the response as you can see in the figure above. To check the
response, steps are as follows:

– Wait for 40 µs.

– Check if the pin is low, then wait for 80 µs (total delay of 120 µs); the pin should
now be high.
– Check if the pin is high. If it is, the response is OK.
– Wait for the pin to go LOW.

52
 • Data Transmission:

Figure 3.30 Data representation pulse

– DHT22 will send 40 bits of data. Each bit’s transmission begins with a low-
voltage level lasting 50 µs, followed by a high-voltage level determining whether
the bit is "1" or "0".
– High-voltage level of 26-28 µs indicates bit "0".
– High-voltage level of 70 µs indicates bit "1".
– The 40 bits sent by DHT22 are: 8-bit integral RH data + 8-bit decimal RH data
+ 8-bit integral T data + 8-bit decimal T data + 8-bit checksum.
– If the data transmission is correct, the checksum should be the last 8 bits of
"8-bit integral RH data + 8-bit decimal RH data + 8-bit integral T data + 8-bit
decimal T data".

• Reading Data from MQ2: The data measured by MQ2 is an analog signal, so the
ADC of ESP32 is used to convert the analog signal to a digital signal. First, the
ADC with a 12-bit resolution is initialized. After reading the signal converted by
the ADC, the manufacturer’s provided formulas are clarified to calculate values for
CO gas, LPG gas, and smoke.

3.3.3 Alarm and Fire Detection Block

3.3.3.1 Objectives

• Early Fire Detection: The system must be able to detect early signs of fire, such
as sudden increases in temperature or gas concentration exceeding safe thresholds.
This helps minimize the risk and damage caused by fire.

• Timely Alerts: When detecting abnormal conditions, the system must immediately
issue alerts so users can take timely action. Alerts can include sound, light, and
mobile app notifications.

53
3.3.3.2 Processes Design

The fire alarm unit checks data from the fire sensor and reads data from the envi-
ronmental monitoring unit, such as gas, smoke, and high temperature. If the readings
reach dangerous thresholds, the system will:

• Alert users and turn off all electrical devices.

• Make emergency calls and send messages to users for timely evacuation or fire-
fighting.

• Activate the fire alarm siren to alert surrounding people continuously.

Figure 3.31 Fire Alarm Block

54
3.3.4 Device Control Block

Figure 3.32 Control Block

Home devices can be turned on and off through two main methods: using physical
buttons or via mobile apps and web interfaces. Additionally, lights will automatically
turn on when motion is detected.

55
 CHAPTER 4: DEVELOPING SOFTWARE SYSTEM FOR
SMART HOME CONTROL

4.1 Building a Database System Using SQLite

4.1.1 Overview of SQLite
SQLite is a relational database management system (DBMS) similar to MySQL,
etc. A prominent feature of SQLite compared to other DBMS is its compactness, light-
ness, simplicity, and notably, it does not require a server-client model. There is no need
for installation, configuration, or startup, thus there are no concepts of user, password,
or permissions in SQLite Database. Data is stored in a single file. While SQLite is
often not used for large systems, it is on par with other DBMS in terms of functional-
ity and speed for medium and small-scale systems like the current smart home systems.
Due to its lack of installation or configuration requirements, SQLite is widely used in
development, testing, etc., avoiding the complications during setup.

Features of SQLite:
• Transactions in SQLite adhere to the ACID principles even after system crashes and
power outages.

• No configuration: no setup or administration is required.

• SQLite supports full-featured capabilities with advanced features such as partial

indexes, expression indexes, JSON, and common table expressions.

• A complete database is stored in a single cross-platform file, suitable for use as an

application file format.

• Supports databases of terabyte sizes and strings of gigabyte sizes.

• API: Simple and easy to use.

• Fast: In some cases, SQLite is faster than direct file system I/O.

• Written in ANSI-C.

• Bindings for dozens of other languages are available separately.

• Full source code, open source, and 100% verifiable.

• Cross-platform: SQLite is available on Android, *BSD, iOS, Linux, Mac, Solaris,

and Windows.

57
4.1.2 Database Design for Control Systems
4.1.2.1 User Information

User information will be stored in the "t_user" table in the database.

Figure 4.1 User Account Database

t_user
The t_user table contains information about users. Each user record includes:

• id: A unique identifier for the user.

• firstname: The first name of the user.

• lastname: The last name of the user.

• selector: A unique string used to identify the user.

• email: The email address of the user, which must be unique.

• birthdate: The birthdate of the user.

58
4.1.2.2 Dashboard Information

Figure 4.2 Dashboard Table

t_dashboard
The t_dashboard table contains information about user dashboards. Each dash-
board record includes:

• id: A unique identifier for the dashboard.

• name: The name of the dashboard, which must be unique.

• type: The type of the dashboard.

• selector: A unique string used to identify the dashboard.

• boxes: A JSON field containing the configuration of the dashboard’s boxes.

• created_at: The timestamp when the dashboard was created.

• updated_at: The timestamp when the dashboard was last updated.

• color: An optional color associated with the dashboard.

• user_id: The ID of the user who owns the dashboard.

59
4.1.2.3 Device

Figure 4.3 Device Table

t_device
The t_device table contains information about devices. Each device record in-
cludes:

• id: A unique identifier for the device.

• service_id: The ID of the service to which the device belongs.

• room_id: The ID of the room where the device is located.

• name: The name of the device.

• external_id: A unique identifier for the device, used externally.

• created_at: The timestamp when the device was created.

• updated_at: The timestamp when the device was last updated.

60
4.1.2.4 House

Figure 4.4 House Table

t_house
The t_house table contains information about houses. Each house record includes:

• id: A unique identifier for the house.

• name: The name of the house, which must be unique.

• selector: A unique string used to identify the house.

• latitude: The latitude coordinate of the house.

• longitude: The longitude coordinate of the house.

• created_at: The timestamp when the house was created.

• updated_at: The timestamp when the house was last updated.

4.1.2.5 Room

Figure 4.5 Room Table

61
t_room
The t_room table contains information about rooms in houses. Each room record
includes:

• id: A unique identifier for the room.

• house_id: The ID of the house to which the room belongs.

• name: The name of the room, which must be unique.

• selector: A unique string used to identify the room.

• created_at: The timestamp when the room was created.

• updated_at: The timestamp when the room was last updated.

4.1.2.6 Data Model

Below figure presents the comprehensive data model of the system, detailing the
structure and relationships of the database tables described previously

Figure 4.6 Data Model

62
4.2 Smart Home containerization using Docker
4.2.1 Benefits of using Docker in Smart Home
Docker is a platform that enables developers to automate the deployment of appli-
cations inside lightweight, portable containers. These containers encapsulate everything
an application needs to run (code, runtime, libraries, and settings), ensuring consistency
across development, testing, and production environments.

By utilizing the ability of Docker, Smart Home benefit from:

• Portability: Docker containers can run on any platform that supports Docker, mak-
ing it easy to deploy Smart Home across different hardware setups, from personal
computers to Raspberry Pi devices.

• Consistency and Reliability: Containers ensure that the Smart Home software runs
consistently in any environment, eliminating issues caused by differences in device
configurations or dependencies.

• Version Control and Rollback: Docker images can be versioned, allowing develop-
ers to track changes, roll back to previous versions, and ensure that specific versions
of Smart Home are deployed. This helps maintain stability and quickly revert to a
known good state if issues arise.

• Automated Updates: Using tools like Watchtower, Smart Home containers running
in a user’s home can automatically update themselves when a new version is de-
ployed. This ensures that the software is always up-to-date with the latest features
and security patches without requiring manual intervention.

• Resource Efficiency: Containers are lightweight and share the host operating sys-
tem’s kernel, making them more efficient in terms of system resources compared to
traditional virtual machines. This is particularly beneficial for Smart Home devices
with limited resources.

• Speed: Containers can be created and started much faster than virtual machines,
enabling rapid development cycles and quick deployment.

• Integration with CI/CD Pipelines: Docker integrates well with Continuous Inte-
gration/Continuous Deployment (CI/CD) tools, enabling automated testing and de-
ployment pipelines. This streamlines the development process and reduces time to
market for new features and updates.

63
4.2.2 Deploy Smart Home with Docker
• Docker uses a file called Dockerfile to automate the building of Docker images by
specifying the environment and instructions for creating the image.

Figure 4.7 Dockerfile for building Smart Home container

• Docker Compose is a tool to define and run multi-container Docker applications

using a YAML file for configuration

Figure 4.8 YAML file for using and configuring Smart Home container

64
4.3 Control System Features
4.3.1 Initialization Process upon System Startup

(a) Welcome page (b) Create user

(c) Unit setting (d) Create House

Figure 4.9 Startup progress

The sign-up process is designed to gather essential information from the user to
create a personalized experience and ensure proper account setup. Initially, users are
required to fill in some basic information, which includes:

• Name.

• Email address.

• Preferred language.

• Login password.

• Units of preference.

Once the basic information is submitted, users proceed to configure their house
within the application. Users are required to provide the location of the house, an unique
name to their house and add rooms to the house.
Users can update and modify all provided information at any later stage, ensuring
that their account and house setup remain accurate and up-to-date.

65
4.3.2 Dashboard
The dashboard is the main page of Smart Home. This page is fully configurable
and you can tweak it to meet your needs.

Figure 4.10 Dashboard

4.3.2.1 Weather

With the intergration of OpenWeather API, user can display the weather forecast
on Smart Home dashboard.

Figure 4.11 Weather Forcast

66
4.3.2.2 Camera

Smart Home supports cameras that expose a RTSP or HTTP stream. Use the cam-
era stream, user can display images from their cameras, straight on the dashboard. These
images are refreshed at regular intervals. User can specify the interval in the camera
configuration and view the camera’s live video feed using the "Live" button.

(a) Camera Display (b) Camera Configuration

Figure 4.12 Camera

4.3.2.3 Devices in room

In Smart Home, user can control their devices directly from the dashboard, and
display the values of the sensors in the interface.

(a) Devices Configuration (b) Devices in Room Display

Figure 4.13 Devices in room

67
4.3.2.4 Charts

User can display a sensor chart on the dashboard. In the dashboard edit page, select
the device want to display here, and :

Figure 4.14 Chart Configuration

The configuration parameters of the chart include:

• Name: It’ll be display on top of the chart.

• Chart type: Different types of chart (line, area, bar, step line).

• Axes: If user want a display without axes, or if they prefer to see the x/y axis.

• Display variation: If selected, the chart will display the relative variation between
the first and last value in the selected interval.

68
 Figure 4.15 Example charts which display sensor and temperate data

4.3.3 MQTT
MQTT allows user to send a value to Smart Home from a connected device (e.g.
a temperature sensor taking temperature readings every 10 minutes). User can also use
MQTT to send a home automation command from Smart Home to a peripheral.
Smart Home therefore implements a MQTT API in both directions:

• Peripheral to Smart Home

• Smart Home to Peripheral

4.3.3.1 Setup MQTT Broker

By leveraging Docker, a Smart Home system can automate the deployment of a

Mosquitto Broker container. This capability facilitates seamless server connectivity with
peripheral devices through MQTT, enhancing reliability and scalability in managing IoT
communications.

Figure 4.16 Set up MQTT Broker

69
4.3.3.2 Setup device

Figure 4.17 MQTT Device setting

Smart Home support many device features to display such as air quality sensor,
camera, CO, CO2 sensor, temperature sensor, distance sensor, humidity sensor, gas leak
sensor, light sensor, presence sensor, speed sensor, volumn sensor ...

4.3.4 Bluetooth

(a) Bluetooth Scan (b) Connect bluetooth device

Figure 4.18 Bluetooth in Smart Home

By using the noble library, a Smart Home system can scan for nearby Bluetooth-
enabled devices and connect to them via their UUIDs. This process involves initializing

70
the library, starting the scan when Bluetooth is powered on, identifying and selecting
target devices based on their UUIDs, and then establishing a connection. Once con-
nected, the system can interact with the devices’ services and characteristics, enabling
comprehensive management and communication with the Bluetooth peripherals.

4.3.5 Setup camera

Smart Home supports cameras that expose a RTSP or HTTP stream. User need to
find the camera’s URL, it usually in their device’s user manual or on the manufacturer’s
website. In this project, Raspberry Pi Module V3 camera is used, it’s stream can be
obtain by using libcamera-vid command to expose to a URL.

Figure 4.19 Camera Setting

4.3.6 Chat
By leveraging the Natural Language Processing, a chat bot in Smart Home system
can effectively interpret and map user request contexts to specific commands that control
various home devices. This allows users to interact with their home environment in a
more intuitive and natural manner. However, due to the current hardware limitations
in the project, the only ability to demonstrate this feature through the Chat section of
the Smart Home application. Despite these limitations, users can still experience the
convenience and functionality of commands. For example, a user can request to view
the camera feed in the kitchen by simply saying, "Show me the camera image in the
kitchen." This capability illustrates how NLP can enhance user interaction and control
within a Smart Home system.

71
 Figure 4.20 Using chat bot to process user’s request

4.3.7 Scene
User can create scenes in Smart Home system. These are a set of actions executed
consecutively or in parallel. The scenes are entirely customizable: the users create their
own action suites in the scene editor. These scenes can be triggered manually, automati-
cally (via a trigger) or from another scene.

(a) Create Scene (b) Set up scene

Figure 4.21 Scene system in Smart Home

The scene system contains 2 blocks with differents behaviour:

• Triggers Block: If user add triggers to the scene (this is optional), the scene can be
triggered by several different triggers. These triggers are all independent.

• An action block: a scene is split into one or more action blocks. When user add
actions to this action block, all actions in the block will run in parallel. If user add

72
 actions to the next action block (not visible in this screenshot), the scene will wait
until action block 1 is finished before moving on to the next one. You can therefore
run actions in parallel and in a sequence.

Some scene examples

4.3.7.1 A "Make coffee every week day" scene, which would turn on the coffee machine
in every morning and turn off it after done making coffee.

Figure 4.22 Add a trigger block to run the scene on every week day morning.

Figure 4.23 Add the turn on switch action (required device to be connected via switch
feature) and add a wait action for 30 minutes.

73
 Figure 4.24 Finally add a turn off switches action.

4.3.7.2 An "Gas alert" scene, which sends a Telegram message to the user. This scene
would be configured to run after an "gas leak" trigger.

Figure 4.25 Add a trigger to check gas data for every 5 seconds.

74
 Figure 4.26 Get both CO and LPG data.

Figure 4.27 Only continue action if the CO and LPG data is higher than some value.

75
Figure 4.28 Send the alarm message to user via both Chat and Telegram.

(a) Alarm message in Smart Home Chat

(b) Alarm message in Telegram

Figure 4.29 Alarm Message

76
4.3.8 User Interface on mobile

(a) Login (b) Password recover

Figure 4.30 UI example on mobile

(a) Dashboard (b) Charts

Figure 4.31 UI example on mobile

77
(a) Intergrations (b) Intergrations

Figure 4.32 UI example on mobile

(a) Map (b) Scenes

Figure 4.33 UI example on mobile

78
 (a) Chat (b) Settings

Figure 4.34 UI example on mobile

(a) System Management (b) Systems Management

Figure 4.35 UI example on mobile

79
 CHAPTER 5: CONCLUSIONS

5.1 Achieved Results

Our project applies IoT, which is a current trend in the Industry 4.0 era. With
passion and enthusiastic guidance from our teacher, along with our efforts in exploring
and discovering new things, we have achieved the following results:

• Built a smart home model.

• Developed an application to control the smart home.

• Created a website for smart home control.

• Established a local network within the control system before deploying it to the
internet.

• Designed and controlled communication between microcontrollers and sensor de-

vices, peripherals.

• Achieved fast fire alarm responses that meet the design expectations, capable of
alerting homeowners and surrounding people.

• Conducted practical experiments and evaluated the results.

5.2 Future Development Directions of the Project

The control and monitoring system over the internet holds significant importance
in various aspects of life, such as security, national defense, livestock, healthcare, family,
and agriculture. Mastery of this area still faces certain limitations, especially for a de-
veloping country like ours in terms of science and technology. Through this project, we
aim to utilize the knowledge gained during our student years to approach the technology
and trends of the world.
From this project, we propose several future development directions for the system:

• Integrate into monitoring and warning systems of apartment buildings.

• Propose cooperation with the fire prevention and fighting department for efficient
and prompt fire detection and handling.

• Expand the system’s control capabilities.

81
 • Improve the user interface for web-based control.

• Enhance the system’s security.

Although we have achieved certain results, there are still some limitations and in-
evitable shortcomings. We sincerely hope to receive feedback from teachers and readers
to improve this project further.
We would like to express our heartfelt thanks!

Hanoi, 24/06/2024

82
 REFERENCES

[1] Node.js. (n.d.). Retrieved April 10, 2024, from https://nodejs.org/

[2] Docker. (n.d.). Retrieved March 29, 2024, from https://www.docker.com/

[3] Cloudflare. (n.d.). Retrieved April 12, 2024, from https://www.cloudflare.

com/

[4] Eclipse Mosquitto. (n.d.). Retrieved March 30, 2024, from https://mosquitto.
org/

83