Lorawan-stack: 콘솔 트래픽 보기에 가입 요청, 업링크 및 오류 표시

"필수품"으로 추가해주셔서 감사합니다.
AWS 시장에서 v3를 평가할 때 가장 먼저 알아차린 것 중 하나였습니다.
물어봐서 죄송합니다. 언제인지 알 수 있나요?

@industrialinternet 관심을 보여주셔서 감사합니다. 2월 마일스톤으로 설정되어 있으므로 이번 달에 완료하는 것이 목표입니다. 이 호를 구독하고 맨 위에 있는 보기를 클릭하여 최소한 릴리스의 경우 이 리포지토리를 시청하여 언제 어떤 릴리스에 도착하는지 알 수 있습니다.

@johanstokking

as.up.forward 이벤트 본문을 고려하십시오.

여기서 as.up.data.forward 말씀하시는 것 같은데요?

1. 언급한 필드가 각 이벤트 유형에 대해 항상 존재한다고 가정할 수 있습니까(이벤트 작업이 성공한 경우)?
2. 이벤트 위젯 구성 요소(엔티티 개요 페이지 중 하나)에는 어떤 필드가 포함되어야 합니까?
   
3. decoded_payload 개체의 크기는 얼마입니까? 이벤트 UI에서 잘릴 수 있기 때문에 묻습니다.

여기서 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 개체의 크기는 얼마입니까? 이벤트 UI에서 잘릴 수 있기 때문에 묻습니다.

줄에서 자르는 것이 좋습니다. 행을 확장하면 JSON으로 표시되어야 합니다. 실제로는 상당히 커질 수 있으며 이는 장치 제조업체나 응용 프로그램 개발자에게 달려 있습니다.

하지만 대부분은 {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5} 입니다.

여기에서 원래 댓글을 업데이트했습니다.

안녕 요한과 이 문제에 관련된 다른 사람들

2월에 "밀스톤"이 있다는 소식을 듣게 되어 반갑습니다.
V3 콘솔을 평가하는 것을 볼 수 있듯이 여기에서 개발자를 위한 뛰어난 제품을 만드는 간단한 방법으로 많은 작업을 수행할 수 있습니다. 및 관리

1) 전체 Application 또는 Node에 개별적으로 하향링크 전송 가능
2) 업링크 페이로드 HEX를 확인하고 별도의 창에서 디코딩 가능
3) 응용 프로그램 디렉토리 fx에 대한 일종의 계층 구조입니다. 부모/자식/노드

자체 서버에 연결된 TTI를 사용하려는 경우에도 R&D 및 모니터링에 탁월한 추가 기능이 될 것입니다.

어쨌든 - 지금까지 잘했습니다. :-)

BR
/ㅏ

중요도 순서

1. 가입 요청에서 ids.join_eui , ids.dev_eui 및 ids.dev_addr , 업링크 메시지에 대해 ids.dev_addr 및 uplink_message.frm_payload 의 16진 표시
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: .... )을 추가하면 더 적은 공간이 남게 됩니다.

이벤트 텍스트를 유지하기 위해 정보를 제거하는 것보다 "forward data uplink message" 텍스트를 아이콘(또는 아이콘, AS + 업링크 + 데이터)으로 바꾸는 것이 좋습니다. 동의하면 @pierrephz 에게 아이콘 디자인을 요청할 수 있습니다. cc @kschiffer

페이로드 검사기에는 형식이 지정되지 않은 원래 오류가 유지됩니다. 이것은 디버깅에 도움이 될 수 있습니다.

오류에 동의

몇 가지 생각:

• 단일 엔터티(최종 장치, 게이트웨이)의 데이터 보기에서 Entity ID 열이 중복되므로 제거할 수 있습니다.
• 그렇지 않으면 Entity ID 열을 조금 더 축소해 보겠습니다.
• 다양한 이벤트, 특히 여기에서 참여 절차와 관련된 이벤트에 대해 더 세분화된 아이콘이 필요합니다(재료 아이콘 라이브러리에서 적절한 아이콘을 찾는 것이 점점 더 어려워질 수 있으므로 곧 자체 아이콘 세트를 구축해야 할 수도 있습니다. cc @pierrephz )
  
  
  
  • 참여 관련 이벤트의 경우 당분간 link 아이콘을 사용할 수 있습니다.
  
  
• (위젯이 아닌) 이벤트 구성 요소에서 가로 스크롤을 사용해야 합니다.
• 일부 이벤트 유형 메시지는 (내가 말할 수 있는 한) 불필요하게 길다, 예를 들어 receive uplinke data message , 그냥 receive uplink data 하면 안 됩니까?
• <SafeInspector /> 의 더 좁은 버전을 사용하여 의 행 높이가 일관되게 유지되도록 하십시오.
• 현재 페이로드 형식 함수를 통해 frm_payload 를 파이프하고 결과를 한 줄 JSON으로 표시하는 것은 굉장할 것입니다(screendesigns 참조). 당분간은 금도금이라고 생각해도 괜찮습니다.

dev_addr에 대한 열이 있고 발생하는 모든 업링크 메시지 및 가입 수락에 대해 열을 채울 수 있습니까?

Data 열에 느슨한 요소로 추가해 보겠습니다.

사용자가 어느 것이 어느 것인지 알 수 있도록 JoinEUI 및 DevEUI와 같은 작은 텍스트를 JoinEUI 및 DevEUI 앞에 추가합니다.

예. @bafonins , 이것은 실제로 내가 슬랙에서 의미한 것입니다. 거기에 대해 충분히 명확하지 못해 죄송합니다.

차라리 "데이터 업링크 메시지 전달" 텍스트를 아이콘(또는 아이콘, AS + 업링크 + 데이터)으로 바꾸고 싶습니다.

"문자는 천 개 이상의 아이콘을 말합니다" 😅. 이벤트 유형 열을 텍스트로 유지하고 싶습니다. 아이콘만으로 내용을 전달하는 것은 불가능합니다.

다음은 응용 프로그램 및 장치 계층에 실행 가능한 솔루션이라고 생각하는 것을 보여주는 두 가지 화면 디자인입니다.

단일 엔터티(최종 장치, 게이트웨이)의 데이터 보기에서 중복되므로 엔터티 ID 열을 제거할 수 있습니다.

👍 의미가 있다

다양한 이벤트, 특히 여기에서 참여 절차와 관련된 이벤트에 대해 더 세분화된 아이콘이 필요합니다.

조인 흐름 뿐만이 아닙니다. MAC 명령에 대한 사용자 정의 아이콘( ns.mac.* )이 있으면 좋을 것입니다.

일부 이벤트 유형 메시지는 (내가 말할 수 있는 한) 불필요하게 길다. 예를 들어 업링크 데이터 메시지를 수신하면 업링크 데이터를 수신할 수 없습니까?

동의합니다. 여러 오류 설명의 이름을 바꾸는 것뿐입니다. receive uplink data 또는 receive uplink message 일 수 있습니다. @johanstokking 어떻게 생각하세요?

현재 페이로드 형식 함수를 통해 frm_payload를 파이프하고 결과를 한 줄 JSON으로 표시하는 것은 굉장할 것입니다(screendesigns 참조).

decoded_payload 를 직접 표시할 수 있습니다. 맞죠? 업링크 메시지에 대한 ApplicationUp 의 구조는 다음과 같습니다.

{
  "uplink_message": {
    ...
    "frm_payload": "AQ==",
    "decoded_payload": {
      "led": "ON"
    }
    ...
}

사용자가 어느 것이 어느 것인지 알 수 있도록 JoinEUI 및 DevEUI와 같은 작은 텍스트를 JoinEUI 및 DevEUI 앞에 추가합니다.

예. @bafonins , 이것은 실제로 내가 슬랙에서 의미한 것입니다. 거기에 대해 충분히 명확하지 않아서 죄송합니다.

👌

조인 흐름 뿐만이 아닙니다. MAC 명령(ns.mac.*)에 대한 사용자 정의 아이콘이 있으면 좋을 것입니다.

물론.

디코딩된_페이로드를 직접 표시할 수 있습니다. 맞죠? 업링크 메시지에 대한 ApplicationUp의 구조는 다음과 같습니다.

아 물론 🤦‍♂

• 예: receive uplinke data message , 그냥 receive uplink data 하면 안 됩니까?

예. 그러나 "수신" 대 "전달" 대 "보내기" 등의 아이콘을 가질 수 있습니까?

이벤트 유형 열을 텍스트로 유지하고 싶습니다. 아이콘만으로 내용을 전달하는 것은 불가능합니다.

뿐만 아니라 당신이 제안한 것처럼 우리는 아이콘으로 눈에 띄는 것을 바꿀 수 있습니다.

dev_addr에 대한 열이 있고 발생하는 모든 업링크 메시지 및 가입 수락에 대해 열을 채울 수 있습니까?

Data 열에 느슨한 요소로 추가해 보겠습니다.

문제는 이것이 장치 활성화(새로운 DevAddr 를 표시할 수 있는 곳)를 포함하여 _모든_ 업스트림 메시지의 일부라는 것입니다. 따라서 첫 번째 디자인에서 DevAddr 가 정렬되지 않았습니다(오른쪽에 있음). 느슨하기 때문입니다.

그 외에는 이 디자인이 정말 좋고 유용해 보입니다.

예. 그러나 "수신" 대 "전달" 대 "보내기" 등의 아이콘을 가질 수 있습니까?

나는 우리가 그것을 끝까지 해야 하거나 전혀 하지 말아야 한다고 생각합니다. 일부만 아이콘으로 바꾸면 더 혼란스러울 것 같아요.

나는 여전히 항목별로 이벤트 유형을 나타내는 가장 좋은 방법에 대해 생각해야 합니다. 내가 본 바로는 스택 구성 요소, 프로세스 또는 주제 및 단계(예: ns.up.data.forward )의 세 가지 레이어가 있습니다.
이 모든 정보를 하나의 아이콘으로 번역하는 것은 실제로 불가능하기 때문에 여러 아이콘을 사용하거나 항상 주제와 같은 이벤트 유형 레이어 중 하나에 집중해야 합니다.

세 개의 아이콘을 사용하는 것이 방법이 될 수 있지만 다시 이벤트 유형 텍스트를 바꾸고 싶지 않으므로 간격 문제에는 실제로 도움이 되지 않지만 최소한 이벤트 항목을 더 쉽게 스캔할 수 있습니다.

문제는 이것이 장치 활성화(새로운 DevAddr를 표시할 수 있는 곳)를 포함한 모든 업스트림 메시지의 일부라는 것입니다. 따라서 첫 번째 디자인에서 DevAddr은 느슨하기 때문에 정렬되지 않았습니다(오른쪽에 있음).

물론. 그러나 규칙에 따라 장치 주소를 항상 먼저 배치할 수 있습니다. 전용 열이 있는 경우 장치 주소를 표시할 필요가 없는 다른 모든 이벤트를 위한 공간이 손실됩니다.

따라서 이것을 실행 가능한 상태로 유지하기 위한 제 제안은 다음과 같습니다.

• 지금은 아이콘과 이벤트 유형 메시지를 만지지 말고 별도의 PR로 만납시다.
• 이벤트 유형의 특정 요구 사항을 기반으로 하는 느슨한 요소와 함께 유연한 형식의 데이터 열 사용

이 문제를 계속 진행하기 위해 다른 정보나 설명이 필요한 경우 @bafonins 에게 알려주십시오.

세 개의 아이콘을 사용하는 것이 방법이 될 수 있지만 다시 이벤트 유형 텍스트를 바꾸고 싶지 않으므로 간격 문제에는 실제로 도움이 되지 않지만 최소한 이벤트 항목을 더 쉽게 스캔할 수 있습니다.

네, 그것이 주요 목표가 될 것입니다.

그 동안 상관 관계 ID별로 그룹화하는 것도 고려할 수 있습니다. 그러면 간격(수직)을 쉽게 스캔할 수 있습니다.

물론. 그러나 규칙에 따라 장치 주소를 항상 먼저 배치할 수 있습니다. 전용 열이 있는 경우 장치 주소를 표시할 필요가 없는 다른 모든 이벤트를 위한 공간이 손실됩니다.

확인

일부 업데이트:

1. 장치, 게이트웨이 및 조직 이벤트에 대한 Entity ID 열은 표시되지 않습니다. 응용 프로그램에만 해당합니다. 이것은 특히 장치의 경우 추가 공간을 절약하는 데 도움이 됩니다.
2. 오류 이벤트:

1. 일반 값 목록으로 사용 가능한 경우 decoded_payload 를 표시합니다. 배열이나 객체와 같은 중첩 항목을 건너뜁니다(페이로드 값에 색상을 추가하는 구현에 대해 후속 조치를 취하겠습니다). 사용 가능한 경우 frm_payload 도 16진수로 표시합니다.

1. 다음은 조인 흐름의 예입니다.
   (응용 이벤트 보기)

(장치 이벤트 보기)

1. AS 다운링크 이벤트의 경우 frm_payload 를 16진수로 표시합니다. 이것은 콘솔을 통해 다운링크를 예약하는 사람들에게 도움이 될 수 있습니다.

@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 를 게시하고 있습니다. UplinkMessage ~를 포함하는 DeviceUplinkMessage 와 같은 형식이어야 합니다.
  
  
  • 프론트엔드가 아직 수행하지 않은 경우 페이로드 디코딩(Basic Station은 PHYPayload를 재구성하기 때문에 수행)
  
  
• 현재 GS 전달 테이블에 여러 호스트(예: NS 및 패킷 브로커)가 있는 경우 여러 전달 이벤트를 게시하고 있습니다. gs.up.forward 의 이벤트 페이로드는 nil 입니다. 호스트 이름으로 새 proto 메시지를 정의하고 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 대신 ?

디코딩된 페이로드는 일반적으로 평평한 객체입니다. {"temperature":21.5,"light":"on"} 등. 중첩된 값이 있으면 건너뛰어도 됩니다. 즉, {"중첩":{...},"light":"on"}

디자인에 따르면 우리는 가치만을 보여줍니다. 따라서 {"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

join_request_payload 를 사용할 수 있는 eui의 흐름에 참여:

디코딩된 페이로드가 있는 업링크:

실패한 이벤트:

AS 업링크/다운링크 이벤트:

게이트웨이 가입 요청 이벤트:

mac_payload 의 게이트웨이 업링크:

엄청난

한 가지 더 부탁드립니다. FRMPayload 가 발생할 때마다 FPort 를 추가하십시오.

폐쇄: https://github.com/TheThingsNetwork/lorawan-stack/pull/2477