Lorawan-stack: Mostrar solicitud de unión, enlace ascendente y errores en la vista de tráfico de la Consola

Gracias por agregar esto, es un "must have"
Fue una de las primeras cosas que notamos al evaluar v3 en el mercado de AWS.
Perdón por preguntar, ¿alguna idea de cuándo?

@industrialinternet gracias por mostrar su interés. Está ambientado en el hito de febrero, por lo que nuestro objetivo es terminarlo este mes. Suscríbase a este número y mire este repositorio, al menos para los lanzamientos, haciendo clic en Ver en la parte superior, para que sepa cuándo aterriza en qué lanzamiento.

@johanstokking

Considere como cuerpos de eventos ascendentes:

¿Supongo que te refieres a as.up.data.forward aquí?

1. ¿Podemos suponer que los campos que mencionó siempre están ahí (si la operación del evento es exitosa) para cada tipo de evento?
2. ¿Qué campos deben incluirse en el componente de widget de eventos (el de las páginas de descripción general de la entidad)?
   
3. ¿Qué tan grande puede ser el objeto decoded_payload ? Preguntando porque podría estar truncado en el evento ui.

¿Supongo que te refieres a as.up.data.forward aquí?

Ah, de hecho, los dividimos en as.up.join.forward y as.up.data.forward , y todos los eventos de enlace descendente que mencioné no se reenvían (todavía).

1. ¿Podemos suponer que los campos que mencionó siempre están ahí (si la operación del evento es exitosa) para cada tipo de evento?

• frm_payload siempre está en as.up.data.forward , pero decoded_payload es opcional
• los identificadores de dispositivos siempre están en as.up.join.forward

2. ¿Qué campos deben incluirse en el componente de widget de eventos (el de las páginas de descripción general de la entidad)?

¿En los casos en los que tenemos menos espacio te refieres? Creo que para el enlace ascendente de datos, la carga útil decodificada, y para unirse, acepta DevEUI.

1. ¿Qué tan grande puede ser el objeto decoded_payload ? Preguntando porque podría estar truncado en el evento ui.

En la fila está bien truncarla. Si expande la fila, debería mostrarse como JSON. En realidad, puede volverse bastante grande, depende del fabricante del dispositivo o del desarrollador de la aplicación.

Pero la mayoría es como {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

Actualizado el comentario original aquí

Hola johan y otros involucrados en este asunto.

Es bueno escuchar que ustedes tienen un "milstone" para febrero.
Como lo vemos evaluando la consola V3, se puede hacer mucho aquí con medios simples para hacer un producto sobresaliente para desarrolladores. y administración

1) Posibilidad de enviar enlaces descendentes a toda la Aplicación o Nodo por separado
2) Ser capaz de ver la carga útil del enlace ascendente HEX y decodificar en una ventana separada
3) Algún tipo de jerarquía para el directorio de aplicaciones fx. Padre/hijo/nodo

Incluso si planeamos usar TTI conectado a nuestros propios servidores, sería una excelente adición para I+D y monitoreo.

De todos modos - buen trabajo hasta ahora chicos :-)

BR
/A

Orden de importancia;

1. Visualización hexadecimal de ids.join_eui , ids.dev_eui y ids.dev_addr en solicitudes de unión, ids.dev_addr y uplink_message.frm_payload para mensajes de enlace ascendente
2. Mensajes de error formateados (es decir, complete los atributos)
3. Mostrar JSON de carga útil decodificada

Solo para aclarar las cosas.

• El flujo de unión es el siguiente:

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   Esto tiene la siguiente vista en la consola:

Tenga en cuenta el orden de los identificadores: join_eui , dev_eui y dev_addr

El flujo de enlace ascendente es el siguiente:

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

Esto tiene la siguiente vista en la Consola:

Tenga en cuenta el orden de los identificadores: dev_addr y frm_payload . Creo que también podemos mostrar los dev_addr para el resto de los eventos en el flujo del enlace ascendente.

El problema que veo aquí es que realmente no tenemos mucho espacio, especialmente para el evento as.up.join.forward en el flujo de combinación. Además, solo los valores realmente no brindan mucha información y agregar etiquetas ( Dev Addr: .... ) dejaría aún menos espacio.

• Respecto a los errores. De hecho, podemos simplemente tomar la causa más profunda y completar los atributos, por ejemplo, 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
}

podemos mostrar

o por solicitud de unión fallida ( ns.up.join.drop ):

Tenga en cuenta que mantenemos el error original sin formato en el inspector de carga útil. Esto podría ser útil para la depuración.

• Mostrando la carga útil decodificada - para más tarde

@johanstokking @kschiffer ¿ alguna sugerencia aquí?

¡Grandes primeros pasos!

Tenga en cuenta el orden de los identificadores: join_eui , dev_eui y dev_addr

Algunos comentarios/preguntas:

1. ¿Podemos tener una columna para dev_addr y llenarla para todos los mensajes de enlace ascendente y aceptaciones de unión que ocurren?
2. Yo antepondría JoinEUI y DevEUI con un pequeño texto como JoinEUI y DevEUI para que los usuarios sepan cuál es cuál.
3. Mostrar los identificadores de cada mensaje que conocemos, por lo que podría ser para muchas filas los mismos identificadores (JS/NS/AS). Esto se debe a que agregamos filtros para eventos más adelante y en algunos clústeres, no todos los componentes están disponibles (como solo JS) y aún queremos ver los identificadores.

Tenga en cuenta el orden de los identificadores: dev_addr y frm_payload .

Bien, aquí también anteponga FRMPayload

Creo que también podemos mostrar dev_addr para el resto de los eventos en el flujo del enlace ascendente.

Sí, ese es el punto 1 anterior. Estoy de acuerdo con eso.

El problema que veo aquí es que realmente no tenemos mucho espacio, especialmente para el evento as.up.join.forward en el flujo de combinación. Además, los valores simples realmente no brindan mucha información y agregar etiquetas ( Dev Addr: .... ) dejaría aún menos espacio.

Preferiría convertir el texto del "mensaje de enlace ascendente de datos reenviados" en un ícono (o íconos; AS + enlace ascendente + datos), en lugar de eliminar información para mantener el texto del evento. Podemos pedirle a @pierrephz que diseñe íconos si estamos de acuerdo. cc @kschiffer

Tenga en cuenta que mantenemos el error original sin formato en el inspector de carga útil. Esto podría ser útil para la depuración.

De acuerdo con los errores

Un par de pensamientos:

• En las vistas de datos de entidades individuales (dispositivos finales, puertas de enlace) podemos eliminar la columna Entity ID , ya que es redundante
• De lo contrario, reduzcamos un poco más la columna Entity ID
• Necesitamos íconos más detallados para diferentes eventos, especialmente aquí, eventos relacionados con el procedimiento de unión (puede ser cada vez más difícil encontrar íconos apropiados en la biblioteca de íconos de material, por lo que es posible que necesitemos crear nuestro propio conjunto de íconos pronto cc @pierrephz )
  
  
  
  • Para unirse a eventos relacionados, podemos usar el ícono link por el momento
  
  
• Deberíamos hacer uso del desplazamiento horizontal en el componente de evento (sin widget)
• Algunos mensajes de tipo de evento son (por lo que sé) innecesariamente largos, por ejemplo, receive uplinke data message , ¿no podría ser simplemente receive uplink data ?
• Use una versión aún más estrecha de <SafeInspector /> para asegurarse de que las alturas de las filas permanezcan consistentes
• Sería increíble canalizar los frm_payload a través de la función de formato de carga útil actual y mostrar el resultado como un JSON de una línea (ver diseños de pantalla). Estoy bien para considerar esto como un baño de oro por el momento.

¿Podemos tener una columna para dev_addr y llenarla con todos los mensajes de enlace ascendente y las aceptaciones de unión que se produzcan?

Agreguemos eso como un elemento suelto en la columna Data .

Yo antepondría JoinEUI y DevEUI con un pequeño texto como JoinEUI y DevEUI para que los usuarios sepan cuál es cuál.

Si. @bafonins , esto es realmente lo que quise decir en holgura. Lo siento por no ser lo suficientemente claro allí.

Preferiría convertir el texto del "mensaje de enlace ascendente de datos reenviados" en un icono (o iconos; AS + enlace ascendente + datos).

"Un texto dice más que mil iconos" 😅. Realmente me gustaría mantener la columna de tipo de evento como texto. Es imposible comunicar su contenido únicamente a través de iconos.

Aquí hay dos diseños de pantalla que muestran lo que creo que es una solución viable para la capa de aplicación y dispositivo.

En las vistas de datos de entidades individuales (dispositivos finales, puertas de enlace) podemos eliminar la columna ID de entidad, ya que es redundante

👍 tiene sentido

Necesitamos íconos más detallados para diferentes eventos, especialmente aquí, eventos relacionados con el procedimiento de unión.

No solo para el flujo de unión. Sería bueno tener un ícono personalizado para los comandos MAC ( ns.mac.* ).

Algunos mensajes de tipo de evento son (hasta donde puedo decir) innecesariamente largos, por ejemplo, recibir un mensaje de datos de enlace ascendente, ¿no podría ser simplemente recibir datos de enlace ascendente?

De acuerdo, es solo cuestión de cambiar el nombre de varias descripciones de error. Podría ser receive uplink data o receive uplink message . @johanstokking ¿qué opinas?

Sería increíble canalizar frm_payload a través de la función de formato de carga útil actual y mostrar el resultado como un JSON de una línea (ver diseños de pantalla).

Podemos mostrar decoded_payload directamente, ¿verdad? La estructura de ApplicationUp para mensajes de enlace ascendente es:

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

Yo antepondría JoinEUI y DevEUI con un pequeño texto como JoinEUI y DevEUI para que los usuarios sepan cuál es cuál.

Si. @bafonins , esto es realmente lo que quise decir en holgura. Lo siento por no ser lo suficientemente claro allí.

👌

No solo para el flujo de unión. Sería bueno tener un ícono personalizado para los comandos MAC (ns.mac.*).

Por supuesto.

Podemos mostrar decoded_payload directamente, ¿verdad? La estructura de ApplicationUp para mensajes de enlace ascendente es:

Oh, por supuesto 🤦‍♂

• por ejemplo receive uplinke data message , ¿no podría ser simplemente receive uplink data ?

Si. Pero, ¿podemos tener un ícono para "recibir" versus "reenviar" versus "enviar", etc.?

Realmente me gustaría mantener la columna de tipo de evento como texto. Es imposible comunicar su contenido únicamente a través de iconos.

No solo, sino que como usted sugirió también, podemos reemplazar algunas cosas obvias por íconos, ¿verdad?

¿Podemos tener una columna para dev_addr y llenarla con todos los mensajes de enlace ascendente y las aceptaciones de unión que se produzcan?

Agreguemos eso como un elemento suelto en la columna Data .

La cuestión es que esto es parte de _todos_ los mensajes ascendentes, incluidas las activaciones de dispositivos (donde podemos mostrar el nuevo DevAddr ). Entonces, en su primer diseño, el DevAddr no está alineado (está a la derecha), porque está suelto, supongo.

Aparte de eso, estos diseños se ven muy bien y son útiles.

Si. Pero, ¿podemos tener un ícono para "recibir" versus "reenviar" versus "enviar", etc.?

Creo que tendríamos que hacerlo todo el camino o no hacerlo. Reemplazar solo algunas cosas por íconos sería más confuso, creo.

Todavía necesito pensar en la mejor manera de representar los tipos de eventos por elementos. Por lo que veo, hay tres capas que son: componente de pila, proceso o tema(s) y paso (por ejemplo ns.up.data.forward ).
Dado que no es realmente posible traducir toda esta información en un solo ícono, necesitamos usar múltiples íconos o enfocarnos siempre en una de las capas de tipo de evento, como sujeto.

Usar tres íconos podría ser una forma, pero, de nuevo, no me gustaría reemplazar el texto del tipo de evento, por lo que realmente no ayudaría con el problema de espaciado, pero al menos haría que las entradas de eventos fueran más fáciles de escanear.

La cuestión es que esto es parte de cada mensaje ascendente, incluidas las activaciones de dispositivos (donde podemos mostrar el nuevo DevAddr). Entonces, en su primer diseño, el DevAddr no está alineado (está a la derecha), porque está suelto, supongo.

Por supuesto. Pero podemos simplemente poner la dirección del dispositivo siempre primero como convención. Si tenemos una columna dedicada, perderíamos espacio para todos los demás eventos que no necesitan mostrar la dirección del dispositivo.

Así que mi sugerencia para mantener esto accionable:

• No toquemos los íconos y el mensaje de tipo de evento por ahora, sino en un PR separado
• Utilice una forma flexible de la columna de datos, con elementos sueltos en función de las necesidades específicas del tipo de evento.

@bafonins avíseme si necesita alguna otra información o aclaración para continuar con este problema.

Usar tres íconos podría ser una forma, pero, de nuevo, no me gustaría reemplazar el texto del tipo de evento, por lo que realmente no ayudaría con el problema de espaciado, pero al menos haría que las entradas de eventos fueran más fáciles de escanear.

Sí, ese sería el objetivo principal.

Mientras estamos en eso, es posible que también deseemos considerar agrupar por ID de correlación. Eso hará que tanto el servicio de espaciado (vertical) sea más fácil de escanear.

Por supuesto. Pero podemos simplemente poner la dirección del dispositivo siempre primero como convención. Si tenemos una columna dedicada, perderíamos espacio para todos los demás eventos que no necesitan mostrar la dirección del dispositivo.

OK

Algunas actualizaciones:

1. No mostramos la columna Entity ID para eventos de dispositivo, puerta de enlace y organización. Solo para aplicaciones. Esto ayuda a ahorrar espacio adicional, especialmente para los dispositivos.
2. Evento de error:

1. Mostramos decoded_payload si está disponible como una lista simple de valores . omitiendo cualquier entrada anidada como matrices u objetos (seguiré con la implementación que agrega colores a los valores de carga útil). También mostramos frm_payload como hexadecimal cuando está disponible:

1. Aquí hay un ejemplo del flujo de unión:
   (vista de eventos de la aplicación)

(vista de eventos del dispositivo)

1. Muestra frm_payload en hexadecimal para eventos de enlace descendente AS. Esto podría ser útil para las personas que programan enlaces descendentes a través de la Consola:

@johanstokking ¿Hay algo más? ¿Hay alguna entrada que podamos mostrar para eventos de puerta de enlace (para gs.up.receive , por ejemplo, podemos mostrar frm_payload f_cnt f_port )?

¡Estupendo!

Algunos comentarios/preguntas menores;

• Para eventos ascendentes de AS, incluya también DevAddr
• ¿Están mostrando los nombres de los eventos ahora?
• Usaría los términos LoRaWAN DevAddr y FRMPayload
• La carga útil decodificada suele ser un objeto plano; {"temperature":21.5,"light":"on"} etc. Si hay un valor anidado, me parece bien omitirlo; es decir {"nested":{...},"light":"on"}

Para los eventos upstream de GS específicamente;

• Actualmente no decodificamos LoRaWAN raw_payload , porque GS no tiene (mucho) que ver con LoRaWAN. GS decodifica los identificadores de LoRaWAN (EUI en la unión, DevAddr en el enlace ascendente), lo que podría ser interesante mostrar en esta transmisión para el filtrado. Posibles soluciones:
  
  
  
  • ~ La solución de los pobres; deja esto en manos del espectador (Consola). Esto es lo que hacemos también en la Consola V2. No es ideal porque agrega lógica LoRaWAN a la consola ~
  
  
  • ~ De alguna manera conecte los identificadores en la carga útil del evento. Actualmente estamos publicando UplinkMessage , que debería convertirse en algo como DeviceUplinkMessage que incrusta UplinkMessage ~
  
  
  • Descodifique la carga útil, si el front-end no lo hizo ya (Basic Station lo hace porque reconstruye PHYPayload)
  
  
• Actualmente estamos publicando varios eventos de reenvío si hay varios hosts en la tabla de reenvío de GS, es decir, NS y Packet Broker. La carga útil del evento para gs.up.forward es nil . Podemos definir un nuevo mensaje proto con el nombre del host y podemos pasar un map[string]string{}

~ @htdvisser , por favor, aconseje sobre los asuntos de carga útil del evento; esto no está cubierto por las pautas de desarrollo.~

@johanstokking

Para eventos ascendentes de AS, incluya también DevAddr

Entonces, por as.up.data.receive , as.up.data.forward ? ¿Qué pasa con as.down.data.receive y as.down.data.forward ?
Supongo que también queremos mostrar lo mismo para ns.up.data.* .

¿Están mostrando los nombres de los eventos ahora?

No, mostraremos la descripción completa del evento tal como está ahora.

Usaría los términos LoRaWAN DevAddr y FRMPayload

¿Quieres decir en lugar de Device Address y Frame Payload ?

La carga útil decodificada suele ser un objeto plano; {"temperature":21.5,"light":"on"}, etc. Si hay un valor anidado, estoy bien omitiéndome; es decir, {"anidado":{...},"luz":"encendido"}

De acuerdo con los diseños, mostramos solo valores. Entonces, por {"temperature":21.5,"light":"on"} mostraremos [21.5, "on"] . ¿Está bien?

GS decodifica los identificadores de LoRaWAN (EUI en la unión, DevAddr en el enlace ascendente), lo que podría ser interesante mostrar en esta transmisión para filtrar

Podemos mostrar los identificadores para gs.up.receive . Para la solicitud de unión, podemos mostrar los EUI de:

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

Y muestre la dirección de desarrollo para los enlaces ascendentes desde:

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

Entonces, por as.up.data.receive , as.up.data.forward ? ¿Qué pasa con as.down.data.receive y as.down.data.forward ?
Supongo que también queremos mostrar lo mismo para ns.up.data.* .

Sí, si los identificadores están en la carga útil, muéstrelos.

¿Quieres decir en lugar de Device Address y Frame Payload ?

>

sí

De acuerdo con los diseños, mostramos solo valores. Entonces, por {"temperature":21.5,"light":"on"} mostraremos [21.5, "on"] . ¿Está bien?

No, creo que necesitamos llaves aquí. Muchos valores son numéricos, por lo que se vuelve confuso. Además, debido a que se trata de un mapa, no hay un orden fijo (a menos que ordene las claves y tome los valores).

Podemos mostrar los identificadores para gs.up.receive . Para la solicitud de unión, podemos mostrar los EUI de:

Sí, pero no los tenemos en la carga útil, ¿verdad? Esta es la carga útil, por ejemplo:

{
  "@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"
  ]
}

Sí, si los identificadores están en el payload, muéstralos

Podemos los identificadores del campo identifiers del evento si la carga útil está vacía:

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

No, creo que necesitamos llaves aquí. Muchos valores son numéricos, por lo que se vuelve confuso. Además, debido a que se trata de un mapa, no hay un orden fijo (a menos que ordene las claves y tome los valores).

👌

Sí, pero no los tenemos en la carga útil, ¿verdad? Esta es la carga útil, por ejemplo:

Esto es lo que tengo 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, sí, muéstrales. Actualmente pueden ser nil , así que tenga en cuenta eso, pero podemos cambiar GS para decodificar la carga útil si eso aún no sucedió.

@johanstokking

Únase al flujo con eui donde join_request_payload está disponible:

Enlace ascendente con carga útil decodificada:

Evento fallido:

AS eventos de enlace ascendente/descendente:

Evento de solicitud de unión de puerta de enlace:

Enlace ascendente de la puerta de enlace con mac_payload :

Impresionante

Una petición más; agregue FPort antes de cada ocurrencia de FRMPayload

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