Lorawan-stack: Beitrittsanfrage, Uplink und Fehler in der Verkehrsansicht der Konsole anzeigen

Danke für das Hinzufügen, es ist ein "must have"
Dies war eines der ersten Dinge, die uns bei der Bewertung von v3 auf dem AWS-Markt aufgefallen sind.
Entschuldigung für die Frage, hast du eine Ahnung wann?

@industrialinternet Vielen Dank für Ihr Interesse. Es ist im Februar-Meilenstein festgelegt, also ist es unser Ziel, es diesen Monat fertigzustellen. Bitte abonnieren Sie diese Ausgabe und beobachten Sie dieses Repository, zumindest für Veröffentlichungen, indem Sie oben auf Beobachten klicken, damit Sie wissen, wann es in welcher Veröffentlichung landet.

@johanstokking

Betrachten Sie als.up.forward-Ereigniskörper:

Ich schätze du meinst hier as.up.data.forward ?

1. Können wir davon ausgehen, dass die von Ihnen erwähnten Felder immer (bei erfolgreicher Ereignisoperation) für jeden Ereignistyp vorhanden sind?
2. Welche Felder sollten in der Event-Widget-Komponente enthalten sein (diejenige der Entitätsübersichtsseiten)?
   
3. Wie groß darf das Objekt decoded_payload sein? Fragen, weil es in der Ereignis-Benutzeroberfläche möglicherweise abgeschnitten wird.

Ich schätze du meinst hier as.up.data.forward ?

Ach ja, wir haben sie in as.up.join.forward und as.up.data.forward aufgeteilt, und alle Downlink-Ereignisse, die ich erwähnt habe, werden (noch) nicht weitergeleitet.

1. Können wir davon ausgehen, dass die von Ihnen erwähnten Felder immer (bei erfolgreicher Ereignisoperation) für jeden Ereignistyp vorhanden sind?

• frm_payload steht immer in as.up.data.forward , aber decoded_payload ist optional
• Gerätekennungen sind immer in as.up.join.forward

2. Welche Felder sollten in der Ereignis-Widget-Komponente enthalten sein (diejenige der Entitätsübersichtsseiten)?

In Fällen, in denen wir weniger Platz haben, meinst du? Ich denke, für Daten-Uplink die decodierte Nutzlast und für Join-akzeptiert die DevEUI.

1. Wie groß darf das decoded_payload Objekt sein? Fragen, weil es in der Ereignis-Benutzeroberfläche möglicherweise abgeschnitten wird.

In der Zeile ist es in Ordnung, es abzuschneiden. Wenn Sie die Zeile erweitern, sollte sie als JSON angezeigt werden. Es kann tatsächlich ziemlich groß werden, es liegt am Gerätehersteller oder Anwendungsentwickler.

Aber das meiste ist wie {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

Hier wurde der ursprüngliche Kommentar aktualisiert

Hallo Johan und andere, die an dieser Angelegenheit beteiligt sind

Schön zu hören, dass ihr einen "Meilenstein" für den Februar habt.
So wie wir die V3-Konsole bewerten, kann hier mit meiner Meinung nach einfachen Mitteln viel getan werden, um ein hervorragendes Produkt für Entwickler zu entwickeln. und Verwaltung

1) Möglichkeit, Downlinks separat an die gesamte Anwendung oder den Knoten zu senden
2) In der Lage sein, die Uplink-Nutzlast HEX zu sehen und in einem separaten Fenster zu dekodieren
3) Eine Art Hierarchie für das Anwendungsverzeichnis fx. Übergeordnet/untergeordnet/Knoten

Selbst wenn wir planen, TTI in Verbindung mit unseren eigenen Servern zu verwenden, wäre dies eine hervorragende Ergänzung für F&E und Überwachung

Wie auch immer - gute Arbeit bisher Leute :-)

BR
/EIN

Reihenfolge der Wichtigkeit;

1. Hex-Anzeige von ids.join_eui , ids.dev_eui und ids.dev_addr in Join-Anfragen, ids.dev_addr und uplink_message.frm_payload für Uplink-Nachrichten
2. Formatierte Fehlermeldungen (dh Attribute ausfüllen)
3. Entschlüsselte Payload-JSON anzeigen

Nur um die Dinge zu klären.

• Der Join-Flow läuft wie folgt ab:

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   Diese hat in der Konsole folgende Ansicht:

Beachten Sie die Reihenfolge der Bezeichner: join_eui , dev_eui und dev_addr

Der Uplink-Fluss verläuft wie folgt:

1. ns.up.merge_metadata
2. ns.up.data.forward
3. as.up.data.receive
4. as.up.data.forward

Diese hat in der Konsole folgende Ansicht:

Beachten Sie die Reihenfolge der Bezeichner: dev_addr und frm_payload . Ich denke, wir können auch die dev_addr für die restlichen Ereignisse im Uplink-Fluss anzeigen.

Das Problem, das ich hier sehe, ist, dass wir nicht wirklich viel Platz haben, insbesondere für das Ereignis as.up.join.forward im Join-Flow. Darüber hinaus liefern nur Werte nicht wirklich viele Informationen, und das Hinzufügen von Labels ( Dev Addr: .... ) würde noch weniger Platz lassen.

• Apropos Fehler. In der Tat können wir einfach die tiefste Ursache nehmen und die Attribute ausfüllen, z. B. für

{
  "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
}

wir können zeigen

oder bei fehlgeschlagener Beitrittsanfrage ( ns.up.join.drop ):

Beachten Sie, dass wir den ursprünglichen, unformatierten Fehler im Payload-Inspektor beibehalten. Dies kann beim Debuggen hilfreich sein.

• Entschlüsselte Nutzdaten werden angezeigt - für später

@johanstokking @kschiffer irgendwelche Vorschläge hier?

Tolle erste Schritte!

Beachten Sie die Reihenfolge der Bezeichner: join_eui , dev_eui und dev_addr

Einige Anmerkungen/Fragen:

1. Können wir eine Spalte für dev_addr haben und diese für alle auftretenden Uplink-Nachrichten und Join-Annahmen füllen?
2. Ich würde JoinEUI und DevEUI mit einem kleinen Text wie JoinEUI und DevEUI voranstellen, damit die Benutzer wissen, welches welches ist
3. Zeigen Sie die Identifikatoren für jede Nachricht, die wir kennen, daher könnten dies für viele Zeilen die gleichen Identifikatoren sein (JS/NS/AS). Dies liegt daran, dass wir die Filterung für Ereignisse später hinzufügen und in einigen Clustern nicht alle Komponenten verfügbar sind (z. B. nur JS) und wir weiterhin Bezeichner sehen möchten

Beachten Sie die Reihenfolge der Bezeichner: dev_addr und frm_payload .

Gut, auch hier FRMPayload voranstellen

Ich denke, wir können auch die dev_addr für die restlichen Ereignisse im Uplink-Fluss anzeigen.

Ja, das ist Punkt 1 oben. Ich stimme dem zu.

Das Problem, das ich hier sehe, ist, dass wir nicht wirklich viel Platz haben, insbesondere für das Ereignis as.up.join.forward im Join-Flow. Darüber hinaus liefern nur Werte nicht wirklich viele Informationen, und das Hinzufügen von Labels ( Dev Addr: .... ) würde noch weniger Platz lassen.

Ich würde den Text "Daten-Uplink-Nachricht weiterleiten" lieber in ein Symbol (oder Symbole; AS + Uplink + Daten) umwandeln, anstatt Informationen zu entfernen, um den Ereignistext beizubehalten. Wir können @pierrephz bitten, Symbole zu entwerfen, wenn wir damit einverstanden sind. cc @kschiffer

Beachten Sie, dass wir den ursprünglichen, unformatierten Fehler im Payload-Inspektor behalten. Dies kann beim Debuggen hilfreich sein.

Einverstanden bei den Fehlern

Paar Gedanken:

• In den Datenansichten einzelner Entitäten (Endgeräte, Gateways) können wir die Spalte Entity ID entfernen, da sie überflüssig ist
• Lassen Sie uns andernfalls die Spalte Entity ID etwas mehr verkleinern
• Wir brauchen feinkörnigere Symbole für verschiedene Ereignisse, insbesondere hier Ereignisse im Zusammenhang mit dem Beitrittsverfahren (es könnte zunehmend schwieriger werden, geeignete Symbole in der materiellen Symbolbibliothek zu finden, daher müssen wir möglicherweise bald unser eigenes Symbolset erstellen cc @pierrephz )
  
  
  
  • Für Veranstaltungen im Zusammenhang mit der Teilnahme können wir vorerst das Symbol link verwenden
  
  
• Wir sollten das horizontale Scrollen in der (Nicht-Widget-) Ereigniskomponente verwenden
• Einige Nachrichten vom Ereignistyp sind (soweit ich das beurteilen kann) unnötig lang, zB receive uplinke data message , könnte es nicht einfach receive uplink data sein?
• Verwenden Sie eine noch schmalere Version von <SafeInspector /> , um sicherzustellen, dass die Zeilenhöhen konsistent bleiben
• Es wäre großartig, die frm_payload durch die aktuelle Payload-Formatfunktion zu leiten und das Ergebnis als einzeiliges JSON anzuzeigen (siehe Screendesigns). Ich kann dies vorerst als Vergoldung betrachten.

Können wir eine Spalte für dev_addr haben und diese für alle auftretenden Uplink-Nachrichten und Join-Annahmen füllen?

Lassen Sie uns das als loses Element in der Spalte Data hinzufügen.

Ich würde JoinEUI und DevEUI einen kleinen Text wie JoinEUI und DevEUI voranstellen, damit Benutzer wissen, welches welches ist

Ja. @bafonins , das habe ich eigentlich in Slack gemeint. Entschuldigung, dass ich mich dort nicht deutlich genug ausgedrückt habe.

Ich würde lieber den Text "Daten-Uplink-Nachricht weiterleiten" in ein Symbol (oder Symbole; AS + Uplink + Daten) umwandeln.

"Ein Text sagt mehr als tausend Ikonen" 😅. Ich möchte wirklich die Ereignistypspalte als Text behalten. Es ist unmöglich, seinen Inhalt nur über Symbole zu kommunizieren.

Hier sind zwei Screendesigns, die meiner Meinung nach eine praktikable Lösung für die Anwendungs- und Geräteebene zeigen.

In den Datenansichten einzelner Entitäten (Endgeräte, Gateways) können wir die Entitäts-ID-Spalte entfernen, da sie redundant ist

👍 macht Sinn

Wir brauchen feinkörnigere Symbole für verschiedene Ereignisse, insbesondere hier Ereignisse, die sich auf das Beitrittsverfahren beziehen

Nicht nur für den Join-Flow. Es wäre schön, ein benutzerdefiniertes Symbol für MAC-Befehle zu haben ( ns.mac.* ).

Einige Nachrichten vom Ereignistyp sind (soweit ich das beurteilen kann) unnötig lang, z. B. Nachrichten zum Empfang von Uplink-Daten.

Stimmen Sie zu, es geht nur darum, mehrere Fehlerbeschreibungen umzubenennen. Es könnte receive uplink data oder receive uplink message sein. @johanstokking was denkst du?

Es wäre großartig, die frm_payload durch die aktuelle Payload-Formatfunktion zu leiten und das Ergebnis als einzeiliges JSON anzuzeigen (siehe Screendesigns).

Wir können decoded_payload direkt anzeigen, richtig? Die Struktur von ApplicationUp für Uplink-Nachrichten ist:

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

Ich würde JoinEUI und DevEUI einen kleinen Text wie JoinEUI und DevEUI voranstellen, damit Benutzer wissen, welches welches ist

Ja. @bafonins , das habe ich eigentlich in Slack gemeint. Entschuldigung, dass ich mich dort nicht deutlich genug ausgedrückt habe.

👌

Nicht nur für den Join-Flow. Es wäre schön, ein benutzerdefiniertes Symbol für MAC-Befehle (ns.mac.*) zu haben.

In der Tat.

Wir können decoded_payload direkt anzeigen, richtig? Die Struktur von ApplicationUp für Uplink-Nachrichten ist:

Ach, natürlich 🤦‍♂

• zB receive uplinke data message , könnte es nicht einfach receive uplink data sein?

Ja. Aber können wir ein Symbol für "Empfangen" vs. "Weiterleiten" vs. "Senden" usw. haben?

Ich möchte wirklich die Ereignistypspalte als Text behalten. Es ist unmöglich, seinen Inhalt nur über Symbole zu kommunizieren.

Nicht nur, aber wie Sie auch vorgeschlagen haben, können wir einige offensichtliche Dinge durch Symbole ersetzen, richtig?

Können wir eine Spalte für dev_addr haben und diese für alle auftretenden Uplink-Nachrichten und Join-Annahmen füllen?

Lassen Sie uns das als loses Element in der Spalte Data hinzufügen.

Die Sache ist die, dass dies Teil _jeder_ Upstream-Nachricht ist, einschließlich Geräteaktivierungen (wo wir das neue DevAddr anzeigen können). In Ihrem ersten Entwurf ist das DevAddr also nicht ausgerichtet (es ist rechts), weil es locker ist, schätze ich?

Abgesehen davon sehen diese Designs wirklich gut und hilfreich aus

Ja. Aber können wir ein Symbol für "Empfangen" vs. "Weiterleiten" vs. "Senden" usw. haben?

Ich denke, wir müssten es entweder ganz oder gar nicht tun. Nur einige Dinge durch Symbole zu ersetzen, wäre verwirrender, denke ich.

Ich muss noch darüber nachdenken, wie ich Ereignistypen am besten durch Elemente darstellen kann. Soweit ich sehe, gibt es drei Ebenen: Stack-Komponente, Prozess oder Thema(s) und Schritt (z. B. ns.up.data.forward ).
Da es nicht wirklich möglich ist, alle diese Informationen in ein Symbol zu übersetzen, müssen wir entweder mehrere Symbole verwenden oder uns immer auf eine der Ebenen des Ereignistyps konzentrieren, z. B. Betreff.

Die Verwendung von drei Symbolen könnte eine Möglichkeit sein, aber andererseits würde ich den Text des Ereignistyps nicht wirklich ersetzen wollen, also würde es nicht wirklich mit dem Abstandsproblem helfen, aber es würde zumindest das Scannen der Ereigniseinträge erleichtern.

Die Sache ist, dass dies Teil jeder Upstream-Nachricht ist, einschließlich Geräteaktivierungen (wo wir die neue DevAddr anzeigen können). In Ihrem ersten Design ist die DevAddr also nicht ausgerichtet (sie ist rechts), weil sie locker ist, denke ich?

In der Tat. Aber wir können die Geräteadresse als Konvention einfach immer an erster Stelle setzen. Wenn wir eine dedizierte Spalte haben, würden wir Platz für alle anderen Ereignisse verlieren, die die Geräteadresse nicht anzeigen müssen.

Also mein Vorschlag, dies umsetzbar zu halten:

• Lassen Sie uns vorerst nicht auf die Symbole und Ereignistypnachrichten eingehen, sondern in einer separaten PR
• Verwenden Sie eine flexible Form der Datenspalte mit losen Elementen, die auf den spezifischen Anforderungen des Ereignistyps basieren

@bafonins lassen Sie mich wissen, wenn Sie weitere Informationen oder Erläuterungen benötigen, um mit diesem Problem fortzufahren.

Die Verwendung von drei Symbolen könnte eine Möglichkeit sein, aber andererseits würde ich den Text des Ereignistyps nicht wirklich ersetzen wollen, also würde es nicht wirklich mit dem Abstandsproblem helfen, aber es würde zumindest das Scannen der Ereigniseinträge erleichtern.

Ja, das wäre das Hauptziel.

Wo wir gerade dabei sind, sollten wir vielleicht auch eine Gruppierung nach Korrelations-ID in Betracht ziehen. Das erleichtert das Scannen durch beide Abstände (vertikal).

In der Tat. Aber wir können die Geräteadresse als Konvention einfach immer an erster Stelle setzen. Wenn wir eine dedizierte Spalte haben, würden wir Platz für alle anderen Ereignisse verlieren, die die Geräteadresse nicht anzeigen müssen.

OK

Einige Aktualisierungen:

1. Wir zeigen die Spalte Entity ID nicht für Geräte-, Gateway- und Organisationsereignisse an. Nur für Bewerbungen. Dies hilft, zusätzlichen Platz zu sparen, insbesondere für Geräte.
2. Fehlerereignis:

1. Wir zeigen decoded_payload falls verfügbar als reine Werteliste . Überspringen aller verschachtelten Einträge wie Arrays oder Objekte (ich werde mit der Implementierung fortfahren, die den Nutzlastwerten Farben hinzufügt). Wir zeigen auch frm_payload als Hex, wenn verfügbar:

1. Hier ist ein Beispiel für den Join-Flow:
   (Anwendungsereignisansicht)

(Geräteereignisansicht)

1. Zeigt frm_payload in Hex für AS-Downlink-Ereignisse an. Dies könnte für Personen hilfreich sein, die Downlinks über die Konsole planen:

@johanstokking Gibt es sonst noch etwas? Gibt es Einträge, die wir für Gateway-Ereignisse anzeigen können (für gs.up.receive können wir beispielsweise frm_payload f_cnt f_port )?

Toll!

Einige kleinere Kommentare/Fragen;

• Fügen Sie für AS-Upstream-Ereignisse auch DevAddr
• Werden die Ereignisnamen jetzt angezeigt?
• Ich würde die LoRaWAN-Begriffe DevAddr und FRMPayload verwenden
• Die decodierte Nutzlast ist normalerweise ein flaches Objekt; {"temperature":21.5,"light":"on"} usw. Wenn es einen verschachtelten Wert gibt, kann ich das überspringen; dh {"nested":{...},"light":"on"}

Speziell für die GS Upstream-Events;

• Derzeit decodieren wir das LoRaWAN raw_payload nicht, da GS nicht (viel) mit LoRaWAN zu tun hat. GS dekodiert die LoRaWAN-Identifikatoren (EUIs on join, DevAddr on uplink), die in diesem Stream zum Filtern interessant sein könnten. Potentielle Lösungen:
  
  
  
  • ~Die Lösung des armen Mannes; überlassen Sie dies dem Betrachter (Konsole). Das machen wir auch in V2 Console. Es ist nicht ideal, da es der Konsole LoRaWAN-Logik hinzufügt~
  
  
  • ~Irgendwie verdrahten Sie die Identifikatoren in der Ereignisnutzlast. Derzeit veröffentlichen wir UplinkMessage , was so etwas wie DeviceUplinkMessage werden sollte, das UplinkMessage ~ einbettet
  
  
  • Entschlüsseln Sie die Nutzdaten, falls das Front-End dies nicht bereits getan hat (Basisstation tut dies, weil sie PHYPayload rekonstruiert).
  
  
• Derzeit veröffentlichen wir mehrere Weiterleitungsereignisse, wenn es mehrere Hosts in der GS-Weiterleitungstabelle gibt, dh NS und Packet Broker. Die Ereignisnutzlast für gs.up.forward ist nil . Wir können eine neue Proto-Nachricht mit dem Hostnamen definieren und map[string]string{} übergeben

~ @htdvisser bitte um Rat bezüglich der Event-Payload-Angelegenheiten; dies wird nicht von den Entwicklungsrichtlinien abgedeckt.~

@johanstokking

Schließen Sie für AS-Upstream-Ereignisse auch die DevAddr ein

Also für as.up.data.receive , as.up.data.forward ? Was ist mit as.down.data.receive und as.down.data.forward ?
Ich schätze, wir wollen dasselbe auch für ns.up.data.* zeigen.

Werden die Ereignisnamen jetzt angezeigt?

Nein, wir zeigen die vollständige Ereignisbeschreibung so, wie sie jetzt ist.

Ich würde die LoRaWAN-Begriffe DevAddr und FRMPayload verwenden

Du meinst statt Device Address und Frame Payload ?

Die decodierte Nutzlast ist normalerweise ein flaches Objekt; {"temperature":21.5,"light":"on"} usw. Wenn es einen verschachtelten Wert gibt, kann ich das überspringen; dh {"nested":{...},"light":"on"}

Gemäß den Entwürfen zeigen wir nur Werte. Für {"temperature":21.5,"light":"on"} zeigen wir also [21.5, "on"] . Ist das in Ordnung?

GS dekodiert die LoRaWAN-Identifikatoren (EUIs on join, DevAddr on uplink), die in diesem Stream zum Filtern interessant sein könnten

Wir können die Bezeichner für gs.up.receive . Für Beitrittsanfragen können wir die EUIs anzeigen von:

  "payload": {
    "join_request_payload": {
      "join_eui": "...",
      "dev_eui": "..."
    }
  }

Und zeige dev addr für Uplinks von:

  "payload": {
    "mac_payload": {
      "f_hdr": {
        "dev_addr": "...",
      }
    }
  }

Also für as.up.data.receive , as.up.data.forward ? Was ist mit as.down.data.receive und as.down.data.forward ?
Ich schätze, wir wollen dasselbe auch für ns.up.data.* zeigen.

Ja, wenn die Identifikatoren in der Nutzlast enthalten sind, zeigen Sie sie an.

Du meinst statt Device Address und Frame Payload ?

>

ja

Gemäß den Entwürfen zeigen wir nur Werte. Für {"temperature":21.5,"light":"on"} zeigen wir also [21.5, "on"] . Ist das in Ordnung?

Nein, ich glaube, wir brauchen hier Schlüssel. Viele Werte sind numerisch, was verwirrend wird. Da es sich um eine Karte handelt, gibt es auch keine feste Reihenfolge (es sei denn, Sie sortieren die Schlüssel und nehmen die Werte).

Wir können die Bezeichner für gs.up.receive . Für Beitrittsanfragen können wir die EUIs anzeigen von:

Ja, aber wir haben sie nicht in der Nutzlast, richtig? Dies ist die Nutzlast zum Beispiel:

{
  "@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"
  ]
}

Ja, wenn die Identifikatoren in der Nutzlast enthalten sind, zeigen Sie sie an

Wir können die Identifikatoren aus dem Feld identifiers des Ereignisses verwenden, wenn die Nutzdaten leer sind:

    "identifiers": [
      {
        "device_ids": {
          "device_id": "...",
          "application_ids": {
            "application_id": "...",
          },
          "dev_eui": "...",
          "join_eui": "...",
          "dev_addr": "...",
        },
      },
    ],

Nein, ich glaube, wir brauchen hier Schlüssel. Viele Werte sind numerisch, was verwirrend wird. Da es sich um eine Karte handelt, gibt es auch keine feste Reihenfolge (es sei denn, Sie sortieren die Schlüssel und nehmen die Werte).

👌

Ja, aber wir haben sie nicht in der Nutzlast, richtig? Dies ist die Nutzlast zum Beispiel:

Hier ist, was ich für receive uplink message - gs.up.receive habe:

{
  "@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"
  ]
}

OK, ja, zeigen Sie es ihnen. Derzeit können sie nil sein, also berücksichtigen Sie das, aber wir können GS ändern, um die Nutzlast zu dekodieren, falls dies noch nicht geschehen ist.

@johanstokking

Treten Sie Flow mit euis bei, wo join_request_payload verfügbar ist:

Uplink mit dekodierter Nutzlast:

Fehlgeschlagenes Ereignis:

AS-Uplink-/Downlink-Ereignisse:

Gateway-Join-Request-Event:

Gateway-Uplink mit mac_payload :

Genial

Noch eine Bitte; Bitte fügen Sie FPort vor jedem Vorkommen von FRMPayload hinzu

Geschlossen von https://github.com/TheThingsNetwork/lorawan-stack/pull/2477