Lorawan-stack: ウィザードを使用してエンドデバイスを作成する

デバイスフォームの現在の実装に関する主な問題は、すべてが一緒に結合されていることです。 これは〜をひき起こす

1. 複雑で長い検証スキーマ
2. スタック構成に基づいて特定のフィールドを無効にする簡単な方法はありません
3. 選択した値に応じてフォームフィールド/フィールドタイトルを変更する簡単な方法はありません
4. バッチ作成/更新/削除および作成ロールバックロジックのためのjsSDKの不必要な複雑さ

デバイスフォームをマルチステップフォームとして実装することを提案します。 これは次のようになります。

このようなアプローチは、上記のすべての問題に対処します。

1. 1つの複雑なスキーマの代わりに、ステップごとに小さなスキーマを定義します。
2. 特定の責任あるコンポーネントがスタックで使用できない場合は、ステップ全体を無効にするだけです。 さらに、説明/通知を介してこれについてユーザーに通知することができます。
3. 以前に送信された値に応じて、各ステップを適応させます。 たとえば、lorawanバージョン1.0.xの場合、 Join EUIラベルをApp EUIに変更します。
4. バッチリクエストは必要ありません。 ユーザーは、さまざまなコンポーネントでデバイスを作成する責任があります。 ただし、便宜上、バッチ削除を保持したい場合があります。

編集デバイスは、アコーディオンのスタックとして実装できます。

各アコーディオンがスタンドアロンフォームで拡張される場所。

デバイスフォームに加えて、アプリケーションフォームのウィザードを使用して次のこともできます。

1. でアプリケーションを作成します
2. アプリケーションをにリンクします

cc @kschiffer @johanstokking @htdvisser

特に、コンポーネントのフィールドを1つのステップでグループ化できる場合は、私には良さそうです。 そうすれば、コンポーネントが利用できない場合に、手順をスキップ/無効にすることができます。

https://github.com/TheThingsNetwork/lorawan-stack/issues/1234も参照してください。 JSが使用可能な場合でも、ユーザーはJSフィールドをスキップできます。

私はそのような図を思いついた：

すべてのノードはステップです

• 輪郭が点線のステップはフォームを送信しませんが、次のステップのためにローカル状態のままにします。
• 他の人は送信時にサーバーにリクエストを送信します。

複雑に見えますが、現在の実装では、検証/送信/フィールドマスクの生成などに関してさらに大きな状態空間があります。

議論を始めるための最初の提案として図を考えてください。

これは良いスタートだと思います。

• おそらく、JoinServerが最初に来た方がフローは良くなるでしょう。
• まだ実際には進歩していない重要なことは、デバイスリポジトリ＃263のデバイステンプレートからフィールドを事前に入力することです。 これにより、本番環境への展開プロセスを本当に簡素化できると思います。

そして、いくつかの小さなこと：

• DevEUIはABPデバイスでは禁止されていません（オプションで設定できます）
• LoRaWAN 1.0.xデバイスにはNwkKeyはなく、 AppKeyのみがあります
• FNwkSIntKeyはNwkSKeyと呼ばれます（ユーザーに対して）
• アプリケーションサーバーはNwkKeyまたはAppKeyを取得しません

はい、素晴らしいスタートです。

• おそらく、JoinServerが最初に来た方がフローは良くなるでしょう。

私はこれに同意する。 アクティベーションモードがOTAAで、クラスターJSが有効になっている場合、ユーザーはJSページでルートキーを入力してクラスターJSに保存するかどうかを選択できます。 （これを無効にすると、クラスターにJSが有効になっていない場合と同様に、NSはJSルックアップを使用します）

• 「アクティベーションモード」はペイロードにあります-あなたの図では、それは実際には2つのフィールドに対応しています- multicast boolとsupports_join bool 。 multicast && supports_joinは無効であるため、3つの可能なオプションがあります。
• frequency_plan -> frequency_plan_id

• resets_f_cntはオプションで、デフォルトでfalseです。

• FNwkSIntKeyは、<1.1の場合にのみNwkKeyとして表示する必要があります

• FNwkSIntKeyが>=1.1のABPNS設定にありません
• multicastデバイスはAppSKeyのみを必要とします-NSはmulticastデバイスが機能するためにキーを必要とせず、ASのみを必要とします

@htdvisser

おそらく、JoinServerが最初に来た方がフローは良くなるでしょう。

なんで？

まだ実際には進歩していない重要なことは、デバイスリポジトリ＃263のデバイステンプレートからフィールドを事前に入力することです。 これにより、本番環境への展開プロセスを本当に簡素化できると思います。

私にとっては、この問題の範囲外のようです

DevEUIはABPデバイスでは禁止されていません（オプションで設定できます）

ABPデバイスにも設定しますか？ フィールドが少なければ少ないほど良いと思います。 ただし、追加できる必要があります。

FNwkSIntKeyはNwkSKeyと呼ばれます（ユーザーに対して）

したがって、ラベルは1.0.xと1.1.xの両方でNwkSKeyである必要がありますか？ コンソールにATMがあるのは次のとおりです。

• LoRaWAN 1.0.xデバイスにはNwkKeyはなく、AppKeyのみがあります
• アプリケーションサーバーはNwkKeyまたはAppKeyを取得しません

修正済み👌

@johanstokking

アクティベーションモードがOTAAで、クラスターJSが有効になっている場合、ユーザーはJSページでルートキーを入力してクラスターJSに保存するかどうかを選択できます。 （これを無効にすると、クラスターにJSが有効になっていない場合と同様に、NSはJSルックアップを使用します）。

それで、これはユーザーがサーバーへの参加送信ステップをスキップできるようにするだけの問題ですか？ jsへのリクエストはまったくありませんか？

https://github.com/TheThingsNetwork/lorawan-stack/issues/1134に関して、これらのフィールドが図のどこに属するかを指定することもできますか？

@rvolosatovs

アクティベーションモード」はペイロードにあります-図では、実際には2つのフィールドに対応しています-マルチキャストboolとsupports_joinbool。マルチキャスト&&supports_joinは無効であるため、3つの可能なオプションがあります。

明確にするために：

1. supports_join=true -OTAA
2. supports_join=false -ABP
3. multicast=true && **no** supports_join -マルチキャスト
   これは正しいです？

resets_f_cntはオプションで、デフォルトではfalseです。

それでもユーザーに見せてもいいと思います。 ユーザーがマルチキャストデバイス用に設定できるようにする必要がありますか？

FNwkSIntKeyは、1.1未満の場合にのみNwkKeyとして提示する必要があります

NwkSKeyという意味ですか？

Frequency_plan-> Frequency_plan_id
FNwkSIntKeyが>=1.1のABPNS設定にありません

修正済み👌

更新された図：

@htdvisser

おそらく、JoinServerが最初に来た方がフローは良くなるでしょう。

なんで？

ええ、私はこれに戻ってきます。 キーを入力する前にMACバージョンを入力する方が理にかなっていると思います。 だから私は現在の流れをサポートしています。 MACバージョンが入力されている場合（NSが有効になっている場合）、1.1.xであるため、 NwkKeyを要求する必要はありません。

まだ実際には進歩していない重要なことは、デバイスリポジトリ＃263のデバイステンプレートからフィールドを事前に入力することです。 これにより、本番環境への展開プロセスを本当に簡素化できると思います。

私にとっては、この問題の範囲外のようです

それは確かに範囲外です。

DevEUIはABPデバイスでは禁止されていません（オプションで設定できます）

ABPデバイスにも設定しますか？ フィールドが少なければ少ないほど良いと思います。 ただし、追加できる必要があります。

はい、オプションでお願いしたいと思います。 エンドデバイスに関する識別情報が多いほど、優れています。 また、ステートフルパッシブローミングでも必要です。 ユーザーにDevEUIの入力を強制しない理由は、DevEUIがない場合、ユーザーに偽の値を入力させたくないためです。

FNwkSIntKeyはNwkSKeyと呼ばれます（ユーザーに対して）

したがって、ラベルは1.0.xと1.1.xの両方でNwkSKeyである必要がありますか？ コンソールにATMがあるのは次のとおりです。

1.0.xの場合NwkSKey $、1.1.xの場合FNwkSIntKeyです。

アクティベーションモードがOTAAで、クラスターJSが有効になっている場合、ユーザーはJSページでルートキーを入力してクラスターJSに保存するかどうかを選択できます。 （これを無効にすると、クラスターにJSが有効になっていない場合と同様に、NSはJSルックアップを使用します）。

それで、これはユーザーがサーバーへの参加送信ステップをスキップできるようにするだけの問題ですか？ jsへのリクエストはまったくありませんか？

それはそう。

例として、SemtechJoinServerを使用するSemtechのモデムを搭載したデバイスがあります。 その場合、EUIを知る必要があるだけです。

＃1134に関して、これらのフィールドが図のどこに属するかを指定することもできますか？

それらはJSステップに属します。 JSがクラスターで有効になっていて、ユーザーがJSでデバイスをプロビジョニングする場合は、これらのフィールドをJSに移動します。

これらのフィールドはオプションです。

明確にするために：

1. supports_join=true -OTAA
2. supports_join=false -ABP
3. multicast=true && **no** supports_join -マルチキャスト
   これは正しいです？

厳密に：

1. OTAA： supports_join
2. ABP： !supports_join && !multicast
3. マルチキャスト： multicast

無効なのはsupports_join && multicastですが、これはNSで検証されます（または検証される必要があります）。

resets_f_cntはオプションで、デフォルトではfalseです。

それでもユーザーに見せてもいいと思います。 ユーザーがマルチキャストデバイス用に設定できるようにする必要がありますか？

いいえ、これはマルチキャスト用ではありません。 resets_f_cntはアップリンクを指しますが、マルチキャストにはアップリンクはありません。

FNwkSIntKeyは、1.1未満の場合にのみNwkKeyとして提示する必要があります

NwkSKeyという意味ですか？

確かにNwkSKeyである必要があります。

@bafoninsは@johanstokkingの答えを見てください。
multicastに関して-デバイスアドレスも必要です

• https://github.com/TheThingsNetwork/lorawan-stack/issues/1134からフィールドを追加しました
• DevEUIをabp/マルチキャストデバイスに追加しました
• マルチキャストデバイスにDevice Addressを追加しました
  

multicastデバイスのネットワークサーバー設定にデバイスアドレスがまだありません

マルチキャストデバイスのネットワークサーバー設定にデバイスアドレスがまだありません

更新されました👌

マルチキャストは1.0.xおよび1.1.xにすることができます。 セッション情報（ DevAddrとキー）の入力は、マルチキャストの場合とABPの場合と同じです。

また、1.1.xのJSでresets_join_noncesを設定できます

デバイスの作成を分割することは間違いなく必要であり、ユーザーの複雑さを軽減しながら、フローと実装をバックエンドの要件に近づけるための優れた方法です。

私が見るいくつかの考えと課題：

• フロー全体を中止する機能を追加する必要があります。その結果、既に作成されているレジストリエントリはすべて削除されます。
  
  
  
  • 同様に、前の手順に進むには、フォームを「更新モード」にする必要があります（ISを除いて、エンドポイントは同じであるため、比較的簡単なはずです）
  
  
• 私が見ている問題の1つは、アプリケーションサーバーのステップが非常に浅く（これは後で変更される可能性がありますか？）、ペイロード形式オプションを追加することも、デバイスの作成中のユーザーのニーズに実際には一致していません。
  
  
  
  • 解決策は、ASとJSの両方のステップが非常に単純で相互依存していないことを前提として、それらをマージすることです。 これはコンポーネントによる分離に反することを私は理解していますが、これは合理的な抽象化でフロー全体を単純化すると思います。 特に、ステップ内でそれぞれのスタックコンポーネントへの接続を伝達しないことを考えると。
  
  
• スタック構成によっては、1つまたは2つのステップしかないウィザードが作成される場合があります。これは、ウィザードのアンチパターンです。
  
  
  
  • たった1つのステップの場合、ウィザードの側面を非表示/削除するだけです。
  
  
  • 2つのステップでは、この問題に対処する必要があると思います🤷‍♂
  
  
• ウィザードソリューションにより、ユーザーストーリーの_完了までの時間_が大幅に増加することを考慮する必要があります
  
  
  
  • これは、多くのデバイスを手動で作成する必要がある状況で問題になる可能性がありますが、このユースケースのバッチ作成機能を紹介し、CLI/スクリプトもそのような状況で役立ちます
  
  
  • それでも、V2コンソールデバイスの作成との違いと、ユーザーがこの変更をどのように認識するかを検討してください
  
  
• 一般的な設定に対応する「セグメント化された編集」ソリューションが好きです
• フロー図は非常に役立ち、最新の状態に保つ必要があります👍

バッチ作成/更新/削除および作成ロールバックロジックのためのjsSDKの不必要な複雑さ

この場合は使用しなくても、デバイスリクエストを分割およびマージするためのSDKの機能はまだかなり価値があると思います

マルチキャストデバイスの@johanstokkingNSは、MIC計算に1.1のSNwkSIntKeyのみを必要とします。 実際、 FNwkSIntKeyとNwkSEncKeyはIMOを設定することを許可されるべきではありません。

• フロー全体を中止する機能を追加する必要があります。その結果、既に作成されているレジストリエントリはすべて削除されます。
  
  
  
  • 同様に、前の手順に進むには、フォームを「更新モード」にする必要があります（ISを除いて、エンドポイントは同じであるため、比較的簡単なはずです）
  
  

フィニッシュか何かを押す前に何かを作成するべきではないと思います。 ウィザードを行ったり来たりしてブラウザウィンドウを閉じても、デバイスが半分作成されることはありません。

• 私が見ている問題の1つは、アプリケーションサーバーのステップが非常に浅く（これは後で変更される可能性がありますか？）、ペイロード形式オプションを追加することも、デバイスの作成中のユーザーのニーズに実際には一致していません。

ここでアプリケーションパッケージの構成を追加します（つまり、リモートマルチキャストセットアップ、断片化されたデータブロック転送、Semtechモデムオプションなど）。 そうです、今は浅いですが、拡張されます。

• 解決策は、ASとJSの両方のステップが非常に単純で相互依存していないことを前提として、それらをマージすることです。 これはコンポーネントによる分離に反することを私は理解していますが、これは合理的な抽象化でフロー全体を単純化すると思います。 特に、ステップ内でそれぞれのスタックコンポーネントへの接続を伝達しないことを考えると。

私たちの将来のために、私はそれらを別々に保つことをお勧めします。 また、それらを組み合わせると、コンポーネントの可用性を条件としてこれらのページにレンダリングが行われるため、すでに複雑なフローが複雑になります。

• スタック構成によっては、1つまたは2つのステップしかないウィザードが作成される場合があります。これは、ウィザードのアンチパターンです。

  • たった1つのステップの場合、ウィザードの側面を非表示/削除するだけです。
  • 2つのステップでは、この問題に対処する必要があると思います🤷‍♂

• ウィザードソリューションにより、ユーザーストーリーの_完了までの時間_が大幅に増加することを考慮する必要があります

  • これは、多くのデバイスを手動で作成する必要がある状況で問題になる可能性がありますが、このユースケースのバッチ作成機能を紹介し、CLI/スクリプトもそのような状況で役立ちます
  • それでも、V2コンソールデバイスの作成との違いと、ユーザーがこの変更をどのように認識するかを検討してください

コンポーネントの分離と柔軟な展開シナリオは、V2と比較した場合の重要な変更の1つであるため、これがV3コンソールで効果的であることは完全に理にかなっています。

実際、大量のデバイスを作成するには、とにかくAPIとCLIを使用する必要があります。

1つのステップでシナリオはありません。常に、少なくとも2つのステップです。

ページの代わりにタブをレンダリングするのはどうですか？ そうすれば、それはまだ1ページですが、段階的に行ったり来たりすることなく、物事に簡単にアクセスできます。

@johanstokking

フィニッシュか何かを押す前に何かを作成するべきではないと思います。

最後のステップでのみ実際のリクエストを行う場合は、3〜4回のリクエストを行うことを意味します。 さまざまなコンポーネントから返されたエラーをどのように処理しますか？ これを処理し、エラーのあるステップ/リセットストアなどにユーザーを移動します。 複雑です。 そのため、すべてのステップで値を送信することをお勧めします。これは、後続のすべてのステップで、送信された値が有効であると信頼できるためです。

ウィザードを行ったり来たりしてブラウザウィンドウを閉じても、デバイスが半分作成されることはありません。

私は、ユーザーがウィザードでデータを編集できるようにすることに反対しています（送信につながるステップについて）。 Mb、単一のコンポーネントに格納されているオプションのフィールドのみ（および他のコンポーネントはそれらを必要としません）、たとえばname 、 description 。 そうしないと、これの処理が非常に複雑になります。

@kschiffer

スタック構成によっては、1つまたは2つのステップしかないウィザードが作成される場合があります。これは、ウィザードのアンチパターンです。

ええと、私たちは代替ソリューションを受け入れています。 何か提案はありますか？

最後のステップでのみ実際のリクエストを行う場合は、3〜4回のリクエストを行うことを意味します。 さまざまなコンポーネントから返されたエラーをどのように処理しますか？ これを処理し、エラーのあるステップ/リセットストアなどにユーザーを移動します。 複雑です。 そのため、すべてのステップで値を送信することをお勧めします。これは、後続のすべてのステップで、送信された値が有効であると信頼できるためです。

わかった。 コンソールがERにあるデバイスを処理できるが、そのステップが失敗したか、ユーザーがタブなどを閉じたためにJS / NS / ASで見つからない限り、これは問題ありません。

私は、ユーザーがウィザードでデータを編集できるようにすることに反対しています（送信につながるステップについて）。 Mb、単一のコンポーネントに格納されているオプションのフィールドのみ（および他のコンポーネントはそれらを必要としません）、たとえばname 、 description 。 そうしないと、これの処理が非常に複雑になります。

どう言う意味ですか？

たとえば、ASはフィールドを必要とせず、デバイスが存在する必要があるだけであることに注意してください。 したがって、ASが存在する場合、ユーザーがASの値を入力しなくても、ASに（空の）デバイスを作成する必要があります。

どう言う意味ですか？

ごめん。 これは@kschifferの提案に向けられました：

同様に、前の手順に進むには、フォームを「更新モード」にする必要があります（ISを除いて、エンドポイントは同じであるため、比較的簡単なはずです）

ウィザードを行ったり来たりしてブラウザウィンドウを閉じても、デバイスが半分作成されることはありません。

これは将来の改善だと思います。 今のところ、未完了のフローに関する通知をユーザーに表示するだけです。 後で、ユーザーは一般設定ページでデバイスを編集/削除できます。

ええと、私たちは代替ソリューションを受け入れています。 何か提案はありますか？

ええと、この特定の状況の_エッジ-casiness_を考えると、この問題を抱えて生きても大丈夫だと思います。 あなたの言葉遣いは、私が提案された解決策なしで懸念を言葉にするべきではないことを示唆していますが、私がすぐに見つけることができない場合、私は他の人にいくつかを思い付く機会を与えたいと思います。

私は、ユーザーがウィザードでデータを編集できるようにすることに反対しています（送信につながるステップについて）。 Mb、単一のコンポーネントに格納されているオプションのフィールドのみ（および他のコンポーネントはそれらを必要としません）、たとえばname 、 description 。 そうしないと、これの処理が非常に複雑になります。

これも、ウィザードパターンのベストプラクティスに違反します。 特にこれらが相互に依存していることを考えると、ユーザーは以前のフィールドを修正または単に検査したいと思うでしょう。 最初はこの機能を含めなくても大丈夫ですが、最終的には追加する必要があります（たとえば、問題を追跡します）。

そうしないと、これの処理が非常に複雑になります。

一般的に言って、複雑なフロントエンドロジックを実装する必要性は、UXへの取り組みに影響を与えるべきではありません。

これは将来の改善だと思います。 今のところ、未完了のフローに関する通知をユーザーに表示するだけです。 後で、ユーザーは一般設定ページでデバイスを編集/削除できます。

最適ではありませんが、最終的にこれを強化する限り、私には受け入れられます。

オフラインで説明したように、これが最初の提案です。

デバイスを作成する

1. 一般設定
   
   
   
   • 田畑
     
     
     
     
     
     • ids
     
     
     
     • オプションのname
     
     
     
     • オプションのdescription
     
     
     
     • オプションのattributes
     
     
     
     • 必要なアクティベーションモード：OTAA、ABPまたはマルチキャスト
     
     
     
     • クラスター内のNSの場合
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • この手順では、ISでのみデバイスを作成します。 そうすれば、識別子が無料であることがわかります
   
   
   • アクティベーションモードはセッション状態で使用されます
   
   
   • クラスタ内のNSでない場合は、ウィザードを簡単にするために、セッション状態で既知の最も高いバージョン（つまり、それぞれ1.1.0と1.1.0-A）を使用できます。
   
   

2. LoRaWAN設定

   • クラスタ内のNSの場合：フィールド
     
     
     
     • lorawan_version （必須）
     
     
     • lorawan_phy_version （必須）
     
     
     • supports_joinアクティベーションモードがOTAAの場合に設定（必須）
     
     
     • multicastは、アクティベーションモードがマルチキャストの場合に設定されます
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id （必須）
     
     
     • mac_settings.supports_32_bit_f_cnt
     
     
     • mac_settings.factory_preset_frequencies
     
     
     • mac_settings.ping_slot_data_rate_index.value
     
     
     • mac_settings.ping_slot_frequency
     
     
     • mac_settings.ping_slot_periodicity.value
     
     
     • mac_settings.rx2_data_rate_index.value
     
     
     • min_frequency
     
     
     • max_frequency
     
     
   • クラスタ内のNSの場合：アクティベーションモードがOTAAの場合のフィールド
     
     
     
     • 外部JSを使用するかどうかのチェックボックス（デフォルトでオン）
     
     
   • アクティベーションモードがABPまたはマルチキャストの場合のフィールド
     
     
     
     • クラスタ内のNSまたはASの場合： session.dev_addr
     
     
     • クラスタ内のNSまたはASの場合： session.keys.session_key_idを生成します
     
     
     • クラスタ内のNSの場合： session.keys.f_nwk_s_int_key.key -必須
     
     
     • クラスタ内のNSの場合： session.keys.s_nwk_s_int_key.key （LW> = 1.1.0の場合）-必須
     
     
     • クラスタ内のNSの場合： session.keys.nwk_s_enc_key.key （LW> = 1.1.0の場合）-必須
     
     
     • クラスタ内のASの場合： session.keys.app_s_key.key -必須
     
     
     • クラスタ内のNSの場合： session.last_conf_f_cnt_down
     
     
     • クラスタ内のNSの場合： session.last_n_f_cnt_down
     
     
   • クラスタ内のNSの場合：アクティベーションモードがABPの場合のフィールド
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • クラスタ内のNSまたはASの場合：アクティベーションモードがABPの場合のフィールド
     
     
     
     • session.last_f_cnt_up -これはセキュリティのために必要です
     
     

   • クラスター内のNSの場合：アクティブ化モードがABPまたはOTAAの場合のフィールド

     • mac_settings.adr_margin
     • mac_settings.class_b_timeout
     • mac_settings.class_c_timeout
     • mac_settings.desired_adr_ack_delay_exponent.value
     • mac_settings.desired_adr_ack_limit_exponent.value
     • mac_settings.desired_max_duty_cycle.value
     • mac_settings.desired_rx1_data_rate_offset
     • mac_settings.desired_rx1_delay.value
     • mac_settings.desired_rx2_data_rate_index.value
     • mac_settings.desired_rx2_frequency
     • mac_settings.max_duty_cycle.value
     • mac_settings.rx1_data_rate_offset
     • mac_settings.rx1_delay.value
     • mac_settings.status_count_periodicity
     • mac_settings.status_time_periodicity
     • mac_settings.supports_32_bit_f_cnt
     • mac_settings.use_adr

   • これにより、デバイスがNSおよびASに設定されます（クラスター内の場合）。 OTAAデバイスを使用している場合、現時点ではASに設定するものはありませんが、一貫性を求める必要があります。

3. クラスタ内のASの場合：アプリケーション設定
   
   
   
   • 田畑
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • これにより、デバイスがASに設定されます
   
   
4. JSがクラスター内にあり、OTAAの場合、および外部JSを使用していない場合：セキュリティ設定
   
   
   
   • 田畑
     
     
     
     
     
     • root_keys.root_key_idを生成します
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key （LW> = 1.1.0の場合）
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • これにより、デバイスがJSに設定されます
   
   

デバイスを更新する

ここでは、基本的にウィザードのステップをタブとして、タブ付きのアプローチを使用します。

ここで重要なのはそれです。

• ids 、 supports_join 、 multicastは読み取り専用です
• アクティベーションモードは次の順序で評価されます。
  
  
  
  • OTAA：クラスターにNSがない場合、またはクラスターにNSがあり、NSがsupports_joinと言っている場合
  
  
  • ABP：クラスター内にNSが必要です（その場合にのみ関連します）： !supports_join && !multicast
  
  
  • マルチキャスト：クラスター内にNSが必要です（その場合にのみ関連します）： !supports_join && multicast （ただし、 multicastで十分です）
  
  

デバイスの更新をサポートするためのいくつかの使用例：

• コンソールはクラスター内にNS、AS、およびJSを含めることができますが、デバイスはNS、AS、またはJSに含まれていない可能性があります（コンソールは404を取得します）。 これは有効なケースであり、コンソールがこれを処理する必要があります。 例として、クレームされたデバイスがあります。このデバイスはERとJSに設定されていますが、NSとASには（まだ）設定されていません。
• 前のバージョンに基づいて：ERとJSにのみ存在するデバイスのLoRaWANとアプリケーションの設定を設定します（つまり、NSとASに設定します）
• lorawan_versionとlorawan_phy_versionを変更する（これにより制約が変更されます）
• 「外部JS」オプションの変更。 つまり、既存のデバイスがあり、cluster-JSでルートキーを構成するとします。 次に、このチェックボックスをオフにすると、ユーザーは[セキュリティ設定]タブでルートキーを設定できるようになります。
• 一括インポートを介して、デバイスはJSで作成され、ルートキーを持つことができますが、それらは公開されません。 今日のように、ユーザーはルートキーがそこにあることを確認できるはずですが（ root_keys != nil ）、公開されていません（ root_keys.app_key == nullなど）。 ユーザーはルートキーをそのままにしておくことができるはずです

一般的なもの

• キーの場合、入力フィールドまたはランダム生成ボタン
• 外部JSと公開されていないルートキーの違い。
  
  
  
  • 外部JSは、JSがNSと同じクラスター内にない場所です。 これにより、OTAAデバイスを作成できますが、キーは別の場所で構成されているため、セキュリティ設定を入力する必要はありません。
  
  
  • 公開されていないルートキーは、デバイスがクラスターローカルJS内にある場所ですが、JSはルートキーを公開しません。 これはセキュリティのためです。つまり、JSがルートキーにアクセスできるが、それらを公開しない安全な要素の場合です。
  
  

https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408には、NSに必要なすべてのものがすでに含まれていると思います。
すべてのmac_settingsは、すべての非マルチキャストデバイスに設定できるようにする必要があると思います。
マルチキャストデバイスの場合、以下のみが意味をなします。

• "mac_settings.factory_preset_frequencies"
• "mac_settings.ping_slot_data_rate_index.value"
• "mac_settings.ping_slot_frequency"
• "mac_settings.ping_slot_periodicity.value"
• "mac_settings.rx2_data_rate_index.value"
• "mac_settings.rx2_frequency"

多分明確にするためにいくつかのこと

作成：

1. 一般設定
   a。 ERでデバイスを作成する場合、NS / AS/JSアドレスは設定しません。 デバイスがそれらに設定されているときにER登録を更新しますか？ 外部JSを使用している場合はどうなりますか？
   b。 アクティベーションモードをERに保存しますか？
   c。 phy / macバージョンをERに保存しますか？
2. LoRaWAN設定
   a。 supports_class_bどうですか？
3. アプリケーションの設定
   a。 はい、これは、デバイスをASに2回設定したことを意味する可能性があります

アップデート：

• アクティベーションモード：これをERに保存すると、はるかに簡単になります
• 404のみを確認しますか、それともERのNS / AS / JSアドレスも確認しますか？
• たとえば、「外部JS」をtrueに変更するときに、個々のNS / AS / JS登録を削除したり、NSでデバイスの状態をリセットしたりできると便利だと思います。

一般的なもの：

• _ "外部JSは、JSがNSと同じクラスター内にない場所です" _：これは「join_server_addressがコンソール構成のJSアドレスと同じではない」のようになります。

トップレベルのフィールドについて話している場合：
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418このチャンク全体はNSに属しています（ただし、これらすべてが必要なわけではありません）

m{in,ax}_frequencyはマルチキャストには適用されません

@rvolosatovs

＃579（コメント）にはすでにNSに必要なものがすべて含まれていると思います。

すべてのmac_settingsは、すべての非マルチキャストデバイスに設定できるようにする必要があると思います。
マルチキャストデバイスの場合、以下のみが意味をなします。

この問題の問題の1つは、コメントに埋め込まれている情報の量です。

適切な場所にフィールドを_正確に_追加していただけますか？ 箇条書きのリスト全体をコピーしていただければ問題ないので、最終バージョンが完成するまで段階的に取り組んでいきます。

@htdvisser

1. 一般設定
   a。 ERでデバイスを作成する場合、NS / AS/JSアドレスは設定しません。 デバイスがそれらに設定されているときにER登録を更新しますか？ 外部JSを使用している場合はどうなりますか？

AS / NS / JSでデバイスを設定するときに、アドレスを更新する必要があると思います。

b。 アクティベーションモードをERに保存しますか？

いいえ、現時点ではそのためのフィールドはありません。実際には必要ありません。これにより、不整合の余地が生まれます。

c。 phy / macバージョンをERに保存しますか？

いいえ、APIドキュメントを参照してください。 繰り返しになりますが、私はその必要性を認識しておらず、それは矛盾の余地を生み出します。

a。 supports_class_bどうですか？

ええ、＃19まで、それを追加する必要があると思います。 @rvolosatovs必要に応じて、これを更新バージョンに含めてください。

1. アプリケーションの設定
   a。 はい、これは、デバイスをASに2回設定したことを意味する可能性があります

はい、それは害はありません

アップデート：

• アクティベーションモード：これをERに保存すると、はるかに簡単になります

はい、でも簡単に行けばいいのか、それが完全に当てはまるのかわかりません。 ホットパスで利用できるようにする必要があります。

また、きれいな状態から始めることができれば簡単です。 ただし、下位互換性が必要です。 lorawan_versionがERにない場合はヒューリスティックを追加し、NSからの条件付き取得を導入します。

• 404のみを確認しますか、それともERのNS / AS / JSアドレスも確認しますか？

アドレスが設定されている場合にのみ404を取得できます。それ以外の場合は、取得するものがありません。 両方を「そのレジストリにない」と解釈する必要があります。 ISとAS/NS / JSでの作成が同時に行われないという理由だけで、ここでエラーを起こすことはできません（以前と同じように）。ユーザーは、コンソールによって作成された不整合を回復できるはずです。

• たとえば、「外部JS」をtrueに変更するときに、個々のNS / AS / JS登録を削除したり、NSでデバイスの状態をリセットしたりできると便利だと思います。

はい、後でやりましょう

• _ "外部JSは、JSがNSと同じクラスター内にない場所です" _：これは「join_server_addressがコンソール構成のJSアドレスと同じではない」のようになります。

はい、それは確かにそれをチェックする方法です。 join_server_addressは、相互運用機能を使用して空にすることもできます。

@bafoninsグラフのソースはまだありますか？
すでにそれを構築するために多くの作業が行われたので、明確な表現を持つためにそれを完全にするためにそれを更新する必要があると思いますか？
ここでの議論を乱雑にしないために、NS部分をオフラインで更新することもできます。

可能なすべてのNSフィールドでグラフを更新しました
赤のフィールドは必須です

@rvolosatovsは、デバイスを作成および更新するときにコンソールに表示するフローとフィールドを定義することを目的としています。

そのような、

• mac_state.lorawan_versionの変更を許可するべきではありません
• 今のところ、CLIを介してmac_state.ping_slot_periodicityを実行できます
• ユーザーがsupports_class_b 、 supports_class_c 、 mac_state.device_classをどのように設定するかを考えてください。 これは作成の一部であり、更新の一部ですが、相互にどのように関係していますか？
• 個々のカウンターを変更するべきではありません。 「フレームカウンターのリセット」ボタンで実行できます（これは、V2コンソールの場合のように、カウンターを0に設定する別のアクションにすることができます）。
• mac_settingsとmac_state.desired_parametersのコンソールで必要な設定を慎重に選択する必要があります。 @htdvisserここで考えられますか？

https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment-553347858で順序を変更しました。 そのリストで段階的に作業してください。

適切な場所に正確にフィールドを追加していただけますか？

私はこの質問に答えました。つまり、NSで設定でき、設定する必要があるすべてのフィールドを提示しました。 または、少なくともそれが私があなたの質問を理解した方法です。

コンソールに何を表示するかについては、すべてのmac_stateはおそらくCLIを介してのみ設定可能である必要がありますが、既存のセッションに登録されているABP/マルチキャストデバイスやOTAAデバイスの場合はそれが必要になる場合があります。したがって、MAC状態。
コメントを更新します。

個々のカウンターを変更するべきではありません。 「フレームカウンターのリセット」ボタンで実行できます（これは、V2コンソールの場合のように、カウンターを0に設定する別のアクションにすることができます）。

ABPとマルチキャストのダウンリンクフレームカウンターを設定できる必要があります。そうしないと、NSはダウンリンクを送信できません。
アップリンクフレームカウンターの場合、ABPのセキュリティの観点からも非常に役立ちます

デバイスを更新する

ここでは、基本的にウィザードのステップをタブとして、タブ付きのアプローチを使用します。

@bafoninsからの最初のコメントに示されているように、ここではアコーディオンアプローチを使用しましょう。

水平方向のスペースに関する問題が少なくなり、 Edit / Createボタンでモードを区別できるようになります。

@rvolosatovs

ABPとマルチキャストのダウンリンクフレームカウンターを設定できる必要があります。そうしないと、NSはダウンリンクを送信できません。
アップリンクフレームカウンターの場合、ABPのセキュリティの観点からも非常に役立ちます

これが簡単であれば、私たちはそれを行うことができます。 実際、2つまたは3つの入力ボックスは、特定のアクションをトリガーするリセットボタンよりも単純な場合があります。

コンソールに何を表示するかについては、すべてのmac_stateはおそらくCLIを介してのみ設定可能である必要がありますが、既存のセッションに登録されているABP/マルチキャストデバイスやOTAAデバイスの場合はそれが必要になる場合があります。したがって、MAC状態。

わかりました。 「新しいABPデバイスとリセットされたABPデバイス」を「すでにネットワーク上にある既存のABPデバイス」から分離する必要があると思います。

前者は完全である必要があるため、 mac_state （つまり、工場出荷時のリセット周波数、RX1遅延、RX2設定など）を含める必要がありますが、$＃$ 2 mac_state.desired_parameters ＃$は含めないでください。

後者は移行を介して実行する必要があり、後でコンソールで微調整設定を追加できます。 今のところCLIを使用する必要があります。

更新していただきありがとうございます

LoRaWAN設定

• クラスタ内のNSの場合：フィールド
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

これらはOTAAに必要ですか？ これはABPとマルチキャストだけではありませんか？

@johanstokking

LoRaWAN設定

• クラスタ内のNSの場合：フィールド
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

これらはOTAAに必要ですか？ これはABPとマルチキャストだけではありませんか？

すべてのMAC設定は設計上オプションです。
これらが「必須」である唯一のケースは、クラスBのマルチキャストデバイスです。これは、クラスBの操作の詳細によるものです。
それとは別に、最良の結果を得るにはABPにfactory_preset_frequenciesが必要になる可能性がありますが、OTAAデバイスがその設定を行うことを妨げるものは何もありません。

すべてのMAC設定は設計上オプションです。
これらが「必須」である唯一のケースは、クラスBのマルチキャストデバイスです。これは、クラスBの操作の詳細によるものです。

わかった

それとは別に、最良の結果を得るにはABPにfactory_preset_frequenciesが必要になる可能性がありますが、OTAAデバイスがその設定を行うことを妨げるものは何もありません。

OTAAには効果がありません。 仕様ではデフォルトの結合周波数が必要であり、チャネルはjoin-acceptおよびMACコマンドを介して着信します。 OTAAデバイスのプリセット周波数の帯域外構成があってはなりません。

@bafoninsは、この問題に関するステータスの更新とタイムラインを提供できますか？

app_s_keyとskip_payload_cryptoの場合、次のようになります。

• ASは、エンドデバイスのフィールドskip_payload_cryptoを尊重します。 trueの場合、ASはペイロードの暗号化と復号化を実行しません
  
  
  
  • ASは、アプリケーションレベルでも（ペイロードフォーマッターのようにリンクを介して） skip_payload_cryptoを取得します。これは、エンドデバイスの設定よりも優先されます。
  
  
• ASにはおそらく常にapp_s_keyがありますが、ラップされている可能性があります。つまり、 session.keys.app_s_key.keyは設定されていません（ただし、 encrypted_keyとkek_labelは設定されています）
  
  
  
  • ASにKEKがない場合、つまり暗号化されたキーをアンラップできない場合。 さて、そのエラー。 おそらく暗号化されたapp_s_keyをそのままクライアントに返します
  
  
• コンソールで、 skip_payload_cryptoがtrue （エンドデバイスまたはアプリケーションリンク上）に設定されている場合は、 app_s_keyを気にしないでください：無効にしてください。気にしないでください