Lorawan-stack: Use um assistente para criar dispositivos finais

O principal problema com a implementação atual da forma do dispositivo é que tudo está acoplado. Isso faz com que

1. Esquema de validação complexo e longo
2. Nenhuma maneira direta de desabilitar determinados campos com base na configuração da pilha
3. Nenhuma maneira direta de alterar os campos de formulário/títulos de campo de acordo com os valores selecionados
4. Complexidade desnecessária no js sdk para criação/atualização/exclusão em lote, bem como lógica de reversão de criação

Proponho implementar o formulário do dispositivo como o formulário de várias etapas. Isso pode ser algo assim:

Essa abordagem aborda todas as questões mencionadas acima:

1. Em vez de um esquema complexo, definimos um pequeno para cada etapa.
2. Simplesmente desabilite toda a etapa se um determinado componente responsável não estiver disponível na pilha. Além disso, podemos informar o usuário sobre isso por meio de descrição/notificação.
3. Adapte cada etapa dependendo dos valores enviados anteriormente. Por exemplo, altere o rótulo Join EUI para App EUI para a versão lorawan 1.0.x .
4. Não há necessidade de solicitações em lote. O usuário torna-se responsável pela criação do dispositivo em diferentes componentes. No entanto, podemos querer manter a exclusão em lote por conveniência.

Os dispositivos de edição podem ser implementados como uma pilha de acordeões:

Onde cada acordeão se expande com uma forma autônoma.

Além do formulário do dispositivo, podemos usar o assistente para o formulário de inscrição também para:

1. Crie o aplicativo no is
2. Vincule o aplicativo a como

cc @kschiffer @johanstokking @htdvisser

Parece bom para mim, especialmente se pudermos agrupar campos para componentes em uma etapa. Dessa forma, podemos simplesmente pular/desabilitar etapas quando um componente não estiver disponível.

Referenciando https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 também; mesmo que JS esteja disponível, o usuário pode pular os campos JS.

Eu vim com esse diagrama:

Cada nó é um passo

• As etapas com contorno pontilhado não enviam o formulário, mas o mantêm no estado local para as próximas etapas.
• Outros enviam solicitações ao servidor na submissão.

Parece complicado, mas a implementação atual tem um espaço de estado ainda maior em relação à validação/submissão/geração de máscara de campo/etc.

Considere o diagrama como uma proposta inicial para iniciar a discussão.

Acho que isso é um bom começo.

• Talvez o fluxo fosse melhor se o Join Server viesse primeiro.
• Uma coisa importante que ainda não fizemos nenhum progresso é o pré-preenchimento de campos de modelos de dispositivos no repositório de dispositivos #263. Acho que isso poderia realmente simplificar o processo para implantações de produção.

E algumas pequenas coisas:

• Um DevEUI não é proibido para dispositivos ABP (pode ser definido opcionalmente)
• Os dispositivos LoRaWAN 1.0.x não possuem NwkKey , apenas AppKey
• FNwkSIntKey chama-se NwkSKey (para o usuário)
• O servidor de aplicativos não obtém o NwkKey ou AppKey

Sim, ótimo começo.

• Talvez o fluxo fosse melhor se o Join Server viesse primeiro.

Eu concordo com isto. Se o modo de ativação for OTAA e o cluster JS estiver ativado, na página JS os usuários terão a opção de inserir chaves raiz e armazená-las no cluster JS. (se eles desabilitarem isso, o NS usa a pesquisa JS, assim como quando não há JS no cluster habilitado)

• O "modo de ativação" está em carga útil - no seu diagrama corresponde a 2 campos - multicast bool e supports_join bool . Existem 3 opções possíveis, pois multicast && supports_join não é válido.
• frequency_plan -> frequency_plan_id

• resets_f_cnt é opcional, false por padrão.

• FNwkSIntKey deve ser apresentado como NwkKey apenas para <1.1

• FNwkSIntKey está faltando nas configurações ABP NS para >= 1.1
• Dispositivos multicast só precisam AppSKey - o NS não precisa de nenhuma chave para que os dispositivos multicast funcionem, apenas AS

@htdvisser

Talvez o fluxo fosse melhor se o Join Server viesse primeiro.

Por quê?

Uma coisa importante que ainda não fizemos nenhum progresso é o pré-preenchimento de campos de modelos de dispositivos no repositório de dispositivos #263. Acho que isso poderia realmente simplificar o processo para implantações de produção.

Para mim, parece fora do escopo desta questão

Um DevEUI não é proibido para dispositivos ABP (pode ser definido opcionalmente)

Queremos configurá-lo para dispositivos ABP também? Eu diria que quanto menos campos tivermos, melhor. No entanto, é necessário que possamos adicioná-lo.

FNwkSIntKey é chamado NwkSKey (para o usuário)

Portanto, o rótulo deve ser NwkSKey para 1.0.xe 1.1.x ? Aqui está o que temos atm no console:

• Os dispositivos LoRaWAN 1.0.x não possuem uma NwkKey, apenas uma AppKey
• O servidor de aplicativos não obtém a NwkKey ou AppKey

Corrigido 👌

@johanstokking

Se o modo de ativação for OTAA e o cluster JS estiver ativado, na página JS os usuários terão a opção de inserir chaves raiz e armazená-las no cluster JS. (se eles desabilitarem isso, o NS usa a pesquisa JS, assim como quando não há JS no cluster habilitado).

Então, isso é apenas uma questão de permitir que os usuários ignorem a etapa de envio do servidor de ingresso? Nenhum pedido para js?

Em relação a https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 , você também poderia especificar onde esses campos pertencem no diagrama?

@rvolosatovs

Modo de ativação" está em carga útil - em seu diagrama corresponde a 2 campos na verdade - multicast bool e support_join bool. Existem 3 opções possíveis, pois multicast && support_join não é válido.

Só para esclarecer:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - multicast
   Isso está correto?

resets_f_cnt é opcional, false por padrão.

Eu acho que ainda é bom mostrá-lo aos usuários. Deve permitir que os usuários o configurem para dispositivos multicast?

FNwkSIntKey deve ser apresentado como NwkKey apenas para <1.1

Você quer dizer NwkSKey ?

plano_frequência -> plano_frequência_id
FNwkSIntKey está ausente nas configurações de ABP NS para >= 1.1

Corrigido 👌

Diagrama atualizado:

@htdvisser

Talvez o fluxo fosse melhor se o Join Server viesse primeiro.

Por quê?

Sim, estou voltando sobre isso; Acho que faz mais sentido inserir versões MAC antes de inserir chaves. Então estou apoiando o fluxo atual. Se a versão MAC for inserida (quando o NS estiver habilitado), não precisamos pedir NwkKey já que é 1.1.x.

Uma coisa importante que ainda não fizemos nenhum progresso é o pré-preenchimento de campos de modelos de dispositivos no repositório de dispositivos #263. Acho que isso poderia realmente simplificar o processo para implantações de produção.

Para mim, parece fora do escopo desta questão

Está fora do escopo mesmo.

Um DevEUI não é proibido para dispositivos ABP (pode ser definido opcionalmente)

Queremos configurá-lo para dispositivos ABP também? Eu diria que quanto menos campos tivermos, melhor. No entanto, é necessário que possamos adicioná-lo.

Sim, queremos pedir opcionalmente. Quanto mais informações de identificação tivermos sobre os dispositivos finais, melhor. Também é necessário em roaming passivo com estado. A razão pela qual não forçamos os usuários a inserir o DevEUI é porque, se não houver DevEUI, não queremos que os usuários insiram valores falsos.

FNwkSIntKey é chamado NwkSKey (para o usuário)

Portanto, o rótulo deve ser NwkSKey para 1.0.xe 1.1.x ? Aqui está o que temos atm no console:

É NwkSKey para 1.0.xe FNwkSIntKey para 1.1.x.

Se o modo de ativação for OTAA e o cluster JS estiver ativado, na página JS os usuários terão a opção de inserir chaves raiz e armazená-las no cluster JS. (se eles desabilitarem isso, o NS usa a pesquisa JS, assim como quando não há JS no cluster habilitado).

Então, isso é apenas uma questão de permitir que os usuários ignorem a etapa de envio do servidor de ingresso? Nenhum pedido para js?

De fato.

Um exemplo é um dispositivo com modem da Semtech que utiliza o Semtech Join Server. Só precisamos conhecer EUIs nesse caso.

Em relação ao nº 1134, você também poderia especificar onde esses campos pertencem no diagrama?

Eles pertencem à etapa JS; esses campos para ir JS, se o JS estiver habilitado no cluster e se o usuário quiser provisionar os dispositivos no JS.

Esses campos são opcionais.

Só para esclarecer:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - multicast
   Isso está correto?

Estritamente:

1. OTA: supports_join
2. PA: !supports_join && !multicast
3. Multicast: multicast

Inválido é supports_join && multicast , mas isso é (ou deveria ser) validado em NS.

resets_f_cnt é opcional, false por padrão.

Eu acho que ainda é bom mostrá-lo aos usuários. Deve permitir que os usuários o configurem para dispositivos multicast?

Não, isso não é para multicast. resets_f_cnt refere-se a uplink, mas não há uplink em multicast.

FNwkSIntKey deve ser apresentado como NwkKey apenas para <1.1

Você quer dizer NwkSKey ?

Deve ser NwkSKey fato.

@bafonins , veja a resposta de @johanstokking .
Em relação a multicast - o endereço do dispositivo também é necessário

• Campos adicionados de https://github.com/TheThingsNetwork/lorawan-stack/issues/1134
• Adicionado DevEUI a dispositivos abp/multicast
• Adicionado Device Address a dispositivos multicast
  

Endereço do dispositivo ainda ausente nas configurações do servidor de rede do dispositivo multicast

Endereço do dispositivo ainda ausente nas configurações do servidor de rede do dispositivo multicast

Atualizado 👌

Multicast pode ser 1.0.xe 1.1.x. A inserção das informações da sessão ( DevAddr e chaves) é a mesma para multicast e ABP.

Também resets_join_nonces pode ser definido em JS com 1.1.x

A divisão da criação do dispositivo é definitivamente necessária e uma boa maneira de aproximar o fluxo e a implementação dos requisitos do back-end, reduzindo a complexidade para o usuário.

Alguns pensamentos e desafios que vejo:

• Devemos adicionar funcionalidade para abortar todo o fluxo, resultando na exclusão de quaisquer entradas de registro que já tenham sido criadas.
  
  
  
  • Da mesma forma, ir para a etapa anterior precisa colocar o formulário em "modo de atualização" (deve ser relativamente fácil, pois os endpoints são os mesmos, exceto o IS)
  
  
• Um problema que vejo é que a etapa do Application Server é muito superficial (isso provavelmente mudará mais tarde?)
  
  
  
  • Uma solução pode ser mesclar a etapa AS e JS, já que ambas são bastante diretas e não interdependentes. Eu percebo que isso vai contra a separação por componente, mas acho que isso simplificaria todo o fluxo com uma abstração razoável. Especialmente porque não comunicamos nenhuma conexão com os respectivos componentes da pilha nas etapas.
  
  
• Dependendo da configuração da pilha, podemos acabar com um assistente que tem apenas uma ou duas etapas, que é um antipadrão para assistentes.
  
  
  
  • Para o caso de apenas uma etapa, podemos simplesmente ocultar/remover o aspecto do assistente
  
  
  • Para dois passos, acho que temos que conviver com o problema 🤷‍♂
  
  
• Deve-se considerar que a solução do assistente aumentará bastante o _time-to-complete_ para a história do usuário
  
  
  
  • Isso pode se tornar um problema em situações em que muitos dispositivos precisam ser criados manualmente, embora apresentemos recursos de criação em lote para este caso de uso e a CLI/script também possa ajudar nessas situações
  
  
  • Ainda assim, considere a diferença com a criação do dispositivo do console V2 e como os usuários podem perceber essa mudança
  
  
• Eu gosto da solução "edição segmentada" correspondente para configurações gerais
• O fluxograma é muito útil e devemos mantê-lo atualizado 👍

Complexidade desnecessária no js sdk para criação/atualização/exclusão em lote, bem como lógica de reversão de criação

Acho que a funcionalidade do SDK para dividir e mesclar solicitações de dispositivos ainda é bastante valiosa, mesmo que não a usemos nesse caso

@johanstokking para dispositivos multicast NS só precisa de SNwkSIntKey em 1.1 para cálculo de MIC. FNwkSIntKey e NwkSEncKey , na verdade, não devem ter permissão para definir IMO.

• Devemos adicionar funcionalidade para abortar todo o fluxo, resultando na exclusão de quaisquer entradas de registro que já tenham sido criadas.
  
  
  
  • Da mesma forma, ir para a etapa anterior precisa colocar o formulário em "modo de atualização" (deve ser relativamente fácil, pois os endpoints são os mesmos, exceto o IS)
  
  

Eu não acho que deveríamos estar criando nada antes de clicar em Finish ou algo assim. Ir e voltar no assistente e fechar a janela do navegador não deve resultar em dispositivos semi-criados.

• Um problema que vejo é que a etapa do Application Server é muito superficial (isso provavelmente mudará mais tarde?)

Adicionaremos a configuração para os pacotes de aplicativos aqui (ou seja, configuração multicast remota, transferência de blocos de dados fragmentados, opções de modem Semtech, etc). Então, sim, é superficial agora, mas será estendido.

• Uma solução pode ser mesclar a etapa AS e JS, já que ambas são bastante diretas e não interdependentes. Eu percebo que isso vai contra a separação por componente, mas acho que isso simplificaria todo o fluxo com uma abstração razoável. Especialmente porque não comunicamos nenhuma conexão com os respectivos componentes da pilha nas etapas.

Para o nosso futuro eu recomendaria mantê-los separados. Além disso, combiná-los torna a renderização dessas páginas condicionada à disponibilidade do componente, o que adiciona complexidade a um fluxo já complexo.

• Dependendo da configuração da pilha, podemos acabar com um assistente que tem apenas uma ou duas etapas, que é um antipadrão para assistentes.

  • Para o caso de apenas uma etapa, podemos simplesmente ocultar/remover o aspecto do assistente
  • Para dois passos, acho que temos que conviver com o problema 🤷‍♂

• Deve-se considerar que a solução do assistente aumentará bastante o _time-to-complete_ para a história do usuário

  • Isso pode se tornar um problema em situações em que muitos dispositivos precisam ser criados manualmente, embora apresentemos recursos de criação em lote para este caso de uso e a CLI/script também possa ajudar nessas situações
  • Ainda assim, considere a diferença com a criação do dispositivo do console V2 e como os usuários podem perceber essa mudança

A separação de componentes e os cenários de implantação flexíveis são uma das principais mudanças em comparação com a V2, portanto, faz todo o sentido que isso seja efetivo no Console V3.

De fato, para criar grandes quantidades de dispositivos, as pessoas devem usar APIs e CLI de qualquer maneira.

Não existe cenário com um passo, são sempre pelo menos dois passos.

Que tal renderizar guias em vez de páginas? Dessa forma, ainda é uma página, mas as coisas são facilmente acessíveis sem ir e voltar em etapas.

@johanstokking

Eu não acho que deveríamos estar criando nada antes de clicar em Finish ou algo assim.

Se fizermos a solicitação real apenas na última etapa, isso significa que faríamos 3-4 solicitações. Como lidamos com erros retornados por diferentes componentes? Lidando com isso, navegando o usuário para a etapa/redefinição de armazenamento com erro/etc. é complexo. É por isso que sugiro enviar valores em todas as etapas, pois todas as etapas sucessivas podem contar com valores enviados como válidos.

Ir e voltar no assistente e fechar a janela do navegador não deve resultar em dispositivos semi-criados.

Sou contra permitir que os usuários editem dados no assistente (para as etapas que resultam no envio). Mb, apenas campos opcionais que são armazenados em um único componente (e nenhum outro componente precisa deles), digamos name , description . Caso contrário, lidar com isso se torna bastante complicado.

@kschiffer

Dependendo da configuração da pilha, podemos acabar com um assistente que tem apenas uma ou duas etapas, que é um antipadrão para assistentes.

Bem, estamos abertos a soluções alternativas. Alguma proposição?

Se fizermos a solicitação real apenas na última etapa, isso significa que faríamos 3-4 solicitações. Como lidamos com erros retornados por diferentes componentes? Lidando com isso, navegando o usuário para a etapa/redefinição de armazenamento com erro/etc. é complexo. É por isso que sugiro enviar valores em todas as etapas, pois todas as etapas sucessivas podem contar com valores enviados como válidos.

OK. Tudo bem, desde que o Console possa lidar com dispositivos que estão em ER, mas não podem ser encontrados em JS/NS/AS porque essa etapa falhou ou o usuário fechou a guia ou algo assim.

Sou contra permitir que os usuários editem dados no assistente (para as etapas que resultam no envio). Mb, apenas campos opcionais que são armazenados em um único componente (e nenhum outro componente precisa deles), digamos name , description . Caso contrário, lidar com isso se torna bastante complicado.

O que você quer dizer?

Observe que o AS, por exemplo, não precisa de nenhum campo, apenas precisa que o dispositivo exista. Portanto, se o AS estiver lá, mesmo que o usuário não insira nenhum valor para AS, ele ainda deve criar um dispositivo (vazio) no AS.

O que você quer dizer?

Desculpe. Isso foi para a sugestão do @kschiffer :

Da mesma forma, ir para a etapa anterior precisa colocar o formulário em "modo de atualização" (deve ser relativamente fácil, pois os endpoints são os mesmos, exceto o IS)

Ir e voltar no assistente e fechar a janela do navegador não deve resultar em dispositivos semi-criados.

Eu consideraria isso como uma melhoria futura. Por enquanto, podemos apenas mostrar uma notificação ao usuário sobre o fluxo incompleto. Posteriormente, o usuário pode editar/excluir o dispositivo na página de configurações gerais.

Bem, estamos abertos a soluções alternativas. Alguma proposição?

Bem, eu acho que dada a _edge-casiness_ desta situação em particular, está tudo bem viver com este problema. Sua redação sugere que eu não deveria expressar preocupações sem soluções propostas, mas gosto de dar aos outros a oportunidade de apresentar algumas se não conseguir encontrar imediatamente nenhuma.

Sou contra permitir que os usuários editem dados no assistente (para as etapas que resultam no envio). Mb, apenas campos opcionais que são armazenados em um único componente (e nenhum outro componente precisa deles), digamos name , description . Caso contrário, lidar com isso se torna bastante complicado.

Isso romperia novamente com as práticas recomendadas para o padrão de assistente. Os usuários provavelmente desejarão revisar ou simplesmente inspecionar campos anteriores, especialmente porque eles são interdependentes. Concordo em não incluir essa funcionalidade inicialmente, mas ela deve ser adicionada eventualmente (como em: monitorado em um problema).

Caso contrário, lidar com isso se torna bastante complicado.

De um modo geral, a necessidade de implementar uma lógica de frontend complexa não deve afetar nosso compromisso com o UX.

Eu consideraria isso como uma melhoria futura. Por enquanto, podemos apenas mostrar uma notificação ao usuário sobre o fluxo incompleto. Posteriormente, o usuário pode editar/excluir o dispositivo na página de configurações gerais.

Não é o ideal, mas é aceitável para mim, desde que melhoremos isso eventualmente.

Conforme discutido offline, aqui está a proposta inicial;

Criar dispositivo

1. Configurações Gerais
   
   
   
   • Campos
     
     
     
     
     
     • ids
     
     
     
     • Opcional name
     
     
     
     • Opcional description
     
     
     
     • Opcional attributes
     
     
     
     • Modo de ativação necessário: OTAA, ABP ou Multicast
     
     
     
     • Se NS no cluster
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • Esta etapa cria o dispositivo apenas em IS. Dessa forma, sabemos que os identificadores são gratuitos
   
   
   • O modo de ativação é usado no estado de sessão
   
   
   • Se não for NS no cluster, para simplificar no assistente, você pode usar as versões mais altas conhecidas (ou seja, agora 1.1.0 e 1.1.0-A respectivamente) no estado de sessão
   
   

2. Configurações LoRaWAN

   • Se NS no cluster: Campos
     
     
     
     • lorawan_version (obrigatório)
     
     
     • lorawan_phy_version (obrigatório)
     
     
     • supports_join definido se o modo de ativação for OTAA (obrigatório)
     
     
     • multicast definido se o modo de ativação for multicast
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (obrigatório)
     
     
     • 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
     
     
   • Se NS no cluster: Campos se o modo de ativação for OTAA
     
     
     
     • Caixa de seleção para usar JS externo (padrão marcado)
     
     
   • Campos se o modo de ativação for ABP ou Multicast
     
     
     
     • Se NS ou AS no cluster: session.dev_addr
     
     
     • Se NS ou AS no cluster: gere um session.keys.session_key_id
     
     
     • Se NS no cluster: session.keys.f_nwk_s_int_key.key - obrigatório
     
     
     • Se NS no cluster: session.keys.s_nwk_s_int_key.key (se LW >= 1.1.0) - obrigatório
     
     
     • Se NS no cluster: session.keys.nwk_s_enc_key.key (se LW >= 1.1.0) - obrigatório
     
     
     • Se AS no cluster: session.keys.app_s_key.key - obrigatório
     
     
     • Se NS no cluster: session.last_conf_f_cnt_down
     
     
     • Se NS no cluster: session.last_n_f_cnt_down
     
     
   • Se NS no cluster: Campos se o modo de ativação for ABP
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • Se NS ou AS no cluster: Campos se o modo de ativação for ABP
     
     
     
     • session.last_f_cnt_up - isso é necessário para segurança
     
     

   • Se NS no cluster: Campos se o modo de ativação for ABP ou 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

   • Isso configura o dispositivo em NS e AS (se estiver em cluster). Se tivermos um dispositivo OTAA, não temos nada para definir no AS neste momento, mas eu ainda pediria consistência

3. Se AS no cluster: configurações do aplicativo
   
   
   
   • Campos
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • Isso define o dispositivo em AS
   
   
4. Se JS no cluster e se OTAA e se não estiver usando JS externo: configurações de segurança
   
   
   
   • Campos
     
     
     
     
     
     • Gerar root_keys.root_key_id
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (se LW >= 1.1.0)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • Isso define o dispositivo em JS
   
   

Atualizar dispositivo

Aqui, eu usaria uma abordagem com guias, basicamente com etapas do assistente como guias.

A chave aqui é isso;

• ids , supports_join , multicast são somente leitura
• O modo de ativação é avaliado nesta ordem:
  
  
  
  • OTAA: se não houver NS no cluster, ou se o NS no cluster e o NS disserem supports_join
  
  
  • ABP: precisa de NS no cluster (e só é relevante nesse caso): !supports_join && !multicast
  
  
  • Multicast: precisa de NS no cluster (e só é relevante nesse caso): !supports_join && multicast (embora multicast deva ser suficiente)
  
  

Alguns casos de uso para suporte na atualização de dispositivos:

• O Console pode ter NS, AS e JS no cluster, mas o dispositivo pode não estar no NS, AS ou JS (o Console obtém 404). Este é um caso válido e o Console deve lidar com isso. Um caso de exemplo é um dispositivo reivindicado, que tem o dispositivo definido em ER e JS, mas não (ainda) em NS e AS
• Com base no anterior: defina as configurações do LoRaWAN e do aplicativo de um dispositivo que está apenas em ER e JS (ou seja, defina-o em NS e AS)
• Alterando lorawan_version e lorawan_phy_version (isso altera as restrições)
• Alterando a opção "JS externo"; ou seja, digamos que você tenha um dispositivo existente, mas deseja configurar chaves raiz no cluster-JS. Em seguida, desmarque esta caixa de seleção e o usuário poderá definir as chaves raiz na guia Configurações de segurança
• Por meio da importação em massa, o dispositivo pode ser criado em JS e ter chaves raiz, mas elas não são expostas. Como hoje, o usuário deve ser capaz de ver que as chaves raiz estão lá ( root_keys != nil ), mas não estão expostas ( root_keys.app_key == null etc). O usuário deve ser capaz de deixar as chaves raiz intactas

Coisas gerais

• Para chaves, um campo de entrada ou um botão gerar aleatório
• A diferença entre JS externo e chaves raiz não expostas;
  
  
  
  • JS externo é onde o JS não está no mesmo cluster que o NS. Isso permite criar um dispositivo OTAA, mas não precisa entrar nas configurações de segurança, pois as chaves são configuradas em outro lugar
  
  
  • As chaves raiz não expostas são onde o dispositivo está no JS local do cluster, mas o JS não expõe as chaves raiz. Isso é para segurança, ou seja, no caso de elementos seguros, onde JS tem acesso às chaves raiz, mas não as expõe
  
  

Acho que https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 já contém tudo o que é necessário para o NS.
Acho que todos os mac_settings devem estar disponíveis para serem configurados para todos os dispositivos não multicast.
Para dispositivos multicast, apenas o seguinte faz sentido:

• "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"

Talvez algumas coisas para esclarecer

Crio:

1. Configurações Gerais
   uma. Quando criamos o dispositivo no ER, não definimos os endereços NS/AS/JS. Atualizamos o registro de ER quando o dispositivo é definido neles? E se estivermos usando um JS externo?
   b. Armazenamos o modo de ativação no ER?
   c. Armazenamos as versões phy/mac no ER?
2. Configurações LoRaWAN
   uma. Que tal supports_class_b ?
3. Configurações do aplicativo
   uma. Sim, isso pode significar que configuramos o dispositivo no AS duas vezes

Atualizar:

• Modo de ativação: seria muito mais fácil se armazenássemos isso no ER
• Nós apenas olhamos para os endereços 404 ou também para os endereços NS/AS/JS no ER?
• Acho que seria bom poder excluir um registro NS/AS/JS individual, por exemplo, ao alterar "JS externo" para true ou redefinir o estado do dispositivo no NS

Coisas gerais:

• _"JS externo é onde o JS não está no mesmo cluster que o NS"_: Acho que isso deveria ser algo como "join_server_address não é o mesmo que o endereço JS na configuração do console"

Se estamos falando de campos de nível superior:
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 este pedaço inteiro pertence ao NS (mas nem todos são necessários)

m{in,ax}_frequency não se aplica a multicast

@rvolosatovs

Acho que #579 (comentário) já contém tudo o que é necessário para NS.

Acho que todos os mac_settings devem estar disponíveis para serem configurados para todos os dispositivos não multicast.
Para dispositivos multicast, apenas o seguinte faz sentido:

Um dos problemas com essa questão é a quantidade de informações escondidas nos comentários.

Você pode adicionar _exatamente_ os campos nos lugares certos? Tudo bem se você copiar toda a minha lista de marcadores, então trabalhamos gradualmente nisso até que tenhamos uma versão final.

@htdvisser

1. Configurações Gerais
   uma. Quando criamos o dispositivo no ER, não definimos os endereços NS/AS/JS. Atualizamos o registro de ER quando o dispositivo é definido neles? E se estivermos usando um JS externo?

Acho que devemos atualizar os endereços quando definirmos os dispositivos em AS/NS/JS.

b. Armazenamos o modo de ativação no ER?

Não, não temos campo para isso no momento, não precisamos muito e isso cria espaço para inconsistências.

c. Armazenamos as versões phy/mac no ER?

Não, consulte a documentação da API. Novamente, não vejo necessidade e isso cria espaço para inconsistências.

uma. Que tal supports_class_b ?

Sim, acho que devemos adicionar isso, pendente #19. @rvolosatovs inclua isso em uma versão atualizada, se relevante.

1. Configurações do aplicativo
   uma. Sim, isso pode significar que configuramos o dispositivo no AS duas vezes

Sim, isso não dói

Atualizar:

• Modo de ativação: seria muito mais fácil se armazenássemos isso no ER

Sim, mas não tenho certeza se devemos ir para a facilidade e se isso se aplica totalmente. Precisamos tê-lo disponível no caminho quente.

Além disso, só seria fácil se pudéssemos começar do zero. No entanto, precisamos ser compatíveis com versões anteriores, adicionando heurística quando lorawan_version não estiver em ER, introduzindo obtenções condicionais de NS etc.

• Nós apenas olhamos para os endereços 404 ou também para os endereços NS/AS/JS no ER?

Só podemos obter um 404 se houver um endereço definido, caso contrário, não há nada para obter. Devemos interpretar ambos como "não nesse registro". Não podemos errar aqui (como fizemos antes), exatamente pelo motivo de que a criação em IS e AS/NS/JS não acontece ao mesmo tempo, e os usuários devem conseguir recuperar inconsistências criadas pelo Console.

• Acho que seria bom poder excluir um registro NS/AS/JS individual, por exemplo, ao alterar "JS externo" para true ou redefinir o estado do dispositivo no NS

Sim, vamos fazer isso mais tarde

• _"JS externo é onde o JS não está no mesmo cluster que o NS"_: Acho que isso deveria ser algo como "join_server_address não é o mesmo que o endereço JS na configuração do console"

Sim, essa é realmente a maneira de verificar isso. join_server_address também pode estar vazio, usando interoperabilidade.

@bafonins você ainda tem a fonte do gráfico?
Já que muito trabalho foi feito para construir isso, acho que devemos apenas atualizá-lo para torná-lo completo para ter uma representação clara?
Também podemos trabalhar na atualização da parte NS offline para não atrapalhar a discussão aqui.

Atualizei o gráfico com todos os campos NS possíveis
Os campos em vermelho são obrigatórios

@rvolosatovs , nosso objetivo é definir o fluxo e os campos que estamos apresentando no Console ao criar e atualizar dispositivos.

Como tal,

• Não deveríamos permitir a alteração de mac_state.lorawan_version
• Podemos fazer mac_state.ping_slot_periodicity através do CLI por enquanto
• Por favor, pense em como o usuário irá definir supports_class_b , supports_class_c e mac_state.device_class ; que faz parte do create, que faz parte do update, como um se relaciona com o outro?
• Não devemos mudar contadores individuais; um botão "redefinir contadores de quadros" faria (que afaik pode ser uma ação separada, como temos no console V2, que é definir os contadores para 0 )
• Devemos selecionar cuidadosamente quais configurações queremos no Console de mac_settings e mac_state.desired_parameters ; @htdvisser você pode pensar junto aqui?

Alterei a ordem em https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858. Por favor, trabalhe de forma incremental nessa lista.

Você pode adicionar exatamente os campos nos lugares certos?

Eu respondi a esta pergunta - ou seja, apresentei todos os campos, que podem ser configurados e devem ser configurados no NS. Ou pelo menos foi assim que entendi sua pergunta.

Em relação ao que deve estar no console, tudo mac_state provavelmente só deve ser configurável através do CLI, no entanto, podemos exigir isso para dispositivos ABP/multicast e/ou dispositivos OTAA, que estão sendo registrados com uma sessão existente e, daí o estado MAC.
Vou atualizar seu comentário.

Não devemos mudar contadores individuais; um botão "redefinir contadores de quadros" faria (que afaik pode ser uma ação separada, como temos no console V2, que é definir os contadores para 0)

Precisamos ser capazes de definir contadores de quadros de downlink para ABP e multicast - caso contrário, o NS não poderá enviar downlinks
Para contadores de quadros de uplink também são muito úteis do ponto de vista de segurança para ABP

Atualizar dispositivo

Aqui, eu usaria uma abordagem com guias, basicamente com etapas do assistente como guias.

Vamos usar a abordagem de acordeão aqui, conforme apresentado no primeiro comentário de @bafonins :

Isso nos dará menos problemas com o espaço horizontal e permite distinguir modos com os botões Edit / Create .

@rvolosatovs

Precisamos ser capazes de definir contadores de quadros de downlink para ABP e multicast - caso contrário, o NS não poderá enviar downlinks
Para contadores de quadros de uplink também são muito úteis do ponto de vista de segurança para ABP

Se isso é simples, podemos fazê-lo. Na verdade, duas/três caixas de entrada podem ser mais simples do que um botão de reset que aciona uma ação específica.

Em relação ao que deve estar no console, tudo mac_state provavelmente só deve ser configurável através do CLI, no entanto, podemos exigir isso para dispositivos ABP/multicast e/ou dispositivos OTAA, que estão sendo registrados com uma sessão existente e, daí o estado MAC.

Eu entendo. Acho que devemos separar "dispositivos ABP novos e redefinidos" de "dispositivos ABP existentes que já estiveram em uma rede".

O primeiro deve estar completo, então deve incluir alguns mac_state (ou seja, frequências de redefinição de fábrica, atraso RX1, configurações RX2, etc.), mas não mac_state.desired_parameters .

O último deve ser feito via migração e podemos adicionar as configurações de ajuste fino posteriormente no Console; por enquanto CLI deve ser usado.

Obrigado por atualizar

Configurações LoRaWAN

• Se NS no cluster: 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
  
  

Estes são necessários para OTAA? Isso não é apenas para ABP e Multicast?

@johanstokking

Configurações LoRaWAN

• Se NS no cluster: 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
  
  

Estes são necessários para OTAA? Isso não é apenas para ABP e Multicast?

Todas as configurações de MAC são opcionais por design.
O único caso em que estes são "obrigatórios" são os dispositivos multicast de classe B, devido às especificidades da operação de classe B.
Além disso, é provável que factory_preset_frequencies seja necessário para o ABP para obter melhores resultados, mas nada impede que o dispositivo OTAA tenha esse conjunto.

Todas as configurações de MAC são opcionais por design.
O único caso em que estes são "obrigatórios" são os dispositivos multicast de classe B, devido às especificidades da operação de classe B.

OK

Além disso, é provável que factory_preset_frequencies seja necessário para o ABP para obter melhores resultados, mas nada impede que o dispositivo OTAA tenha esse conjunto.

É ineficaz para OTAA; as frequências de junção padrão são exigidas por especificação, e os canais entram por meio de comandos join-accept e MAC. Não deve haver configuração fora de banda de frequências predefinidas para dispositivos OTAA.

@bafonins você pode dar uma atualização de status e linha do tempo sobre este problema?

Para app_s_key e skip_payload_crypto , aqui está;

• AS respeita o campo skip_payload_crypto do dispositivo final. Se true , AS não executa criptografia e descriptografia de carga útil
  
  
  
  • O AS também receberá skip_payload_crypto no nível do aplicativo (via Link, como formatadores de carga útil), que tem precedência sobre a configuração do dispositivo final
  
  
• Provavelmente há sempre um app_s_key no AS, mas pode ser encapsulado, ou seja, session.keys.app_s_key.key não está definido (mas encrypted_key e kek_label estão definidos)
  
  
  
  • Quando o AS não possui a KEK, ou seja, não pode desempacotar a chave criptografada. Agora, esses erros. Provavelmente retornaremos o app_s_key criptografado como está para os clientes
  
  
• No Console, se skip_payload_crypto estiver definido true (no dispositivo final ou no link do aplicativo), não se preocupe com app_s_key : desative-o, não se importe