Chương 2 CƠ SỞ LÝ THUYẾT
2.8 GIAO THỨC MQTT
MQTT (Message Queuing Telemetry Transport) được phát triển bởi IBM và Eurotech, phiên bản mới nhất là MQTT 3.1.
MQTT là giao thức truyền message theo mơ hình publish/subcribe. Nó 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.
Kiến trúc mức cao (high-level) của MQTT gồm 2 phần chính là Broker và Clients. Trong đó, broker được coi như trung tâm, nó là điểm giao của tất cả các kết nối đến từ client. Nhiệm vụ chính của broker là nhận mesage từ publisher, xếp các message theo hàng đợi rồi chuyển chúng tới một địa chỉ cụ thể. Nhiệm vụ phụ của broker là nó có thể đảm nhận thêm một vài tính năng liên quan tới q trình truyền thông như: bảo mật message, lưu trữ message, logs, …
Client thì được chia thành 2 nhóm là publisher và subscriber. Client là các software components hoạt động tại edge device nên chúng được thiết kế để có thể hoạt động một cách linh hoạt (lightweight). Client chỉ làm ít nhất một trong 2 việc là publish các message lên một topic cụ thể hoặc subscribe một topic nào đó để nhận message từ topic này.
Hình 2.26: MQTT Broker
MQTT Clients tương thích với hầu hết các nền tảng hệ điều hành hiện có: MAC OS, Windows, LInux, Androids, iOS…
Có thể tưởng tượng broker giống như một sạp báo. Publisher là các tòa soạn báo. Tòa soạn in báo và chuyển cho sạp báo. Người đọc báo đến sạp báo, chọn tờ báo mình cần đọc (subscriber).
Bởi vì giao thức này sử dụng băng thơng thấp trong mơi trường có độ trễ cao nên nó là một giao thức lý tưởng cho các ứng dụng M2M (Machine to machine)
a. Publish, subscribe
Trong một hệ thống sử dụng giao thức MQTT, nhiều node trạm (gọi là mqtt client – gọi tắt là client) kết nối tới một MQTT server (gọi là broker). Mỗi client sẽ đăng ký một vài kênh (topic), ví dụ như “/client1/channel1”, “/client1/channel2”. Quá trình đăng ký này gọi là “subscribe”, mỗi client sẽ nhận được dữ liệu khi bất kỳ trạm nào khác gởi dữ liệu và kênh đã đăng ký. Khi một client gởi dữ liệu tới kênh đó, gọi là “publish”.
b. QoS (Qualities of service)
Có 3 tuỳ chọn QoS khi “publish” và “subscribe”:
- QoS0 Broker/client sẽ gởi dữ liệu đúng 1 lần, quá trình gởi được xác nhận bởi chỉ giao thức TCP/IP.
- QoS1 Broker/client sẽ gởi dữ liệu với ít nhất 1 lần xác nhận từ đầu kia, nghĩa là có thể có nhiều hơn 1 lần xác nhận đã nhận được dữ liệu.
- QoS2 Broker/client đảm bảm khi gởi dữ liệu thì phía nhận chỉ nhận được đúng 1 lần.
Một gói tin có thể được gởi ở bất kỳ QoS nào, và các client cũng có thể subscribe với bất kỳ yêu cầu QoS nào. Có nghĩa là client sẽ lựa chọn QoS tối đa mà nó có để nhận tin.
Ví dụ, nếu 1 gói dữ liệu được publish với QoS2, và client subscribe với QoS0, thì gói dữ liệu được nhận về client này sẽ được broker gởi với QoS0, và 1 client khác đăng ký cùng kênh này với QoS2, thì nó sẽ được Broker gởi dữ liệu với QoS2.
Một ví dụ khác, nếu 1 client subscribe với QoS2 và gói dữ liệu gởi vào kênh đó publish với QoS0 thì client đó sẽ được Broker gởi dữ liệu với QoS0. QoS càng cao thì càng đáng tin cậy, đồng thời độ trễ và băng thơng địi hỏi cũng cao hơn.
c. Retain
Retain là một cờ (flag) được gắn cho một message của giao thức MQTT. Retain chỉ nhận giá trị 0 hoặc 1 (tương ứng 2 giá trị logic false hoặc true). Nếu retain = 1, broker sẽ lưu lại message cuối cùng của 1 topic kèm theo mức QoS tương ứng. Khi client bắt đầu subscribe topic có message được lưu lại đó, client ngay lập tức nhận được message.
2.8.2 MQTT Bridge
MQTT Bridge là một tính năng của MQTT Broker cho phép các MQTT Broker có thể kết nối và trao đổi dữ liệu với nhau. Để sử dụng tính năng này, ta cần tối thiểu 2 Broker, trong đó, một Broker bất kỳ sẽ được cấu hình thành Bridge. Khi cấu hình MQTT bridge, ta cần lưu ý tới các thông số sau:
address: địa chỉ của broker cần kết nối
bridge_protocol_version: phiên bản của giao thức MQTT đang sử dụng chung cho 2 broker
topic: phần này định nghĩa 3 thông số: tên topic được trao đổi giữa 2 broker, chiều trao đổi (1 chiều hay 2 chiều) và topic mapping giữa 2 broker
2.8.3 Bảo mật
MQTT được thiết kế một cách nhẹ và linh hoạt nhất có thể. Do đó nó chỉ có 1 lớp bảo mật ở tầng ứng dụng: bảo mật bằng xác thực (xác thực các client được quyền truy cập tới broker).
Tuy vậy, MQTT vẫn có thể được cài đặt kết hợp với các giải pháp bảo mật đa tầng khác như kết hợp với VPN ở tầng mạng hoặc SSL/TLS ở tầng transport.
MQTT được thiết kế nhằm phục vụ truyền thơng machine-to-machine nhưng thực tế chứng minh nó lại linh hoạt hơn mong đợi. Nó hồn tồn có thể áp dụng cho các kịch bản truyền thông khác như: machine-to-cloud, cloud-to-machine, app-to- app. Chỉ cần có một broker phù hợp và MQTT client được cài đặt đúng cách, các thiết bị xây dựng trên nhiều nền tảng khác nhau có thể giao tiếp với nhau một cách dễ dàng.
Giao thức MQTT ra đời năm 1999 và tính đến thời điểm hiện tại, MQTT phiên bản 3.1.1 được công nhận chuẩn OASIS.
2.8.4 Ứng dụng của MQTT
Có một số dự án thực hiện MQTT.
Facebook Messenger, Facebook đã sử dụng các khía cạnh của MQTT trong Facebook Messenger để trị chuyện trực tuyến. Tuy nhiên, khơng rõ MQTT được sử dụng bao nhiêu hoặc để làm gì.
IECC Scalable, DeltaRail phiên bản mới nhất của hệ thống kiểm soát hiệu IECC của họ ‘s sử dụng MQTT cho thông tin liên lạc trong các phần khác nhau của hệ thống và các thành phần khác của hệ thống báo hiệu. Nó cung cấp khung truyền thông cơ bản cho một hệ thống tuân thủ các tiêu chuẩn CENELEC cho các thông tin liên lạc quan trọng về an toàn.
Amazon Web Services đã công bố Amazon IoT dựa trên MQTT vào năm 2015.
Các tổ chức không gian địa lý SensorThings API đặc điểm kỹ thuật tiêu chuẩn có một phần mở rộng MQTT trong tiêu chuẩn như một giao thức thông báo bổ sung ràng buộc. Nó đã được chứng minh trong một thí điểm IoT của Bộ An ninh Nội địa Hoa Kỳ.
Các dịch vụ của Cơ sở hạ tầng thượng nguồn OpenStack được kết nối bằng một bus tin nhắn hợp nhất MQTT với Mosquitto là broker MQTT.
Adafruit đưa ra một MQTT miễn phí dịch vụ đám mây cho thí nghiệm IOT và người học gọi Adafruit IO trong năm 2015.
Microsoft Azure IoT Hub sử dụng MQTT làm giao thức chính cho các tin nhắn từ xa.
Nền tảng tự động hóa phần mềm nguồn mở Home Assistant được bật MQTT và cung cấp bốn tùy chọn cho các broker MQTT.
Chương 3. TÍNH TỐN VÀ THIẾT KẾ
3.1 GIỚI THIỆU
Tổng quan yêu cầu đề tài: Thiết kế và thi công hệ thống điều khiển – giám sát ngôi nhà, xây dựng hệ thống điều khiển qua ứng dụng trên điện thoại Android, Web Server và công cụ hỗ trợ điều khiển bằng giọng nói. Lập trình lấy thơng tin thời tiết, nhiệt độ, độ ẩm từ Internet hiển thị lên màn hình oled. Cảnh báo khi có sự cố cháy, rị rỉ khí gas. Thiết lập bảo mật cửa vào 2 lớp và cảnh báo khi có người lạ cố tình xâm nhập vào nhà.
Giớ i thiê ̣u về phần cứng
Thiết bị đầu vào: Cảm biến nhiệt độ - độ ẩm DHT11, cảm biến khí gas, cảm
biến mưa, cảm biến ánh sáng, cảm biến chuyển động PIR, RFID, bàn phím ma trận 4x4, nú t nhấn cảm ứng.
Thiết bị đầu ra: động cơ servo, động cơ DC, đèn 12V, quạt 12V, LCD 16x2,
Oled, chuông báo.
Thiết bị điều khiển trung tâm: Arduino Mega. Module wifi: NodeMCU ESP8266.
Các chuẩn truyền dữ liệu: UART, SPI, I2C.
Thiết bị giao diện điều khiển: Web server, App Android, trợ lí ảo của Google 3.2 TÍNH TỐN VÀ THIẾT KẾ HỆ THỐNG