Lorawan-stack: Afficher le dernier message de liaison montante et le nombre de liaisons montantes et descendantes

Je ne sais pas si c'est la même chose, mais vérifier rapidement l'existence du session du NS, la date/heure d'activation et éventuellement les compteurs de trames serait très utile.

@rvolosatovs gardons -nous un horodatage "dernière vue" en NS ?

@rvolosatovs gardons -nous un horodatage "dernière vue" en NS ?

Non, mais il peut être dérivé de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

@rvolosatovs gardons -nous un horodatage "dernière vue" en NS ?

Non, mais il peut être dérivé de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

C'est ce que j'ai fait, mais j'ai pensé que pour la fonctionnalité complète, nous aurions besoin de nous connecter au flux d'événements pour maintenir les chiffres à jour en temps réel.

C'est ce que j'ai fait, mais j'ai pensé que pour la fonctionnalité complète, nous aurions besoin de nous connecter au flux d'événements pour maintenir les chiffres à jour en temps réel.

Avant d'aller de l'avant et de l'implémenter de cette façon, @htdvisser pensez-vous que cette approche est suffisamment approfondie ? Les événements de liaison montante de liaison descendante ne contiennent pas le nombre d'images actuel, je devrais donc les incrémenter en fonction de la valeur initiale que j'ai obtenue de la prop de session à l'intérieur du périphérique final.

Ce n'est pas la voie à suivre, j'en ai peur.

N'envoyons-nous pas les compteurs de trames ? Ce serait alors le vrai problème.

@rvolosatovs gardons -nous un horodatage "dernière vue" en NS ?

Non, mais il peut être dérivé de RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

C'est ce que j'ai fait, mais j'ai pensé que pour la fonctionnalité complète, nous aurions besoin de nous connecter au flux d'événements pour maintenir les chiffres à jour en temps réel.

Malheureusement, ce n'est pas aussi simple qu'il y paraît à première vue.

1. (ABP) Appareil, pour lequel ResetsFCnt==true peut réinitialiser lui-même FCnt
2. (OTAA) L'appareil peut rejoindre, ce qui en soi ne réinitialisera pas encore le FCnt - FCnt sera soit réinitialisé, soit augmenté en fonction de l'ID de clé de session utilisé dans la prochaine liaison montante de données reçue
3. La FCnt dans la charge utile de la liaison montante n'est pas nécessairement le périphérique réel FCnt , car seuls 16 LSB sont envoyés dans la liaison montante, tandis que les compteurs de trames peuvent avoir une largeur de 32 bits.

Tout cela est géré par NS (et 2. en partie par AS), et je ne pense certainement pas que la console fera de même.

Je pense que la voie à suivre consiste à ajouter des événements pour (1.) - ns.device.reset et (2.) - ns.device.confirm_session (ou peut-être ns.device.rejoin ?).
Pour (3.), nous devons trouver un moyen de fournir la valeur totale FCnt à la console. Nous pouvons vouloir introduire un autre événement, par exemple ns.up.data.match , ou ns.up.data.handle qui indique un traitement réussi de la liaison montante et inclut FCnt complet (et éventuellement plus). Notez que ns.up.data.forward n'est pas lié ici et indique simplement que la liaison montante est envoyée à l'AS, il est actuellement publié par erreur sur chaque liaison montante, il ne sera désormais publié que lorsqu'il sera réellement transmis à l'AS (PR entrant), également , la charge utile de la liaison montante AS ne contient pas le FCnt complet, mais le FCnt envoyé dans la liaison montante (donc, 16 LSB)

Bloqué jusqu'à ce que nous arrivions à une conclusion sur les événements NS pour conduire ceci et cela est mis en œuvre dans NS.

Ok je comprends que ce n'est effectivement pas faisable pour le moment. Qu'en est-il de la last seen alors. Est-il préférable d'obtenir une valeur initiale à partir du registre de l'appareil, puis de la maintenir à jour via les événements pertinents de l'appareil (comme la liaison montante, la liaison descendante confirmée, etc.) ?

Ok je comprends que ce n'est effectivement pas faisable pour le moment. Qu'en est-il de la last seen alors. Est-il préférable d'obtenir une valeur initiale à partir du registre de l'appareil, puis de la maintenir à jour via les événements pertinents de l'appareil (comme la liaison montante, la liaison descendante confirmée, etc.) ?

Oui, ns.up.data.receive , ns.up.join.receive , ns.up.rejoin.receive est ce que vous cherchez

~Bloqué par https://github.com/TheThingsNetwork/lorawan-stack/pull/2221 #2222~

NS publie maintenant l'événement ns.up.data.process , qui contient la liaison montante avec FCnt complet comme charge utile

Veuillez utiliser la valeur dans la liaison montante comme active réelle DevAddr et FCntUp de l'appareil

Pour les liaisons descendantes, nous n'avons actuellement pas de fonctionnalité similaire, mais ce n'est pas non plus l'objet de ce problème, commençons par la liaison montante FCnt, puis ajoutons des liaisons descendantes à un stade ultérieur (notez que, selon la version de LoRaWAN, nous pouvons en fait avoir 2 liaisons descendantes distinctes compteurs de trames - un pour NS et un pour AS, il est donc beaucoup moins trivial que le compteur de trames de liaison montante également.)

Lorsque nous connaissons la dernière liaison montante dans l'application, remplaçons Linked par Last seen dans la vue de l'application (similaire à la page de présentation de la passerelle).

Lorsque nous connaissons la dernière liaison montante dans l'application, remplaçons Linked par Last seen dans la vue de l'application (similaire à la page de présentation de la passerelle).

Ce serait certainement bien de montrer ces informations globalement pour l'application, mais cela signifierait que la console doit sonder tous les périphériques finaux associés à l'application l'un après l'autre, pour pouvoir afficher le dernier état vu initial. Je ne pense pas que ce soit viable lorsque nous devons assumer des applications avec potentiellement des centaines ou des milliers d'appareils finaux.

Deux choses auxquelles je pourrais penser :

1. Je pourrais afficher les dernières informations vues au fur et à mesure qu'elles sont disponibles via le flux entrant d'événements de message de l'appareil. Selon la configuration de l'application, cela pourrait toutefois signifier qu'il n'y aura pas de tels événements disponibles en temps opportun (pensez aux appareils finaux qui envoient des liaisons descendantes toutes les heures ou moins fréquemment).
2. Nous pourrions utiliser un seuil du nombre d'appareils après lequel nous arrêtons initialement de calculer la dernière valeur vue. Si une application a plus de 100 appareils, il est également très probable que les événements d'appareil nécessaires arrivent très peu de temps après le chargement de la page de l'application.

@htdvisser @rvolosatovs Est-ce que j'oublie peut-être quelque chose ? Sinon, pouvez-vous penser à un moyen d'agréger ces données et de les rendre disponibles via un point de terminaison API ?

ApplicationLinkStats a juste un last_up_received_at et last_downlink_forwarded_at :

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

Fermé via #2585