UỶ BAN NHÂN DÂN
THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC SÀI GÒN
BÁO CÁO TỔNG KẾT
ĐỀ TÀI NGHIÊN CỨU KHOA HỌC CỦA SINH VIÊN
TÊN ĐỀ TÀI: XÂY DỰNG HỆ THỐNG QUẢN LÝ NHÀ THÔNG MINH ỨNG
DỤNG DEEPLEARNING
Mã đề tài: SV2024-106
Thuộc nhóm ngành khoa học: Công nghệ thông tin
Chủ nhiệm đề tài: Nguyễn Nhật Nam
Thành viên tham gia:
3122410251: Trần Nhật Nam
3122419252: Nguyễn Thành Nam
3122410248: Nguyễn Nhật Nam
Giáo viên hướng dẫn: ThS Hà Thanh Dũng
ỦY BAN NHÂN DÂN
THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC SÀI GÒN
BÁO CÁO TỔNG KẾT
ĐỀ TÀI NGHIÊN CỨU KHOA HỌC SINH VIÊN
TÊN ĐỀ TÀI: XÂY DỰNG HỆ THỐNG QUẢN LÝ NHÀ THÔNG MINH ỨNG
DỤNG DEEPLEARNING
Mã đề tài: SV2024-106
Xác nhận của
Chủ nhiệm đề tài
Chủ tịch hội đồng nghiệm thu
(kí, họ tên)
(Ký, họ tên)
Thành phố Hồ Chí Minh, ngày 02 tháng 4 năm 2022
LỜI CẢM ƠN
Trên thực tế không có sự thành công nào mà không gắn liền với những sự hỗ
trợ, giúp đỡ dù ít hay nhiều, dù trực tiếp hay gián tiếp của người khác. Trong suốt
thời gian từ khi bắt đầu thực hiện đến nay, chúng em đã nhận được rất nhiều sự quan
tâm, giúp đỡ của giáo viên hướng dẫn, gia đình và bạn bè.
Với tình cảm sâu sắc và chân thành nhất, em tỏ lòng biết ơn đến thầy Hà
Thanh Dũng– người đã tận tình hướng dẫn, nhận xét và góp ý giúp chúng em hoàn
thành đề tài nghiên cứu này.
Đồng thời, trong quá trình làm bài nghiên cứu, do trình độ lý luận cũng như
kinh nghiệm thực tiễn còn hạn chế nên cũng không thể tránh khỏi những thiếu sót,
chúng em rất mong nhận được ý kiến đóng góp từ phía thầy cô để em có thể học hỏi
được nhiều kinh nghiệm.
Cuối cùng, chúng em xin dành lời cảm ơn chân thành đến gia đình, bạn bè –
những người đã tận tình giúp đỡ và hỗ trợ em trong suốt thời gian học tập và nghiên
cứu đề tài khóa luận này. Em xin chân thành cảm ơn
LỜI CAM ĐOAN
Em xin cam đoan báo cáo nghiên cứu khoa học này là kết quả nghiên cứu,
tìm hiểu của tụi em, được thực hiện dưới sự hướng dẫn khoa học của Giảng viên
hướng dẫn THS. Hà Thanh Dũng, đảm bảo tính trung thực về các nội dung báo
cáo. Những số liệu trong các bảng biểu phục vụ cho việc phân tích, nhận xét,
đánh giá được chính tác giả thu thập từ nhiều nguồn khác nhau và có ghi rõ
trong phần tài liệu tham khảo.
Ngoài ra, trong bài báo cáo còn sử dụng một số nhận xét, đánh giá cũng
như số liệu của các tác giả khác, cơ quan tổ chức khác đều có trích dẫn và chú
thích nguồn gốc.
Nếu phát hiện có bất kỳ sự gian lận nào chúng em xin hoàn toàn chịu
trách nhiệm về nội dung bài nghiên cứu của mình. Trường Đại học Sài Gòn
không liên quan đến những vi phạm tác quyền, bản quyền do chúng em gây ra
trong quá trình thực hiện (nếu có).
Ngày 02 tháng 04 năm 2025
Chủ nhiệm đề tài
Nguyễn Nhật Nam
Mục lục
Danh mục hình ảnh ........................................................................................................ iv
Danh mục từ viết tắt....................................................................................................... vii
MỞ ĐẦU .......................................................................................................................... 1
1.
Tính cấp thiết của đề tài....................................................................................... 1
2.
Lịch sử nghiên cứu vấn đề.................................................................................. 1
3.
Mục đích và nhiệm vụ nghiên cứu....................................................................... 2
4.
Đối tượng và phạm vi nghiên cứu ....................................................................... 3
4.1 Đối tượng nghiên cứu ........................................................................................ 3
4.2 Phạm vi nghiên cứu ........................................................................................... 3
5.
Phương pháp nghiên cứu ................................................................................... 4
6.
Những đóng góp của đề tài ................................................................................. 4
7.
Kết cấu đề tài ....................................................................................................... 4
CHƯƠNG 1. TỔNG QUAN VỀ ĐỀ TÀI VÀ CƠ SỞ LÍ THUYẾT ......................................... 5
1
Giới thiệu ............................................................................................................. 5
1.1 Internet of thing (IoT).......................................................................................... 5
1.2
React native và expo .................................................................................... 7
1.3
Firebase ........................................................................................................ 8
1.4
MQTT ............................................................................................................ 9
1.5
Websocket .................................................................................................. 11
1.6
Facenet ....................................................................................................... 11
Phương pháp thực hiện .................................................................................... 12
2
2.1
Nghiên cứu và phân tích ............................................................................ 12
2.2
Thiết kế hệ thống........................................................................................ 12
3
Xây dựng phân hệ phần cứng ........................................................................... 12
4
Xây dựng phân hệ phần mềm............................................................................ 13
5
Kiểm thử và đánh giá hiệu quả.......................................................................... 13
6
Đưa ra hướng tối ưu, cải tiến ............................................................................ 13
7
Các tiêu chí đánh giá ......................................................................................... 14
CHƯƠNG 2. THIẾT KẾ TỔNG QUAN HỆ THỐNG .......................................................... 15
2.1
Mô hình tổng quan hệ thống .......................................................................... 15
2.2
Một số yêu cầu chung của hệ thống .............................................................. 16
2.3
Yêu cầu chức năng các phân hệ chính.......................................................... 17
2.3.1
Phân hệ device ........................................................................................... 17
2.3.2
Phân hệ Sever-Backend ............................................................................. 17
2.3.3
Phân hệ mobile app .................................................................................... 18
i
Yêu cầu chức năng các phân hệ phụ............................................................. 19
2.4
2.4.1
Phân hệ MQTT Broker ................................................................................ 19
2.4.2
Phân hệ firebase......................................................................................... 19
2.4.3
Phân hệ FaceNet ........................................................................................ 20
CHƯƠNG 3. THIẾT KẾ PHÂN HỆ MOBILE APPLICATION ............................................ 21
3.1
Sơ đồ tổng quan của phân hệ........................................................................ 21
3.2
Triển khai........................................................................................................ 21
3.2.1
Khởi tạo dự án ........................................................................................... 21
3.2.2
Setup redux toolkit: .................................................................................... 23
3.2.3
Setup firebase và persist dữ liệu đăng nhập ............................................. 25
3.3
Giao tiếp giữa mobiapp – sever backend/firebase ........................................ 26
3.4
Thiết kế luồng hoạt động một số dịch vụ ...................................................... 27
3.4.1
Luồng điều hướng màn hình khi mở MobiApp ............................................... 27
3.4.2
Luồng đăng kí tài khoản mới ......................................................................... 29
3.4.3
Luồng đăng nhập tài khoản ........................................................................... 29
3.4.4
Luồng kết nối máy chủ socket ....................................................................... 30
3.4.5
Luồng chung của 1 restful api ....................................................................... 31
3.5
Một số giao diện phân hệ mobile app ............................................................ 32
3.5.1
Giao diện đăng kí ......................................................................................... 32
3.5.2
Giao diện đăng nhập .................................................................................... 33
3.5.3
Giao diện trung tâm ...................................................................................... 34
3.5.4
Giao diện chi tiết các phòng .......................................................................... 34
3.5.5
Giao diện chi tiết thiết bị................................................................................ 35
3.5.6
Giao diện cài đặt .......................................................................................... 35
CHƯƠNG 4. THIẾT KẾ VÀ TRIỂN KHAI PHÂN HỆ DEVICE........................................... 37
4.1
Sơ đồ tổng quan của phân hệ........................................................................ 37
4.2
Triển khai phân hệ.......................................................................................... 37
4.2.1
Thiết kế luồng hoạt động của một số dịch vụ ............................................ 37
4.2.2
Phần cứng của device................................................................................ 38
4.2.3
Chương trình nhúng firmware của device ................................................. 50
CHƯƠNG 5. THIẾT KẾ VÀ TRIỂN KHAI PHÂN HỆ SERVER BACKEND ....................... 56
5.1
Sơ đồ tổng quan của phân hệ ........................................................................... 57
5.1.1
Cloud server................................................................................................. 57
5.1.2
Database: .................................................................................................... 58
5.1.3
BEApp: ........................................................................................................ 58
5.1.4
MQTT Broker: .............................................................................................. 58
5.1.5
AI Server (Server xử lý hình ảnh) .................................................................. 59
ii
5.2
Triển khai phân hệ ............................................................................................. 60
5.2.1
Thiết kế luồng hoạt động của backend 1 ....................................................... 60
5.2.2
Thiết kế luồng hoạt động của backend 2(AI Server) ....................................... 64
5.2.3
Cấu hình database ....................................................................................... 66
5.2.4
Các công nghệ/ thư viện được sử dụng để thiết kế BE App ........................... 68
CHƯƠNG 6. THIẾT KẾ VÀ TRIỂN KHAI FACENET ....................................................... 71
6.1
Giới thiệu........................................................................................................ 71
6.1.1
Facenet và đặc trưng ánh xạ không gian ....................................................... 71
6.1.2
Mạng no-ron tích chập và triplet loss trong facenet ........................................ 71
6.2
Cấu trúc mạng FaceNet ..................................................................................... 71
6.2.1
Mạng nơ ron tích chập (CNN) để trích xuất đặc trưng .................................... 72
6.2.2
Lớp Fully Connected (FC) để ánh xạ đặc trưng ............................................. 73
6.2.3
Hàm mất mát Triplet Loss ............................................................................. 73
Triển khai và ứng dụng...................................................................................... 76
6.3
6.3.1
Detected image ............................................................................................ 76
6.3.2
Retrain ......................................................................................................... 78
6.3.3
TrainModel ................................................................................................... 79
CHƯƠNG 7: KẾT LUẬN................................................................................................. 80
7.1
Kết quả đạt được ............................................................................................. 80
7.2
Các lỗi thường gặp và hướng giải quyết ........................................................... 81
7.3
Bài học kinh nghiệm ......................................................................................... 81
7.4
Hướng nghiên cứu tiếp theo ............................................................................. 82
7.4.1
Nâng cao độ chính xác và tối ưu nhận diện khuôn mặt: ................................. 82
7.4.2
Nâng cấp giao tiếp giữa các thiết bị............................................................... 82
7.4.3
Cải tiến mobile app ....................................................................................... 83
iii
Danh mục hình ảnh
Hình 1.1 React native ........................................................................................................ 7
Hình 1.2 Expo ................................................................................................................... 8
Hình 1.3 Cloud firestore .................................................................................................... 9
Hình 1.4 Firebase Authentication ....................................................................................... 9
Hình 1.5 Kết nối giữa MQTT client và MQTT Broker ......................................................... 10
Hình 1.6 Cơ chế hoạt động của websocket ...................................................................... 11
Hình 2.1 Mô hình tổng quan và cách thức giao tiếp giữa các phân hệ .............................. 16
Hình 3.1 Sử dụng terminal để tạo dự án .......................................................................... 21
Hình 3.2 Cấu trúc của dự án ........................................................................................... 22
Hình 3.3 cài đặt RTK bằng terminal ................................................................................. 23
Hình 3.4 Tạo store trong dự án........................................................................................ 24
Hình 3.5 Tạo slice trong dự án ........................................................................................ 24
Hình 3.6 Sử dụng RTK .................................................................................................... 25
Hình 3.7 Tải thư viện firebase bằng terminal .................................................................... 25
Hình 3.8 enable email authenticate .................................................................................. 26
Hình 3.9 Config firebase .................................................................................................. 26
Hình 3.10 Sơ đồ tổng quan về giao tiếp giữa mobile app và sever backend ...................... 26
Hình 3.11 Ví dụ về danh sách fcm token một tài khoản sẽ lưu .......................................... 27
Hình 3.12 Luồng điều hướng màn hình khi mở app .......................................................... 28
Hình 3.13 Luồng đăng kí tài khoản .................................................................................. 29
Hình 3.14 Luồng đăng nhập tài khoản.............................................................................. 30
Hình 3.15 Luồng kết nối máy chủ socket .......................................................................... 30
Hình 3.16 Luồng thực hiện chung của một RESTful API ................................................... 31
Hình 3.17 Giao diện đăng kí ............................................................................................ 33
Hình 3.18 Giao diện đăng nhập ....................................................................................... 33
Hình 3.19 Giao diện trung tâm ......................................................................................... 34
Hình 3.20 Giao diện các phòng........................................................................................ 35
Hình 3.21 Giao diện chi tiết thiết bị .................................................................................. 35
Hình 3.22 giao diện cài đặt .............................................................................................. 36
Hình 4.1 Sơ đồ tổng quan của phân hệ device ................................................................. 37
Hình 4.2 Sơ đồ hoạt động tổng quan của thiết bị .............................................................. 38
Hình 4.3 Luồng hoạt động khi giá trị cảm biến thay đổi ..................................................... 38
Hình 4.4 Sơ đồ tổng quan phần cứng của device ............................................................. 39
Hình 4.5 Esp32 ............................................................................................................... 40
Hình 4.6 rain sensor ........................................................................................................ 41
iv
Hình 4.7 HC-SR501 ........................................................................................................ 42
Hình 4.8 Cảm biến độ ẩm ................................................................................................ 43
Hình 4.9 Cảm biến ánh sáng ........................................................................................... 44
Hình 4.10 Cảm biến khí gas ............................................................................................ 45
Hình 4.11 Cảm biến cháy ................................................................................................ 46
Hình 4.12 Mô hình gửi nhận dữ liệu tổng quan giữa device và hệ thống ........................... 46
Hình 4.13 một số tập lệnh AT của SIM7020 ..................................................................... 48
Hình 4.14 Tập lệnh At kết nối với sever............................................................................ 48
Hình 4.15 Luồng gửi dữ liệu từ device ............................................................................. 48
Hình 4.16 Luồng nhận dữ liệu ......................................................................................... 49
Hình 4.17 khai báo chân device ....................................................................................... 50
Hình 4.18 Xác định mode của chân ................................................................................. 51
Hình 4.19 Kết nối wifi cho esp32 ...................................................................................... 51
Hình 4.20 kết nối mqtt với esp32 ..................................................................................... 52
Hình 4.21 Sơ đồ kết nối mqtt broker ................................................................................ 52
Hình 4.22 Đọc giá trị sensor ............................................................................................ 53
Hình 4.23 Sơ đồ chân của esp32..................................................................................... 54
Hình 4.24 Ví dụ ngưỡng cảnh báo của gas sensor ........................................................... 54
Hình 4.25 Mã nguồn publish data .................................................................................... 55
Hình 4.26 Mã nguồn hàm callback ................................................................................... 55
Hình 5.1 Sơ đồ tổng quan của phân hệ backend .............................................................. 57
Hình 5.2 Luồng hoạt động tổng quan của BE ................................................................... 60
Hình 5.3 Đọc danh sách thiết bị từ firestore...................................................................... 61
Hình 5.4 Luồng BE nhận các request api từ client ............................................................ 62
Hình 5.5 Luồng Backend Application khi nhận message từ MQTT Broker ......................... 63
Hình 5.6 sơ đồ tổng quan firmware server ai .................................................................... 64
Hình 5.7 Phản hồi từ server ............................................................................................. 65
Hình 5.8 thư mục chứa ảnh để phục vụ retrain ................................................................. 66
Hình 5.9 cấu trúc collections user .................................................................................... 67
Hình 5.10 Cấu trúc collection devices .............................................................................. 68
Hình 5.11 Cấu trúc collection rooms ................................................................................ 68
Hình 5.12 Một số route được cấu hình trong dự án .......................................................... 69
Hình 5.13 Các tính năng firebase-admin cung cấp cho nodejs so với các nền tảng khác ... 69
Hình 6.1 Mô hình facenet ................................................................................................ 71
Hình 6.2 Thực hiện tăng cường dữ liệu ........................................................................... 76
Hình 6.3 Triển khai detected image ................................................................................. 77
Hình 6.4 Response trả về với độ tương đồng nhỏ hơn 0.7................................................ 77
v
Hình 6.5 Response trả về với độ tương đồng lớn hơn 0.7 ................................................ 78
Hình 6.5 Retrain data ...................................................................................................... 78
Hình 6.6 Train model ....................................................................................................... 79
vi
Danh mục từ viết tắt
MQTT
Message Queueing Telemetry
Transpor
BE
Backend
FE
Frontend
API
Application Programming Interface
IoT
Internet of things
AI
Artificial intelligence
CNN
Convolutional Neural Network
MTCNN
Multi-task Cascaded Convolutional
Networks
FC
Fully Connected
SSL
Secure Socket Layer
TSL
ransport Layer Security
vii
MỞ ĐẦU
1. Tính cấp thiết của đề tài
Ngày nay với sự phát triển mạnh mẽ của công nghệ, tự động hóa nhà thông minh
và ứng dụng của nó đã nhận được nhiều thành tựu hướng tới sự thoải mái, thoải mái,
an toàn và anh ninh.
Với những tiến bộ trong công nghệ và Internet of Things (IoT), môi trường nhà
ở đã chứng kiến sự cải thiện trong việc điều khiển từ xa các thiết bị, giám sát và an
ninh nhà ở qua internet. Nhiều hệ thống tự động hóa nhà đã được phát triển để giám
sát chuyển động trong nhà và báo cáo cho người dùng. Các hệ thống tự động hóa
nhà hiện có phát hiện chuyển động và có giám sát cho an ninh nhà ở.
Tuy nhiên, khía cạnh logic của việc ngăn chặn các thông báo không cần thiết
hoặc giả mạo vẫn là một thách thức lớn. Phản ứng và giám sát thông minh làm cho
tự động hóa nhà thông minh hiệu quả. Bên cạnh đó, nhu cầu tự động hóa và kiểm
soát môi trường sống ngày càng tăng, đặc biệt trong bối cảnh các thành phố thông
minh đang phát triển mạnh.
Hệ thống nhà thông minh không chỉ giúp tiết kiệm năng lượng mà còn đảm bảo
an toàn cho người dùng thông qua các giải pháp giám sát tiên tiến. Do đó, nghiên
cứu về việc áp dụng AI vào kiểm soát và bảo mật nhà thông minh không chỉ có ý
nghĩa về mặt công nghệ mà còn đóng góp vào việc nâng cao chất lượng cuộc sống.
2. Lịch sử nghiên cứu vấn đề
Em đã nghiên cứu đề tài này trong học phần lập trình python (2022-2023) dưới
sự hướng dẫn của thầy Dũng. Trong quá trình em đã tập trrung vào cách xây dựng
và kết nối các thiết bị,nghiên cứu khả năng giao tiếp giữa các thiết bị với nhau, đồng
thời nghiên cứ về các phương thức giao tiếp như UART, I2C, MQTT,… Bên cạnh
1
đó em cũng được tìm hiểu về các loại mô hình học sâu như CNN, RNN,
Transformer.
Những nghiên cứu này đã đặt nền tảng quan trọng để em tiếp tục mở rộng các
nghiên cứu cho đến thời điểm hiện tại. Em cũng tập trung tìm hiểu sâu hơn về các
phương thức giao tiếp không dây, tăng tốc độ nhận diện khuôn mặt thông qua việc
tối ưu mô hình và sử dụng các thư viện hỗ trợ.
Bên cạnh các vấn đề về kĩ thuật, em cũng chú trọng vào tính bảo mật và quản lí
dữ liệu của người dùng thông qua việc lưu trữ dữ liệu lên cloud sever firebase, giúp
cho việc quản lí dữ liệu trở nên hiệu quả và nhanh chóng hơn. Tuy nhiên, do hạn
chế về mặt kinh nghiệm, thời gian và nhân lực nên ứng dụng chỉ có thể hoàn thành
được 50% so với kì vọng trước đó. Một số vấn đề vẫn còn tồn đọng như kết nối giữa
các sever với nhau, đồng bộ dữ liệu và khả năng tương tác giữa các thiết bị.
Hiện nay, tụi em tiếp tục phát triển dự án với sự đầu tư nhiều hơn về thời gian,
nhân lực cùng với sự hỗ trợ của thầy Dũng để nâng cao hiệu suất cũng như tăng trải
nghiệm cho người dùng. Với những điều kiện thuận lợi hơn, chúng em hy vọng sẽ
đạt được một kết quả tốt hơn.
3. Mục đích và nhiệm vụ nghiên cứu
Trong đề tài nghiên cứu này, nhóm chúng em tập trung tìm hiểu và đề xuất các
giải pháp hiệu quả để các thiết bị giao tiếp với nhau trơn tru và mượt mà, từ đó xây
dựng quy trình thu thập dữ liệu từ các cảm biến một cách hiệu quả, giúp ngăn chặn
các thông báo không cần thiết.
Tích hợp Deep learning để nâng cao khả năng nhận diện và tăng cường tính bảo
mật cho ngôi nhà. Cụ thể nghiên cứu sẽ tập trung vào facenet, mã hóa khuôn mặt
thành một vector đặc trưng nhỏ gọn nhằm nắm bắt các điểm độc đáo của khuôn mặt
đó, tăng mức độ chính xác và khả năng làm việc hiệu quả.
Hỗ trợ điều khiển các thiết bị trong nhà từ xa thông qua điện thoại di động, giúp
người dùng dễ dàng quản lý và giám sát hệ thống dù ở bất kì đâu
Mục đích của nghiên cứu không chỉ tìm hiểu về các giải pháp phù hợp mà còn
tập trung vào việc tối ưu hóa quy trình, giúp dễ bảo trì và phát triển ứng dụng trong
2
tương lai. Bên cạnh đó chúng em muốn triển khai ứng dụng trên các thiết bị thật
thông qua expo nhằm phục vụ tính năng mở rộng trong tương lai
4. Đối tượng và phạm vi nghiên cứu
4.1 Đối tượng nghiên cứu
Đối với phần cứng: Nghiên cứu sẽ tập trung vào cách các thiết bị giao tiếp
với nhau, cách kết nối và cấu hình, khả năng mở rộng mô hình, cách các thiết bị
đọc và trả dữ liệu
Đối với phần mềm: Nghiên cứu sẽ tập trung vào việc xây dựng ứng dụng
đơn giản, dễ sử dụng, tương thích với nhiều thiết bị và có thể giao tiếp với phần
cứng
Đối với DeepLearning: Dữ liệu khuôn mặt của người dùng
Bên cạnh đó, nghiên cứu còn đề cập đến các công cụ hỗ trợ như firebase để
đồng bộ dữ liệu , mqtt broker giúp cho việc giao tiếp trở nên dễ dàng hơn,
platformIO hỗ trợ việc lập trình nhúng và websocket để cập nhật realtime trạng
thái của thiết bị
4.2 Phạm vi nghiên cứu
Không gian nghiên cứu: Xây dựng mô hình và các điều kiện môi trường
xung quanh, không thực nghiệm trên nhà thật
Các tình huống thử nghiệm bao gồm:
 Thiết bị được điều khiển thông qua mobile app
 Thiết bị được tự động điều khiển dựa theo các dữ liệu cảm biến trả về
 Gửi thông báo về cho người dùng nếu phát hiện nguy hiểm
 Xử lý lỗi và đề xuất phương án tối ưu
Thời gian nghiên cứu: Từ tháng 9/2024 đến tháng 4/2025
Nguồn lực nghiên cứu: 3 thành viên cùng tổng chi phí dự kiến là bảy triệu
đồng
3
5. Phương pháp nghiên cứu
Tìm hiểu, tham khảo các bài báo, cái tài liệu có liên quan đến nội dung nghiên
cứu: expo, express, mqtt, pub-sub client…
Thu thập các dữ liệu từ môi trường xung quanh, phân tích dữ liệu và dựa trên
dữ liệu để đưa ra các lệnh thực hiện cho các thiết bị
Thu thập dữ liệu về khuôn mặt của người dùng, sử dụng các model và các
phương pháp MTCNN
6. Những đóng góp của đề tài
Tối ưu hóa trải nghiệm của người dùng
 Xây dựng ứng dụng mobile app đơn giản, dễ tiếp cận và tiện lợi
 Có thể điều khiển thiết bị từ xa thông qua mobile app
 Tự động điều khiển thiết bị khi gặp các tình huống xấu
Tích hợp các công nghệ tiên tiến để tối ưu hiệu suất
 Sử dụng các dịch vụ của firebase để lưu trữ dữ liệu người dùng, hỗ trợ
authenticate tăng tính bảo mật và đồng bộ hóa dữ liệu
 Mqtt để hỗ trợ việc giao tiếp giữa các thiết bị, giúp cho dữ liệu truyền đến
các thiết bị khác gần như ngay lập tức
 Thư viện facenet nhằm hỗ trợ việc đăng nhập bằng khuôn mặt, nhận diện
người trong video hoặc ảnh
7. Kết cấu đề tài
Ngoài phần mở đầu, kết luận, tài liệu tham khảo và phụ lục, nội dung bài nghiên
cứu có kết cấu gồm 6 chương, cụ thể như sau:
Chương 1: Tổng quan về đề tài và cơ sở lí thuyết
Chương 2: Trình bày mô hình tổng quan của hệ thống, đưa ra các yêu cầu chức
năng phi chức năng của hệ thống.
Chương 3: Trình bày thiết kế và triển khai mobile app
Chương 4: Trình bày thiết kế và triển khai các thiết bị
Chương 5: Trình bày thiết kế và triển khai backend
Chương 6; Trình bày thiết kết và triển khai facenet
4
Chương 7: Hướng phát triển và thực nghiệm
CHƯƠNG 1. TỔNG QUAN VỀ ĐỀ TÀI VÀ CƠ SỞ LÍ THUYẾT
Chương 1 cung cấp cái nhìn tổng quan về đề tài, làm rõ các khái niệm về các công
nghệ sử dụng trong đề tài, làm rõ các đặc điểm, tính năng và sự khác biệt giữa chúng.
1 Giới thiệu
1.1 Internet of thing (IoT)
Internet vạn vật (IoT) xem xét sự kết nối giữa một số thiết bị, tức là hệ thống
công nghiệp, cảm biến thông minh, xe tự hành, cơ chế và thiết bị đầu cuối, hệ
thống cơ khí, v.v. [1, 2].
Ngoài ra, nó có thể được gọi là mạng lưới các vật thể hoặc vật thể vật lý
được kết nối với khả năng giao tiếp, tính toán và lưu trữ hạn chế cùng với các
thiết bị điện tử nhúng (tức là cảm biến và bộ truyền động), khả năng kết nối mạng
và phần mềm cho phép những thứ này trao đổi, phân tích và thu thập dữ liệu [3].
IoT liên quan đến cuộc sống hàng ngày của chúng ta, mở rộng từ các thiết bị
thông minh trong gia đình, tức là đồng hồ thông minh, camera IP, máy dò khói,
bộ điều hợp thông minh, tủ lạnh thông minh, bóng đèn thông minh, AC, lò nướng
thông minh và cảm biến nhiệt độ, đến các thiết bị tiên tiến hơn, ví dụ như máy
dò nhịp tim, thiết bị nhận dạng tần số vô tuyến (RFID), máy đo gia tốc, IoT trong
ô tô, cảm biến trong phòng, v.v. [4].
Một số dịch vụ và ứng dụng được IoT đề cập đang nổi lên trong chăm sóc
sức khỏe cá nhân, thiết bị gia dụng, cơ sở hạ tầng nông nghiệp quan trọng và
quân đội [1] và được sử dụng phổ biến trong đời sống với các mô hình nhà thông
minh. Với sự phổ biến đó cũng đặt ra nhìu vấn đề:
 Vấn đề 1: Sự giao tiếp giữa các thiết bị với nhau
 Vấn đề 2: Phản hồi của hệ thống đối với những tình huống khẩn cấp
 Vấn đề 3: Bảo mật thông tin
Tính bảo mật của các hệ thống IoT phải đối mặt với rủi ro cao hơn so với
tính bảo mật của các thiết bị điện toán truyền thống khác. Các hệ thống điện
toán lỗi thời sẽ không có hiệu quả đối với các chương trình IoT này [5–7]. Hệ
5
thống IoT phải ngay lập tức xem xét bảo mật, hiệu quả năng lượng, ứng dụng
phần mềm IoT và phân tích dữ liệu tại thời điểm thực hiện các tác vụ liên quan
như một dấu hiệu của ứng dụng rộng rãi [8]. )
Việc mở rộng này cung cấp phạm vi sáng tạo cho các học giả từ chương trình
nghiên cứu liên ngành để xem xét những thách thức gần đây trong các chương
trình IoT từ nhiều nhận thức khác nhau. Tuy nhiên, bản chất quy mô lớn cũng
như đa ngành của các thiết bị IoT và nhiều thành phần tham gia vào quá trình
triển khai của chúng đã tạo ra các vấn đề bảo mật mới. ) Đặc điểm của các thiết
bị IoT nêu ra nhiều vấn đề bảo mật khác nhau.
Ngoài ra, các giai đoạn của IoT cung cấp một lượng lớn thông tin hữu ích.
Nếu thông tin này không được phân tích và truyền tải một cách an toàn, có thể
xảy ra lỗ hổng bảo mật quan trọng. Việc áp dụng các cơ chế bảo mật liên quan,
chẳng hạn như xác thực, mã hóa, bảo mật ứng dụng, bảo mật mạng và kiểm soát
truy cập, là không đủ và đầy thách thức đối với các chương trình lớn có nhiều
chương trình liên quan. Mọi phần của nền tảng IoT đều chứa các lỗ hổng nội tại.
Ví dụ, một loại botnet đặc biệt như "Mirai" mới bị ảnh hưởng bởi các cuộc tấn
công từ chối dịch vụ phân tán rộng rãi (DDoS) bằng cách sử dụng các hệ thống
IoT [5,7].
Trong khi IoT đã được tiến hành trong những năm gần đây, toàn bộ lĩnh vực
học sâu trong các ứng dụng IoT vẫn còn ở giai đoạn sơ khai.
Một số ít nhà nghiên cứu, các bài báo đã được đánh giá về mạng cảm biến
không dây (WSN) với ML, triển khai các phương pháp DL cho khoa chăm sóc
sức khỏe, các phương pháp tiếp cận và khả năng ứng dụng DL mai trong các ứng
dụng IoT tập trung vào phân tích dữ liệu lớn và phát trực tuyến và các thuật toán
DL với các ứng dụng của nó để tạo ra sự phát triển thông minh. Sau khi thực
hiện khảo sát các bài báo hiện có, vẫn chưa có khảo sát nào khám phá nhiều loại
thiết bị IoT bằng DL một cách kỹ lưỡng. Đó cũng là thách thức cho chúng em
trong việc tìm tòi và nghiên cứu về chủ đề này.
6
1.2 React native và expo
React native là frameword của Meta (Facebook) cho phép xây dựng ứng
dụng di động native (Android và iOS) bằng react và javascript
React native sử dụng react (component-based) để xây dựng UI
React native có thể gọi được API native của hệ điều hành (camera, GPS,
Bluetooth)
Mục tiêu của React native: Viết một lần bằng javaScript, build ra app chạy
native trên Android và iOS
Hình 1.1 React native
Expo là công cụ xây dựng trên nền React native, giúp phát triển React native
dễ dàng hơn, ẩn bớt phần native phức tạp, cung cấp các thư viện native có sẵn.
Với expo, lập trình viên có thể viết mã JavaScript hoặc TypeScript một lần chạy
được trên cả iOS, Android và Web. Bên cạnh đó expo còn hỗ trợ việc build ứng
dụng để hoạt động trên điện thoại thật
7
Hình 1.2 Expo
1.3 Firebase
Fire base là một sản phẩm của google, là một công cụ mạnh mẽ hỗ trợ việc
xây dựng, quản lý và mở rộng ứng dụng một cách dễ dàng. Firebase đơn giản
hóa quá trình phát triển ứng dụng bằng cách cung cấp một backend an toàn, hiệu
quả, loại bỏ nhu cầu lập trình phía máy chủ. Firebase hỗ trợ nhiều nền tảng như
Android, iOS, Web và Unity, giúp nó trở thành một giải pháp linh hoạt cho các
nhà phát triển.
Với các tính năng như lưu trữ dữ liệu thời gian thực trên đám mây, xác thực
người dùng và hỗ trợ cơ sở dữ liệu NoSQL, Firebase đảm bảo việc quản lý và
đồng bộ dữ liệu trở nên mượt mà. Hạ tầng đám mây của Firebase cho phép phát
triển nhanh hơn, bảo mật tốt hơn và khả năng mở rộng dễ dàng, giúp các nhà
phát triển tập trung vào việc tạo ra trải nghiệm người dùng tuyệt vời.
Các tính năng của firebase được sử dụng trong đề tài:
 Cloud Firestore: Là cơ sở dữ liệu tài liệu NoSQL cho phép lưu trữ, đồng
bộ và truy vấn dữ liệu trên quy mô toàn cầu. Dữ liệu được lưu dưới dạng
document (tài liệu), theo cặp key-value và có thể chứa nhiều loại dữ liệu
như chuỗi, nhị phân, hoặc cây JSON.
8
Hình 1.3 Cloud firestore
 Authentication: Dịch vụ xác thực Firebase cung cấp thư viện UI và SDK
dễ sử dụng để xác thực người dùng. Nó giúp giảm thời gian và công sức
cần thiết để xây dựng hệ thống đăng nhập, kể cả các chức năng phức tạp
như gộp tài khoản.
Hình 1.4 Firebase Authentication
1.4 MQTT
MQTT (Message Queuing Telemetry Transport) là một giao thức nhắn tin
nhẹ theo mô hình publish/subscribe (xuất bản/đăng ký), đặc biệt phù hợp với các
9
ứng dụng IoT nhờ vào thiết kế đơn giản, tiết kiệm tài nguyên và hoạt động hiệu
quả trên các mạng không ổn định hoặc băng thông thấp.
Hai thành phần chính của MQTT:
 MQTT client
MQTT Client là bất kỳ thiết bị hoặc ứng dụng nào sử dụng thư viện MQTT
và kết nối với một MQTT Broker thông qua mạng. Một client có thể đóng vai
trò là publisher (người xuất bản) – gửi thông điệp, hoặc subscriber (người đăng
ký) – nhận thông điệp. Trong nhiều trường hợp, một MQTT client có thể vừa
xuất bản, vừa đăng ký nhận thông điệp.
MQTT Client có thể là bất kỳ thiết bị nào từ vi điều khiển nhỏ gọn (như
ESP32, Arduino) đến máy chủ mạnh mẽ, miễn là thiết bị đó sử dụng được giao
thức TCP/IP và có thể chạy thư viện MQTT.
Các thư viện MQTT client hiện có sẵn trên nhiều ngôn ngữ và nền tảng như:
C, C++, Java ,JavaScript Nhờ đó, việc tích hợp giao thức MQTT vào ứng dụng
trở nên dễ dàng hơn mà không cần xây dựng từ đầu.
 MQTT broker
MQTT broker là thành phần trung tâm của mô hình publish/subscribe.
MQTT broker chịu trách nhiệm: Nhận và phân phối thông điệp từ publisher
đến các subscriber tương ứng, quản lý phiên làm việc, xác thực và phân
quyền, bảo mật…
Hiện nay có rất nhiều nhà cung cấp dịch vụ MQTT broker nhưng trong đề
tài này chúng em lựa chọn nhà cung cấp HiveMQ
Hình 1.5 Kết nối giữa MQTT client và MQTT Broker
10
1.5 Websocket
WebSocket là một giao thức mạng cấp ứng dụng hoạt động trên nền tảng
TCP, cho phép thiết lập một kết nối song công (full-duplex) giữa client (trình
duyệt, app) và server (thiết bị, máy chủ) thông qua một kết nối TCP duy nhất.
Không giống như HTTP, trong đó mỗi request cần một response riêng biệt,
WebSocket cho phép gửi và nhận dữ liệu liên tục sau khi kết nối được thiết lập,
không cần lặp lại quá trình handshake.
Hình 1.6 Cơ chế hoạt động của websocket
1.6 Facenet
FaceNet là một hệ thống nhận diện và xác minh khuôn mặt được phát triển
bởi nhóm nghiên cứu của Google vào năm 2015. Thay vì phân loại khuôn mặt
thành các nhãn (labels), FaceNet biểu diễn mỗi khuôn mặt bằng một vector
(embedding) trong không gian nhiều chiều, từ đó có thể:
 So sánh độ giống nhau giữa các khuôn mặt
 Tìm kiếm người tương tự
 Gom nhóm khuôn mặt
Nguyên lí hoạt động:
FaceNet sử dụng mạng nơ-ron sâu (CNN) để trích xuất đặc trưng khuôn mặt
từ ảnh đầu vào và ánh xạ chúng thành một vector có độ dài cố định (thường là
128 chiều). Mỗi vector sẽ đại diện cho một khuôn mặt duy nhất.
11
Khoảng cách giữa hai vector trong không gian embedding càng nhỏ thì
khuôn mặt càng giống nhau.
 Nếu distance < threshold → hai ảnh cùng người
 Nếu distance > threshold → hai ảnh khác người
2 Phương pháp thực hiện
2.1 Nghiên cứu và phân tích
Chúng em tiến hành nghiên cứu tổng quan về các thiết bị IoT phổ biến, các
loại bo mạch, vi điều khiển như esp32, esp32cam, module sim a7680c, các chuẩn
kết nối( Wifi, MQTT, Websocket…) và cơ chết giao tiếp giữa các thiết bị
Bên cạnh đó, chúng em cũng tiến hành nghiên cứu các công nghệ xử lý dữ
liệu và thuật toán nhận diện khuôn mặt ứng dụng deep learning, các mô hình
facenet và MTCNN
2.2 Thiết kế hệ thống
Xác định các yêu cầu chức năng (ví dụ: phát hiện người lạ, gửi cảnh báo...)
và phi chức năng (như độ tin cậy, độ trễ thấp, mở rộng linh hoạt). Tiến hành thiết
kế kiến trúc tổng thể của hệ thống bao gồm:
 Các thiết bị cảm biến (camera, PIR, nhiệt độ, độ ẩm…)
 Bộ điều khiển trung tâm (ESP32, Raspberry Pi)
 Giao thức truyền thông (MQTT/WebSocket)
 Cơ sở dữ liệu lưu trữ thông tin
 Giao diện người dùng (ứng dụng di động/web)
Xây dựng sơ đồ xử lý dữ liệu và tích hợp các thuật toán phát hiện khuôn mặt,
phân loại người lạ và xử lý tình huống khẩn cấp.
3 Xây dựng phân hệ phần cứng
Dựa trên yêu cầu của hệ thống, lựa chọn các thiết bị cảm biến và thiết bị IoT
phù hợp. Thiết kế thiết bị có thể gắn vào mô hình, đưa cảnh báo và trao đổi dữ liệu
với hệ thống phần mềm.
Tối ưu hóa việc sử dụng các cổng điều khiển của vi điều khiển esp32 do số lượng
chân điều khiển có hạn, một số chân không được sử dụng vì sẽ làm ảnh hưởng đến
12
việc nạp chương trình cũng như trong quá trình kết nối wifi như GPIO0,
GPIO2,GPIO15
Đảm bảo các thiết bị đều được cấp đúng với điện áp định mức, tránh tình trạng
chập cháy, làm hỏng các thiết bị hoặc không đủ điện áp gây nhiễu tín hiệu
4 Xây dựng phân hệ phần mềm
Phát triển phần mềm phân tích dữ liệu và giao diện người dùng. Xác định các
cơ chế cảnh báo và cách thức gửi thông báo đến người dùng hoặc cơ quan chức năng
khi phát hiện tình huống đáng ngờ.
Xây dựng phần mềm trực quan, dễ sử dụng trên nền tảng di động Android để
theo dõi trạng thái hệ thống
Triển khai các cơ chế cảnh báo như thông báo đẩy, SMS hoặc Call khi phát hiện
sự bất thường
5 Kiểm thử và đánh giá hiệu quả
Triển khai hệ thống vào môi trường thực tế và tiến hành thử nghiệm hoạt động
của hệ thống. Đánh giá hiệu quả của hệ thống trong việc phát các tình huống đặc
biệt. Đo lường khả năng phát hiện, độ chính xác và thời gian phản ứng của hệ thống
như:
 Tỷ lệ nhận diện đúng khuôn mặt
 Tỷ lệ phát hiện người lạ
 Độ trễ từ lúc phát hiện đến khi gửi cảnh báo
 Tính liên tục và khả năng phản hồi của hệ thống
Dựa trên các kết quả thực nghiệm, đánh giá hiệu quả tổng thể và khả năng đáp
ứng nhu cầu thực tế
6 Đưa ra hướng tối ưu, cải tiến
Dựa trên kết quả đánh giá, tiến hành đưa ra hướng tối ưu, cải tiến hệ thống trong
tương lai để nâng cao hiệu quả và độ tin cậy như:
 Nâng cao độ chính xác cùa mô hình AI
 Tối ưu hiệu năng xử lý
13
 Mở rộng quy mô hệ thống
 Tăng cường bảo mật trong truyền thông và lưu dữ liệu
7 Các tiêu chí đánh giá
1. Tính tương thích
Có thể tương thích với các thiết bị cũng như các dòng điện thoại khác nhau
2. Tính khả dụng
Thời gian hoạt động của hệ thống trong một khoảng thời gian nhất định. Tính
khả dụng cao đảm bảo hệ thống luôn sẵn sàng hoạt động và cung cấp cảnh báo
kịp thời khi cần thiết.
3. Tính tin cậy và bảo mật
Đảm bảo rằng dữ liệu được truyền tải đúng nơi và lưu trữ một cách an toàn,
tránh việc rò rỉ thông tin và truy cập trái phép.
4. Hiệu suất
Tốc độ phản hồi và xử lý dữ liệu của hệ thống. Hệ thống cần có hiệu suất cao
để phát hiện và cảnh báo kịp thời trong các tình huống nguy hiểm.
5. Dễ dàng sử dụng
Hệ thống cần có giao diện phần mềm, thiết bị phần cứng đơn giản, rõ ràng
và dễ dàng thao tác.
6. Chi phí
Đánh giá chi phí triển khai và vận hành hệ thống. Đảm bảo rằng hệ thống đáp
ứng hiệu quả về chi phí và có tính khả thi trong việc triển khai thực tế.
7. Hiệu quả
Đánh giá khả năng của hệ thống trong việc giảm thiểu các báo động giả phát
hiện, giúp đỡ kịp thời những tình huống nguy cấp.
14
CHƯƠNG 2. THIẾT KẾ TỔNG QUAN HỆ THỐNG
Chương 2 trình bày kiến trúc tổng thể và thiết kế các phân hệ chính của hệ thống
quản lí nhà thông minh ứng dụng deep learning. Hệ thống được xây dựng dựa trên kiến
trúc IoT nhiều lớp, bao gồm ba phân hệ chính: Device, Server-backend, Mobile app,
cùng với hai phân hệ phụ trợ là MQTT Broker và Firebase.
Phân hệ Device đảm nhận việc thu thập dữ liệu môi trường thông qua cảm biến,
nhận lệnh điều khiển và gửi cảnh báo bất thường. Phân hệ Server-Backend chịu trách
nhiệm xử lý dữ liệu, lưu trữ thông tin, gửi cảnh báo đến người dùng, đồng thời hỗ trợ
huấn luyện mô hình nhận diện khuôn mặt. Phân hệ Mobile App cho phép người dùng
đăng ký, đăng nhập, liên kết với thiết bị, điều khiển từ xa và nhận cảnh báo.
Ngoài ra, hệ thống sử dụng MQTT Broker làm cầu nối truyền thông giữa các phân
hệ và Firebase để quản lý cơ sở dữ liệu, xác thực người dùng, gửi thông báo thời gian
thực. Phân hệ FaceNet được tích hợp để xử lý và trích xuất đặc trưng khuôn mặt, phục
vụ cho việc nhận dạng người dùng.
Chương này cũng nêu rõ các yêu cầu chức năng của từng phân hệ và đề xuất mở
rộng hệ thống trong tương lai nhằm nâng cao hiệu quả vận hành và trải nghiệm người
dùng.
2.1 Mô hình tổng quan hệ thống
15
Hình 2.1 Mô hình tổng quan và cách thức giao tiếp giữa các phân hệ
Hệ thống được xây dựng dựa vào kiến trúc IOT, với 3 phân hệ chính Device,
Server-Backend, MobiApp; 2 phân hệ phụ MQTT Broker, Firebase được ứng dụng
vào từng lớp như sau (có sự tuỳ biến với chức năng của từng lớp):
 Perception Layer: chứa Device (thiết bị phần cứng) được gắn trên mô hình.
Tại đây, dữ liệu được thu thập thông qua các cảm biến. Lớp này sẽ gửi các
dữ liệu cần thiết lên lớp tiếp theo.
 Network Layer: sử dụng giao thức truyền thông MQTT + MQTT Broker để
gửi những dữ liệu được tính toán, thu thập từ thiết bị cho các lớp phía trên.
 Processing Layer: chứa Server-Backend có vai trò nhận dữ liệu từ Device,
sau đó thực hiện những tác vụ với Firebase (đóng vai trò làm database lưu
dữ liệu cần thiết từ Device) và MobileApp. Tại đây cũng nhận những tín hiệu
được gửi từ phía MobileApp, sau đó yêu cầu Device thực hiện một số yêu
cầu.
 Application Layer: chứa MobileApp được triển khai trên các thiết bị di động
thông minh, có khả năng nhận dữ liệu từ BE, sau đó hiển thị trực quan với
người dùng, họ cũng có thể tương tác trực tiếp với Device tại đây. Với những
tình huống cần có thông báo trực tiếp tới người dùng, BE sẽ có nhiệm vụ
thực hiện những chức năng như gửi SMS, PhoneCall và FCM (thông qua
Firebase)
2.2 Một số yêu cầu chung của hệ thống
16
Có khả năng quản lí nhiều thiết bị vầ tài khoản, có thể điều khiển thiết bị
trong hệ thống thông qua mobile app đồng thời cập nhật realtime trạng thái của
các thiết bị ở các enduser khác có cùng mã
Có khả năng thực hiện các chức năng đã đề ra( Chấp nhận tỉ lệ lỗi nhất định
ở giai đoạn đầu của dự án – giai đoạn xây dựng hệ thống, triển khai nguyên mẫu)
Mobile app có giao diện thân thiện với người dùng
Nhiều người có khả năng đăng nhập chung trên cùng tài khoản, đăng nhập
trên nhiều thiết bị
Nhận diện khuôn mặt chính xác dựa trên các tập dữ liệu đã được train trước
đó
2.3 Yêu cầu chức năng các phân hệ chính
2.3.1 Phân hệ device
Phân hệ device đóng vai trò thu thập dữ liệu và thực thi các tác vụ với phân
hệ device, hệ thống yêu cầu chức năng như sau:
 Kết nối mạng 4g/LTE ổn định
 Thu thập các điều kiện của môi trường thông qua các cảm biến (nhiệt độ, độ
ẩm, chuyển động, khí gas
 Bật tắt thủ công các thiết bị bằng công tắc
 Dựa vào các số liệu của cảm biến gửi về, tiến hành phân tích, sau đó đưa ra
trạng thái bất thường đồng thời gửi thông báo cho người dùng thông qua sms
 Nhận những yêu cầu, cài đặt của backend
 Gửi dữ liệu, trạng thái tới sever backend
 Gửi dữ liệu từ các cảm biến một cách thường xuyên
 Gửi trạng thái bất thường (nếu có) ngay lập tức

Thu thập hình ảnh từ bên ngoài gửi về backend để phân tích xử lí nếu có nguời
lạ
2.3.2 Phân hệ Sever-Backend
17
Với phân hệ sever backend, hệ thống yêu cầu các chức năng:
 Nhận thông tin, dữ liệu và các trạng thái bất thường (nếu có) từ device, tiến
hành thực hiện một số chức năng: như đóng mở hiên chắn, báo cháy, bật tắt
thiết bị
 Gửi cảnh báo về cho người dùng qua sms, phonecall trong trường hợp
nguy hiểm
 Gửi cảnh báo về cho người dùng qua mobile app
 Điều khiển các thiết bị tự động dựa vào các điều kiện của môi
trường (mưa, ánh sáng)
 Lưu dữ liệu cần thiết của người dùng vào db
 Dựa vào hình ảnh nhận được tiến hành train model để nhận diện
các user
 Nhận dữ liệu và yêu cầu từ moblie app tiến hành thực hiện một số tính năng:
 Lưu thông tin người dùng vào db
 Lưu thông tin các thiết bị vào db
 Cập nhật realtime trạng thái các thiết bị
 Dựa vào hình ảnh nhận được tiến hành train model để nhận diện
các user
 Gửi thiết lập đến device, tiến hành thực hiện một số tính năng:
 Gửi thiết lập bật tắt các thiết bị, device nhận được sẽ triển khai các tính năng
2.3.3 Phân hệ mobile app
Phân hệ MobiApp sẽ là thành phần chính, hệ thống yêu cầu các chức năng
sau:
 Đăng kí tài khoản.
 Đăng nhập tài khoản bằng email và password.
 Chỉnh sửa thông tin người dùng của tài khoản.
 Hiển thị các thông báo/cảnh báo từ hệ thống:
18
 Phân biệt rõ trạng thái thông báo/cảnh báo đã xem, chưa xem.
 Phân biệt các tình huống thông báo/cảnh báo khác nhau bằng:
tiêu đề, nội dung, biểu tượng
 Có nút bấm xác nhận xem toàn bộ thông báo/cảnh báo.
 Liên kết tài khoản với Device.
 Sau khi đã liên kết thành công tài khoản với Device, MobiApp có các chức
năng:
 Điều khiển các thiết bị
 Hiển thị thông tin các thiết bị hiện có trong phòng
 Bật tắt toàn bộ thiết bị trong phòng
 Ngoài ra còn có một số tính năng:
 Đăng xuất khỏi mobile app
 Nhận diện khuôn mặt
2.4 Yêu cầu chức năng các phân hệ phụ
2.4.1 Phân hệ MQTT Broker
Phân hệ MQTT Broker giữ vai trò trung tâm điều phối giao tiếp giữa các thiết
bị IoT (Device) và Server-Backend thông qua giao thức truyền thông nhẹ MQTT.
Trong hệ thống này, dịch vụ HiveMQ được lựa chọn làm MQTT Broker vì
tính ổn định cao, khả năng mở rộng linh hoạt và hỗ trợ giao tiếp bảo mật
(TLS/SSL).
HiveMQ cho phép hàng nghìn thiết bị IoT kết nối đồng thời và truyền dữ liệu
real-time một cách hiệu quả. HiveMQ đóng vai trò “môi giới” tin nhắn, định
tuyến các bản tin MQTT theo topic từ các thiết bị gửi lên đến Server-Backend,
đảm bảo dữ liệu được phân phối chính xác và kịp thời.Phân hệ Firebase
2.4.2 Phân hệ firebase
19
Firebase đóng vai trò nền tảng hỗ trợ phía backed trong việc lưu trữ và xử
lí dữ liệu, xác thực người dùng và gửi thông báo. Hệ thống sử dụng các
dịch vụ chính của firebase như sau:
 Cloud firestore: Lưu trữ và quản lý dữ liệu của người dùng, các thiết
bị trong hệ thống và thông báo.
 Firebase authenticate: xác thực người dùng thông qua email, đảm
bảo tính bảo mật
 Firebase reCAPTCHA: xác thực số điện thoại đảm bảo tính chính
xác trước khi thực hiện đăng kí tài khoản
2.4.3 Phân hệ FaceNet
Phân hệ FaceNet hỗ trợ việc trích xuất đặc trưng khuôn mặt và biểu diễn
dưới dạng vector số. Nhờ đó, giúp hệ thống so sánh và nhận diện khuôn
mặt với độ chính xác cao. Một số chức năng yêu cầu:
 Trích xuất đặc trưng khuôn mặt và chuyển thành vector 128 chiều
 So sánh vector đặc trưng với cơ sỡ dữ liệu người dùng đã lưu để nhận
dạng
 Hỗ trợ nhận diện người lạ bằng cách phát hiện vector không trùng
khớp
 Kết hợp với esp32-cam để xử lý ảnh đầu vào và trả kết quả thời gian
thực hiện về backend
20
CHƯƠNG 3. THIẾT KẾ PHÂN HỆ MOBILE APPLICATION
3.1 Sơ đồ tổng quan của phân hệ
Phân hệ mobile gồm các khối sau:
 UI screens (màn hình giao diện người dùng): Chứa các màn hình của ứng dụng,
hiển thị dữ liệu và tương tác với người dùng
 Components: Thành phần tái sử dụng, chứa các UI nhỏ như button, card, input
để tái sử dụng trên nhiều màn hình
 Navigation: Điều hướng giữa các màn hình
 State management: quản lí trạng thái dữ liệu và trạng thái toàn cục bằng redux,
zustand, context api. Trong đề tài này, redux được sử dụng để quản lí trạng
thái dữ liệu
 Service: Giao tiếp api và websocket, chứa logic giao tiếp với server, gọi api,
hoặc xử lí dữ liệu cục bộ
 Assets: Tài nguyên và thư viện UI
3.2 Triển khai
3.2.1 Khởi tạo dự án
Dự án React (hay MobiApp) cần được liên kết với dự án Firebase của hệ thống.
Firebase sẽ đóng vai trò là nhà cung cấp dịch vụ xác thực tài khoản, dịch vụ gửi
thông báo tới Smartphone (Smartphone) v.v.
Xây dựng kiến trúc dự án react native:
Mở terminal và gõ npx-create-expo-app@latest sau đó đặt tên cho dự án
Hình 3.1 Sử dụng terminal để tạo dự án
21
Sau khi tạo mới, máy tính tự động tải về các file quan trọng, sẵn sàng cho việc
thiết kế giao diện
Dựa vào sơ đồ tổng quan của phân hệ MobiApp, có thể thấy kiến trúc dự án mã
nguồn React được xây dựng theo dạng modular và feature-based đễ dễ dàng mở
rộng, bảo trì và test.
Ngoài những thư mục/tệp tin được cấu hình sẵn của react native, dưới đây là kiến
trúc chính của dự án react.
Hình 3.2 Cấu trúc của dự án
Một số thư mục, tệp chính trong dự án:
 Component: Chứa các thành phần tái sử dụng của dự án
 Configs: Chứa các file cấu hình đến firebase, redux
 Hooks: Chứa các hook do lập trình viên tự thiết kế
 Navigation: Điều hướng các màn hình
 Redux: Quản lí trạng thái components
 Screens: Chứa các thiết kế màn hình
 Service: Giao tiếp với backend
22
 Utils: xây dựng các hàm, thư viện hỗ trợ dùng chung cho các Module (nếu cần)
3.2.2 Setup redux toolkit:
Redux là một state management phổ biến trong hệ sinh thái react. Redux được
phát triển từ những năm 2015 và được ưa chuộng phổ biến giúp việc quản lí state
trong react trở nên dễ dàng. Tuy nhiên, redux core lại gặp vấn đề về tái sử dụng
code đồng thời việc cấu hình cũng khá phức tạp. Sau khi tìm hiểu qua các giải pháp,
chúng em đã quyết định sử dụng react toolkit trong đề tài này. RTK giúp việc code
reduce trở nên gọn hơn, nhanh hơn và hoàn chỉnh theo một quy chuẩn thống nhât
Quy trình xây dựng:
Mở terminal và gõ npm i @reduxjs/toolkit để cài đặt thư viện
Hình 3.3 cài đặt RTK bằng terminal
Tạo một store trong ứng dụng bằng cách sử dụng configureStore() từ RTK.
File này đóng vai trò là trung tâm quản lí trạng thái toàn cục.
Các thành phần của file bao gồm:
 ConfigureStore(): API từ RTK để tạo redux store một cách đơn giản, tích
hợp sẵn middleware như redux-thunk, redux-devtools
 Reducer: Gộp nhiều slice thành một reducer tổng
 Store.getState: Lấy toàn bộ state hiện tại của ứng dụng
 Store.dispatch: Gửi action để thay đổi state
 RootState và AppDispatch: Định nghĩa kiểu dữ liệu cho state
23
Hình 3.4 Tạo store trong dự án
Tạo slice với redux toolkit
Một slice là một bộ logic reducer Redux và hành động cho một tính năng duy
nhất của ứng dụng.
Hàm createSlice của RTK đơn giản hóa việc viết reducer và tạo ra hành động
Ngoài ra còn các phương thức khác như PayloadAction<T> dùng để khai báo dữ
liệu đi kèm action, RootState định nghĩa kiểu của toàn bộ state trong Redux store
Hình 3.5 Tạo slice trong dự án
Cuối cùng bọc thẻ <Provider store ={store}> bên ngoài các component khác
24
Hình 3.6 Sử dụng RTK
3.2.3 Setup firebase và persist dữ liệu đăng nhập
Firebase là một kiểu back-end service của google, cung cấp nhiều tính năng
mạnh mẽ giúp phát triển ứng dụng mobile trở nên dễ dàng hơn
Quy trình xây dựng:
Mở terminal và gõ npm i firebase để cài đặt thư viện
Hình 3.7 Tải thư viện firebase bằng terminal
Truy cập vào trang web https://console.firebase.google.com/ và tạo project
Sau khi tạo thành công project, chọn vào project vừa tạo -> develop ->
Authentication -> Sign-in methode -> ở Sign-in provider chọn Email/Password.
Enable và save lại
25
Hình 3.8 enable email authenticate
Tiếp theo tạo file firebaseConfig.js để tiến hành kết nối đến firebase:
Hình 3.9 Config firebase
3.3 Giao tiếp giữa mobiapp – sever backend/firebase
Hình 3.10 Sơ đồ tổng quan về giao tiếp giữa mobile app và sever backend
MobiApp và Server Backend / Firebase trao đổi dữ liệu với nhau bằng dữ liệu
dạng JSON (phụ lục 2).
26
1. Giao tiếp http
Những dữ liệu về người dùng, Device, danh sách thông báo, xác thực v.v.
mà không cần có sự kết nối theo thời gian thực, hệ thống sử dụng giao tiếp
http với tiêu chuẩn JWT (phụ lục 3) và tiêu chuẩn RESTful API (phụ lục 4).
Trong đó, JWT sẽ có nhiệm vụ xác thực tài khoản với Server Backend, còn
RESTful API là tiêu chuẩn áp dụng để thiết kế các APIs, giúp MobiApp gửi
và nhận dữ liệu với Server Backend.
2. Giao tiếp socket
Những dữ liệu mang tính chất thời gian thực (Ví dụ: vị trí, trạng thái của
Device v.v.), hệ thống sử dụng giao tiếp socket (phụ lục 5) để đảm bảo mọi
thứ được tự động cập nhật trên giao diện người dùng. Sau khi đã đăng nhập
thành công, MobiApp sẽ khởi tạo và xác thực socket
3. Giao tiếp fcm
FCM là dịch vụ của Firebase cung cấp, với nhiệm vụ gửi riêng thông báo
từ hệ thống tới Smartphone (không liên quan tới MobiApp). Mỗi Smartphone
khi được xác thực với Firebase, sẽ được cung cấp một fcmToken – mã này gần
giống như địa chỉ của Smartphone, thứ sẽ giúp những FCM được gửi tới đúng
đích.
Khi hệ thống nhận thấy cần gửi thông báo, Firebase sẽ gửi FCM tới những
Smartphone đã đăng nhập với tài khoản trước đó đã xác thực với Firebase.
Hình 3.11 Ví dụ về danh sách fcm token một tài khoản sẽ lưu
3.4 Thiết kế luồng hoạt động một số dịch vụ
3.4.1 Luồng điều hướng màn hình khi mở MobiApp
27
Khi mới mở MobiApp từ Smartphone, MobiApp sẽ điều hướng màn hình hiển
thị đầu tiên dựa vào luồng dưới đây.
Hình 3.12 Luồng điều hướng màn hình khi mở app
Mô tả hoạt động:
Khởi động ứng dụng: Người dùng mở app trên thiết bị
Kiểm tra đăng nhập: Ứng dụng kiểm tra xem người dùng đã đăng nhập trước
đó hay chưa (thông qua token xác thực JWT)
Xác định trạng thái đăng nhập: Nếu chưa đăng nhập thì chuyển đến trang
đăng nhập, nếu đã đăng nhập thì tiến hành kết nối socket với sever backend
Kết nối socket: Sau khi xác thực, tạo kết nối socket đến sever backend để
đồng bộ trạng thái thiết bị.
Vào trung tâm điều khiển: Khi kết nối socket hoàn tất, điều hướng người
dùng vào trang trung tâm điều khiển
28
3.4.2 Luồng đăng kí tài khoản mới
Luồng đăng kí tài khoản mới được thể hiện ở ảnh dưới
Hình 3.13 Luồng đăng kí tài khoản
Mô tả hoạt động:
Nhập thông tin: Người dùng nhập thông tin
Xác nhận thông tin hợp lệ: Sau khi kiểm tra thông tin hợp lệ, tiến hành lưu
fcm token và gọi api đăng kí tài khoản, nếu không hiển thị lỗi
Xử lý phản hồi từ server backend: Nếu đăng kí thành công, lưu lại access
token và chuyển về màn hình điều khiển thiết bị, nếu thất bại thông báo lỗi
cho người dùng
3.4.3 Luồng đăng nhập tài khoản
Luồng đăng nhập tài khoản được thể hiện ở ảnh bên dưới:
29
Hình 3.14 Luồng đăng nhập tài khoản
Mô tả hoạt động:
Nhập thông tin: Người dùng nhập thông tin
Xác nhận thông tin hợp lệ: Sau khi kiểm tra thông tin hợp lệ, tiến hành lưu
fcm token và gọi api đăng nhập, nếu không hiển thị lỗi
Xử lý phản hồi từ server backend: Nếu đăng kí thành công, lưu lại access
token và chuyển về màn hình điều khiển thiết bị, nếu thất bại thông báo lỗi
cho người dùng
3.4.4 Luồng kết nối máy chủ socket
Hình 3.15 Luồng kết nối máy chủ socket
30
Mô tả hoạt động:
Khởi tạo socket: sử dụng url nhận được của socket server và user access token
tiến hành tạo kết nối đến server
Xác thực socket: Ngay sau khi socket được khởi tạo, client sẽ gửi Access
token để xác thực danh tính người dùng với socket server
Kiểm tra kết nối: Nếu kết nối thất bại, hiển thị lỗi kết nối, nếu kết nối thành
công tiến hành nhận dữ liệu
Xử lí dữ liệu: Dữ liệu JSON nhận được từ socket sẽ được thực hiện một số
Action tùy vào nội dung (ví dụ: cập nhật trạng thái thiết bị, hiển thị thông báo
thời gian thực...).
3.4.5 Luồng chung của 1 restful api
Hình 3.16 Luồng thực hiện chung của một RESTful API
Mô tả hoạt động:
Action: Người dùng thực hiện hành động trong ứng dụng (nhấn nút, kéo thanh
trượt…)
Gửi event tới bloc (RTK): Ứng dụng gửi dữ liệu đến RTK để xử lí yêu cầu,
bloc nhận event, quyết định hành động cần thực hiện
31
Bloc gửi Request tới repository: Bloc tạo ra một request và gửi cho lớp
repository
Repository gọi API server: thực hiện các http request (bằng axios), gửi các
request với method tới url của server
Nhận dữ liệu: server trả lại json data về servic, service trả response về
repository, rồi đến bloc, bloc cập nhật state mới, tiến hành re-render
component để hiển thị dữ liệu mới
3.5 Một số giao diện phân hệ mobile app
3.5.1 Giao diện đăng kí
Giao diện của màn hình:
 Ô nhập email
 Ô nhập tên
 Ô nhập số điện thoại
 Ô nhập password
 Ô xác nhận mật khẩu
 Nút đăng kí để thực thi tính năng đăng kí thông tin tài khoản (nút bấm sẽ được
cho phép nhấn, đổi màu đỏ khi người nhập đủ thông tin phía trên), đồng thời
điều hướng tới màn hình bảng điều khiển (nếu đã đăng kí tài khoản và đăng kí
thông tin thành công. Nếu không đăng kí thành công, cần đăng kí lại).
 Nút quay lại trang login
32
Hình 3.17 Giao diện đăng kí
3.5.2 Giao diện đăng nhập
 Ô nhập email
 Ô nhập password
 Nút bấm Sign In để thực thi tính năng đăng nhập (nút bấm sẽ được cho phép
nhấn, đổi màu đỏ khi người nhập đủ thông tin phía trên), đồng thời điều hướng
tới màn hình bảng điều khiển (nếu đã đăng nhập thành công).
Hình 3.18 Giao diện đăng nhập
33
3.5.3 Giao diện trung tâm
 Hiển thị nhiệt độ và thời tiết
 Hiển thị vài thiết bị ở các phòng hay sử dụng
 Hiển thị thông báo (nếu có)
Hình 3.19 Giao diện trung tâm
3.5.4 Giao diện chi tiết các phòng
 Hiển thị các phòng hiện có
 Hiển thị số thiết bị trong phòng
 Bấm vào phòng sẽ hiển thị các thiết bị hiện có trong phòng đó
34
Hình 3.20 Giao diện các phòng
3.5.5 Giao diện chi tiết thiết bị
 Nút bấm để bật tắt thiết bị
 Thanh trượt để điều chỉnh độ mạnh yếu
Hình 3.21 Giao diện chi tiết thiết bị
3.5.6 Giao diện cài đặt
 Nút edit profile cho phép người dùng sửa thông tin cá nhân
35
 Nút face recognize để tiến hành nhận diện khuôn mặt
 Nút Person information để xem thông tin cá nhân
 Nút change password để đổi thông tin
 Nút logout để đăng xuất
Hình 3.22 giao diện cài đặt
36
CHƯƠNG 4. THIẾT KẾ VÀ TRIỂN KHAI PHÂN HỆ DEVICE
4.1
Sơ đồ tổng quan của phân hệ
 Phân hệ device gồm các khối sau:
 MCU: Khối đóng vai trò trung tâm của phân hệ, chịu trách nhiệm xử lí dữ liệu,
điều khiển cảm biến, quản lý nguồn và gửi dữ liệu. Khối này có thể là ESP32,
STM32, Arduino,…
 Sensor: Thu thập thông tin từ môi trường(nhiệt độ, độ ẩm, ánh sáng, mưa,…)
đồng thời gửi dữ liệu về cho MCU xử lý. Khối này có các cảm biến như
(DHT11, HC-SR04, HC-SR01)
 Power: Cung cấp điện áp cho các thiết bị. Có thể dùng nguồn trực tiếp từ
laptop, nguồn ngoài như pin sạc, pin mặt trời. MCU thường cần nguồn 3.3v
hoặc 5v
 Alert: Cảnh báo người dùng hoặc hệ thống khi có sự cố. Các thiết bị có thể là
buzzer, led, hoặc gửi tín hiệu cảnh báo qua wifi
 Communicate(giao tiếp với các hệ thống bên ngoài – IOT, REST API, MQTT,
Socket): giúp thiết bị gửi và nhận dữ liệu với hệ thống. Có thể giao tiếp bằng
wifi, bluetooth, mqtt hoặc rest api
Hình 4.1 Sơ đồ tổng quan của phân hệ device
4.2
Triển khai phân hệ
4.2.1 Thiết kế luồng hoạt động của một số dịch vụ
1. Luồng hoạt động tổng quan của device
37
Hình 4.2 Sơ đồ hoạt động tổng quan của thiết bị
2. Luồng hoạt động khi các điều kiện bên ngoài tác động đến các cảm
biến
Hình 4.3 Luồng hoạt động khi giá trị cảm biến thay đổi
4.2.2 Phần cứng của device
1. Sơ đồ khối tổng quan của phần cứng
38
 Dựa vào sơ đồ tổng quan của Device, phần cứng sẽ được triển khai với sơ đồ
khối, linh kiện của từng khối, cách thức giao tiếp giữa các khối như sau:
 Khối MCU: kit NodeMCU ESP32
 Khối Power: Pin 18650
 Khối sensor: Rain water sensor, PIR SR501,BH1750, DHT11, MQ-2, flame
sensor
 Khối communicate: Module sim
 Khối alert: còi, đèn led
 Nút bấm thao tác với device
Hình 4.4 Sơ đồ tổng quan phần cứng của device
2. Giới thiệu các phần cứng
a. Esp32
Kit Wifi BLE ESP32 NodeMCU-32S CH340 Ai-Thinker được phát triển trên
nền Vi điều khiển trung tâm là ESP32 SoC với công nghệ Wifi, BLE và kiến trúc
ARM mới nhất hiện nay, kit có thiết kế phần cứng, firmware và cách sử dụng tương
tự Kit NodeMCU ESP8266, với ưu điểm là cách sử dụng dễ dàng, ra chân đầy đủ,
39
tích hợp mạch nạp và giao tiếp UART CH340, thích hợp với các nghiên cứu, ứng
dụng về Wifi, BLE, IoT và điều khiển, thu thập dữ liệu qua mạng.
Thông số kỹ thuật:

Nhà sản xuất: Ai-Thinker

Module trung tâm: Ai-Thinker ESP32-S

SPI Flash: 32Mbits

Frequency Range: 2400~2483.5Mhz

Bluetooth: BLE 4.2 BR/EDR

Wifi: 802.11 b/g/n/e/i

Support Interface: UART/SPI/SDIO/I2C/PWM/I2S/IR/ADC/DAC

Nguồn sử dụng: 5VDC từ cổng Micro USB.

Tích hợp mạch nạp và giao tiếp UART CH340

Chuẩn 38 chân cắm 2.54mm, ra chân đầy đủ module ESP32.

Tích hợp Led Status, nút nhấn IO0 (BOOT) và ENABLE.

Kích thước: 25.4 x 48.3mm
Hình 4.5 Esp32
b. Rain water sensor
Cảm biến nước mưa (Rain Water Sensor ) được sử dụng để phát hiện mưa,
nước hoặc các dung dịch dẫn điện tiếp xúc với bề mặt cảm biến sẽ phát ra tín
hiệu để làm các ứng dụng tự động: phát hiện mưa, báo mực nước tự động,...
Thông số kỹ thuật:
40

Điện áp sử dụng: 5VDC

Kích thước tấm cảm biến mưa: 54 x 40mm

Kích thước board PCB: 30 x 16mm

Tín hiệu đầu ra: Digital TTL (0VDC / 5VDC) và đầu ra Analog A0 trả giá trị
điện áp tuyến tính theo lượng nước tiếp xúc với cảm biến.

Lỗ cố định bu lông dễ dàng để cài đặt

Có đèn báo hiệu nguồn và đầu ra

Độ nhạy có thể được điều chỉnh thông qua chiết áp

LED sáng lên khi không có mưa đầu ra cao, có mưa, đầu ra thấp LED tắt.
chế độ kết nối:

VCC: Nguồn

GND: Đất

D0: Đầu ra tín hiệu TTL chuyển đổi

A0: Đầu ra tín hiệu Analog
Hình 4.6 rain sensor
c. Pir SR501
41
Cảm biến thân nhiệt chuyển động PIR (Passive infrared sensor) HCSR501 được sử dụng để phát hiện chuyển động của các vật thể phát ra bức xạ
hồng ngoại (con người, con vật, các vật phát nhiệt,...), cảm biến có thể chỉnh
được độ nhạy để giới hạn khoảng cách bắt xa gần cũng như cường độ bức xạ của
vật thể mong muốn, ngoài ra cảm biến còn có thể điều chỉnh thời gian kích trễ
(giữ tín hiệu bao lâu sau khi kích hoạt) qua biến trở tích hợp sẵn.
Thông số kỹ thuật:

Phạm vi phát hiện : góc 360 độ hình nón, độ xa tối đa 6m.

Nhiệt độ hoạt động : 32-122 ° F ( 050 ° C)

Điện áp hoạt động : DC 3.8V - 5V

Mức tiêu thụ dòng: ≤ 50 uA

Thời gian báo: 30 giây có thể tùy chỉnh bằng biến trở.

Độ nhạy có thể điều chỉnh bằng biến trở.

Kích thước: 1,27 x 0,96 x 1.0 ( 32,2 x 24,3 x 25,4 mm)
Hình 4.7 HC-SR501
42
d. DHT11
Cảm biến độ ẩm và nhiệt độ DHT11 Temperature Humidity Sensor
là cảm biến rất thông dụng hiện nay vì chi phí rẻ và rất dễ lấy dữ liệu thông qua
giao tiếp 1 wire (giao tiếp digital 1 dây truyền dữ liệu duy nhất). Bộ tiền xử lý
tín hiệu tích hợp trong cảm biến giúp bạn có được dữ liệu chính xác mà không
phải qua bất kỳ tính toán nào. So với cảm biến đời mới hơn là DHT22 thì DHT11
cho khoảng đo và độ chính xác kém hơn rất nhiều.
Thông tin kỹ thuật:

Nguồn: 3 -> 5 VDC.

Dòng sử dụng: 2.5mA max (khi truyền dữ liệu).

Khoảng đo độ ẩm: 20%-90% RH (sai số 5%RH)

Khoảng đo nhiệt độ: 0-50°C (sai số 2°C)

Tần số lấy mẫu tối đa: 1Hz (1 giây / lần)

Kích thước 15mm x 12mm x 5.5mm.
Hình 4.8 Cảm biến độ ẩm
43
e. BH1750
Cảm biến ánh sáng BH1750 Digital Light Sensor được sử dụng để đo
cường độ ánh sáng theo đơn vị lux, càm biến có ADC nội và bộ tiền xử lý nên
giá trị được trả ra là giá trị trực tiếp cường độ ánh sáng lux mà không phải qua
bất kỳ xử lý hay tính toán nào thông qua giao tiếp I2C.
Thông số:

Nguồn: 3~5VDC

Điện áp giao tiếp: TTL 3.3~5VDC

Chuẩn giao tiếp: I2C

Khoảng đo: 1 -> 65535 lux

Kích cỡ: 21*16*3.3mm
Một số ví dụ về độ rọi của ánh sáng:

Vào buổi tối : 0.001 - 0.02 Lux

Ánh trăng : 0.02 - 0.3 lux

Trời nhiều mây trong nhà : 5 - 50 lux

Trời nhiều mây ngoài trời : 50 - 500 lux

Trời nắng trong nhà : 100 - 1000 lux

Ánh sáng cần thiết để đọc sách: 50 - 60 lux
Hình 4.9 Cảm biến ánh sáng
44
f. MQ-2
Cảm biến khí Gas (LPG/CO/CH4) MQ-2 sử dụng phần tử SnO2 có độ
dẫn điện thấp hơn trong không khí sạch, khi khí dễ cháy tồn tại, cảm biến có độ
dẫn điện cao hơn, nồng độ chất dễ cháy càng cao thì độ dẫn điện của SnO2 sẽ
càng cao và được tương ứng chuyển đổi thành mức tín hiệu điện. MQ-2 là cảm
biến khí có độ nhạy cao với LPG, Propane và Hydrogen, mê-tan (CH4) và hơi
dễ bắt lửa khác, với chi phí thấp và phù hợp cho các ứng dụng khác nhau.
Cảm biến khí Gas (LPG/CO/CH4) MQ-2 xuất ra cả hai dạng tín hiệu là
Analog và Digital, tín hiệu Digital có thể điều chỉnh mức báo bằng biến trở.
Thông số kỹ thuật:

Cảm biến chính: MQ-2 (LPG/CO/CH4)

Nguồn sử dụng: 5VDC
Chuẩn giao tiếp: Analog / Digital.
Hình 4.10 Cảm biến khí gas
g. Flame sensor
Cảm biến phát hiện lửa (flame sensor) thường được sử dụng cho các ứng
dụng phát hiện lửa như: xe robot chữa cháy, cảm biến lửa,... Tầm phát hiện của
cảm biến trong khoảng 80cm, góc quét là 60 độ, có thể phát hiện lửa tốt nhất là
loại có bước sóng từ 760nm - 1100nm.
45
Cảm biến phát hiện lửa (flame sensor) có hai ngõ ra tín hiệu là Digital và
Analog rất dễ dử dụng.
Thông số kỹ thuật:

Nguồn cấp: 3.3V - 5VDC

Dòng tiêu thụ: 15mA

Tín hiệu ra: Digital 3.3 - 5VDC tùy nguồn cấp hoặc Analog.

Khoảng cách : 80 cm

Góc quét : 60 độ

Kích thước : 3.2 x 1.4 cm
Hình 4.11 Cảm biến cháy
3. Luồng gửi nhận giữa device và hệ thống
a. Mô hình gửi nhận dữ liệu tổng quan giữa device và hệ thống
Device sẽ giao tiếp với phân hệ Backend Server thông qua MQTT, với
MQTT Broker Server là thành phần trung gian phân phối MQTT
Hình 4.12 Mô hình gửi nhận dữ liệu tổng quan giữa device và hệ thống
46
Khối MQTT BROKER SERVER: sử dụng MQTT Broker miễn phí của dịch
vụ HIVEMQ. Các khối còn lại muốn giao tiếp cần Subscribe, Publish với đúng
đường dẫn trên với bản tin được quy định trước.
Khối DEVICE: sử dụng mô-đun SIM 7020C để gửi, nhận gói tin MQTT.
Khối BACKEND – SERVER: sử dụng thư viện mqtt với NodeJS (trình bày ở
chương dưới).
Quy ước:
Subscriber: Khối nhận dữ liệu, với hành động Subscribe
Publisher: Khối gửi dữ liệu, với hành động Publish
Như vậy, 2 khối giao tiếp MQTT là Device và Backend - Server có
thể đóng vai trò là Subscriber hoặc Publisher. MQTT Broker Server
đóng vai trò trung chuyển gói tin.
Thiết kế chủ đề, dữ liệu của gói tin MQTT:
Quy định chủ đề truyền nhận giữa Device và Server:
 Mỗi chủ đề phải là duy nhất trên từng thiết bị( dựa vào device Id), để mỗi
gói tin MQTT biết được nó sẽ đi về đâu
 Chủ đề 1: Publisher (device) gửi gói tin lên subscriber (backend server)
thông qua MQTT broker: /serviceTopic/sensorData/name với name là tên
của loại sensor gửi dữ liệu
 Chủ đề 2: Subscriber(device) nhận gói tin từ Publisher (backend server)
thông qua MQTT broke: /serviceTopic/update/{id} với id là device id
b. Giao tiếp giữa MCU và mô-đun SIM7020C
Khối truyền thông COMMUNICATE có nhiệm vụ giúp Device giao tiếp với
hệ thống. Khối này sử dụng mô-đun SIM 7020C, hỗ trợ tập lệnh AT (phụ lục 19)
giúp kiểm tra các thông số của mô-đun, cũng như nhận yêu cầu từ MCU để thực
hiện một số dịch vụ (Ví dụ: kết nối, đăng kí bản tin, gửi nhận gói tin MQTT)
47
Một số tập lệnh AT của SIM7020 nhằm giúp kiểm tra các thông tin cơ bản
của sim như kiểm tra sim, sóng RF...
Hình 4.13 một số tập lệnh AT của SIM7020
Hình 4.14 Tập lệnh At kết nối với sever
c. Luồng gửi dữ liệu từ device
Hình 4.15 Luồng gửi dữ liệu từ device
48
Khối MCU sẽ gửi những lệnh điều khiển “AT COMMAND” để mô-đun SIM
phân tích, thực hiện những dịch vụ MCU yêu cầu.
Ví dụ một câu lệnh “AT COMMAND” gửi từ MCU cho mô-đun SIM:
AT+CMQPUB=0,"/home/kitten/,0,0,0,95,"{"deviceId":"B0:A7:32:DE:92:84,"
status":0}
AT+CMQPUB: yêu cầu mô-đun SIM xuất bản một gói tin MQTT.Trong đó
(sau dấu = từ trái qua phải):
• 0: MQTT id, nhận được khi thực hiện lệnh AT+CMQNEW
• "/home/kitten/: bản tin quy định trước đó
• 0: thông số QoS (Quality of Service), giá trị là 0/1/2, chọn lựa tuỳ vào mức
độ QoS bài toán yêu cầu, nếu cần xử phản hồi bản tin, lựa chọn 1 hoặc 2
• 0: cờ giữ lại, giá trị là 0/1, được sử dụng để đảm bảo rằng các client mới kết
nối vào hệ thống có thể nhận được thông tin quan trọng nhất (gói tin cuối cùng)
của một topic ngay khi họ tham gia, và nó giúp quản lý gói tin lưu giữ của các
topic trong hệ thống MQTT.
• 0: cờ trùng lặp, giá trị là 0/1, sử dụng để xác định xem một gói tin có phải là
bản sao của một gói tin đã được gửi trước đó hay không, giúp đảm bảo tính nhất
quán trong hệ thống MQTT.
• 95: độ dài chuỗi data (từ 2 đến 1000)
• "{"deviceId":"B0:A7:32:DE:92:84"," status":0 }" : dữ liệu dạng JSON được
gửi kèm “MQTT Message” được đóng gói chứa: chủ đề, dữ liệu.
Khối MQTT BROKER SERVER có nhiệm vụ: phân phối “MQTT Message”
tới những Subscriber nào Subscribe chủ đề kèm trong gói tin.
Khối BACKEND SERVER nhận những “MQTT Message” mà mình đã đăng
kí chủ đề trong gói tin đó.
d. Luồng nhận dữ liệu trên device
Hình 4.16 Luồng nhận dữ liệu
49
Khối MQTT BROKER SERVER có nhiệm vụ: phân phối “MQTT Message”
tới những Subscriber nào Subscribe chủ đề kèm trong gói tin.
Mô-đun SIM cần đăng kí chủ đề chứa trong “MQTT Message”.
Mỗi khi Mô-đun SIM nhận “MQTT Message” từ Publisher thông qua chủ đề
đã đăng kí, mô-đun này sẽ nhận lượng thông tin đó, xử lý gói tin, sau đó tiến
hành gửi CMQ Data cho MCU để phân tích dữ liệu.
4.2.3 Chương trình nhúng firmware của device
Các chương trình được thiết kế bằng ngôn ngữ lập trình C/C++ cùng với các
thư viện hỗ trợ. Chương trình sẽ được nạp vào vi điều khiển esp32 để thực hiện
các tính toán logic của các dịch vụ trên device
1. Setup device:
Để có thể đọc và điều khiển tín hiệu của device, ta phải tiến hành khai báo các
chân kết nối của device, xác định trạng thái của chân đó:
Hình 4.17 khai báo chân device
Khi sử dụng cần lưu ý tránh các chân GPIO0 GPIO4 GIPO12, đó là những
chân boot, việc thay đổi điện áp có thể khiến mạch không thể nạp chương trình
Xác định mode của các chân. INPUT sẽ nhận tín hiệu điều khiển từ esp32
trong khi output sẽ được đọc bằng digitalRead() hoặc analogRead ()
50
Hình 4.18 Xác định mode của chân
Để có thể gửi được dữ liệu lên mqtt broker cũng như giao tiếp giữa các esp
đòi hỏi esp đang sử dụng phải được kết nối wifi
Để có thể kết nối wifi trên esp, cần có SSID và password của mạng
Hình 4.19 Kết nối wifi cho esp32
Trong đó:
Ssid là tên của mạng đang sử dụng
Password là mật khẩu của mạng
Ngoài ra khi esp được kết nối mạng sẽ sinh ra 1 localIP khác nhau, để thuận
tiện hơn cho việc cấu hình trong đề tài này em sẽ gán một localIp cố đinh cho
esp thông qua các tham số được cấu hình sẵn như trên
Kết nối MQTT: Thông qua mqtt các thiết bị có thể giao tiếp với nhau theo mô
hình pub/sub client.
51
Hình 4.20 kết nối mqtt với esp32
Trong đó:
MQTT_BROKER_ADDRESS: địa chỉ domain của MQTT Broker server
MQTT_USERNAME: Tên đăng nhập để xác thực vào MQTT Broker
MQTT_PASSWORD: Mật khẩu đi kèm để xác thực với MQTT Broker
MQTT_PORT: cổng kết nối của MQTT Broker, với giá trị 1883(không SSL)
và 8883 (SSL/TLS)
Sơ đồ luồng kết nối MQTT broker
Hình 4.21 Sơ đồ kết nối mqtt broker
52
2. Đọc dữ liệu từ sensor
Sau khi hoàn tất cấu hình các chân GPIO và thiết lập kết nối mạng, bước tiếp
theo là thực hiện thu thập dữ liệu từ các cảm biến được kết nối với esp32
Phân loại tín hiệu cảm biến: Có 2 loại tín hiệu cảm biến thường được sử dụng
là tín hiệu analog và tín hiệu degital
 Tín hiệu analog:
Các cảm biến như khí gas, ánh sáng, nhiệt độ xuất ra các tín hiệu dạng
điện áp tuyến tính giao động trong khoảng 0v-3.3v
Esp32 sử dụng hàm analogRead(pin) để đọc giá trị điện áp. Giá trị trả về
nằm trong khoảng giá trị 0-4095 (tương ứng 0v-3.3v)
 Tín hiệu digital
Các cảm biến như cảm biến chuyển động, công tắc hành trình sẽ trả về
tín hiệu logic (digital)
Esp32 sử dụng hàm digitalRead (pin) để đọc giá trị. Giá trị nhận được
tương ứng là 0 và 1 (low và high)
Hình 4.22 Đọc giá trị sensor
Một số lưu ý trong việc đọc dữ liệu từ sensor:
Mạch ESP32 hỗ trợ đo tín hiệu Analog ở 18 kênh khác nhau. Sơ đồ chân trên
board để xác định vị trí các trang ESP32 ADC:
53
Hình 4.23 Sơ đồ chân của esp32
Dựa trên sơ đồ chân ta thấy có tổng cộng 18 kênh adc1 để đọc tín hiệu analog.
Ngoài ra không sử dụng các chân khác như adc2 để đọc tín hiệu analog do adc2
bị chiếm tài nguyên bởi wifi driver sẽ làm xung đột gây lỗi
Ngoài ra việc các tín hiệu analog bị nhiễu là điều khó tránh khỏi. Chính vì vậy
để đảm bảo tính chính xác của giá trị, em đã thực hiện việc lấy trung bình cộng
nhiều lần để đảm bảo tính ổn định
Đối với các cảm biến như khí gas hay cảm biến cháy, cần thiết lập các ngưỡng
để phân biệt trạng thái bất thường
Hình 4.24 Ví dụ ngưỡng cảnh báo của gas sensor
3. Gửi dữ liệu về mqtt để xử lí
54
Sau khi thu thập dữ liệu hoàn tất. tiến hành chuẩn hóa dữ liệu theo kiểu json
và gửi về mqtt broker để backend xử lý
Hình 4.25 Mã nguồn publish data
Khi dữ liệu được publish, hàm callback ở server sẽ được gọi để tiến hành sử
lí dữ liệu
Hình 4.26 Mã nguồn hàm callback
55
CHƯƠNG 5. THIẾT KẾ VÀ TRIỂN KHAI PHÂN HỆ SERVER
BACKEND
Chương 5 trình bày quá trình thiết kế và triển khai phân hệ Server Backend, đóng
vai trò trung tâm trong việc xử lý dữ liệu và hình ảnh của hệ thống nhà thông minh ứng
dụng Deep Learning.
Phân hệ Server được chia thành hai hệ thống độc lập:
Server Backend 1 (BEApp): Phụ trách quản lý dữ liệu người dùng, thiết bị, trạng
thái cảm biến, và hệ thống thông báo. Server này được xây dựng bằng Node.js, kết nối
Firestore Database của Firebase để lưu trữ dữ liệu. BEApp cung cấp các API RESTful
cho Mobile App giao tiếp, đồng thời sử dụng WebSocket để cập nhật dữ liệu thời gian
thực và giao tiếp với thiết bị qua MQTT Broker.
Server Backend 2 (AI Server): Đóng vai trò nhận hình ảnh được gửi từ các thiết
bị ESP32-CAM, tiến hành xử lý bằng mô hình FaceNet để trích xuất đặc trưng khuôn
mặt (embedding vector). Các vector này được lưu trữ để phục vụ cho quá trình nhận
diện khuôn mặt, phát hiện người lạ hoặc xác thực người dùng hợp lệ. Server 2 được xây
dựng bằng Python (Flask hoặc FastAPI) kết hợp TensorFlow và OpenCV.
Hệ thống sử dụng một VPS chạy Ubuntu Server 20.04 để triển khai server, sử
dụng dịch vụ EMQX Cloud làm MQTT Broker để trung chuyển dữ liệu MQTT.
Cơ sở dữ liệu Firestore lưu trữ các thông tin như người dùng, thiết bị, phòng,
thông báo, và embedding vector khuôn mặt.
Các luồng hoạt động chính của hệ thống bao gồm:
Mobile App giao tiếp với BEApp thông qua HTTP API.
BEApp nhận dữ liệu từ MQTT Broker, lưu trữ và gửi cảnh báo về Mobile App.
ESP32 Camera gửi hình ảnh về AI Server để xử lý Deep Learning.
AI Server phân tích hình ảnh, trích xuất đặc trưng khuôn mặt bằng FaceNet, và
cập nhật dữ liệu khuôn mặt lên hệ thống.
Hệ thống gửi thông báo cảnh báo nếu phát hiện người lạ hoặc hành vi bất thường.
56
Việc tách riêng hai server theo nhiệm vụ không chỉ tối ưu hóa tài nguyên, mà
còn giúp hệ thống dễ dàng mở rộng về sau, đặc biệt là khi số lượng thiết bị và khối
lượng hình ảnh tăng cao.
5.1
Sơ đồ tổng quan của phân hệ
Hình 5.1 Sơ đồ tổng quan của phân hệ backend
Phân hệ Server – Backend gồm các khối như sau:
5.1.1 Cloud server
Clound server hay VPS là viết tắt của Virtual private server (máy chủ riêng ảo).
Lí do nó được gọi là virtual (ảo) là vì nó được chia ra từ các máy tính vật lý của bên
nhà cung cấp (1 máy tính vật lý tạo ra nhiều VPS) và thường sẽ cấp cho người
mua/thuê 1 hoặc nhiều địa chỉ static public IP để có thể kết nối và sử dụng tùy vào
mục đích.
Hệ thống chọn VPS có cấu hình như sau:
 Hệ điều hành: Ubuntu server 20.04
 CPU: Intel Xeon E5 2696v4 x 2
 Memory: DRR4 ECC 4Gb
 SSD: 20Gb
 IP: 1 x Ipv4
57
5.1.2 Database:
Hệ thống sử dụng service của Firebase– Firestore đóng vai trò làm DB, dịch vụ
này tương tự như một NoSQL cloud DB.
Điểm khác biệt của Firestore và các NoSQL DB khác, đó là việc dịch vụ cung
cấp SDK cho cả các ứng dụng IOS/Android/Web chứ không cung cấp riêng cho mỗi
ứng dụng phía Backend. Từ đó có thể giúp các ứng dụng này có thể truy xuất, cập
nhật DB mà không cần thiết phải có ứng dụng phía Backend.
Cụ thể với hệ thống này, phía BEApp sẽ kết nối tới Firestore qua SDK của
Firebase là firebase-admin.
5.1.3 BEApp:
Khối chứa các ứng dụng chạy phía Server – Backend, các ứng dụng này chạy
trên một hệ điều hành (cài trên một máy tính), có khả năng tương tác để thực thi các
tính năng cần thiết như: tạo Webserver, cung cấp API, kết nối DB, chỉnh sửa file
trên hệ thống...
Hệ thống sử dụng dụng BEApp được triển khai bằng NodeJS – môi trường chạy
của ngôn ngữ lập trình JS
Các thành phần kết nối với BEApp và giao thức tương ứng:
Với DB: sử dụng dịch vụ Firestore, dùng thư viện firebase-admin (SDK của
Firebase cung cấp cho NodeJs)
Với MQTT Broker: sử dụng thư viện MQTT cung cấp cho NodeJS.
Với Client: BEApp cung cấp RESTful API cho MobiApp giao tiếp, sử dụng giao
thức HTTP 1.1
Ngoài ra, BEApp cũng được triển khai như một Websocket Server (WS), giúp
giao tiếp thời gian thực với MobiApp
5.1.4 MQTT Broker:
Hệ thống sử dụng dịch vụ cung cấp MQTT Broker của Emqx – một nền tảng phổ
biến cung cấp MQTT Broker cho những ứng dụng IOT.
58
Hivemq hỗ trợ đầy đủ các kết nối bằng giao thức MQTT, MQTT với SSL, WS,
WSS (Websocket với SSL).
Khi sử dụng dịch vụ MQTT Broker của bên thứ 3, có thể thấy được ưu và nhược
điểm như sau:
Ưu điểm:
Có các gói miễn phí (phù hợp với giai đoạn đầu của dự án)
Tốc độ ổn định
Hỗ trợ đầy đủ các giao thức cần thiết, đặc biệt là SSL với khả năng tăng bảo mật
đường truyền.
Nhược điểm (có thể chấp nhận nhược những nhược điểm này ở giai đoạn đầu
của dự án):
Broker được cung cấp là một Broker công khai, không có khả năng xác thực
người dùng khi kết nối.
Đôi khi xảy ra tình trạng bị mất kết nối tới Broker (không đáng kể)
5.1.5 AI Server (Server xử lý hình ảnh)
AI Server là một server riêng biệt được triển khai để xử lý hình ảnh nhận từ các
thiết bị ESP32-CAM. Nhiệm vụ của AI Server bao gồm:

Nhận hình ảnh gửi từ ESP32 qua HTTP POST.

Xử lý tiền xử lý ảnh: cắt khuôn mặt, resize, chuẩn hóa.

Trích xuất đặc trưng
khuôn mặt
bằng
mô hình
(TensorFlow/Keras).

Sinh embedding vectors (vector đặc trưng khuôn mặt).

Lưu trữ embedding vào Firestore hoặc Database nội bộ.

So sánh embedding để nhận diện user hoặc phát hiện người lạ.
Công nghệ sử dụng tại AI Server:

Python (Flask)
59
FaceNet

TensorFlow / Keras (Model FaceNet)

OpenCV
AI Server chỉ chịu trách nhiệm chuyên biệt cho bài toán Deep Learning, tách
biệt hoàn toàn với server quản lý dữ liệu người dùng để tối ưu hiệu suất và bảo trì
hệ thống.
5.2
Triển khai phân hệ
Phân hệ Server – Backend cần liên kết với dự án Firebase của hệ thống để sử dụng
các dịch vụ cần thiết. BEApp sẽ đóng vai trò là quản trị viên của dự án Firebase, các
cấu hình Service Firebase Admin
Xây dựng kiến trúc BE:
5.2.1 Thiết kế luồng hoạt động của backend 1
1. Luồng tổng quan của BE
Hình 5.2 Luồng hoạt động tổng quan của BE
Mô tả:
Khởi tạo các kết nối và thành phần cần thiết: Firestore database, MQTT broker,
http server, socket io
Kiểm tra kết quả khởi tạo:
60
 Nếu thành công tiến hành nhận và trả dữ liệu
 Nếu thất bại ứng dụng sẽ kết thúc ngay để tránh vận hành trong trạng thái
không ổn định.
Sau khi khởi tạo thành công, backend hoạt động với hai nhiệm vụ chính song
song:

Nhận và xử lý API request từ client (Mobile App):
o
Nhận các yêu cầu như: đăng ký tài khoản, đăng nhập, cập nhật thiết
bị, lấy trạng thái thiết bị, nhận danh sách thông báo...
o
Giao tiếp với Firestore Database để đọc, ghi, chỉnh sửa dữ liệu theo
yêu cầu.
Hình 5.3 Đọc danh sách thiết bị từ firestore

Nhận và xử lý message từ MQTT Broker:
o
Lắng nghe các bản tin MQTT được gửi từ thiết bị ESP32.
o
Phân tích dữ liệu nhận được:

Nếu là dữ liệu sensor → lưu Firestore, cập nhật trạng thái thiết bị.

Nếu là cảnh báo → tạo thông báo và push tới Mobile App qua
FCM.

Nếu là trạng thái → cập nhật realtime qua WebSocket cho Mobile
App.
61
2. Luồng BE nhận các request API từ client
Hình 5.4 Luồng BE nhận các request api từ client
Mô tả:
Nhận request API từ các client
Xác thực client (người dùng) bằng middleware:
 Middleware sẽ kiểm tra xem client gửi request có hợp lệ không (kiểm tra
token, session, quyền truy cập...).
 Nếu không hợp lệ, hệ thống trả lỗi về cho client ngay lập tức (ví dụ: 401
Unauthorized).
Xác thực người dùng thành công:
 Nếu middleware xác nhận client hợp lệ, luồng tiếp tục.
Thực hiện các lệnh ứng với đầu API:
62
 Dựa trên yêu cầu cụ thể (ví dụ: bật đèn, mở khóa cửa, lấy thông tin cảm
biến...), hệ thống sẽ gọi các lệnh tương ứng.
Đọc/Cập nhật dữ liệu từ/đến database nếu cần thiết:
Nếu API yêu cầu liên quan đến dữ liệu (ví dụ: lấy lịch sử bật tắt đèn, lưu trạng
thái thiết bị...), hệ thống sẽ truy vấn hoặc cập nhật vào cơ sở dữ liệu (database).
Trả về kết quả cho client:
Sau khi hoàn thành xử lý, hệ thống gửi phản hồi (response) trở lại client: bao
gồm dữ liệu hoặc thông báo thành công/thất bại.
3. Luồng BE nhận các bản tin từ MQTT Broker
Hình 5.5 Luồng Backend Application khi nhận message từ MQTT Broker
Nhận dữ liệu: Hệ thống nhận message từ MQTT Broker, chứa thông tin cập
nhật từ các thiết bị IoT.
Cập nhật database: Thông tin mới của thiết bị được ghi vào cơ sở dữ liệu.
Xử lý dữ liệu sensor: Tiếp tục nhận dữ liệu từ các cảm biến (sensor) về các chỉ
số giám sát.
63
Kiểm tra ngưỡng cảnh báo:
 Nếu chỉ số đạt ngưỡng cảnh báo, chuyển bước tiếp theo.
 Nếu chưa đạt, tiếp tục lắng nghe sensor để cập nhật liên tục.
Gửi thông báo và kích hoạt tính năng an toàn: Khi phát hiện bất thường, hệ thống
sẽ:
 Gửi thông báo về điện thoại người dùng.
 Kích hoạt các tính năng an toàn như báo động, khóa cửa, cắt điện thiết bị,
v.v.
5.2.2 Thiết kế luồng hoạt động của backend 2(AI Server)
AI Server là một server riêng biệt được triển khai để xử lí hình ảnh nhận được từ
các thiết bị như esp32-cam
1. Sơ đồ luồng tổng quan
Hình 5.6 sơ đồ tổng quan firmware server ai
64
Sau khi nhận được ảnh từ esp32 cam thông qua giao thức http, hệ thống tiến hành
thực hiện các bước sau:
1. Nhận diện khuôn mặt
Ảnh được tải lên server và tạm thời lưu thông tin qua middleware multer
Đường dẫn file ảnh sẽ được lấy và chuyển làm tham số cho script Python
detect_image.py
Server gọi PythonShell để thực thi detect_image.py. Script này sẽ thực hiện
các chức năng:
 Tiền xử lý ảnh
 Trích xuất embedding
 So sánh embedding với dữ liệu embedding có sẵn
Dựa trên kết quả phân loại, server sẽ trả về custom token firebase hoặc
unknown face
Hình 5.7 Phản hồi từ server
Nếu trong quá trình chạy script xảy ra lỗi, server sẽ trả về mã lỗi 500 kèm
thông báo chi tiết
2. Lưu ảnh mới để phục vụ huấn luyện
Khi hệ thống hoặc người dùng muốn thêm khuôn mặt mới vào bộ dữ liệu,
ảnh sẽ được gửi qua API /get-image-face-train
Ảnh sẽ được lưu vào thư mục check_face dùng để huấn luyện lại mô hình
Sau khi lưu thành công server sẽ phản hồi {messgae: “success”}
65
Hình 5.8 thư mục chứa ảnh để phục vụ retrain
3. Huấn luyện lại mô hình nhận diện
Khi bộ dữ liệu đã có ảnh mới, server hỗ trợ huấn luyện lại mô hình facenet:
Bước 1: Khi nhận yêu cầu POST tới /train, server sử dụng PythonShell để
gọi script re_train.py.
Bước 2: Script Python thực hiện:
 Đọc toàn bộ dữ liệu hình ảnh mới.
 Trích xuất embedding đặc trưng từ ảnh mới.
 Huấn luyện (fine-tune) lại mô hình nhận diện.
 Cập nhật cơ sở dữ liệu embedding.
Bước 3: Sau khi train hoàn tất:
 Trả về kết quả thành công.
 Nếu lỗi huấn luyện (ví dụ thiếu ảnh, format sai...), server sẽ trả về lỗi 500.
5.2.3 Cấu hình database
66
Thiết kế cấu trúc dữ liệu: Dịch vụ Firestore database là một NoSQL database (sử
dụng cơ sở dữ liệu NoSQL), nó lưu trữ dữ liệu dưới dạng tài liệu (document) được
tổ chức thành các bộ sưu tập (collections).
Firestore database cũng hỗ trợ các truy vấn để thực hiện các hoạt động đọc và
ghi dữ liệu vào các collections. Có thể truy vấn các tài liệu trong collection để lấy
thông tin, thêm mới, cập nhật hoặc xóa chúng.
Một collection trong Firestore database tương tự như một bảng trong cơ sở dữ
liệu quan hệ truyền thống. Nó là một nhóm các documents có cấu trúc tương tự nhau
hoặc liên quan chặt chẽ với nhau. Mỗi collection có thể chứa nhiều documents và
chúng được lưu trữ dưới dạng các cặp khóa-giá trị (key- value). Mỗi document trong
một collection sẽ có một ID duy nhất để phân biệt nó với các document khác trong
cùng collection.
Collection “users” là tập hợp document chứa thông tin của người dùng như:




Tên của người dùng(name)
Email
Số điện thoại
Id user
Hình 5.9 cấu trúc collections user
Collection “devices” là tập hợp document chứa thông tin của Device, là
collection con của room như:




ID (id)
Tên của Device (name)
Trạng thái (status)
ID của phòng liên kết với Device (roomId) Collection
67
Hình 5.10 Cấu trúc collection devices
Collection “rooms” là tập hợp các document chứa thông tin thông báo như:




ID
Tên phòng
Số thiết bị
Icon để hiển thị ở client
Hình 5.11 Cấu trúc collection rooms
5.2.4 Các công nghệ/ thư viện được sử dụng để thiết kế BE App
BE App được triển khai bằng NodeJS, kết hợp với một số thư viện hỗ trợ được
liệt kê dưới đây:
Express: là một khung làm việc phổ biến trên nên tảng nodeJS, cung cấp một số
tính năng như:
 Xử lý các HTTP request (POST, GET, PUT, DELETE) gửi đến ứng dụng
thông qua đường dẫn url
68
Hình 5.12 Một số route được cấu hình trong dự án
 Chèn, sửa các mẫu html. Js để cung cấp cho trang web
 Tạo, xử lý các phần mềm trung gian(middleware), được ứng dụng trong kiểm
tra chuẩn của dữ liệu, xác thực và phân quyền người dùng trong ứng dụng
Firebase admin: Thư viện của firebase hỗ trợ, cung cấp đầy đủ tính năng để ứng
dụng nodejs thực hiện các chức năng có trên dự án firebase. Trong hệ thống này,
ứng dụng nodejs sử dụng tính năng User management để quản lý người dùng xác từ
mobile app
Hình 5.13 Các tính năng firebase-admin cung cấp cho nodejs so với các nền tảng
khác
69
Mqtt: thư viện này giúp BEApp kết nối với MQTT Broker, subscribe, publish
dữ liệu từ/tới các topic, giúp giao tiếp một cách gián tiếp với thiết bị để đảm bảo
truyền nhận.
FaceNet: hỗ trợ việc train model nhận diện khuôn mặt, chi tiết sẽ được đề cập
trong phần sau
70
CHƯƠNG 6. THIẾT KẾ VÀ TRIỂN KHAI FACENET
6.1
Giới thiệu
6.1.1 Facenet và đặc trưng ánh xạ không gian
Facenet là một mô hình học sâu (Deeplearning) được phát triển bởi google vào
năm 2015. Điểm nổi bật của FaceNet là nó không chỉ đơn giản là nhận diện khuôn
mặt mà còn ánh xạ mỗi khuôn mặt vào một không gian đặc trưng (embedding space)
sao cho khoảng cách Euclidean giữa hai vector đặc trưng đại diện cho hai khuôn
mặt tương tự nhau sẽ nhỏ, trong khi khoảng cách giữa hai vector đại diện cho hai
khuôn mặt khác nhau sẽ lớn
6.1.2 Mạng no-ron tích chập và triplet loss trong facenet
Facenet sử dụng mạng nơ-ron tích chập (Convolutional Neural Network – CNN)
để học các đặc trưng của khuôn mặt. Sau khi qua mạng, mỗi khuôn mặt sẽ được
ánh xạ thành một vector có độ dài cố định, thường là 128 chiều, gọi là face
embedding. Vector này có thể được sử dụng cho các nhiệm vụ như xác thực khuôn
mặt, tìm kiếm khuôn mặt, và nhóm khuôn mặt.
Một trong những đặc điểm chính của facenet là khả năng tạo ra các vector đặc
trưng có tính phân biệt cao. Điều này đạt được nhờ việc sử dụng hàm mất mát đặc
biệt gọi là triplet loss, cùng với một kỹ thuật huấn luyện tinh vi
6.2
Cấu trúc mạng FaceNet
Hình 6.1 Mô hình facenet
71
Mô hình FaceNet có một cấu trúc phức tạp với nhiều thành phần khác nhau, mỗi
phần đóng một vai trò quan trọng trong việc trích xuất và ánh xạ đặc trưng khuôn
mặt. Cấu trúc chính của FaceNet bao gồm các phần sau:
6.2.1 Mạng nơ ron tích chập (CNN) để trích xuất đặc trưng
Phần đầu tiên của FaceNet là một mạng nơ-ron tích chập (CNN) được thiết kế
để trích xuất các đặc trưng từ hình ảnh khuôn mặt. Mạng này bao gồm nhiều lớp
tích chập (convolutional layers) và lớp gộp (pooling layers) để học các đặc trưng
hình học và phong cách của khuôn mặt.
Cấu trúc điển hình của mạng CNN trong FaceNet có thể bao gồm:
 Lớp tích chập (Convolutional Layer): Các lớp này giúp phát hiện các đặc
trưng cơ bản của hình ảnh, như cạnh và kết cấu. Ví dụ, lớp tích chập đầu tiên
có thể có 64 kênh đầu ra với kích thước kernel là 7×7.
 Lớp Gộp (Pooling Layer): Các lớp này giảm kích thước không gian của hình
ảnh đầu vào, giúp giảm số lượng tham số và tính toán, đồng thời giữ lại các
đặc trưng quan trọng. Lớp gộp thường sử dụng phương pháp gộp tối đa (max
pooling) với kích thước kernel là 3×3.
 Lớp Batch Normalization: Lớp này giúp chuẩn hóa đầu ra của các lớp tích
chập, giảm thiểu sự thay đổi phân phối trong quá trình huấn luyện.
 Lớp kích hoạt (Activation Layer): Lớp ReLU (Rectified Linear Unit) thường
được sử dụng để thêm tính phi tuyến vào mô hình, giúp mô hình học các đặc
trưng phức tạp hơn.
Ví dụ về cấu trúc mạng CNN có thể như sau:
Input Imgae -> Conv1(64 filters, 7x7) -> ReLU -> MaxPool (3x3) -> Conv2(128
filters,3x3) -> ReLU ->MaxPool(3x3)
Trong đó:
72
 Conv1: Convolution layer đầu tiên, áp dụng 64 bộ lọc, mỗi filter có kích
thước 7x7 pixel. Sau Conv1, ảnh sẽ được chuyển đổi thành base64 bản đồ
đặc trưng
 ReLU (Rectified Linear Unit): Là hàm kích hoạt phi tuyến tính, có tác dụng
loại bỏ các giá trị âm, chỉ giữ lại các giá trị dương.
 Giúp mạng học nhanh hơn, giảm vấn đề gradient biến mất
 MaxPooling (3x3): Là lớp giảm kích thước, chia ảnh ra thành các ô 3x3, chọn
giá trị lớn nhất trong mỗi ô, mục tiêu để giảm số lượng tham số và tính toán,
chỉ giữ lại thông tin quan trọng nhất đồng thời tăng tính dịch chuyển bất biến
 Conv2 (128 filters, 3x3): Convolution layer thứ 2, áp dụng 128 filter, mỗi
filter kích thước 3x3 nhỏ hơn, 128 feature maps sẽ học các đặc trưng phức
tạp hơn (đường cong, kết cấu)
6.2.2 Lớp Fully Connected (FC) để ánh xạ đặc trưng
Sau khi các đặc trưng được trích xuất bởi các lớp CNN, chúng được đưa qua các
lớp fully connected (FC) để ánh xạ các đặc trưng này thành vector embedding có
độ dài cố định. Các lớp FC thường được thiết kế để giảm dần số lượng kích thước
đặc trưng từ các lớp tích chập xuống một kích thước nhỏ hơn, thường là 128 hoặc
512 chiều cho vector embedding.
Cấu trúc của các lớp FC có thể như sau:
Flatten→FC1 (1024 units)→ReLU→FC2 (Embedding Dim)
Trong đó, Embedding Dim là kích thước của vector đặc trưng, thường là 128.
6.2.3 Hàm mất mát Triplet Loss
Triplet Loss là một trong những hàm mất mát quan trọng nhất trong mô hình
FaceNet. Mục tiêu của Triplet Loss là đảm bảo rằng khoảng cách giữa vector đặc
trưng của một khuôn mặt (gọi là Anchor) và một khuôn mặt khác của cùng một
73
người (gọi là Positive) phải nhỏ hơn khoảng cách giữa vector đặc trưng của khuôn
mặt đó và khuôn mặt của một người khác (gọi là Negative).
Định nghĩa:
𝑁
ℒ=∑
[‖𝑓(𝑥𝑖𝐴 )– 𝑓(𝑥𝑖𝑃 )‖22 – ‖𝑓(𝑥𝑖𝐴 )– 𝑓(𝑥𝑖𝑁 )‖22 + 𝛼]+
𝑖=1
Trong đó:

𝑥𝑖𝐴 : Hình ảnh Anchor (mỏ neo)

𝑥𝑖𝑃 : Hình ảnh Positive (tích cực, cùng một người với Anchor)

𝑥𝑖𝑁 : Hình ảnh Negative (tiêu cực, người khác với Anchor)

f(x): Hàm ánh xạ hình ảnh x thành vector đặc trưng (embedding)

𝛼: Một siêu tham số gọi là margin, giúp kiểm soát khoảng cách tối thiểu giữa
Positive và Negative
Hàm mất mát này yêu cầu rằng khoảng cách giữa Anchor và Positive nhỏ hơn
khoảng cách giữa Anchor và Negative ít nhất là một lượng bằng α. Điều này giúp
mô hình học cách phân biệt rõ ràng giữa các khuôn mặt khác nhau.
Hoạt động:
Hàm Triplet Loss dựa trên việc điều chỉnh ba hình ảnh: Anchor (A), Positive (P),
và Negative (N). Mục tiêu của mô hình là học sao cho:
‖𝑓(𝑥𝑖𝐴 )– 𝑓(𝑥𝑖𝑃 )‖22 + 𝛼 < ‖𝑓(𝑥𝑖𝐴 )– 𝑓(𝑥𝑖𝑁 )‖22
74
Trong đó, ‖. ‖22 là khoảng cách Euclidean giữa các vector đặc trưng. Điều này có
nghĩa là khoảng cách giữa Anchor và Positive sẽ được thu nhỏ, trong khi khoảng
cách giữa Anchor và Negative sẽ được mở rộng.
Ví dụ, nếu 𝑓(𝑥𝑖𝐴 ) là vector đặc trưng cho một khuôn mặt, 𝑓(𝑥𝑖𝑃 ) là vector đặc
trưng cho cùng một khuôn mặt nhưng với biểu cảm khác, và 𝑓(𝑥𝑖𝑁 ) là vector đặc
trưng cho một khuôn mặt khác, thì hàm Triplet Loss sẽ cố gắng đảm bảo rằng:
‖𝑓(𝑥𝑖𝐴 )– 𝑓(𝑥𝑖𝑃 )‖22 + 𝛼 < ‖𝑓(𝑥𝑖𝐴 )– 𝑓(𝑥𝑖𝑁 )‖22
Nếu điều kiện này không được thoả mãn, mô hình sẽ điều chỉnh các trọng số để
giảm giá trị mất mát, làm cho các vector đặc trưng di chuyển gần hoặc xa nhau tùy
theo yêu cầu.
6.2.4 Kỹ thuật tăng cường (Data Augmentation)
Để cải thiện khả năng tổng quát của mô hình và giảm hiện tượng overfitting, các
kỹ thuật tăng cường dữ liệu thường được sử dụng. Các kỹ thuật này có thể bao gồm:
Chuyển đổi màu sắc: Thay đổi độ sáng, độ tương phản, và bão hòa của hình
ảnh.
Biến dạng hình học: Xoay, cắt, và thay đổi kích thước của hình ảnh.
Làm mờ và nhiễu: Thêm nhiễu hoặc làm mờ hình ảnh để làm cho mô hình mạnh
mẽ hơn với các điều kiện không giống như trong dữ liệu huấn luyện.
Việc áp dụng các kỹ thuật tăng cường giúp mô hình FaceNet có khả năng xử lý
các biến thể trong điều kiện thực tế và cải thiện hiệu suất nhận diện khuôn mặt.
75
Hình 6.2 Thực hiện tăng cường dữ liệu
Trong đó:
 Transform.Resize: Thay đổi kích thước hình ảnh để có ảnh đồng nhất
 transforms.ToTensor: Chuyển đổi hình ảnh thành tensor, điều này là cần
thiết cho việc đưa dữ liệu vào mô hình học máy trong PyTorch.
 Transforms.Normalize: chuẩn hóa pixel về [-1,1]
6.3
Triển khai và ứng dụng
AI server bao gồm 3 thành phần chương trình chính:
Detect: dùng để nhận diện khuôn mặt
Retrain: Dùng để cập nhật (retrain) embedding khi thêm người mới
Trainmodel: Dùng để huấn luyện lại toàn bộ embeddings từ đầu
6.3.1 Detected image
Có nhiệm vụ phân tích một bức ảnh nhận vào và xác định người trong ảnh
76
Hình 6.3 Triển khai detected image
Đầu tiên server nhận đường dẫn từ ESP32 gửi tới, tiến hành các bước tiền xử lí
Sử dụng mô hình facenet để trích xuất embedding đặc trưng
So sánh embedding với tập embeddings đa lưu bằng cosnie similarity, nếu độ
tương đồng cao hơn 0.7 -> xác nhận người dùng, nếu không trả về unknown
Hình 6.4 Response trả về với độ tương đồng nhỏ hơn 0.7
77
Hình 6.5 Response trả về với độ tương đồng lớn hơn 0.7
6.3.2 Retrain
Mục đích: Khi có người mới tham gia hệ thống, cho phép cập nhật nhanh dữ liệu
Hình 6.5 Retrain data
Quy trình thực hiện:
Đầu tiên, duyệt qua các thư mục data set chứa ảnh khuôn mặt, loại bỏ các thư
mục có ít hơn 10 ảnh để đảm bảo chất lượng dữ liệu
Sử dụng MTCNN để tự động phát hiện và crop khuôn mặt trong ảnh
78
Trích xuất embedding mới bằng môi hình facenet
Gộp embedding mới vào file face_embeddings.pth
Cuối cùng, cập nhật danh sách các thư mục đã được train
6.3.3 TrainModel
Mục đích: Xây dựng lại toàn bộ tập embeddings khi cần
Hình 6.6 Train model
Quy trình:
Đọc toàn bộ dữ liệu từ dataset, resize ảnh thành batch
Trích xuất embedding cho tất cả các ảnh
Gộp và lưu embeddings vào file face_embeddings.pth
79
CHƯƠNG 7: KẾT LUẬN
Chương cuối được dùng để mô tả kết quả đạt được trong quá trình kết nối và
điều khiển thiết bị, tập trung vào hiệu quả và các bài học kinh nghiệm
Chương này cũng đề cập đến các lỗi thường gặp trong quá trình thực hiện chương
trình. Các lỗi này được chúng em đưa ra hướng giải quyết giúp dảm bảo sự ổn định giữa
các kết nối và trơn tru trong việc điều khiển
7.1 Kết quả đạt được
Sau quá trình xây dựng, triển khai và thử nghiệm hệ thống, chúng em đã đạt được
những kết quả cụ thể như sau:
Thiết bị điều khiển ổn định:
 Các thiết bị kết nối với hệ thống thông qua giao thức MQTT hoạt động chính
xác và có độ trễ thấp.
 Lệnh bật/tắt thiết bị, cập nhật trạng thái cảm biến được phản hồi gần như
theo thời gian thực trên ứng dụng Mobile.
 Các chế độ cảnh báo hoạt động chính xác, ít bị nhiễu và các tập dữ liệu nhận
được có độ chính xác cao
Nhận diện khuôn mặt thành công:
 Server AI thực hiện nhận diện khuôn mặt từ ảnh gửi lên với độ chính xác
tương đối
 Thời gian trung bình cho mỗi lượt nhận diện giao động từ 1-3 giây tùy thuộc
vào kích thước của ảnh và mạng
80
Với việc chia ra thành nhiều server sử lí từng chức năng riêng biệt giúp giảm
tải cho hệ thống, dễ bảo trì, tăng tốc xử lí, không bị gián đoạn trong khi đang
thực hiện các công việc khác
7.2 Các lỗi thường gặp và hướng giải quyết
 Lỗi kết nối wifi thất bại ở esp32
Nguyên nhân: có thể sai ssid,password hoặc tín hiệu yếu
Khắc phục: Kiểm tra cấu hình wifi
 Lỗi kết nối tới mqtt:lỗi DNS Failed for
34dbcea1a454478b81305ce4a75b8a43.s1.eu.hivemq.cloud failed, rc=-2
Nguyên nhân:
o Không có kết nối internet
o Kết nối interet không có ssl
o Cấu hình dns không đúng
o Broker domain sai hoặc bị chặn
Hướng xử lí:
o Kiểm tra lại DNS
o Đảm bảo cấu hình HiveMQ đúng
 Lỗi server backend crash khi thiếu file .pth
Nguyên nhân: chưa kiểm tra sự tồn tại của model trước khi load
Khắc phục: Bổ sung try-except và gửi cảnh báo trước
7.3 Bài học kinh nghiệm
Tầm quan trọng của quản lý kết nối:
Việc duy trì kết nối ổn định giữa các phân hệ (ESP32, MQTT Broker, Backend,
Mobile App) đóng vai trò then chốt trong đảm bảo tính liên tục của hệ thống.
81
Cần chuẩn hóa dữ liệu đầu vào:
Ảnh đầu vào cần được kiểm soát tốt về chất lượng (độ sáng, kích thước) để cải
thiện độ chính xác khi nhận diện khuôn mặt.
Xây dựng kiến trúc hệ thống có khả năng tự phục hồi:
Các thành phần như ESP32 cần có khả năng tự động reconnect WiFi, MQTT khi
gặp lỗi.
Backend cần có các cơ chế kiểm tra, ghi log lỗi rõ ràng để dễ dàng xử lý.
Thường xuyên kiểm thử các tình huống lỗi:
Việc chủ động tạo ra các tình huống lỗi giả lập giúp phát hiện và xử lý vấn đề
sớm, giảm thiểu sự cố khi vận hành thực tế.
7.4 Hướng nghiên cứu tiếp theo
7.4.1 Nâng cao độ chính xác và tối ưu nhận diện khuôn mặt:
Bổ sung nhiều dữ liệu hơn cho mỗi người dùng để tăng khả năng nhận diện trong
các điều kiện ánh sáng, góc chụp khác nhau.
Fine-tune lại mô hình FaceNet trên tập dữ liệu riêng của hệ thống để tối ưu hóa
cho các khuôn mặt thực tế tại môi trường sử dụng.
7.4.2 Nâng cấp giao tiếp giữa các thiết bị
Chuyển MQTT Broker về server riêng có bảo mật SSL/TLS thay vì sử dụng
broker công khai, nhằm tăng độ an toàn truyền thông.
Triển khai mô hình cluster MQTT (nhiều broker) để đảm bảo độ tin cậy cao khi
có nhiều thiết bị cùng kết nối.
82
Nâng cấp lên MQTT 5.0, tận dụng các tính năng mới như session expiry, user
property,...
7.4.3 Cải tiến mobile app
Thêm chức năng quản lý quyền người dùng: phân quyền cho từng thành viên
trong gia đình (ví dụ: quản lý, khách...).
Tối ưu giao diện (UI/UX) để dễ sử dụng hơn, phản hồi nhanh hơn trên nhiều
thiết bị di động.
83
Trích dẫn
[1] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash,
“Internet of things: a survey on enabling technologies, protocols, and applications,”
IEEE communi cations surveys & tutorials, vol. 17, no. 4, pp. 2347–2376, 2015.
[2] A. Sharma, P. K. Singh, and Y. Kumar, “An integrated fire detection system
using IoT and image processing technique for smart cities,” Sustainable Cities and
Society, vol. 61, Article ID 102332, 2020.
[3] F. Hussain, R. Hussain, S. A. Hassan, and E. Hossain, “Machine Learning in
IoT Security: Current Solutions and Future Challenges,” IEEE Communications
Surveys & Tu torials, vol. 22, 2020.
[4] F. Hussain, Internet of 1ings: Building Blocks and Business Models,
Springer, New York, NY, USA, 2017
[5] E. Bertino and N. Islam, “Botnets and internet of things security,” Computer,
vol. 50, no. 2, pp. 76–79, 2017.
[6] S. Raza, L. Wallgren, and T. Voigt, “SVELTE: real-time intrusion detection
in the internet of things,” Ad Hoc Net works, vol. 11, no. 8, pp. 2661–2674, 2013.
[7] S. Bharati, M. R. H. Mondal, P. Podder, and V. B. Prasath, “Federated
learning: applications, challenges and future directions,” International Journal of
Hybrid Intelligent Sys tems, vol. 18, pp. 1–17, 2022.
[8] S. Ray, Y. Jin, and A. Raychowdhury, “)e changing com puting paradigm
with internet of things: a tutorial intro duction,” IEEE Design & Test, vol. 33, no. 2, pp.
76–96, 2016
84
PHỤ LỤC
Phụ lục 1
Hệ thống IoT (Internet of Things) là một mạng lưới kết nối các đối tượng vật
lý, thiết bị thông minh và cảm biến thông qua internet, cho phép chúng tương tác
và trao đổi dữ liệu với nhau. Một hệ thống IoT thường bao gồm các lớp sau:
- Perception Layer: lớp đầu tiên trong hệ thống IoT. Nó bao gồm các cảm
biến và thiết bị đo lường để thu thập dữ liệu từ môi trường vật lý. Các cảm
biến có thể đo nhiệt độ, độ ẩm, ánh sáng, chuyển động, định vị GPS, cảm
biến khí, cảm biến hình ảnh và nhiều loại cảm biến khác. Nhiệm vụ của lớp
này là thu thập dữ liệu và chuyển tiếp nó đến lớp tiếp theo.
- Network Layer: lớp trung gian xử lý và truyền dữ liệu giữa Perception và
các lớp tiếp theo. Lớp này xử lý việc chuyển tiếp, mã hóa và giải mã dữ liệu
thu thập từ lớp Perception. Nó đảm bảo rằng dữ liệu được truyền đi một
cách an toàn và hiệu quả. Lớp Network sử dụng các giao thức mạng như
Wi-Fi, Bluetooth, Zigbee, LoRaWAN và các giao thức mạng khác để kết
nối các thiết bị IoT với nhau và với internet.
- Processing Layer: đóng vai trò nhận dữ liệu từ lớp Network và tiến hành xử
lý, phân tích và lọc dữ liệu. Lớp này có thể áp dụng các thuật toán học máy,
trí tuệ nhân tạo và xử lý dữ liệu để tạo ra thông tin hữu ích từ dữ liệu thu
thập được. Nhiệm vụ của lớp Processing là biến dữ liệu thành thông tin có
ý nghĩa và cung cấp dữ liệu đã được xử lý cho lớp Application.
- Application Layer: nhận dữ liệu đã được xử lý từ lớp Processing Layer và
cung cấp các dịch vụ, ứng dụng và giao diện người dùng. Lớp này cho phép
người dùng tương tác với hệ thống IoT, quản lý và điều khiển các thiết bị
85
IoT, và tận dụng các thông tin hữu ích từ dữ liệu thu thập được. Các ứng
dụng IoT.
Phụ lục 2. Kiểu dữ liệu JSON
JSON (JavaScript Object Notation) [10] là một định dạng dữ liệu dựa trên
văn bản được sử dụng để trao đổi dữ liệu giữa các ứng dụng. Mặc dù tên gợi nhớ
đến JavaScript, JSON thực chất là độc lập với ngôn ngữ này, nó có thể được sử
dụng bởi nhiều ngôn ngữ lập trình khác nhau.
JSON thường được sử dụng để biểu diễn dữ liệu có cấu trúc dưới dạng các
cặp key-value (khóa-giá trị). Dữ liệu trong JSON có thể là số, chuỗi, đối tượng
(object), mảng (array), giá trị logic (true, false), hoặc giá trị null.
JSON đã trở thành một định dạng phổ biến trong việc truyền tải dữ liệu giữa
các ứng dụng web và thường được sử dụng trong API để giao tiếp giữa máy chủ
và máy khách.
86
Ví dụ:
{
"name": "John Doe",
"age": 30,
"is_student": true
}
Phụ lục 3. Tiêu chuẩn JWT
Tiêu chuẩn JWT (JSON Web Token) [17] là một phương tiện định dạng và trao
đổi thông tin an toàn dựa trên định dạng JSON giữa các bên. JWT là một chuỗi được
mã hóa chứa thông tin về người dùng hoặc thông tin xác thực, được sử dụng trong việc
xác thực và phân quyền trong các ứng dụng web và dịch vụ web.
JWT được định nghĩa trong các tài liệu tiêu chuẩn của IETF (Internet
Engineering Task Force) với mục đích cụ thể là RFC 7519. Nó là một tiêu chuẩn mở,
linh hoạt và bảo mật, cho phép các bên trao đổi thông tin an toàn theo cơ chế phát hành
token.
JWT bao gồm ba phần chính, mỗi phần cách nhau bởi dấu chấm (.):
- Header: Chứa các thông tin mô tả về loại token và thuật toán mã hóa được
sử dụng. Header thường chứa hai thuộc tính quan trọng là "typ" (kiểu) và
"alg" (algorithm).
- Payload: Chứa các thông tin cần thiết và có thể truyền tải, chẳng hạn như
thông tin người dùng, quyền hạn, thông tin liên quan đến phiên làm việc và
nhiều thuộc tính khác. Payload không được mã hóa và có thể dễ dàng đọc
được bởi bất kỳ ai.
- Signature: Được tạo bằng cách ký số (được mã hóa) của phần header và
87
payload bằng một khóa bí mật duy nhất chỉ được biết đến bởi server. Nó
được sử dụng để xác minh tính toàn vẹn của token và đảm bảo rằng token
không bị sửa đổi khi được truyền tải.
Khi một ứng dụng xác thực người dùng, nó gửi JWT cho người dùng sau khi họ
đăng nhập thành công. Sau đó, JWT sẽ được gửi kèm với mỗi yêu cầu từ người dùng
đến máy chủ. Máy chủ sẽ xác thực token và kiểm tra tính hợp lệ của nó trước khi cho
phép truy cập vào các tài nguyên hoặc chức năng cần được bảo mật.
Phụ lục 4. Tiêu chuẩn REST và RESTful API
Tiêu chuẩn REST (Representational State Transfer) là một kiến trúc dựa
trên các nguyên tắc thiết kế cho việc xây dựng các ứng dụng phân tán và các dịch
vụ web. Nó được giới thiệu bởi Roy Fielding trong luận văn tiến sĩ vào năm 2000
và đã trở thành một trong những phương pháp phổ biến để thiết kế các API (Application
Programming Interface) trong việc tạo ra các dịch vụ web.
Một số điểm quan trọng của kiến trúc REST bao gồm:
- Cơ sở dữ liệu đại diện (Representational): Mỗi tài nguyên (resource) trong
hệ thống được đại diện bởi một URI (Uniform Resource Identifier), chẳng
hạn như URL (Uniform Resource Locator). Ví dụ, tài nguyên có thể là một
bài viết, người dùng, hoặc sản phẩm.
- Trạng thái (State): Trạng thái của tài nguyên được trả về trong phản hồi khi yêu
cầu xem tài nguyên. Các tài nguyên có thể có nhiều trạng thái khác nhau, và REST đảm
bảo rằng các thao tác CRUD (Create, Read, Update, Delete) có thể được thực hiện dễ
dàng.
- Truyền tải thông tin qua các phương thức HTTP: REST sử dụng các phương
thức HTTP như GET (lấy thông tin), POST (tạo mới tài nguyên), PUT (cập
nhật tài nguyên), DELETE (xóa tài nguyên) để quản lý tài nguyên và thực hiện
các thao tác trên chúng.
88
- Stateless (Không lưu trạng thái): Server không lưu trữ thông tin trạng thái
của client giữa các yêu cầu. Mỗi yêu cầu từ client phải chứa đủ thông tin
cần thiết để xử lý yêu cầu này mà không cần dựa vào thông tin từ yêu cầu
trước đó.
Quy định các cấu trúc dữ liệu đơn giản: REST thường sử dụng các định dạng dữ
liệu như JSON hoặc XML để truyền tải thông tin giữa client và server.
Kiến trúc REST cho phép các ứng dụng có thể hoạt động độc lập và liên kết với
nhau thông qua các API. Điều này giúp giảm sự ràng buộc giữa các thành phần trong
hệ thống, làm cho ứng dụng linh hoạt và dễ dàng mở rộng. Nó cũng là một tiêu chuẩn
rất phổ biến trong việc xây dựng các dịch vụ web và ứng dụng web hiện đại.
RESTful API là một cách triển khai của tiêu chuẩn REST. Nó là một API
(Application Programming Interface) được thiết kế và triển khai theo các nguyên tắc và
tiêu chuẩn của REST. Một API được gọi là RESTful nếu nó tuân thủ các nguyên tắc cơ
bản của REST.
Một API RESTful sử dụng các phương thức HTTP chuẩn như GET, POST, PUT
và DELETE để thực hiện các thao tác CRUD (Create, Read, Update, Delete) trên các
tài nguyên. Các tài nguyên được xác định bằng các URI (Uniform Resource Identifier)
và trạng thái của tài nguyên được truyền tải qua các phản hồi từ server. Các phương
thức HTTP thường được sử dụng trong RESTful API bao gồm:
- GET: Lấy thông tin về một tài nguyên hoặc danh sách tài nguyên.
- POST: Tạo mới một tài nguyên.
- PUT: Cập nhật tài nguyên đã tồn tại.
- DELETE: Xóa một tài nguyên.
Phụ lục 5. Giao thức truyền thông Websocket
WebSoket là công nghệ hỗ trợ giao tiếp hai chiều giữa client và server bằng cách
sử dụng một TCP socket để tạo một kết nối hiệu quả và ít tốn kém. Mặc dù được thiết
89
kế để chuyên sử dụng cho các ứng dụng web, lập trình viên vẫn có thể đưa chúng vào
bất kì loại ứng dụng nào.
WebSockets mới xuất hiện trong HTML5, là một kỹ thuật Reverse Ajax.
WebSockets cho phép các kênh giao tiếp song song hai chiều và hiện đã được
hỗ trợ trong nhiều trình duyệt (Firefox, Google Chrome và Safari). Kết nối được mở
thông qua một HTTP request (yêu cầu HTTP), được gọi là liên kết WebSockets với
những header đặc biệt. Kết nối được duy trì để bạn có thể viết và nhận dữ liệu bằng
JavaScript như khi bạn đang sử dụng một TCP socket đơn thuần.
90