Lorawan-stack: 显示最新的上行消息和上行和下行fcount

我不确定这是否相同，但快速检查 NS 的session是否存在、激活日期/时间和可能的帧计数器会非常有帮助。

@rvolosatovs我们是否在 NS 中保留“最后一次看到”的时间戳？

@rvolosatovs我们是否在 NS 中保留“最后一次看到”的时间戳？

不，但它可以从RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

@rvolosatovs我们是否在 NS 中保留“最后一次看到”的时间戳？

不，但它可以从RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

这就是我所做的，但我认为对于完整的功能，我们需要挂钩到事件流以实时更新数字。

这就是我所做的，但我认为对于完整的功能，我们需要挂钩到事件流以实时更新数字。

在我继续以这种方式实施之前， @htdvisser你认为这种方法是否足够彻底？ 上行链路下行链路事件不包含当前帧计数，因此我必须根据从终端设备内的会话道具获得的初始值来增加它们。

恐怕这不是要走的路。

我们不发送帧计数器吗？ 那将是真正的问题。

@rvolosatovs我们是否在 NS 中保留“最后一次看到”的时间戳？

不，但它可以从RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

这就是我所做的，但我认为对于完整的功能，我们需要挂钩到事件流以实时更新数字。

不幸的是，它并不像乍看起来那么简单。

1. (ABP) 设备， ResetsFCnt==true可以自行重置FCnt
2. (OTAA) 设备可能重新加入，它本身不应重置FCnt - FCnt应根据在下一个接收到的数据上行链路中使用的会话密钥 ID 进行重置或增加
3. 上行链路有效载荷中的FCnt值不一定是实际设备FCnt ，因为上行链路中仅发送 16 LSB，而帧计数器可能为 32 位宽。

所有这些都由 NS（和 2. 部分由 AS）处理，我当然不认为控制台应该这样做。

我认为前进的方向是为 (1.) - ns.device.reset和 (2.) - ns.device.confirm_session （或者可能是ns.device.rejoin ？）添加事件。
对于 (3.)，我们需要想办法将完整的FCnt值传递到控制台。 我们可能想要引入另一个事件，例如ns.up.data.match或ns.up.data.handle ，这表明上行链路的成功处理并包括完整的FCnt （可能更多）。 注意，这里ns.up.data.forward是不相关的，只是表示上行发送到AS，目前在每个上行都错误发布，现在只有在实际转发到AS时才会发布（PR传入），也，AS 上行链路有效载荷不包含完整的FCnt ，而是在上行链路中发送的FCnt （因此，16 LSB）

在我们对 NS 事件得出结论以驱动这个和那个在 NS 中实现之前被阻止。

好的，我知道目前这确实不可行。 那么last seen的值呢？ 从设备注册表中获取初始值，然后通过相关设备事件（如上行链路、确认下行链路等）保持更新是否保存？

好的，我知道目前这确实不可行。 那么last seen的值呢？ 从设备注册表中获取初始值，然后通过相关设备事件（如上行链路、确认下行链路等）保持更新是否保存？

是的， ns.up.data.receive ， ns.up.join.receive ， ns.up.rejoin.receive就是你要找的

~被https://github.com/TheThingsNetwork/lorawan-stack/pull/2221 #2222 屏蔽~

NS 现在发布ns.up.data.process事件，其中包含带有完整FCnt作为有效负载的上行链路

请使用上行链路中的值作为设备的实际活跃DevAddr和FCntUp

对于下行链路，我们目前没有类似的功能，但这也不是这个问题的重点，让我们从上行链路 FCnt 开始，然后在稍后阶段添加下行链路（注意，根据 LoRaWAN 版本，我们实际上可能有 2 个不同的下行链路帧计数器 - 一个用于 NS，一个用于 AS，因此上行帧计数器也不那么简单。）

当我们知道应用程序中的最后一个上行链路时，让我们在应用程序视图中将Linked替换为Last seen （类似于网关概览页面）。

当我们知道应用程序中的最后一个上行链路时，让我们在应用程序视图中将Linked替换为Last seen （类似于网关概览页面）。

为应用程序全局显示该信息肯定会很好，但这样做意味着控制台需要一个接一个地探测与应用程序关联的所有终端设备，以便能够显示最初的最后一次看到状态。 当我们必须假设应用程序可能具有数百或数千个终端设备时，我认为这是不可行的。

我能想到的两件事：

1. 我可以显示最后一次看到的信息，因为它可以通过传入的设备消息事件流获得。 然而，根据应用程序的设置，这可能意味着不会及时提供此类事件（想想每小时发送下行链路或不那么频繁的终端设备）。
2. 我们可以使用设备计数的阈值，之后我们最初停止计算最后一次看到的值。 如果一个应用程序有 100 多个设备，那么在加载应用程序页面后，必要的设备事件也很可能很快到达。

@htdvisser @rvolosatovs我可能忽略了什么吗？ 或者，您能想出任何方法来聚合这些数据并通过 API 端点提供这些数据吗？

ApplicationLinkStats只有last_up_received_at和last_downlink_forwarded_at ：

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

通过 #2585 关闭