Lorawan-stack: Utilice un asistente para crear dispositivos finales

El principal problema con la implementación actual de la forma de dispositivo es que todo está acoplado. Esto causa

1. Esquema de validación largo y complejo
2. No hay una forma sencilla de deshabilitar ciertos campos según la configuración de la pila
3. No hay una forma sencilla de cambiar los campos de formulario/títulos de campo según los valores seleccionados
4. Complejidad innecesaria en js sdk para creación/actualización/eliminación por lotes, así como lógica de reversión de creación

Propongo implementar el formulario de dispositivo como el formulario de varios pasos. Esto puede verse algo como esto:

Dicho enfoque aborda todos los problemas mencionados anteriormente:

1. En lugar de un esquema complejo, definimos uno pequeño para cada paso.
2. Simplemente deshabilite todo el paso si un determinado componente responsable no está disponible en la pila. Además, podemos informar al usuario sobre esto a través de una descripción/notificación.
3. Adapte cada paso en función de los valores enviados anteriormente. Por ejemplo, cambie la etiqueta Join EUI a App EUI para la versión de lorawan 1.0.x .
4. No hay necesidad de solicitudes por lotes. El usuario se hace responsable de crear el dispositivo en diferentes componentes. Sin embargo, es posible que deseemos mantener la eliminación por lotes por conveniencia.

Los dispositivos de edición se pueden implementar como una pila de acordeones:

Donde cada acordeón se expande con una forma independiente.

Además del formulario de dispositivo, también podemos usar el asistente para el formulario de solicitud para:

1. Crear la aplicación en el es
2. Vincular la aplicación a como

CC @kschiffer @johanstokking @htdvisser

Me parece bien, especialmente si podemos agrupar campos para componentes en un solo paso. De esa manera, podemos simplemente omitir/deshabilitar pasos cuando un componente no está disponible.

Haciendo referencia a https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 también; incluso si JS está disponible, el usuario puede omitir los campos de JS.

Se me ocurrió tal diagrama:

Cada nodo es un paso

• Los pasos con contorno punteado no envían el formulario, pero manténgalo en el estado local para los próximos pasos.
• Otros envían solicitudes al servidor en el momento del envío.

Parece complicado, pero la implementación actual tiene un espacio de estado aún mayor con respecto a la validación/envío/generación de máscaras de campo/etc.

Considere el diagrama como una propuesta inicial para iniciar la discusión.

Creo que este es un buen comienzo.

• Tal vez el flujo sería mejor si el servidor de unión fuera lo primero.
• Una cosa importante en la que aún no hemos hecho ningún progreso es el llenado previo de los campos de las plantillas de dispositivos en el repositorio de dispositivos #263. Creo que eso realmente podría simplificar el proceso para las implementaciones de producción.

Y algunas cositas:

• Un DevEUI no está prohibido para dispositivos ABP (se puede configurar opcionalmente)
• Los dispositivos LoRaWAN 1.0.x no tienen un NwkKey , solo un AppKey
• FNwkSIntKey se llama NwkSKey (hacia el usuario)
• El servidor de aplicaciones no obtiene NwkKey o AppKey

Sí, gran comienzo.

• Tal vez el flujo sería mejor si el servidor de unión fuera lo primero.

Estoy de acuerdo con ésto. Si el modo de activación es OTAA y el clúster JS está habilitado, en la página JS, los usuarios tienen la opción de ingresar claves raíz y almacenarlas en el clúster JS. (si lo deshabilitan, NS usa la búsqueda de JS, al igual que cuando no hay JS en el clúster habilitado)

• El "modo de activación" está en la carga útil; en su diagrama, corresponde en realidad a 2 campos: multicast bool y supports_join bool . Hay 3 opciones posibles, ya que multicast && supports_join no es válido.
• frequency_plan -> frequency_plan_id

• resets_f_cnt es opcional, false por defecto.

• FNwkSIntKey debe presentarse como NwkKey solo para <1.1

• Falta FNwkSIntKey en la configuración de ABP NS para >= 1.1
• Los dispositivos multicast solo necesitan AppSKey - NS no necesita ninguna clave para que los dispositivos multicast funcionen, solo AS

@htdvisser

Tal vez el flujo sería mejor si el servidor de unión fuera lo primero.

¿Por qué?

Una cosa importante en la que aún no hemos hecho ningún progreso es el llenado previo de los campos de las plantillas de dispositivos en el repositorio de dispositivos #263. Creo que eso realmente podría simplificar el proceso para las implementaciones de producción.

Para mí parece fuera del alcance de este problema.

Un DevEUI no está prohibido para dispositivos ABP (se puede configurar opcionalmente)

¿Queremos configurarlo también para dispositivos ABP? Yo diría que cuantos menos campos tengamos, mejor. Sin embargo, es necesario que podamos agregarlo.

FNwkSIntKey se llama NwkSKey (hacia el usuario)

¿Entonces la etiqueta debería ser NwkSKey tanto para 1.0.x como para 1.1.x? Esto es lo que tenemos atm en la consola:

• Los dispositivos LoRaWAN 1.0.x no tienen una NwkKey, solo una AppKey
• El servidor de aplicaciones no obtiene la NwkKey o la AppKey

Fijo 👌

@johanstokking

Si el modo de activación es OTAA y el clúster JS está habilitado, en la página JS, los usuarios tienen la opción de ingresar claves raíz y almacenarlas en el clúster JS. (si lo deshabilitan, NS usa la búsqueda de JS, al igual que cuando no hay JS en el clúster habilitado).

Entonces, ¿se trata solo de permitir que los usuarios se salten el paso de envío de unión al servidor? ¿No hay solicitudes para js en absoluto?

Con respecto a https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 , ¿podría también especificar dónde pertenecen estos campos en el diagrama?

@rvolosatovs

El modo de activación" está en la carga útil: en su diagrama corresponde a 2 campos: multicast bool y support_join bool. Hay 3 opciones posibles, ya que multicast && support_join no es válido.

Solo para aclarar:

1. supports_join=true - OTAA
2. supports_join=false - PAA
3. multicast=true && **no** supports_join - multidifusión
   ¿Es esto correcto?

resets_f_cnt es opcional, falso por defecto.

Creo que todavía está bien mostrárselo a los usuarios. ¿Debería permitir a los usuarios configurarlo para dispositivos de multidifusión?

FNwkSIntKey debe presentarse como NwkKey solo para <1.1

¿Quieres decir NwkSKey ?

frecuencia_plan -> frecuencia_plan_id
Falta FNwkSIntKey en la configuración de ABP NS para >= 1.1

Fijo 👌

Diagrama actualizado:

@htdvisser

Tal vez el flujo sería mejor si el servidor de unión fuera lo primero.

¿Por qué?

Sí, estoy volviendo sobre esto; Creo que tiene más sentido ingresar versiones MAC antes de ingresar claves. Así que estoy apoyando el flujo actual. Si se ingresa la versión MAC (cuando NS está habilitado), no tenemos que pedir NwkKey ya que es 1.1.x.

Una cosa importante en la que aún no hemos hecho ningún progreso es el llenado previo de los campos de las plantillas de dispositivos en el repositorio de dispositivos #263. Creo que eso realmente podría simplificar el proceso para las implementaciones de producción.

Para mí parece fuera del alcance de este problema.

Está fuera de alcance de hecho.

Un DevEUI no está prohibido para dispositivos ABP (se puede configurar opcionalmente)

¿Queremos configurarlo también para dispositivos ABP? Yo diría que cuantos menos campos tengamos, mejor. Sin embargo, es necesario que podamos agregarlo.

Sí, queremos pedirlo opcionalmente. Cuanta más información de identificación tengamos sobre los dispositivos finales, mejor. También se requiere en itinerancia pasiva con estado. La razón por la que no obligamos a los usuarios a ingresar DevEUI es porque si no hay DevEUI, no queremos que los usuarios ingresen valores falsos.

FNwkSIntKey se llama NwkSKey (hacia el usuario)

¿Entonces la etiqueta debería ser NwkSKey tanto para 1.0.x como para 1.1.x? Esto es lo que tenemos atm en la consola:

Es NwkSKey para 1.0.x y FNwkSIntKey para 1.1.x.

Si el modo de activación es OTAA y el clúster JS está habilitado, en la página JS, los usuarios tienen la opción de ingresar claves raíz y almacenarlas en el clúster JS. (si lo deshabilitan, NS usa la búsqueda de JS, al igual que cuando no hay JS en el clúster habilitado).

Entonces, ¿se trata solo de permitir que los usuarios se salten el paso de envío de unión al servidor? ¿No hay solicitudes para js en absoluto?

Por supuesto.

Un ejemplo es un dispositivo con el módem de Semtech que utiliza el servidor de unión de Semtech. Solo necesitamos saber los EUI en ese caso.

Con respecto al #1134, ¿podría también especificar dónde pertenecen estos campos en el diagrama?

Pertenecen al paso JS; estos campos para ir a JS, si el JS está habilitado en el clúster y si el usuario desea aprovisionar los dispositivos en el JS.

Estos campos son opcionales.

Solo para aclarar:

1. supports_join=true - OTAA
2. supports_join=false - PAA
3. multicast=true && **no** supports_join - multidifusión
   ¿Es esto correcto?

Estrictamente:

1. OTAA: supports_join
2. PAA: !supports_join && !multicast
3. Multidifusión: multicast

Inválido es supports_join && multicast , pero esto es (o debería ser) validado en NS.

resets_f_cnt es opcional, falso por defecto.

Creo que todavía está bien mostrárselo a los usuarios. ¿Debería permitir a los usuarios configurarlo para dispositivos de multidifusión?

No, esto no es para multidifusión. resets_f_cnt se refiere al enlace ascendente, pero no hay enlace ascendente en multidifusión.

FNwkSIntKey debe presentarse como NwkKey solo para <1.1

¿Quieres decir NwkSKey ?

Debería ser NwkSKey hecho.

@bafonins , consulte la respuesta de @johanstokking .
Con respecto a multicast , también se requiere la dirección del dispositivo

• Se agregaron campos de https://github.com/TheThingsNetwork/lorawan-stack/issues/1134
• Se agregaron DevEUI a dispositivos abp/multicast
• Se agregó Device Address a los dispositivos de multidifusión
  

Aún falta la dirección del dispositivo en la configuración del servidor de red del dispositivo multicast

Aún falta la dirección del dispositivo en la configuración del servidor de red del dispositivo de multidifusión

Actualizado 👌

La multidifusión puede ser 1.0.x y 1.1.x. Ingresar la información de la sesión ( DevAddr y teclas) es lo mismo para multidifusión que para ABP.

También se puede configurar resets_join_nonces en JS con 1.1.x

Definitivamente es necesario dividir la creación del dispositivo y es una buena manera de acercar el flujo y la implementación a los requisitos del backend, al tiempo que se reduce la complejidad para el usuario.

Algunos pensamientos y desafíos que veo:

• Deberíamos agregar funcionalidad para abortar todo el flujo, lo que resultaría en la eliminación de cualquier entrada de registro que ya se haya creado.
  
  
  
  • Del mismo modo, ir al paso anterior debe poner el formulario en "modo de actualización" (debería ser relativamente fácil ya que los puntos finales son los mismos, excepto IS)
  
  
• Un problema que veo es que el paso del servidor de aplicaciones es muy superficial (¿es probable que esto cambie más adelante?) y agregar las opciones de formato de carga útil tampoco está realmente en línea con las necesidades del usuario al crear un dispositivo.
  
  
  
  • Una solución podría ser fusionar el paso AS y JS dado que ambos son bastante sencillos y no interdependientes. Me doy cuenta de que esto va en contra de la separación por componente, pero creo que esto simplificaría todo el flujo con una abstracción razonable. Especialmente dado que no comunicamos ninguna conexión a los respectivos componentes de la pila dentro de los pasos.
  
  
• Dependiendo de la configuración de la pila, podríamos terminar con un asistente que solo tiene uno o dos pasos, lo cual es un antipatrón para los asistentes.
  
  
  
  • Para el caso de un solo paso, simplemente podemos ocultar/eliminar el aspecto del asistente
  
  
  • Por dos pasos, creo que tenemos que vivir con el tema 🤷‍♂
  
  
• Debe tenerse en cuenta que la solución del asistente aumentará bastante el _tiempo de finalización_ de la historia de usuario.
  
  
  
  • Esto podría convertirse en un problema en situaciones en las que es necesario crear muchos dispositivos a mano, aunque presentaremos funciones de creación por lotes para este caso de uso y la CLI/secuencias de comandos también puede ayudar con tales situaciones.
  
  
  • Aún así, considere la diferencia con la creación del dispositivo de consola V2 y cómo los usuarios pueden percibir este cambio
  
  
• Me gusta la solución de "edición segmentada" correspondiente para la configuración general
• El diagrama de flujo es muy útil y debemos mantenerlo actualizado 👍

Complejidad innecesaria en js sdk para creación/actualización/eliminación por lotes, así como lógica de reversión de creación

Creo que la funcionalidad del SDK para dividir y fusionar solicitudes de dispositivos sigue siendo bastante valiosa, incluso si no la usamos en este caso.

@johanstokking para dispositivos de multidifusión NS solo necesita SNwkSIntKey en 1.1 para el cálculo de MIC. FNwkSIntKey y NwkSEncKey , de hecho, no se debe permitir establecer IMO.

• Deberíamos agregar funcionalidad para abortar todo el flujo, lo que resultaría en la eliminación de cualquier entrada de registro que ya se haya creado.
  
  
  
  • Del mismo modo, ir al paso anterior debe poner el formulario en "modo de actualización" (debería ser relativamente fácil ya que los puntos finales son los mismos, excepto IS)
  
  

No creo que debamos crear nada antes de presionar Finalizar o algo así. Avanzar y retroceder en el asistente y cerrar la ventana del navegador no debería generar dispositivos a medio crear.

• Un problema que veo es que el paso del servidor de aplicaciones es muy superficial (¿es probable que esto cambie más adelante?) y agregar las opciones de formato de carga útil tampoco está realmente en línea con las necesidades del usuario al crear un dispositivo.

Agregaremos la configuración para los paquetes de aplicaciones aquí (es decir, configuración remota de multidifusión, transferencia de bloques de datos fragmentados, opciones de módem Semtech, etc.). Entonces sí, ahora es poco profundo, pero se extenderá.

• Una solución podría ser fusionar el paso AS y JS dado que ambos son bastante sencillos y no interdependientes. Me doy cuenta de que esto va en contra de la separación por componente, pero creo que esto simplificaría todo el flujo con una abstracción razonable. Especialmente dado que no comunicamos ninguna conexión a los respectivos componentes de la pila dentro de los pasos.

Para nuestro futuro yo recomendaría mantenerlos separados. Además, combinarlos hace que la representación de las cosas en esas páginas dependa de la disponibilidad de los componentes, lo que agrega complejidad a un flujo ya complejo.

• Dependiendo de la configuración de la pila, podríamos terminar con un asistente que solo tiene uno o dos pasos, lo cual es un antipatrón para los asistentes.

  • Para el caso de un solo paso, simplemente podemos ocultar/eliminar el aspecto del asistente
  • Por dos pasos, creo que tenemos que vivir con el tema 🤷‍♂

• Debe tenerse en cuenta que la solución del asistente aumentará bastante el _tiempo de finalización_ de la historia de usuario.

  • Esto podría convertirse en un problema en situaciones en las que es necesario crear muchos dispositivos a mano, aunque presentaremos funciones de creación por lotes para este caso de uso y la CLI/secuencias de comandos también puede ayudar con tales situaciones.
  • Aún así, considere la diferencia con la creación del dispositivo de consola V2 y cómo los usuarios pueden percibir este cambio

La separación de componentes y los escenarios de implementación flexibles es uno de los cambios clave en comparación con V2, por lo que tiene mucho sentido que esto sea efectivo en V3 Console.

De hecho, para crear grandes cantidades de dispositivos, las personas deberían usar API y CLI de todos modos.

No hay escenario con un paso, siempre hay al menos dos pasos.

¿Qué hay de renderizar pestañas en lugar de páginas? De esa manera, sigue siendo una página, pero se puede acceder fácilmente a las cosas sin tener que ir y venir en los pasos.

@johanstokking

No creo que debamos crear nada antes de presionar Finalizar o algo así.

Si hacemos la solicitud real solo en el último paso, significa que haríamos 3-4 solicitudes. ¿Cómo manejamos los errores devueltos por diferentes componentes? Manejando esto, navegando al usuario al paso erróneo/restablecimiento de la tienda/etc. es complejo. Es por eso que sugiero enviar valores en cada paso, porque cada paso sucesivo puede confiar en los valores enviados como válidos.

Avanzar y retroceder en el asistente y cerrar la ventana del navegador no debería generar dispositivos a medio crear.

Estoy en contra de permitir que los usuarios editen datos en el asistente (para los pasos que resultan en el envío). Mb, solo campos opcionales que se almacenan en un solo componente (y ningún otro componente los necesita), digamos name , description . De lo contrario, manejar esto se vuelve bastante complicado.

@kschiffer

Dependiendo de la configuración de la pila, podríamos terminar con un asistente que solo tiene uno o dos pasos, lo cual es un antipatrón para los asistentes.

Bueno, estamos abiertos a soluciones alternativas. ¿Alguna proposición?

Si hacemos la solicitud real solo en el último paso, significa que haríamos 3-4 solicitudes. ¿Cómo manejamos los errores devueltos por diferentes componentes? Manejando esto, navegando al usuario al paso erróneo/restablecimiento de la tienda/etc. es complejo. Es por eso que sugiero enviar valores en cada paso, porque cada paso sucesivo puede confiar en los valores enviados como válidos.

está bien. Eso está bien, siempre que la consola pueda manejar dispositivos que están en ER pero que no se pueden encontrar en JS/NS/AS porque ese paso falló o el usuario cerró la pestaña o algo así.

Estoy en contra de permitir que los usuarios editen datos en el asistente (para los pasos que resultan en el envío). Mb, solo campos opcionales que se almacenan en un solo componente (y ningún otro componente los necesita), digamos name , description . De lo contrario, manejar esto se vuelve bastante complicado.

¿Qué quieres decir?

Tenga en cuenta que AS, por ejemplo, no necesita ningún campo, solo necesita que el dispositivo exista. Entonces, si el AS está allí, incluso si el usuario no ingresa ningún valor para AS, aún debe crear un dispositivo (vacío) en AS.

¿Qué quieres decir?

Lo siento. Esto fue hacia la sugerencia de @kschiffer :

Del mismo modo, ir al paso anterior debe poner el formulario en "modo de actualización" (debería ser relativamente fácil ya que los puntos finales son los mismos, excepto IS)

Avanzar y retroceder en el asistente y cerrar la ventana del navegador no debería generar dispositivos a medio crear.

Lo consideraría como una mejora futura. Por ahora, solo podemos mostrar una notificación al usuario sobre el flujo incompleto. Posteriormente, el usuario puede editar/eliminar el dispositivo en la página de configuración general.

Bueno, estamos abiertos a soluciones alternativas. ¿Alguna proposición?

Bueno, creo que dado lo _extremo-casiness_ de esta situación en particular, está bien vivir con este problema. Su redacción sugiere que no debo expresar preocupaciones sin soluciones propuestas, pero me gusta dar a otros la oportunidad de presentar algunas si no puedo encontrar ninguna de inmediato.

Estoy en contra de permitir que los usuarios editen datos en el asistente (para los pasos que resultan en el envío). Mb, solo campos opcionales que se almacenan en un solo componente (y ningún otro componente los necesita), digamos name , description . De lo contrario, manejar esto se vuelve bastante complicado.

Esto volvería a romper con las mejores prácticas para el patrón de asistente. Es probable que los usuarios deseen revisar o simplemente inspeccionar campos anteriores, especialmente dado que estos son interdependientes. Estoy de acuerdo con no incluir esta funcionalidad inicialmente, pero debería agregarse eventualmente (como en: seguimiento de un problema).

De lo contrario, manejar esto se vuelve bastante complicado.

En términos generales, la necesidad de implementar una lógica frontend compleja no debería afectar nuestro compromiso con UX.

Lo consideraría como una mejora futura. Por ahora, solo podemos mostrar una notificación al usuario sobre el flujo incompleto. Posteriormente, el usuario puede editar/eliminar el dispositivo en la página de configuración general.

No es óptimo, pero aceptable para mí, siempre que lo mejoremos eventualmente.

Como se discutió fuera de línea, aquí está la propuesta inicial;

Crear dispositivo

1. Configuración general
   
   
   
   • Campos
     
     
     
     
     
     • ids
     
     
     
     • Opcional name
     
     
     
     • Opcional description
     
     
     
     • Opcional attributes
     
     
     
     • Modo de activación requerido: OTAA, ABP o Multicast
     
     
     
     • Si NS en el clúster
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • Este paso crea el dispositivo solo en IS. Así sabemos que los identificadores son libres.
   
   
   • El modo de activación se utiliza en el estado de sesión
   
   
   • Si no está NS en el clúster, para simplificar el asistente, puede usar las versiones más conocidas (es decir, ahora 1.1.0 y 1.1.0-A respectivamente) en el estado de la sesión
   
   

2. Configuración de LoRaWAN

   • Si NS en clúster: Campos
     
     
     
     • lorawan_version (requerido)
     
     
     • lorawan_phy_version (requerido)
     
     
     • supports_join establecido si el modo de activación es OTAA (obligatorio)
     
     
     • multicast establecido si el modo de activación es multidifusión
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (requerido)
     
     
     • 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
     
     
   • Si NS en clúster: Campos si el modo de activación es OTAA
     
     
     
     • Casilla de verificación para usar JS externo (marcado por defecto)
     
     
   • Campos si el modo de activación es ABP o Multicast
     
     
     
     • Si NS o AS en clúster: session.dev_addr
     
     
     • Si NS o AS en clúster: generar un session.keys.session_key_id
     
     
     • Si NS en clúster: session.keys.f_nwk_s_int_key.key - requerido
     
     
     • Si NS en clúster: session.keys.s_nwk_s_int_key.key (si LW >= 1.1.0) - requerido
     
     
     • Si NS en clúster: session.keys.nwk_s_enc_key.key (si LW >= 1.1.0) - requerido
     
     
     • Si AS en clúster: session.keys.app_s_key.key - requerido
     
     
     • Si NS en clúster: session.last_conf_f_cnt_down
     
     
     • Si NS en clúster: session.last_n_f_cnt_down
     
     
   • Si NS en clúster: Campos si el modo de activación es ABP
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • Si NS o AS en clúster: Campos si el modo de activación es ABP
     
     
     
     • session.last_f_cnt_up - esto es necesario por seguridad
     
     

   • Si NS en clúster: Campos si el modo de activación es ABP u 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

   • Esto configura el dispositivo en NS y AS (si está en un clúster). Si tenemos un dispositivo OTAA, no tenemos nada que configurar en AS en este momento, pero aun así haría un llamado a la coherencia.

3. Si AS en clúster: configuración de la aplicación
   
   
   
   • Campos
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • Esto establece el dispositivo en AS
   
   
4. Si JS en clúster y si OTAA y si no usa JS externo: configuración de seguridad
   
   
   
   • Campos
     
     
     
     
     
     • Genera root_keys.root_key_id
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (si LW >= 1.1.0)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • Esto configura el dispositivo en JS
   
   

Actualizar dispositivo

Aquí, optaría por un enfoque con pestañas, básicamente con los pasos del asistente como pestañas.

La clave aquí es eso;

• ids , supports_join , multicast son de solo lectura
• El modo de activación se evalúa en este orden:
  
  
  
  • OTAA: si no hay NS en el clúster, o si NS en el clúster y NS dice supports_join
  
  
  • ABP: necesita NS en el clúster (y solo es relevante en ese caso): !supports_join && !multicast
  
  
  • Multidifusión: necesita NS en el clúster (y solo es relevante en ese caso): !supports_join && multicast (aunque multicast debería ser suficiente)
  
  

Algunos casos de uso para apoyar en la actualización de dispositivos:

• La consola puede tener NS, AS y JS en el clúster, pero es posible que el dispositivo no esté en NS, AS o JS (la consola obtiene 404). Este es un caso válido y la consola debería manejarlo. Un caso de ejemplo es un dispositivo reclamado, que tiene el dispositivo configurado en ER y JS, pero no (todavía) en NS y AS
• Sobre la base de lo anterior: establezca la configuración de LoRaWAN y la aplicación de un dispositivo que solo esté en ER y JS (es decir, configúrelo en NS y AS)
• Cambiando lorawan_version y lorawan_phy_version (esto cambia las restricciones)
• Cambiando la opción "JS externo"; es decir, supongamos que tiene un dispositivo existente pero desea configurar claves raíz en el clúster-JS. Luego, desmarque esta casilla de verificación y el usuario debería poder configurar las claves raíz en la pestaña Configuración de seguridad
• A través de la importación masiva, el dispositivo puede crearse en JS y tener claves raíz, pero no están expuestas. Al igual que hoy, el usuario debería poder ver que las claves raíz están ahí ( root_keys != nil ) pero no están expuestas ( root_keys.app_key == null etc.). El usuario debería poder dejar intactas las claves raíz.

cosas generales

• Para claves, un campo de entrada o un botón generar aleatorio
• La diferencia entre JS externo y claves raíz no expuestas;
  
  
  
  • JS externo es donde el JS no está en el mismo clúster que el NS. Esto permite crear un dispositivo OTAA pero no tener que ingresar a la configuración de Seguridad, ya que las claves se configuran en otro lugar
  
  
  • Las claves raíz no expuestas es donde se encuentra el dispositivo en el JS local del clúster, pero el JS no expone las claves raíz. Esto es por seguridad, es decir, en el caso de elementos seguros, donde JS tiene acceso a las claves raíz pero no las expone.
  
  

Creo que https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 ya contiene todo lo necesario para NS.
Creo que todos los mac_settings deberían estar disponibles para configurarse para todos los dispositivos que no sean de multidifusión.
Para dispositivos de multidifusión solo tiene sentido lo siguiente:

• "mac_settings.factory_preset_frequencies"
• "mac_settings.ping_slot_data_rate_index.value"
• "mac_settings.ping_slot_frequency"
• "mac_settings.ping_slot_periodicidad.valor"
• "mac_settings.rx2_data_rate_index.valor"
• "mac_settings.rx2_frecuencia"

Tal vez algunas cosas para aclarar

Crear:

1. Configuración general
   un. Cuando creamos el dispositivo en la sala de emergencias, no configuramos las direcciones NS/AS/JS. ¿Actualizamos el registro de ER cuando el dispositivo está configurado en esos? ¿Qué pasa si estamos usando un JS externo?
   B. ¿Almacenamos el modo de activación en Urgencias?
   C. ¿Almacenamos las versiones phy/mac en la sala de emergencias?
2. Configuración de LoRaWAN
   un. ¿Qué tal supports_class_b ?
3. Configuraciones de la aplicación
   un. Sí, esto podría significar que configuramos el dispositivo en el AS dos veces

Actualizar:

• Modo de activación: sería mucho más fácil si almacenamos esto en ER
• ¿Solo miramos los 404 o también las direcciones NS/AS/JS en la sala de emergencias?
• Creo que sería bueno poder eliminar un registro NS/AS/JS individual, por ejemplo, al cambiar "JS externo" a true , o restablecer el estado del dispositivo en el NS

Cosas generales:

• _"JS externo es donde el JS no está en el mismo clúster que el NS"_: creo que esto debería ser algo así como "join_server_address no es lo mismo que la dirección JS en la configuración de la consola"

Si estamos hablando de campos de nivel superior:
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 todo este fragmento pertenece a NS (pero no todos son necesarios)

m{in,ax}_frequency no se aplica a la multidifusión

@rvolosatovs

Creo que #579 (comentario) ya contiene todo lo necesario para NS.

Creo que todos los mac_settings deberían estar disponibles para configurarse para todos los dispositivos que no sean de multidifusión.
Para dispositivos de multidifusión solo tiene sentido lo siguiente:

Uno de los problemas de este problema es la cantidad de información oculta en los comentarios.

¿Puede agregar _exactamente_ los campos en los lugares correctos? Estoy bien si copia mi lista completa de viñetas para que trabajemos gradualmente en eso hasta que tengamos una versión final.

@htdvisser

1. Configuración general
   un. Cuando creamos el dispositivo en la sala de emergencias, no configuramos las direcciones NS/AS/JS. ¿Actualizamos el registro de ER cuando el dispositivo está configurado en esos? ¿Qué pasa si estamos usando un JS externo?

Creo que deberíamos actualizar las direcciones cuando configuramos los dispositivos en AS/NS/JS.

B. ¿Almacenamos el modo de activación en Urgencias?

No, no tenemos un campo para eso en este momento, realmente no lo necesitamos y crea espacio para inconsistencias.

C. ¿Almacenamos las versiones phy/mac en la sala de emergencias?

No, consulte la documentación de la API. Nuevamente, no veo la necesidad y crea espacio para inconsistencias.

un. ¿Qué tal supports_class_b ?

Sí, supongo que deberíamos agregar eso, pendiente #19. @rvolosatovs , incluya esto en una versión actualizada si es relevante.

1. Configuraciones de la aplicación
   un. Sí, esto podría significar que configuramos el dispositivo en el AS dos veces

si, eso no duele

Actualizar:

• Modo de activación: sería mucho más fácil si almacenamos esto en ER

Sí, pero no estoy seguro de si deberíamos optar por la facilidad y si eso se aplica completamente. Necesitamos tenerlo disponible en la ruta activa.

Además, solo sería fácil si pudiéramos empezar desde cero. Sin embargo, debemos ser compatibles con versiones anteriores, agregando heurísticas cuando lorawan_version no está en ER, introduciendo obtenciones condicionales de NS, etc.

• ¿Solo miramos los 404 o también las direcciones NS/AS/JS en la sala de emergencias?

Solo podemos obtener un 404 si hay una dirección establecida, de lo contrario no hay nada que obtener. Deberíamos interpretar ambos como "no en ese registro". No podemos cometer errores aquí (como lo hicimos antes), exactamente porque la creación en IS y AS/NS/JS no ocurre al mismo tiempo, y los usuarios deberían poder recuperar las inconsistencias creadas por la Consola.

• Creo que sería bueno poder eliminar un registro NS/AS/JS individual, por ejemplo, al cambiar "JS externo" a true , o restablecer el estado del dispositivo en el NS

Sí, hagámoslo más tarde.

• _"JS externo es donde el JS no está en el mismo clúster que el NS"_: creo que esto debería ser algo así como "join_server_address no es lo mismo que la dirección JS en la configuración de la consola"

Sí, esa es de hecho la forma de comprobarlo. join_server_address también puede estar vacío, usando interoperabilidad.

@bafonins , ¿todavía tienes la fuente del gráfico?
Dado que ya se ha trabajado mucho en la construcción de eso, creo que deberíamos actualizarlo para completarlo y tener una representación clara.
También podemos trabajar en la actualización de la parte NS fuera de línea para no saturar la discusión aquí.

Actualicé el gráfico con todos los campos NS posibles
Los campos en rojo son obligatorios

@rvolosatovs nuestro objetivo es definir el flujo y los campos que presentamos en la Consola al crear y actualizar dispositivos.

Como tal,

• No deberíamos permitir cambiar mac_state.lorawan_version
• Podemos hacer mac_state.ping_slot_periodicity a través de CLI por ahora
• Piense en cómo el usuario establecerá supports_class_b , supports_class_c y mac_state.device_class ; cuál es parte de crear, cuál es parte de actualizar, ¿cómo se relacionan entre sí?
• No deberíamos estar cambiando contadores individuales; haría un botón de "restablecer contadores de fotogramas" (que afaik puede ser una acción separada, como la que tenemos en la consola V2, que está configurando los contadores en 0 )
• Debemos seleccionar cuidadosamente qué configuraciones queremos en la Consola de mac_settings y mac_state.desired_parameters ; @htdvisser , ¿puedes pensar aquí?

Cambié el orden en https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858. Trabaje gradualmente en esa lista.

¿Puede agregar exactamente los campos en los lugares correctos?

Respondí esta pregunta, es decir, presenté todos los campos que se pueden configurar y deben configurarse en NS. O al menos así entendí tu pregunta.

Con respecto a lo que debería estar en la consola, todo mac_state probablemente solo debería configurarse a través de CLI, sin embargo, es posible que lo requieramos para dispositivos ABP/multidifusión y/o dispositivos OTAA, que se están registrando con una sesión existente, y, por lo tanto, estado MAC.
Actualizaré tu comentario.

No deberíamos estar cambiando contadores individuales; haría un botón de "restablecer contadores de fotogramas" (que afaik puede ser una acción separada, como la que tenemos en la consola V2, que está configurando los contadores en 0)

Necesitamos poder configurar contadores de tramas de enlace descendente para ABP y multidifusión; de lo contrario, NS no puede enviar enlaces descendentes.
Los contadores de tramas de enlace ascendente también son muy útiles desde el punto de vista de la seguridad para ABP.

Actualizar dispositivo

Aquí, optaría por un enfoque con pestañas, básicamente con los pasos del asistente como pestañas.

Usemos el enfoque de acordeón aquí, como se presenta en el primer comentario de @bafonins :

Nos dará menos problemas con el espacio horizontal, y permite distinguir modos con botones Edit / Create .

@rvolosatovs

Necesitamos poder configurar contadores de tramas de enlace descendente para ABP y multidifusión; de lo contrario, NS no puede enviar enlaces descendentes.
Los contadores de tramas de enlace ascendente también son muy útiles desde el punto de vista de la seguridad para ABP.

Si esto es simple, podemos hacerlo. De hecho, dos o tres cuadros de entrada pueden ser más simples que un botón de reinicio que desencadena una acción específica.

Con respecto a lo que debería estar en la consola, todo mac_state probablemente solo debería configurarse a través de CLI, sin embargo, es posible que lo requieramos para dispositivos ABP/multidifusión y/o dispositivos OTAA, que se están registrando con una sesión existente, y, por lo tanto, estado MAC.

Entiendo. Creo que deberíamos separar los "dispositivos de PAA nuevos y reiniciados" de los "dispositivos de PAA existentes que ya han estado en una red".

El primero debe estar completo, por lo que debe incluir algo mac_state (es decir, frecuencias de restablecimiento de fábrica, retraso de RX1, configuración de RX2, etc.) pero no mac_state.desired_parameters .

Esto último debe hacerse a través de la migración y podemos agregar la configuración de ajuste fino más adelante en la Consola; por ahora se debe usar CLI.

gracias por actualizar

Configuración de LoRaWAN

• Si NS en clúster: Campos
  
  
  
  • 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
  
  

¿Son necesarios para OTAA? ¿No es esto solo para ABP y Multicast?

@johanstokking

Configuración de LoRaWAN

• Si NS en clúster: Campos
  
  
  
  • 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
  
  

¿Son necesarios para OTAA? ¿No es esto solo para ABP y Multicast?

Todas las configuraciones MAC son opcionales por diseño.
El único caso en el que estos son "requeridos" son los dispositivos de multidifusión de clase B, que se debe a las especificaciones de operación de clase B.
Aparte de eso, es probable que se requiera factory_preset_frequencies para ABP para obtener los mejores resultados, pero nada impide que el dispositivo OTAA tenga ese conjunto.

Todas las configuraciones MAC son opcionales por diseño.
El único caso en el que estos son "requeridos" son los dispositivos de multidifusión de clase B, que se debe a las especificaciones de operación de clase B.

OK

Aparte de eso, es probable que se requiera factory_preset_frequencies para ABP para obtener los mejores resultados, pero nada impide que el dispositivo OTAA tenga ese conjunto.

Es ineficaz para OTAA; las frecuencias de unión predeterminadas son requeridas por especificación, y los canales entran a través de comandos de aceptación de unión y MAC. No debe haber una configuración fuera de banda de frecuencias preestablecidas para dispositivos OTAA.

@bafonins , ¿puede proporcionar una actualización de estado y un cronograma sobre este problema?

Para app_s_key y skip_payload_crypto , aquí está la cosa;

• AS respeta el campo skip_payload_crypto del dispositivo final. Si true , AS no realiza el cifrado y descifrado de la carga útil
  
  
  
  • AS también obtendrá skip_payload_crypto en el nivel de la aplicación (a través de Link, como formateadores de carga útil), que tiene prioridad sobre la configuración del dispositivo final
  
  
• Probablemente siempre haya un app_s_key en AS, pero puede estar envuelto, es decir, session.keys.app_s_key.key no está configurado (pero encrypted_key y kek_label están configurados)
  
  
  
  • Cuando AS no tiene la KEK, es decir, no puede desenvolver la clave cifrada. Ahora, esos errores. Probablemente devolveremos los app_s_key encriptados tal como están a los clientes
  
  
• En la consola, si skip_payload_crypto está configurado true (en el dispositivo final o en el enlace de la aplicación), no se moleste con app_s_key : desactívelo, no importa