Lorawan-stack: コンソールトラフィックビューに参加要求、アップリンク、およびエラーを表示する

これを追加してくれてありがとうそれは「必需品」です
これは、AWS市場でv3を評価したときに最初に気づいたことの1つでした。
申し訳ありませんが、いつアイデアはありますか？

@industrialinternetご関心をお寄せいただきありがとうございます。 2月のマイルストーンに設定されているので、今月終了することを目指しています。 この問題をサブスクライブし、上部の[監視]をクリックして、少なくともリリースについてはこのリポジトリを監視してください。これにより、どのリリースにいつ到達するかがわかります。

@johanstokking

as.up.forwardイベント本体を検討してください。

ここでas.up.data.forwardという意味ですか？

1. あなたが言及したフィールドは、各イベントタイプに対して（イベント操作が成功した場合）常にそこにあると想定できますか？
2. イベントウィジェットコンポーネント（エンティティの概要ページの1つ）に含める必要のあるフィールドは何ですか？
   
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.イベントウィジェットコンポーネント（エンティティの概要ページの1つ）に含める必要のあるフィールドは何ですか？

スペースが少ない場合はどういう意味ですか？ データアップリンクの場合はデコードされたペイロード、参加の場合はDevEUIを受け入れます。

1. decoded_payloadオブジェクトの大きさはどれくらいですか？ イベントuiで切り捨てられる可能性があるため、質問します。

行では、それを切り捨てても問題ありません。 行を展開すると、JSONとして表示されます。 実際にはかなり大きくなる可能性があります。デバイスメーカーまたはアプリケーション開発者次第です。

しかし、ほとんどは{"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}のようなものです

ここで元のコメントを更新しました

こんにちはヨハンとこの問題に関係する他の人

あなたたちが2月の「ミルストーン」を持っていると聞いてうれしいです。
V3コンソールを評価しているので、ここでは多くのことができます。開発者向けの優れた製品を作成するための簡単な方法だと思います。 と管理

1）アプリケーション全体またはノードに個別にダウンリンクを送信する可能性
2）アップリンクペイロードHEXを表示し、別のウィンドウでデコードできる
3）アプリケーションディレクトリfxのある種の階層。 親/子/ノード

自社のサーバーに接続されたTTIを使用することを計画している場合でも、これはR＆Dと監視のための優れた追加になります。

とにかく-これまでのところ素晴らしい仕事です:-)

BR
/ A

重要度の順序;

1. 参加リクエストではids.join_eui 、 ids.dev_eui 、 ids.dev_addr $、アップリンクメッセージではids.dev_addr 、 uplink_message.frm_payloadの16進表示
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）である可能性があります。 これは、後でイベントのフィルタリングを追加し、一部のクラスターでは、すべてのコンポーネントが使用可能であるとは限らず（JSのみのように）、識別子を確認したいためです。

識別子の順序に注意してください： dev_addrとfrm_payload 。

よし、ここにもFRMPayloadを追加する

アップリンクフローの残りのイベントについてもdev_addrを表示できると思います。

はい、それは上記のポイント1です。 私はそれに同意します。

ここで私が見ている問題は、特に結合フローのas.up.join.forwardイベントの場合、実際には多くのスペースがないことです。 さらに、値だけでは実際には多くの情報が得られず、ラベル（ Dev Addr: .... ）を追加するとスペースがさらに少なくなります。

イベントテキストを保持するために情報を削除するのではなく、「転送データアップリンクメッセージ」テキストをアイコン（またはアイコン; AS +アップリンク+データ）に変換したいと思います。 同意する場合は、 @ pierrephzにアイコンのデザインを依頼できます。 cc @kschiffer

元のフォーマットされていないエラーをペイロードインスペクターに保持することに注意してください。 これはデバッグに役立つ場合があります。

エラーについて合意

いくつかの考え：

• 単一のエンティティ（エンドデバイス、ゲートウェイ）のデータビューでは、冗長であるため、 Entity ID列を削除できます。
• それ以外の場合は、 Entity ID列をもう少し縮小しましょう
• さまざまなイベント、特にここでは、結合手順に関連するイベントに対して、よりきめ細かいアイコンが必要です（マテリアルアイコンライブラリで適切なアイコンを見つけるのがますます難しくなる可能性があるため、すぐに独自のアイコンセットを作成する必要がありますcc @pierrephz ）。
  
  
  
  • 参加関連のイベントについては、当面はlinkアイコンを使用できます
  
  
• （非ウィジェット）イベントコンポーネントで水平スクロールを利用する必要があります
• 一部のイベントタイプのメッセージは（私が知る限り）不必要に長くなります。たとえば、 receive uplinke data messageのように、 receive uplink dataだけではないでしょうか。
• <SafeInspector />のさらに狭いバージョンを使用して、の行の高さが一定に保たれるようにします
• frm_payloadを現在のペイロード形式関数にパイプして結果を1行のJSONとして表示するのは素晴らしいことです（screendesignsを参照）。 とりあえずこれを金メッキと考えても大丈夫です。

dev_addrの列を作成し、それをすべてのアップリンクメッセージに入力して、発生する参加受け入れを行うことはできますか？

それをData列の緩い要素として追加しましょう。

JoinEUIとDevEUIの前に、JoinEUIとDevEUIのような小さなテキストを追加して、ユーザーがどちらがどちらであるかがわかるようにします。

はい。 @bafonins 、これは実際に私がたるみで意味したことです。 そこに十分に明確ではないことをお詫び申し上げます。

「転送データアップリンクメッセージ」のテキストをアイコン（またはアイコン; AS +アップリンク+データ）に変換したいと思います。

「テキストには10​​00以上のアイコンが書かれています」😅。 イベントタイプの列をテキストのままにしておきたいのですが。 アイコンだけでコンテンツを伝えることはできません。

これは、アプリケーションとデバイスレイヤーの実行可能なソリューションであると私が考えるものを示す2つの画面デザインです。

単一のエンティティ（エンドデバイス、ゲートウェイ）のデータビューでは、冗長であるため、[エンティティID]列を削除できます

👍は理にかなっています

さまざまなイベント、特にここでは、参加手順に関連するイベントに対して、よりきめ細かいアイコンが必要です。

結合フローだけではありません。 MACコマンド用のカスタムアイコン（ ns.mac.* ）があると便利です。

一部のイベントタイプのメッセージは（私が知る限り）不必要に長くなります。たとえば、アップリンクデータメッセージを受信するだけでは、アップリンクデータを受信するだけではないでしょうか。

同意します。いくつかのエラーの説明の名前を変更するだけです。 receive uplink dataまたはreceive uplink messageの場合があります。 @johanstokkingどう思いますか？

frm_payloadを現在のペイロード形式関数にパイプ処理し、結果を1行のJSONとして表示するのは素晴らしいことです（screendesignsを参照）。

decoded_payloadを直接表示できますよね？ アップリンクメッセージのApplicationUpの構造は次のとおりです。

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

JoinEUIとDevEUIの前に、JoinEUIとDevEUIのような小さなテキストを追加して、ユーザーがどちらがどちらであるかがわかるようにします。

はい。 @bafonins 、これは実際に私がたるみで意味したことです。 そこに十分に明確ではないことをお詫び申し上げます。

👌

結合フローだけではありません。 MACコマンド用のカスタムアイコン（ns.mac。*）があると便利です。

それはそう。

decode_payloadを直接表示できますよね？ アップリンクメッセージのApplicationUpの構造は次のとおりです。

ああ、もちろん🤦‍♂

• 例： receive uplinke data message 、 receive uplink dataだけではないでしょうか？

はい。 しかし、「受信」、「転送」、「送信」などのアイコンを設定できますか？

イベントタイプの列をテキストのままにしておきたいのですが。 アイコンだけでコンテンツを伝えることはできません。

だけでなく、あなたが提案したように、私たちはいくつかの明白なものをアイコンに置き換えることができますよね？

dev_addrの列を作成し、それをすべてのアップリンクメッセージに入力して、発生する参加受け入れを行うことはできますか？

それをData列の緩い要素として追加しましょう。

これは、デバイスのアクティブ化（新しいDevAddrを表示できる）を含む、_every_アップストリームメッセージの一部であるということです。 したがって、最初のデザインでは、 DevAddrは位置合わせされていません（右側にあります）。緩いためだと思いますか？

それ以外は、これらのデザインは本当に良くて役立つように見えます

はい。 しかし、「受信」、「転送」、「送信」などのアイコンを設定できますか？

私たちはそれをずっとやらなければならないか、まったくやらなくてはならないと思います。 一部のものだけをアイコンに置き換えると、もっと混乱するだろうと思います。

イベントタイプをアイテムで表すための最良の方法を考える必要があります。 私が見るところ、スタックコンポーネント、プロセスまたはサブジェクト、およびステップ（ ns.up.data.forwardなど）の3つのレイヤーがあります。
このすべての情報を1つのアイコンに変換することは実際には不可能であるため、複数のアイコンを使用するか、件名などのイベントタイプレイヤーの1つに常に焦点を当てる必要があります。

3つのアイコンを使用することもできますが、イベントタイプのテキストを置き換えたくないので、間隔の問題にはあまり役立ちませんが、少なくともイベントエントリのスキャンが容易になります。

これは、デバイスのアクティブ化（新しいDevAddrを表示できる場所）を含むすべてのアップストリームメッセージの一部であるということです。 したがって、最初の設計では、DevAddrは位置合わせされていません（右側にあります）。緩いためだと思いますか？

それはそう。 ただし、慣例として、デバイスアドレスを常に最初に置くことができます。 専用の列がある場合、デバイスアドレスを表示する必要のない他のすべてのイベントのためのスペースが失われます。

したがって、これを実行可能に保つための私の提案：

• 今のところアイコンとイベントタイプのメッセージには触れないで、別のPRに入れましょう
• イベントタイプの特定のニーズに基づいた緩い要素を使用して、柔軟な形式のデータ列を使用します

@bafoninsは、この問題を続行するために他の情報や説明が必要な場合はお知らせください。

3つのアイコンを使用することもできますが、イベントタイプのテキストを置き換えたくないので、間隔の問題にはあまり役立ちませんが、少なくともイベントエントリのスキャンが容易になります。

ええ、それが主な目的です。

その間、相関IDによるグループ化も検討することをお勧めします。 これにより、両方の間隔（垂直）のスキャンが容易になります。

それはそう。 ただし、慣例として、デバイスアドレスを常に最初に置くことができます。 専用の列がある場合、デバイスアドレスを表示する必要のない他のすべてのイベントのためのスペースが失われます。

わかった

いくつかの更新：

1. デバイス、ゲートウェイ、および組織のイベントのEntity ID列は表示されません。 アプリケーションのみ。 これは、特にデバイスの場合、余分なスペースを節約するのに役立ちます。
2. エラーイベント：

1. 値のプレーンリストとして利用可能な場合は、 decoded_payloadを表示します。 配列やオブジェクトなどのネストされたエントリをスキップします（ペイロード値に色を追加する実装をフォローアップします）。 また、利用可能な場合は、 frm_payloadを16進数として表示します。

1. 結合フローの例を次に示します。
   （アプリケーションイベントビュー）

（デバイスイベントビュー）

1. ASダウンリンクイベントの16進数でfrm_payloadを表示します。 これは、コンソールを介してダウンリンクをスケジュールする人に役立つ可能性があります。

@johanstokking他に何かありますか？ ゲートウェイイベントに表示できるエントリはありますか（たとえば、 gs.up.receiveの場合、 frm_payload f_cnt f_portを表示できます）？

素晴らしい！

いくつかのマイナーなコメント/質問;

• ASアップストリームイベントの場合は、 DevAddrも含めます
• 現在、イベント名を表示していますか？
• LoRaWANの用語DevAddrとFRMPayloadを使用します
• デコードされたペイロードは通常、フラットオブジェクトです。 {"temperature":21.5,"light":"on"}など。ネストされた値がある場合は、それをスキップしても問題ありません。 つまり{"nested":{...},"light":"on"}

特にGSアップストリームイベントの場合。

• GSはLoRaWANと（多くの）関係がないため、現在、LoRaWAN raw_payloadをデコードしていません。 GSはLoRaWAN識別子（参加時のEUI、アップリンク時のDevAddr）をデコードします。これは、フィルタリングのためにこのストリームに表示するのに興味深い場合があります。 考えられる解決策：
  
  
  
  • 〜貧乏人の解決策; これはビューア（コンソール）に任せてください。 これは、V2コンソールでも行うことです。 コンソールにLoRaWANロジックを追加するため、理想的ではありません〜
  
  
  • 〜どういうわけか、イベントペイロードの識別子を配線します。 現在、 UplinkMessageを公​​開しています。これは、 UplinkMessage DeviceUplinkMessageのようなものになるはずです。
  
  
  • フロントエンドがまだ実行していない場合は、ペイロードをデコードします（Basic StationはPHYPayloadを再構築するため実行します）
  
  
• 現在、GS転送テーブルに複数のホスト（NSとPacket Broker）がある場合、複数の転送イベントを公開しています。 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.*についても同じことを示したいと思います。

現在、イベント名を表示していますか？

いいえ、イベントの完全な説明をそのまま表示します。

LoRaWANの用語であるDevAddrとFRMPayloadを使用します

Device AddressとFrame Payloadの代わりに？

デコードされたペイロードは通常、フラットオブジェクトです。 {"temperature"：21.5、 "light"： "on"}など。ネストされた値がある場合は、スキップしても問題ありません。 すなわち{"nested"：{...}、 "light"： "on"}

デザインによると、値のみを表示します。 したがって、 {"temperature":21.5,"light":"on"}の場合、 [21.5, "on"]を表示します。 これでいいですか？

GSはLoRaWAN識別子（参加時のEUI、アップリンク時のDevAddr）をデコードします。これは、フィルタリングのためにこのストリームに表示するのが興味深い場合があります

gs.up.receiveの識別子を表示できます。 参加リクエストの場合、EUIを次の場所から表示できます。

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

そして、次のアップリンクのdevaddrを表示します。

  "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である可能性があるため、それを考慮に入れてください。ただし、まだ発生していない場合は、GSを変更してペイロードをデコードできます。

@johanstokking

join_request_payloadが利用可能なeuiのフローに参加します。

デコードされたペイロードとのアップリンク：

失敗したイベント：

ASアップリンク/ダウンリンクイベント：

ゲートウェイ参加要求イベント：

mac_payloadのゲートウェイアップリンク：

素晴らしい

もう1つのリクエスト。 FRMPayloadが発生するたびに、 FPortを追加してください

https://github.com/TheThingsNetwork/lorawan-stack/pull/2477によって閉じられました