Lorawan-stack: Mostrar el último mensaje de enlace ascendente y el recuento de enlaces ascendentes y descendentes

No estoy seguro de si esto es lo mismo, pero sería muy útil comprobar rápidamente la existencia de session del NS, la fecha/hora de activación y los posibles contadores de fotogramas.

@rvolosatovs , ¿mantenemos una marca de tiempo "visto por última vez" en NS?

@rvolosatovs , ¿mantenemos una marca de tiempo "visto por última vez" en NS?

No, pero se puede derivar de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

@rvolosatovs , ¿mantenemos una marca de tiempo "visto por última vez" en NS?

No, pero se puede derivar de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

Eso es lo que hice, pero pensé que para la funcionalidad completa, necesitaríamos conectarnos al flujo de eventos para mantener los números actualizados en tiempo real.

Eso es lo que hice, pero pensé que para la funcionalidad completa, necesitaríamos conectarnos al flujo de eventos para mantener los números actualizados en tiempo real.

Antes de continuar e implementarlo de esta manera, @htdvisser , ¿cree que ese enfoque es lo suficientemente completo? Los eventos de enlace ascendente de enlace descendente no contienen el recuento de fotogramas actual, por lo que tendría que incrementarlos en función del valor inicial que obtuve del accesorio de sesión dentro del dispositivo final.

Ese no es el camino a seguir, me temo.

¿No estamos enviando los contadores de fotogramas? Ese sería el verdadero problema entonces.

@rvolosatovs , ¿mantenemos una marca de tiempo "visto por última vez" en NS?

No, pero se puede derivar de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

Eso es lo que hice, pero pensé que para la funcionalidad completa, necesitaríamos conectarnos al flujo de eventos para mantener los números actualizados en tiempo real.

Desafortunadamente, no es tan simple como parece a primera vista.

1. (ABP) Dispositivo, para el cual ResetsFCnt==true puede restablecer FCnt por sí mismo
2. (OTAA) El dispositivo puede volver a unirse, lo que en sí mismo no restablecerá los FCnt todavía - FCnt se restablecerá o aumentará dependiendo de la ID de clave de sesión utilizada en el siguiente enlace ascendente de datos recibido
3. El FCnt en la carga útil del enlace ascendente no es necesariamente el dispositivo real FCnt , porque solo se envían 16 LSB en el enlace ascendente, mientras que los contadores de cuadros pueden tener un ancho de 32 bits.

Todo esto lo maneja NS (y 2. en parte AS), y ciertamente no creo que la consola haga lo mismo.

Creo que el camino a seguir es agregar eventos para (1.) - ns.device.reset y (2.) - ns.device.confirm_session (¿o tal vez ns.device.rejoin ?).
Para (3.) necesitamos encontrar una manera de entregar el valor total FCnt a la consola. Es posible que queramos introducir otro evento, por ejemplo, ns.up.data.match o ns.up.data.handle que indican un procesamiento exitoso del enlace ascendente e incluyen FCnt completos (y posiblemente más). Tenga en cuenta que ns.up.data.forward no está relacionado aquí y simplemente indica que el enlace ascendente se envía a AS, actualmente se publica por error en cada enlace ascendente, ahora se publicará solo cuando se reenvíe al AS (PR entrante), también , la carga útil del enlace ascendente AS no contiene los FCnt completos, pero los FCnt enviados en el enlace ascendente (es decir, 16 LSB)

Bloqueado hasta que lleguemos a una conclusión sobre los eventos de NS para impulsar esto y que se implemente en NS.

Ok, entiendo que esto no es factible en este momento. Entonces, ¿qué pasa con el valor de last seen ? ¿Es seguro obtener un valor inicial del registro del dispositivo y luego mantenerlo actualizado a través de eventos relevantes del dispositivo (como enlace ascendente, enlace descendente confirmado, etc.)?

Ok, entiendo que esto no es factible en este momento. Entonces, ¿qué pasa con el valor de last seen ? ¿Es seguro obtener un valor inicial del registro del dispositivo y luego mantenerlo actualizado a través de eventos relevantes del dispositivo (como enlace ascendente, enlace descendente confirmado, etc.)?

Sí, ns.up.data.receive , ns.up.join.receive , ns.up.rejoin.receive es lo que estás buscando

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

NS ahora publica el evento ns.up.data.process , que contiene el enlace ascendente con FCnt completo como carga útil

Utilice el valor en el enlace ascendente como activo real DevAddr y FCntUp del dispositivo

Para los enlaces descendentes, actualmente no tenemos una funcionalidad similar, pero ese tampoco es el enfoque de este problema, comencemos solo con el enlace ascendente FCnt y luego agreguemos enlaces descendentes en una etapa posterior (Tenga en cuenta que, según la versión de LoRaWAN, en realidad podemos tener 2 enlaces descendentes distintos contadores de cuadros: uno para NS y otro para AS, por lo que también es mucho menos trivial que el contador de cuadros de enlace ascendente).

Cuando sepamos el último enlace ascendente en la aplicación, reemplacemos Linked con Last seen en la vista de la aplicación (similar a la página de descripción general de la puerta de enlace).

Cuando sepamos el último enlace ascendente en la aplicación, reemplacemos Linked con Last seen en la vista de la aplicación (similar a la página de descripción general de la puerta de enlace).

Definitivamente sería bueno mostrar esa información globalmente para la aplicación, pero hacerlo significaría que la consola necesita sondear todos los dispositivos finales asociados con la aplicación, uno tras otro, para poder mostrar el estado inicial visto por última vez. No creo que esto sea viable cuando tenemos que asumir aplicaciones con potencialmente cientos o miles de dispositivos finales.

Dos cosas en las que podría pensar:

1. Podría mostrar la última información vista a medida que esté disponible a través del flujo entrante de eventos de mensajes del dispositivo. Sin embargo, según la configuración de la aplicación, podría significar que no habrá tales eventos disponibles de manera oportuna (piense en los dispositivos finales que envían enlaces descendentes cada hora o con menos frecuencia).
2. Podríamos usar un umbral del conteo de dispositivos después del cual dejamos de calcular el último valor visto inicialmente. Si una aplicación tiene más de 100 dispositivos, también es muy probable que los eventos de dispositivo necesarios lleguen muy pronto después de cargar la página de la aplicación.

@htdvisser @rvolosatovs ¿Tal vez pase algo por alto? Alternativamente, ¿puede pensar en alguna forma de agregar esos datos y ponerlos a disposición a través de un punto final de API?

ApplicationLinkStats solo tiene last_up_received_at y last_downlink_forwarded_at :

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

Cerrado vía #2585