デバイスのMACレイヤーは、コンソールから構成可能である必要があります。
https://github.com/TheThingsNetwork/lorawan-stack/issues/1378を置き換え
デバイスのMACレイヤーを構成する唯一の手段としてのCLI
すべてのMACSettings
フィールドの構成のサポート。
すべてのデバイス
rx2_data_rate_index
rx2_frequency
factory_preset_frequencies
クラスA固有(別名、すべての非マルチキャストデバイス)
rx1_delay
rx1_data_rate_offset
resets_f_cnt
クラスB固有
ping_slot_periodicity
クラスA固有(別名、すべての非マルチキャストデバイス)
max_duty_cycle
supports_32_bit_f_cnt
use_adr
status_time_periodicity
status_count_periodicity
クラスB固有
ping_slot_data_rate_index
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はそれを処理します
私は主に、MAC設定構成の優先度の高いフィールドで完了しています。
スクリーンショット
ABP:
クラスB:
OTAA:
ただし、それらすべてを追加してユーザーが登録できるようにするために、たとえば、コンソールを介したThe Things Unoのmac_state.factory_preset_frequencies
フィールドがありません。 これをUIでどの程度正確に表現する必要があるかわかりません。現在、次のアイデアがあります。
IMO、そのようなフィールドは周波数の選択を非常に簡単にします。 さらに、エンドデバイスのfrequency_plan_id
に基づいてユーザーに頻度を提示できます。 ただし、 @ rvolosatovsが述べたように、入力は任意の値を持つことができ、必ずしもエンドデバイスの周波数計画に依存するわけではありません。
さらに、このアプローチでは、RPCを使用して、帯域ごとの周波数のプリセットをフェッチできると便利です。
このアプローチはより柔軟性がありますが、ユーザーがフィールドを設定するのに時間がかかり、入力頻度が必要になります。
基本的に、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に追加されました