Lorawan-stack: Afficher la demande de jointure, la liaison montante et les erreurs dans la vue du trafic de la console

Merci pour l'ajout c'est un "must have"
C'est l'une des premières choses que nous avons remarquées lors de l'évaluation de la v3 sur le marché AWS.
Désolé de demander, une idée de quand ?

@industrialinternet merci de votre intérêt. Il est défini dans le jalon de février, donc notre objectif est de le terminer ce mois-ci. Veuillez vous abonner à ce numéro et surveiller ce référentiel, au moins pour les versions, en cliquant sur Regarder en haut, afin que vous sachiez quand il atterrit dans quelle version.

@johanstokking

Considérez comme corps d'événement up.forward :

Je suppose que vous voulez dire as.up.data.forward ici ?

1. Pouvons-nous supposer que les champs que vous avez mentionnés sont toujours là (si l'opération d'événement réussit) pour chaque type d'événement ?
2. Quels champs doivent être inclus dans le composant widget des événements (celui des pages de présentation des entités) ?
   
3. Quelle peut être la taille de l'objet decoded_payload ? Demander car il peut être tronqué dans l'interface utilisateur de l'événement.

Je suppose que vous voulez dire as.up.data.forward ici ?

Ah en effet, nous les avons divisés en as.up.join.forward et as.up.data.forward , et tous les événements de liaison descendante que j'ai mentionnés ne sont pas (encore) transmis.

1. Pouvons-nous supposer que les champs que vous avez mentionnés sont toujours là (si l'opération d'événement réussit) pour chaque type d'événement ?

• frm_payload est toujours dans as.up.data.forward , mais decoded_payload est facultatif
• les identifiants d'appareil sont toujours en as.up.join.forward

2. Quels champs doivent être inclus dans le composant widget des événements (celui des pages de présentation des entités) ?

Dans les cas où nous avons moins d'espace tu veux dire ? Je pense que pour la liaison montante de données, la charge utile décodée et pour la jointure accepte le DevEUI.

1. Quelle peut être la taille de l'objet decoded_payload ? Demander car il peut être tronqué dans l'interface utilisateur de l'événement.

Dans la ligne, c'est bien de le tronquer. Si vous développez la ligne, elle doit s'afficher au format JSON. Cela peut devenir assez gros en fait, cela dépend du fabricant de l'appareil ou du développeur de l'application.

Mais la plupart sont comme {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

Mise à jour du commentaire original ici

Salut Johan et les autres personnes impliquées dans cette affaire

Ravi d'apprendre que vous avez un "milstone" pour février.
Comme nous le voyons évaluer la console V3, beaucoup peut être fait ici avec, je pense, des moyens simples pour créer un produit exceptionnel pour le développement. et administrative

1) Possibilité d'envoyer des liens descendants vers l'ensemble de l'application ou du nœud séparément
2) Pouvoir voir la charge utile HEX de liaison montante et décodée dans une fenêtre séparée
3) Une sorte de hiérarchie pour le répertoire d'applications fx. Parent/enfant/nœud

Même si nous prévoyons d'utiliser TTI connecté à nos propres serveurs, cela constituerait un excellent complément pour la R&D et la surveillance.

Quoi qu'il en soit - beau travail jusqu'à présent les gars :-)

BR
/UNE

Ordre d'importance;

1. Affichage hexadécimal de ids.join_eui , ids.dev_eui et ids.dev_addr dans les demandes de jointure, ids.dev_addr et uplink_message.frm_payload pour les messages de liaison montante
2. Messages d'erreur formatés (c'est-à-dire remplir les attributs)
3. Afficher la charge utile décodée JSON

Juste pour clarifier les choses.

• Le flux de jointure se déroule comme suit :

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   Cela a la vue suivante dans la console :

Notez l'ordre des identifiants : join_eui , dev_eui et dev_addr

Le flux de liaison montante se déroule comme suit :

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

Cela a la vue suivante dans la console :

Notez l'ordre des identifiants : dev_addr et frm_payload . Je pense que nous pouvons également afficher les dev_addr pour le reste des événements dans le flux de liaison montante.

Le problème que je vois ici est que nous n'avons pas vraiment beaucoup d'espace, en particulier pour l'événement as.up.join.forward dans le flux de jointure. De plus, seules les valeurs ne donnent pas vraiment beaucoup d'informations et l'ajout d'étiquettes ( Dev Addr: .... ) laisserait encore moins d'espace.

• Concernant les erreurs. En effet, nous pouvons simplement prendre la cause la plus profonde et remplir les attributs, par exemple pour

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

nous pouvons montrer

ou pour une demande de jointure échouée ( ns.up.join.drop ):

Notez que nous conservons l'erreur d'origine non formatée dans l'inspecteur de charge utile. Cela peut être utile pour le débogage.

• Affichage de la charge utile décodée - pour plus tard

@johanstokking @kschiffer des suggestions ici?

Excellents premiers pas !

Notez l'ordre des identifiants : join_eui , dev_eui et dev_addr

Quelques commentaires/questions :

1. Pouvons-nous avoir une colonne pour dev_addr et la remplir pour tous les messages de liaison montante et les acceptations de jointure qui se produisent ?
2. Je ferais précéder JoinEUI et DevEUI d'un petit texte comme JoinEUI et DevEUI pour que les utilisateurs sachent lequel est lequel
3. Afficher les identifiants pour chaque message que nous connaissons, il peut donc s'agir pour plusieurs lignes des mêmes identifiants (JS/NS/AS). En effet, nous ajoutons le filtrage des événements plus tard et dans certains clusters, tous les composants ne sont pas disponibles (comme JS uniquement) et nous voulons toujours voir les identifiants

Notez l'ordre des identifiants : dev_addr et frm_payload .

Bien, également ici préfixer avec FRMPayload

Je pense que nous pouvons également afficher les dev_addr pour le reste des événements dans le flux de liaison montante.

Oui, c'est le point 1 ci-dessus. Je suis d'accord avec ça.

Le problème que je vois ici est que nous n'avons pas vraiment beaucoup d'espace, en particulier pour l'événement as.up.join.forward dans le flux de jointure. De plus, seules les valeurs ne donnent pas vraiment beaucoup d'informations et l'ajout d'étiquettes ( Dev Addr: .... ) laisserait encore moins d'espace.

Je préférerais transformer le texte "message de liaison montante de données de transfert" en une icône (ou des icônes; AS + liaison montante + données), plutôt que de supprimer des informations pour conserver le texte de l'événement. On peut demander à @pierrephz de concevoir des icônes si on est d'accord. cc @kschiffer

Notez que nous conservons l'erreur d'origine non formatée dans l'inspecteur de charge utile. Cela peut être utile pour le débogage.

D'accord sur les erreurs

Quelques pensées :

• Dans les vues de données d'entités individuelles (terminaux, passerelles), nous pouvons supprimer la colonne Entity ID , car elle est redondante
• Sinon, réduisons un peu plus la colonne Entity ID
• Nous avons besoin d'icônes plus fines pour différents événements, en particulier ici, les événements liés à la procédure de jointure (il pourrait devenir de plus en plus difficile de trouver des icônes appropriées dans la bibliothèque d'icônes de matériaux, nous devrons donc peut-être bientôt créer notre propre jeu d'icônes cc @pierrephz )
  
  
  
  • Pour rejoindre les événements liés, nous pouvons utiliser l'icône link pour le moment
  
  
• Nous devrions utiliser le défilement horizontal dans le composant d'événement (non-widget)
• Certains messages de type événement sont (pour autant que je sache) inutilement longs, par exemple receive uplinke data message , ne pourrait-il pas simplement s'agir receive uplink data ?
• Utilisez une version encore plus étroite du <SafeInspector /> pour vous assurer que les hauteurs de ligne restent cohérentes
• Ce serait génial de diriger le frm_payload à travers la fonction de format de charge utile actuelle et d'afficher le résultat sous la forme d'un JSON sur une ligne (voir screendesigns). Je suis d'accord pour considérer cela comme du goldplating pour le moment.

Pouvons-nous avoir une colonne pour dev_addr et la remplir pour tous les messages de liaison montante et les acceptations de jointure qui se produisent ?

Ajoutons cela en tant qu'élément lâche dans la colonne Data .

Je ferais précéder JoinEUI et DevEUI d'un petit texte comme JoinEUI et DevEUI afin que les utilisateurs sachent lequel est lequel

Oui. @bafonins , c'est en fait ce que je voulais dire par slack. Désolé de ne pas avoir été assez clair là.

Je préférerais transformer le texte "message de liaison montante de données de transfert" en une icône (ou des icônes ; AS + liaison montante + données).

"Un texte en dit plus que mille icônes" 😅. Je voudrais vraiment garder la colonne de type d'événement sous forme de texte. Il est impossible de communiquer son contenu uniquement via des icônes.

Voici deux conceptions d'écran qui montrent ce que je pense être une solution viable pour la couche application et périphérique.

Dans les vues de données d'entités individuelles (dispositifs finaux, passerelles), nous pouvons supprimer la colonne ID d'entité, car elle est redondante

👍 a du sens

Nous avons besoin d'icônes plus fines pour différents événements, en particulier ici, les événements liés à la procédure de jointure

Pas seulement pour le flux de jointure. Ce serait bien d'avoir une icône personnalisée pour les commandes MAC ( ns.mac.* ).

Certains messages de type événement sont (pour autant que je sache) inutilement longs, par exemple recevoir un message de données de liaison montante, ne pourrait-il pas simplement s'agir de recevoir des données de liaison montante?

D'accord, il suffit de renommer plusieurs descriptions d'erreurs. Cela pourrait être receive uplink data ou receive uplink message . @johanstokking qu'en pensez-vous?

Ce serait génial de diriger le frm_payload via la fonction de format de charge utile actuelle et d'afficher le résultat sous la forme d'un JSON d'une ligne (voir screendesigns).

Nous pouvons afficher decoded_payload directement, n'est-ce pas ? La structure de ApplicationUp pour les messages de liaison montante est :

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

Je ferais précéder JoinEUI et DevEUI d'un petit texte comme JoinEUI et DevEUI afin que les utilisateurs sachent lequel est lequel

Oui. @bafonins , c'est en fait ce que je voulais dire par slack. Désolé de ne pas avoir été assez clair là.

👌

Pas seulement pour le flux de jointure. Ce serait bien d'avoir une icône personnalisée pour les commandes MAC (ns.mac.*).

En effet.

On peut afficher directement decoded_payload, non ? La structure d'ApplicationUp pour les messages de liaison montante est :

Oh, bien sûr 🤦‍♂

• par exemple receive uplinke data message , ne pourrait-il pas simplement s'agir receive uplink data ?

Oui. Mais pouvons-nous avoir une icône pour "recevoir" vs "transférer" vs "envoyer" etc. ?

Je voudrais vraiment garder la colonne de type d'événement sous forme de texte. Il est impossible de communiquer son contenu uniquement via des icônes.

Pas seulement, mais comme vous l'avez suggéré aussi, nous pouvons remplacer certaines choses évidentes par des icônes, n'est-ce pas ?

Pouvons-nous avoir une colonne pour dev_addr et la remplir pour tous les messages de liaison montante et les acceptations de jointure qui se produisent ?

Ajoutons cela en tant qu'élément lâche dans la colonne Data .

Le fait est que cela fait partie de _tous_ les messages en amont, y compris les activations de périphériques (où nous pouvons afficher le nouveau DevAddr ). Donc, dans votre premier dessin, le DevAddr n'est pas aligné (c'est à droite), parce qu'il est lâche, je suppose ?

En dehors de cela, ces conceptions ont l'air vraiment bonnes et utiles

Oui. Mais pouvons-nous avoir une icône pour "recevoir" vs "transférer" vs "envoyer" etc. ?

Je pense qu'il faudrait soit le faire jusqu'au bout, soit pas du tout. Remplacer seulement certaines choses par des icônes serait plus déroutant, je pense.

Je dois encore réfléchir à la meilleure façon de représenter les types d'événements par des éléments. D'après ce que je vois, il y a trois couches qui sont : composant de pile, processus ou sujet(s) et étape (par exemple ns.up.data.forward ).
Puisqu'il n'est pas vraiment possible de traduire toutes ces informations en une seule icône, nous devons soit utiliser plusieurs icônes, soit toujours nous concentrer sur l'une des couches de type d'événement, comme le sujet.

L'utilisation de trois icônes peut être un moyen, mais encore une fois, je ne voudrais pas vraiment remplacer le texte du type d'événement, donc cela n'aiderait pas vraiment avec le problème d'espacement, mais rendrait au moins les entrées d'événement plus faciles à analyser.

Le fait est que cela fait partie de chaque message en amont, y compris les activations de périphérique (où nous pouvons afficher le nouveau DevAddr). Donc, dans votre premier design, le DevAddr n'est pas aligné (il est à droite), car il est lâche, je suppose ?

En effet. Mais nous pouvons simplement mettre l'adresse de l'appareil toujours en premier par convention. Si nous avions une colonne dédiée, nous perdrions de l'espace pour tous les autres événements qui n'ont pas besoin d'afficher l'adresse de l'appareil.

Donc ma suggestion pour garder cela exploitable:

• Ne touchons pas aux icônes et au message de type événement pour l'instant mais dans un PR séparé
• Utilisez une forme flexible de la colonne de données, avec des éléments lâches basés sur les besoins spécifiques du type d'événement

@bafonins faites-moi savoir si vous avez besoin d'autres informations ou clarifications pour continuer avec ce problème.

L'utilisation de trois icônes peut être un moyen, mais encore une fois, je ne voudrais pas vraiment remplacer le texte du type d'événement, donc cela n'aiderait pas vraiment avec le problème d'espacement, mais rendrait au moins les entrées d'événement plus faciles à analyser.

Oui, ce serait l'objectif principal.

Pendant que nous y sommes, nous pourrions également envisager de regrouper par ID de corrélation. Cela servira à la fois à l'espacement (vertical) et à la numérisation plus facile.

En effet. Mais nous pouvons simplement mettre l'adresse de l'appareil toujours en premier par convention. Si nous avions une colonne dédiée, nous perdrions de l'espace pour tous les autres événements qui n'ont pas besoin d'afficher l'adresse de l'appareil.

d'accord

Quelques mises à jour :

1. Nous n'affichons pas la colonne Entity ID pour les événements d'appareil, de passerelle et d'organisation. Uniquement pour les candidatures. Cela permet d'économiser de l'espace supplémentaire, en particulier pour les appareils.
2. Événement d'erreur :

1. Nous affichons decoded_payload s'il est disponible sous forme de simple liste de valeurs . en sautant toutes les entrées imbriquées comme les tableaux ou les objets (je suivrai avec l'implémentation qui ajoute des couleurs aux valeurs de charge utile). Nous affichons également frm_payload en hexadécimal lorsqu'il est disponible :

1. Voici un exemple de flux de jointure :
   (vue des événements de l'application)

(affichage des événements de l'appareil)

1. Afficher frm_payload en hexadécimal pour les événements de liaison descendante AS. Cela pourrait être utile pour les personnes qui planifient des liaisons descendantes via la console :

@johanstokking Y a-t-il autre chose ? Y a-t-il des entrées que nous pouvons afficher pour les événements de passerelle (pour gs.up.receive , par exemple, nous pouvons afficher frm_payload f_cnt f_port ) ?

Super!

Quelques commentaires/questions mineurs ;

• Pour les événements AS en amont, incluez également le DevAddr
• Les noms des événements s'affichent-ils maintenant ?
• J'utiliserais les termes LoRaWAN DevAddr et FRMPayload
• La charge utile décodée est généralement un objet plat ; {"temperature":21.5,"light":"on"} etc. S'il y a une valeur imbriquée, je vais bien l'ignorer ; c'est-à-dire {"nested":{...},"light":"on"}

Pour les événements GS en amont spécifiquement ;

• Actuellement, nous ne décodons pas le LoRaWAN raw_payload , car GS n'a pas (beaucoup) à voir avec LoRaWAN. GS décode les identifiants LoRaWAN (EUIs on join, DevAddr on uplink), ce qui pourrait être intéressant à montrer dans ce flux pour le filtrage. Solutions potentielles :
  
  
  
  • ~La solution du pauvre ; laissez cela au spectateur (Console). C'est également ce que nous faisons dans la console V2. Ce n'est pas idéal car cela ajoute la logique LoRaWAN à la console ~
  
  
  • ~Câblez d'une manière ou d'une autre les identifiants dans la charge utile de l'événement. Actuellement, nous publions UplinkMessage , qui devrait devenir quelque chose comme DeviceUplinkMessage qui intègre UplinkMessage ~
  
  
  • Décodez la charge utile, si le frontal ne l'a pas déjà fait (Basic Station le fait car il reconstruit PHYPayload)
  
  
• Actuellement, nous publions plusieurs événements de transfert s'il existe plusieurs hôtes dans la table de transfert GS, c'est-à-dire NS et Packet Broker. La charge utile de l'événement pour gs.up.forward est nil . Nous pouvons définir un nouveau message proto avec le nom d'hôte et nous pouvons passer un map[string]string{}

~ @htdvisser , veuillez donner des conseils sur les questions de charge utile de l'événement ; ceci n'est pas couvert par les directives de développement.~

@johanstokking

Pour les événements AS en amont, incluez également le DevAddr

Donc, pour as.up.data.receive , as.up.data.forward ? Qu'en est-il de as.down.data.receive et as.down.data.forward ?
Je suppose que nous voulons également montrer la même chose pour ns.up.data.* .

Les noms des événements s'affichent-ils maintenant ?

Non, nous afficherons la description complète de l'événement telle qu'elle est actuellement.

J'utiliserais les termes LoRaWAN DevAddr et FRMPayload

Vous voulez dire au lieu de Device Address et Frame Payload ?

La charge utile décodée est généralement un objet plat ; {"temperature":21.5,"light":"on"} etc. S'il y a une valeur imbriquée, je vais bien l'ignorer ; c'est-à-dire {"imbriqué":{...},"light":"on"}

Selon les conceptions, nous ne montrons que des valeurs. Donc, pour {"temperature":21.5,"light":"on"} nous montrerons [21.5, "on"] . Est-ce bien?

GS décode les identifiants LoRaWAN (EUIs on join, DevAddr on uplink), ce qui pourrait être intéressant à montrer dans ce flux pour le filtrage

Nous pouvons afficher les identifiants pour gs.up.receive . Pour une demande d'adhésion, nous pouvons afficher les EUI de :

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

Et affichez l'adresse de développement pour les liaisons montantes à partir de :

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

Donc, pour as.up.data.receive , as.up.data.forward ? Qu'en est-il de as.down.data.receive et as.down.data.forward ?
Je suppose que nous voulons également montrer la même chose pour ns.up.data.* .

Oui, si les identifiants sont dans la charge utile, affichez-les.

Vous voulez dire au lieu de Device Address et Frame Payload ?

>

Oui

Selon les conceptions, nous ne montrons que des valeurs. Donc, pour {"temperature":21.5,"light":"on"} nous montrerons [21.5, "on"] . Est-ce bien?

Non, je pense que nous avons besoin de clés ici. Beaucoup de valeurs sont numériques, ce qui devient déroutant. De plus, comme il s'agit d'une carte, il n'y a pas d'ordre fixe (sauf si vous triez les clés et prenez les valeurs).

Nous pouvons afficher les identifiants pour gs.up.receive . Pour une demande d'adhésion, nous pouvons afficher les EUI de :

Oui, mais nous ne les avons pas dans la charge utile, n'est-ce pas ? Voici la charge utile par exemple :

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

Oui, si les identifiants sont dans la charge utile, affichez-les

Nous pouvons récupérer les identifiants du champ identifiers de l'événement si la charge utile est vide :

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

Non, je pense que nous avons besoin de clés ici. Beaucoup de valeurs sont numériques, ce qui devient déroutant. De plus, comme il s'agit d'une carte, il n'y a pas d'ordre fixe (sauf si vous triez les clés et prenez les valeurs).

👌

Oui, mais nous ne les avons pas dans la charge utile, n'est-ce pas ? Voici la charge utile par exemple :

Voici ce que j'ai pour 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, oui, montrez-leur. Actuellement, ils peuvent être nil , donc tenez compte de cela, mais nous pouvons changer GS pour décoder la charge utile si cela ne s'est pas encore produit.

@johanstokking

Rejoignez le flux avec les eui où join_request_payload est disponible :

Liaison montante avec charge utile décodée :

Échec de l'événement :

Événements de liaison montante/descendante AS :

Événement de demande d'adhésion à la passerelle :

Liaison montante de la passerelle avec mac_payload :

Impressionnant

Une autre demande ; veuillez ajouter FPort avant chaque occurrence de FRMPayload

Fermé par https://github.com/TheThingsNetwork/lorawan-stack/pull/2477