Lorawan-stack: अंतिम उपकरण बनाने के लिए विज़ार्ड का उपयोग करें

डिवाइस फॉर्म के वर्तमान कार्यान्वयन के साथ मुख्य समस्या यह है कि सब कुछ एक साथ युग्मित है। इसकी वजह से

1. जटिल और लंबी सत्यापन स्कीमा
2. स्टैक कॉन्फ़िगरेशन के आधार पर कुछ फ़ील्ड को अक्षम करने का कोई सीधा तरीका नहीं है
3. चयनित मानों के अनुसार प्रपत्र फ़ील्ड/फ़ील्ड शीर्षक बदलने का कोई सीधा तरीका नहीं है
4. बैच निर्माण/अद्यतन/हटाने के साथ-साथ निर्माण रोलबैक तर्क के लिए जेएस एसडीके में अनावश्यक जटिलता

मैं डिवाइस फॉर्म को मल्टी-स्टेप फॉर्म के रूप में लागू करने का प्रस्ताव करता हूं। यह कुछ इस तरह दिख सकता है:

ऐसा दृष्टिकोण ऊपर वर्णित सभी मुद्दों को संबोधित करता है:

1. एक जटिल स्कीमा के बजाय हम प्रत्येक चरण के लिए एक छोटे को परिभाषित करते हैं।
2. यदि स्टैक में एक निश्चित जिम्मेदार घटक उपलब्ध नहीं है, तो बस पूरे चरण को अक्षम करें। इसके अलावा, हम उपयोगकर्ता को इसके बारे में विवरण/अधिसूचना के माध्यम से सूचित कर सकते हैं।
3. पहले सबमिट किए गए मानों के आधार पर प्रत्येक चरण को अपनाएं। उदाहरण के लिए, लोरावन संस्करण 1.0.x के लिए Join EUI लेबल को App EUI में बदलें।
4. बैच अनुरोधों की कोई ज़रूरत नहीं है। उपयोगकर्ता विभिन्न घटकों में डिवाइस बनाने के लिए जिम्मेदार हो जाता है। हालाँकि हम सुविधा के लिए बैचेड विलोपन रखना चाह सकते हैं।

संपादन उपकरणों को समझौते के ढेर के रूप में लागू किया जा सकता है:

जहां प्रत्येक अकॉर्डियन एक स्टैंडअलोन फॉर्म के साथ फैलता है।

डिवाइस फॉर्म के अलावा हम विजार्ड का उपयोग एप्लिकेशन फॉर्म के लिए भी कर सकते हैं:

1. is . में एप्लिकेशन बनाएं
2. एप्लिकेशन को as . से लिंक करें

cc @kschiffer @johanstokking @htdvisser

मेरे लिए अच्छा लगता है, खासकर अगर हम एक चरण में घटकों के लिए फ़ील्ड को एक साथ समूहित कर सकते हैं। इस तरह, जब कोई घटक उपलब्ध नहीं होता है, तो हम केवल चरणों को छोड़/अक्षम कर सकते हैं।

संदर्भ https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 भी; भले ही JS उपलब्ध हो, उपयोगकर्ता JS फ़ील्ड को छोड़ सकता है।

मैं इस तरह के आरेख के साथ आया:

हर नोड एक कदम है

• बिंदीदार रूपरेखा वाले चरण फॉर्म जमा नहीं करते हैं, लेकिन इसे अगले चरणों के लिए स्थानीय स्थिति में रखते हैं।
• अन्य सबमिट करने पर सर्वर को अनुरोध भेजते हैं।

यह जटिल दिखता है, लेकिन वर्तमान कार्यान्वयन में सत्यापन/सबमिशन/फील्ड मास्क पीढ़ी/आदि के संबंध में और भी बड़ा राज्य स्थान है।

चर्चा शुरू करने के लिए एक प्रारंभिक प्रस्ताव के रूप में आरेख पर विचार करें।

मुझे लगता है कि यह एक अच्छी शुरुआत है।

• हो सकता है कि फ्लो बेहतर होगा अगर ज्वाइन सर्वर पहले आए।
• एक महत्वपूर्ण चीज जिस पर हमने वास्तव में अभी तक कोई प्रगति नहीं की है, वह है डिवाइस रिपोजिटरी #263 में डिवाइस टेम्प्लेट से फ़ील्ड को पहले से भरना। मुझे लगता है कि यह वास्तव में उत्पादन परिनियोजन की प्रक्रिया को सरल बना सकता है।

और कुछ छोटी चीजें:

• ABP उपकरणों के लिए DevEUI वर्जित नहीं है (इसे वैकल्पिक रूप से सेट किया जा सकता है)
• लोरावन 1.0.x उपकरणों में NwkKey नहीं है, केवल एक AppKey है
• FNwkSIntKey को NwkSKey कहा जाता है (उपयोगकर्ता की ओर)
• एप्लिकेशन सर्वर को NwkKey या AppKey . नहीं मिलता है

हाँ, बढ़िया शुरुआत।

• हो सकता है कि फ्लो बेहतर होगा अगर ज्वाइन सर्वर पहले आए।

मैं इससे सहमत हु। यदि सक्रियण मोड OTAA है और क्लस्टर JS सक्षम है, तो JS पृष्ठ पर उपयोगकर्ताओं को रूट कुंजियों को दर्ज करने और उन्हें क्लस्टर JS पर संग्रहीत करने का विकल्प मिलता है। (यदि वे इसे अक्षम करते हैं, तो NS JS लुकअप का उपयोग करता है, ठीक उसी तरह जब क्लस्टर में कोई JS सक्षम नहीं होता है)

• "सक्रियण मोड" पेलोड में है - आपके आरेख में यह वास्तव में 2 फ़ील्ड - multicast bool और supports_join bool से मेल खाता है। 3 संभावित विकल्प हैं, क्योंकि multicast && supports_join मान्य नहीं है।
• frequency_plan -> frequency_plan_id

• resets_f_cnt वैकल्पिक है, डिफ़ॉल्ट रूप से false ।

• FNwkSIntKey को केवल <1.1 . के लिए NwkKey के रूप में प्रस्तुत किया जाना चाहिए

• >= 1.1 . के लिए ABP NS सेटिंग में FNwkSIntKey गुम है
• multicast उपकरणों को केवल AppSKey की आवश्यकता है - NS को काम करने के लिए multicast उपकरणों के लिए किसी कुंजी की आवश्यकता नहीं है, केवल AS

@htdvisser

हो सकता है कि फ्लो बेहतर होगा अगर ज्वाइन सर्वर पहले आए।

क्यों?

एक महत्वपूर्ण चीज जिस पर हमने वास्तव में अभी तक कोई प्रगति नहीं की है, वह है डिवाइस रिपोजिटरी #263 में डिवाइस टेम्प्लेट से फ़ील्ड को पहले से भरना। मुझे लगता है कि यह वास्तव में उत्पादन परिनियोजन की प्रक्रिया को सरल बना सकता है।

मेरे लिए यह इस मुद्दे के दायरे से बाहर लगता है

ABP उपकरणों के लिए एक DevEUI निषिद्ध नहीं है (इसे वैकल्पिक रूप से सेट किया जा सकता है)

क्या हम इसे एबीपी उपकरणों के लिए भी सेट करना चाहते हैं? मैं कहूंगा कि हमारे पास जितने कम क्षेत्र होंगे, उतना अच्छा होगा। हालाँकि, इसकी आवश्यकता है हम इसे जोड़ सकते हैं।

FNwkSIntKey को NwkSKey कहा जाता है (उपयोगकर्ता की ओर)

तो 1.0.x और 1.1.x दोनों के लिए लेबल NwkSKey होना चाहिए? यहाँ हमारे पास कंसोल में एटीएम है:

• LoRaWAN 1.0.x उपकरणों में NwkKey नहीं है, केवल एक AppKey है
• एप्लिकेशन सर्वर को NwkKey या AppKey नहीं मिलता है

फिक्स्ड

@johanstokking

यदि सक्रियण मोड OTAA है और क्लस्टर JS सक्षम है, तो JS पृष्ठ पर उपयोगकर्ताओं को रूट कुंजियों को दर्ज करने और उन्हें क्लस्टर JS पर संग्रहीत करने का विकल्प मिलता है। (यदि वे इसे अक्षम करते हैं, तो NS JS लुकअप का उपयोग करता है, ठीक उसी तरह जब क्लस्टर में कोई JS सक्षम नहीं होता है)।

तो यह सिर्फ उपयोगकर्ताओं को सर्वर सबमिशन चरण में शामिल होने की अनुमति देने की बात है? जेएस के लिए बिल्कुल कोई अनुरोध नहीं?

https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 के संबंध में, क्या आप यह भी निर्दिष्ट कर सकते हैं कि ये फ़ील्ड आरेख में कहां हैं?

@rvolosatovs

सक्रियण मोड" पेलोड में है - आपके आरेख में यह वास्तव में 2 फ़ील्ड से मेल खाता है - मल्टीकास्ट बूल और सपोर्ट_जॉइन बूल। 3 संभावित विकल्प हैं, क्योंकि मल्टीकास्ट && सपोर्ट_जॉइन मान्य नहीं है।

केवल स्पष्ट करने हेतु:

1. supports_join=true - ओटीएएए
2. supports_join=false - एबीपी
3. multicast=true && **no** supports_join - मल्टीकास्ट
   क्या ये सही है?

resets_f_cnt वैकल्पिक है, डिफ़ॉल्ट रूप से गलत है।

मुझे लगता है कि इसे उपयोगकर्ताओं को दिखाना अभी भी ठीक है। क्या उपयोगकर्ताओं को इसे मल्टीकास्ट डिवाइस के लिए सेट करने की अनुमति देनी चाहिए?

FNwkSIntKey को केवल <1.1 . के लिए NwkKey के रूप में प्रस्तुत किया जाना चाहिए

आपका मतलब NwkSKey है?

फ़्रीक्वेंसी_प्लान -> फ़्रीक्वेंसी_प्लान_आईडी
FNwkSIntKey >= 1.1 . के लिए ABP NS सेटिंग्स में अनुपलब्ध है

फिक्स्ड

अद्यतन आरेख:

@htdvisser

हो सकता है कि फ्लो बेहतर होगा अगर ज्वाइन सर्वर पहले आए।

क्यों?

हाँ, मैं इस पर वापस आ रहा हूँ; मुझे लगता है कि कुंजी दर्ज करने से पहले मैक संस्करण दर्ज करना अधिक समझ में आता है। इसलिए मैं वर्तमान प्रवाह का समर्थन कर रहा हूं। यदि MAC संस्करण दर्ज किया गया है (जब NS सक्षम है), तो हमें NwkKey के लिए पूछने की आवश्यकता नहीं है क्योंकि यह 1.1.x है।

एक महत्वपूर्ण चीज जिस पर हमने वास्तव में अभी तक कोई प्रगति नहीं की है, वह है डिवाइस रिपोजिटरी #263 में डिवाइस टेम्प्लेट से फ़ील्ड को पहले से भरना। मुझे लगता है कि यह वास्तव में उत्पादन परिनियोजन की प्रक्रिया को सरल बना सकता है।

मेरे लिए यह इस मुद्दे के दायरे से बाहर लगता है

यह वास्तव में दायरे से बाहर है।

ABP उपकरणों के लिए एक DevEUI निषिद्ध नहीं है (इसे वैकल्पिक रूप से सेट किया जा सकता है)

क्या हम इसे एबीपी उपकरणों के लिए भी सेट करना चाहते हैं? मैं कहूंगा कि हमारे पास जितने कम क्षेत्र होंगे, उतना अच्छा होगा। हालाँकि, इसकी आवश्यकता है हम इसे जोड़ सकते हैं।

हां, हम वैकल्पिक रूप से इसके लिए पूछना चाहते हैं। हमारे पास अंतिम उपकरणों के बारे में जितनी अधिक पहचान जानकारी होगी, उतना ही बेहतर होगा। स्टेटफुल पैसिव रोमिंग में भी इसकी आवश्यकता होती है। इसका कारण यह है कि हम उपयोगकर्ताओं को DevEUI में प्रवेश करने के लिए बाध्य नहीं करते हैं, क्योंकि यदि कोई DevEUI नहीं है, तो हम नहीं चाहते कि उपयोगकर्ता फर्जी मान दर्ज करें।

FNwkSIntKey को NwkSKey कहा जाता है (उपयोगकर्ता की ओर)

तो 1.0.x और 1.1.x दोनों के लिए लेबल NwkSKey होना चाहिए? यहाँ हमारे पास कंसोल में एटीएम है:

यह 1.0.x के लिए NwkSKey और 1.1.x के लिए FNwkSIntKey है।

यदि सक्रियण मोड OTAA है और क्लस्टर JS सक्षम है, तो JS पृष्ठ पर उपयोगकर्ताओं को रूट कुंजियों को दर्ज करने और उन्हें क्लस्टर JS पर संग्रहीत करने का विकल्प मिलता है। (यदि वे इसे अक्षम करते हैं, तो NS JS लुकअप का उपयोग करता है, ठीक उसी तरह जब क्लस्टर में कोई JS सक्षम नहीं होता है)।

तो यह सिर्फ उपयोगकर्ताओं को सर्वर सबमिशन चरण में शामिल होने की अनुमति देने की बात है? जेएस के लिए बिल्कुल कोई अनुरोध नहीं?

वास्तव में।

एक उदाहरण सेमटेक के मॉडेम की विशेषता वाला एक उपकरण है जो सेमटेक जॉइन सर्वर का उपयोग करता है। हमें उस मामले में केवल EUI को जानने की आवश्यकता है।

#1134 के संबंध में, क्या आप यह भी निर्दिष्ट कर सकते हैं कि ये फ़ील्ड आरेख में कहाँ हैं?

वे जेएस चरण में हैं; जेएस जाने के लिए इन क्षेत्रों, यदि जेएस क्लस्टर में सक्षम है और यदि उपयोगकर्ता जेएस पर उपकरणों का प्रावधान करना चाहता है।

ये फ़ील्ड वैकल्पिक हैं।

केवल स्पष्ट करने हेतु:

1. supports_join=true - ओटीएएए
2. supports_join=false - एबीपी
3. multicast=true && **no** supports_join - मल्टीकास्ट
   क्या ये सही है?

कठोरता से:

1. ओटीएए: supports_join
2. एबीपी: !supports_join && !multicast
3. मल्टीकास्ट: multicast

अमान्य है supports_join && multicast , लेकिन यह NS पर मान्य है (या होना चाहिए)।

resets_f_cnt वैकल्पिक है, डिफ़ॉल्ट रूप से गलत है।

मुझे लगता है कि इसे उपयोगकर्ताओं को दिखाना अभी भी ठीक है। क्या उपयोगकर्ताओं को इसे मल्टीकास्ट डिवाइस के लिए सेट करने की अनुमति देनी चाहिए?

नहीं, यह मल्टीकास्ट के लिए नहीं है। resets_f_cnt अपलिंक को संदर्भित करता है, लेकिन मल्टीकास्ट में अपलिंक नहीं है।

FNwkSIntKey को केवल <1.1 . के लिए NwkKey के रूप में प्रस्तुत किया जाना चाहिए

आपका मतलब NwkSKey है?

वास्तव में NwkSKey होना चाहिए।

@bafonins कृपया @johanstokking का उत्तर देखें।
multicast के संबंध में - डिवाइस का पता भी आवश्यक है

• https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 से जोड़े गए फ़ील्ड
• abp/मल्टीकास्ट डिवाइस में DevEUI जोड़ा गया
• मल्टीकास्ट डिवाइस में Device Address जोड़ा गया
  

डिवाइस पता अभी भी multicast डिवाइस नेटवर्क सर्वर सेटिंग्स से गायब है

मल्टीकास्ट डिवाइस से डिवाइस का पता अभी भी गायब है नेटवर्क सर्वर सेटिंग्स

अपडेट किया गया

मल्टीकास्ट 1.0.x और 1.1.x हो सकता है। सत्र की जानकारी दर्ज करना ( DevAddr और कुंजियाँ) मल्टीकास्ट के लिए एबीपी के समान ही है।

इसके अलावा resets_join_nonces जेएस में 1.1.x . के साथ सेट किया जा सकता है

डिवाइस निर्माण को विभाजित करना निश्चित रूप से आवश्यक है और उपयोगकर्ता के लिए जटिलता को कम करते हुए प्रवाह और कार्यान्वयन को बैकएंड की आवश्यकताओं के करीब लाने का एक अच्छा तरीका है।

कुछ विचार और चुनौतियाँ जो मुझे दिखाई देती हैं:

• हमें पूरे प्रवाह को रद्द करने के लिए कार्यक्षमता जोड़नी चाहिए, जिसके परिणामस्वरूप जो भी रजिस्ट्री प्रविष्टियाँ पहले ही बनाई जा चुकी हैं, उन्हें हटा दिया जाएगा।
  
  
  
  • इसी तरह, पिछले चरण पर जाने के लिए फ़ॉर्म को "अपडेट मोड" में रखना होगा (आईएस को छोड़कर, यह अपेक्षाकृत आसान होना चाहिए क्योंकि एंडपॉइंट समान हैं)
  
  
• एक समस्या जो मैं देख रहा हूं वह यह है कि एप्लिकेशन सर्वर चरण बहुत उथला है (क्या यह बाद में बदल जाएगा?) और पेलोड प्रारूप विकल्प जोड़ना वास्तव में डिवाइस बनाते समय उपयोगकर्ता की जरूरतों के अनुरूप नहीं है।
  
  
  
  • एक समाधान एएस और जेएस चरण को मर्ज करना हो सकता है, क्योंकि दोनों बहुत सीधे हैं और अन्योन्याश्रित नहीं हैं। मुझे एहसास है कि यह घटक द्वारा अलगाव के खिलाफ जाता है लेकिन मुझे लगता है कि यह पूरे प्रवाह को उचित अमूर्तता के साथ सरल बना देगा। विशेष रूप से यह देखते हुए कि हम चरणों के भीतर संबंधित स्टैक घटकों से किसी भी कनेक्शन का संचार नहीं करते हैं।
  
  
• स्टैक कॉन्फ़िगरेशन के आधार पर हम एक विज़ार्ड के साथ समाप्त हो सकते हैं जिसमें केवल एक या दो चरण होते हैं, जो जादूगरों के लिए एक विरोधी पैटर्न है।
  
  
  
  • केवल एक चरण के मामले में, हम केवल विज़ार्ड पहलू को छुपा/हटा सकते हैं
  
  
  • दो चरणों के लिए, मुझे लगता है कि हमें इस मुद्दे के साथ रहना होगा ‍♂
  
  
• यह माना जाना चाहिए कि विज़ार्ड समाधान उपयोगकर्ता की कहानी के लिए _समय-से-पूर्ण_ को थोड़ा बढ़ा देगा
  
  
  
  • यह उन स्थितियों में एक मुद्दा बन सकता है जहां बहुत सारे उपकरणों को हाथ से बनाने की आवश्यकता होती है, हालांकि हम इस उपयोग के मामले के लिए बैच निर्माण सुविधाएँ पेश करेंगे और सीएलआई / स्क्रिप्टिंग ऐसी स्थितियों में भी मदद कर सकती है।
  
  
  • फिर भी, V2 कंसोल डिवाइस निर्माण के साथ अंतर पर विचार करें और उपयोगकर्ता इस परिवर्तन को कैसे समझ सकते हैं
  
  
• मुझे सामान्य सेटिंग्स के लिए संबंधित "खंडित संपादन" समाधान पसंद है
• प्रवाह आरेख बहुत उपयोगी है और हमें इसे अद्यतन रखना चाहिए

बैच निर्माण/अद्यतन/हटाने के साथ-साथ निर्माण रोलबैक तर्क के लिए जेएस एसडीके में अनावश्यक जटिलता

मुझे लगता है कि डिवाइस अनुरोधों को विभाजित करने और विलय करने के लिए एसडीके में कार्यक्षमता अभी भी बहुत मूल्यवान है, भले ही हम इस मामले में इसका उपयोग न करें

मल्टीकास्ट उपकरणों के लिए @johanstokking एमआईसी गणना के लिए एनएस को केवल 1.1 में SNwkSIntKey की आवश्यकता है। FNwkSIntKey और NwkSEncKey , वास्तव में, IMO सेट करने की अनुमति नहीं दी जानी चाहिए।

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

मुझे नहीं लगता कि फिनिश या कुछ और मारने से पहले हमें कुछ भी बनाना चाहिए। विज़ार्ड में आगे-पीछे जाने और ब्राउज़र विंडो बंद करने के परिणामस्वरूप आधे-अधूरे उपकरण नहीं होने चाहिए।

• एक समस्या जो मैं देख रहा हूं वह यह है कि एप्लिकेशन सर्वर चरण बहुत उथला है (क्या यह बाद में बदल जाएगा?) और पेलोड प्रारूप विकल्प जोड़ना वास्तव में डिवाइस बनाते समय उपयोगकर्ता की जरूरतों के अनुरूप नहीं है।

हम यहां एप्लिकेशन पैकेज के लिए कॉन्फ़िगरेशन जोड़ेंगे (यानी रिमोट मल्टीकास्ट सेटअप, खंडित डेटा ब्लॉक ट्रांसफर, सेमटेक मॉडेम विकल्प, आदि)। तो हाँ अब यह उथला है लेकिन इसे बढ़ाया जाएगा।

• एक समाधान एएस और जेएस चरण को मर्ज करना हो सकता है, क्योंकि दोनों बहुत सीधे हैं और अन्योन्याश्रित नहीं हैं। मुझे एहसास है कि यह घटक द्वारा अलगाव के खिलाफ जाता है लेकिन मुझे लगता है कि यह पूरे प्रवाह को उचित अमूर्तता के साथ सरल बना देगा। विशेष रूप से यह देखते हुए कि हम चरणों के भीतर संबंधित स्टैक घटकों से किसी भी कनेक्शन का संचार नहीं करते हैं।

हमारे भविष्य के लिए मैं उन्हें अलग रखने की सलाह दूंगा। साथ ही उन्हें संयोजित करने से उन पृष्ठों पर रेंडरिंग सामग्री बन जाती है जो घटक उपलब्धता पर सशर्त होती है जो पहले से ही जटिल प्रवाह में जटिलता जोड़ती है।

• स्टैक कॉन्फ़िगरेशन के आधार पर हम एक विज़ार्ड के साथ समाप्त हो सकते हैं जिसमें केवल एक या दो चरण होते हैं, जो जादूगरों के लिए एक विरोधी पैटर्न है।

  • केवल एक चरण के मामले में, हम केवल विज़ार्ड पहलू को छुपा/हटा सकते हैं
  • दो चरणों के लिए, मुझे लगता है कि हमें इस मुद्दे के साथ रहना होगा ‍♂

• यह माना जाना चाहिए कि विज़ार्ड समाधान उपयोगकर्ता की कहानी के लिए _समय-से-पूर्ण_ को थोड़ा बढ़ा देगा

  • यह उन स्थितियों में एक मुद्दा बन सकता है जहां बहुत सारे उपकरणों को हाथ से बनाने की आवश्यकता होती है, हालांकि हम इस उपयोग के मामले के लिए बैच निर्माण सुविधाएँ पेश करेंगे और सीएलआई / स्क्रिप्टिंग ऐसी स्थितियों में भी मदद कर सकती है।
  • फिर भी, V2 कंसोल डिवाइस निर्माण के साथ अंतर पर विचार करें और उपयोगकर्ता इस परिवर्तन को कैसे समझ सकते हैं

घटकों का पृथक्करण और लचीला परिनियोजन परिदृश्य V2 की तुलना में महत्वपूर्ण परिवर्तनों में से एक है, इसलिए यह पूरी तरह से समझ में आता है कि यह V3 कंसोल में प्रभावी है।

दरअसल, बड़ी मात्रा में डिवाइस बनाने के लिए लोगों को वैसे भी एपीआई और सीएलआई का इस्तेमाल करना चाहिए।

एक कदम के साथ कोई परिदृश्य नहीं है, यह हमेशा कम से कम दो कदम होता है।

पृष्ठों के बजाय टैब प्रस्तुत करने के बारे में कैसे? इस तरह यह अभी भी एक पृष्ठ है लेकिन चीजें आसानी से चरणों में आगे-पीछे किए बिना पहुंच योग्य हैं।

@johanstokking

मुझे नहीं लगता कि फिनिश या कुछ और मारने से पहले हमें कुछ भी बनाना चाहिए।

यदि हम केवल अंतिम चरण में वास्तविक अनुरोध करते हैं, तो इसका मतलब है कि हम 3-4 अनुरोध करेंगे। हम विभिन्न घटकों द्वारा लौटाई गई त्रुटियों को कैसे संभालते हैं? इसे संभालना, उपयोगकर्ता को त्रुटिपूर्ण चरण/रीसेटिंग स्टोर/आदि पर नेविगेट करना। जटिल है। यही कारण है कि मैं हर कदम पर मान सबमिट करने का सुझाव देता हूं, क्योंकि प्रत्येक क्रमिक चरण सबमिट किए गए मानों को मान्य मान सकता है।

विज़ार्ड में आगे-पीछे जाने और ब्राउज़र विंडो बंद करने के परिणामस्वरूप आधे-अधूरे उपकरण नहीं होने चाहिए।

मैं उपयोगकर्ताओं को विज़ार्ड में डेटा संपादित करने की अनुमति देने के खिलाफ हूं (उन चरणों के लिए जो सबमिशन में परिणामित होते हैं)। एमबी, केवल वैकल्पिक फ़ील्ड जो एक घटक में संग्रहीत हैं (और किसी अन्य घटक को उनकी आवश्यकता नहीं है), name , description कहें। अन्यथा इसे संभालना काफी जटिल हो जाता है।

@kschiffer

स्टैक कॉन्फ़िगरेशन के आधार पर हम एक विज़ार्ड के साथ समाप्त हो सकते हैं जिसमें केवल एक या दो चरण होते हैं, जो जादूगरों के लिए एक विरोधी पैटर्न है।

खैर, हम वैकल्पिक समाधानों के लिए खुले हैं। कोई प्रस्ताव?

यदि हम केवल अंतिम चरण में वास्तविक अनुरोध करते हैं, तो इसका मतलब है कि हम 3-4 अनुरोध करेंगे। हम विभिन्न घटकों द्वारा लौटाई गई त्रुटियों को कैसे संभालते हैं? इसे संभालना, उपयोगकर्ता को त्रुटिपूर्ण चरण/रीसेटिंग स्टोर/आदि पर नेविगेट करना। जटिल है। यही कारण है कि मैं हर कदम पर मान सबमिट करने का सुझाव देता हूं, क्योंकि प्रत्येक क्रमिक चरण सबमिट किए गए मानों को मान्य मान सकता है।

ठीक। यह ठीक है, जब तक कंसोल ईआर में मौजूद उपकरणों को संभाल सकता है लेकिन जेएस/एनएस/एएस में नहीं मिल सकता है क्योंकि वह चरण विफल हो गया है या उपयोगकर्ता ने टैब या कुछ बंद कर दिया है।

मैं उपयोगकर्ताओं को विज़ार्ड में डेटा संपादित करने की अनुमति देने के खिलाफ हूं (उन चरणों के लिए जो सबमिशन में परिणामित होते हैं)। एमबी, केवल वैकल्पिक फ़ील्ड जो एक घटक में संग्रहीत हैं (और किसी अन्य घटक को उनकी आवश्यकता नहीं है), name , description कहें। अन्यथा इसे संभालना काफी जटिल हो जाता है।

आपका क्या मतलब है?

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

आपका क्या मतलब है?

माफ़ करना। यह @kschiffer सुझाव की ओर था:

इसी तरह, पिछले चरण पर जाने के लिए फ़ॉर्म को "अपडेट मोड" में रखना होगा (आईएस को छोड़कर, यह अपेक्षाकृत आसान होना चाहिए क्योंकि एंडपॉइंट समान हैं)

विज़ार्ड में आगे-पीछे जाने और ब्राउज़र विंडो बंद करने के परिणामस्वरूप आधे-अधूरे उपकरण नहीं होने चाहिए।

मैं इसे भविष्य में सुधार के रूप में मानूंगा। अभी के लिए हम केवल अपूर्ण प्रवाह पर उपयोगकर्ता को एक सूचना दिखा सकते हैं। बाद में, उपयोगकर्ता सामान्य सेटिंग पृष्ठ में डिवाइस को संपादित/हटा सकता है।

खैर, हम वैकल्पिक समाधानों के लिए खुले हैं। कोई प्रस्ताव?

खैर, मुझे लगता है कि इस विशेष स्थिति के _edge-casiness_ को देखते हुए, इस मुद्दे के साथ रहना ठीक है। आपके शब्दों से पता चलता है कि मुझे प्रस्तावित समाधानों के बिना चिंताओं को दूर नहीं करना चाहिए, लेकिन मैं दूसरों को कुछ के साथ आने का अवसर देना चाहता हूं अगर मुझे तुरंत कोई नहीं मिल रहा है।

मैं उपयोगकर्ताओं को विज़ार्ड में डेटा संपादित करने की अनुमति देने के खिलाफ हूं (उन चरणों के लिए जो सबमिशन में परिणामित होते हैं)। एमबी, केवल वैकल्पिक फ़ील्ड जो एक घटक में संग्रहीत हैं (और किसी अन्य घटक को उनकी आवश्यकता नहीं है), name , description कहें। अन्यथा इसे संभालना काफी जटिल हो जाता है।

यह फिर से विज़ार्ड पैटर्न के लिए सर्वोत्तम प्रथाओं के साथ टूट जाएगा। उपयोगकर्ता संभवतः पहले के क्षेत्रों को संशोधित करना या उनका निरीक्षण करना चाहेंगे, विशेष रूप से यह देखते हुए कि ये अन्योन्याश्रित हैं। मैं शुरुआत में इस कार्यक्षमता को शामिल नहीं करने के साथ ठीक हूं, लेकिन इसे अंततः जोड़ा जाना चाहिए (जैसा कि: किसी समस्या में ट्रैक रखा गया है)।

अन्यथा इसे संभालना काफी जटिल हो जाता है।

सामान्यतया, जटिल फ्रंटएंड लॉजिक को लागू करने की आवश्यकता UX के प्रति हमारी प्रतिबद्धता को प्रभावित नहीं करनी चाहिए।

मैं इसे भविष्य में सुधार के रूप में मानूंगा। अभी के लिए, हम केवल अपूर्ण प्रवाह पर उपयोगकर्ता को एक सूचना दिखा सकते हैं। बाद में, उपयोगकर्ता सामान्य सेटिंग पृष्ठ में डिवाइस को संपादित/हटा सकता है।

इष्टतम नहीं लेकिन मेरे लिए स्वीकार्य है, जब तक हम इसे अंततः बढ़ाएंगे।

जैसा कि ऑफ़लाइन चर्चा की गई है, यहां प्रारंभिक प्रस्ताव है;

डिवाइस बनाएं

1. सामान्य सेटिंग्स
   
   
   
   • खेत
     
     
     
     
     
     • ids
     
     
     
     • वैकल्पिक name
     
     
     
     • वैकल्पिक description
     
     
     
     • वैकल्पिक attributes
     
     
     
     • आवश्यक सक्रियण मोड: OTAA, ABP या मल्टीकास्ट
     
     
     
     • यदि क्लस्टर में NS
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • यह चरण डिवाइस को केवल IS में बनाता है। इस तरह, हम जानते हैं कि पहचानकर्ता स्वतंत्र हैं
   
   
   • सत्र स्थिति में सक्रियण मोड का उपयोग किया जाता है
   
   
   • यदि क्लस्टर में NS नहीं है, तो विज़ार्ड में सरलता के लिए, आप सत्र स्थिति में उच्चतम ज्ञात संस्करणों (अर्थात अब क्रमशः 1.1.0 और 1.1.0-A) का उपयोग कर सकते हैं
   
   

2. लोरावन सेटिंग्स

   • यदि क्लस्टर में NS: फ़ील्ड
     
     
     
     • lorawan_version (आवश्यक)
     
     
     • lorawan_phy_version (आवश्यक)
     
     
     • supports_join यदि सक्रियण मोड OTAA (आवश्यक) है तो सेट करें
     
     
     • multicast अगर एक्टिवेशन मोड मल्टीकास्ट है तो सेट करें
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (आवश्यक)
     
     
     • mac_settings.supports_32_bit_f_cnt
     
     
     • mac_settings.factory_preset_frequencies
     
     
     • mac_settings.ping_slot_data_rate_index.value
     
     
     • mac_settings.ping_slot_frequency
     
     
     • mac_settings.ping_slot_periodicity.value
     
     
     • mac_settings.rx2_data_rate_index.value
     
     
     • min_frequency
     
     
     • max_frequency
     
     
   • यदि क्लस्टर में NS: यदि सक्रियण मोड OTAA है तो फ़ील्ड्स
     
     
     
     • चेकबॉक्स बाहरी जेएस का उपयोग करना है या नहीं (डिफ़ॉल्ट चेक किया गया)
     
     
   • फ़ील्ड यदि सक्रियण मोड एबीपी या मल्टीकास्ट है
     
     
     
     • यदि क्लस्टर में NS या AS: session.dev_addr
     
     
     • यदि क्लस्टर में NS या AS: session.keys.session_key_id . उत्पन्न करें
     
     
     • यदि क्लस्टर में NS: session.keys.f_nwk_s_int_key.key - आवश्यक
     
     
     • यदि क्लस्टर में NS: session.keys.s_nwk_s_int_key.key (यदि LW >= 1.1.0) - आवश्यक
     
     
     • यदि क्लस्टर में NS: session.keys.nwk_s_enc_key.key (यदि LW >= 1.1.0) - आवश्यक
     
     
     • यदि क्लस्टर में AS: session.keys.app_s_key.key - आवश्यक
     
     
     • यदि क्लस्टर में NS: session.last_conf_f_cnt_down
     
     
     • यदि क्लस्टर में NS: session.last_n_f_cnt_down
     
     
   • यदि क्लस्टर में NS: फ़ील्ड यदि सक्रियण मोड ABP है
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • यदि क्लस्टर में NS या AS: यदि सक्रियण मोड ABP है तो फ़ील्ड्स
     
     
     
     • session.last_f_cnt_up - सुरक्षा के लिए यह आवश्यक है
     
     

   • यदि क्लस्टर में NS: फ़ील्ड यदि सक्रियण मोड ABP या OTAA है

     • mac_settings.adr_margin
     • mac_settings.class_b_timeout
     • mac_settings.class_c_timeout
     • mac_settings.desired_adr_ack_delay_exponent.value
     • mac_settings.desired_adr_ack_limit_exponent.value
     • mac_settings.desired_max_duty_cycle.value
     • mac_settings.desired_rx1_data_rate_offset
     • mac_settings.desired_rx1_delay.value
     • mac_settings.desired_rx2_data_rate_index.value
     • mac_settings.desired_rx2_frequency
     • mac_settings.max_duty_cycle.value
     • mac_settings.rx1_data_rate_offset
     • mac_settings.rx1_delay.value
     • mac_settings.status_count_periodicity
     • mac_settings.status_time_periodicity
     • mac_settings.supports_32_bit_f_cnt
     • mac_settings.use_adr

   • यह डिवाइस को NS और AS (यदि क्लस्टर में है) में सेट करता है। अगर हमारे पास ओटीएए डिवाइस है, तो इस समय हमारे पास एएस में सेट करने के लिए कुछ भी नहीं है, लेकिन मैं अभी भी स्थिरता के लिए कॉल करूंगा

3. यदि क्लस्टर में AS: अनुप्रयोग सेटिंग्स
   
   
   
   • खेत
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • यह डिवाइस को AS . में सेट करता है
   
   
4. यदि JS क्लस्टर में है और यदि OTAA और यदि बाहरी JS का उपयोग नहीं कर रहा है: सुरक्षा सेटिंग्स
   
   
   
   • खेत
     
     
     
     
     
     • root_keys.root_key_id उत्पन्न करें
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (यदि एलडब्ल्यू>= 1.1.0)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • यह डिवाइस को JS . में सेट करता है
   
   

डिवाइस अपडेट करें

यहां, मैं एक टैब्ड दृष्टिकोण के साथ जाऊंगा, मूल रूप से टैब के रूप में विज़ार्ड चरणों के साथ।

यहाँ कुंजी है कि;

• ids , supports_join , multicast केवल पढ़ने के लिए हैं
• इस क्रम में सक्रियण मोड का मूल्यांकन किया जाता है:
  
  
  
  • OTAA: यदि क्लस्टर में कोई NS नहीं है, या यदि क्लस्टर में NS और NS कहता है supports_join
  
  
  • एबीपी: क्लस्टर में एनएस की जरूरत है (और केवल उस मामले में प्रासंगिक है): !supports_join && !multicast
  
  
  • मल्टीकास्ट: क्लस्टर में एनएस की जरूरत है (और केवल उस मामले में प्रासंगिक है): !supports_join && multicast (हालांकि multicast पर्याप्त होना चाहिए)
  
  

कुछ मामलों का उपयोग उपकरणों को अद्यतन करने में समर्थन के लिए करते हैं:

• कंसोल में क्लस्टर में NS, AS और JS हो सकते हैं, लेकिन डिवाइस NS, AS या JS में नहीं हो सकता है (कंसोल 404 हो जाता है)। यह एक वैध मामला है और कंसोल को इसे संभालना चाहिए। एक उदाहरण मामला दावा किया गया डिवाइस है, जिसमें डिवाइस ईआर और जेएस में सेट है, लेकिन एनएस और एएस में नहीं (अभी तक)
• पिछले पर निर्माण: एक डिवाइस की लोरावन और एप्लिकेशन सेटिंग्स सेट करें जो केवल ईआर और जेएस में है (यानी इसे एनएस और एएस में सेट करें)
• lorawan_version और lorawan_phy_version बदलना (यह बाधाओं को बदलता है)
• "बाहरी जेएस" विकल्प बदलना; यानी मान लें कि आपके पास एक मौजूदा डिवाइस है लेकिन आप क्लस्टर-जेएस में रूट कुंजियों को कॉन्फ़िगर करना चाहते हैं। फिर, आप इस चेकबॉक्स को अनचेक करें और उपयोगकर्ता सुरक्षा सेटिंग्स टैब में रूट कुंजियों को सेट करने में सक्षम होना चाहिए
• थोक आयात के माध्यम से, डिवाइस जेएस पर बनाया जा सकता है और रूट कुंजी हो सकती है, लेकिन वे उजागर नहीं होते हैं। आज की तरह, उपयोगकर्ता को यह देखने में सक्षम होना चाहिए कि रूट कुंजियाँ हैं ( root_keys != nil ) लेकिन वे उजागर नहीं हैं ( root_keys.app_key == null आदि)। उपयोगकर्ता को रूट कुंजियों को बरकरार रखने में सक्षम होना चाहिए

सामान्य सामान

• कुंजियों के लिए, एक इनपुट फ़ील्ड या एक यादृच्छिक बटन उत्पन्न करें
• बाहरी जेएस और अनएक्सपोज़्ड रूट कीज़ के बीच अंतर;
  
  
  
  • बाहरी जेएस वह जगह है जहां जेएस एनएस के समान क्लस्टर में नहीं है। यह एक OTAA डिवाइस बनाने की अनुमति देता है, लेकिन सुरक्षा सेटिंग्स में प्रवेश करने की आवश्यकता नहीं है, क्योंकि कुंजियाँ कहीं और कॉन्फ़िगर की गई हैं
  
  
  • अनएक्सपोज़्ड रूट कीज़ वह जगह है जहाँ डिवाइस क्लस्टर-लोकल JS में है, लेकिन JS रूट कीज़ को एक्सपोज़ नहीं करता है। यह सुरक्षा के लिए है, यानी सुरक्षित तत्वों के मामले में, जहां JS के पास रूट कुंजियों तक पहुंच है, लेकिन उन्हें उजागर नहीं करता है
  
  

मुझे लगता है कि https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 में पहले से ही NS के लिए आवश्यक सभी चीजें शामिल हैं।
मुझे लगता है कि सभी mac_settings सभी गैर-मल्टीकास्ट उपकरणों के लिए सेट होने के लिए उपलब्ध होना चाहिए।
मल्टीकास्ट उपकरणों के लिए केवल निम्नलिखित का अर्थ है:

• "mac_settings.factory_preset_frequencies"
• "mac_settings.ping_slot_data_rate_index.value"
• "मैक_सेटिंग्स.पिंग_स्लॉट_फ्रीक्वेंसी"
• "mac_settings.ping_slot_periodicity.value"
• "mac_settings.rx2_data_rate_index.value"
• "mac_settings.rx2_फ़्रीक्वेंसी"

शायद कुछ बातें स्पष्ट करने के लिए

सृजन करना:

1. सामान्य सेटिंग्स
   ए। जब हम ईआर में डिवाइस बनाते हैं, तो हम एनएस/एएस/जेएस पते सेट नहीं करते हैं। क्या हम ईआर पंजीकरण को अपडेट करते हैं जब उनमें डिवाइस सेट हो? क्या होगा यदि हम बाहरी जेएस का उपयोग कर रहे हैं?
   बी। क्या हम ईआर में एक्टिवेशन मोड स्टोर करते हैं?
   सी। क्या हम ईआर में phy/mac संस्करणों को स्टोर करते हैं?
2. लोरावन सेटिंग्स
   ए। कैसे के बारे में supports_class_b ?
3. अनुप्रयोग सेटिंग
   ए। हां, इसका मतलब यह हो सकता है कि हमने डिवाइस को AS पर दो बार सेट किया है

अद्यतन:

• सक्रियण मोड: यदि हम इसे ER . में संग्रहीत करते हैं तो यह बहुत आसान होगा
• क्या हम ईआर में केवल 404 या एनएस/एएस/जेएस पतों को देखते हैं?
• मुझे लगता है कि एक व्यक्तिगत एनएस/एएस/जेएस पंजीकरण को हटाने में सक्षम होना अच्छा होगा उदाहरण के लिए "बाहरी जेएस" को true में बदलते समय, या एनएस में डिवाइस स्थिति को रीसेट करने के लिए

सामान्य सामान:

• _ "बाहरी जेएस वह जगह है जहां जेएस एनएस के समान क्लस्टर में नहीं है" _: मुझे लगता है कि यह कुछ ऐसा होना चाहिए जैसे "join_server_address कंसोल कॉन्फ़िगरेशन में जेएस पते के समान नहीं है"

यदि हम शीर्ष-स्तरीय क्षेत्रों के बारे में बात कर रहे हैं:
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 यह पूरा हिस्सा NS में है (लेकिन इन सभी की आवश्यकता नहीं है)

m{in,ax}_frequency मल्टीकास्ट पर लागू नहीं है

@rvolosatovs

मुझे लगता है कि #579 (टिप्पणी) में पहले से ही एनएस के लिए आवश्यक सभी चीजें शामिल हैं।

मुझे लगता है कि सभी mac_settings सभी गैर-मल्टीकास्ट उपकरणों के लिए सेट होने के लिए उपलब्ध होना चाहिए।
मल्टीकास्ट उपकरणों के लिए केवल निम्नलिखित का अर्थ है:

इस समस्या के साथ समस्याओं में से एक टिप्पणियों में दफन की गई जानकारी की मात्रा है।

क्या आप कृपया सही जगहों पर _exactly_ फ़ील्ड जोड़ सकते हैं? मैं ठीक हूँ यदि आप बुलेट पॉइंट्स की मेरी पूरी सूची को कॉपी करते हैं तो हम उस पर तब तक काम करते हैं जब तक कि हमारे पास अंतिम संस्करण न हो।

@htdvisser

1. सामान्य सेटिंग्स
   ए। जब हम ईआर में डिवाइस बनाते हैं, तो हम एनएस/एएस/जेएस पते सेट नहीं करते हैं। क्या हम ईआर पंजीकरण को अपडेट करते हैं जब उनमें डिवाइस सेट हो? क्या होगा यदि हम बाहरी जेएस का उपयोग कर रहे हैं?

मुझे लगता है कि जब हम एएस/एनएस/जेएस में डिवाइस सेट करते हैं तो हमें पते अपडेट करना चाहिए।

बी। क्या हम ईआर में एक्टिवेशन मोड स्टोर करते हैं?

नहीं, इस समय हमारे पास इसके लिए कोई क्षेत्र नहीं है, हमें वास्तव में इसकी आवश्यकता नहीं है और यह विसंगतियों के लिए जगह बनाता है।

सी। क्या हम ईआर में phy/mac संस्करणों को स्टोर करते हैं?

नहीं, एपीआई दस्तावेज देखें। फिर से, मुझे इसकी आवश्यकता नहीं दिखती और यह विसंगतियों के लिए जगह बनाता है।

ए। कैसे के बारे में supports_class_b ?

हाँ, मुझे लगता है कि हमें इसे जोड़ना चाहिए, लंबित #19। @rvolosatovs कृपया इसे एक अद्यतन संस्करण में शामिल करें यदि प्रासंगिक हो।

1. अनुप्रयोग सेटिंग
   ए। हां, इसका मतलब यह हो सकता है कि हमने डिवाइस को AS पर दो बार सेट किया है

हाँ, यह चोट नहीं करता है

अद्यतन:

• सक्रियण मोड: यदि हम इसे ER . में संग्रहीत करते हैं तो यह बहुत आसान होगा

हां, लेकिन मुझे यकीन नहीं है कि हमें सहजता के लिए जाना चाहिए और अगर यह पूरी तरह से लागू होता है। हमें इसे गर्म पथ में उपलब्ध कराने की आवश्यकता है।

साथ ही, यह तभी आसान होगा जब हम एक साफ स्लेट से शुरुआत कर सकें। हालांकि, हमें पिछड़े संगत होने की जरूरत है, जब lorawan_version ईआर में नहीं है, तो एनएस आदि से सशर्त हो जाता है।

• क्या हम ईआर में केवल 404 या एनएस/एएस/जेएस पतों को देखते हैं?

पता सेट होने पर हम केवल 404 प्राप्त कर सकते हैं, अन्यथा प्राप्त करने के लिए कुछ भी नहीं है। हमें दोनों की व्याख्या "उस रजिस्ट्री में नहीं" के रूप में करनी चाहिए। हम यहां त्रुटि नहीं कर सकते (जैसे हमने पहले किया था), ठीक इस कारण से कि IS और AS/NS/JS में निर्माण एक ही समय में नहीं होता है, और उपयोगकर्ताओं को कंसोल द्वारा बनाई गई विसंगतियों को पुनर्प्राप्त करने में सक्षम होना चाहिए।

• मुझे लगता है कि एक व्यक्तिगत एनएस/एएस/जेएस पंजीकरण को हटाने में सक्षम होना अच्छा होगा उदाहरण के लिए "बाहरी जेएस" को true में बदलते समय, या एनएस में डिवाइस स्थिति को रीसेट करने के लिए

हाँ, चलिए इसे बाद में करते हैं

• _ "बाहरी जेएस वह जगह है जहां जेएस एनएस के समान क्लस्टर में नहीं है" _: मुझे लगता है कि यह कुछ ऐसा होना चाहिए जैसे "join_server_address कंसोल कॉन्फ़िगरेशन में जेएस पते के समान नहीं है"

हां, यह वास्तव में इसे जांचने का तरीका है। इंटरऑप का उपयोग करके join_server_address भी खाली हो सकता है।

@bafonins क्या आपके पास अभी भी ग्राफ का स्रोत है?
चूंकि बहुत सारे काम पहले से ही निर्माण में चले गए हैं, मुझे लगता है कि हमें स्पष्ट प्रतिनिधित्व के लिए इसे पूरा करने के लिए इसे अपडेट करना चाहिए?
हम यहां चर्चा को अव्यवस्थित न करने के लिए एनएस भाग को ऑफ़लाइन अपडेट करने पर भी काम कर सकते हैं।

मैंने सभी संभावित एनएस क्षेत्रों के साथ ग्राफ को अद्यतन किया
लाल रंग में फ़ील्ड अनिवार्य हैं

@rvolosatovs हम उस प्रवाह और फ़ील्ड को परिभाषित करने का लक्ष्य रखते हैं जिसे हम डिवाइस बनाते और अपडेट करते समय कंसोल में प्रस्तुत कर रहे हैं।

जैसे की,

• हमें mac_state.lorawan_version बदलने की अनुमति नहीं देनी चाहिए
• हम अभी के लिए CLI के माध्यम से mac_state.ping_slot_periodicity कर सकते हैं
• कृपया इस बारे में सोचें कि उपयोगकर्ता supports_class_b , supports_class_c और mac_state.device_class कैसे सेट करने जा रहा है; जो निर्माण का हिस्सा है, जो अद्यतन का हिस्सा है, एक दूसरे से कैसे संबंधित है?
• हमें अलग-अलग काउंटर नहीं बदलने चाहिए; एक "रीसेट फ्रेम काउंटर" बटन करेगा (जो afaik एक अलग क्रिया हो सकती है, जैसे हमारे पास V2 कंसोल में है, जो काउंटरों को 0 पर सेट कर रहा है)
• mac_settings और mac_state.desired_parameters के कंसोल में हमें सावधानीपूर्वक चयन करना चाहिए कि हमें कौन सी सेटिंग चाहिए; @htdvisser क्या आप यहां सोच सकते हैं?

मैंने https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858 में ऑर्डर बदल दिया। कृपया उस सूची में वृद्धिशील रूप से कार्य करें।

क्या आप कृपया बिल्कुल सही जगहों पर फ़ील्ड जोड़ सकते हैं?

मैंने इस प्रश्न का उत्तर दिया - यानी मैंने सभी फ़ील्ड प्रस्तुत किए, जिन्हें सेट किया जा सकता है और एनएस पर सेट किया जाना चाहिए । या कम से कम इस तरह मैं आपके प्रश्न को समझ गया।

कंसोल में क्या होना चाहिए, इसके बारे में सब कुछ mac_state शायद केवल सीएलआई के माध्यम से व्यवस्थित होना चाहिए, हालांकि हमें एबीपी/मल्टीकास्ट डिवाइस और/या ओटीएए डिवाइसों के लिए इसकी आवश्यकता हो सकती है, जो मौजूदा सत्र के साथ पंजीकृत हैं, और, इसलिए मैक राज्य।
मैं आपकी टिप्पणी अपडेट करूंगा।

हमें अलग-अलग काउंटर नहीं बदलने चाहिए; एक "रीसेट फ्रेम काउंटर" बटन करेगा (जो afaik एक अलग क्रिया हो सकती है, जैसे हमारे पास V2 कंसोल में है, जो काउंटरों को 0 पर सेट कर रहा है)

हमें एबीपी और मल्टीकास्ट के लिए डाउनलिंक फ्रेम काउंटर सेट करने में सक्षम होने की आवश्यकता है - अन्यथा एनएस डाउनलिंक नहीं भेज सकता है
अपलिंक फ्रेम के लिए काउंटर एबीपी के लिए सुरक्षा की दृष्टि से भी बहुत उपयोगी हैं

डिवाइस अपडेट करें

यहां, मैं एक टैब्ड दृष्टिकोण के साथ जाऊंगा, मूल रूप से टैब के रूप में विज़ार्ड चरणों के साथ।

आइए यहां अकॉर्डियन दृष्टिकोण का उपयोग करें, जैसा कि @bafonins की पहली टिप्पणी में प्रस्तुत किया गया है:

यह हमें क्षैतिज स्थान के साथ कम समस्याएं देगा, और Edit / Create बटन के साथ मोड को अलग करने की अनुमति देता है।

@rvolosatovs

हमें एबीपी और मल्टीकास्ट के लिए डाउनलिंक फ्रेम काउंटर सेट करने में सक्षम होने की आवश्यकता है - अन्यथा एनएस डाउनलिंक नहीं भेज सकता है
अपलिंक फ्रेम के लिए काउंटर एबीपी के लिए सुरक्षा की दृष्टि से भी बहुत उपयोगी हैं

अगर यह आसान है तो हम इसे कर सकते हैं। वास्तव में, दो/तीन इनपुट बॉक्स एक रीसेट बटन की तुलना में सरल हो सकते हैं जो एक विशिष्ट क्रिया को ट्रिगर करता है।

कंसोल में क्या होना चाहिए, इसके बारे में सब कुछ mac_state शायद केवल सीएलआई के माध्यम से व्यवस्थित होना चाहिए, हालांकि हमें एबीपी/मल्टीकास्ट डिवाइस और/या ओटीएए डिवाइसों के लिए इसकी आवश्यकता हो सकती है, जो मौजूदा सत्र के साथ पंजीकृत हैं, और, इसलिए मैक राज्य।

मैं समझता हूं। मुझे लगता है कि हमें "नए और रीसेट एबीपी डिवाइस" को "मौजूदा एबीपी डिवाइस जो पहले से ही नेटवर्क पर हैं" से अलग करना चाहिए।

पूर्व पूर्ण होना चाहिए, इसलिए इसमें कुछ mac_state (यानी फ़ैक्टरी रीसेट आवृत्तियों, RX1 विलंब, RX2 सेटिंग्स, आदि) शामिल होना चाहिए, लेकिन mac_state.desired_parameters नहीं।

उत्तरार्द्ध को माइग्रेशन के माध्यम से किया जाना चाहिए और हम बाद में कंसोल में फाइन ट्यूनिंग सेटिंग्स जोड़ सकते हैं; अभी के लिए सीएलआई का उपयोग किया जाना चाहिए।

अपडेट करने के लिए धन्यवाद

लोरावन सेटिंग्स

• यदि क्लस्टर में NS: फ़ील्ड
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

क्या ये ओटीएए के लिए आवश्यक हैं? क्या यह केवल एबीपी और मल्टीकास्ट के लिए नहीं है?

@johanstokking

लोरावन सेटिंग्स

• यदि क्लस्टर में NS: फ़ील्ड
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

क्या ये ओटीएए के लिए आवश्यक हैं? क्या यह केवल एबीपी और मल्टीकास्ट के लिए नहीं है?

सभी मैक सेटिंग्स डिज़ाइन द्वारा वैकल्पिक हैं।
एकमात्र मामला जहां ये "आवश्यक" हैं, क्लास बी मल्टीकास्ट डिवाइस हैं, जो कि क्लास बी ऑपरेशन की बारीकियों के कारण है।
इसके अलावा, सर्वोत्तम परिणामों के लिए ABP के लिए factory_preset_frequencies की आवश्यकता होने की संभावना है, लेकिन कुछ भी OTAA डिवाइस को वह सेट करने से नहीं रोकता है।

सभी मैक सेटिंग्स डिज़ाइन द्वारा वैकल्पिक हैं।
एकमात्र मामला जहां ये "आवश्यक" हैं, क्लास बी मल्टीकास्ट डिवाइस हैं, जो कि क्लास बी ऑपरेशन की बारीकियों के कारण है।

ठीक

इसके अलावा, सर्वोत्तम परिणामों के लिए ABP के लिए factory_preset_frequencies की आवश्यकता होने की संभावना है, लेकिन कुछ भी OTAA डिवाइस को वह सेट करने से नहीं रोकता है।

यह OTAA के लिए अप्रभावी है; डिफ़ॉल्ट जॉइन फ़्रीक्वेंसी कल्पना द्वारा आवश्यक हैं, और चैनल ज्वाइन-स्वीकृति और मैक कमांड के माध्यम से आते हैं। OTAA उपकरणों के लिए प्रीसेट फ़्रीक्वेंसी का आउट-ऑफ-बैंड कॉन्फ़िगरेशन नहीं होना चाहिए।

@bafonins क्या आप इस मुद्दे पर स्टेटस अपडेट और टाइमलाइन दे सकते हैं?

app_s_key और skip_payload_crypto के लिए, यह रही बात;

• AS अंतिम डिवाइस के फ़ील्ड skip_payload_crypto का सम्मान करता है। यदि true , AS पेलोड एन्क्रिप्शन और डिक्रिप्शन नहीं करता है
  
  
  
  • AS को एप्लिकेशन-स्तर पर भी skip_payload_crypto मिलेगा (लिंक के माध्यम से, पेलोड फॉर्मेटर्स की तरह), जो अंतिम डिवाइस की सेटिंग पर पूर्वता लेता है
  
  
• AS में शायद हमेशा app_s_key होता है, लेकिन इसे लपेटा जा सकता है, यानी session.keys.app_s_key.key सेट नहीं है (लेकिन encrypted_key और kek_label सेट है)
  
  
  
  • जब AS के पास KEK नहीं होता है, यानी यह एन्क्रिप्टेड कुंजी को खोल नहीं सकता है। अब, वह त्रुटियां। हम शायद ग्राहकों को एन्क्रिप्टेड app_s_key की तरह ही वापस कर देंगे
  
  
• कंसोल में, यदि skip_payload_crypto true (अंतिम डिवाइस या एप्लिकेशन लिंक पर) सेट है, तो app_s_key से परेशान न हों: इसे अक्षम करें, परवाह न करें