Lorawan-stack: Configuração da camada MAC do dispositivo no console

Criado em 25 fev. 2020  ·  9Comentários  ·  Fonte: TheThingsNetwork/lorawan-stack

Resumo

A camada MAC do dispositivo deve ser configurável a partir do console.
Substitui https://github.com/TheThingsNetwork/lorawan-stack/issues/1378

Por que nós precisamos disso?

  • Criação/atualização de dispositivos classe B a partir do console
  • Criação/atualização de dispositivos finais usando configurações de camada MAC não padrão (por exemplo, The Things Uno)

O que já existe? O que você vê agora?

CLI como o único meio de configurar a camada MAC do dispositivo

O que está faltando? O que você quer ver?

Suporte para configurar todos os campos MACSettings .

Lista de prioridade de campo
Alto

  • Todos os dispositivos

    • [x] rx2_data_rate_index
    • [x] rx2_frequency
    • [x] factory_preset_frequencies

  • Classe A específica (também conhecido como todos os dispositivos não multicast)

    • [x] rx1_delay
    • [x] rx1_data_rate_offset
    • [x] resets_f_cnt

  • Classe B específica

    • [x] ping_slot_periodicity
Médio

  • Classe A específica (também conhecido como todos os dispositivos não multicast)

    • [ ] max_duty_cycle
    • [x] supports_32_bit_f_cnt
    • [ ] use_adr
    • [ ] status_time_periodicity
    • [ ] status_count_periodicity

  • Classe B específica

    • [ ] ping_slot_data_rate_index
    • [x] ping_slot_frequency
    • [ ] beacon_frequency
Baixo

  • Classe A específica (também conhecido como todos os dispositivos não multicast)

    • [ ] adr_margin
    • [ ] desired_rx1_delay
    • [ ] desired_rx1_data_rate_offset
    • [ ] desired_rx2_data_rate_index
    • [ ] desired_rx2_frequency
    • [ ] desired_max_duty_cycle
    • [ ] desired_adr_ack_limit_exponent
    • [ ] desired_adr_ack_delay_exponent

  • Classe B específica

    • Não multicast

      • [ ] class_b_timeout

      • [ ] desired_ping_slot_data_rate_index

      • [ ] desired_ping_slot_frequency

      • [ ] desired_beacon_frequency

  • Classe C específica

    • Não multicast

      • [ ] class_c_timeout

NOTA: Alguns deles já podem ser configuráveis ​​(por exemplo, coisas do FCnt), atualize as caixas de seleção adequadamente e verifique se essas configurações estão nos locais corretos (ou seja, não está disponível para dispositivos multicast)

Acredito que as configurações específicas de classe B e C devem estar disponíveis para todos os dispositivos, mesmo para dispositivos para os quais o respectivo SupportsClass{B,C} é false . Desta forma os usuários podem (temporariamente) desabilitar/habilitar a operação classe B/C sempre que necessário e manter as configurações específicas.

As configurações específicas da classe A devem estar disponíveis apenas para dispositivos não multicast.

Como você se propõe a implementar isso?

Adicione todos os campos de MACSettings https://github.com/TheThingsNetwork/lorawan-stack/blob/74c9da9a9e07a31d7103eabcd3440f9c80c24ea1/api/end_device.proto#L190 -L284 como campos para a configuração da camada de rede. Esses campos devem ser sempre configuráveis, ou seja, tanto na criação quanto na atualização.

Use comentários do proto para descrição.

Você pode fazer isso sozinho e enviar um Pull Request?

@bafonins vai lidar com isso

console compaapi documentation uweb
Fonte
picture rvolosatovs

Todos 9 comentários

Eu terminei principalmente com os campos de alta prioridade para a configuração de configurações de MAC:


Capturas de tela
PA:

Screenshot 2020-03-29 at 17 41 50

classe B:

Screenshot 2020-03-29 at 17 44 00

OTAA:
Screenshot 2020-03-29 at 18 11 58

No entanto, para adicionar todos eles e permitir que os usuários registrem, por exemplo, The Things Uno via Console, o campo mac_state.factory_preset_frequencies está ausente. Não tenho certeza de como exatamente isso deve ser representado na interface do usuário, atualmente tenho essas ideias:

  1. Como seleção múltipla:
    Screenshot 2020-03-30 at 09 47 01

IMO, esse campo torna a seleção de frequências muito fácil. Além disso, podemos apresentar ao usuário frequências com base no frequency_plan_id para o dispositivo final. No entanto, como @rvolosatovs mencionou que as entradas podem ter valores arbitrários e não necessariamente dependem do plano de frequência do dispositivo final.

Além disso, para esta abordagem seria ótimo ter um RPC para buscar presets de frequências por banda.

  1. Como matriz de entradas numéricas (semelhante a como permitimos adicionar cabeçalhos a integrações de webhook):
    Screenshot 2020-03-30 at 11 06 13

Essa abordagem é mais flexível, porém, leva mais tempo para o usuário definir o campo, exige frequências de digitação.

  1. Como seleção múltipla com opções para criar novos rótulos:

freqqs

Basicamente, uma combinação de 1 e 2.

@rvolosatovs @johanstokking

bafonins picture bafonins em 30 mar. 2020

Acho que ter a lista (2) é mais claro, pois mostra a ordem. E a ordem é importante.

As frequências podem ser qualquer coisa, mas seria muito útil buscá-las por meio de um plano de frequência existente.

johanstokking picture johanstokking em 30 mar. 2020
👍1

Adicionando compat/api porque podemos precisar de um NS rpc para obter o plano de frequência.

johanstokking picture johanstokking em 30 mar. 2020

Acho que ter a lista (2) é mais claro, pois mostra a ordem. E a ordem é importante.

Ambos os componentes selecionados (1) e (2) também preservam a ordem.

As frequências podem realmente ser qualquer coisa,

Com (3) valores de frequência arbitrários também podem ser adicionados

bafonins picture bafonins em 30 mar. 2020

Eu acho que a solução (2) é a mais limpa também, enquanto (3) parece melhor para uma pequena quantidade de frequências, ter várias (por exemplo, 4 ou mais) parecerá confuso e difícil de acompanhar.
Seria ótimo se pudéssemos ter sugestões de frequência para (2) em cada caixa de texto (do RPC do plano de frequência proposto), então é mais ou menos o que você vê em (3), mas por caixa de texto

rvolosatovs picture rvolosatovs em 30 mar. 2020
👍1

Mais ou menos concluído com a implementação, mas deseja esperar que https://github.com/TheThingsNetwork/lorawan-stack/issues/2605 seja mesclado antes de fazer um PR para adicionar testes para o assistente do dispositivo (incluindo o manuseio das configurações do mac)

bafonins picture bafonins em 12 jul. 2020

Qual é o estado aqui?

johanstokking picture johanstokking em 3 nov. 2020

@johanstokking https://github.com/TheThingsNetwork/lorawan-stack/pull/3065 está pronto para revisão. Eu adicionei todos os campos de alta e alguns campos de prioridade média.

bafonins picture bafonins em 3 nov. 2020
👍1

Mudando o marco desta edição sem próxima. Todos os campos de alta prioridade, juntamente com alguns campos de prioridade média, foram adicionados em https://github.com/TheThingsNetwork/lorawan-stack/pull/3065. Voltaremos a isso mais tarde se quaisquer outros campos forem adicionados ao console.

bafonins picture bafonins em 21 dez. 2020
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

thinkOfaNumber picture thinkOfaNumber  ·  4Comentários
ZeroSum24 picture ZeroSum24  ·  3Comentários
w4tsn picture w4tsn  ·  6Comentários
johanstokking picture johanstokking  ·  8Comentários
adriansmares picture adriansmares  ·  9Comentários