Apakah protokol MQTT sesuai untuk mentransmisikan pembacaan sensor melalui BLE?

Asumsikan bahwa ada banyak sensor lemah (misalnya, perangkat tingkat Arduino) yang mengandalkan BLE sebagai alat komunikasi dan bahwa perangkat ini terhubung ke gateway yang lebih kuat (misalnya, perangkat tingkat Raspberry pi).

Saya ingin tahu apakah MQTT dianggap sebagai protokol yang tepat untuk mentransmisikan bacaan mereka (pesan singkat dan sering meledak).

Sejumlah blog / dokumen menganggap MQTT sesuai untuk "aplikasi IoT" karena bobotnya ringan jika dibandingkan dengan HTTP dan menghemat daya. Namun, untuk pemahaman saya itu memerlukan koneksi tetap terbuka yang tidak terjadi dengan BLE atau protokol komunikasi lain yang sesuai untuk IoT. BLE tidak menjaga koneksi tetap terbuka untuk waktu yang lama untuk menghemat energi. Rupanya, MQTT sesuai ketika protokol lapisan MAC seperti WiFi digunakan. Ini hampir mematahkan alasan di balik penggunaan MQTT di tempat pertama (yaitu, jika perangkat yang secara komputatif menangani protokol seperti WiFi maka mungkin tidak memerlukan protokol seperti MQTT). Apakah Anda melihat cacat dalam logika ini?

Apakah ada protokol lapisan aplikasi alternatif untuk tujuan itu? Apa struktur yang paling sering terlihat dari jenis pesan ini (misalnya, data biner mentah, JSON, XML) ketika mereka berkomunikasi dengan gateway dan ketika mereka berkomunikasi dengan server secara langsung?

mqtt power-consumption bluetooth-low-energy

— dr.doom
sumber

Apakah mekanisme BLE asli tidak sesuai untuk alasan tertentu?

— Sean Houlihane

Pertanyaan Sean mungkin sebaiknya dibagi menjadi dua bagian - A) apakah mekanisme protokol BLE asli dapat diterapkan untuk tautan langsung dari perangkat, dan B) ke mana data akhirnya harus pergi? Jika jawaban untuk bagian B berada di luar jangkauan BLE, maka diperlukan jembatan (setidaknya antara format radio tetapi mungkin juga protokol).

— Chris Stratton

Apakah gateway mengkonsumsi bacaan mentah, atau hanya menyampaikannya, dan dalam konteks itu masuk akal untuk terowongan MQTT ujung ke ujung daripada menjembatani BLE asli ke MQTT di gateway?

— Sean Houlihane

Jawaban:

MQTT harus menjalankan lebih dari TCP / IP (Saya tidak ingat apakah itu benar-benar dalam spesifikasi atau jika asumsi yang dibuat cukup untuk membuatnya begitu) tetapi protokol saudara MQTT-SN dapat dijalankan melalui hampir semua protokol yang dapat mengirimkan data , Saya telah melihat implementasi di UDP dan serial.

Setelah mengatakan bahwa saya tidak yakin apa yang Anda peroleh dengan menjalankan lebih dari BLE, Karakteristik bawaan BLE menawarkan banyak manfaat yang sama (jika hanya berdasarkan 1 banding 1) dengan hal-hal seperti pemberitahuan.

Saya pikir salah satu hal penting yang perlu diingat adalah apa yang "saya" singkatan dari IOT, itu menyiratkan akses ke Internet di beberapa titik (bahkan jika itu adalah perangkat gateway atau telepon). Pada titik itu MQTT bisa sangat berguna, tetapi itu tidak selalu berarti semua jalan ke tepi (perdarahan).

— hardillb
sumber

Pertama-tama terima kasih telah memberi tahu saya tentang keberadaan MQTT-SN. Sebagian besar literatur agak menyesatkan karena menyiratkan bahwa MQTT memberdayakan perangkat tepi sebagian besar karena atribut hemat daya. Dalam hal pengurangan konsumsi daya bukan argumen yang nyata karena dalam perangkat dengan profil itu tidak masalah. Perangkat harus menerapkan tumpukan IP lengkap dan karena MQTT mempertahankan koneksi terbuka, protokol lapisan MAC yang hemat energi bukanlah pilihan.

— dr.doom

MQTT memang menghemat daya dibandingkan dengan sesuatu seperti HTTP karena koneksi TCP terbuka tidak benar-benar mengkonsumsi banyak daya untuk tetap terbuka setelah Anda sudah menjalankan tumpukan TCP, dan paket tetap hidup kecil. Juga overhead protokol jauh lebih rendah daripada HTTP karena header HTTP sangat besar dibandingkan dengan header paket MQTT. Banyak literatur komputasi didasarkan pada perangkat seluler misalnya telepon

— hardillb

Tepi juga telah bergerak, dulu tempat TCP / IP berhenti, hal-hal seperti ble dan ZigBee (terutama dengan lpwan) dan bahkan prosesor daya yang lebih rendah telah pindah ke perangkat yang lebih tipis lagi

— hardillb

Secara eksplisit bukan hanya TCP / IP; satu-satunya persyaratan adalah bahwa protokol harus menyediakan "koneksi bi-directional" yang dipesan, hilang, dan terhubung ". Ini seperti paragraf kedua dari abstrak dokumen. SN ada karena persyaratan itu memberatkan untuk sistem kecil, terutama yang berbasis radio. Mungkin itulah yang Anda maksudkan dengan "cukup banyak asumsi yang dibuat untuk membuatnya", tapi itu pasti tidak bergantung pada TCP / IP.

— Dave Newton

Boleh dibilang, Anda akan lebih baik melakukan pemetaan sederhana data dari paradigma BLE ke MQTT, daripada mencoba mengirim MQTT secara harfiah melalui BLE.

BLE umumnya bertukar data dalam bentuk karakteristik . Ini memiliki berbagai mekanisme unik BLE untuk menemukan perubahan nilai yang mungkin berguna bagi Anda. Tetapi mereka memiliki panjang data maksimum 20 byte .

Hal ini dimungkinkan untuk streaming data serial lebih BLE, bergerak 20 byte pada suatu waktu. Ini kadang-kadang dilakukan untuk mengimplementasikan port serial virtual, dan Anda bisa tunnel MQTT penuh melalui ini.

Tetapi Anda mungkin lebih baik menggunakan koleksi karakteristik BLE untuk membawa data berbagai topik, dan memiliki jembatan yang memetakan identitas karakteristik ke topik MQTT dan memetakan nilai ke muatan MQTT.

BLE memiliki pengertian sendiri tentang sesi yang terhubung yang sedang berlangsung vs yang tidak terhubung. Kemungkinan Anda harus mengetahui penggunaan BLE apa yang terbaik untuk aplikasi Anda, dan kemudian memetakan ini ke rasa MQTT menjaga koneksi.

Anda harus dapat melakukan ini di salah satu atau kedua arah: BLE-> MQTT dan MQTT-> BLE

— Chris Stratton
sumber

Jika Anda menginginkan jembatan MQTT 2 BLE, Anda dapat melihat milik saya github.com/hardillb/mqtt2ble

— hardillb

Terima kasih untuk tautan itu, saya melihatnya sekarang.

— dr.doom