Lorawan-stack: नवीनतम अपलिंक संदेश दिखाएं और अप और डाउनलिंक fcount

मुझे यकीन नहीं है कि यह वही है, लेकिन अस्तित्व के लिए एनएस के session को तुरंत जांचना, सक्रियण तिथि/समय और संभावित फ्रेम काउंटर बहुत उपयोगी होंगे।

@rvolosatovs क्या हम NS में "आखिरी बार देखा गया" टाइमस्टैम्प रख रहे हैं?

@rvolosatovs क्या हम NS में "आखिरी बार देखा गया" टाइमस्टैम्प रख रहे हैं?

नहीं, लेकिन इसे RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt ) से प्राप्त किया जा सकता है

@rvolosatovs क्या हम NS में "आखिरी बार देखा गया" टाइमस्टैम्प रख रहे हैं?

नहीं, लेकिन इसे RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt ) से प्राप्त किया जा सकता है

मैंने यही किया, लेकिन मुझे लगा कि पूरी कार्यक्षमता के लिए, हमें वास्तविक समय में संख्याओं को अद्यतन रखने के लिए ईवेंट स्ट्रीम में शामिल होना होगा।

मैंने यही किया, लेकिन मुझे लगा कि पूरी कार्यक्षमता के लिए, हमें वास्तविक समय में संख्याओं को अद्यतन रखने के लिए ईवेंट स्ट्रीम में शामिल होना होगा।

इससे पहले कि मैं आगे बढ़ूं और इसे इस तरह लागू करूं, @htdvisser क्या आपको लगता है कि दृष्टिकोण पूरी तरह से पर्याप्त है? अपलिंक डाउनलिंक घटनाओं में वर्तमान फ्रेम गणना नहीं होती है, इसलिए मुझे अंत डिवाइस के अंदर सत्र प्रोप से प्राप्त प्रारंभिक मूल्य के आधार पर उन्हें बढ़ाना होगा।

यह जाने का रास्ता नहीं है मुझे डर है।

क्या हम फ्रेम काउंटर साथ नहीं भेज रहे हैं? तब असली मुद्दा यही होगा।

@rvolosatovs क्या हम NS में "आखिरी बार देखा गया" टाइमस्टैम्प रख रहे हैं?

नहीं, लेकिन इसे RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt ) से प्राप्त किया जा सकता है

मैंने यही किया, लेकिन मुझे लगा कि पूरी कार्यक्षमता के लिए, हमें वास्तविक समय में संख्याओं को अद्यतन रखने के लिए ईवेंट स्ट्रीम में शामिल होना होगा।

दुर्भाग्य से, यह उतना आसान नहीं है जितना पहली नज़र में लगता है।

1. (एबीपी) डिवाइस, जिसके लिए ResetsFCnt==true FCnt को ही रीसेट कर सकता है
2. (OTAA) डिवाइस फिर से जुड़ सकता है, जो अपने आप में FCnt अभी तक रीसेट नहीं करेगा - FCnt को या तो रीसेट किया जाएगा या अगले प्राप्त डेटा अपलिंक में उपयोग की जाने वाली सत्र कुंजी आईडी के आधार पर बढ़ाया जाएगा
3. अपलिंक पेलोड में FCnt मूल्य जरूरी नहीं कि वास्तविक डिवाइस FCnt हो, क्योंकि अपलिंक में केवल 16 एलएसबी भेजे जाते हैं, जबकि फ्रेम काउंटर 32-बिट चौड़े हो सकते हैं।

यह सब एनएस (और 2. एएस द्वारा भाग में) द्वारा नियंत्रित किया जाता है, और मुझे निश्चित रूप से नहीं लगता कि कंसोल ऐसा ही करेगा।

मुझे लगता है कि आगे का रास्ता (1.) - ns.device.reset और (2.) - ns.device.confirm_session (या शायद ns.device.rejoin ?) के लिए ईवेंट जोड़ना है।
के लिए (3.) हमें कंसोल को पूर्ण FCnt मूल्य वितरित करने का एक तरीका निकालने की आवश्यकता है। हम एक और घटना शुरू करना चाह सकते हैं, उदाहरण के लिए ns.up.data.match , या ns.up.data.handle जो अपलिंक के सफल प्रसंस्करण को इंगित करता है और इसमें पूर्ण FCnt (और संभवतः अधिक) शामिल है। ध्यान दें, कि ns.up.data.forward यहां संबंधित नहीं है और केवल एएस को अपलिंक भेजे जाने का संकेत देता है, यह वर्तमान में गलती से प्रत्येक अपलिंक पर प्रकाशित हो गया है, अब इसे केवल तभी प्रकाशित किया जाएगा जब वास्तव में एएस (पीआर इनकमिंग) को अग्रेषित किया जा रहा हो। , AS अपलिंक पेलोड में पूरा FCnt नहीं होता है, लेकिन अपलिंक में भेजा गया FCnt होता है (इसलिए, 16 LSB)

जब तक हम इसे चलाने के लिए NS घटनाओं पर किसी निष्कर्ष पर नहीं पहुँचते और इसे NS में लागू किया जाता है, तब तक ब्लॉक किया जाता है।

ठीक है, मुझे लगता है कि इस समय यह वास्तव में संभव नहीं है। तब last seen मूल्य के बारे में क्या। क्या यह डिवाइस रजिस्ट्री से प्रारंभिक मूल्य प्राप्त करने के लिए सहेजा जाता है और फिर इसे प्रासंगिक डिवाइस ईवेंट (जैसे अपलिंक, कन्फर्म डाउनलिंक, आदि) के माध्यम से अपडेट रखा जाता है?

ठीक है, मुझे लगता है कि इस समय यह वास्तव में संभव नहीं है। तब last seen मूल्य के बारे में क्या। क्या यह डिवाइस रजिस्ट्री से प्रारंभिक मूल्य प्राप्त करने के लिए सहेजा जाता है और फिर इसे प्रासंगिक डिवाइस ईवेंट (जैसे अपलिंक, कन्फर्म डाउनलिंक, आदि) के माध्यम से अपडेट रखा जाता है?

हां, ns.up.data.receive , ns.up.join.receive , ns.up.rejoin.receive वह है जिसे आप ढूंढ रहे हैं

~ https://github.com/TheThingsNetwork/lorawan-stack/pull/2221 #2222~ द्वारा अवरोधित

एनएस अब ns.up.data.process घटना प्रकाशित करता है, जिसमें पेलोड के रूप में पूर्ण FCnt के साथ अपलिंक शामिल है

कृपया अपलिंक में मान का उपयोग डिवाइस के वास्तविक सक्रिय DevAddr और FCntUp के रूप में करें

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

जब हम एप्लिकेशन में अंतिम अपलिंक जानते हैं, तो आइए एप्लिकेशन दृश्य में Linked को Last seen से बदलें (गेटवे अवलोकन पृष्ठ के समान)।

जब हम एप्लिकेशन में अंतिम अपलिंक जानते हैं, तो आइए एप्लिकेशन दृश्य में Linked को Last seen से बदलें (गेटवे अवलोकन पृष्ठ के समान)।

एप्लिकेशन के लिए उस जानकारी को विश्व स्तर पर दिखाना निश्चित रूप से अच्छा होगा, लेकिन ऐसा करने का मतलब यह होगा कि कंसोल को एप्लिकेशन से जुड़े सभी अंतिम उपकरणों की एक के बाद एक जांच करने की आवश्यकता है, ताकि प्रारंभिक अंतिम बार देखी गई स्थिति दिखाने में सक्षम हो सके। मुझे नहीं लगता कि यह व्यवहार्य है जब हमें संभावित रूप से सैकड़ों या हजारों अंतिम उपकरणों के साथ अनुप्रयोगों को ग्रहण करना पड़ता है।

दो चीजें जो मैं सोच सकता था:

1. मैं आखिरी बार देखी गई जानकारी दिखा सकता हूं क्योंकि यह डिवाइस संदेश ईवेंट की आने वाली स्ट्रीम के माध्यम से उपलब्ध हो जाती है। एप्लिकेशन के सेटअप के आधार पर इसका मतलब यह हो सकता है कि ऐसी कोई घटना समय पर उपलब्ध नहीं होगी (अंतिम उपकरणों के बारे में सोचें जो हर घंटे या उससे कम बार डाउनलिंक भेजते हैं)।
2. हम डिवाइस गिनती की सीमा का उपयोग कर सकते हैं जिसके बाद हम शुरू में अंतिम बार देखे गए मूल्य की गणना करना बंद कर देते हैं। यदि किसी एप्लिकेशन में 100+ डिवाइस हैं, तो यह भी बहुत संभव है कि आवश्यक डिवाइस इवेंट एप्लिकेशन पेज लोड करने के तुरंत बाद आ जाएं।

@htdvisser @rvolosatovs क्या मैं शायद कुछ अनदेखा कर दूं? वैकल्पिक रूप से, क्या आप उस डेटा को एकत्र करने और उसे एपीआई एंडपॉइंट के माध्यम से उपलब्ध कराने के किसी भी तरीके के बारे में सोच सकते हैं?

ApplicationLinkStats बस एक last_up_received_at और last_downlink_forwarded_at है:

https://github.com/TheThingsNetwork/lorawan-stack/blob/develop/api/applicationserver.proto#L56 -L69

#2585 . के माध्यम से बंद