Lorawan-stack: 使用向导创建终端设备

当前实现设备形式的主要问题是所有东西都耦合在一起。 这引起

1. 复杂而冗长的验证模式
2. 没有直接的方法可以根据堆栈配置禁用某些字段
3. 没有直接的方法可以根据所选值更改表单字段/字段标题
4. 用于批量创建/更新/删除以及创建回滚逻辑的 js sdk 中不必要的复杂性

我建议将设备表单实现为多步表单。 这看起来像这样：

这种方法解决了上述所有问题：

1. 我们为每个步骤定义一个小的模式，而不是一个复杂的模式。
2. 如果堆栈中没有某个负责任的组件，只需禁用整个步骤。 更重要的是，我们可以通过描述/通知告知用户这一点。
3. 根据先前提交的值调整每个步骤。 例如，对于 lorawan 版本1.0.x ，将Join EUI标签更改为App EUI #$ 。
4. 不需要批量请求。 用户负责在不同的组件中创建设备。 但是，为了方便起见，我们可能希望保留批量删除。

编辑设备可以实现为手风琴堆栈：

每个手风琴都以独立的形式扩展。

除了设备表格外，我们还可以使用申请表格向导来：

1. 在 is 中创建应用程序
2. 将应用程序链接到 as

抄送@kschiffer @johanstokking @htdvisser

对我来说听起来不错，尤其是如果我们可以一步将组件的字段组合在一起。 这样，当组件不可用时，我们可以简单地跳过/禁用步骤。

也参考https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 ； 即使 JS 可用，用户也可以跳过 JS 字段。

我想出了这样的图表：

每个节点都是一步

• 带有虚线轮廓的步骤不提交表单，而是将其保留在本地状态以进行下一步。
• 其他人在提交时向服务器发送请求。

它看起来很复杂，但当前的实现在验证/提交/字段掩码生成/等方面具有更大的状态空间。

将图表视为开始讨论的初始命题。

我认为这是一个好的开始。

• 如果加入服务器先出现，也许流程会更好。
• 我们尚未真正取得任何进展的重要事情是从设备存储库 #263 中的设备模板中预填充字段。 我认为这可以真正简化生产部署的过程。

还有一些小事：

• ABP 设备不禁止DevEUI （可以选择设置）
• LoRaWAN 1.0.x 设备没有NwkKey ，只有AppKey
• FNwkSIntKey被称为NwkSKey （面向用户）
• 应用程序服务器没有得到NwkKey或AppKey

是的，很好的开始。

• 如果加入服务器先出现，也许流程会更好。

我同意这一点。 如果激活方式是OTAA并且开启了集群JS，在JS页面用户可以选择输入根密钥并存储在集群JS中。 （如果他们禁用它，NS 使用 JS 查找，就像启用集群中没有 JS 时一样）

• “激活模式”在有效负载中 - 在您的图表中，它实际上对应于 2 个字段 - multicast bool和supports_join bool 。 有 3 个可能的选项，因为multicast && supports_join无效。
• frequency_plan -> frequency_plan_id

• resets_f_cnt是可选的，默认false 。

• FNwkSIntKey应显示为NwkKey仅适用于 <1.1

• >= 1.1 的 ABP NS 设置中缺少FNwkSIntKey
• multicast设备只需要AppSKey - NS 不需要任何密钥才能使multicast设备工作，只有 AS

@htdvisser

如果加入服务器先出现，也许流程会更好。

为什么？

我们尚未真正取得任何进展的重要事情是从设备存储库 #263 中的设备模板中预填充字段。 我认为这可以真正简化生产部署的过程。

对我来说，这似乎超出了这个问题的范围

ABP 设备不禁止 DevEUI（可以选择设置）

我们是否也想为 ABP 设备设置它？ 我想说我们拥有的领域越少越好。 但是，需要我们可以添加它。

FNwkSIntKey 被称为 NwkSKey（面向用户）

所以标签应该是NwkSKey对于 1.0.x 和 1.1.x ？ 这是我们在控制台中的atm：

• LoRaWAN 1.0.x 设备没有 NwkKey，只有 AppKey
• 应用服务器未获取 NwkKey 或 AppKey

固定👌

@johanstokking

如果激活方式是OTAA并且开启了集群JS，在JS页面用户可以选择输入根密钥并存储在集群JS中。 （如果他们禁用它，NS 使用 JS 查找，就像启用集群中没有 JS 时一样）。

所以这只是允许用户跳过加入服务器提交步骤的问题吗？ 根本没有对js的请求？

关于https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 ，您能否指定这些字段在图中的位置？

@rvolosatovs

激活模式”在有效负载中 - 在您的图表中，它实际上对应于 2 个字段 - 多播 bool 和 support_join bool。有 3 个可能的选项，因为多播 && supports_join 无效。

只是为了澄清：

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 ？

频率计划 -> 频率计划 ID
ABP NS 设置中缺少 FNwkSIntKey >= 1.1

固定👌

更新的图表：

@htdvisser

如果加入服务器先出现，也许流程会更好。

为什么？

是的，我要回来了； 我认为在输入密钥之前输入 MAC 版本更有意义。 所以我支持当前的流程。 如果输入 MAC 版本（启用 NS 时），我们不必询问NwkKey ，因为那是 1.1.x。

我们尚未真正取得任何进展的重要事情是从设备存储库 #263 中的设备模板中预填充字段。 我认为这可以真正简化生产部署的过程。

对我来说，这似乎超出了这个问题的范围

确实超出了范围。

ABP 设备不禁止 DevEUI（可以选择设置）

我们是否也想为 ABP 设备设置它？ 我想说我们拥有的领域越少越好。 但是，需要我们可以添加它。

是的，我们想有选择地要求它。 我们拥有的关于终端设备的识别信息越多越好。 在有状态的被动漫游中也需要它。 我们不强制用户输入 DevEUI 的原因是，如果没有 DevEUI，我们不希望用户输入虚假值。

FNwkSIntKey 被称为 NwkSKey（面向用户）

所以标签应该是NwkSKey对于 1.0.x 和 1.1.x ？ 这是我们在控制台中的atm：

1.0.x 为 $# NwkSKey FNwkSIntKey ，1.1.x 为 FNwkSIntKey。

如果激活方式是OTAA并且开启了集群JS，在JS页面用户可以选择输入根密钥并存储在集群JS中。 （如果他们禁用它，NS 使用 JS 查找，就像启用集群中没有 JS 时一样）。

所以这只是允许用户跳过加入服务器提交步骤的问题吗？ 根本没有对js的请求？

确实。

一个例子是具有 Semtech 调制解调器的设备，它使用 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. 血压： !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。 对于多播和 ABP，输入会话信息（ DevAddr和密钥）是相同的。

resets_join_nonces也可以在 JS 中使用 1.1.x 设置

拆分设备创建是绝对必要的，这是一种使流程和实现更接近后端需求的好方法，同时降低用户的复杂性。

我看到的一些想法和挑战：

• 我们应该添加功能以中止整个流程，从而删除已创建的任何注册表项。
  
  
  
  • 同样，进入上一步需要将表单置于“更新模式”（应该相对容易，因为端点相同，除了 IS）
  
  
• 我看到的一个问题是应用程序服务器步骤非常浅（以后可能会改变吗？）并且在创建设备时添加有效负载格式选项也并不真正符合用户的需求。
  
  
  
  • 一个解决方案可能是合并 AS 和 JS 步骤，因为两者都非常简单且不相互依赖。 我意识到这违背了组件的分离，但我认为这将通过合理的抽象简化整个流程。 特别是考虑到我们没有在步骤中与相应的堆栈组件通信任何连接。
  
  
• 根据堆栈配置，我们最终可能会得到一个只有一两个步骤的向导，这是向导的反模式。
  
  
  
  • 对于只有一步的情况，我们可以简单地隐藏/删除向导方面
  
  
  • 对于两个步骤，我认为我们必须忍受这个问题🤷‍♂
  
  
• 应该考虑到向导解决方案会增加相当多的用户故事的_time-to-complete_
  
  
  
  • 在需要手动创建大量设备的情况下，这可能会成为一个问题，尽管我们将为此用例引入批量创建功能，并且 CLI/脚本也可以帮助解决这种情况
  
  
  • 尽管如此，请考虑与 V2 控制台设备创建的差异以及用户如何看待这种变化
  
  
• 我喜欢通用设置的相应“分段编辑”解决方案
• 流程图非常有用，我们应该保持更新👍

用于批量创建/更新/删除以及创建回滚逻辑的 js sdk 中不必要的复杂性

我认为 SDK 中用于拆分和合并设备请求的功能仍然非常有价值，即使我们在这种情况下不使用它

多播设备 NS 的@johanstokking只需要 1.1 中的SNwkSIntKey进行 MIC 计算。 FNwkSIntKey和NwkSEncKey实际上不应该被允许设置 IMO。

• 我们应该添加功能以中止整个流程，从而删除已创建的任何注册表项。
  
  
  
  • 同样，进入上一步需要将表单置于“更新模式”（应该相对容易，因为端点相同，除了 IS）
  
  

我认为我们不应该在点击Finish之前创建任何东西。 在向导中来回切换并关闭浏览器窗口不应导致设备创建一半。

• 我看到的一个问题是应用程序服务器步骤非常浅（以后可能会改变吗？）并且在创建设备时添加有效负载格式选项也并不真正符合用户的需求。

我们将在此处添加应用程序包的配置（即远程多播设置、分段数据块传输、Semtech 调制解调器选项等）。 所以是的，它现在很浅，但它会被扩展。

• 一个解决方案可能是合并 AS 和 JS 步骤，因为两者都非常简单且不相互依赖。 我意识到这违背了组件的分离，但我认为这将通过合理的抽象简化整个流程。 特别是考虑到我们没有在步骤中与相应的堆栈组件通信任何连接。

对于我们未来的自己，我建议将它们分开。 此外，将它们结合起来会使这些页面上的渲染内容取决于组件的可用性，这增加了已经很复杂的流程的复杂性。

• 根据堆栈配置，我们最终可能会得到一个只有一两个步骤的向导，这是向导的反模式。

  • 对于只有一步的情况，我们可以简单地隐藏/删除向导方面
  • 对于两个步骤，我认为我们必须忍受这个问题🤷‍♂

• 应该考虑到向导解决方案会增加相当多的用户故事的_time-to-complete_

  • 在需要手动创建大量设备的情况下，这可能会成为一个问题，尽管我们将为此用例引入批量创建功能，并且 CLI/脚本也可以帮助解决这种情况
  • 尽管如此，请考虑与 V2 控制台设备创建的差异以及用户如何看待这种变化

与 V2 相比，组件的分离和灵活的部署场景是关键变化之一，因此在 V3 Console 中这是有效的。

事实上，为了创建大量设备，人们无论如何都应该使用 API 和 CLI。

没有一个步骤的场景，它总是至少有两个步骤。

渲染标签而不是页面怎么样？ 这样，它仍然是一页，但无需逐步来回即可轻松访问内容。

@johanstokking

我认为我们不应该在点击 Finish 之前创建任何东西。

如果我们只在最后一步发出实际请求，那么这意味着我们将发出 3-4 个请求。 我们如何处理不同组件返回的错误？ 处理这个，将用户导航到错误的步骤/重置存储/等。 很复杂。 这就是为什么我建议在每一步都提交值，因为每个后续步骤都可以依赖提交的值作为有效值。

在向导中来回切换并关闭浏览器窗口不应导致设备创建一半。

我反对允许用户在向导中编辑数据（对于导致提交的步骤）。 Mb，仅存储在单个组件中的可选字段（并且没有其他组件需要这些），例如name ， description 。 否则处理这个变得相当复杂。

@kschiffer

根据堆栈配置，我们最终可能会得到一个只有一两个步骤的向导，这是向导的反模式。

好吧，我们对替代解决方案持开放态度。 有什么提议吗？

如果我们只在最后一步发出实际请求，那么这意味着我们将发出 3-4 个请求。 我们如何处理不同组件返回的错误？ 处理这个，将用户导航到错误的步骤/重置存储/等。 很复杂。 这就是为什么我建议在每一步都提交值，因为每个后续步骤都可以依赖提交的值作为有效值。

好的。 没关系，只要控制台可以处理 ER 中但由于该步骤失败或用户关闭选项卡或其他原因而在 JS/NS/AS 中找不到的设备。

我反对允许用户在向导中编辑数据（对于导致提交的步骤）。 Mb，仅存储在单个组件中的可选字段（并且没有其他组件需要这些），例如name ， description 。 否则处理这个变得相当复杂。

你的意思是？

请注意，例如，AS 不需要任何字段，它只需要设备存在即可。 因此，如果 AS 存在，即使用户没有为 AS 输入任何值，它仍然应该在 AS 中创建一个（空）设备。

你的意思是？

对不起。 这是针对@kschiffer 的建议：

同样，进入上一步需要将表单置于“更新模式”（应该相对容易，因为端点相同，除了 IS）

在向导中来回切换并关闭浏览器窗口不应导致设备创建一半。

我认为这是未来的改进。 现在我们可以只向用户显示未完成流程的通知。 稍后，用户可以在常规设置页面中编辑/删除设备。

好吧，我们对替代解决方案持开放态度。 有什么提议吗？

好吧，我认为鉴于这种特殊情况的_edge-casiness_，可以忍受这个问题。 你的措辞表明我不应该在没有提出解决方案的情况下提出问题，但如果我不能立即找到任何解决方案，我愿意让其他人有机会提出一些问题。

我反对允许用户在向导中编辑数据（对于导致提交的步骤）。 Mb，仅存储在单个组件中的可选字段（并且没有其他组件需要这些），例如name ， description 。 否则处理这个变得相当复杂。

这将再次打破向导模式的最佳实践。 用户可能希望修改或简单地检查较早的字段，尤其是考虑到这些字段是相互依赖的。 我最初不包括此功能是可以的，但最终应该添加它（如：在问题中跟踪）。

否则处理这个变得相当复杂。

一般来说，实现复杂前端逻辑的必要性不应该影响我们对用户体验的承诺。

我认为这是未来的改进。 目前，我们可以只向用户显示未完成流程的通知。 稍后，用户可以在常规设置页面中编辑/删除设备。

不是最优的，但对我来说可以接受，只要我们最终会增强它。

正如离线讨论的那样，这是最初的提议；

创建设备

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 （必填）
     
     
     • 如果激活模式为 OTAA，则设置supports_join （必需）
     
     
     • 如果激活模式是多播，则设置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应该足够了）
  
  

支持更新设备的一些用例：

• Console可以在集群中有NS、AS和JS，但是设备可能不在NS、AS或者JS中（Console得到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. 通用设置
   一种。 当我们在 ER 中创建设备时，我们不设置 NS/AS/JS 地址。 当设备设置在这些设备中时，我们是否更新 ER 注册？ 如果我们使用外部 JS 怎么办？
   湾。 我们是否将激活模式存储在 ER 中？
   C。 我们是否将 phy/mac 版本存储在 ER 中？
2. LoRaWAN 设置
   一种。 supports_class_b怎么样？
3. 应用程序设置
   一种。 是的，这可能意味着我们在 AS 上设置了两次设备

更新：

• 激活模式：如果我们将其存储在 ER 中会容易得多
• 我们是只查看 404 还是查看 ER 中的 NS/AS/JS 地址？
• 我认为能够删除单个 NS/AS/JS 注册会很好，例如在将“外部 JS”更改为true或在 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都应该可以为所有非多播设备设置。
对于多播设备，只有以下内容有意义：

这个问题的问题之一是隐藏在评论中的信息量。

你能在正确的地方添加_exactly_字段吗？ 如果你复制我的整个项目符号列表，我很好，所以我们会逐步进行工作，直到我们有最终版本。

@htdvisser

1. 通用设置
   一种。 当我们在 ER 中创建设备时，我们不设置 NS/AS/JS 地址。 当设备设置在这些设备中时，我们是否更新 ER 注册？ 如果我们使用外部 JS 怎么办？

我认为我们在 AS/NS/JS 中设置设备时应该更新地址。

湾。 我们是否将激活模式存储在 ER 中？

不，我们目前没有这个领域，我们真的不需要它，它为不一致创造了空间。

C。 我们是否将 phy/mac 版本存储在 ER 中？

否，请参阅 API 文档。 同样，我看不出有必要，它为不一致创造了空间。

一种。 supports_class_b怎么样？

是的，我想我们应该补充一点，待定 #19。 @rvolosatovs如果相关，请将其包含在更新版本中。

1. 应用程序设置
   一种。 是的，这可能意味着我们在 AS 上设置了两次设备

是的，这不痛

更新：

• 激活模式：如果我们将其存储在 ER 中会容易得多

是的，但我不确定我们是否应该追求轻松，以及这是否完全适用。 我们需要让它在热路径中可用。

此外，只有从头开始，这才容易。 但是，我们需要向后兼容，当lorawan_version不在 ER 中时添加启发式，从 NS 引入条件获取等。

• 我们是只查看 404 还是查看 ER 中的 NS/AS/JS 地址？

如果设置了地址，我们只能得到 404，否则就什么也得不到。 我们应该将两者都解释为“不在该注册表中”。 我们不能在这里出错（就像我们之前所做的那样），正是因为在 IS 和 AS/NS/JS 中的创建不会同时发生，用户应该能够恢复由控制台创建的不一致。

• 我认为能够删除单个 NS/AS/JS 注册会很好，例如在将“外部 JS”更改为true或在 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 ； 哪个是创建的一部分，哪个是更新的一部分，它们之间的关系如何？
• 我们不应该改变个人计数器； 一个“重置帧计数器”按钮就可以了（这 afaik 可以是一个单独的操作，就像我们在 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 状态。
我会更新你的评论。

我们不应该改变个人计数器； 一个“重置帧计数器”按钮会做（这 afaik 可以是一个单独的动作，就像我们在 V2 控制台中所做的那样，将计数器设置为 0）

我们确实需要能够为 ABP 和多播设置下行帧计数器 - 否则 NS 无法发送下行链路
从安全角度来看，对于 ABP，上行帧计数器也非常有用

更新设备

在这里，我将采用选项卡式方法，基本上将向导步骤作为选项卡。

让我们在这里使用手风琴方法，如@bafonins的第一条评论中所述：

它将减少水平空间的问题，并允许使用Edit / Create按钮区分模式。

@rvolosatovs

我们确实需要能够为 ABP 和多播设置下行帧计数器 - 否则 NS 无法发送下行链路
从安全角度来看，对于 ABP，上行帧计数器也非常有用

如果这很简单，我们可以做到。 事实上，两个/三个输入框可能比触发特定操作的重置按钮更简单。

关于控制台中应该包含的内容， mac_state的所有内容可能只能通过 CLI 进行设置，但是我们可能要求在现有会话中注册的 ABP/多播设备和/或 OTAA 设备，并且，因此 MAC 状态。

我明白。 我认为我们应该将“新的和重置的 ABP 设备”与“已经在网络上的现有 ABP 设备”分开。

前者应该是完整的，所以它应该包括一些mac_state （即出厂重置频率、RX1 延迟、RX2 设置等），但不包括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不进行payload加解密
  
  
  
  • 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 ：禁用它，不要在意