Lorawan-stack: Mostrar a última mensagem de uplink e contagem de up- & downlink

Não tenho certeza se isso é o mesmo, mas verificar rapidamente session do NS quanto à existência, data/hora de ativação e contadores de quadros potencialmente seria muito útil.

@rvolosatovs estamos mantendo um carimbo de data/hora "visto pela última vez" no NS?

@rvolosatovs estamos mantendo um carimbo de data/hora "visto pela última vez" no NS?

Não, mas pode ser derivado de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

@rvolosatovs estamos mantendo um carimbo de data/hora "visto pela última vez" no NS?

Não, mas pode ser derivado de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

Foi o que fiz, mas imaginei que, para a funcionalidade completa, precisaríamos nos conectar ao fluxo de eventos para manter os números atualizados em tempo real.

Foi o que fiz, mas imaginei que, para a funcionalidade completa, precisaríamos nos conectar ao fluxo de eventos para manter os números atualizados em tempo real.

Antes de prosseguir e implementá-lo dessa maneira, @htdvisser , você acha que essa abordagem é completa o suficiente? Os eventos de downlink de uplink não contêm a contagem de quadros atual, então eu teria que incrementá-los com base no valor inicial que obtive do prop de sessão dentro do dispositivo final.

Esse não é o caminho a seguir, eu temo.

Não estamos enviando os contadores de quadros? Essa seria a verdadeira questão então.

@rvolosatovs estamos mantendo um carimbo de data/hora "visto pela última vez" no NS?

Não, mas pode ser derivado de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

Foi o que fiz, mas imaginei que, para a funcionalidade completa, precisaríamos nos conectar ao fluxo de eventos para manter os números atualizados em tempo real.

Infelizmente, não é tão simples quanto parece à primeira vista.

1. (ABP) Dispositivo, para o qual ResetsFCnt==true pode redefinir o próprio FCnt
2. (OTAA) O dispositivo pode se juntar novamente, o que por si só não deve redefinir o FCnt ainda - FCnt deve ser redefinido ou aumentado dependendo do ID da chave de sessão usado no próximo uplink de dados recebido
3. O FCnt no payload do uplink não é necessariamente o dispositivo real FCnt , porque apenas 16 LSB são enviados no uplink, enquanto os contadores de quadros podem ter 32 bits de largura.

Tudo isso é tratado pelo NS (e 2. em parte pelo AS), e eu certamente não acho que o console fará o mesmo.

Acho que o caminho a seguir é adicionar eventos para (1.) - ns.device.reset e (2.) - ns.device.confirm_session (ou talvez ns.device.rejoin ?).
Para (3.), precisamos descobrir uma maneira de entregar o valor total FCnt ao console. Podemos querer introduzir outro evento, por exemplo ns.up.data.match , ou ns.up.data.handle que indica o processamento bem sucedido do uplink e inclui FCnt completo (e possivelmente mais). Observe que ns.up.data.forward não está relacionado aqui e apenas indica que o uplink está sendo enviado para o AS, atualmente é publicado erroneamente em cada uplink, agora será publicado apenas quando estiver realmente sendo encaminhado para o AS(PR entrante), também , a carga útil do uplink AS não contém o FCnt completo, mas o FCnt enviado no uplink (portanto, 16 LSB)

Bloqueado até chegarmos a uma conclusão sobre os eventos do NS para conduzir isso e que é implementado no NS.

Ok, entendo que isso realmente não é viável no momento. E quanto ao last seen então. É salvar para obter um valor inicial do registro do dispositivo e mantê-lo atualizado por meio de eventos relevantes do dispositivo (como uplink, downlink confirmado etc.)?

Ok, entendo que isso realmente não é viável no momento. E quanto ao last seen então. É salvar para obter um valor inicial do registro do dispositivo e mantê-lo atualizado por meio de eventos relevantes do dispositivo (como uplink, downlink confirmado etc.)?

Sim, ns.up.data.receive , ns.up.join.receive , ns.up.rejoin.receive é o que você está procurando

~Bloqueado por https://github.com/TheThingsNetwork/lorawan-stack/pull/2221 #2222~

O NS agora publica o evento ns.up.data.process , que contém o uplink com FCnt completo como carga útil

Use o valor no uplink como ativo real DevAddr e FCntUp do dispositivo

Para downlinks, atualmente não temos funcionalidade semelhante, mas esse também não é o foco deste problema, vamos começar apenas com o uplink FCnt e depois adicionar downlinks em um estágio posterior (Observe que, dependendo da versão do LoRaWAN, podemos ter 2 downlinks distintos contadores de quadros - um para NS e outro para AS, então é muito menos trivial que o contador de quadros de uplink também.)

Quando soubermos o último uplink no aplicativo, vamos substituir Linked por Last seen na visualização do aplicativo (semelhante à página de visão geral do gateway).

Quando soubermos o último uplink no aplicativo, vamos substituir Linked por Last seen na visualização do aplicativo (semelhante à página de visão geral do gateway).

Definitivamente seria bom mostrar essas informações globalmente para o aplicativo, mas isso significaria que o console precisa sondar todos os dispositivos finais associados ao aplicativo um após o outro, para poder mostrar o status inicial visto pela última vez. Não acho que isso seja viável quando temos que assumir aplicativos com potencialmente centenas ou milhares de dispositivos finais.

Duas coisas que eu poderia pensar:

1. Eu poderia mostrar as últimas informações vistas à medida que ficam disponíveis por meio do fluxo de entrada de eventos de mensagens do dispositivo. Dependendo da configuração do aplicativo, no entanto, isso pode significar que não haverá tais eventos disponíveis em tempo hábil (pense em dispositivos finais que enviam downlinks a cada hora ou menos frequentemente).
2. Poderíamos usar um limite da contagem de dispositivos após o qual paramos de calcular o último valor visto inicialmente. Se um aplicativo tiver mais de 100 dispositivos, também é muito provável que os eventos de dispositivo necessários cheguem logo após o carregamento da página do aplicativo.

@htdvisser @rvolosatovs Talvez eu ignore algo? Como alternativa, você pode pensar em alguma maneira de agregar esses dados e disponibilizá-los por meio de um endpoint de API?

ApplicationLinkStats tem apenas last_up_received_at e last_downlink_forwarded_at :

https://github.com/TheThingsNetwork/lorawan-stack/blob/develop/api/applicationserver.proto#L56 -L69

Fechado via #2585