Lorawan-stack: Показать последнее сообщение восходящей линии связи и fcount восходящей и нисходящей линии связи

Я не уверен, что это то же самое, но быстрая проверка существования session NS, даты/времени активации и, возможно, счетчиков кадров была бы очень полезной.

@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 должно либо сбрасываться, либо увеличиваться в зависимости от идентификатора сеансового ключа, используемого в следующем полученном восходящем канале данных.
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 содержит не полные 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