Lorawan-stack: 在控制台流量视图中显示加入请求、上行链路和错误

感谢您添加此内容，这是“必须拥有”
这是我们在 AWS 市场上评估 v3 时首先注意到的事情之一。
不好意思问一下，知道什么时候吗？

@industrialinternet感谢您的关注。 它设定在二月份的里程碑，所以我们的目标是在这个月完成它。 请订阅此问题并观看此存储库，至少对于发布，通过单击顶部的观看，以便您知道它何时登陆哪个发布。

@johanstokking

考虑 as.up.forward 事件主体：

我猜你的意思是这里的as.up.data.forward ？

1. 我们是否可以假设您提到的字段对于每种事件类型总是存在（如果事件操作成功）？
2. 事件小部件组件（实体概览页面之一）中应包含哪些字段？
   
3. decoded_payload对象可以有多大？ 询问，因为它可能在事件 ui 中被截断。

我猜你的意思是这里的as.up.data.forward ？

啊确实，我们将它们分成as.up.join.forward和as.up.data.forward ，并且我提到的所有下行链路事件都没有转发（还）。

1. 我们是否可以假设您提到的字段对于每种事件类型总是存在（如果事件操作成功）？

• frm_payload总是在as.up.data.forward中，但decoded_payload是可选的
• 设备标识符总是在as.up.join.forward

2. 事件小部件组件（实体概览页面之一）中应包含哪些字段？

如果我们的空间较小，您的意思是？ 我认为对于数据上行链路解码的有效载荷，并且对于加入接受 DevEUI。

1. decoded_payload对象可以有多大？ 询问，因为它可能在事件 ui 中被截断。

在行中截断它很好。 如果您展开该行，它应该显示为 JSON。 它实际上可以变得相当大，这取决于设备制造商或应用程序开发人员。

但大多数就像{"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

在此处更新了原始评论

嗨，约翰和其他参与此事的人

很高兴听到你们二月份有一个“里程碑”。
正如我们看到它评估 V​​3 控制台时，我认为可以通过简单的方法来为开发人员制作出色的产品。 和行政

1) 可以单独向整个应用程序或节点发送下行链路
2) 能够看到上行有效载荷 HEX 并在单独的窗口中解码
3) 应用程序目录 fx 的某种层次结构。 父/子/节点

即使我们计划使用连接到我们自己的服务器的 TTI，这也会为研发和监控提供极好的补充

无论如何-到目前为止，伙计的工作做得很好:-)

BR
/一个

重要性顺序；

1. 加入请求中ids.join_eui 、 ids.dev_eui和ids.dev_addr的十六进制显示，上行链路消息中的ids.dev_addr和uplink_message.frm_payload
2. 格式化的错误信息（即填写属性）
3. 显示解码的有效负载 JSON

只是为了澄清事情。

• 加入流程如下：

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   这在控制台中有以下视图：

注意标识符的顺序： join_eui 、 dev_eui和dev_addr

上行流程如下：

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

这在控制台中有以下视图：

注意标识符的顺序： dev_addr和frm_payload 。 我认为我们还可以为上行链路流中的其余事件显示dev_addr 。

我在这里看到的问题是我们实际上并没有太多空间，尤其是对于连接流中的as.up.join.forward事件。 此外，仅值并不能真正提供太多信息，并且添加标签（ Dev Addr: .... ）会留下更少的空间。

• 关于错误。 确实，我们可以只取最深的原因并填写属性，例如

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

我们可以展示

或者对于失败的加入请求（ ns.up.join.drop ）：

请注意，我们在有效负载检查器中保留了原始的未格式化错误。 这可能有助于调试。

• 显示解码的有效载荷 - 供以后使用

@johanstokking @kschiffer有什么建议吗？

伟大的第一步！

注意标识符的顺序： join_eui 、 dev_eui和dev_addr

一些评论/问题：

1. 我们可以为dev_addr设置一列，并为所有上行链路消息填写该列并加入接受吗？
2. 我会在 JoinEUI 和 DevEUI 前面加上JoinEUI和DevEUI这样的小文本，以便用户知道哪个是哪个
3. 显示我们知道的每条消息的标识符，因此对于许多行来说，这可能是相同的标识符（JS/NS/AS）。 这是因为我们稍后会为事件添加过滤，并且在某些集群中，并非所有组件都可用（例如 JS-only），我们仍然希望看到标识符

注意标识符的顺序： dev_addr和frm_payload 。

很好，这里也加上FRMPayload

我认为我们还可以为上行链路流中的其余事件显示dev_addr 。

是的，这就是上面的第 1 点。 我同意这一点。

我在这里看到的问题是我们实际上并没有太多空间，尤其是对于连接流中的as.up.join.forward事件。 此外，仅值并不能真正提供太多信息，并且添加标签（ Dev Addr: .... ）会留下更少的空间。

我宁愿将“转发数据上行消息”文本变成一个图标（或图标；AS + uplink + data），而不是删除信息以保留事件文本。 如果我们同意，我们可以要求@pierrephz设计图标。 抄送@kschiffer

请注意，我们在有效负载检查器中保留了原始的未格式化错误。 这可能有助于调试。

同意错误

几个想法：

• 在单个实体（终端设备、网关）的数据视图中，我们可以删除Entity ID列，因为它是多余的
• 否则，让我们再缩小Entity ID列
• 对于不同的事件，我们需要更细粒度的图标，尤其是与连接过程相关的事件（在材质图标库中找到合适的图标可能会变得越来越困难，因此我们可能需要尽快构建自己的图标集 cc @pierrephz )
  
  
  
  • 加入相关活动，我们暂时可以使用link图标
  
  
• 我们应该在（非小部件）事件组件中使用水平滚动
• 一些事件类型的消息（据我所知）不必要地冗长，例如receive uplinke data message ，它不能只是receive uplink data吗？
• 使用<SafeInspector />的更窄版本以确保行高保持一致
• 将frm_payload通过当前的有效载荷格式函数进行管道传输并将结果显示为单行 JSON（参见屏幕设计）会很棒。 暂时把这当成镀金就好了。

我们可以为 dev_addr 设置一列，并为所有上行链路消息填充它并接受发生的加入吗？

让我们将它作为一个松散的元素添加到Data列中。

我会在 JoinEUI 和 DevEUI 前面加上一个像 JoinEUI 和 DevEUI 这样的小文本，以便用户知道哪个是哪个

是的。 @bafonins ，这实际上是我在松弛时的意思。 很抱歉那里不够清楚。

我宁愿将“转发数据上行消息”文本变成一个图标（或图标；AS + uplink + data）。

“一条文字说一千多个图标”😅。 我真的很想将事件类型列保留为文本。 仅通过图标来传达其内容是不可能的。

这里有两个屏幕设计，展示了我认为适用于应用程序和设备层的可行解决方案。

在单个实体（终端设备、网关）的数据视图中，我们可以删除实体 ID 列，因为它是多余的

👍 有道理

对于不同的事件，我们需要更细粒度的图标，特别是这里，与加入过程相关的事件

不仅适用于加入流程。 最好有一个 MAC 命令的自定义图标（ ns.mac.* ）。

一些事件类型的消息（据我所知）不必要地冗长，例如接收上行链路数据消息，它不能只是接收上行链路数据吗？

同意，这只是重命名几个错误描述的问题。 它可能是receive uplink data或receive uplink message 。 @johanstokking你怎么看？

将 frm_payload 通过当前的有效负载格式函数进行管道传输并将结果显示为单行 JSON（参见屏幕设计）会很棒。

我们可以直接显示decoded_payload ，对吧？ 上行消息的ApplicationUp的结构是：

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

我会在 JoinEUI 和 DevEUI 前面加上一个像 JoinEUI 和 DevEUI 这样的小文本，以便用户知道哪个是哪个

是的。 @bafonins ，这实际上是我在松弛时的意思。 很抱歉那里不够清楚。

👌

不仅适用于加入流程。 最好有一个 MAC 命令的自定义图标 (ns.mac.*)。

的确。

我们可以直接显示decoded_pa​​yload，对吧？ 上行消息的ApplicationUp结构为：

哦，当然🤦‍♂

• 例如receive uplinke data message ，不能只是receive uplink data吗？

是的。 但是我们可以有一个“接收”、“转发”和“发送”等图标吗？

我真的很想将事件类型列保留为文本。 仅通过图标来传达其内容是不可能的。

不仅如此，而且就像你建议的那样，我们可以用图标替换一些明显的东西，对吧？

我们可以为 dev_addr 设置一列，并为所有上行链路消息填充它并接受发生的加入吗？

让我们将其作为松散元素添加到Data列中。

问题是这是 _every_ 上游消息的一部分，包括设备激活（我们可以在其中显示新的DevAddr ）。 所以在你的第一个设计中， DevAddr没有对齐（它在右边），因为它是松散的，我猜？

除此之外，这些设计看起来真的很好而且很有帮助

是的。 但是我们可以有一个“接收”、“转发”和“发送”等图标吗？

我认为我们要么必须一直这样做，要么根本不这样做。 我认为只用图标替换一些东西会更令人困惑。

我仍然需要考虑按项目表示事件类型的最佳方式。 据我所知，共有三层：堆栈组件、流程或主题和步骤（例如ns.up.data.forward ）。
由于实际上不可能将所有这些信息转换为一个图标，因此我们需要使用多个图标或始终关注其中一个事件类型层，例如主题。

使用三个图标可能是一种方法，但话又说回来，我真的不想替换事件类型文本，因此它不会真正帮助解决间距问题，但至少会使事件条目更易于扫描。

问题是这是每个上游消息的一部分，包括设备激活（我们可以在其中显示新的 DevAddr）。 所以在你的第一个设计中，DevAddr 没有对齐（它在右边），因为它是松散的，我猜？

的确。 但是我们可以简单地将设备地址放在首位作为约定。 如果我们有一个专用列，我们将失去所有其他不需要显示设备地址的事件的空间。

所以我建议保持这个可行：

• 我们暂时不要触摸图标和事件类型消息，而是在单独的 PR 中
• 使用灵活的数据列形式，根据事件类型的具体需求使用松散的元素

@bafonins让我知道您是否需要任何其他信息或澄清以继续解决此问题。

使用三个图标可能是一种方法，但话又说回来，我真的不想替换事件类型文本，因此它不会真正帮助解决间距问题，但至少会使事件条目更易于扫描。

是的，这将是主要目标。

当我们这样做时，我们可能还想考虑按相关 ID 进行分组。 这将使两个间距（垂直）更容易扫描。

的确。 但是我们可以简单地将设备地址放在首位作为约定。 如果我们有一个专用列，我们将失去所有其他不需要显示设备地址的事件的空间。

行

一些更新：

1. 我们不显示设备、网关和组织事件的Entity ID列。 仅适用于应用程序。 这有助于节省一些额外的空间，尤其是对于设备。
2. 错误事件：

1. 我们显示decoded_payload如果可以作为简单的值列表。 跳过任何嵌套条目，如数组或对象（我将跟进为有效负载值添加颜色的实现）。 我们还将frm_payload显示为可用的十六进制：

1. 以下是连接流程的示例：
   （应用事件视图）

（设备事件视图）

1. 对于 AS 下行链路事件，以十六进制显示frm_payload 。 这可能有助于人们通过控制台安排下行链路：

@johanstokking还有别的吗？ 我们可以为网关事件显示任何条目（例如，对于gs.up.receive ，我们可以显示frm_payload f_cnt f_port ）？

伟大的！

一些小的评论/问题；

• 对于 AS 上游事件，还包括DevAddr
• 现在显示活动名称吗？
• 我会使用 LoRaWAN 术语DevAddr和FRMPayload
• 解码后的有效载荷通常是一个平面对象； {"temperature":21.5,"light":"on"}等。如果有嵌套值，我可以跳过它； 即{"nested":{...},"light":"on"}

专门针对 GS 上游事件；

• 目前我们不解码 LoRaWAN raw_payload ，因为 GS 与 LoRaWAN 没有（太多）关系。 GS 确实解码了 LoRaWAN 标识符（加入时的 EUI，上行链路上的 DevAddr），在此流中显示以进行过滤可能会很有趣。 潜在的解决方案：
  
  
  
  • 〜穷人的解决方案； 把它留给观众（控制台）。 这也是我们在 V2 Console 中所做的。 不太理想，因为它在 Console 中添加了 LoRaWAN 逻辑~
  
  
  • 〜以某种方式连接事件有效负载中的标识符。 目前我们正在发布UplinkMessage ，它应该变成像DeviceUplinkMessage这样嵌入UplinkMessage的东西~
  
  
  • 解码有效载荷，如果前端还没有这样做（基本站这样做是因为它重建了 PHYPayload）
  
  
• 目前，如果 GS 转发表中有多个主机，即 NS 和 Packet Broker，我们将发布多个转发事件。 gs.up.forward的事件有效负载是nil 。 我们可以用主机名定义一个新的 proto 消息，我们可以传递一个map[string]string{}

~ @htdvisser请就事件有效负载问题提出建议； 这不在开发指南中。~

@johanstokking

对于 AS 上游事件，还包括 DevAddr

那么，对于as.up.data.receive ， as.up.data.forward ？ as.down.data.receive和as.down.data.forward呢？
我想我们也想为ns.up.data.*显示相同的内容。

现在显示活动名称吗？

不，我们将像现在一样显示完整的事件描述。

我会使用 LoRaWAN 术语 DevAddr 和 FRMPayload

您的意思不是Device Address和Frame Payload吗？

解码后的有效载荷通常是一个平面对象； {"temperature":21.5,"light":"on"} 等。如果有嵌套值，我可以跳过它； 即 {"nested":{...},"light":"on"}

根据设计，我们只显示值。 因此，对于{"temperature":21.5,"light":"on"} ，我们将显示[21.5, "on"] 。 这样好吗？

GS 确实解码了 LoRaWAN 标识符（加入时的 EUI，上行链路上的 DevAddr），在此流中显示以进行过滤可能会很有趣

我们可以显示gs.up.receive的标识符。 对于加入请求，我们可以显示 EUI 来自：

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

并显示来自以下地址的上行链路的 dev addr：

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

那么，对于as.up.data.receive ， as.up.data.forward ？ as.down.data.receive和as.down.data.forward呢？
我想我们也想为ns.up.data.*显示相同的内容。

是的，如果标识符在有效负载中，请显示它们。

您的意思不是Device Address和Frame Payload吗？

>

是的

根据设计，我们只显示值。 因此，对于{"temperature":21.5,"light":"on"} ，我们将显示[21.5, "on"] 。 这样好吗？

不，我认为我们需要这里的钥匙。 很多值都是数字的，因此变得混乱。 同样因为这是一张地图，所以没有固定的顺序（除非您对键进行排序并获取值）。

我们可以显示gs.up.receive的标识符。 对于加入请求，我们可以显示 EUI 来自：

是的，但我们在有效载荷中没有它们，对吧？ 这是有效载荷，例如：

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

是的，如果标识符在有效载荷中，显示它们

如果有效负载为空，我们可以从事件的identifiers字段中获取标识符：

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

不，我认为我们需要这里的钥匙。 很多值都是数字的，因此变得混乱。 同样因为这是一张地图，所以没有固定的顺序（除非您对键进行排序并获取值）。

👌

是的，但我们在有效载荷中没有它们，对吧？ 这是有效载荷，例如：

这是我为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"
  ]
}

好的，是的，给他们看。 目前它们可以是nil ，因此请考虑到这一点，但如果还没有发生，我们可以更改 GS 以解码有效负载。

@johanstokking

在join_request_payload可用的地方加入 eui 流：

带解码有效载荷的上行链路：

失败事件：

AS 上行/下行事件：

网关加入请求事件：

带有mac_payload的网关上行链路：

惊人的

又一个要求； 请在每次出现FRMPayload FPort #$

由https://github.com/TheThingsNetwork/lorawan-stack/pull/2477关闭