Lorawan-stack: Letzte Uplink-Nachricht und Up- & Downlink-Fcount anzeigen

Ich bin mir nicht sicher, ob dies dasselbe ist, aber es wäre sehr hilfreich, die session des NS auf Existenz, Aktivierungsdatum/-zeit und möglicherweise Frame-Zähler zu überprüfen.

@rvolosatovs behalten wir einen "zuletzt gesehenen" Zeitstempel in NS?

@rvolosatovs behalten wir einen "zuletzt gesehenen" Zeitstempel in NS?

Nein, aber es kann von RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt ) abgeleitet werden

@rvolosatovs behalten wir einen "zuletzt gesehenen" Zeitstempel in NS?

Nein, aber es kann von RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt ) abgeleitet werden

Das habe ich getan, aber ich dachte mir, dass wir uns für die vollständige Funktionalität in den Event-Stream einklinken müssten, um die Zahlen in Echtzeit auf dem neuesten Stand zu halten.

Das habe ich getan, aber ich dachte mir, dass wir uns für die vollständige Funktionalität in den Event-Stream einklinken müssten, um die Zahlen in Echtzeit auf dem neuesten Stand zu halten.

Bevor ich fortfahre und es auf diese Weise umsetze, @htdvisser , denkst du, dass dieser Ansatz gründlich genug ist? Die Uplink-Downlink-Ereignisse enthalten nicht die aktuelle Frameanzahl, daher müsste ich sie basierend auf dem Anfangswert erhöhen, den ich von der Sitzungsstütze im Endgerät erhalten habe.

Das ist nicht der richtige Weg, fürchte ich.

Schicken wir die Bildzähler nicht mit? Das wäre dann das eigentliche Problem.

@rvolosatovs behalten wir einen "zuletzt gesehenen" Zeitstempel in NS?

Nein, aber es kann von RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt ) abgeleitet werden

Das habe ich getan, aber ich dachte mir, dass wir uns für die vollständige Funktionalität in den Event-Stream einklinken müssten, um die Zahlen in Echtzeit auf dem neuesten Stand zu halten.

Leider ist es nicht so einfach, wie es auf den ersten Blick scheint.

1. (ABP) Gerät, für das ResetsFCnt==true FCnt selbst zurücksetzen kann
2. (OTAA) Das Gerät kann sich wieder anschließen, was an sich die FCnt noch nicht zurücksetzen soll – FCnt wird entweder zurückgesetzt oder erhöht, abhängig von der Sitzungsschlüssel-ID, die im nächsten empfangenen Daten-Uplink verwendet wird
3. Der FCnt -Wert in der Uplink-Nutzlast ist nicht unbedingt das tatsächliche Gerät FCnt , da im Uplink nur 16 LSB gesendet werden, während die Frame-Zähler 32 Bit breit sein können.

All dies wird von NS (und 2. teilweise von AS) gehandhabt, und ich glaube sicherlich nicht, dass die Konsole das Gleiche tun sollte.

Ich denke, der Weg nach vorne besteht darin, Ereignisse für (1.) - ns.device.reset und (2.) - ns.device.confirm_session (oder vielleicht ns.device.rejoin ?) hinzuzufügen.
Für (3.) müssen wir einen Weg finden, den vollen FCnt an die Konsole zu liefern. Möglicherweise möchten wir ein weiteres Ereignis einführen, z. B. ns.up.data.match oder ns.up.data.handle , das die erfolgreiche Verarbeitung des Uplinks anzeigt und die vollständigen FCnt (und möglicherweise mehr) enthält. Beachten Sie, dass ns.up.data.forward hier nicht verwandt ist und lediglich anzeigt, dass ein Uplink an AS gesendet wird. Es wird derzeit fälschlicherweise auf jedem Uplink veröffentlicht. Es wird jetzt auch nur veröffentlicht, wenn es tatsächlich an das AS weitergeleitet wird (PR eingehend). , enthält die AS-Uplink-Payload nicht die vollständigen FCnt , sondern die im Uplink gesendeten FCnt (also 16 LSB)

Blockiert, bis wir zu einer Schlussfolgerung über NS-Ereignisse kommen, um dies und das in NS zu implementieren.

Ok, ich verstehe, dass dies im Moment tatsächlich nicht machbar ist. Was ist dann mit dem last seen ? Ist es sicher, einen Anfangswert aus der Geräteregistrierung zu erhalten und ihn dann über relevante Geräteereignisse (wie Uplink, bestätigter Downlink usw.) auf dem neuesten Stand zu halten?

Ok, ich verstehe, dass dies im Moment tatsächlich nicht machbar ist. Was ist dann mit dem last seen ? Ist es sicher, einen Anfangswert aus der Geräteregistrierung zu erhalten und ihn dann über relevante Geräteereignisse (wie Uplink, bestätigter Downlink usw.) auf dem neuesten Stand zu halten?

Ja, ns.up.data.receive , ns.up.join.receive , ns.up.rejoin.receive ist das, wonach Sie suchen

~Blockiert durch https://github.com/TheThingsNetwork/lorawan-stack/pull/2221 #2222~

NS veröffentlicht nun das ns.up.data.process Event, das den Uplink mit vollem FCnt als Payload enthält

Bitte verwenden Sie den Wert im Uplink als tatsächlich aktive DevAddr und FCntUp des Geräts

Für Downlinks haben wir derzeit keine ähnliche Funktionalität, aber das ist auch nicht der Schwerpunkt dieser Ausgabe, beginnen wir nur mit dem Uplink FCnt und fügen dann zu einem späteren Zeitpunkt Downlinks hinzu (Beachten Sie, dass wir je nach LoRaWAN-Version möglicherweise tatsächlich 2 verschiedene Downlinks haben Frame-Zähler - einer für NS und einer für AS, daher ist es auch viel weniger trivial, dass der Uplink-Frame-Zähler ebenfalls verwendet wird.)

Wenn wir den letzten Uplink in der Anwendung kennen, ersetzen wir in der Anwendungsansicht (ähnlich wie auf der Gateway-Übersichtsseite) Linked durch Last seen .

Wenn wir den letzten Uplink in der Anwendung kennen, ersetzen wir in der Anwendungsansicht (ähnlich wie auf der Gateway-Übersichtsseite) Linked durch Last seen .

Es wäre auf jeden Fall schön, diese Informationen global für die Anwendung anzuzeigen, aber dies würde bedeuten, dass die Konsole alle mit der Anwendung verbundenen Endgeräte nacheinander prüfen muss, um den anfänglichen zuletzt gesehenen Status anzeigen zu können. Das halte ich für nicht praktikabel, wenn wir von Anwendungen mit potenziell Hunderten oder Tausenden von Endgeräten ausgehen müssen.

Zwei Dinge könnten mir einfallen:

1. Ich könnte die zuletzt gesehenen Informationen anzeigen, sobald sie durch den eingehenden Strom von Gerätenachrichtenereignissen verfügbar werden. Je nach Einrichtung der Anwendung kann es jedoch dazu führen, dass solche Ereignisse nicht zeitnah verfügbar sind (denken Sie an Endgeräte, die stündlich oder seltener Downlinks senden).
2. Wir könnten einen Schwellenwert der Geräteanzahl verwenden, nach dem wir die Berechnung des zuletzt gesehenen Werts zunächst beenden. Wenn eine Anwendung mehr als 100 Geräte hat, ist es auch sehr wahrscheinlich, dass die erforderlichen Geräteereignisse sehr bald nach dem Laden der Anwendungsseite eintreffen.

@htdvisser @rvolosatovs Übersehe ich vielleicht etwas? Können Sie sich alternativ eine Möglichkeit vorstellen, diese Daten zu aggregieren und über einen API-Endpunkt verfügbar zu machen?

ApplicationLinkStats hat nur last_up_received_at und last_downlink_forwarded_at :

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

Geschlossen über #2585