Lorawan-stack: कंसोल ट्रैफ़िक दृश्य में शामिल होने का अनुरोध, अपलिंक और त्रुटियां दिखाएं

इसे जोड़ने के लिए धन्यवाद यह "होना चाहिए"
एडब्ल्यूएस बाजार पर v3 का मूल्यांकन करते समय हमने देखा कि यह पहली चीजों में से एक था।
पूछने के लिए खेद है, कोई विचार कब?

@industrialinternet आपकी रुचि दिखाने के लिए धन्यवाद। यह फरवरी के मील के पत्थर में सेट है, इसलिए हमारा लक्ष्य इसे इसी महीने पूरा करना है। कृपया इस मुद्दे की सदस्यता लें और शीर्ष पर देखें पर क्लिक करके, कम से कम रिलीज के लिए इस भंडार को देखें, ताकि आप जान सकें कि यह किस रिलीज में आता है।

@johanstokking

घटना निकायों के रूप में विचार करें:

मुझे लगता है कि आपका मतलब यहां as.up.data.forward है?

1. क्या हम मान सकते हैं कि आपके द्वारा उल्लिखित फ़ील्ड प्रत्येक ईवेंट प्रकार के लिए हमेशा मौजूद हैं (यदि ईवेंट ऑपरेशन सफल होता है)?
2. ईवेंट विजेट घटक (इकाई अवलोकन पृष्ठों में से एक) में कौन से फ़ील्ड शामिल किए जाने चाहिए?
   
3. decoded_payload वस्तु कितनी बड़ी हो सकती है? पूछ रहे हैं क्योंकि इसे इवेंट ui में छोटा किया जा सकता है।

मुझे लगता है कि आपका मतलब यहां as.up.data.forward है?

आह वास्तव में, हमने उन्हें as.up.join.forward और as.up.data.forward में विभाजित कर दिया है, और मेरे द्वारा उल्लिखित सभी डाउनलिंक ईवेंट अग्रेषित नहीं किए गए हैं (अभी तक)।

1. क्या हम मान सकते हैं कि आपके द्वारा उल्लिखित फ़ील्ड प्रत्येक ईवेंट प्रकार के लिए हमेशा मौजूद हैं (यदि ईवेंट ऑपरेशन सफल होता है)?

• frm_payload हमेशा as.up.data.forward में होता है, लेकिन decoded_payload वैकल्पिक है
• डिवाइस पहचानकर्ता हमेशा as.up.join.forward . में होते हैं

2. ईवेंट विजेट घटक (इकाई अवलोकन पृष्ठों में से एक) में कौन से फ़ील्ड शामिल किए जाने चाहिए?

उन मामलों में जहां हमारे पास कम जगह है, आपका मतलब है? मुझे लगता है कि डेटा के लिए डीकोडेड पेलोड अपलिंक, और शामिल होने के लिए DevEUI को स्वीकार करता है।

1. decoded_payload वस्तु कितनी बड़ी हो सकती है? पूछ रहे हैं क्योंकि इसे इवेंट ui में छोटा किया जा सकता है।

पंक्ति में इसे छोटा करना ठीक है। यदि आप पंक्ति का विस्तार करते हैं तो इसे JSON के रूप में प्रदर्शित किया जाना चाहिए। यह वास्तव में काफी बड़ा हो सकता है, यह डिवाइस निर्माता या एप्लिकेशन डेवलपर पर निर्भर है।

लेकिन अधिकांश {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5} . जैसा है

यहां मूल टिप्पणी अपडेट की गई

हाय जोहान और इस मामले में शामिल अन्य लोग

यह सुनकर अच्छा लगा कि आप लोगों के पास फरवरी के लिए "मिलस्टोन" है।
जैसा कि हम देखते हैं कि यह V3 कंसोल का मूल्यांकन कर रहा है, यहाँ बहुत कुछ किया जा सकता है, मुझे लगता है कि देव के लिए एक उत्कृष्ट उत्पाद बनाने का सरल साधन है। और प्रशासन

1) संपूर्ण एप्लिकेशन या नोड को अलग से डाउनलिंक भेजने की संभावना
2) अपलिंक पेलोड एचईएक्स को देखने में सक्षम हो और अलग विंडो में डीकोड किया गया
3) अनुप्रयोग निर्देशिका fx के लिए किसी प्रकार का पदानुक्रम। माता-पिता/बच्चे/नोड

भले ही हम अपने सर्वर से जुड़े टीटीआई का उपयोग करने की योजना बना रहे हों, यह आर एंड डी और निगरानी के लिए एक उत्कृष्ट अतिरिक्त होगा।

वैसे भी - अच्छा काम अब तक दोस्तों :-)

बीआर
/ए

महत्ता का क्रम;

1. अपलिंक संदेशों के लिए ids.join_eui , ids.dev_eui और ids.dev_addr में शामिल होने के अनुरोध, ids.dev_addr और uplink_message.frm_payload का हेक्स डिस्प्ले
2. स्वरूपित त्रुटि संदेश (यानी विशेषताएँ भरें)
3. डीकोडेड पेलोड JSON दिखाएं

बस चीजों को स्पष्ट करने के लिए।

• जुड़ने का प्रवाह इस प्रकार है:

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   कंसोल में इसका निम्न दृश्य है:

पहचानकर्ताओं के क्रम पर ध्यान दें: join_eui , dev_eui और dev_addr

अपलिंक प्रवाह इस प्रकार है:

1. ns.up.merge_metadata
2. ns.up.data.forward
3. as.up.data.receive
4. as.up.data.forward

कंसोल में इसका निम्न दृश्य है:

पहचानकर्ताओं के क्रम पर ध्यान दें: dev_addr और frm_payload । मुझे लगता है कि हम अपलिंक प्रवाह में शेष घटनाओं के लिए dev_addr भी दिखा सकते हैं।

मुझे यहां जो समस्या दिखाई दे रही है, वह यह है कि हमारे पास वास्तव में ज्यादा जगह नहीं है, खासकर as.up.join.forward इवेंट के लिए जॉइन फ्लो में। इसके अलावा, केवल मान वास्तव में अधिक जानकारी नहीं देते हैं और लेबल जोड़ने ( Dev Addr: .... ) और भी कम जगह छोड़ देंगे।

• त्रुटियों के संबंध में। वास्तव में, हम केवल गहरा कारण ले सकते हैं और विशेषताओं को भर सकते हैं, उदाहरण के लिए

{
  "namespace": "pkg/gatewayserver",
  "name": "host_handle",
  "message_format": "host `{host}` failed to handle message",
  "attributes": {
    "host": "cluster"
  },
  "cause": {
    "namespace": "pkg/networkserver",
    "name": "device_not_found",
    "message_format": "device not found",
    "correlation_id": "25407ee7f3cd4894aeeb23fecd4c4071",
    "code": 5
  },
  "code": 5
}

हम दिखा सकते हैं

या असफल शामिल होने के अनुरोध के लिए ( ns.up.join.drop ):

ध्यान दें कि हम पेलोड इंस्पेक्टर में मूल, बिना प्रारूप वाली त्रुटि रखते हैं। यह डिबगिंग के लिए सहायक हो सकता है।

• डीकोडेड पेलोड दिखा रहा है - बाद के लिए

@johanstokking @kschiffer यहां कोई सुझाव है?

महान पहला कदम!

पहचानकर्ताओं के क्रम पर ध्यान दें: join_eui , dev_eui और dev_addr

कुछ टिप्पणियाँ/प्रश्न:

1. क्या हमारे पास dev_addr के लिए एक कॉलम हो सकता है, और इसे सभी अपलिंक संदेशों के लिए भर सकते हैं और शामिल होने वाले स्वीकार कर सकते हैं?
2. मैं JoinEUI और DevEUI जैसे छोटे टेक्स्ट के साथ JoinEUI और DevEUI को प्रीपेन्ड करूंगा ताकि उपयोगकर्ता जान सकें कि कौन सा टेक्स्ट है
3. प्रत्येक संदेश के लिए पहचानकर्ता दिखाएं जिसे हम जानते हैं, इसलिए यह कई पंक्तियों के लिए समान पहचानकर्ता (JS/NS/AS) हो सकता है। ऐसा इसलिए है क्योंकि हम बाद में और कुछ समूहों में घटनाओं के लिए फ़िल्टरिंग जोड़ते हैं, सभी घटक उपलब्ध नहीं होते हैं (जैसे केवल जेएस) और हम अभी भी पहचानकर्ता देखना चाहते हैं

पहचानकर्ताओं के क्रम पर ध्यान दें: dev_addr और frm_payload ।

अच्छा, यहाँ भी FRMPayload . के साथ प्रीपेड करें

मुझे लगता है कि हम अपलिंक प्रवाह में शेष घटनाओं के लिए dev_addr भी दिखा सकते हैं।

हां, वह बिंदु 1 ऊपर है। मैं इससे सहमत हूँ।

मुझे यहां जो समस्या दिखाई दे रही है, वह यह है कि हमारे पास वास्तव में ज्यादा जगह नहीं है, खासकर as.up.join.forward घटना के लिए शामिल होने के प्रवाह में। इसके अलावा, केवल मान वास्तव में अधिक जानकारी नहीं देते हैं और लेबल जोड़ने ( Dev Addr: .... ) और भी कम जगह छोड़ देंगे।

मैं ईवेंट टेक्स्ट को रखने के लिए जानकारी को हटाने के बजाय "फॉरवर्ड डेटा अपलिंक संदेश" टेक्स्ट को एक आइकन (या आइकन; एएस + अपलिंक + डेटा) में बदल दूंगा। अगर हम सहमत हैं तो हम @pierrephz को आइकन डिजाइन करने के लिए कह सकते हैं। सीसी @kschiffer

ध्यान दें कि हम पेलोड इंस्पेक्टर में मूल, बिना प्रारूप वाली त्रुटि रखते हैं। यह डिबगिंग के लिए सहायक हो सकता है।

त्रुटियों पर सहमत

विचारों की जोड़ी:

• एकल संस्थाओं (अंतिम उपकरणों, गेटवे) के डेटा दृश्यों में हम Entity ID कॉलम को हटा सकते हैं, क्योंकि यह बेमानी है
• अन्यथा, Entity ID कॉलम को थोड़ा और छोटा करते हैं
• हमें अलग-अलग घटनाओं के लिए और अधिक बारीक चिह्नों की आवश्यकता है, विशेष रूप से यहां, शामिल होने की प्रक्रिया से संबंधित घटनाएं (सामग्री आइकन लाइब्रेरी में उपयुक्त आइकन ढूंढना कठिन हो सकता है, इसलिए हमें जल्द ही अपना खुद का आइकन सेट बनाने की आवश्यकता हो सकती है cc @pierrephz )
  
  
  
  • संबंधित घटनाओं में शामिल होने के लिए, हम फिलहाल के लिए link आइकन का उपयोग कर सकते हैं
  
  
• हमें (गैर-विजेट) ईवेंट घटक में क्षैतिज स्क्रॉलिंग का उपयोग करना चाहिए
• कुछ ईवेंट प्रकार के संदेश (जहाँ तक मैं बता सकता हूँ) अनावश्यक रूप से लंबे होते हैं, जैसे receive uplinke data message , क्या यह केवल receive uplink data नहीं हो सकता?
• यह सुनिश्चित करने के लिए <SafeInspector /> के और भी संकीर्ण संस्करण का उपयोग करें कि पंक्ति की ऊंचाई एक समान बनी रहे
• वर्तमान पेलोड प्रारूप फ़ंक्शन के माध्यम से frm_payload को पाइप करना और परिणाम को एक-पंक्ति JSON (स्क्रीन डिज़ाइन देखें) के रूप में प्रदर्शित करना बहुत बढ़िया होगा। मैं इसे फिलहाल के लिए सोना चढ़ाना के रूप में मानता हूं।

क्या हमारे पास dev_addr के लिए एक कॉलम हो सकता है, और इसे सभी अपलिंक संदेशों के लिए भर सकते हैं और शामिल होने वाले स्वीकार कर सकते हैं?

आइए इसे Data कॉलम में एक ढीले तत्व के रूप में जोड़ें।

मैं JoinEUI और DevEUI को छोटे टेक्स्ट जैसे JoinEUI और DevEUI के साथ जोड़ दूंगा ताकि उपयोगकर्ता जान सकें कि कौन सा है

हां। @bafonins , वास्तव में यह वही है जो मेरा मतलब सुस्त था। वहां पर्याप्त स्पष्ट नहीं होने के लिए खेद है।

मैं इसके बजाय "फॉरवर्ड डेटा अपलिंक संदेश" टेक्स्ट को एक आइकन (या आइकन; एएस + अपलिंक + डेटा) में बदल दूंगा।

"एक पाठ एक हजार से अधिक चिह्न कहता है" . मैं वास्तव में ईवेंट प्रकार कॉलम को टेक्स्ट के रूप में रखना चाहता हूं। केवल आइकनों के माध्यम से इसकी सामग्री को संप्रेषित करना असंभव है।

यहां दो स्क्रीन डिज़ाइन हैं जो दिखाते हैं कि मुझे क्या लगता है कि एप्लिकेशन और डिवाइस परत के लिए एक व्यवहार्य समाधान है।

एकल संस्थाओं (अंतिम उपकरणों, गेटवे) के डेटा दृश्यों में हम इकाई आईडी कॉलम को हटा सकते हैं, क्योंकि यह बेमानी है

समझ में आता है

हमें विभिन्न आयोजनों के लिए और अधिक सूक्ष्म चिह्नों की आवश्यकता है, विशेष रूप से यहां, शामिल होने की प्रक्रिया से संबंधित कार्यक्रम

न केवल प्रवाह में शामिल होने के लिए। मैक कमांड के लिए एक कस्टम आइकन होना अच्छा होगा ( ns.mac.* )।

कुछ ईवेंट प्रकार के संदेश (जहाँ तक मैं बता सकता हूँ) अनावश्यक रूप से लंबे होते हैं, उदाहरण के लिए अपलिंक डेटा संदेश प्राप्त करना, क्या यह केवल अपलिंक डेटा प्राप्त नहीं हो सकता है?

सहमत हूं, यह कई त्रुटि विवरणों का नाम बदलने की बात है। यह receive uplink data या receive uplink message हो सकता है। @johanstokking आपको क्या लगता है?

वर्तमान पेलोड प्रारूप फ़ंक्शन के माध्यम से frm_payload को पाइप करना और परिणाम को एक-पंक्ति JSON (स्क्रीन डिज़ाइन देखें) के रूप में प्रदर्शित करना बहुत बढ़िया होगा।

हम decoded_payload सीधे प्रदर्शित कर सकते हैं, है ना? अपलिंक संदेशों के लिए ApplicationUp की संरचना है:

{
  "uplink_message": {
    ...
    "frm_payload": "AQ==",
    "decoded_payload": {
      "led": "ON"
    }
    ...
}

मैं JoinEUI और DevEUI को छोटे टेक्स्ट जैसे JoinEUI और DevEUI के साथ जोड़ दूंगा ताकि उपयोगकर्ता जान सकें कि कौन सा है

हां। @bafonins , वास्तव में यह वही है जो मेरा मतलब सुस्त था। वहां पर्याप्त स्पष्ट नहीं होने के लिए खेद है।

मैं

न केवल प्रवाह में शामिल होने के लिए। मैक कमांड (ns.mac.*) के लिए एक कस्टम आइकन होना अच्छा होगा।

वास्तव में।

हम सीधे डीकोडेड_पेलोड प्रदर्शित कर सकते हैं, है ना? अपलिंक संदेशों के लिए ApplicationUp की संरचना है:

ओह, बिल्कुल ‍

• उदाहरण के लिए receive uplinke data message , क्या यह सिर्फ receive uplink data नहीं हो सकता?

हां। लेकिन क्या हमारे पास "प्राप्त" बनाम "आगे" बनाम "भेजें" आदि के लिए एक आइकन हो सकता है?

मैं वास्तव में ईवेंट प्रकार कॉलम को टेक्स्ट के रूप में रखना चाहता हूं। केवल आइकनों के माध्यम से इसकी सामग्री को संप्रेषित करना असंभव है।

न केवल, बल्कि जैसा आपने भी सुझाव दिया है, हम कुछ स्पष्ट चीजों को चिह्नों से बदल सकते हैं, है ना?

क्या हमारे पास dev_addr के लिए एक कॉलम हो सकता है, और इसे सभी अपलिंक संदेशों के लिए भर सकते हैं और शामिल होने वाले स्वीकार कर सकते हैं?

आइए इसे Data कॉलम में एक ढीले तत्व के रूप में जोड़ें।

बात यह है कि यह डिवाइस सक्रियण सहित _every_ अपस्ट्रीम संदेश का हिस्सा है (जहां हम नया DevAddr दिखा सकते हैं)। तो आपके पहले डिज़ाइन में, DevAddr संरेखित नहीं है (यह दाईं ओर है), क्योंकि यह ढीला है, मुझे लगता है?

इसके अलावा, ये डिज़ाइन वास्तव में अच्छे और मददगार लगते हैं

हां। लेकिन क्या हमारे पास "प्राप्त" बनाम "आगे" बनाम "भेजें" आदि के लिए एक आइकन हो सकता है?

मुझे लगता है कि हमें या तो इसे पूरी तरह से करना होगा या बिल्कुल नहीं करना होगा। मुझे लगता है कि केवल कुछ चीजों को आइकन से बदलना अधिक भ्रमित करने वाला होगा।

मुझे अभी भी आइटम द्वारा ईवेंट प्रकारों का प्रतिनिधित्व करने के सर्वोत्तम तरीके के बारे में सोचने की आवश्यकता है। मैं जो देख रहा हूं, उसमें तीन परतें हैं जो हैं: स्टैक घटक, प्रक्रिया या विषय और चरण (जैसे ns.up.data.forward )।
चूंकि इस सारी जानकारी को एक आइकन में अनुवाद करना वास्तव में संभव नहीं है, इसलिए हमें या तो कई आइकन का उपयोग करने की आवश्यकता है या हमेशा किसी एक घटना प्रकार की परतों पर ध्यान केंद्रित करना होगा, जैसे विषय।

तीन आइकन का उपयोग करना एक तरीका हो सकता है, लेकिन फिर से, मैं वास्तव में ईवेंट प्रकार के टेक्स्ट को बदलना नहीं चाहूंगा, इसलिए यह वास्तव में रिक्ति की समस्या में मदद नहीं करेगा, लेकिन कम से कम ईवेंट प्रविष्टियों को स्कैन करना आसान बना देगा।

बात यह है कि यह प्रत्येक अपस्ट्रीम संदेश का हिस्सा है, जिसमें डिवाइस सक्रियण (जहां हम नया DevAddr दिखा सकते हैं) शामिल हैं। तो आपके पहले डिज़ाइन में, DevAddr संरेखित नहीं है (यह दाईं ओर है), क्योंकि यह ढीला है, मुझे लगता है?

वास्तव में। लेकिन हम केवल एक कन्वेंशन के रूप में डिवाइस एड्रेस को हमेशा पहले रख सकते हैं। यदि हमारे पास एक समर्पित कॉलम है, तो हम अन्य सभी घटनाओं के लिए स्थान खो देंगे जिन्हें डिवाइस का पता दिखाने की आवश्यकता नहीं है।

तो इसे कार्रवाई योग्य रखने का मेरा सुझाव:

• आइए अभी के लिए आइकन और ईवेंट प्रकार के संदेश को स्पर्श न करें बल्कि एक अलग PR . में स्पर्श करें
• ईवेंट प्रकार की विशिष्ट आवश्यकताओं के आधार पर ढीले तत्वों के साथ डेटा कॉलम के लचीले रूप का उपयोग करें

@bafonins मुझे बताएं कि क्या आपको इस मुद्दे को जारी रखने के लिए किसी अन्य जानकारी या स्पष्टीकरण की आवश्यकता है।

तीन आइकन का उपयोग करना एक तरीका हो सकता है, लेकिन फिर से, मैं वास्तव में ईवेंट प्रकार के टेक्स्ट को बदलना नहीं चाहूंगा, इसलिए यह वास्तव में रिक्ति की समस्या में मदद नहीं करेगा, लेकिन कम से कम ईवेंट प्रविष्टियों को स्कैन करना आसान बना देगा।

हाँ, यह मुख्य उद्देश्य होगा।

जब हम उस पर होते हैं, तो हम सहसंबंध आईडी के आधार पर समूहीकरण पर भी विचार कर सकते हैं। यह दोनों रिक्ति (ऊर्ध्वाधर) आसान स्कैनिंग की सेवा करेगा।

वास्तव में। लेकिन हम केवल एक कन्वेंशन के रूप में डिवाइस एड्रेस को हमेशा पहले रख सकते हैं। यदि हमारे पास एक समर्पित कॉलम है, तो हम अन्य सभी घटनाओं के लिए स्थान खो देंगे जिन्हें डिवाइस का पता दिखाने की आवश्यकता नहीं है।

ठीक है

कुछ अपडेट:

1. हम डिवाइस, गेटवे और संगठन ईवेंट के लिए Entity ID कॉलम नहीं दिखाते हैं। केवल आवेदनों के लिए। यह कुछ अतिरिक्त स्थान बचाने में मदद करता है, विशेष रूप से उपकरणों के लिए।
2. त्रुटि घटना:

1. हम decoded_payload दिखाते हैं यदि मूल्यों की सादा सूची के रूप में उपलब्ध है। सरणियों या वस्तुओं जैसी किसी भी नेस्टेड प्रविष्टियों को छोड़ना (मैं कार्यान्वयन के साथ पालन करूंगा जो पेलोड मानों में रंग जोड़ता है)। उपलब्ध होने पर हम frm_payload को हेक्स के रूप में भी दिखाते हैं:

1. यहाँ शामिल प्रवाह का एक उदाहरण है:
   (आवेदन घटना दृश्य)

(डिवाइस घटना दृश्य)

1. AS डाउनलिंक ईवेंट के लिए frm_payload हेक्स में दिखाएं। यह कंसोल के माध्यम से डाउनलिंक शेड्यूल करने वाले लोगों के लिए मददगार हो सकता है:

@johanstokking क्या कुछ और है? क्या ऐसी कोई प्रविष्टियां हैं जिन्हें हम गेटवे ईवेंट के लिए दिखा सकते हैं ( gs.up.receive के लिए, उदाहरण के लिए, हम frm_payload f_cnt f_port दिखा सकते हैं)?

महान!

कुछ छोटी टिप्पणियाँ/प्रश्न;

• AS अपस्ट्रीम इवेंट के लिए, DevAddr . भी शामिल करें
• क्या अब इवेंट के नाम दिखा रहे हैं?
• मैं लोरावन शब्द DevAddr और FRMPayload . का उपयोग करूंगा
• डीकोडेड पेलोड आमतौर पर एक सपाट वस्तु होती है; {"temperature":21.5,"light":"on"} आदि। यदि कोई नेस्टेड मान है, तो मैं इसे छोड़ रहा हूं; यानी {"nested":{...},"light":"on"}

जीएस अपस्ट्रीम घटनाओं के लिए विशेष रूप से;

• वर्तमान में हम LoRaWAN raw_payload को डिकोड नहीं करते हैं, क्योंकि GS का LoRaWAN से कोई लेना-देना नहीं है। GS LoRaWAN आइडेंटिफ़ायर (EUIs on join, DevAddr on uplink) को डीकोड करता है, जिसे फ़िल्टरिंग के लिए इस स्ट्रीम में दिखाना दिलचस्प हो सकता है। संभावित समाधान:
  
  
  
  • ~ गरीब आदमी का समाधान; इसे दर्शक (कंसोल) पर छोड़ दें। हम V2 कंसोल में भी यही करते हैं। यह आदर्श नहीं है क्योंकि यह कंसोल में लोरावन तर्क जोड़ता है~
  
  
  • ~ घटना पेलोड में पहचानकर्ताओं में किसी तरह तार। वर्तमान में हम UplinkMessage प्रकाशित कर रहे हैं, जो DeviceUplinkMessage जैसा कुछ बनना चाहिए जो UplinkMessage ~
  
  
  • पेलोड को डीकोड करें, अगर फ्रंट-एंड ने पहले से ऐसा नहीं किया है (बेसिक स्टेशन करता है क्योंकि यह PHYPayload को फिर से बनाता है)
  
  
• वर्तमान में हम कई फॉरवर्ड इवेंट प्रकाशित कर रहे हैं यदि जीएस फॉरवर्ड टेबल में कई होस्ट हैं, यानी एनएस और पैकेट ब्रोकर। gs.up.forward के लिए ईवेंट पेलोड nil है। हम होस्ट नाम के साथ एक नया प्रोटो संदेश परिभाषित कर सकते हैं और हम एक map[string]string{} . पास कर सकते हैं

~ @htdvisser कृपया घटना पेलोड मामलों पर सलाह दें; यह विकास दिशानिर्देशों के अंतर्गत नहीं आता है।~

@johanstokking

AS अपस्ट्रीम ईवेंट के लिए, DevAddr . भी शामिल करें

तो, as.up.data.receive , as.up.data.forward के लिए? as.down.data.receive और as.down.data.forward के बारे में क्या?
मुझे लगता है कि हम इसे ns.up.data.* के लिए भी दिखाना चाहते हैं।

क्या अब इवेंट के नाम दिखा रहे हैं?

नहीं, हम पूरी घटना का विवरण वैसे ही दिखाएंगे जैसे अभी है।

मैं लोरावन शब्दों का प्रयोग करूंगा DevAddr और FRMPayload

आपका मतलब Device Address और Frame Payload के बजाय है?

डीकोडेड पेलोड आमतौर पर एक सपाट वस्तु होती है; {"temperature":21.5,"light":"on"} इत्यादि। यदि कोई नेस्टेड मान है, तो मैं उसे छोड़ रहा हूं; यानी {"नेस्टेड":{...},"लाइट":"ऑन"}

डिजाइनों के अनुसार, हम केवल मूल्य दिखाते हैं। तो, {"temperature":21.5,"light":"on"} के लिए हम [21.5, "on"] दिखाएंगे। क्या यह ठीक है?

जीएस लोरावन आइडेंटिफ़ायर (ईयूआई ऑन जॉइन, देवएड्र ऑन अपलिंक) को डिकोड करता है, जिसे फ़िल्टरिंग के लिए इस स्ट्रीम में दिखाना दिलचस्प हो सकता है

हम gs.up.receive के लिए पहचानकर्ता दिखा सकते हैं। शामिल होने के अनुरोध के लिए हम EUI को यहां से दिखा सकते हैं:

  "payload": {
    "join_request_payload": {
      "join_eui": "...",
      "dev_eui": "..."
    }
  }

और अपलिंक के लिए देव योजक दिखाएं:

  "payload": {
    "mac_payload": {
      "f_hdr": {
        "dev_addr": "...",
      }
    }
  }

तो, as.up.data.receive , as.up.data.forward के लिए? as.down.data.receive और as.down.data.forward के बारे में क्या?
मुझे लगता है कि हम इसे ns.up.data.* के लिए भी दिखाना चाहते हैं।

हां, यदि पहचानकर्ता पेलोड में हैं, तो उन्हें दिखाएं।

आपका मतलब Device Address और Frame Payload के बजाय है?

>

हां

डिजाइनों के अनुसार, हम केवल मूल्य दिखाते हैं। तो, {"temperature":21.5,"light":"on"} के लिए हम [21.5, "on"] दिखाएंगे। क्या यह ठीक है?

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

हम gs.up.receive के लिए पहचानकर्ता दिखा सकते हैं। शामिल होने के अनुरोध के लिए हम EUI को यहां से दिखा सकते हैं:

हाँ, लेकिन हमारे पास उन्हें पेलोड में नहीं है, है ना? उदाहरण के लिए यह पेलोड है:

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
  "raw_payload": "QOYAACeAws8CQ+4LarGLXmIEFQ==",
  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 7
      }
    },
    "coding_rate": "4/5",
    "frequency": "867900000",
    "timestamp": 2986005427,
    "time": "2020-04-29T07:57:06Z"
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "kerlink-ifemtocell",
        "eui": "7276FF003903007D"
      },
      "time": "2020-04-29T07:57:06Z",
      "timestamp": 2986005427,
      "rssi": -28,
      "channel_rssi": -28,
      "snr": 8,
      "uplink_token": "CiAKHgoSa2VybGluay1pZmVtdG9jZWxsEghydv8AOQMAfRCzp+uPCw==",
      "channel_index": 4
    }
  ],
  "received_at": "2020-04-29T07:57:06.748570190Z",
  "correlation_ids": [
    "gs:conn:01E6VEV9V14WMAY1DW19BQQPMX",
    "gs:uplink:01E72F0YSWJAKBYBJDBXG4CJ4G"
  ]
}

हां, यदि पहचानकर्ता पेलोड में हैं, तो उन्हें दिखाएं

पेलोड खाली होने पर हम ईवेंट के identifiers फ़ील्ड से पहचानकर्ता कर सकते हैं:

    "identifiers": [
      {
        "device_ids": {
          "device_id": "...",
          "application_ids": {
            "application_id": "...",
          },
          "dev_eui": "...",
          "join_eui": "...",
          "dev_addr": "...",
        },
      },
    ],

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

मैं

हाँ, लेकिन हमारे पास उन्हें पेलोड में नहीं है, है ना? उदाहरण के लिए यह पेलोड है:

मेरे पास receive uplink message - gs.up.receive के लिए यह है:

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
  "raw_payload": "AAEAUAEAy6BYiiAcAAujBAB5X7wJxJ0=",
  "payload": {
    "m_hdr": {},
    "mic": "vAnEnQ==",
    "join_request_payload": {
      "join_eui": "...",
      "dev_eui": "...",
      "dev_nonce": "..."
    }
  },
  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 7
      }
    },
    "coding_rate": "4/5",
    "frequency": "868300000",
    "timestamp": 3115131027,
    "time": "2020-04-29T08:13:09.690629005Z"
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "bafonins-ttig",
        "eui": "58A0CBFFFE8010D6"
      },
      "time": "2020-04-29T08:13:09.690629005Z",
      "timestamp": 3115131027,
      "rssi": -35,
      "channel_rssi": -35,
      "snr": 8.25,
      "uplink_token": "ChsKGQoNYmFmb25pbnMtdHRpZxIIWKDL//6AENYQk8G0zQs="
    }
  ],
  "received_at": "2020-04-29T08:13:09.450967669Z",
  "correlation_ids": [
    "gs:conn:01E7140GJKZ5BKHMC774RV4C11",
    "gs:uplink:01E72FYAYB272T9X90MJEZNEAX"
  ]
}

ठीक है, हाँ, उन्हें दिखाओ। वर्तमान में वे nil हो सकते हैं, इसलिए इसके लिए खाते हैं, लेकिन हम पेलोड को डीकोड करने के लिए जीएस को बदल सकते हैं यदि ऐसा अभी तक नहीं हुआ है।

@johanstokking

ईयूआई के साथ प्रवाह में शामिल हों जहां join_request_payload उपलब्ध है:

डीकोडेड पेलोड के साथ अपलिंक:

विफल घटना:

अपलिंक/डाउनलिंक ईवेंट के रूप में:

गेटवे अनुरोध घटना में शामिल हों:

mac_payload के साथ गेटवे अपलिंक :

विस्मयकारी

एक और अनुरोध; $#$ FRMPayload . की प्रत्येक घटना से पहले कृपया FPort जोड़ें

https://github.com/TheThingsNetwork/lorawan-stack/pull/2477 द्वारा बंद