Lorawan-stack: عرض أحدث رسالة للوصلة الصاعدة و up- & downlink fcount

لست متأكدًا مما إذا كان هذا هو نفسه ، ولكن التحقق بسرعة من NS 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. (ABP) الجهاز الذي قد يقوم ResetsFCnt==true بإعادة تعيين FCnt نفسه من أجله
2. (OTAA) قد ينضم الجهاز مرة أخرى ، والذي في حد ذاته لن يعيد تعيين FCnt حتى الآن - FCnt يجب إما إعادة تعيينه أو زيادته اعتمادًا على معرّف مفتاح الجلسة المستخدم في الارتباط الصاعد التالي للبيانات المستلمة
3. FCnt في حمولة الارتباط الصاعد ليست بالضرورة الجهاز الفعلي FCnt ، لأنه يتم إرسال 16 LSB فقط في الوصلة الصاعدة ، بينما قد تكون عدادات الإطارات بعرض 32 بت.

يتم التعامل مع كل هذا بواسطة NS (و 2. جزئيًا بواسطة AS) ، وأنا بالتأكيد لا أعتقد أن وحدة التحكم ستفعل الشيء نفسه.

أعتقد أن الطريق إلى الأمام هو إضافة أحداث لـ (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 ، ويتم نشره عن طريق الخطأ حاليًا على كل ارتباط صاعد ، وسيتم نشره الآن فقط عند إعادة توجيهه بالفعل إلى AS (العلاقات العامة الواردة) ، أيضًا ، حمولة الارتباط الصاعد 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 الآن حدث ns.up.data.process ، والذي يحتوي على الارتباط الصاعد بحمولة كاملة FCnt

الرجاء استخدام القيمة الموجودة في الوصلة الصاعدة على أنها نشطة فعلية DevAddr و FCntUp للجهاز

بالنسبة إلى الروابط الهابطة ، ليس لدينا حاليًا وظائف مماثلة ، ولكن هذا أيضًا ليس محور هذه المشكلة ، فلنبدأ فقط بالوصلة الصاعدة FCnt ثم نضيف الوصلات الهابطة في مرحلة لاحقة (ملاحظة ، اعتمادًا على إصدار LoRaWAN ، قد يكون لدينا في الواقع رابطان مختلفان للوصلة الهابطة عدادات الإطارات - واحدة لـ NS وواحدة لـ AS ، لذا فهي أقل أهمية من عداد إطار الوصلة الصاعدة أيضًا.)

عندما نعرف آخر ارتباط صاعد في التطبيق ، فلنستبدل Linked بـ Last seen في عرض التطبيق (على غرار صفحة نظرة عامة على البوابة).

عندما نعرف آخر ارتباط صاعد في التطبيق ، فلنستبدل Linked بـ Last seen في عرض التطبيق (على غرار صفحة نظرة عامة على البوابة).

سيكون من الجيد بالتأكيد إظهار هذه المعلومات عالميًا للتطبيق ، ولكن القيام بذلك يعني أن وحدة التحكم تحتاج إلى فحص جميع الأجهزة الطرفية المرتبطة بالتطبيق واحدًا تلو الآخر ، لتتمكن من إظهار الحالة الأولية التي شوهدت مؤخرًا. لا أعتقد أن هذا قابل للتطبيق عندما يتعين علينا افتراض تطبيقات تحتوي على مئات أو آلاف الأجهزة الطرفية.

شيئان يمكنني التفكير فيهما:

1. يمكنني عرض آخر معلومات تمت رؤيتها عند توفرها من خلال الدفق الوارد لأحداث رسائل الجهاز. اعتمادًا على إعداد التطبيق ، قد يعني ذلك أنه لن تكون هناك مثل هذه الأحداث متاحة في الوقت المناسب (فكر في الأجهزة الطرفية التي ترسل روابط هابطة كل ساعة أو أقل تكرارًا).
2. يمكننا استخدام حد لعدد الأجهزة وبعد ذلك نتوقف عن حساب آخر قيمة تمت رؤيتها في البداية. إذا كان التطبيق يحتوي على أكثر من 100 جهاز ، فمن المحتمل أيضًا أن تصل أحداث الجهاز الضرورية بعد وقت قصير جدًا من تحميل صفحة التطبيق.

تضمين التغريدة بدلاً من ذلك ، هل يمكنك التفكير في أي طريقة لتجميع تلك البيانات وإتاحتها من خلال نقطة نهاية API؟

ApplicationLinkStats لديه last_up_received_at و last_downlink_forwarded_at :

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

مغلق عبر # 2585