Lorawan-stack: コンソールでのデバイスMACレイヤー構成

作成日 2020年02月25日  ·  9コメント  ·  ソース: TheThingsNetwork/lorawan-stack

概要

デバイスのMACレイヤーは、コンソールから構成可能である必要があります。
https://github.com/TheThingsNetwork/lorawan-stack/issues/1378を置き換え

なぜ私たちはこれが必要なのですか?

  • コンソールからのクラスBデバイスの作成/更新
  • デフォルト以外のMACレイヤー設定を使用したエンドデバイスの作成/更新(例:The Things Uno)

すでに何がありますか? あなたは今何を見ていますか?

デバイスのMACレイヤーを構成する唯一の手段としてのCLI

何が欠けている? あなたは何が見たいですか?

すべてのMACSettingsフィールドの構成のサポート。

フィールド優先順位リスト
高い
  • すべてのデバイス

    • [x] rx2_data_rate_index
    • [x] rx2_frequency
    • [x] factory_preset_frequencies
  • クラスA固有(別名、すべての非マルチキャストデバイス)

    • [x] rx1_delay
    • [x] rx1_data_rate_offset
    • [x] resets_f_cnt
  • クラスB固有

    • [x] ping_slot_periodicity
中くらい
  • クラスA固有(別名、すべての非マルチキャストデバイス)

    • [] max_duty_cycle
    • [x] supports_32_bit_f_cnt
    • [] use_adr
    • [] status_time_periodicity
    • [] status_count_periodicity
  • クラスB固有

    • [] ping_slot_data_rate_index
    • [x] ping_slot_frequency
    • [] beacon_frequency
低い
  • クラスA固有(別名、すべての非マルチキャストデバイス)

    • [] adr_margin
    • [] desired_rx1_delay
    • [] desired_rx1_data_rate_offset
    • [] desired_rx2_data_rate_index
    • [] desired_rx2_frequency
    • [] desired_max_duty_cycle
    • [] desired_adr_ack_limit_exponent
    • [] desired_adr_ack_delay_exponent
  • クラスB固有

    • 非マルチキャスト

      • [] class_b_timeout

      • [] desired_ping_slot_data_rate_index

      • [] desired_ping_slot_frequency

      • [] desired_beacon_frequency

  • クラスC固有

    • 非マルチキャスト

      • [] class_c_timeout

注:これらの一部はすでに構成可能である可能性があります(FCntのものなど)。それに応じてチェックボックスを更新し、これらの設定が正しい場所に配置されていることを確認してください(つまり、マルチキャストデバイスでは使用できません)

クラスBおよびC固有の設定は、それぞれのSupportsClass{B,C}falseデバイスであっても、すべてのデバイスで使用できる必要があると思います。 このようにして、ユーザーは必要に応じてクラスB / C操作を(一時的に)無効化/有効化し、特定の設定を維持できます。

クラスA固有の設定は、マルチキャスト以外のデバイスでのみ使用できます。

これをどのように実装することを提案しますか?

MACSettings https://github.com/TheThingsNetwork/lorawan-stack/blob/74c9da9a9e07a31d7103eabcd3440f9c80c24ea1/api/end_device.proto#L190-L284のすべてのフィールドをフィールドとしてネットワーク層構成に追加します。 これらのフィールドは、常に、つまり作成時と更新時の両方で構成可能である必要があります。

説明には、プロトからのコメントを使用してください。

これを自分で行い、プルリクエストを送信できますか?

@bafoninsはそれを処理します

console compaapi documentation uweb

全てのコメント9件

私は主に、MAC設定構成の優先度の高いフィールドで完了しています。


スクリーンショット
ABP:

Screenshot 2020-03-29 at 17 41 50

クラスB:

Screenshot 2020-03-29 at 17 44 00

OTAA:
Screenshot 2020-03-29 at 18 11 58

ただし、それらすべてを追加してユーザーが登録できるようにするために、たとえば、コンソールを介したThe Things Unoのmac_state.factory_preset_frequenciesフィールドがありません。 これをUIでどの程度正確に表現する必要があるかわかりません。現在、次のアイデアがあります。

  1. 複数選択として:
    Screenshot 2020-03-30 at 09 47 01

IMO、そのようなフィールドは周波数の選択を非常に簡単にします。 さらに、エンドデバイスのfrequency_plan_idに基づいてユーザーに頻度を提示できます。 ただし、 @ rvolosatovsが述べたように、入力は任意の値を持つことができ、必ずしもエンドデバイスの周波数計画に依存するわけではありません。

さらに、このアプローチでは、RPCを使用して、帯域ごとの周波数のプリセットをフェッチできると便利です。

  1. 数値入力の配列として(Webhook統合にヘッダーを追加できるようにする方法と同様):
    Screenshot 2020-03-30 at 11 06 13

このアプローチはより柔軟性がありますが、ユーザーがフィールドを設定するのに時間がかかり、入力頻度が必要になります。

  1. 新しいラベルを作成するためのオプションを使用して複数選択すると、次のようになります。

freqqs

基本的に、1と2の組み合わせ。

@rvolosatovs @johanstokking

リスト(2)を持っていることが、順序を示しているので、最も明確だと思います。 そして、順序は重要です。

頻度は確かに何でもかまいませんが、既存の頻度計画を介してそれらを取得することは非常に役立ちます。

compat/api追加すると、周波数プランを取得するためにNSrpcが必要になる場合があります。

リスト(2)を持っていることが、順序を示しているので、最も明確だと思います。 そして、順序は重要です。

一部のコンポーネント(1)と(2)は、どちらも順序を保持します。

周波数は確かに何でもかまいません、

(3)を使用すると、任意の周波数値を追加することもできます

解決策(2)も最もクリーンだと思いますが、(3)は少量の周波数では見栄えが良く、複数(たとえば、4つ以上)があると、雑然としていて追跡が困難になります。
(提案された頻度計画RPCからの)各テキストボックスに(2)の頻度の提案があれば素晴らしいので、(3)に表示されるようなものですが、テキストボックスごとに

実装はほぼ完了しましたが、 https://github.com/TheThingsNetwork/lorawan-stack/issues/2605がマージされるのを待ってから、PRを作成してデバイスウィザードのテストを追加します(Mac設定の処理を含む)

ここのステータスは何ですか?

@johanstokkinghttps ://github.com/TheThingsNetwork/lorawan-stack/pull/3065はレビューの準備ができています。 すべての高優先度フィールドといくつかの中優先度フィールドを追加しました。

この問題のマイルストーンを変更することは次のことではありません。 すべての高優先度フィールドといくつかの中優先度フィールドがhttps://github.com/TheThingsNetwork/lorawan-stack/pull/3065に追加されました

このページは役に立ちましたか?
0 / 5 - 0 評価