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

Спасибо, что добавили это, это "должно быть"
Это была одна из первых вещей, которую мы заметили при оценке версии 3 на рынке AWS.
Извините, что спрашиваю, есть идеи, когда?

@industrialinternet спасибо за проявленный интерес. Он установлен в февральском рубеже, поэтому наша цель — закончить его в этом месяце. Пожалуйста, подпишитесь на этот выпуск и следите за этим репозиторием, по крайней мере, за выпусками, нажав «Смотреть» вверху, чтобы вы знали, когда он попадет в какой выпуск.

@johanstokking

Рассмотрим тела событий .up.forward:

Я думаю, вы имеете в виду as.up.data.forward здесь?

1. Можем ли мы предположить, что указанные вами поля всегда присутствуют (если операция события прошла успешно) для каждого типа события?
2. Какие поля должны быть включены в компонент виджета событий (одна из страниц обзора объекта)?
   
3. Насколько большим может быть объект decoded_payload ? Спрашиваю, потому что это может быть усечено в пользовательском интерфейсе события.

Я думаю, вы имеете в виду 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 ? Спрашиваю, потому что это может быть усечено в пользовательском интерфейсе события.

В строке можно обрезать его. Если вы развернете строку, она должна отображаться как JSON. На самом деле он может стать довольно большим, это зависит от производителя устройства или разработчика приложения.

Но большинство похоже {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

Обновлен оригинальный комментарий здесь

Привет, Йохан и другие, причастные к этому вопросу.

Приятно слышать, что у вас, ребята, есть "веха" на февраль.
Как мы видим, оценивая консоль V3, многое можно сделать здесь с помощью простых средств, чтобы создать выдающийся продукт для разработчиков. и администрация

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), а мы все еще хотим видеть идентификаторы.

Обратите внимание на порядок идентификаторов: dev_addr и frm_payload .

Хорошо, здесь тоже нужно добавить FRMPayload

Я думаю, что мы можем также показать dev_addr для остальных событий в восходящем потоке.

Да, это пункт 1 выше. Я согласен с этим.

Проблема, которую я здесь вижу, заключается в том, что у нас на самом деле не так много места, особенно для события as.up.join.forward в потоке соединения. Более того, просто значения на самом деле не дают много информации, а добавление меток ( Dev Addr: .... ) оставит еще меньше места.

Я бы предпочел превратить текст «сообщение восходящей линии связи для пересылки данных» в значок (или значки; AS + восходящая линия связи + данные), а не удалять информацию, чтобы сохранить текст события. Мы можем попросить @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 , на самом деле это то, что я имел в виду в slack. Извините, что не достаточно ясно выразился.

Я бы предпочел превратить текст «сообщение восходящей линии связи для пересылки данных» в значок (или значки; AS + восходящая линия связи + данные).

«Текст говорит больше, чем тысяча иконок» 😅. Я действительно хотел бы сохранить столбец типа события в виде текста. Невозможно передать его содержимое исключительно с помощью значков.

Вот два дизайна экрана, которые показывают то, что я считаю жизнеспособным решением для уровня приложений и устройств.

В представлениях данных отдельных объектов (конечные устройства, шлюзы) мы можем удалить столбец Entity 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 , на самом деле это то, что я имел в виду в slack. Извините, что не достаточно ясно выразился.

👌

Не только для потока соединений. Было бы неплохо иметь собственную иконку для команд MAC (ns.mac.*).

Верно.

Мы можем отображать decoded_payload напрямую, верно? Структура ApplicationUp для восходящих сообщений:

О, конечно 🤦‍♂

• например receive uplinke data message , разве это не может быть просто receive uplink data ?

да. Но можем ли мы иметь значок для «получения», «пересылки» и «отправки» и т. д.?

Я действительно хотел бы сохранить столбец типа события в виде текста. Невозможно передать его содержимое исключительно с помощью значков.

Не только, но, как вы и предложили, мы можем заменить некоторые очевидные вещи значками, верно?

Можем ли мы иметь столбец для dev_addr и заполнять его для всех восходящих сообщений и присоединений, которые происходят?

Давайте добавим это как свободный элемент в столбец Data .

Дело в том, что это часть _каждого_ восходящего сообщения, включая активацию устройства (где мы можем показать новые DevAddr ). Итак, в вашем первом дизайне DevAddr не выровнены (это справа), потому что, я полагаю, они свободны?

Кроме того, эти дизайны выглядят действительно хорошо и полезно.

да. Но можем ли мы иметь значок для «получения», «пересылки» и «отправки» и т. д.?

Я думаю, что мы либо должны делать это полностью, либо не делать вообще. Я думаю, что замена только некоторых вещей иконками была бы более запутанной.

Мне все еще нужно подумать о наилучшем способе представления типов событий по элементам. Из того, что я вижу, есть три уровня: компонент стека, процесс или субъект(ы) и шаг (например, ns.up.data.forward ).
Поскольку на самом деле невозможно перевести всю эту информацию в один значок, нам нужно либо использовать несколько значков, либо всегда фокусироваться на одном из слоев типа события, например на теме.

Использование трех значков могло бы быть способом, но опять же, я бы не хотел заменять текст типа события, поэтому это не помогло бы решить проблему пробелов, но, по крайней мере, облегчило бы сканирование записей событий.

Дело в том, что это часть каждого восходящего сообщения, включая активацию устройства (где мы можем показать новый DevAddr). Итак, в вашем первом дизайне DevAddr не выровнен (он справа), потому что он свободен, я полагаю?

Верно. Но мы можем просто ставить адрес устройства всегда первым по соглашению. Если у нас есть выделенный столбец, мы потеряем место для всех других событий, которым не нужно показывать адрес устройства.

Итак, мое предложение сохранить это действенным:

• Иконки и сообщение о типе события пока не трогаем, а в отдельном PR
• Используйте гибкую форму столбца данных со свободными элементами в зависимости от конкретных потребностей типа события.

@bafonins дайте мне знать, если вам нужна какая-либо другая информация или разъяснения, чтобы продолжить работу над этой проблемой.

Использование трех значков могло бы быть способом, но опять же, я бы не хотел заменять текст типа события, поэтому это не помогло бы решить проблему пробелов, но, по крайней мере, облегчило бы сканирование записей событий.

Да, это будет основная цель.

Пока мы на этом, мы могли бы захотеть также рассмотреть возможность группировки по идентификатору корреляции. Это сделает обслуживание как разносным (вертикальным), так и более легким сканированием.

Верно. Но мы можем просто по соглашению всегда ставить адрес устройства первым. Если у нас есть выделенный столбец, мы потеряем место для всех других событий, которым не нужно показывать адрес устройства.

В ПОРЯДКЕ

Некоторые обновления:

1. Мы не показываем столбец Entity ID для событий устройства, шлюза и организации. Только для приложений. Это помогает сэкономить дополнительное пространство, особенно для устройств.
2. Событие ошибки:

1. Мы показываем decoded_payload , если они доступны в виде простого списка значений . пропуская любые вложенные записи, такие как массивы или объекты (я буду следить за реализацией, которая добавляет цвета к значениям полезной нагрузки). Мы также показываем frm_payload в шестнадцатеричном виде, когда они доступны:

1. Вот пример потока соединения:
   (просмотр событий приложения)

(просмотр событий устройства)

1. Показывать frm_payload в шестнадцатеричном формате для событий нисходящего канала AS. Это может быть полезно для людей, планирующих нисходящие ссылки через консоль:

@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. Это не идеально, потому что добавляет логику LoRaWAN в консоль~
  
  
  • ~ Каким-то образом подключите идентификаторы в полезной нагрузке события. В настоящее время мы публикуем UplinkMessage , который должен стать чем-то вроде DeviceUplinkMessage , который включает UplinkMessage ~
  
  
  • Декодировать полезную нагрузку, если внешний интерфейс еще этого не сделал (Basic Station делает это, потому что реконструирует PHYPayload).
  
  
• В настоящее время мы публикуем несколько событий переадресации, если в таблице переадресации GS есть несколько хостов, то есть NS и Packet Broker. Полезная нагрузка события для gs.up.forward составляет nil . Мы можем определить новое прото-сообщение с именем хоста и передать 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 ?

Декодированная полезная нагрузка обычно представляет собой плоский объект; {"температура":21,5,"свет":"вкл"} и т. д. Если есть вложенное значение, я могу его пропустить; т.е. {"вложенный":{...},"свет":"включен"}

Согласно проектам, мы показываем только значения. Итак, для {"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

Присоединяйтесь к потоку с eui, где доступен join_request_payload :

Восходящий канал с декодированной полезной нагрузкой:

Неудавшееся событие:

События восходящей/нисходящей линии AS:

Событие запроса на присоединение к шлюзу:

Восходящий канал шлюза с mac_payload :

Потрясающий

Еще одна просьба; добавьте FPort перед каждым вхождением FRMPayload

Закрыто https://github.com/TheThingsNetwork/lorawan-stack/pull/2477