Giao thức MQTT có thích hợp để truyền các bài đọc cảm biến qua BLE không?

Giả sử rằng có nhiều cảm biến yếu (ví dụ: các thiết bị cấp Arduino) dựa vào BLE làm phương tiện liên lạc và các thiết bị này được kết nối với một cổng mạnh hơn (ví dụ: cấp độ Raspberry pi của thiết bị).

Tôi muốn biết nếu MQTT được coi là một giao thức thích hợp để truyền các bài đọc của họ (tin nhắn bùng nổ ngắn, thường xuyên).

Một số blog / tài liệu coi MQTT phù hợp với "ứng dụng IoT" vì nó nhẹ (er) khi so sánh với HTTP và bảo toàn sức mạnh. Tuy nhiên, theo hiểu biết của tôi, nó đòi hỏi phải có kết nối mở, điều này không xảy ra với BLE hoặc các giao thức truyền thông khác phù hợp với IoT. BLE không duy trì kết nối mở trong thời gian dài để dự trữ năng lượng. Rõ ràng, MQTT thích hợp khi sử dụng giao thức lớp MAC như WiFi. Điều này gần như phá vỡ lý do đằng sau việc sử dụng MQTT ở vị trí đầu tiên (nghĩa là, nếu thiết bị xử lý một cách tính toán một giao thức như WiFi thì nó có thể không cần một giao thức như MQTT). Bạn có thấy một lỗ hổng trong logic này không?

Có bất kỳ giao thức lớp ứng dụng thay thế cho mục đích đó? Cấu trúc thường thấy nhất của các loại thông báo này (ví dụ: dữ liệu nhị phân thô, JSON, XML) khi chúng giao tiếp với một cổng và khi chúng giao tiếp trực tiếp với máy chủ?

mqtt power-consumption bluetooth-low-energy

— dr.doom
nguồn

Là cơ chế BLE bản địa không phù hợp cho bất kỳ lý do cụ thể?

— Sean Houlihane

Câu hỏi của Sean có thể được chia thành hai phần tốt nhất - A) là các cơ chế giao thức BLE gốc có thể thực hiện được cho liên kết ngay lập tức từ thiết bị và B) cuối cùng dữ liệu cần phải đi đâu? Nếu câu trả lời cho phần B nằm ngoài phạm vi của BLE, thì cần một cây cầu (ít nhất là giữa các định dạng radio nhưng cũng có thể là các giao thức).

— Chris Stratton

Liệu cổng có tiêu thụ các bài đọc thô, hoặc chỉ đơn giản là chuyển tiếp chúng, và trong bối cảnh đó, nó có thể có ý nghĩa đối với đường hầm MQTT từ đầu đến cuối chứ không phải là cầu nối BLE có nguồn gốc từ MQTT tại cổng không?

— Sean Houlihane

Câu trả lời:

MQTT có để chạy trên TCP / IP (Tôi không thể nhớ nếu nó thực sự trong đặc tả hoặc nếu chỉ giả định đủ được thực hiện để làm cho nó như vậy) nhưng giao thức chị nó MQTT-SN có thể chạy trên hầu như bất kỳ giao thức có thể truyền dữ liệu , Tôi đã thấy các triển khai trong UDP và nối tiếp.

Phải nói rằng tôi không chắc chắn những gì bạn đạt được bằng cách chạy trên BLE, Đặc điểm được xây dựng của BLE mang lại nhiều lợi ích tương tự (nếu chỉ trên cơ sở 1 đến 1) với những thứ như thông báo.

Tôi nghĩ một trong những điều quan trọng cần nhớ là chữ "I" là viết tắt của IoT, nó ngụ ý truy cập Internet vào một lúc nào đó (ngay cả khi đó là thiết bị cổng hoặc điện thoại). Tại thời điểm đó MQTT có thể rất hữu ích, nhưng nó không nhất thiết có nghĩa là tất cả các cách để cạnh (chảy máu).

— hardillb
nguồn

Trước hết cảm ơn vì đã cho tôi biết về sự tồn tại của MQTT-SN. Phần lớn các tài liệu có phần sai lệch bởi vì nó ngụ ý rằng MQTT trao quyền cho các thiết bị cạnh chủ yếu là do các thuộc tính tiết kiệm năng lượng của nó. Trong trường hợp đó, mức tiêu thụ điện năng giảm không phải là một cuộc tranh cãi thực sự bởi vì trong các thiết bị có cấu hình đó, điều đó chỉ đơn giản là không thành vấn đề. Các thiết bị nên thực hiện một ngăn xếp IP đầy đủ và vì MQTT duy trì kết nối mở, các giao thức lớp MAC tiết kiệm năng lượng không phải là một tùy chọn.

— dr.doom

MQTT tiết kiệm năng lượng so với thứ gì đó như HTTP vì kết nối TCP mở thực sự không tiêu tốn nhiều năng lượng đó để duy trì mở khi bạn đã chạy ngăn xếp TCP và các gói tin còn sống rất nhỏ. Ngoài ra, chi phí giao thức thấp hơn nhiều so với HTTP vì tiêu đề HTTP rất lớn so với tiêu đề gói MQTT. Rất nhiều tài liệu tính toán dựa trên một thiết bị di động, ví dụ như điện thoại

— hardillb

Ngoài ra, cạnh đã di chuyển, nó từng là nơi TCP / IP dừng lại, những thứ như ble và ZigBee (đặc biệt là với lpwan) và thậm chí các bộ xử lý năng lượng thấp hơn đã chuyển sang các thiết bị thậm chí mỏng hơn

— hardillb

Đó rõ ràng không chỉ là TCP / IP; yêu cầu duy nhất là giao thức phải cung cấp "các kết nối hai chiều, không mất trật tự". Nó giống như đoạn thứ hai của tài liệu trừu tượng. SN tồn tại bởi vì yêu cầu đó rất phù hợp với các hệ thống nhỏ, đặc biệt là các hệ thống dựa trên radio. Có thể đó là những gì bạn muốn nói bởi "đủ các giả định được thực hiện để biến nó thành như vậy", nhưng chắc chắn là nó không phụ thuộc vào TCP / IP.

— Dave Newton

Có thể cho rằng, tốt hơn hết là bạn nên lập bản đồ dữ liệu đơn giản từ mô hình BLE sang MQTT, thay vì cố gắng gửi MQTT theo nghĩa đen qua BLE.

BLE thường trao đổi dữ liệu dưới dạng đặc điểm . Chúng có các cơ chế độc đáo BLE khác nhau để khám phá thay đổi giá trị mà bạn có thể thấy hữu ích. Nhưng chúng có độ dài dữ liệu tối đa là 20 byte .

Có thể truyền dữ liệu nối tiếp qua BLE, di chuyển 20 byte mỗi lần. Điều này đôi khi được thực hiện để thực hiện một cổng nối tiếp ảo và bạn có thể tạo đường hầm MQTT đầy đủ thông qua việc này.

Nhưng có lẽ bạn nên sử dụng một tập hợp các đặc điểm BLE để mang dữ liệu của các chủ đề khác nhau và có một cây cầu ánh xạ danh tính đặc trưng cho một chủ đề MQTT và ánh xạ giá trị vào tải trọng MQTT.

BLE có ý thức riêng về các phiên được kết nối liên tục so với các phiên không kết nối. Có khả năng bạn nên tìm ra cách sử dụng BLE nào là tốt nhất cho ứng dụng của bạn, và sau đó ánh xạ nó tới ý nghĩa duy trì kết nối MQTT.

Bạn sẽ có thể thực hiện việc này theo một hoặc cả hai hướng: BLE-> MQTT và MQTT-> BLE

— Chris Stratton
nguồn

Nếu bạn muốn một cây cầu MQTT 2 BLE, bạn có thể xem của tôi github.com/hardillb/mqtt2ble

— hardillb

Cảm ơn vì liên kết đó tôi đang xem nó ngay bây giờ.

— dr.doom