MQTT và khái niệm cơ bản

mqtt
82 / 100

1- Broker và Client:

Client: Để thực thi 1 dự án IoT với MQTT, đầu tiên ta cần có các Client, Client là các thiết bị của chúng ta: phần điều khiển có PLC, Arduino, Rasp, các màn hình HMI…. phần hiển thị điều khiển giám sát như máy tính, điện thoại… Client rất đa dạng và được hộ trợ bởi các thư viện MQTT client được code cũng rất đa dang như dùng C, C++, java, ios, .net… Một mạng lưới IoT sẻ rất đa dạng và nhiều Client, các Client trong 1 hệ MQTT không giao tiếp trực tiếp nhau mà giao tiếp nhau thông qua 1 Broker theo cơ chế publishers và subscribers

Broker: Broker đứng ở giữa với vai trò là 1 Server tiếp nhận tất cả các publishers/subscribers từ các Client gửi tới chứa nội dung: Topic và Message. Các Clients thông qua Broker để nhận Topic mà Client đó đăng ký Subciber.

2- Các thông số

2.1 Kết nối:

Giao thức MQTT dựa trên Control Protocol (TCP) và Internet Protocol (IP). Do đó các Client của chúng ta cần phải hỗ trợ TCP/IP thì mới làm được.

Phương thức truyền thì như trên ta cũng đã hiểu qua: Client gửi 1 Topic chứa Message tới Broker, Broker sẻ phát message tới Client có subscriber topic khớp.

Khi thiết lập kết nối tới Broker, client gửi 1 Message CONNECT như sau:

  • ClientId: quy định Id cho từng Client, mỗi client phải là 1 ID duy nhất và không đụng hàng trong 1 hệ MQTT, để giúp Broker nhận diện Client chính xác.

  • Clean Session: nếu CleanSession=false thì Broker sẻ lưu trữ các Topic và Message cho Client (chỉ khi cấp độ QoS cài = 1 hoặc 2) để đảm bảo dữ liệu phải được truyền nhận tới đích trong tất cả các phiên, khi QoS=0 đồng nghĩa với việc Client xác nhận dữ liệu gửi nhận mất cũng được trong tất cả các phiên. Còn CleanSession=true thì ngược lại Broker sẻ không lưu trữ gì lại cho Client cả, các phiên truyền nhận sẻ tự động xóa.
  • Username/Password: việc truyền nhận thông tin user/pass qua MQTT cần được mã hóa với TLS hay dùng SSL certificate để nhận dạng Clients. Hầu hết thư viện ở các Client hỗ trợ mã hóa TLS và ta nhớ Active lên để sử dụng cho an toàn.

  • Will Message: cũng có Topic và Message, tuy nhiên Will được sử dụng chỉ để phát hiện trạng thái của Client: kết nối hay mất kết nối. Khi kết nối được thiết lập với Broker, Client gửi Will Message lên Broker và Broker xác nhận đã kết nối, khi bị mất kết nối Broker sẻ xác nhận mất kết nối và gửi Will Message tới các Client khác đang chờ. Tức là Broker giữ WillMessage của 1 client và chỉ phát đi khi client đó mất kết nối.
  • KeepAlive: Khi kết nối được thiết lập với Broker, có thể pub/sub không có liên tục, để detect chính xác việc kết nối giữa Client và Broker, client luôn gửi tín hiệu PINGREQ tới Broker, Broker sẻ nhận và gửi lại Client PINGRESP, hay nói cách khác nó là 1 WatchDog. Điều này giúp Broker xác nhận chính xác Client còn kết nối hay không, nếu tín hiệu Ping qua lại này gián đoạn, quá thời gian KeepAlive thì Broker thông báo mất kết nối với Client.

2.2 Publish:

Đóng gói và gửi dữ liệu, dữ liệu Publish có thể là Tex, xml, json, binary. Dữ liệu Publish đóng gói như sau:

  • Packet identifier: thư viện tự tạo khi QoS>0, vì QoS=0 thì mặc định PaketID=0.
  • Topics: cho phép dài tuy nhiên ngắn thì là ít nhất 1 ký tự, cho phép khoảng space, dùng dấu “/” để phân cấp trong topic, ví dụ: Ho boi/Nhietdo/Nhiet do 1… Topic sẻ phân biệt chữ thường và chữ hoa, ví dụ Hoboi/nhietdo và hoboi/nhietdo là 2 topic khác nhau hoàn toàn do khác chữ H viết hoa.
  • Wildcards: tính năng này giúp Client subscribe topic đa dạng dưới 2 cấp độ,

    • cấp độ đơn là chèn vào dấu +: ví dụ: Hoboi/+/nhietdo thì Client sẻ nhận subscribe từ bất cứ Topic nào giống vậy, miễn là chỉ khác ở chỗ dấu + như: Hoboi/ho1/nhietdo hay Hoboi/ho2/nhietdo, còn Hoboi/ho1/ho2/nhietdo thì lại không được

    • cấp độ đa dạng hơn: chèn vào dấu #, ví dụ Hoboi/#/nhietdo thì Client sẻ nhận sub từ tất cả topic diện rộng hơn ví dụ: Hoboi/ho1/nhietdo, Hoboi/ho1/ho2/nhietdo, Hoboi/ho1/ho2/ho3/nhietdo   ….
    • Tuy nhiên nhiều khi bạn muốn tạo topic có chữ # có thể dẫn tới nhận nhầm của 1 vài client, để vô hiệu tính năng của # ở chế độ widcards ta chèn vào trước topic chữ $, ví dụ $Hoboi/#/nhietdo, khi đó dấu # không còn ý nghĩa như ở trên nữa.
  • QoS: Quality of Service, 
    • Q0S=0: dữ liệu Client publish lên Broker, Broker nhận được hay không Client không quan tâm
    • Q0S=1: dữ liệu Client publish lên Broker, Broker nhận được và gửi 1 PUBACK packet tới Client xác nhận là đã nhận để Client biết
    • Q0S=2: dữ liệu Client publish lên Broker, Broker nhận được và gửi 1 PUBACK packet tới Client xác nhận là đã nhận để Client biết, Client nhận được PUBACK thì gửi lại cho Broker 1 gói Pubcomp xác nhận với Broker là tao đã nhận được PUBACK nhé.
    • PUBACK, Pubcomp đều chứa nội dung là PacketId, tức là Id của Topic đang được Publish, nếu Q0S=0 thì PacketId=0
  • Retain Flag: giúp giữ lại Message của 1 topic có tag này set true. Và tất nhiên nó là Message cuối. Việc này giúp client nào muốn Sub topic đó sẻ có ngay kết quả cuối mà không cần chờ cho tới khi có topic mới pub lên.

2.3 Subscribe: 

Sub khá đơn giản, chỉ chứa PacketID và Topic mà client muốn Sub. Client gửi subdcibe tới Broker để lấy topic mình muốn về khi Broker có. Broker gửi lại 1 SUBACK để xác nhận với Client. SUBACK  chứa PacketId và Returncode lưu mã QoS, nếu Returncode =128 là lỗi.

 

Tham khảo: hivemq.com

 

Thư viện MQTT cho S7 1200, S7 1500:

Thư viện MQTT client cho S7 1200, S7 1500

Leave a Reply

Your email address will not be published. Required fields are marked *

Exit mobile version