Lorawan-stack: إظهار طلب الانضمام والوصلة الصاعدة والأخطاء في عرض حركة مرور وحدة التحكم

شكرا لإضافته هذا "يجب أن يكون"
كان من أول الأشياء التي لاحظناها عند تقييم الإصدار 3 في سوق AWS.
آسف للسؤال ، أي فكرة متى؟

شكرا industrialinternet لإبداء اهتمامك. تم تعيينه في معلم فبراير لذا هدفنا هو الانتهاء منه هذا الشهر. يرجى الاشتراك في هذه المشكلة ومشاهدة هذا المستودع ، على الأقل بالنسبة للإصدارات ، من خلال النقر فوق "مشاهدة" في الجزء العلوي ، حتى تعرف متى يصل إلى أي إصدار.

تضمين التغريدة

ضع في اعتبارك هيئات الأحداث مثل up.forward:

أعتقد أنك تعني as.up.data.forward هنا؟

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

أعتقد أنك تعني 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 ؟ السؤال لأنه قد يتم اقتطاعه في واجهة المستخدم الخاصة بالحدث.

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

ولكن معظمها يشبه {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

تم تحديث التعليق الأصلي هنا

مرحبًا جوهان والآخرين المتورطين في هذا الأمر

يسعدني سماع أن لديكما "علامة مميزة" لشهر فبراير.
كما نراه يقيِّم وحدة التحكم V3 ، يمكن فعل الكثير هنا باستخدام وسائل بسيطة أعتقد أنها تقدم منتجًا متميزًا للتطوير. والإدارة

1) إمكانية إرسال روابط هابطة إلى التطبيق بأكمله أو العقدة بشكل منفصل
2) أن تكون قادرًا على رؤية حمولة الوصلة الصاعدة HEX وفك تشفيرها في نافذة منفصلة
3) نوع من التسلسل الهرمي لدليل التطبيقات fx. الوالد / الطفل / العقدة

حتى إذا كنا نخطط لاستخدام TTI المتصل بخوادمنا الخاصة ، فسيكون هذا إضافة ممتازة للبحث والتطوير والمراقبة

على أي حال - عمل جميل حتى الآن يا رجل :-)

BR
/أ

الترتيب من حيث الأهمية؛

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 ):

لاحظ أننا نحتفظ بالخطأ الأصلي غير المنسق في مفتش الحمولة النافعة. قد يكون هذا مفيدًا في التصحيح.

• جارٍ إظهار الحمولة المنقولة التي تم فك شفرتها - لاستخدامها لاحقًا

johanstokkingkschiffer هل من اقتراحات هنا؟

خطوات أولى رائعة!

لاحظ ترتيب المعرفات: join_eui ، dev_eui و dev_addr

بعض التعليقات / الأسئلة:

1. هل يمكن أن يكون لدينا عمود لـ dev_addr ، ونملأ ذلك لجميع رسائل الارتباط الصاعد ويقبل الانضمام الذي يحدث؟
2. أود إرفاق JoinEUI و DevEUI مسبقًا بنص صغير مثل JoinEUI و DevEUI حتى يعرف المستخدمون أيهما
3. اعرض المعرفات لكل رسالة نعرفها ، لذلك قد يكون هذا للعديد من الصفوف نفس المعرفات (JS / NS / AS). هذا لأننا نضيف تصفية للأحداث لاحقًا وفي بعض المجموعات ، لا تتوفر جميع المكونات (مثل JS-only) وما زلنا نريد رؤية المعرفات

لاحظ ترتيب المعرفات: dev_addr و frm_payload .

جيد ، هنا أيضًا تعتمد FRMPayload

أعتقد أنه يمكننا أيضًا إظهار dev_addr لبقية الأحداث في تدفق الارتباط الصاعد.

نعم ، هذه النقطة 1 أعلاه. أنا أتفق مع ذلك.

المشكلة التي أراها هنا هي أنه ليس لدينا مساحة كبيرة بالفعل ، خاصة بالنسبة للحدث as.up.join.forward في تدفق الانضمام. علاوة على ذلك ، فإن القيم فقط لا تعطي الكثير من المعلومات حقًا وإضافة الملصقات ( Dev Addr: .... ) ستترك مساحة أقل.

أفضل تحويل نص "رسالة الارتباط الصاعد لبيانات إعادة التوجيه" إلى رمز (أو رموز ؛ AS + ارتباط + بيانات) ، بدلاً من إزالة المعلومات للاحتفاظ بنص الحدث. يمكننا أن نطلب من pierrephz تصميم أيقونات إذا وافقنا. cckschiffer

لاحظ أننا نحتفظ بالخطأ الأصلي غير المنسق في مفتش الحمولة النافعة. قد يكون هذا مفيدًا في التصحيح.

متفقون على الأخطاء

زوجان من الأفكار:

• في طرق عرض البيانات للكيانات الفردية (الأجهزة الطرفية ، البوابات) يمكننا إزالة العمود Entity ID ، لأنه فائض عن الحاجة
• وإلا فلنقلص العمود Entity ID أكثر قليلاً
• نحتاج إلى المزيد من الرموز الدقيقة للأحداث المختلفة ، خاصة هنا ، الأحداث المتعلقة بإجراء الانضمام (قد يصبح من الصعب بشكل متزايد العثور على الرموز المناسبة في مكتبة رمز المواد ، لذلك قد نحتاج إلى إنشاء رمز خاص بنا تم تعيينه قريبًا ccpierrephz )
  
  
  
  • للانضمام إلى الأحداث ذات الصلة ، يمكننا استخدام رمز link في الوقت الحالي
  
  
• يجب أن نستخدم التمرير الأفقي في مكون الحدث (غير عنصر واجهة المستخدم)
• بعض رسائل نوع الحدث (بقدر ما أستطيع أن أقول) طويلة بلا داع ، على سبيل المثال receive uplinke data message ، ألا يمكن أن تكون receive uplink data فقط؟
• استخدم إصدارًا أضيق من <SafeInspector /> للتأكد من أن ارتفاعات الصف تظل متسقة
• سيكون من الرائع تمرير frm_payload من خلال وظيفة تنسيق الحمولة الحالية وعرض النتيجة على هيئة JSON من سطر واحد (انظر screendesigns). أنا بخير أن أعتبر هذا طلاءًا ذهبيًا في الوقت الحالي.

هل يمكننا الحصول على عمود لـ dev_addr ، وملئه لجميع رسائل الارتباط الصاعد ويقبل الانضمام الذي يحدث؟

دعنا نضيف ذلك كعنصر فضفاض في العمود Data .

أود إرفاق JoinEUI و DevEUI مسبقًا بنص صغير مثل JoinEUI و DevEUI حتى يعرف المستخدمون أيهما

نعم. bafonins ، هذا في الواقع ما قصدته في Slack. آسف لعدم الوضوح الكافي هناك.

أفضل تحويل نص "رسالة الارتباط الصاعد لبيانات إعادة التوجيه" إلى رمز (أو رموز ؛ AS + ارتباط + بيانات).

"النص يقول أكثر من ألف رمز" 😅. أريد حقًا الاحتفاظ بعمود نوع الحدث كنص. من المستحيل توصيل محتواها عبر الرموز فقط.

فيما يلي تصميمان للشاشة يوضحان ما أعتقد أنه حل قابل للتطبيق لطبقة التطبيق والجهاز.

في طرق عرض البيانات للكيانات الفردية (الأجهزة الطرفية ، البوابات) يمكننا إزالة عمود معرف الكيان ، نظرًا لأنه فائض عن الحاجة

👍 منطقي

نحتاج إلى المزيد من الرموز الدقيقة للأحداث المختلفة ، خاصة هنا ، الأحداث المتعلقة بإجراء الانضمام

ليس فقط لتدفق الانضمام. سيكون من الجيد أن يكون لديك رمز مخصص لأوامر MAC ( ns.mac.* ).

بعض رسائل نوع الحدث (بقدر ما أستطيع أن أقول) طويلة بلا داع ، على سبيل المثال تلقي رسالة بيانات الوصلة الصاعدة ، ألا يمكن أن تكون مجرد تلقي بيانات الوصلة الصاعدة؟

موافق ، إنها مجرد مسألة إعادة تسمية العديد من أوصاف الأخطاء. يمكن أن يكون receive uplink data أو receive uplink message . johanstokking ما رأيك؟

سيكون من الرائع توجيه frm_payload عبر وظيفة تنسيق الحمولة الحالية وعرض النتيجة على هيئة JSON من سطر واحد (انظر screendesigns).

يمكننا عرض decoded_payload مباشرة ، أليس كذلك؟ بنية ApplicationUp لرسائل الوصلة الصاعدة هي:

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

أود إرفاق JoinEUI و DevEUI مسبقًا بنص صغير مثل JoinEUI و DevEUI حتى يعرف المستخدمون أيهما

نعم. bafonins ، هذا في الواقع ما قصدته في Slack. آسف لعدم الوضوح الكافي هناك.

👌

ليس فقط لتدفق الانضمام. سيكون من الجيد أن يكون لديك رمز مخصص لأوامر MAC (ns.mac. *).

بالفعل.

يمكننا عرض decoded_payload مباشرة ، أليس كذلك؟ هيكل ApplicationUp لرسائل الوصلة الصاعدة هو:

أوه بالطبع 🤦‍♂

• على سبيل المثال ، receive uplinke data message ، ألا يمكن أن يكون receive uplink data فقط؟

نعم. ولكن هل يمكننا الحصول على رمز "تلقي" مقابل "إعادة توجيه" مقابل "إرسال" وما إلى ذلك؟

أريد حقًا الاحتفاظ بعمود نوع الحدث كنص. من المستحيل توصيل محتواها عبر الرموز فقط.

ليس فقط ، ولكن كما اقترحت أيضًا ، يمكننا استبدال بعض الأشياء الواضحة بالرموز ، أليس كذلك؟

هل يمكننا الحصول على عمود لـ dev_addr ، وملئه لجميع رسائل الارتباط الصاعد ويقبل الانضمام الذي يحدث؟

دعنا نضيف ذلك كعنصر فضفاض في العمود Data .

الشيء هو أن هذا جزء من _ كل_ رسالة أولية ، بما في ذلك عمليات تنشيط الجهاز (حيث يمكننا إظهار DevAddr الجديد). إذن في تصميمك الأول ، لم يتم محاذاة DevAddr (إنه على اليمين) ، لأنه فضفاض ، على ما أعتقد؟

بخلاف ذلك ، تبدو هذه التصميمات جيدة ومفيدة حقًا

نعم. ولكن هل يمكننا الحصول على رمز "تلقي" مقابل "إعادة توجيه" مقابل "إرسال" وما إلى ذلك؟

أعتقد أنه سيتعين علينا إما القيام بذلك على طول الطريق أو عدم القيام بذلك على الإطلاق. أعتقد أن استبدال بعض الأشياء بالأيقونات سيكون أكثر إرباكًا.

ما زلت بحاجة إلى التفكير في أفضل طريقة لتمثيل أنواع الأحداث حسب العناصر. من خلال ما أراه ، هناك ثلاث طبقات وهي: مكدس المكون أو العملية أو الموضوع (الموضوعات) والخطوة (على سبيل المثال ns.up.data.forward ).
نظرًا لأنه ليس من الممكن حقًا ترجمة كل هذه المعلومات إلى رمز واحد ، فنحن بحاجة إما إلى استخدام رموز متعددة أو التركيز دائمًا على إحدى طبقات نوع الحدث ، مثل الموضوع.

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

الشيء هو أن هذا جزء من كل رسالة أولية ، بما في ذلك عمليات تنشيط الجهاز (حيث يمكننا إظهار DevAddr الجديد). لذلك في تصميمك الأول ، لم يتم محاذاة DevAddr (إنه على اليمين) ، لأنه فضفاض ، على ما أعتقد؟

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

لذا اقتراحي إبقاء هذا قابلاً للتنفيذ:

• دعونا لا نلمس الرموز ورسالة كتابة الحدث في الوقت الحالي ولكن في علاقات عامة منفصلة
• استخدم نموذجًا مرنًا لعمود البيانات ، مع عناصر فضفاضة بناءً على الاحتياجات المحددة لنوع الحدث

bafonins اسمحوا لي أن أعرف إذا كنت بحاجة إلى أي معلومات أو توضيح آخر لمتابعة هذه المشكلة.

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

نعم سيكون هذا هو الهدف الرئيسي.

أثناء وجودنا في ذلك ، قد نرغب في التفكير في التجميع حسب معرف الارتباط أيضًا. سيخدم ذلك مسحًا أسهل للمسافات (الرأسية).

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

موافق

بعض التحديثات:

1. لا نعرض العمود Entity ID لأحداث الجهاز والبوابة والتنظيم. فقط للتطبيقات. يساعد هذا في توفير بعض المساحة الإضافية ، خاصة للأجهزة.
2. حدث الخطأ:

1. نعرض decoded_payload إذا كان ذلك متاحًا كقائمة بسيطة من القيم . تخطي أي إدخالات متداخلة مثل المصفوفات أو الكائنات (سأتابع التنفيذ الذي يضيف ألوانًا إلى قيم الحمولة). نعرض أيضًا frm_payload على شكل ست عشري عندما يكون ذلك متاحًا:

1. فيما يلي مثال على تدفق الانضمام:
   (عرض حدث التطبيق)

(عرض حدث الجهاز)

1. إظهار frm_payload في شكل سداسي عشري لأحداث الوصلة الهابطة AS. قد يكون هذا مفيدًا للأشخاص الذين يقومون بجدولة الروابط الهابطة عبر وحدة التحكم:

johanstokking هل هناك أي شيء آخر؟ هل هناك أي إدخالات يمكننا عرضها لأحداث البوابة (بالنسبة إلى gs.up.receive ، على سبيل المثال ، يمكننا إظهار frm_payload f_cnt f_port )؟

باهر!

بعض التعليقات / الأسئلة الطفيفة ؛

• لأحداث المنبع AS ، قم أيضًا بتضمين DevAddr
• يتم عرض أسماء الحدث الآن؟
• سأستخدم مصطلحات LoRaWAN DevAddr و FRMPayload
• عادة ما تكون الحمولة التي تم فك تشفيرها عبارة عن جسم مسطح ؛ {"temperature":21.5,"light":"on"} إلخ. إذا كانت هناك قيمة متداخلة ، فلا بأس في تخطيها ؛ أي {"nested":{...},"light":"on"}

لأحداث المنبع GS على وجه التحديد ؛

• لا نقوم حاليًا بفك تشفير LoRaWAN raw_payload ، لأن GS ليس لديها (الكثير) لتفعله مع LoRaWAN. تقوم GS بفك تشفير معرفات LoRaWAN (EUIs عند الانضمام ، DevAddr عند الارتباط الصاعد) ، والتي قد يكون من المثير للاهتمام عرضها في هذا الدفق للتصفية. الحلول الممكنة:
  
  
  
  • ~ حل الرجل المسكين ؛ اترك هذا الأمر للمشاهد (وحدة التحكم). هذا ما نفعله في V2 Console أيضًا. إنها ليست مثالية لأنها تضيف منطق LoRaWAN إلى وحدة التحكم ~
  
  
  • ~ سلك بطريقة ما في المعرفات في الحمولة النافعة للحدث. نقوم حاليًا بنشر UplinkMessage ، والذي يجب أن يصبح شيئًا مثل DeviceUplinkMessage الذي يتضمن UplinkMessage ~
  
  
  • فك شفرة الحمولة ، إذا لم تقم الواجهة الأمامية بذلك بالفعل (تقوم المحطة الأساسية بذلك لأنها تعيد بناء PHYPayload)
  
  
• نقوم حاليًا بنشر العديد من الأحداث المستقبلية إذا كان هناك مضيفون متعددون في جدول إعادة توجيه GS ، مثل NS و Packet Broker. حمولة الحدث لـ gs.up.forward هي nil . يمكننا تحديد رسالة أولية جديدة باسم المضيف ويمكننا تمرير map[string]string{}

~ htdvisser يرجى تقديم المشورة بشأن مسائل حمولة الحدث ؛ لا تغطي إرشادات التطوير هذا

تضمين التغريدة

لأحداث AS upstream ، قم أيضًا بتضمين DevAddr

إذن ، مقابل as.up.data.receive ، as.up.data.forward ؟ ماذا عن as.down.data.receive و as.down.data.forward ؟
أعتقد أننا نريد أيضًا إظهار نفس الشيء مقابل ns.up.data.* .

يتم عرض أسماء الحدث الآن؟

لا ، سنعرض الوصف الكامل للحدث كما هو الآن.

سأستخدم مصطلحات LoRaWAN DevAddr و FRMPayload

تقصد بدلاً من Device Address و Frame Payload ؟

عادة ما تكون الحمولة التي تم فك تشفيرها عبارة عن جسم مسطح ؛ {"temperature": 21.5، "light": "on"} إلخ. إذا كانت هناك قيمة متداخلة ، فلا بأس من تخطي ذلك ؛ مثل {"متداخل": {...}، "خفيف": "تشغيل"}

وفقًا للتصاميم ، نظهر القيم فقط. لذلك ، مقابل {"temperature":21.5,"light":"on"} ، سنعرض [21.5, "on"] . هل هذا جيد؟

تقوم GS بفك تشفير معرفات LoRaWAN (EUIs عند الانضمام ، DevAddr عند الارتباط الصاعد) ، والتي قد يكون من المثير للاهتمام عرضها في هذا الدفق للتصفية

يمكننا إظهار معرّفات gs.up.receive . لطلب الانضمام يمكننا إظهار EUI's من:

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

وإظهار عنوان dev للروابط الصاعدة من:

  "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's من:

نعم ولكن ليس لديناهم في الحمولة ، أليس كذلك؟ هذه هي الحمولة على سبيل المثال:

{
  "@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 ، لذا ضع في اعتبارك ذلك ، لكن يمكننا تغيير GS لفك تشفير الحمولة إذا لم يحدث ذلك بعد.

تضمين التغريدة

انضم إلى التدفق مع eui's حيث يتوفر join_request_payload :

الإرسال مع الحمولة التي تم فك تشفيرها:

حدث فاشل:

أحداث الوصلة الصاعدة / الهابطة:

حدث طلب الانضمام إلى البوابة:

الارتباط الصاعد للبوابة بـ mac_payload :

مدهش

طلب واحد آخر ؛ الرجاء إضافة FPort قبل كل تكرار لـ FRMPayload

مغلق بواسطة https://github.com/TheThingsNetwork/lorawan-stack/pull/2477