IoT डिवाइस सेटिंग्स कॉन्फ़िगर करने के लिए प्रोटोकॉल

Question

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

हालाँकि, जब यह एक अंतिम सर्वर पर सेटिंग्स कॉन्फ़िगर करने के लिए एक केंद्रीय सर्वर की बात आती है, तो मुझे यकीन नहीं है कि मॉडल बहुत उपयुक्त है। सर्वर डिवाइस को एक कमांड भेजना चाहता है और प्रतिक्रिया की प्रतीक्षा करेगा (उदाहरण के लिए एक विशिष्ट सेटिंग पढ़ें, प्रतिक्रिया की प्रतीक्षा करें), जो वास्तव में एमक्यूटीटी के प्रकाशित-सदस्यता मॉडल के अनुरूप नहीं है।

मैं सोच रहा था कि क्या कोई मौजूदा प्रोटोकॉल है जो कमांड भेजने और प्राप्त करने और दूरस्थ उपकरणों को कॉन्फ़िगर करने की दिशा में सक्षम है?

Comments

क्या आप सुनिश्चित हैं कि MQTT ग्राहक को नियंत्रण चैनल की सदस्यता लेने की अनुमति नहीं देता है? मुझे लगता है कि उत्तरों की तलाश शुरू करने के लिए यह जगह है, लेकिन मैं एक उत्तर en.wikipedia.org/wiki/Representational_state_transfer

— Sean

मत भूलो, समापन बिंदु को चैनल शुरू करने की आवश्यकता है, इसलिए यह बिजली की खपत के नियंत्रण में है।

— शॉन हुलिएन

@SeanHoulihane आपके द्वारा बताए अनुसार कमांड / सेटिंग्स भेजने और प्राप्त करने के लिए MQTT का उपयोग करना निश्चित रूप से संभव है, लेकिन जिस तरह से मैं इसे देखता हूं, आदर्श रूप से आपको एक प्रोटोकॉल होना चाहिए जो "सत्र-आधारित" है, अर्थात आप सत्र बनाएँ, एक कमांड भेजें और उसी सत्र में एक प्रतिक्रिया प्राप्त करते हैं, इस प्रकार प्रतिक्रिया को मूल कमांड से आसानी से जोड़ते हैं। MQTT संदेश आधारित है, इसलिए संदेशों को एक-दूसरे के साथ लिंक करने के लिए कुछ भी नहीं है - यह आपको उस हिस्से को संभालने के लिए है। मैं सोच रहा था कि क्या कोई आसानी से उपलब्ध प्रोटोकॉल था जिसे मैं उस उद्देश्य के लिए उपयोग कर सकता था।

— अमृत ​​बेचित

en.wikipedia.org/wiki/OMA_LWM2M मुझे यकीन नहीं है कि कैसे, लेकिन क्लाउड क्लाइंट में कॉलबैक को ट्रिगर करने के लिए PUT या POST कॉल करने में सक्षम होने लगता है।

— शॉन होउलहिन

MQTTv5 में पहले संदेश की प्रतिक्रिया के रूप में संदेश को चिह्नित करने के लिए हेडर फ़ील्ड हैं।

— हार्डिल्ब

Answer 1

सीओएपी के लिए एक नौकरी की तरह लगता है :

HTTP की तरह, CoAP बेतहाशा सफल REST मॉडल पर आधारित है: सर्वर URL के तहत संसाधन उपलब्ध कराते हैं, और क्लाइंट इन संसाधनों का उपयोग GET, PUT, POST और DELETE जैसे तरीकों से करते हैं।

डेवलपर के दृष्टिकोण से, CoAP को HTTP बहुत पसंद है। एक सेंसर से एक मूल्य प्राप्त करना वेब एपीआई से एक मूल्य प्राप्त करने से बहुत अलग नहीं है।

यह स्पष्ट रूप से बहुत कम ओवरहेड के साथ लागू किया जा सकता है :

CoAP को माइक्रोकंट्रोलर्स पर काम करने के लिए डिज़ाइन किया गया है, जिसमें 10 KiB रैम और 100 KiB कोड स्पेस है

CoFC RFC 7252 में निर्दिष्ट है , और विभिन्न कार्यान्वयन हैं (जैसे C में )।

यह बहुत हद तक REST से प्रेरित है जैसा कि वेब एपीआई के लिए HTTP के साथ प्रयोग किया जाता है, इसलिए यदि आप उन लोगों से परिचित हैं, तो आप जल्दी से सीओएपी उठा लेंगे। यदि नहीं, तो आपको यह प्रस्तुति संदर्भ के लिए उपयोगी लग सकती है। यह विचार है कि प्रत्येक HTTP पद्धति का एक अर्थ अर्थ है, उदाहरण के GETलिए कुछ भी बदलने के बिना डिवाइस से जानकारी का अनुरोध करता है POST, PUTऔर DELETEडेटा को म्यूट करता है।

जैसा कि आप कहते हैं, प्रकाशित / सदस्यता मॉडल उस स्थिति के लिए काम नहीं करेगा जहां आपका डिवाइस केंद्रीय प्रणाली समन्वय के लिए 'सर्वर' के रूप में कार्य करता है (जो प्रत्येक डिवाइस के लिए क्लाइंट के रूप में कार्य करता है)। इसके बजाय, HTTP के समान एक मॉडल आदर्श है, सिवाय इसके कि HTTP में बहुत अधिक ओवरहेड है, जो कि CoAP में आता है।

Answer 2

मैं सोच रहा था कि क्या कोई मौजूदा प्रोटोकॉल है जो कमांड भेजने और प्राप्त करने और दूरस्थ उपकरणों को कॉन्फ़िगर करने की दिशा में सक्षम है?

हां, IoT में डिवाइस मैनेजमेंट के लिए बेहतर प्रोटोकॉल है। यह LwM2M है - यह MQTT और COAP, MQTT और HTTP के ऊपर की तुलना में बहुत अधिक कुशल है।

LwM2M एक अच्छी तरह से परिभाषित डेटा और डिवाइस प्रबंधन मॉडल के साथ आता है, विभिन्न प्रकार के रेडी-टू-यूज़ स्टैंडर्ड ऑब्जेक्ट्स (IPSO स्मार्ट ऑब्जेक्ट्स), कनेक्टिविटी मॉनिटरिंग, रिमोट डिवाइस एक्शन और संरचित FOTA और SOTA अपडेट पेश करता है, जबकि MQTT में ये फीचर्स पूरी तरह से हैं। विक्रेता और प्लेटफ़ॉर्म-विशिष्ट। इस प्रकार है कि MQTT के साथ, फर्मवेयर अपडेट या किसी अन्य प्रबंधन सुविधाओं को खरोंच से बनाया जाना चाहिए। इसके विपरीत, LwM2M अपने बुनियादी कार्यों में से एक के रूप में फर्मवेयर के उन्नयन की पेशकश करता है, इसलिए संचार के लिए किसी भी नए बिल्डिंग ब्लॉक का आविष्कार करने की आवश्यकता नहीं है।

यहां आपके पास MQTT बनाम LwM2M और पूरे क्रैश कोर्स की तुलना है ।