Lorawan-stack: Mostrar solicitação de junção, uplink e erros na visualização de tráfego do console

Obrigado por adicionar isso é um "must have"
Foi uma das primeiras coisas que notamos ao avaliar a v3 no mercado da AWS.
Desculpe perguntar, alguma ideia de quando?

@industrialinternet obrigado por mostrar seu interesse. Está definido no marco de fevereiro, então nosso objetivo é terminá-lo este mês. Por favor, assine esta edição e assista a este repositório, pelo menos para lançamentos, clicando em Assistir na parte superior, para que você saiba quando ele chega em qual lançamento.

@johanstokking

Considere os corpos de eventos como.up.forward:

Eu acho que você quer dizer as.up.data.forward aqui?

1. Podemos supor que os campos que você mencionou estão sempre lá (se a operação do evento for bem-sucedida) para cada tipo de evento?
2. Quais campos devem ser incluídos no componente widget de eventos (aquele das páginas de visão geral da entidade)?
   
3. Quão grande o objeto decoded_payload pode ser? Perguntando porque pode ser truncado no evento ui.

Eu acho que você quer dizer as.up.data.forward aqui?

Ah, de fato, nós os dividimos em as.up.join.forward e as.up.data.forward , e todos os eventos de downlink que mencionei não foram encaminhados (ainda).

1. Podemos supor que os campos que você mencionou estão sempre lá (se a operação do evento for bem-sucedida) para cada tipo de evento?

• frm_payload está sempre em as.up.data.forward , mas decoded_payload é opcional
• os identificadores de dispositivo estão sempre em as.up.join.forward

2. Quais campos devem ser incluídos no componente widget de eventos (aquele das páginas de visão geral da entidade)?

Nos casos em que temos menos espaço você quer dizer? Eu acho que para uplink de dados a carga útil decodificada e para join aceita o DevEUI.

1. Quão grande pode ser o objeto decoded_payload ? Perguntando porque pode ser truncado no evento ui.

Na linha, não há problema em truncá-lo. Se você expandir a linha, ela deverá ser exibida como JSON. Na verdade, pode se tornar bastante grande, depende do fabricante do dispositivo ou do desenvolvedor do aplicativo.

Mas a maioria é como {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

Atualizado o comentário original aqui

Oi johan e outros envolvidos neste assunto

Bom saber que vocês têm um "milstone" para fevereiro.
Como vemos avaliando o console V3, muito pode ser feito aqui com meios simples de fazer um excelente produto para desenvolvedores. e administração

1) Possibilidade de enviar downlinks para todo o aplicativo ou nó separadamente
2) Ser capaz de ver o HEX da carga útil do uplink e decodificado em uma janela separada
3) Algum tipo de hierarquia para o diretório de aplicativos fx. Pai/filho/nó

Mesmo que planejemos usar o TTI conectado aos nossos próprios servidores, isso seria uma excelente adição para P&D e monitoramento

Enfim - bom trabalho até agora cara :-)

BR
/UMA

Ordem de importância;

1. Exibição hexadecimal de ids.join_eui , ids.dev_eui e ids.dev_addr em solicitações de junção, ids.dev_addr e uplink_message.frm_payload para mensagens de uplink
2. Mensagens de erro formatadas (ou seja, preencha os atributos)
3. Mostrar JSON de payload decodificado

Só para esclarecer as coisas.

• O fluxo de junção é o seguinte:

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   Isso tem a seguinte visualização no Console:

Observe a ordem dos identificadores: join_eui , dev_eui e dev_addr

O fluxo de uplink é o seguinte:

1. ns.up.merge_metadata
2. ns.up.data.forward
3. as.up.data.receive
4. as.up.data.forward

Isso tem a seguinte visualização no Console:

Observe a ordem dos identificadores: dev_addr e frm_payload . Acho que também podemos mostrar dev_addr para o resto dos eventos no fluxo de uplink.

O problema que vejo aqui é que não temos muito espaço, principalmente para o evento as.up.join.forward no fluxo de junção. Além disso, apenas valores não fornecem muita informação e adicionar rótulos ( Dev Addr: .... ) deixaria ainda menos espaço.

• Em relação aos erros. Na verdade, podemos apenas pegar a causa mais profunda e preencher os atributos, por exemplo, para

{
  "namespace": "pkg/gatewayserver",
  "name": "host_handle",
  "message_format": "host `{host}` failed to handle message",
  "attributes": {
    "host": "cluster"
  },
  "cause": {
    "namespace": "pkg/networkserver",
    "name": "device_not_found",
    "message_format": "device not found",
    "correlation_id": "25407ee7f3cd4894aeeb23fecd4c4071",
    "code": 5
  },
  "code": 5
}

nós podemos mostrar

ou para solicitação de junção com falha ( ns.up.join.drop ):

Observe que mantemos o erro original não formatado no inspetor de carga útil. Isso pode ser útil para depuração.

• Mostrando carga útil decodificada - para mais tarde

@johanstokking @kschiffer alguma sugestão aqui?

Ótimos primeiros passos!

Observe a ordem dos identificadores: join_eui , dev_eui e dev_addr

Alguns comentários/perguntas:

1. Podemos ter uma coluna para dev_addr , e preenchê-la para todas as mensagens de uplink e aceitação de junção que ocorrerem?
2. Eu acrescentaria JoinEUI e DevEUI com um pequeno texto como JoinEUI e DevEUI para que os usuários saibam qual é qual
3. Mostre os identificadores para cada mensagem que conhecemos, portanto, para muitas linhas, os mesmos identificadores (JS/NS/AS). Isso ocorre porque adicionamos filtragem para eventos posteriormente e em alguns clusters, nem todos os componentes estão disponíveis (como somente JS) e ainda queremos ver identificadores

Observe a ordem dos identificadores: dev_addr e frm_payload .

Bom, também aqui precede com FRMPayload

Acho que também podemos mostrar o dev_addr para o resto dos eventos no fluxo de uplink.

Sim, esse é o ponto 1 acima. Eu concordo com isso.

O problema que vejo aqui é que não temos muito espaço, principalmente para o evento as.up.join.forward no fluxo de junção. Além disso, apenas valores não fornecem muita informação e adicionar rótulos ( Dev Addr: .... ) deixaria ainda menos espaço.

Prefiro transformar o texto "forward data uplink message" em um ícone (ou ícones; AS + uplink + data), em vez de remover informações para manter o texto do evento. Podemos pedir a @pierrephz para criar ícones se concordarmos. cc @kschiffer

Observe que mantemos o erro original não formatado no inspetor de carga útil. Isso pode ser útil para depuração.

Concordou com os erros

Par de pensamentos:

• Nas visualizações de dados de entidades únicas (dispositivos finais, gateways) podemos remover a coluna Entity ID , pois é redundante
• Caso contrário, vamos reduzir um pouco mais a coluna Entity ID
• Precisamos de ícones mais refinados para diferentes eventos, especialmente aqui, eventos relacionados ao procedimento de junção (pode se tornar cada vez mais difícil encontrar ícones apropriados na biblioteca de ícones de material, portanto, talvez precisemos criar nosso próprio conjunto de ícones em breve cc @pierrephz )
  
  
  
  • Para participar de eventos relacionados, podemos usar o ícone link por enquanto
  
  
• Devemos fazer uso de rolagem horizontal no componente de evento (não-widget)
• Algumas mensagens de tipo de evento são (até onde eu sei) desnecessariamente longas, por exemplo receive uplinke data message , não poderia ser apenas receive uplink data ?
• Use uma versão ainda mais estreita do <SafeInspector /> para garantir que as alturas das linhas permaneçam consistentes
• Seria incrível canalizar o frm_payload através da função de formato de carga útil atual e exibir o resultado como um JSON de uma linha (consulte screendesigns). Eu estou bem em considerar isso como ouro por enquanto.

Podemos ter uma coluna para dev_addr e preenchê-la para todas as mensagens de uplink e join aceita que ocorrem?

Vamos adicionar isso como um elemento solto na coluna Data .

Eu acrescentaria o JoinEUI e o DevEUI com um pequeno texto como JoinEUI e DevEUI para que os usuários saibam qual é qual

sim. @bafonins , isso é realmente o que eu quis dizer no slack. Desculpe por não ter sido claro o suficiente lá.

Eu prefiro transformar o texto "forward data uplink message" em um ícone (ou ícones; AS + uplink + dados).

"Um texto diz mais que mil ícones" 😅. Eu realmente gostaria de manter a coluna do tipo de evento como texto. É impossível comunicar seu conteúdo apenas por meio de ícones.

Aqui estão dois screendesigns que mostram o que eu acho que é uma solução viável para aplicação e camada de dispositivo.

Nas visualizações de dados de entidades únicas (dispositivos finais, gateways), podemos remover a coluna Entity ID, pois é redundante

👍 faz sentido

Precisamos de ícones mais refinados para diferentes eventos, especialmente aqui, eventos relacionados ao procedimento de junção

Não apenas para o fluxo de junção. Seria bom ter um ícone personalizado para comandos MAC ( ns.mac.* ).

Algumas mensagens do tipo de evento são (até onde eu sei) desnecessariamente longas, por exemplo, receber mensagem de dados de uplink, não poderia ser apenas receber dados de uplink?

Concordo, é apenas uma questão de renomear várias descrições de erro. Pode ser receive uplink data ou receive uplink message . @johanstokking o que você acha?

Seria incrível canalizar o frm_payload através da função de formato de carga útil atual e exibir o resultado como um JSON de uma linha (consulte screendesigns).

Podemos exibir decoded_payload diretamente, certo? A estrutura de ApplicationUp para mensagens de uplink é:

{
  "uplink_message": {
    ...
    "frm_payload": "AQ==",
    "decoded_payload": {
      "led": "ON"
    }
    ...
}

Eu acrescentaria o JoinEUI e o DevEUI com um pequeno texto como JoinEUI e DevEUI para que os usuários saibam qual é qual

sim. @bafonins , isso é realmente o que eu quis dizer no slack. Desculpe por não ter sido claro o suficiente lá.

👌

Não apenas para o fluxo de junção. Seria bom ter um ícone personalizado para comandos MAC (ns.mac.*).

De fato.

Podemos exibir decoded_payload diretamente, certo? A estrutura do ApplicationUp para mensagens de uplink é:

Ah, claro 🤦‍♂

• por exemplo receive uplinke data message , não poderia ser apenas receive uplink data ?

sim. Mas podemos ter um ícone para "receber" vs "encaminhar" vs "enviar" etc?

Eu realmente gostaria de manter a coluna do tipo de evento como texto. É impossível comunicar seu conteúdo apenas por meio de ícones.

Não apenas, mas como você sugeriu também, podemos substituir algumas coisas óbvias por ícones, certo?

Podemos ter uma coluna para dev_addr e preenchê-la para todas as mensagens de uplink e join aceita que ocorrem?

Vamos adicionar isso como um elemento solto na coluna Data .

A questão é que isso faz parte de _every_ mensagem upstream, incluindo ativações de dispositivos (onde podemos mostrar o novo DevAddr ). Então, no seu primeiro design, o DevAddr não está alinhado (está à direita), porque está solto, eu acho?

Fora isso, esses designs parecem muito bons e úteis

sim. Mas podemos ter um ícone para "receber" vs "encaminhar" vs "enviar" etc?

Acho que teríamos que fazer tudo ou não. Substituir apenas algumas coisas por ícones seria mais confuso, eu acho.

Ainda preciso pensar na melhor forma de representar os tipos de eventos por itens. Pelo que vejo, existem três camadas que são: componente de pilha, processo ou assunto(s) e etapa (por exemplo ns.up.data.forward ).
Como não é realmente possível traduzir todas essas informações em um ícone, precisamos usar vários ícones ou sempre focar em uma das camadas de tipo de evento, como assunto.

Usar três ícones pode ser uma maneira, mas, novamente, eu realmente não gostaria de substituir o texto do tipo de evento, então isso não ajudaria muito com o problema de espaçamento, mas pelo menos tornaria as entradas do evento mais fáceis de verificar.

O fato é que isso faz parte de todas as mensagens upstream, incluindo ativações de dispositivos (onde podemos mostrar o novo DevAddr). Então, no seu primeiro design, o DevAddr não está alinhado (está à direita), porque está solto, eu acho?

De fato. Mas podemos simplesmente colocar o endereço do dispositivo sempre em primeiro lugar por convenção. Se tivéssemos uma coluna dedicada, perderíamos espaço para todos os outros eventos que não precisam mostrar o endereço do dispositivo.

Então, minha sugestão para manter isso acionável:

• Não vamos tocar nos ícones e mensagem do tipo de evento por enquanto, mas em um PR separado
• Use um formulário flexível da coluna de dados, com elementos soltos com base nas necessidades específicas do tipo de evento

@bafonins deixe-me saber se você precisar de qualquer outra informação ou esclarecimento para continuar com este problema.

Usar três ícones pode ser uma maneira, mas, novamente, eu realmente não gostaria de substituir o texto do tipo de evento, então isso não ajudaria muito com o problema de espaçamento, mas pelo menos tornaria as entradas do evento mais fáceis de verificar.

Sim, esse seria o objetivo principal.

Enquanto estamos nisso, podemos considerar o agrupamento por ID de correlação também. Isso atenderá tanto o espaçamento (vertical) quanto a digitalização mais fácil.

De fato. Mas podemos simplesmente colocar o endereço do dispositivo sempre em primeiro lugar por convenção. Se tivéssemos uma coluna dedicada, perderíamos espaço para todos os outros eventos que não precisam mostrar o endereço do dispositivo.

OK

Algumas atualizações:

1. Não mostramos a coluna Entity ID para eventos de dispositivo, gateway e organização. Apenas para aplicações. Isso ajuda a economizar espaço extra, especialmente para dispositivos.
2. Evento de erro:

1. Mostramos decoded_payload se disponível como uma lista simples de valores . pulando quaisquer entradas aninhadas, como matrizes ou objetos (acompanharei a implementação que adiciona cores aos valores de carga útil). Também mostramos frm_payload como hexadecimal quando disponível:

1. Aqui está um exemplo do fluxo de junção:
   (visualização de eventos do aplicativo)

(visualização de eventos do dispositivo)

1. Mostre frm_payload em hexadecimal para eventos de downlink AS. Isso pode ser útil para pessoas que agendam downlinks por meio do Console:

@johanstokking Tem mais alguma coisa? Existem entradas que podemos mostrar para eventos de gateway (para gs.up.receive , por exemplo, podemos mostrar frm_payload f_cnt f_port )?

Excelente!

Alguns comentários/perguntas menores;

• Para eventos upstream AS, inclua também o DevAddr
• Estão mostrando os nomes dos eventos agora?
• Eu usaria os termos LoRaWAN DevAddr e FRMPayload
• A carga útil decodificada geralmente é um objeto plano; {"temperature":21.5,"light":"on"} etc. Se houver um valor aninhado, não há problema em pular isso; ou seja {"nested":{...},"light":"on"}

Para os eventos upstream GS especificamente;

• Atualmente não decodificamos o LoRaWAN raw_payload , porque GS não tem (muito) a ver com LoRaWAN. O GS decodifica os identificadores LoRaWAN (EUIs na junção, DevAddr no uplink), o que pode ser interessante para mostrar neste fluxo para filtragem. Soluções potenciais:
  
  
  
  • ~Solução do pobre; deixe isso para o espectador (console). Isso é o que fazemos no Console V2 também. Não é ideal porque adiciona lógica LoRaWAN ao Console~
  
  
  • ~De alguma forma, conecte os identificadores na carga útil do evento. Atualmente estamos publicando UplinkMessage , que deve se tornar algo como DeviceUplinkMessage que incorpora UplinkMessage ~
  
  
  • Decodifique a carga útil, se o front-end ainda não fez isso (o Basic Station faz porque reconstrói o PHYPayload)
  
  
• Atualmente, estamos publicando vários eventos de encaminhamento se houver vários hosts na tabela de encaminhamento do GS, ou seja, NS e Packet Broker. A carga útil do evento para gs.up.forward é nil . Podemos definir uma nova mensagem proto com o nome do host e podemos passar um map[string]string{}

~ @htdvisser , por favor, aconselhe sobre os assuntos de carga útil do evento; isso não é coberto pelas diretrizes de desenvolvimento.~

@johanstokking

Para eventos upstream AS, inclua também o DevAddr

Então, para as.up.data.receive , as.up.data.forward ? E as.down.data.receive e as.down.data.forward ?
Acho que também queremos mostrar o mesmo para ns.up.data.* .

Estão mostrando os nomes dos eventos agora?

Não, mostraremos a descrição completa do evento como está agora.

Eu usaria os termos LoRaWAN DevAddr e FRMPayload

Você quer dizer em vez de Device Address e Frame Payload ?

A carga útil decodificada geralmente é um objeto plano; {"temperature":21.5,"light":"on"} etc. Se houver um valor aninhado, não há problema em pular isso; ou seja, {"nested":{...},"light":"on"}

De acordo com os desenhos, mostramos apenas valores. Então, para {"temperature":21.5,"light":"on"} vamos mostrar [21.5, "on"] . Isso é bom?

O GS decodifica os identificadores LoRaWAN (EUIs na junção, DevAddr no uplink), o que pode ser interessante para mostrar neste fluxo para filtragem

Podemos mostrar os identificadores para gs.up.receive . Para solicitação de associação, podemos mostrar os EUIs de:

  "payload": {
    "join_request_payload": {
      "join_eui": "...",
      "dev_eui": "..."
    }
  }

E mostre dev addr para uplinks de:

  "payload": {
    "mac_payload": {
      "f_hdr": {
        "dev_addr": "...",
      }
    }
  }

Então, para as.up.data.receive , as.up.data.forward ? E as.down.data.receive e as.down.data.forward ?
Acho que também queremos mostrar o mesmo para ns.up.data.* .

Sim, se os identificadores estiverem na carga, mostre-os.

Você quer dizer em vez de Device Address e Frame Payload ?

>

sim

De acordo com os desenhos, mostramos apenas valores. Então, para {"temperature":21.5,"light":"on"} vamos mostrar [21.5, "on"] . Isso é bom?

Não, acho que precisamos de chaves aqui. Muitos valores são numéricos, então isso se torna confuso. Também porque este é um mapa, não há ordem fixa (a menos que você classifique as chaves e pegue os valores).

Podemos mostrar os identificadores para gs.up.receive . Para solicitação de associação, podemos mostrar os EUIs de:

Sim, mas não temos eles na carga, certo? Esta é a carga útil, por exemplo:

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
  "raw_payload": "QOYAACeAws8CQ+4LarGLXmIEFQ==",
  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 7
      }
    },
    "coding_rate": "4/5",
    "frequency": "867900000",
    "timestamp": 2986005427,
    "time": "2020-04-29T07:57:06Z"
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "kerlink-ifemtocell",
        "eui": "7276FF003903007D"
      },
      "time": "2020-04-29T07:57:06Z",
      "timestamp": 2986005427,
      "rssi": -28,
      "channel_rssi": -28,
      "snr": 8,
      "uplink_token": "CiAKHgoSa2VybGluay1pZmVtdG9jZWxsEghydv8AOQMAfRCzp+uPCw==",
      "channel_index": 4
    }
  ],
  "received_at": "2020-04-29T07:57:06.748570190Z",
  "correlation_ids": [
    "gs:conn:01E6VEV9V14WMAY1DW19BQQPMX",
    "gs:uplink:01E72F0YSWJAKBYBJDBXG4CJ4G"
  ]
}

Sim, se os identificadores estiverem no payload, mostre-os

Podemos os identificadores do campo identifiers do evento se a carga estiver vazia:

    "identifiers": [
      {
        "device_ids": {
          "device_id": "...",
          "application_ids": {
            "application_id": "...",
          },
          "dev_eui": "...",
          "join_eui": "...",
          "dev_addr": "...",
        },
      },
    ],

Não, acho que precisamos de chaves aqui. Muitos valores são numéricos, então isso se torna confuso. Também porque este é um mapa, não há ordem fixa (a menos que você classifique as chaves e pegue os valores).

👌

Sim, mas não temos eles na carga, certo? Esta é a carga útil, por exemplo:

Aqui está o que eu tenho para receive uplink message - gs.up.receive :

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
  "raw_payload": "AAEAUAEAy6BYiiAcAAujBAB5X7wJxJ0=",
  "payload": {
    "m_hdr": {},
    "mic": "vAnEnQ==",
    "join_request_payload": {
      "join_eui": "...",
      "dev_eui": "...",
      "dev_nonce": "..."
    }
  },
  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 7
      }
    },
    "coding_rate": "4/5",
    "frequency": "868300000",
    "timestamp": 3115131027,
    "time": "2020-04-29T08:13:09.690629005Z"
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "bafonins-ttig",
        "eui": "58A0CBFFFE8010D6"
      },
      "time": "2020-04-29T08:13:09.690629005Z",
      "timestamp": 3115131027,
      "rssi": -35,
      "channel_rssi": -35,
      "snr": 8.25,
      "uplink_token": "ChsKGQoNYmFmb25pbnMtdHRpZxIIWKDL//6AENYQk8G0zQs="
    }
  ],
  "received_at": "2020-04-29T08:13:09.450967669Z",
  "correlation_ids": [
    "gs:conn:01E7140GJKZ5BKHMC774RV4C11",
    "gs:uplink:01E72FYAYB272T9X90MJEZNEAX"
  ]
}

OK, sim, mostre-lhes. Atualmente eles podem ser nil , então considere isso, mas podemos alterar o GS para decodificar a carga se isso ainda não aconteceu.

@johanstokking

Junte-se ao fluxo com eui onde join_request_payload está disponível:

Uplink com carga útil decodificada:

Evento com falha:

Eventos de uplink/downlink AS:

Evento de solicitação de ingresso no gateway:

Uplink de gateway com mac_payload :

Impressionante

Mais um pedido; adicione FPort antes de cada ocorrência de FRMPayload

Fechado por https://github.com/TheThingsNetwork/lorawan-stack/pull/2477