1. Trang chủ
  2. » Luận Văn - Báo Cáo

Thiết kế mô hình hệ thống nhà thông minh điều khiển giám sát thiết bị từ xa bằng giọng nói

100 3 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Thiết kế mô hình hệ thống nhà thông minh điều khiển giám sát thiết bị từ xa bằng giọng nói
Trường học Trường Đại học Công Nghệ Thông Tin - Đại học Quốc Gia Hà Nội
Chuyên ngành Khoa Học Máy Tính và Trí Tuệ Nhân Tạo
Thể loại Đồ án tốt nghiệp
Thành phố Hà Nội
Định dạng
Số trang 100
Dung lượng 2,71 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Cấu trúc

  • CHƯƠNG 1. TỔNG QUAN (10)
    • 1.1. Tổng quan chung về lãnh vực nghiên cứu, Kết quả nghiên cứu trong và ngoài nước (10)
    • 1.2. Mục tiêu đề tài (12)
    • 1.3. Nhiệm vụ và giới hạn của đề tài (12)
  • CHƯƠNG 2. CƠ SỞ LÝ THUYẾT (14)
    • 2.1. Tổng quan về giao thức MQTT (Message Queuing Telemetry Transport) (14)
      • 2.1.1. Giới thiệu về MQTT (14)
      • 2.1.2. Đặc điểm của MQTT (16)
      • 2.1.3. Nguồn gốc và tương lai của MQTT (16)
      • 2.1.4. Mô hình MQTT (18)
      • 2.1.5. Định dạng tin nhắn MQTT (19)
      • 2.1.6. Các khái niệm đáng chú ý trong MQTT (22)
      • 2.1.7. Quy trình truyền nhận dữ liệu chính trong MQTT (25)
      • 2.1.8. Kết luận (29)
    • 2.2. Module wifi ESP32 (30)
      • 2.2.1. Giới thiệu module (30)
      • 2.2.3. Cảm biến nhiệt độ trên ESP32 (32)
      • 2.2.4. Cảm biến điện dung trên ESP32 (32)
      • 2.2.5. Trình biên dịch Arduino IDE cho ESP32 (32)
      • 2.2.6. MQTT-Client trên ESP32 (37)
        • 2.2.6.1. Cài đặt thư viện PubSubClient (37)
        • 2.2.6.2. Sử dụng các hàm API của thư viện PubSubClient (38)
      • 2.2.7. Kết luận (39)
    • 2.3. Nhận dạng giọng nói trong Universal Windows Platform (UWP) (39)
      • 2.3.1.1. Giới thiệu chung (39)
      • 2.3.1.2. Vòng đời ứng dụng UWP (40)
      • 2.3.2. Nhận dạng giọng nói trong UWP (41)
        • 2.3.2.1. Công nghệ nhận giạng giọng nói (41)
        • 2.3.2.2. Sử dụng Speech Recognition trong UWP (41)
      • 2.3.3. UWP và trợ lý ảo Cortana (43)
      • 2.3.4. MQTT-Client trong ứng dụng UWP (45)
      • 2.3.5. Kết luận (47)
  • CHƯƠNG 3: XÂY DỰNG MÔ HÌNH HỆ THỐNG NHÀ THÔNG MINH (48)
    • 3.1. Sơ đồ khối tổng quan (48)
      • 3.1.1. Khối truyền thông (48)
      • 3.1.2. Khối nhận dạng giọng nói (50)
      • 3.1.3. Khối smart phone, laptop và module ESP32 (51)
      • 3.1.4. Khối cảm biến (54)
      • 3.1.5. Khối chấp hành (62)
      • 3.1.6. Khối nguồn (63)
    • 3.2. Sơ đồ kết nối (65)
    • 3.3. Giao diện điều khiển (66)
    • 3.4. Kết luận (66)
  • CHƯƠNG 4: ĐÁNH GIÁ KẾT QUẢ, KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN (67)
    • 4.1. Kết luận (67)
      • 4.1.1. Kết quả đạt được (67)
      • 4.1.2. Hạn chế (67)
    • 4.2. Hướng phát triển (67)
  • TÀI LIỆU THAM KHẢO (68)
  • PHỤ LỤC (69)

Nội dung

Ngày nay, với sự phát triển của công nghệ, các hệ thống nhà thông minh còn cho phép kết nối đến các thiết bị như smartphone hay tablet để tăng tính tiện dụng.. Tất cả các hệ thống thiết

Trang 1

LỜI CẢM ƠN

DANH MỤC HÌNH VẼ

DANH MỤC BẢNG BIỂU

DANH MỤC CHỮ VIẾT TẮT

THÔNG TIN KẾT QUẢ NGHIÊN CỨU CỦA ĐỀ TÀI

CHƯƠNG 1 TỔNG QUAN 1

1.1 Tổng quan chung về lãnh vực nghiên cứu, Kết quả nghiên cứu trong và ngoài nước 1

1.2 Mục tiêu đề tài 3

1.3 Nhiệm vụ và giới hạn của đề tài 3

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 5

2.1 Tổng quan về giao thức MQTT (Message Queuing Telemetry Transport) 5

2.1.1 Giới thiệu về MQTT 5

2.1.2 Đặc điểm của MQTT 7

2.1.3 Nguồn gốc và tương lai của MQTT 7

2.1.4 Mô hình MQTT 9

2.1.5 Định dạng tin nhắn MQTT 10

2.1.6 Các khái niệm đáng chú ý trong MQTT 13

2.1.7 Quy trình truyền nhận dữ liệu chính trong MQTT 16

2.1.8 Kết luận 20

2.2 Module wifi ESP32 21

2.2.1 Giới thiệu module 21

2.2.2 Sử dụng các GPIO 22

2.2.3 Cảm biến nhiệt độ trên ESP32 23

2.2.4 Cảm biến điện dung trên ESP32 24

2.2.5 Trình biên dịch Arduino IDE cho ESP32 23

2.2.6 MQTT-Client trên ESP32 28

2.2.6.1 Cài đặt thư viện PubSubClient 28

2.2.6.2 Sử dụng các hàm API của thư viện PubSubClient 29

2.2.7 Kết luận 30

2.3 Nhận dạng giọng nói trong Universal Windows Platform (UWP) 30

Trang 2

2.3.1.1 Giới thiệu chung 30

2.3.1.2 Vòng đời ứng dụng UWP 31

2.3.2 Nhận dạng giọng nói trong UWP 32

2.3.2.1 Công nghệ nhận giạng giọng nói 32

2.3.2.2 Sử dụng Speech Recognition trong UWP 32

2.3.3 UWP và trợ lý ảo Cortana 34

2.3.4 MQTT-Client trong ứng dụng UWP 36

2.3.5 Kết luận 38

CHƯƠNG 3: XÂY DỰNG MÔ HÌNH HỆ THỐNG NHÀ THÔNG MINH 39

3.1 Sơ đồ khối tổng quan 39

3.1.1 Khối truyền thông 39

3.1.2 Khối nhận dạng giọng nói 41

3.1.3 Khối smart phone, laptop và module ESP32 42

3.1.4 Khối cảm biến 45

3.1.5 Khối chấp hành 53

3.1.6 Khối nguồn 54

3.2 Sơ đồ kết nối 56

3.3 Giao diện điều khiển 57

3.4 Kết luận 57

CHƯƠNG 4: ĐÁNH GIÁ KẾT QUẢ, KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 58

4.1 Kết luận 58

4.1.1 Kết quả đạt được 58

4.1.2 Hạn chế 58

4.2 Hướng phát triển 58

TÀI LIỆU THAM KHẢO 59

PHỤ LỤC 59

Trang 3

có thể hoàn thiện được Một lần nữa, em xin chân thành cảm ơn thầy cô Bài báo cáo được thực hiện trong khoảng thời gian gần 3 tuần Bước đầu đi vào thực tế, tìm hiểu về lĩnh vực sáng tạo trong nghiên cứu khoa học, kiến thức của em còn hạn chế và còn nhiều bỡ ngỡ Do vậy, không tránh khỏi những thiếu sót là điều chắc chắn, em rất mong nhận được những ý kiến đóng góp quý báu của quý thầy cô và các bạn học cùng lớp để kiến thức của em trong lĩnh vực này được hoàn thiện hơn

Lời cảm tạ cô Ngô Thị Thu Hương và thầy Nguyễn Văn Bình Sau cùng, em xin kính chúc quý thầy cô trong khoa Điện – Điện Tử và thầy hiệu trưởng thật dồi dào sức khỏe, niềm tin để tiếp tục thực hiện sứ mệnh cao đẹp của mình là truyền đạt kiến thức cho thế hệ mai sau

Trang 4

DANH MỤC HÌNH VẼ

Hình 1.1 Xu hướng phát triển nhà thông minh của thế giới 1

Hình 1.2 Dây chuyền sản xuất thiết bị smarthome của Bkav Ảnh: T.H 2

Hình 2.1 Ví dụ về kết nối trong mạng lưới MQTT 6

Hình 2.2 gửi tín hiệu điều khiển actor node thông qua broker 6

Hình 2.3 Mô hình truyền thông của MQTT 7

Hình 2.4 Quá trình phát triển của MQTT 9

Hình 2.5 Mô hình cơ bản của giao thức MQTT 9

Hình 2.6 Session và subscription được thiết lập với clean session flag = 1 17

Hình 2.7 Session và subscription được thiết lập với clean session flag = 0 18

Hình 2.8 QoS mức 0 18

Hình 2.9 QoS mức 1 19

Hình 2.10 QoS mức 2 20

Hình 2.11 Module ESP32 21

Hình 2.12 Sờ đồ chân Module ESP32 22

Hình 2.13 Nền tảng UWP 30

Hình 2.14 Vòng dời ứng dụng UWP 31

Hình 2.15 Vòng đời ứng dụng UWP phiên bản 1607 32

Hình 2.16 Microphone (DeviceCapability) 33

Hình 2.17 Kết quả giao diện người dung 34

Hình 2.18 Kết quả sau khi nói 34

Hình 3.1 Sơ đồ khối nhà thông minh 39

Hình 3.2 Mô hình giao thức MQTT 39

Hình 3.3 Mosquitto Setup 40

Hình 3.4 Cấu hình mosquitto trên CMD 41

Hình 3.5 Lưu đồ nhận dạng giọng nói 43

Hình 3.6 Lưu đồ điều khiển thiết bị 44

Hình 3.7 Lưu đồ điều khiển giàn phơi đồ 45

Trang 5

Hình 3.9 Cảm biến mưa TRGS-01 45

Hình 3.10 Cảm biến khí gas MQ-2 46

Hình 3.11 Cảm biến chuyển động HC-SR501 48

Hình 3.12.Ví dụ kết nối với Arduino 50

Hình 3.13 Cảm biến nhiệt độ, độ ẩm DHT11 50

Hình 3.14 Sơ đồ chân cảm biến DHT11 51

Hình 3.15 Cách kết nối cảm biến DHT11 52

Hình 3.16.Lưu đồ hệ thống cảnh báo và bảo vệ 53

Hình 3.17 Module relay 5V 2 kênh 54

Hình 3.18 Module mosfet IRF520 54

Hình 3.19 Adapter 12V 2A 55

Hình 3.20 Module giảm áp LM2596 55

Hình 3.21 Sơ đồ kết nối các thiết bị 56

Hình 3.22 Giao diện điều khiển 57

Trang 6

Bảng 2.1 Header cố định 10

Bảng 2.2 Loại message 11

Bảng 2.3 Bảng các cờ 11

Bảng 2.4 Giá trị QoS 12

Bảng 2.5 Bảng miêu tả độ dàu ứng với số byte 13

Bảng 2.6 Ý nghĩa gói CONNACK 14

Bảng 2.7 Giá trị mức QoS 15

DANH MỤC CHỮ VIẾT TẮT

1) MQTT : Message Queuing Telemetry Transport

2) IoT : Internet of Things

3) M2M : Machine to Machine/ Mobile to Mobile

4) UWP: Universal Windows Platform

Trang 7

PHÂN HIỆU TẠI THÀNH PHỐ HỒ CHÍ MINH

THÔNG TIN KẾT QUẢ NGHIÊN CỨU CỦA ĐỀ TÀI

1 Thông tin chung:

- Tên đề tài: Thiết kế mô hình hệ thống nhà thông minh điều khiển giám sát thiết bị từ

xa bằng giọng nói

- Sinh viên thực hiện:

1 Nguyễn Thanh Phương Tùng

- Lớp: Tự Động Hóa Khoa: Điện- Điện Tử Năm thứ: 4 Số năm đào tạo: 4,5 năm

2 Huỳnh Thiên Duy

- Lớp: Tự Động Hóa Khoa: Điện- Điện Tử Năm thứ: 4 Số năm đào tạo: 4,5 năm

3 Nguyễn Minh Châu

- Lớp: Tự Động Hóa Khoa: Điện- Điện Tử Năm thứ: 3 Số năm đào tạo: 4,5 năm

- Người hướng dẫn: KS Ngô Thị Thu Hương

- Không cần di chuyển, chỉ ngồi một nơi cầm chiếc điện thoại di động trên tay là người

sử dụng có thể điều khiển các thiết bị điện trong nhà

Trang 8

- Điều khiển thiết bị thông qua wifi, 3G

- Xây dựng mô hình hệ thống nhà thông minh điều khiển và giám sát bằng laptop, smart phone qua internet

5 Đóng góp về mặt kinh tế - xã hội, giáo dục và đào tạo, an ninh, quốc phòng và khả năng áp dụng của đề tài:

Về cơ bản, hệ thống nhà thông minh cho phép điều khiển các thiết bị trong nhà như thiết bị chiếu sáng, điều hòa, chống trộm… một cách tự động và tập trung, nhằm tạo ra sự tiện nghi, thoải mái, tiết kiệm năng lượng và an ninh

Nhà thông minh bắt nguồn từ hệ thống tự động hóa tòa nhà, được biến đổi để áp dụng vào quy mô nhỏ hơn của một ngôi nhà hoặc một căn hộ Ngày nay, với sự phát triển của công nghệ, các hệ thống nhà thông minh còn cho phép kết nối đến các thiết bị như smartphone hay tablet để tăng tính tiện dụng

6 Công bố khoa học của sinh viên từ kết quả nghiên cứu của đề tài (ghi rõ họ tên tác giả, nhan đề và các yếu tố về xuất bản nếu có) hoặc nhận xét, đánh giá của cơ sở

đã áp dụng các kết quả nghiên cứu (nếu có):

Ngày tháng năm

Sinh viên chịu trách nhiệm chính

thực hiện đề tài (ký, họ và tên)

Trang 9

hiện đề tài (phần này do người hướng dẫn ghi):

Ngày tháng năm

Người hướng dẫn (ký, họ và tên)

Trang 10

Hình 1.1 Xu hướng phát triển nhà thông minh của thế giới

- Tất cả các hãng công nghệ lớn như Google, Amazon, Apple và Samsung đều đang tìm cách tiến sâu hơn vào thị trường smarthome Theo thống kê của Statista, năm

2020, giá trị thị trường của smarthome dự báo đạt 43 tỉ USD, gấp 3 lần so với năm

2014 Rõ ràng các khách hàng ngày càng yêu thích các ngôi nhà tự động hơn Thị trường Việt Nam cũng được đánh giá cao khi bất động sản nhà ở đang phát triển trong

xu hướng tích cực và người dùng sẵn lòng chi nhiều tiền hơn cho nội thất, tiện ích, trong đó có các sản phẩm công nghệ

Trang 11

- Tại Việt Nam, Bkav là công ty tiên phong giới thiệu công nghệ smarthome vào năm

2013, kèm theo tuyên bố đã mất 10 năm để đeo đuổi và hoàn thiện công nghệ này, gồm cả phần cứng thiết bị và phần mềm điều khiển thông minh Tất cả các hệ thống thiết bị của ngôi nhà như chiếu sáng, cấp nước, điều hòa, âm thanh, truyền hình… đều được gắn các bộ điều khiển điện tử để có thể kết nối với Internet và điện thoại di động, cho phép chủ nhân điều khiển vật dụng từ xa hoặc lập trình cho thiết bị ở nhà hoạt động theo lịch

- Từng giới thiệu tại CES 2015 (Mỹ) và nhiều triển lãm công nghệ trên thế giới, hệ thống SmartHome của Bkav khiến người tiêu dùng trong nước chú ý hơn tới giải pháp thông minh cho ngôi nhà

- Từ dấu ấn của Bkav, thị trường các thiết bị thông minh tại Việt Nam ngày càng phát triển Dù chưa tiến tới khái niệm smarthome, nhiều doanh nghiệp trong nước cũng muốn mở rộng thị trường thiết bị tự động (home automation) Chẳng hạn, cuối năm

2016, một nhóm các bạn trẻ ở Đại học Bách Khoa TP.HCM quyết tâm phát triển ý tưởng từ dự án tốt nghiệp: "Điều khiển hệ thống điện trong nhà bằng điện thoại Android" Kết quả là tháng 4 năm ngoái, Công ty Cổ phần Vsmarttek ra đời ở Khu Công nghệ cao TP.HCM Vsmarttek đang chập chững đi lại con đường mà những người khởi nghiệp cùng lĩnh vực ở Đại học Bách Khoa Hà Nội đã từng trải qua với các sản phẩm thiết bị tự động thương hiệu Lumi Hay mới đây Onsky, một công ty tư nhân

có trụ sở tại Thung lũng Silicon (Mỹ), cũng tung ra loạt sản phẩm thông minh trong nhà, phần cứng và phần mềm do các kỹ sư Việt Nam thiết kế

Trang 12

Hình 1.2 Dây chuyền sản xuất thiết bị smarthome của Bkav Ảnh: T.H

- Sự tham gia của Vsmarttek, Onsky hay Lumi cho thấy nhu cầu khá cao trong thị trường home automation, đáp ứng trải nghiệm của nhiều khách hàng về hệ thống các thiết bị tự động trong nhà Ưu thế của các giải pháp này là chi phí phù hợp với nhu cầu của người dùng tại Việt Nam, chỉ với khoảng 9-40 triệu đồng

- Ngoài các doanh nghiệp trên, thị trường có nhiều thương hiệu nước ngoài như Schneider, Smartg4, Arteor, My Home, WattStopper Đồng thời, cũng có không ít sản phẩm có xuất xứ từ Đài Loan, Trung Quốc với giá rẻ, cung cấp các thiết bị chiếu sáng tự động bằng cảm biến, công tắc thông minh, đến các gói giải pháp điều khiển thiết bị đèn, quạt, điều hòa bằng smartphone

- Trước sự đa dạng về chất lượng và giá cả, người dùng lại khá bối rối khi lựa chọn giải pháp cho smarthome Theo ông Vũ Thanh Thắng, Phó Chủ tịch phụ trách phần cứng Bkav, thị trường smarthome không hẳn đang ở trong tình trạng "loạn" mà tách biệt rõ giữa smarthome và home automation Điều này tùy thuộc vào nhu cầu của khách hàng "Hệ thống smarthome đúng nghĩa chứa đựng rất nhiều công nghệ hiện đại, thiết bị cao cấp… gồm cả phần cứng và phần mềm Trong đó có cả trí tuệ nhân tạo để đáp ứng được đòi hỏi độ thông minh của ngôi nhà", ông Thắng giải thích

- Đầu tư cho giải pháp smarthome hay home automation tùy thuộc vào nhu cầu của khách hàng Thực tế, giá cả là một rào cản lớn đối với các sản phẩm smarthome không riêng gì ở Việt Nam Theo khảo sát năm 2016 của Buzz, 2 nguyên nhân lớn khiến gia chủ ở Mỹ không sử dụng smarthome là vì không có hứng thú (37%) và quá đắt (31%), tiếp theo là nhu cầu riêng tư (21%)

1.2 Mục tiêu đề tài

- Xây dựng phần cứng và phần mềm hệ thống nhà thông minh điều khiển, giám sát thiết bị từ xa

- Nhận dạng giọng nói điều khiển thiết bị bằng laptop, smart phone qua internet

- Hoàn thành mô hình hệ thống nhà thông minh

1.3 Nhiệm vụ và giới hạn của đề tài

- Nghiên cứu về giao thức truyền dữ liệu

- Nghiên cứu sử dụng module wifi ESP32 và ứng dụng giao thức truyền dữ liệu giữa ESP32, smart phone và máy tính

Trang 13

- Thiết kế và thực hiện ứng dụng điều khiển, giám sát bằng giọng nói trên smart phone

và máy tính

- Xây dựng mô hình hệ thống nhà thông minh điều khiển và giám sát bằng laptop, smart phone qua internet

Trang 14

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

2.1 Tổng quan về giao thức MQTT (Message Queuing Telemetry Transport) 2.1.1 Giới thiệu về MQTT:

- MQTT được phát triển bởi IBM và Eurotech, phiên bản mới nhất là MQTT 3.1

- MQTT (Giao vận tầm xa) là giao thức truyền message theo mô hình cung cấp/thuê bao publish/subcribe MQTT dựa trên một Broker (điểm trung gian) “nhẹ” (khá ít xử lý), và được thiết kế có tính mở (không đăng trưng cho ứng dụng nào), rất đơn giản và

dễ để tích hợp MQTT phù hợp cho các ứng dụng M2M(Mobile to mobile), WSN (Wireless Sensor Networks) hay IoT (Internet of Things) Những đặc trưng này khiến MQTT rất lý tưởng để sử dụng trong các môi trường bị giới hạn tài nguyên như:

- Những nơi mà giá mạng quá đắt hoặc băng thông thấp, hoặc độ tin cậy thấp

- Khi chạy trên một thiết bị nhúng bị giới hạn về tài nguyên tốc độ và bộ nhớ - Các đặc trưng chính của giao thức bao gồm:

- Dạng truyền message cung cấp/thuê bao (publish/subcribe) cung cấp việc truyền tin phân tán 1-nhiều

- Việc truyền message là luôn không quan tâm đến nội dung truyền

- Dựa trên nền TCP/IP để cung cấp đường truyền – Có 3 loại QoS được đưa ra:

+ “Hầu như chỉ 1 lần “ : “At most once”, message được truyền nhận dựa hoàn toàn vào tính tin cận của TCP/IP Việc mất hoặc lặp message có thể xảy ra Ở QoS này, có thể ví dụ 1 trường hợp sử dụng: như trong môi trừong sensor mà việc mất

1 gói dữ liệu tại 1 thời điểm không ảnh hưởng đến toàn bộ quá trình

+ “Ít nhất 1 lần” : “At least once”, các message được đảm bảo nhận được nhưng

có thể xảy ra lặp

+ “Chính xác chỉ 1 lần” : “Exactly once”, message được đảm bảo đến nơi đúng

1 lần Ở level này, các hệ thống thanh toán, nơi mà việc lặp hay mất message có thể gây ra việc tính tiền bị sai

- Dữ liệu bao bọc dữ liệu truyền (overhead) nhỏ (độ dài cố định luôn là 2 byte), and là gia thức giảm đến mức tối thiểu traffic đường truyền

- Một cơ chế để thông báo đến các thuê bao khi đường truyền bị đứt bất thường, sử dụng Last Will và Testament feature

Trang 15

Hình 2.1 Ví dụ về kết nối trong mạng lưới MQTT

- Light sensor liên tục gửi dữ liệu về broker - Ứng dụng điều khiển tòa nhà nhận dữ liệu từ broker để quyết định trạng thái các thiết bị trong nhà

- Ứng dụng gửi tín hiệu điều khiển actor node thông qua broker

Hình 2.2 gửi tín hiệu điều khiển actor node thông qua broker

Trang 16

2.1.2 Đặc điểm của MQTT

- Truyền tin nhắn với tốc độ cao và có thế truyền trong môi trường có tín hiệu yếu

- Mô hình truyền thông không đồng bộ

- Dung lượng thấp (Khoảng 2 bite) cho các ứng dụng băng thông mạng thấp

- Sử dụng theo hình thức Publish / Subscribe (PubSub)

- Truyền dữ liệu từ Publisher với Subcriber thông qua các Topics (message queues)

- Giao thức đơn giản nhưng có thể sử dụng trong những môi trường phức tạp, bị nhiễu (Ví dụ: VSN- Wireless Sensor Networks: Mạng cảm biến không dây)

- Có thể làm việc khi mạng bị gián đoạn

Hình 2.3 Mô hình truyền thông của MQTT

2.1.3 Nguồn gốc và tương lai của MQTT

Nhìn lại lịch sử, con người đã chứng kiến 3 cuộc cách mạng khoa học kỹ thuật lớn:

Cuộc cách mạng công nghiệp lần thứ nhất (từ 1784) xảy ra khi loài người phát minh động cơ hơi nước, tác động trực tiếp đến các ngành nghề như dệt may, chế tạo cơ khí, giao thông vận tải Động cơ hơi nước được đưa vào ôtô, tàu hỏa, tàu thủy, mở ra một kỷ nguyên mới trong lịch sử nhân loại

Cuộc cách mạng công nghiệp lần thứ hai (từ 1870) đến khi loài người phát minh

ra động cơ điện, mang lại cuộc sống văn minh, năng suất tăng nhiều lần so với động cơ hơi nước

Cuộc cách mạng công nghiệp lần thứ ba (từ 1969) xuất hiện khi con người phát minh ra bóng bán dẫn, điện tử, kết nối thế giới liên lạc được với nhau Vệ tinh, máy bay, máy tính, điện thoại, Internet… là những công nghệ hiện nay chúng ta thụ hưởng

là từ cuộc cách mạng này

Cuộc cách mạng công nghiệp lần thứ tư đang diễn ra từ những năm 2000 gọi

Trang 17

là cuộc cách mạng số, thông qua các công nghệ như Internet vạn vật (IoT), trí tuệ nhân tạo (AI), thực tế ảo (VR), tương tác thực tại ảo (AR), mạng xã hội, điện toán đám mây, di động, phân tích dữ liệu lớn (SMAC) để chuyển hóa toàn bộ thế giới thực thành thế giới số

Năm 2013, một từ khóa mới là “Công nghiệp 4.0” (Industrie 4.0) bắt đầu nổi lên xuất phát từ một báo cáo của chính phủ Đức đề cập đến cụm từ này nhằm nói tới chiến lược công nghệ cao, điện toán hóa ngành sản xuất mà không cần sự tham gia của con người Thủ tướng Đức Angela Merkel tiếp tục nhắc tới Industrie 4.0 tại Diễn đàn Kinh

tế thế giới ở Davos tháng 1/2015 Hiện nay, Công nghiệp 4.0 đã vượt ra khỏi khuôn khổ dự án của Đức với sự tham gia của nhiều nước và trở thành một phần quan trọng của cuộc cách mạng công nghiệp lần thứ tư

Và IoT là một trong nhưng công nghệ quan trong nhất sẽ là thành phần quyết định của CM công nghiệp lần thứ 4 Với mức phát triển nhanh chóng, năm 1984, có 1.000 thiết bị kết nối toàn cầu, Đến năm 2010 là 10 tỷ Và đến 2020 dự đoán có 50 tỷ thiết bị được kết nối vào hệ thống Internet toàn cầu

Trong IoT có rất nhiều các phương thức và giao thức kết nối Từ vật lý đến mô hình mạng không dây

MQTT ban đầu được phát triển bởi IBM và Eurotech

Phiên bản mới nhất của MQTT là version 3.1 (link http ://mqtt.org/)

Vào năm 2014, MQTT đã được OASIS thông qua và công bố như một tiêu chuẩn chính thức (xuất bản V3.1.1)

Như vậy, OASIS đã trở thành ngôi nhà mới cho sự phát triển của MQTT

OASIS TC (Ủy ban kỹ thuật) được giao nhiệm vụ phát triển MQTT

Phiên bản 3.1.1 của MQTT tương thích ngược với 3.1 và chỉ mang lại những thay đổi nhỏ :

• Các thay đổi bị giới hạn trong tin nhắn CONNECT

• Làm rõ phiên bản 3.1 (phần lớn là những thay đổi về biên tập)

Trang 18

Hình 2.4 Quá trình phát triển của MQTT

2.1.4 Mô hình MQTT:

- Các thành phần chính của MQTT là clients, servers (=brokers), sessions, subscriptions và topics

Hình 2.5 Mô hình cơ bản của giao thức MQTT

- MQTT client (publisher, subscriber): Client thực hiện subscribe đến topics để publish

và receive các gói tin

- MQTT server (broker): Servers thực hiện run các topic, đồng thời nhận subscriptions

từ clients yêu cầu các topics, nhận các messages từ clients và forward chúng

- Topic: Về mặt kỹ thuật, topics là các hàng đợi chứa message Về logic, topics cho phép clients trao đổi thông tin và dữ liệu

- Session: Một session được định nghĩa là kết nối từ client đến server Tất cả các giao tiếp giữa client và server đều là 1 phần của session

Trang 19

- Subscription: Không giống như sessions, subscription về mặt logic là kết nối từ client đến topic Khi thực hiện subscribed đến topic, client có thể trao đổi messages với topic Subscriptions có thể ở trạng thái ‘transient’ hoặc ‘durable’, phụ thuộc vào cờ clean session trong gói Connect

- Message: Messages là các đơn vị dữ liệu được trao đổi giữa các topic clients

2.1.5 Định dạng tin nhắn MQTT

* Phần header cố định

- Tất cả các message luôn chứa phần cố định theo bảng 2.4

Bảng 2.1 Header cố định

Byte 1 : Chứa loại Message và các cờ (DUP, QoS level, and RETAIN)

Byte 2 : (Ít nhất 1 byte) quy định độ dài còn lại

Loại Message Vị trí: byte 1, bits 7-4

Một số 4-bit không dấu diễn tả các giá trị được miêu tả dưới bảng 2.5

Trang 20

Bảng 2.2 Loại message

- Các cờ Bit còn lại của byte đầu chứa các trường DUP, QoS và RETAIN Vị trí các bit và ý nghĩa được miêu tả trong bảng 2.6

Bảng 2.3 Bảng các cờ

* DUP :Vị trí byte 1, bit 3

Cờ này được bật khi client hoặc server đang cố chuyển lại một gói PUBLISH, PUBREL, SUBSCRIBE hoặc UNSUBSCRIBE Giá trị này được sử dụng trong các mesage mà có QoSS lớn hơn 0 và yêu cầu ACK Khi bit DUP được set, phần header

Trang 21

thay đổi sẽ chứa Message ID Nhìn vào giá trị này sẽ biết được gói tin đã nhận được trước đó hay không Nó không nên sử dụng để tin ngay rằng có duplicates hay không

* QoS : Vị trí byte 1, bits 2-1

Cờ này sẽ cho biết độ đảm bảo việc nhận message PUBLISH Giá trị của QoS được miêu tả trong bảng 2.7

Bảng 2.4 Giá trị QoS

* RETAIN: Vị trí byte 1, bit 0

Cờ này chỉ được sử dụng ở message PUBLISH Khi client gửi 1 message PUBLISH đến server, nếu cờ Retain được set (1), thì server phải hiểu rằng nên giữ message này ngay cả sau khi chuyển nó đến các subcribers hiện tại Khi có 1 subcription mới được thiết lập trên 1 topic, message cuối cùng của topic đó nên được gửi đến subscriber với 1 trường Retain được set trong header Nếu không có messsage nào còn, thì không cần gửi gì hết

Trường này sẽ có ích khi publisher gửi message để báo “report bằng ngoại lệ”, thỉnh thoảng là nơi giữa các message Điều này cho phép những subcribers mới nhanh chóng nhận dữ cần thiết Trường hợp mà server chuyển tiếp nội dung vừa nhận được

từ một Publisher thì trường Retain sẽ không được set Điều này sẽ giúp phân biệt được message có từ trước với message mới được publish lên Message Retained sẽ được giữ thậm chí sau khi restart lại server Server sẽ xóa message được retained nếu nó nhận được một message với payload bằng zero

* Độ dài còn lại

Vị trí: byte 2

Miêu tả độ dài bao gồm cả phần header và payload có trong message Việc encoding với độ dài thay đổi sử dụng 1 byte để miêu tả độ dài, vì thế độ dài tối đa sẽ là

127 Những message dài hơn sẽ được miêu tả theo cách sau 7 bít được dùng để miêu

tả giá trị, bít còn lại dùng để miêu tả phía sau còn byte nào miêu tả trường này hay

Trang 22

không Mỗi byte tiếp sau đó cũng như vậy 7 bit để lưu giá trị, 1 bít gọi là bit tiếp tục Giá trị được tính bằng cách nhân giá trị được diên tả bởi 7 bit và lũy thừa tăng dần của

128 Ví dụ miêu tả độ Remain Length = 64, ta chỉ cần 1 byte, trong đó 7 bytes để miêu

tả giá trị 64, 1 bit còn lại bằng 0 Một ví dụ nữa, giá trị là 321 chẳng hạn 321 = 65*128^0 + 2* 128^1, ta cần 2 byte để biểu diễn Byte đầu chứa giá trị 65 trong 7 bit

và bit còn lại là 1 Byte thứ 2 chứa giá trị 2 ở 7 bit và 1 bit chứa giá trị bằng 0

Trường này được biểu diễn tối đa trong 4 byte Tức là cho độ dài cho phép sẽ là đến 268 435 455 (256 MB)

Bảng 2.5 Bảng miêu tả độ dàu ứng với số byte

2.1.6 Các khái niệm đáng chú ý trong MQTT

a CONNECT – Client yêu cầu connect đến server

Khi một một kết nối TCP/IP được thiết lập từ client đến server, thì một session ở mức protocol cũng được tạo sử dụng luồng CONNECT Server sẽ gửi message CONNACK để trả lời message CONNECT từ client Nếu server không nhận được mesage CONNET từ client trong một khoang thời gian nào đó sau khi thiết lập kết nối TCP/IP, thì server nên đóng kết nối đó lại Nếu client không nhận được một message CONNACK từ server trong một khoảng thời gian nhất định, thì client cũng nên đóng kết nối đó lại, và restart session bằng một socket mới đến server rồi tiếp tục gửi yêu cầu kết nối bằng gói CONNECT Trong cả 2 trường hợp trên, thời gian chờ để nhận được message CONNECT hoặc CONNACK phụ thuộc vào ứng dụng và điều kiện kết nối Nếu một client kết nối bằng một Client ID đang được kết nối với Server rồi, thì client trước đó phải được disconnect bắt buộc bởi server trước khi thực hiện luồng CONNECT với client mới Nếu client gửi một một message CONNECT không hợp lệ, server nên đóng kết nối luôn Không hợp ở đây bao gồm việc khác nhau về Protocol Name hoặc Protocol Version Numbers Nếu server đã parse message CONNECT rồi

Trang 23

mới phát hiện ra có một trường nào đó không hợp lệ, nó nên gửi lại message CONNACK chứa nội dung mã có nội dung “Kết nối bị từ chối: phiên bản protocol không được chấp nhận” trước khi hủy kết nối này

b CONNACK – Acknowledge connection request

Message CONNACK được gửi bởi server như để trả lời một yêu cầu a CONNECT từ client Mỗi giá trị trả về của Connack được chỉ ra dưới bảng 2.9

Bảng 2.6 Ý nghĩa gói CONNACK

Mã trả về là 2 sẽ (định danh bị từ chối) sẽ được gửi nếu nếu định danh duy nhất cho 1 client có độ dài không nằm trong khoảng từ 1 đến 23

c PUBLISH – Message Publish Một message

PUBLISH được gửi từ một client đến server để phân tán chúng đến các subscriber cần chúng Mỗi message luôn gắn liền với một topic name (cũng được hiểu

là Subject hoặc Channel) Topic là có dạng không gian phân cấp, nó định nghĩa ra một cách phân loại nguồn thông tin để cho các subscribers có thể subscribe nếu muốn.Một message được published đến một topic nào đó sẽ được phân phát đến các subscriber quan tâm đến topic đó

Nếu 1 client subscribe một hoặc nhiều topic, thì mọi message được published đến những topic đó được gửi bởi server đến client như là một message PUBLISH Response cho PUBLISH message phụ thuộc vào level của QoS

Trang 24

Bảng 2.7 Giá trị mức QoS

Các message PUBLISH được gửi từ Publisher đến server, hoặc là từ Server đến Subsciber Việc tiếp thu khi nó nhận được messsage phụ thuộc vào QoS level của message:

QoS 0 : Phải đảm bảo chắc chắn rằng các message đến các bên quan tâm QoS 1: Giữ một bản của messsage trên bộ nhớ ngoài, tất nhiên cũng phải đảm báo nó đến các bên quan tâm, và trả lại một message PUBACK đến bên gửi

QoS 2 : Giữ lại một bản trên bộ nhớ ngoài, đừng gửi nó đến các bên quan tâm , trả về message PUBREC đến bên gửi

Ở đây, nếu server nhận được message, các bên quan tâm nghĩa là các subscriber đến topic của message PUBLISH đó Nếu một subscriber nhận một message, thì các bên quan tâm ám chỉ đến các ứng dụng bên phía client mà đã subcribe mọt hoặc nhiều topics và đang đợi một message đến từ server

Nếu một server mà không xác nhận được một PUBLISH từ một client, thì nó không có cách nào để thông bao đến client đó Vì thế nó phải đảm bảo một mức hiểu biết nhất định, tùy thuộc vào các rule QoS, client sẽ không được báo rằng việc xác thực message PUBLISH nó gửi đi

d SUBSCRIBE – Subscribe to named topics

Message SUBSCRIBE cho phép client subscribe một hoặc nhiều topics với server Message được published lên server sẽ được chuyển đến client bằng message PUBLISH Message SUBSCRIBE cũng chỉ ra QoS level mà subscriber muốn nhận message Khi nhận được một message SUBSCRIBE message, server trả lời bằng message SUBACK

Một server bắt đầu gửi một message PUBLISH cho yêu cầu của về subscription của client thậm chí trước khi client nhận được message SUBACK Nếu một server không xác nhận một yêu cầu SUBSCRIBE từ client, thì nó không có cách

Trang 25

nào thông tin cho client Vì thế nó tạo ra message SUBACK như là để xác nhận, và client sẽ không được thông báo rằng nó không được xác thực

Một server có quyền chỉ định một level of QoS thấp hơn client yêu cầu Điều này có thể xảy ra nếu server không thể cung cấp các levels of QoS cao hơn Ví dụ, nếu server không cung cấp một cơ chế lưu trữ tin cậy nào đó nó có thể chỉ cấp cho các subscriptions với QoS là 0

e PINGREQ – PING request

Message PINGREQ có nghĩa là message “Kết nối vẫn tốt đúng không?” được gửi từ một client đã kết nối đến server

f PINGRESP – PING response

Một message PINGRESP được gửi từ server cho một message PINGREQ và nó

có nghĩa là “OK”

g DISCONNECT – Disconnect notification

Message DISCONNECT được gửi từ client đến server để báo rằng nó sẽ đóng kết nối TCP/IP đang kết nối Cái này cho phép một clean disconnection, chứ không chỉ

là hủy kết nối Một server không nên để việc đóng kết nối này cho phía client sau khi nhận message DISCONNECT

2.1.7 Quy trình truyền nhận dữ liệu chính trong MQTT

a CONNECT and SUBSCRIBE message sequence

Trường hợp 1: Session và subscription được thiết lập với clean session flag = 1 (transient subscription)

Trang 26

Hình 2.6 Session và subscription được thiết lập với clean session flag = 1 Quy trình truyền nhận dữ liệu trong MQTT khi session flag = 1:

- Client và Server được kết nối qua giao thức TCP

- Client gửi gói tin CONNECT yêu cầu kết nối đến Server, clean session = 1 Đây là thời điểm đánh dấu session được thiết lập

- Server gởi gói CONNACK xác nhận thiết lập kết nối thành công

- Client thực hiện SUBSCRIBE đến topic XYZ Đây là thời điểm bắt đầu timeout của một subscription

- Server gởi gói SUBACK xác nhận quá trình subscription

- Client PUBLISH để gởi topic

- message đến server

- Sau khi nhận đủ thông tin, client gửi gói UNSUBSCRIBE topic XYZ để kết thúc quá trình Subscribe

- Server trả về gói UNSUBACK

- Client gửi gói DISCONNECT để kết thúc session truyền thông

Trường hợp 2: Session và subscription được thiết lập với clean session flag = 0 (durable subscription)

Trang 27

Hình 2.7 Session và subscription được thiết lập với clean session flag = 0 Quy trình truyền nhận dữ liệu trong MQTT khi session flag = 0:

- Subscription lifetime đã được thiết lập trước

- Client và Server được kết nối qua giao thức TCP

- Client gửi gói tin CONNECT yêu cầu kết nối đến Server, clean session = 0 Đây là thời điểm đánh dấu session được thiết lập

- Server gởi gói CONNACK xác nhận thiết lập kết nối thành công

- Client PUBLISH để gởi topic

- message đến server

- Client gửi gói DISCONNECT để kết thúc session truyền thông

b PUBLISH message flows QoS

level 0: At most once delivery

Message được phân phối dựa trên best efforts của tầng mạng TCP/IP bên dưới Một response sẽ không được định nghĩa trong giao thức Các message đến server hoặc chỉ 1 lần hoặc không bao giờ

Hình 2.8 QoS mức 0 QoS level 1: At least once delivery

Trang 28

Việc nhận được message bên phía server được xác nhận bởi một message PUBACK Nếu có lỗi do kết nối hoặc gửi đến device, hoặc message xác nhận không nhận được sau một khoảng thời gian nhất định, sender sẽ gửi lại message và set DUP bit trong phần header của message header Message đến server ít nhất 1 lần Cả message SUBSCRIBE và message UNSUBSCRIBE đều sử dụng QoS level là 1

Khi nhận được một message lặp lại từ phía client, server sẽ publish các message đến các subscribers, và gửi một message PUBACK khác

Hình 2.9 QoS mức 1 QoS level 2: Exactly once delivery

Một luồng được thêm vào luồng QoS level bằng 1 ở trên để đảm bảo rằng message bị lặp lại không bị chuyển đến ứng dụng Đây là mức độ cao nhất khi khi phân phối message, không message lặp nào được chấp nhận Nhờ đó mà lưu lượng mạng sẽ tăng lên

Nếu phát hiện lỗi, hoặc sau một khoảng thời gian nhất định, luồng protocol sẽ được thực hiện lại từ kết quả của message xác nhận cuối cùng; hoặc là PUBLISH , hoặc là PUBREL Luồng protocol đảm bảo rằng message đến các subscriber chỉ đúng

1 lần

Trang 29

Hình 2.10 QoS mức 2

2.1.8 Kết luận

MQTT là một giao thức gửi dạng publish/subscribe , là giao thức ở tầng ứng dụng, sử dụng tầng giao vận là giao thức đáp ứng 3 yêu cầu đó là: các gói tin đến theo thứ tự, không bị mất mát và kết nối là kết nối 2 chiều(giống như các đặc điểm của giao thức tầng giao vận TCP/IP) Với cơ chế publish/subscribe thông qua Broker trung giao giúp hệ thống giải quyết được vấn đề đồng bộ khi điều khiển từ nhiều thiết bị khác nhau mà không sợ xung đột hoặc bị ngược trạng thái điều khiển

MQTT được sử dụng cho các thiết bị Internet of Thing với băng thông thấp, độ tin cậy cao và khả năng được sử dụng trong mạng lưới không ổn định, vì vậy đây là giao thức rất thích hợp để xây dựng hệ thống nhà thông minh có khả năng điều khiển, giám sát từ xa

Trang 30

2.2 Module wifi ESP32

Hình 2.11 Module ESP32 2.2.1 Giới thiệu module :

- ESP32 có thể được xem là một hệ thống độc lập hoàn chỉnh để thực hiện các chức năng đầy đủ của một thiết bị đáp ứng nhu cầu như : giao tiếp với một hề thống khác thông qua WIFI hoặc Bluetooth thông qua các giao điện SPI/SDIO hoặc I2C/UART

- Được tích hợp nhiều chức năng với thiết bị chuyển mạch ăng-ten , RF , bộ khuếch đâị công suất, chống nhiễu, bộ lọc và module quản lý năng lượng, bổ sung nhiều chức năng vô cùng linh hoạt với 1 yêu cầu tối thiểu của một PCB

- Được thiết kế cho các thiết bị đi động, các thiết bị đeo và ứng đụng IOT, ESP32 có mức tiêu thụ năng lượng cực thấp với sự kết hợp của một số phần mềm độc quyền ESP32 cũng bao gồm các khá nhiều tính năng tiên tiến,…

- Thiết kế mạnh mẽ hoạt động trong môi trường -40 đến 125 độ C , trang bị mạch cân chỉnh tiên tiến , tự thích ứng với sự thay đổi của môi trường

- Trên thị trường có rất nhiều biến thể của module này nhưng bài viết này sẽ cho các bạn biết những thứ tổng quan nhất về Module này

- Hỗ trợ Wifi chuẩn 802.22 b/g/n ( tốc độ lên đến 150 Mbps) ở dãy tần 2.4GHz – 2.5GHz

- Hỗ trợ Bluetooth V4.2 BR/EDR và BLE

Trang 31

- Các Module giao tiếp : SD card, UART, SPI, SDIO, I2C, LED PWM, Motor PWM, I2S, IR

- Cảm biến tích hợp trên ESP32 : Hall sensor ( Cảm Biến Từ) , Temperature Sensor ( Nhiệt độ) , Cảm biến chạm điện dung (touch sensor)

- 2 ngõ kết nối dao động thạch anh 32.768kHz GPIO( 32 ,33 )

- RTC ở chân GPIO (4,0,12,13,14,25,26,32,33,34,35) để sử dụng hệ thống thời gian thực

- Các ngõ ADC nằm ở GPIO (0,2,4,12,13,14,15,25,26,27, 32,33,34,35)

Trang 32

2.2.3 Cảm biến nhiệt độ trên ESP32

- Cảm biến nhiệt độ có chức năng tạo ra điện áp thay đổi theo nhiệt độ Điện áp được chuyển đổi nội bộ qua một chuyển đổi ADC ra dạng số, hoạt động từ dãy -40 đến 125

độ C , độ sai lệch của cảm biến đến từ chip do các biến thể quá trình hoặc nhiệt lượng tỏa ra từ mạch WIFI tạo ra ảnh hướng đến phép đo vì vậy nó chỉ dùng để phát hiện thay đổi nhiệt độ , và không thể mang tính chất tuyệt đối về mặt chính xác

2.2.4 Cảm biến điện dung trên ESP32

- ESP32 có 10 GPIO cảm biến điện dung sử dụng với 1 ngón tay hoặc các vật khác Bản chất chống nhiễu cao của thiết kế và độ nhạy tốt của mạch cho phép phát hiện chuẩn xác với nhiều điểm hơn

2.2.5 Trình biên dịch Arduino IDE cho ESP32

- ESP32 được biên dịch trên Arduino IDE một công cụ khá phổ biến cho các lĩnh vực

về arduino , đây là một lợi thế vì trình biên dịch hỗ trợ nhiều thư viện đáp ứng nhu cầu

- Hướng dẫn cài đặt để sử dụng esp32 :

Bước 1: Lên trang arduino tải trình IDE mới nhất

https://www.arduino.cc/en/Main/Software

Trang 33

Mở file Setup.exe và chạy

Sau đó chọn ổ đĩa muốn cài đặt IDE , thông thường mặc định sẽ là ổ C

Chờ cài đặt các file cần thiết mất khoảng vài phút

Trang 34

Bước 2: Cài đặt Python : 2.7.12.amd64.msi

http://www.mediafire.com/file/xaeb4ej1stav0yb/python-Mở file vừa tải về và khởi chạy bằng nút Run

Chọn cài đặt cho người dùng , thông thường chọn cho tất cả thì all use, nếu muốn sử dụng riêng thì chọn

Install for me

Chọn nơi nưu trữ cài đặt , phần này nên để ổ mặc định

Trang 35

Tiếp theo chọn vào dòng add python.exe to Path và chọn next

Chọn Finish để hoàn tất quá trình cài đặt

Trang 36

Bước 3: Cài đặt spyserial

vào CMD (windows+R) gõ lệnh : pip install pyserial

Bước 4: Cài đặt module và thư viện cho ESP32

Tải file module này về : http://www.mediafire.com/file/5xr7v57ardsh1eo/esp32.7z

Giải nén nó vào thư mục : \Arduino\hardware\espressif\esp32

Sau đó vào thư mục sau để chạy file get.exe : \Arduino\hardware\espressif\esp32\tools

Trang 37

Cài đặt xong các sẽ thấy Board : ESP32 Dev Module

2.2.6 MQTT-Client trên ESP32

2.2.6.1 Cài đặt thư viện PubSubClient

- Vào Sketch chọn Include Library

- Gõ chữ PubSubClient và cài đặt

Trang 38

2.2.6.2 Sử dụng các hàm API của thư viện PubSubClient

 Hàm PubSubClient(Client &client) để khởi động bộ thư viện Chúng ta sẽ tạo 1 biến kiểu Client và pass địa chỉ biến đó vào hàm này để khởi động bộ thư viện

 Hàm setServer(<domain name của Broker>, <TCP port>) để thiết lập địa chỉ của Broker server và port TCP sẽ kết nối đến

 Hàm setCallback(<callback>) để đăng ký hàm callback sẽ được gọi khi thư viện nhận được giá trị mới từ Broker cho dữ liệu đã được subscribe

 Hàm connect(<client_name>) để bắt đầu quá trình kết nối đến Broker server Hàm này sẽ đợi đến khi kết nối thành công hoặc timeout; giá trị trả về của hàm là kiểu boolean với True là kết nối thành công, False là kết nối không thành công

 Hàm disconnect() để chủ động ngắt kết nối đến Broker server

 Hàm publish(<topic>, <value>) để gửi giá trị <value> cho dữ liệu <topic> lên Broker server

 Hàm subscribe(<topic>) để đăng ký nhận giá trị mới của dữ liệu <topic> từ Broker server

 Hàm connnected() để kiểm tra trạng thái kết nối đến Broker server (True = kết nối OK)

 Hàm loop() là hàm xử lý các tác vụ theo giao thức MQTT Chúng ta sẽ gọi hàm này liên tục trong hàm loop() của ESP32

Trang 39

2.2.7 Kết luận

Module Wifi ESP32 có IC trung tâm là ESP32 v

32-bit LX6 microprocessors đ

Bluetooth BR/EDR & BLE v4.2, ngoài ra còn có 448 Kbyte ROM, 520 Kbyte SRAM

in RTCm, clock & Times Module có kích thư

ESP32, mạch được thiết k

nhiễu và anten Wifi BLE PCB tích h

Việc lập trình cho ESP32 c

quá quen thuộc, với thư vi

MQTT với module ESP32 đóng vai tr

năng vượt trội, module Wifi ESP32 là s

dụng về Wifi, BLE và IoT

2.3 Nhận dạng giọng nói trong Universal Windo

2.3.1 Giới thiệu chung v

2.3.1.1 Giới thiệu chung

UWP là một nền t

tính năng của mình và điể

cả mọi thiết bị nào có kh

cho đến HoloLens và Xbox và ngay c

Window 10 IoT

ifi ESP32 có IC trung tâm là ESP32 với nhân xử lý dualoprocessors đầy mạnh mẽ, tích hợp chuẩn Wi-Bluetooth BR/EDR & BLE v4.2, ngoài ra còn có 448 Kbyte ROM, 520 Kbyte SRAM

in RTCm, clock & Times Module có kích thước nhỏ gọn, ra chân đ

t kế và gia công với chất lượng tốt với vỏ

u và anten Wifi BLE PCB tích hợp cho khoảng cách truyền xa và

p trình cho ESP32 cực kỳ dễ dàng với trình biên d

i thư viện MQTT-Client ta hoàn toàn có thể

i module ESP32 đóng vai trò là 1 Client.Cùng với giá thành r

i, module Wifi ESP32 là sự lựa chọn hàng đầu trong các nghiên cWifi, BLE và IoT

ận dạng giọng nói trong Universal Windows Platform (UWP)

u chung về Unviversal Windows Flatform (UWP)

u chung

Hình 2.13 Nền tảng UWP

n tảng cốt lõi của Windows 10 giúp các ứng d

ểm hay nhất nằm ở chỗ UWP sẽ hoạt động thnào có khả năng chạy Windows 10, từ điện thoại, máy tính b

n HoloLens và Xbox và ngay cả trên Raspberry pi 3 ch

lý dual-core Xtensa®

-Fi 802.11 b/g/n/e/l, Bluetooth BR/EDR & BLE v4.2, ngoài ra còn có 448 Kbyte ROM, 520 Kbyte SRAM

n, ra chân đầy đủ của IC

ng dụng thực hiện các

ng thống nhất trên tất

i, máy tính bảng, PC trên Raspberry pi 3 chạy hệ điều hành

Trang 40

UWP là một nền tảng chứa các tính năng mà Windows 10 cho các ứng dụng sử dụng, ví dụ như khả năng truy cập mạng, khả năng tuy cập bộ nhớ lưu trữ, khả năng

xử lý tập tin, khả năng phát video Chúng ta có thể xem UWP như một lớp bên dưới

và các ứng dụng universal sẽ được xây dựng dựa trên lớp này

UWP rất linh hoạt Ta có thể sử dụng các ngôn ngữ như C#, C++, Javascript và

VB để viết ứng dụng UWP và ta hoàn toàn có thể sử dụng bộ công cụ Visual Stiduio

- Từ phiên bản Windows 10 1607 thì có thêm trạng thái Running in background, tức

là ứng dụng vẫn hoạt động ngầm mà người dùng không quan sát thấy ứng dụng và tương tác được

Ngày đăng: 31/05/2023, 10:41

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w