Lorawan-stack: Используйте мастер для создания конечных устройств

Основная проблема с текущей реализацией формы устройства заключается в том, что все взаимосвязано. Это вызывает

1. Сложная и долгая схема проверки
2. Нет простого способа отключить определенные поля на основе конфигурации стека.
3. Нет простого способа изменить поля формы/названия полей в соответствии с выбранными значениями
4. Ненужная сложность в js sdk для пакетного создания/обновления/удаления, а также логика отката создания

Я предлагаю реализовать форму устройства как многоступенчатую форму. Это может выглядеть примерно так:

Такой подход решает все вопросы, упомянутые выше:

1. Вместо одной сложной схемы мы определяем маленькую для каждого шага.
2. Просто отключите весь шаг, если определенный ответственный компонент недоступен в стеке. Более того, мы можем сообщить об этом пользователю через описание/уведомление.
3. Адаптируйте каждый шаг в зависимости от ранее отправленных значений. Например, измените метку Join EUI на App EUI для версии lorawan 1.0.x .
4. Нет необходимости в пакетных запросах. Пользователь становится ответственным за создание устройства в различных компонентах. Однако мы можем захотеть сохранить пакетное удаление для удобства.

Устройства редактирования могут быть реализованы в виде стека аккордеонов:

Где каждый аккордеон расширяется в отдельную форму.

Помимо формы устройства мы также можем использовать мастер для формы заявки, чтобы:

1. Создайте приложение в is
2. Связать приложение как

копия @kschiffer @johanstokking @htdvisser

Звучит неплохо, особенно если мы можем сгруппировать поля для компонентов вместе за один шаг. Таким образом, мы можем просто пропускать/отключать шаги, когда компонент недоступен.

Ссылка также на https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 ; даже если JS доступен, пользователь может пропустить поля JS.

Я придумал такую ​​схему:

Каждый узел — это шаг

• Шаги с пунктирным контуром не отправляют форму, но сохраняют ее в локальном состоянии для следующих шагов.
• Другие отправляют запросы на сервер при отправке.

Это выглядит сложно, но текущая реализация имеет еще большее пространство состояний в отношении проверки/отправки/генерации маски поля и т.д.

Рассмотрите диаграмму как исходное предложение для начала обсуждения.

Я думаю, это хорошее начало.

• Возможно, поток был бы лучше, если бы сервер присоединения был первым.
• Важная вещь, в которой мы еще не продвинулись, — это предварительное заполнение полей из шаблонов устройств в репозитории устройств № 263. Я думаю, что это могло бы действительно упростить процесс развертывания в производственной среде.

И немного мелочей:

• DevEUI не запрещен для устройств ABP (может быть установлен опционально)
• У устройств 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

• FNwkSIntKey отсутствует в настройках ABP NS для >= 1.1
• Устройствам multicast нужны только AppSKey — NS не нужны никакие ключи для работы устройств multicast , только AS

@htdvisser

Возможно, поток был бы лучше, если бы сервер присоединения был первым.

Почему?

Важная вещь, в которой мы еще не продвинулись, — это предварительное заполнение полей из шаблонов устройств в репозитории устройств № 263. Я думаю, что это могло бы действительно упростить процесс развертывания в производственной среде.

Для меня это выходит за рамки этого вопроса

DevEUI не запрещен для устройств ABP (может быть установлен опционально)

Хотим ли мы установить его и для устройств 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

Activation mode" находится в полезной нагрузке - на вашей диаграмме ему соответствуют фактически 2 поля - multicast bool и supports_join bool. Возможны 3 варианта, так как multicast && supports_join недействителен.

Просто для уточнения:

1. supports_join=true - OTAA
2. supports_join=false – ABP
3. multicast=true && **no** supports_join - многоадресная рассылка
   Это правильно?

resets_f_cnt является необязательным, по умолчанию false.

Я думаю, что это все еще нормально, чтобы показать это пользователям. Следует ли разрешить пользователям устанавливать его для многоадресных устройств?

FNwkSIntKey должен быть представлен как NwkKey только для <1.1

Вы имеете в виду NwkSKey ?

частота_план -> частота_план_ид
FNwkSIntKey отсутствует в настройках ABP NS для >= 1.1

Исправлено 👌

Обновленная схема:

@htdvisser

Возможно, поток был бы лучше, если бы сервер присоединения был первым.

Почему?

Да, я возвращаюсь к этому; Я думаю, что имеет смысл вводить версии MAC перед вводом ключей. Так что я поддерживаю текущий поток. Если введена версия MAC (когда включен NS), нам не нужно запрашивать NwkKey , так как это 1.1.x.

Важная вещь, в которой мы еще не продвинулись, — это предварительное заполнение полей из шаблонов устройств в репозитории устройств № 263. Я думаю, что это могло бы действительно упростить процесс развертывания в производственной среде.

Для меня это выходит за рамки этого вопроса

Это действительно выходит за рамки.

DevEUI не запрещен для устройств ABP (может быть установлен опционально)

Хотим ли мы установить его и для устройств ABP? Я бы сказал, чем меньше у нас полей, тем лучше. Тем не менее, это необходимо, мы можем добавить его.

Да, мы хотим дополнительно попросить об этом. Чем больше у нас будет идентификационной информации о конечных устройствах, тем лучше. Это также требуется в пассивном роуминге с отслеживанием состояния. Причина, по которой мы не заставляем пользователей вводить DevEUI, заключается в том, что если нет DevEUI, мы не хотим, чтобы пользователи вводили фиктивные значения.

FNwkSIntKey называется NwkSKey (по направлению к пользователю)

Таким образом, метка должна быть NwkSKey как для 1.0.x, так и для 1.1.x? Вот что у нас есть atm в консоли:

Это NwkSKey для 1.0.x и FNwkSIntKey для 1.1.x.

Если режим активации — 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. ОТАА: supports_join
2. АД: !supports_join && !multicast
3. Многоадресная рассылка: multicast

Недействительным является supports_join && multicast , но это (или должно быть) проверено в NS.

resets_f_cnt является необязательным, по умолчанию false.

Я думаю, что это все еще нормально, чтобы показать это пользователям. Следует ли разрешить пользователям устанавливать его для многоадресных устройств?

Нет, это не для мультикаста. resets_f_cnt относится к восходящему каналу, но в многоадресной рассылке восходящего канала нет.

FNwkSIntKey должен быть представлен как NwkKey только для <1.1

Вы имеете в виду NwkSKey ?

Должно быть действительно NwkSKey .

@bafonins, пожалуйста, смотрите ответ @johanstokking .
Что касается multicast — также требуется адрес устройства.

• Добавлены поля с https://github.com/TheThingsNetwork/lorawan-stack/issues/1134.
• Добавлено DevEUI на устройства abp/multicast.
• Добавлено Device Address на многоадресные устройства.
  

Адрес устройства по-прежнему отсутствует в настройках сетевого сервера устройства multicast

Адрес устройства по-прежнему отсутствует в настройках сетевого сервера многоадресного устройства

Обновлено 👌

Мультикаст может быть 1.0.x и 1.1.x. Ввод информации о сеансе ( DevAddr и ключи) для многоадресной рассылки такой же, как и для ABP.

Также resets_join_nonces можно установить в JS с 1.1.x

Разделение создания устройства определенно необходимо, и это хороший способ приблизить поток и реализацию к требованиям бэкэнда, уменьшив при этом сложность для пользователя.

Некоторые мысли и проблемы, которые я вижу:

• Мы должны добавить функциональность для прерывания всего потока, что приведет к удалению всех записей реестра, которые уже были созданы.
  
  
  
  • Аналогичным образом, переход к предыдущему шагу должен перевести форму в «режим обновления» (это должно быть относительно легко, поскольку конечные точки одинаковы, за исключением IS).
  
  
• Одна проблема, которую я вижу, заключается в том, что шаг сервера приложений очень поверхностный (вероятно, это изменится позже?) и добавление параметров формата полезной нагрузки также не совсем соответствует потребностям пользователя при создании устройства.
  
  
  
  • Решением может быть объединение шагов AS и JS, учитывая, что оба они довольно просты и не зависят друг от друга. Я понимаю, что это противоречит разделению по компонентам, но я думаю, что это упростило бы весь поток с разумной абстракцией. Особенно с учетом того, что мы не сообщаем о каком-либо соединении с соответствующими компонентами стека в рамках шагов.
  
  
• В зависимости от конфигурации стека мы можем получить мастер, который имеет только один или два шага, что является антишаблоном для мастеров.
  
  
  
  • В случае всего одного шага мы можем просто скрыть/удалить аспект мастера
  
  
  • За два шага, я думаю, мы должны жить с проблемой 🤷‍♂
  
  
• Следует учитывать, что решение мастера значительно увеличит _время выполнения_ пользовательской истории.
  
  
  
  • Это может стать проблемой в ситуациях, когда необходимо создать множество устройств вручную, хотя мы представим функции пакетного создания для этого варианта использования, и CLI/скрипты также могут помочь в таких ситуациях.
  
  
  • Тем не менее, рассмотрите разницу с созданием консольного устройства V2 и то, как пользователи могут воспринять это изменение.
  
  
• Мне нравится соответствующее решение «сегментированного редактирования» для общих настроек.
• Блок-схема очень полезна, и мы должны обновлять ее 👍

Ненужная сложность в js sdk для пакетного создания/обновления/удаления, а также логика отката создания

Я думаю, что функциональность SDK для разделения и объединения запросов устройств по-прежнему очень ценна, даже если мы не используем ее в этом случае.

@johanstokking для многоадресных устройств NS требуется только SNwkSIntKey в 1.1 для расчета MIC. FNwkSIntKey и NwkSEncKey , на самом деле, не должны быть разрешены для установки IMO.

• Мы должны добавить функциональность для прерывания всего потока, что приведет к удалению всех записей реестра, которые уже были созданы.
  
  
  
  • Аналогичным образом, переход к предыдущему шагу должен перевести форму в «режим обновления» (это должно быть относительно легко, поскольку конечные точки одинаковы, за исключением IS).
  
  

Я не думаю, что мы должны что-то создавать до того, как нажмем «Готово» или что-то в этом роде. Переход назад и вперед в мастере и закрытие окна браузера не должно приводить к созданию наполовину созданных устройств.

• Одна проблема, которую я вижу, заключается в том, что шаг сервера приложений очень поверхностный (вероятно, это изменится позже?) и добавление параметров формата полезной нагрузки также не совсем соответствует потребностям пользователя при создании устройства.

Здесь мы добавим конфигурацию для пакетов приложений (т. е. удаленную настройку многоадресной рассылки, передачу блоков фрагментированных данных, параметры модема Semtech и т. д.). Так что да, сейчас это неглубоко, но это будет расширено.

• Решением может быть объединение шагов AS и JS, учитывая, что оба они довольно просты и не зависят друг от друга. Я понимаю, что это противоречит разделению по компонентам, но я думаю, что это упростило бы весь поток с разумной абстракцией. Особенно с учетом того, что мы не сообщаем о каком-либо соединении с соответствующими компонентами стека в рамках шагов.

Для нашего будущего я бы рекомендовал держать их отдельно. Кроме того, их объединение делает рендеринг на этих страницах зависимым от доступности компонентов, что усложняет и без того сложный процесс.

• В зависимости от конфигурации стека мы можем получить мастер, который имеет только один или два шага, что является антишаблоном для мастеров.

  • В случае всего одного шага мы можем просто скрыть/удалить аспект мастера
  • За два шага, я думаю, мы должны жить с проблемой 🤷‍♂

• Следует учитывать, что решение мастера значительно увеличит _время выполнения_ пользовательской истории.

  • Это может стать проблемой в ситуациях, когда необходимо создать множество устройств вручную, хотя мы представим функции пакетного создания для этого варианта использования, и CLI/скрипты также могут помочь в таких ситуациях.
  • Тем не менее, рассмотрите разницу с созданием консольного устройства V2 и то, как пользователи могут воспринять это изменение.

Разделение компонентов и гибкие сценарии развертывания — одно из ключевых изменений по сравнению с версией 2, поэтому вполне логично, что это эффективно в консоли версии 3.

Действительно, для создания большого количества устройств люди в любом случае должны использовать API и CLI.

Не бывает сценария с одним шагом, всегда минимум два шага.

Как насчет рендеринга вкладок вместо страниц? Таким образом, это по-прежнему одна страница, но к вещам легко получить доступ, не переходя назад и вперед по шагам.

@johanstokking

Я не думаю, что мы должны что-то создавать до того, как нажмем «Готово» или что-то в этом роде.

Если мы делаем собственно запрос только на последнем шаге, то это значит, что мы сделаем 3-4 запроса. Как мы обрабатываем ошибки, возвращаемые разными компонентами? Обработка этого, навигация пользователя к ошибочному шагу/сбросу хранилища/и т. д. сложный. Вот почему я предлагаю отправлять значения на каждом этапе, потому что каждый последующий шаг может полагаться на представленные значения как на действительные.

Переход назад и вперед в мастере и закрытие окна браузера не должно приводить к созданию наполовину созданных устройств.

Я против разрешения пользователям редактировать данные в мастере (для шагов, которые приводят к отправке). Мб, только необязательные поля, которые хранятся в одном компоненте (и никаким другим компонентам они не нужны), скажем, name , description . В противном случае обработка этого становится довольно сложной.

@kschiffer

В зависимости от конфигурации стека мы можем получить мастер, который имеет только один или два шага, что является антишаблоном для мастеров.

Что ж, мы открыты для альтернативных решений. Есть предложения?

Если мы делаем собственно запрос только на последнем шаге, то это значит, что мы сделаем 3-4 запроса. Как мы обрабатываем ошибки, возвращаемые разными компонентами? Обработка этого, навигация пользователя к ошибочному шагу/сбросу хранилища/и т. д. сложный. Вот почему я предлагаю отправлять значения на каждом этапе, потому что каждый последующий шаг может полагаться на представленные значения как на действительные.

OK. Это нормально, пока консоль может обрабатывать устройства, которые находятся в ER, но не могут быть найдены в JS/NS/AS, потому что этот шаг не удался или пользователь закрыл вкладку или что-то в этом роде.

Я против разрешения пользователям редактировать данные в мастере (для шагов, которые приводят к отправке). Мб, только необязательные поля, которые хранятся в одном компоненте (и никаким другим компонентам они не нужны), скажем, name , description . В противном случае обработка этого становится довольно сложной.

Что ты имеешь в виду?

Обратите внимание, что этому AS, например, не нужны никакие поля, ему просто нужно, чтобы устройство существовало. Поэтому, если AS есть, даже если пользователь не вводит никаких значений для AS, он все равно должен создать (пустое) устройство в AS.

Что ты имеешь в виду?

Извиняюсь. Это было к предложению @kschiffer :

Аналогичным образом, переход к предыдущему шагу должен перевести форму в «режим обновления» (это должно быть относительно легко, поскольку конечные точки одинаковы, за исключением IS).

Переход назад и вперед в мастере и закрытие окна браузера не должно приводить к созданию наполовину созданных устройств.

Я бы рассматривал это как будущее улучшение. Пока мы можем просто показать пользователю уведомление о незавершенном потоке. Позже пользователь может отредактировать/удалить устройство на странице общих настроек.

Что ж, мы открыты для альтернативных решений. Есть предложения?

Что ж, я думаю, что, учитывая _крайность_ этой конкретной ситуации, можно мириться с этой проблемой. Ваша формулировка предполагает, что я не должен озвучивать проблемы без предложенных решений, но мне нравится давать другим возможность придумать некоторые из них, если я не могу найти их сразу.

Я против разрешения пользователям редактировать данные в мастере (для шагов, которые приводят к отправке). Мб, только необязательные поля, которые хранятся в одном компоненте (и никаким другим компонентам они не нужны), скажем, name , description . В противном случае обработка этого становится довольно сложной.

Это снова нарушит лучшие практики для шаблона мастера. Пользователи, скорее всего, захотят пересмотреть или просто проверить более ранние поля, особенно если учесть, что они взаимозависимы. Я согласен с тем, что изначально не включал эту функцию, но в конечном итоге ее следует добавить (например, отслеживать в задаче).

В противном случае обработка этого становится довольно сложной.

Вообще говоря, необходимость реализации сложной логики внешнего интерфейса не должна влиять на нашу приверженность UX.

Я бы рассматривал это как будущее улучшение. На данный момент мы можем просто показать пользователю уведомление о незавершенном потоке. Позже пользователь может отредактировать/удалить устройство на странице общих настроек.

Не оптимально, но приемлемо для меня, если мы в конечном итоге улучшим это.

Как обсуждалось в автономном режиме, вот первоначальное предложение;

Создать устройство

1. Общие настройки
   
   
   
   • Поля
     
     
     
     
     
     • ids
     
     
     
     • Дополнительно name
     
     
     
     • Дополнительно description
     
     
     
     • Дополнительно attributes
     
     
     
     • Требуемый режим активации: OTAA, ABP или Multicast
     
     
     
     • Если 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 или Multicast
     
     
     
     • Если 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.
• Основываясь на предыдущем: установите настройки LoRaWAN и приложения устройства, которое находится только в ER и JS (т.е. установите его в NS и AS)
• Изменение lorawan_version и lorawan_phy_version (это изменяет ограничения)
• Изменение опции «внешний JS»; т.е. скажем, у вас есть существующее устройство, но вы хотите настроить корневые ключи в кластере-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_частота"

Может быть, что-то уточнить

Создавать:

1. общие настройки
   а. Когда мы создаем устройство в ER, мы не устанавливаем адреса NS/AS/JS. Обновляем ли мы регистрацию ER, когда устройство установлено в них? Что, если мы используем внешний JS?
   б. Сохраняем ли мы режим активации в ER?
   в. Храним ли мы версии phy/mac в ER?
2. Настройки LoRaWAN
   а. Как насчет supports_class_b ?
3. Настройки приложения
   а. Да, это может означать, что мы установили устройство на AS дважды

Обновлять:

• Режим активации: было бы намного проще, если бы мы сохранили это в ER
• Мы смотрим только на 404 или также на адреса NS/AS/JS в ER?
• Я думаю, было бы неплохо иметь возможность удалить отдельную регистрацию 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 должны быть доступны для установки для всех устройств без многоадресной рассылки.
Для многоадресных устройств имеет смысл только следующее:

Одной из проблем с этой проблемой является количество информации, скрытой в комментариях.

Не могли бы вы добавить _точно_ поля в нужных местах? Я не против, если вы скопируете весь мой список пунктов, чтобы мы постепенно работали над ним, пока не получим окончательную версию.

@htdvisser

1. общие настройки
   а. Когда мы создаем устройство в ER, мы не устанавливаем адреса NS/AS/JS. Обновляем ли мы регистрацию ER, когда устройство установлено в них? Что, если мы используем внешний JS?

Я думаю, что мы должны обновить адреса, когда мы устанавливаем устройства в AS/NS/JS.

б. Сохраняем ли мы режим активации в ER?

Нет, на данный момент у нас нет поля для этого, оно нам на самом деле не нужно, и это создает место для несоответствий.

в. Храним ли мы версии phy/mac в ER?

Нет, см. документацию по API. Опять же, я не вижу необходимости, и это создает место для несоответствий.

а. Как насчет supports_class_b ?

Да, я думаю, мы должны добавить это, ожидая № 19. @rvolosatovs, пожалуйста, включите это в обновленную версию, если это уместно.

1. Настройки приложения
   а. Да, это может означать, что мы установили устройство на AS дважды

Да, это не больно

Обновлять:

• Режим активации: было бы намного проще, если бы мы сохранили это в ER

Да, но я не уверен, следует ли нам стремиться к легкости и применимо ли это в полной мере. Нам нужно, чтобы он был доступен на горячем пути.

Кроме того, было бы легко, только если бы мы могли начать с чистого листа. Однако нам нужно обеспечить обратную совместимость, добавить эвристику, когда lorawan_version не находится в ER, ввести условные запросы из NS и т. д.

• Мы смотрим только на 404 или также на адреса NS/AS/JS в ER?

Мы можем получить ошибку 404 только в том случае, если установлен адрес, иначе нам нечего будет получить. Мы должны интерпретировать оба как «не в этом реестре». Здесь мы не можем ошибаться (как раньше) именно по той причине, что создание в IS и AS/NS/JS происходит не одновременно, и пользователи должны иметь возможность восстанавливать несоответствия, созданные Консолью.

• Я думаю, было бы неплохо иметь возможность удалить отдельную регистрацию NS/AS/JS, например, при изменении «внешнего JS» на true или сбросить состояние устройства в NS.

Да, давай сделаем это позже

• _ "Внешний JS - это когда JS не находится в том же кластере, что и NS"_: я думаю, это должно быть что-то вроде "join_server_address не совпадает с адресом JS в конфигурации консоли"

Да, это действительно способ проверить это. join_server_address также может быть пустым, используя interop.

@bafonins у вас все еще есть источник графика?
Поскольку для его создания уже было проделано много работы, я думаю, мы должны просто обновить его, чтобы сделать его полным и иметь четкое представление?
Мы также можем работать над обновлением части NS в автономном режиме, чтобы не загромождать обсуждение здесь.

Я обновил график со всеми возможными полями NS
Поля, выделенные красным, обязательны для заполнения

@rvolosatovs мы стремимся определить поток и поля, которые мы представляем в консоли при создании и обновлении устройств.

В качестве таких,

• Мы не должны позволять изменять mac_state.lorawan_version
• Сейчас мы можем сделать mac_state.ping_slot_periodicity через CLI
• Пожалуйста, подумайте о том, как пользователь будет устанавливать 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.

Если это просто, мы можем это сделать. На самом деле, два/три поля ввода могут быть проще, чем кнопка сброса, которая запускает определенное действие.

Что касается того, что должно быть в консоли, все 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 и Multicast?

@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 и Multicast?

Все настройки MAC являются необязательными по замыслу.
Единственный случай, когда они «требуются», — это многоадресные устройства класса B, что связано со спецификой работы класса B.
Кроме того, для достижения наилучших результатов, вероятно, потребуется factory_preset_frequencies для ABP, но ничто не мешает устройству OTAA иметь этот набор.

Все настройки MAC являются необязательными по замыслу.
Единственный случай, когда они «требуются», — это многоадресные устройства класса B, что связано со спецификой работы класса B.

Ok

Кроме того, factory_preset_frequencies , вероятно, потребуется для ABP для достижения наилучших результатов, но ничто не мешает устройству OTAA иметь этот набор.

Это неэффективно для OTAA; частоты соединения по умолчанию требуются по спецификации, а каналы поступают с помощью команд join-accept и MAC. Не должно быть внеполосной настройки предустановленных частот для устройств OTAA.

@bafonins , можете ли вы дать обновление статуса и сроки по этой проблеме?

Для app_s_key и skip_payload_crypto вот в чем дело;

• AS учитывает поле skip_payload_crypto конечного устройства. Если true , AS не выполняет шифрование и дешифрование полезной нагрузки.
  
  
  
  • AS также получит skip_payload_crypto на уровне приложения (через Link, например форматтеры полезной нагрузки), что имеет приоритет над настройкой конечного устройства.
  
  
• Вероятно, в 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 : отключите его, все равно