क्या MQTT प्रोटोकॉल BLE से अधिक सेंसर रीडिंग संचारित करने के लिए उपयुक्त है?


12

मान लें कि कई कमजोर सेंसर हैं (उदाहरण के लिए, Arduino स्तर के उपकरण) जो संचार के साधन के रूप में BLE पर निर्भर करते हैं और ये डिवाइस अधिक शक्तिशाली गेटवे (जैसे, रास्पबेरी पीआई उपकरणों के स्तर) से जुड़े हैं।

मैं जानना चाहूंगा कि क्या MQTT को उनके रीडिंग (छोटे, लगातार फटने वाले संदेशों) को प्रसारित करने के लिए एक उपयुक्त प्रोटोकॉल माना जाता है।

कई ब्लॉग / दस्तावेज़ MQTT को "IoT अनुप्रयोगों" के लिए उपयुक्त मानते हैं क्योंकि यह HTTP की तुलना में हल्का (er) भार है और शक्ति का संरक्षण करता है। हालाँकि, मेरी समझ से इसके लिए एक कनेक्शन को खुला रखने की आवश्यकता होती है जो कि BLE या अन्य संचार प्रोटोकॉल के मामले में IoT के लिए उपयुक्त नहीं है। बीएलई लंबे समय तक ऊर्जा आरक्षित रखने के लिए कनेक्शन को खुला नहीं रखता है। जाहिरा तौर पर, एमक्यूटीटी तब उपयुक्त होता है जब मैक के रूप में मैक परत प्रोटोकॉल का उपयोग किया जाता है। यह लगभग पहली जगह में MQTT का उपयोग करने के पीछे तर्क को तोड़ता है (यानी, यदि डिवाइस कंप्यूटर में वाईफाई जैसे प्रोटोकॉल को संभालता है तो उसे MQTT जैसे प्रोटोकॉल की आवश्यकता नहीं हो सकती है)। क्या आप इस तर्क में कोई दोष देखते हैं?

क्या उस उद्देश्य के लिए कोई वैकल्पिक अनुप्रयोग परत प्रोटोकॉल है? इन प्रकार के संदेशों की सबसे अधिक बार देखी जाने वाली संरचना क्या है (जैसे, कच्चे बाइनरी डेटा, JSON, XML) जब वे एक गेटवे के साथ संवाद करते हैं और जब वे एक सर्वर से सीधे संवाद करते हैं?


क्या मूल BLE तंत्र किसी विशेष कारण से अनुपयुक्त है?
शॉन हुलिएन

सीन का प्रश्न दो भागों में सबसे अच्छा विभाजित हो सकता है - ए) डिवाइस से तत्काल लिंक के लिए देशी बीएलई प्रोटोकॉल तंत्र काम करने योग्य हैं, और बी) डेटा को आखिरकार जाने की आवश्यकता कहां है? यदि भाग B का उत्तर BLE की सीमा से परे है, तो एक पुल (कम से कम रेडियो प्रारूपों के बीच लेकिन संभवतः प्रोटोकॉल के रूप में) की आवश्यकता है।
क्रिस स्ट्रैटन

क्या गेटवे कच्चे रीडिंग का उपभोग करता है, या बस उन्हें रिले करता है, और इस संदर्भ में यह गेटवे पर MQTT के लिए BLE मूल निवासी को पुल करने के बजाय सुरंग MQTT के अंत-अंत तक समझ में आ सकता है?
सीन होउलहिन

जवाबों:


14

MQTT को TCP / IP पर चलाना है (मुझे याद नहीं है कि क्या यह वास्तव में कल्पना में है या यदि इसे बनाने के लिए सिर्फ पर्याप्त धारणाएं हैं), लेकिन इसकी बहन प्रोटोकॉल MQTT-SN को लगभग किसी भी प्रोटोकॉल पर चलाया जा सकता है जो डेटा पास कर सकता है , मैंने यूडीपी और धारावाहिक में कार्यान्वयन देखा है।

यह कहने के बाद कि मुझे यकीन नहीं है कि आप BLE से अधिक रन करके क्या हासिल कर रहे हैं, BLE द्वारा निर्मित अभिलक्षण, अधिसूचना जैसी चीजों के साथ एक ही लाभ (यदि केवल 1 से 1 के आधार पर) की पेशकश करते हैं।

मुझे लगता है कि याद रखने में एक महत्वपूर्ण बात यह है कि "मैं" आईओटी में क्या है, इसका तात्पर्य कुछ बिंदु पर इंटरनेट तक पहुंच है (भले ही यह एक गेटवे डिवाइस या फोन हो)। उस बिंदु पर MQTT बहुत उपयोगी हो सकता है, लेकिन यह जरूरी नहीं है कि सभी तरह से (खून बह रहा) बढ़त हो।


सबसे पहले मुझे MQTT-SN के अस्तित्व के बारे में बताने के लिए धन्यवाद। साहित्य का अधिकांश हिस्सा कुछ भ्रामक है क्योंकि इसका तात्पर्य है कि MQTT अपने शक्ति-बचत गुणों के कारण ज्यादातर बढ़त उपकरणों को सशक्त बनाता है। उस मामले में कम बिजली की खपत एक वास्तविक तर्क के रूप में ज्यादा नहीं है क्योंकि उस प्रोफ़ाइल वाले उपकरणों में यह बस कोई फर्क नहीं पड़ेगा। उपकरणों को एक पूर्ण आईपी स्टैक लागू करना चाहिए और चूंकि MQTT एक खुला कनेक्शन रखता है, ऊर्जा-कुशल मैक परत प्रोटोकॉल एक विकल्प नहीं हैं।
18

1
MQTT HTTP की तरह कुछ की तुलना में बिजली की बचत करता है क्योंकि एक खुला टीसीपी कनेक्शन वास्तव में उस बिजली का उपभोग नहीं करता है जो आपके पहले से ही एक टीसीपी स्टैक को चलाने के लिए खुला रहता है, और जीवित पैकेट छोटे होते हैं। इसके अलावा प्रोटोकॉल ओवरहेड HTTP की तुलना में बहुत कम है क्योंकि एक HTTP हेडर एक MQTT पैकेट हेडर की तुलना में बहुत बड़ा है। बहुत सारे संगणना साहित्य एक सेलुलर डिवाइस जैसे फोन पर आधारित है
हार्डिलब

इसके अलावा, किनारा बदल गया है, यह जहां टीसीपी / आईपी बंद हो जाता था, ब्लीड और ZigBee (विशेष रूप से lpwan के साथ) और यहां तक ​​कि कम बिजली प्रोसेसर जैसी चीजें भी पतले उपकरणों में स्थानांतरित हो गई हैं
हार्डिलब

यह स्पष्ट है नहीं बस टीसीपी / आईपी; एकमात्र आवश्यकता यह है कि प्रोटोकॉल को "आदेशित, दोषरहित, द्वि-दिशात्मक कनेक्शन" प्रदान करना होगा। यह डॉक्टर के सार के दूसरे पैराग्राफ की तरह है। एसएन मौजूद है, क्योंकि यह आवश्यकता छोटे सिस्टमों, विशेष रूप से रेडियो-आधारित लोगों के लिए महत्वपूर्ण है। हो सकता है कि आपके द्वारा इसका मतलब "पर्याप्त अनुमान के लिए इसे बनाया जाए", लेकिन यह निश्चित रूप से टीसीपी / आईपी पर निर्भर नहीं है।
डेव न्यूटन

9

संभवतः, आप BLE प्रतिमानों से MQTT तक डेटा का एक सरल मानचित्रण करने से बेहतर होंगे, बजाय BLE पर MQTT को शाब्दिक रूप से भेजने के।

BLE आमतौर पर विशेषताओं के रूप में डेटा का आदान-प्रदान करता है । मूल्य परिवर्तन की खोज के लिए इनमें विभिन्न BLE- अद्वितीय तंत्र हैं जो आपको उपयोगी लग सकते हैं। लेकिन उनके पास अधिकतम 20 बाइट्स की डेटा लंबाई है

यह है संभव BLE से अधिक धारावाहिक डेटा स्ट्रीम करने के लिए, एक समय में 20 बाइट घूम रहा है। यह कभी-कभी एक आभासी सीरियल पोर्ट को लागू करने के लिए किया जाता है, और आप इसके माध्यम से पूर्ण MQTT को सुरंग कर सकते हैं।

लेकिन आप शायद अलग-अलग विषयों के डेटा को ले जाने के लिए BLE विशेषताओं के संग्रह का उपयोग करने के लिए बेहतर काम करेंगे, और एक पुल है जो एक MQTT विषय के लिए विशिष्ट पहचान को मैप करता है और MQTT पेलोड के मान को मैप करता है ।

BLE के पास निरंतर जुड़े सत्रों बनाम गैर-कनेक्टेड लोगों की अपनी भावना है। संभवतः आपको यह पता लगाना चाहिए कि आपके आवेदन के लिए BLE का क्या उपयोग सबसे अच्छा है, और फिर कनेक्शन बनाए रखने के लिए MQTT अर्थ में इसे मैप करें।

आपको ऐसा करने में सक्षम होना चाहिए या दोनों दिशाओं में: BLE-> MQTT और MQTT-> BLE


5
यदि आप एक MQTT 2 BLE पुल चाहते हैं तो आप मेरा github.com/hardillb/mqtt2ble
hardillb

उस लिंक के लिए धन्यवाद, मैं इसे अभी देख रहा हूं।
dr.doom
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.