Lorawan-stack: 最新のアップリンクメッセージとアップリンクおよびダウンリンクの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は、次に受信したデータアップリンクで使用されるセッションキーIDに応じて、リセットまたは増加します
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（PR着信）に転送された場合にのみ公開されるようになります。 、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は、ペイロードとして完全なFCntを含むアップリンクを含むns.up.data.processイベントを公開するようになりました

アップリンクの値を、デバイスの実際のアクティブなDevAddrおよびFCntUpとして使用してください

ダウンリンクについては、現在同様の機能はありませんが、それもこの問題の焦点では​​ありません。アップリンクFCntだけから始めて、後の段階でダウンリンクを追加しましょう（LoRaWANのバージョンによっては、実際には2つの異なるダウンリンクがある場合があることに注意してください）フレームカウンター-1つはNS用、もう1つはAS用なので、アップリンクフレームカウンターほど簡単ではありません。）

アプリケーションの最後のアップリンクがわかったら、アプリケーションビューでLinkedをLast seenに置き換えましょう（ゲートウェイの概要ページと同様）。

アプリケーションの最後のアップリンクがわかったら、アプリケーションビューでLinkedをLast seenに置き換えましょう（ゲートウェイの概要ページと同様）。

その情報をアプリケーションのグローバルに表示するのは間違いなく素晴らしいことですが、そうすることは、コンソールがアプリケーションに関連付けられているすべてのエンドデバイスを次々にプローブして、最初に最後に表示されたステータスを表示できるようにする必要があることを意味します。 数百または数千のエンドデバイスが存在する可能性のあるアプリケーションを想定する必要がある場合、これは実行可能ではないと思います。

私が考えることができる2つのこと：

1. デバイスメッセージイベントの着信ストリームを通じて利用可能になるときに、最後に表示された情報を表示できます。 ただし、アプリケーションの設定によっては、そのようなイベントがタイムリーに利用できないことを意味する場合があります（1時間ごとまたはそれ以下の頻度でダウンリンクを送信するエンドデバイスを考えてみてください）。
2. デバイス数のしきい値を使用できます。その後、最初に最後に表示された値の計算を停止します。 アプリケーションに100以上のデバイスがある場合、アプリケーションページをロードした直後に必要なデバイスイベントが到着する可能性も非常に高くなります。

@htdvisser @rvolosatovs何か見落としているのでしょうか？ または、そのデータを集約し、APIエンドポイントを介して利用できるようにする方法を考えられますか？

ApplicationLinkStatsにはlast_up_received_atとlast_downlink_forwarded_atがあります：

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

＃2585経由で閉鎖