Lorawan-stack: Tampilkan permintaan bergabung, uplink, dan kesalahan dalam tampilan lalu lintas Konsol

Terima kasih telah menambahkan ini "harus dimiliki"
Itu adalah salah satu hal pertama yang kami perhatikan saat mengevaluasi v3 di pasar AWS.
Maaf mau tanya, ada ide kapan?

@industrialinternet terima kasih telah menunjukkan minat Anda. Itu ditetapkan pada tonggak Februari jadi tujuan kami adalah menyelesaikannya bulan ini. Silakan berlangganan masalah ini dan tonton repositori ini, setidaknya untuk rilis, dengan mengklik Tonton di bagian atas, sehingga Anda tahu kapan itu mendarat di rilis mana.

@johanstokking

Pertimbangkan badan acara as.up.forward:

Saya kira maksud Anda as.up.data.forward di sini?

1. Bisakah kita berasumsi bahwa bidang yang Anda sebutkan selalu ada (jika operasi acara berhasil) untuk setiap jenis acara?
2. Bidang apa yang harus disertakan dalam komponen widget acara (salah satu halaman ikhtisar entitas)?
   
3. Seberapa besar objek decoded_payload itu? Bertanya karena mungkin terpotong di acara ui.

Saya kira maksud Anda as.up.data.forward di sini?

Ah memang, kami membaginya menjadi as.up.join.forward dan as.up.data.forward , dan semua peristiwa downlink yang saya sebutkan belum diteruskan (belum).

1. Bisakah kita berasumsi bahwa bidang yang Anda sebutkan selalu ada (jika operasi acara berhasil) untuk setiap jenis acara?

• frm_payload selalu dalam as.up.data.forward , tetapi decoded_payload adalah opsional
• pengenal perangkat selalu dalam as.up.join.forward

2. Bidang apa yang harus disertakan dalam komponen widget acara (salah satu halaman ikhtisar entitas)?

Dalam kasus di mana kami memiliki lebih sedikit ruang, maksud Anda? Saya pikir untuk data uplink payload yang didekodekan, dan untuk bergabung-menerima DevEUI.

1. Seberapa besar objek decoded_payload itu? Bertanya karena mungkin terpotong di acara ui.

Di baris itu baik-baik saja untuk memotongnya. Jika Anda memperluas baris itu harus ditampilkan sebagai JSON. Ini bisa menjadi cukup besar sebenarnya, terserah pembuat perangkat atau pengembang aplikasi.

Tapi kebanyakan seperti {"temperature": 21.5, "humidity": 62, "x": -1, "y": 5}

Memperbarui komentar asli di sini

Hai johan dan orang lain yang terlibat dalam masalah ini

Senang mendengar bahwa kalian memiliki "batu tonggak" untuk bulan Februari.
Seperti yang kita lihat mengevaluasi konsol V3, banyak yang bisa dilakukan di sini dengan cara yang menurut saya sederhana untuk membuat produk yang luar biasa untuk dev. dan administrasi

1) Kemungkinan untuk mengirim downlink ke seluruh Aplikasi atau Node secara terpisah
2) Dapat melihat uplink payload HEX dan diterjemahkan di jendela terpisah
3) Beberapa jenis hierarki untuk direktori Aplikasi fx. Orang tua/anak/Node

Bahkan jika kami berencana untuk menggunakan TTI yang terhubung ke server kami sendiri, ini akan menjadi tambahan yang sangat baik untuk R&D dan pemantauan

Pokoknya - kerja bagus sejauh ini guys :-)

BR
/SEBUAH

Urutan kepentingan;

1. Tampilan hex ids.join_eui , ids.dev_eui dan ids.dev_addr dalam permintaan bergabung, ids.dev_addr dan uplink_message.frm_payload untuk pesan uplink
2. Pesan kesalahan yang diformat (yaitu mengisi atribut)
3. Tampilkan JSON payload yang didekodekan

Hanya untuk memperjelas hal.

• Alur bergabung berjalan sebagai berikut:

1. js.join.accept
2. ns.up.join.forward
3. ns.up.merge_metadata
4. as.up.join.receive
5. as.up.join.forward
   Ini memiliki tampilan berikut di Konsol:

Perhatikan urutan pengidentifikasi: join_eui , dev_eui dan dev_addr

Aliran uplink berjalan sebagai berikut:

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

Ini memiliki tampilan berikut di Konsol:

Perhatikan urutan pengidentifikasi: dev_addr dan frm_payload . Saya pikir kami juga dapat menampilkan dev_addr untuk sisa acara dalam aliran uplink.

Masalah yang saya lihat di sini adalah bahwa kami tidak memiliki banyak ruang, terutama untuk acara as.up.join.forward dalam alur gabung. Selain itu, nilai saja tidak benar-benar memberikan banyak informasi dan menambahkan label ( Dev Addr: .... ) akan menyisakan lebih sedikit ruang.

• Mengenai kesalahan. Memang kita bisa saja mengambil penyebab terdalam dan mengisi atributnya, misal untuk

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

kita bisa menunjukkan

atau untuk permintaan bergabung yang gagal ( ns.up.join.drop ):

Perhatikan bahwa kami menyimpan kesalahan asli yang tidak diformat di inspektur muatan. Ini mungkin berguna untuk debugging.

• Menampilkan muatan yang didekodekan - untuk nanti

@johanstokking @kschiffer ada saran di sini?

Langkah pertama yang bagus!

Perhatikan urutan pengidentifikasi: join_eui , dev_eui dan dev_addr

Sedikit komentar/pertanyaan:

1. Bisakah kita memiliki kolom untuk dev_addr , dan mengisinya untuk semua pesan uplink dan penerimaan bergabung yang terjadi?
2. Saya akan menambahkan JoinEUI dan DevEUI dengan teks kecil seperti JoinEUI dan DevEUI sehingga pengguna tahu yang mana
3. Tampilkan pengidentifikasi untuk setiap pesan yang kami ketahui, jadi ini mungkin untuk banyak baris pengidentifikasi yang sama (JS/NS/AS). Ini karena kami menambahkan pemfilteran untuk acara nanti dan di beberapa cluster, tidak semua komponen tersedia (seperti hanya JS) dan kami masih ingin melihat pengidentifikasi

Perhatikan urutan pengidentifikasi: dev_addr dan frm_payload .

Bagus, juga di sini awali dengan FRMPayload

Saya pikir kami juga dapat menampilkan dev_addr untuk sisa acara dalam aliran uplink.

Ya, itu poin 1 di atas. Saya setuju dengan itu.

Masalah yang saya lihat di sini adalah bahwa kami tidak memiliki banyak ruang, terutama untuk acara as.up.join.forward dalam alur gabung. Selain itu, nilai saja tidak benar-benar memberikan banyak informasi dan menambahkan label ( Dev Addr: .... ) akan menyisakan lebih sedikit ruang.

Saya lebih suka mengubah teks "teruskan data uplink pesan" menjadi ikon (atau ikon; AS + uplink + data), daripada menghapus informasi untuk menyimpan teks acara. Kami dapat meminta @pierrephz untuk mendesain ikon jika kami setuju. cc @kschiffer

Perhatikan bahwa kami menyimpan kesalahan asli yang tidak diformat di inspektur muatan. Ini mungkin berguna untuk debugging.

Setuju dengan kesalahan

Beberapa pemikiran:

• Dalam tampilan data entitas tunggal (perangkat akhir, gateway) kita dapat menghapus kolom Entity ID , karena itu berlebihan
• Jika tidak, mari kita mengecilkan kolom Entity ID sedikit lagi
• Kami membutuhkan ikon yang lebih halus untuk berbagai acara, terutama di sini, acara yang berkaitan dengan prosedur penggabungan (mungkin menjadi semakin sulit untuk menemukan ikon yang sesuai di pustaka ikon materi, jadi kami mungkin perlu segera membuat kumpulan ikon kami sendiri cc @pierrephz )
  
  
  
  • Untuk bergabung dengan acara terkait, kita dapat menggunakan ikon link untuk saat ini
  
  
• Kita harus menggunakan pengguliran horizontal di komponen acara (non-widget)
• Beberapa pesan jenis acara (sejauh yang saya tahu) tidak perlu panjang, misalnya receive uplinke data message , tidak bisakah itu hanya receive uplink data ?
• Gunakan versi <SafeInspector /> yang lebih sempit untuk memastikan bahwa tinggi baris tetap konsisten
• Akan luar biasa untuk menyalurkan frm_payload melalui fungsi format muatan saat ini dan untuk menampilkan hasilnya sebagai JSON satu baris (lihat desain layar). Saya baik-baik saja untuk menganggap ini sebagai pelapisan emas untuk saat ini.

Bisakah kita memiliki kolom untuk dev_addr, dan mengisinya untuk semua pesan uplink dan bergabung menerima yang terjadi?

Mari tambahkan itu sebagai elemen lepas di kolom Data .

Saya akan menambahkan JoinEUI dan DevEUI dengan teks kecil seperti JoinEUI dan DevEUI sehingga pengguna tahu yang mana

Ya. @bafonins , ini sebenarnya yang saya maksud dengan slack. Maaf karena tidak cukup jelas di sana.

Saya lebih suka mengubah teks "teruskan data uplink pesan" menjadi ikon (atau ikon; AS + uplink + data).

"Sebuah teks mengatakan lebih dari seribu ikon" . Saya benar-benar ingin menyimpan kolom jenis acara sebagai teks. Tidak mungkin mengomunikasikan kontennya hanya melalui ikon.

Berikut adalah dua desain layar yang menunjukkan apa yang menurut saya merupakan solusi yang layak untuk lapisan aplikasi dan perangkat.

Dalam tampilan data entitas tunggal (perangkat akhir, gateway) kami dapat menghapus kolom ID Entitas, karena itu berlebihan

👍 masuk akal

Kami membutuhkan ikon yang lebih halus untuk berbagai acara, terutama di sini, acara yang berkaitan dengan prosedur bergabung

Tidak hanya untuk aliran bergabung. Akan menyenangkan untuk memiliki ikon khusus untuk perintah MAC ( ns.mac.* ).

Beberapa pesan jenis acara (sejauh yang saya tahu) tidak perlu panjang, misalnya menerima pesan data uplink, tidak bisakah itu hanya menerima data uplink?

Setuju, ini hanya masalah mengganti nama beberapa deskripsi kesalahan. Bisa jadi receive uplink data atau receive uplink message . @johanstokking bagaimana menurutmu?

Akan luar biasa untuk menyalurkan frm_payload melalui fungsi format payload saat ini dan menampilkan hasilnya sebagai JSON satu baris (lihat desain layar).

Kita bisa langsung menampilkan decoded_payload kan? Struktur ApplicationUp untuk pesan uplink adalah:

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

Saya akan menambahkan JoinEUI dan DevEUI dengan teks kecil seperti JoinEUI dan DevEUI sehingga pengguna tahu yang mana

Ya. @bafonins , ini sebenarnya yang saya maksud dengan slack. Maaf karena tidak cukup jelas di sana.

👌.

Tidak hanya untuk aliran bergabung. Akan menyenangkan untuk memiliki ikon khusus untuk perintah MAC (ns.mac.*).

Memang.

Kita bisa langsung menampilkan decode_payload, kan? Struktur ApplicationUp untuk pesan uplink adalah:

Oh, tentu saja

• misalnya receive uplinke data message , tidak bisakah itu hanya receive uplink data ?

Ya. Tetapi bisakah kita memiliki ikon untuk "terima" vs "teruskan" vs "kirim" dll?

Saya benar-benar ingin menyimpan kolom jenis acara sebagai teks. Tidak mungkin mengomunikasikan kontennya hanya melalui ikon.

Tidak hanya, tetapi seperti yang Anda sarankan juga, kami dapat mengganti beberapa hal yang jelas dengan ikon, bukan?

Bisakah kita memiliki kolom untuk dev_addr, dan mengisinya untuk semua pesan uplink dan bergabung menerima yang terjadi?

Mari tambahkan itu sebagai elemen lepas di kolom Data .

Masalahnya adalah ini adalah bagian dari _setiap_ pesan upstream, termasuk aktivasi perangkat (di mana kita dapat menampilkan DevAddr baru). Jadi dalam desain pertama Anda, DevAddr tidak sejajar (ada di sebelah kanan), karena longgar, saya kira?

Selain itu, desain ini terlihat sangat bagus dan bermanfaat

Ya. Tetapi bisakah kita memiliki ikon untuk "terima" vs "teruskan" vs "kirim" dll?

Saya pikir kita harus melakukannya sepanjang jalan atau tidak sama sekali. Mengganti hanya beberapa hal dengan ikon akan lebih membingungkan, saya pikir.

Saya masih perlu memikirkan cara terbaik untuk mewakili jenis acara berdasarkan item. Dari apa yang saya lihat, ada tiga lapisan yaitu: komponen tumpukan, proses atau subjek dan langkah (misalnya ns.up.data.forward ).
Karena tidak mungkin untuk menerjemahkan semua informasi ini menjadi satu ikon, kita perlu menggunakan beberapa ikon atau selalu fokus pada salah satu lapisan jenis peristiwa, seperti subjek.

Menggunakan tiga ikon mungkin merupakan cara, tetapi sekali lagi, saya tidak benar-benar ingin mengganti teks jenis acara, jadi itu tidak akan terlalu membantu dengan masalah jarak, tetapi setidaknya akan membuat entri acara lebih mudah untuk dipindai.

Masalahnya adalah ini adalah bagian dari setiap pesan upstream, termasuk aktivasi perangkat (di mana kami dapat menampilkan DevAddr baru). Jadi dalam desain pertama Anda, DevAddr tidak sejajar (ada di sebelah kanan), karena longgar, saya kira?

Memang. Tapi kita bisa menempatkan alamat perangkat selalu pertama sebagai sebuah konvensi. Jika kami memiliki kolom khusus, kami akan kehilangan ruang untuk semua acara lain yang tidak perlu menunjukkan alamat perangkat.

Jadi saran saya agar ini dapat ditindaklanjuti:

• Mari kita tidak menyentuh ikon dan pesan jenis acara untuk saat ini tetapi dalam PR terpisah
• Gunakan bentuk kolom data yang fleksibel, dengan elemen longgar berdasarkan kebutuhan spesifik dari jenis acara

@bafonins beri tahu saya jika Anda memerlukan info atau klarifikasi lain untuk melanjutkan masalah ini.

Menggunakan tiga ikon mungkin merupakan cara, tetapi sekali lagi, saya tidak benar-benar ingin mengganti teks jenis acara, jadi itu tidak akan terlalu membantu dengan masalah jarak, tetapi setidaknya akan membuat entri acara lebih mudah untuk dipindai.

Ya itu akan menjadi tujuan utama.

Sementara kami berada di sana, kami mungkin ingin mempertimbangkan pengelompokan berdasarkan ID korelasi juga. Itu akan melayani pemindaian jarak (vertikal) lebih mudah.

Memang. Tapi kita bisa menempatkan alamat perangkat selalu pertama sebagai sebuah konvensi. Jika kami memiliki kolom khusus, kami akan kehilangan ruang untuk semua acara lain yang tidak perlu menunjukkan alamat perangkat.

Oke

Beberapa pembaruan:

1. Kami tidak menampilkan kolom Entity ID untuk acara perangkat, gateway, dan organisasi. Hanya untuk aplikasi. Ini membantu menghemat ruang ekstra, terutama untuk perangkat.
2. Peristiwa kesalahan:

1. Kami menampilkan decoded_payload jika tersedia sebagai daftar nilai biasa . melewatkan entri bersarang seperti array atau objek (saya akan menindaklanjuti dengan implementasi yang menambahkan warna ke nilai muatan). Kami juga menampilkan frm_payload sebagai hex jika tersedia:

1. Berikut adalah contoh alur join:
   (tampilan acara aplikasi)

(tampilan acara perangkat)

1. Tampilkan frm_payload dalam hex untuk acara downlink AS. Ini dapat membantu orang yang menjadwalkan downlink melalui Konsol:

@johanstokking Apakah ada yang lain? Apakah ada entri yang dapat kami tampilkan untuk acara gateway (untuk gs.up.receive , misalnya, kami dapat menampilkan frm_payload f_cnt f_port )?

Besar!

Sedikit komentar/pertanyaan kecil;

• Untuk acara hulu AS, sertakan juga DevAddr
• Apakah menampilkan nama acara sekarang?
• Saya akan menggunakan istilah LoRaWAN DevAddr dan FRMPayload
• Muatan yang didekode biasanya berupa objek datar; {"temperature":21.5,"light":"on"} dll. Jika ada nilai bersarang, saya baik-baik saja melewatkannya; yaitu {"nested":{...},"light":"on"}

Khusus untuk acara GS upstream;

• Saat ini kami tidak mendekode LoRaWAN raw_payload , karena GS tidak (banyak) berhubungan dengan LoRaWAN. GS memang memecahkan kode pengidentifikasi LoRaWAN (EUI saat bergabung, DevAddr saat uplink), yang mungkin menarik untuk ditampilkan di aliran ini untuk pemfilteran. Solusi potensial:
  
  
  
  • ~Solusi orang miskin; serahkan ini pada pemirsa (Konsol). Ini juga yang kami lakukan di Konsol V2. Ini tidak ideal karena menambahkan logika LoRaWAN ke Konsol~
  
  
  • ~Entah bagaimana memasang pengidentifikasi dalam muatan acara. Saat ini kami sedang menerbitkan UplinkMessage , yang seharusnya menjadi sesuatu seperti DeviceUplinkMessage yang menyematkan UplinkMessage ~
  
  
  • Decode payload, jika front-end belum melakukannya (Basic Station melakukannya karena merekonstruksi PHYPayload)
  
  
• Saat ini kami menerbitkan beberapa acara penerusan jika ada beberapa host di tabel penerusan GS, yaitu NS dan Broker Paket. Muatan acara untuk gs.up.forward adalah nil . Kita dapat mendefinisikan pesan proto baru dengan nama host dan kita dapat mengirimkan map[string]string{}

~ @htdvisser mohon saran tentang masalah muatan acara; ini tidak tercakup dalam pedoman pengembangan.~

@johanstokking

Untuk acara hulu AS, sertakan juga DevAddr

Jadi, untuk as.up.data.receive , as.up.data.forward ? Bagaimana dengan as.down.data.receive dan as.down.data.forward ?
Saya kira kami juga ingin menunjukkan hal yang sama untuk ns.up.data.* .

Apakah menampilkan nama acara sekarang?

Tidak, kami akan menampilkan deskripsi acara lengkap seperti sekarang.

Saya akan menggunakan istilah LoRaWAN DevAddr dan FRMPayload

Maksud Anda alih-alih Device Address dan Frame Payload ?

Muatan yang didekode biasanya berupa objek datar; {"temperature":21.5,"light":"on"} dll. Jika ada nilai bersarang, saya baik-baik saja melewatkannya; yaitu {"bersarang":{...},"light":"on"}

Menurut desain, kami hanya menunjukkan nilai. Jadi, untuk {"temperature":21.5,"light":"on"} kita akan menampilkan [21.5, "on"] . Apakah ini baik-baik saja?

GS memang memecahkan kode pengidentifikasi LoRaWAN (EUI saat bergabung, DevAddr saat uplink), yang mungkin menarik untuk ditampilkan di aliran ini untuk pemfilteran

Kami dapat menunjukkan pengidentifikasi untuk gs.up.receive . Untuk permintaan bergabung, kami dapat menunjukkan EUI dari:

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

Dan tampilkan dev addr untuk uplink dari:

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

Jadi, untuk as.up.data.receive , as.up.data.forward ? Bagaimana dengan as.down.data.receive dan as.down.data.forward ?
Saya kira kami juga ingin menunjukkan hal yang sama untuk ns.up.data.* .

Ya, jika pengenal ada di payload, tunjukkan.

Maksud Anda alih-alih Device Address dan Frame Payload ?

>

Ya

Menurut desain, kami hanya menunjukkan nilai. Jadi, untuk {"temperature":21.5,"light":"on"} kita akan menampilkan [21.5, "on"] . Apakah ini baik-baik saja?

Tidak, saya pikir kita perlu kunci di sini. Banyak nilai numerik sehingga menjadi membingungkan. Juga karena ini adalah peta, tidak ada urutan tetap (kecuali jika Anda mengurutkan kunci dan mengambil nilainya).

Kami dapat menunjukkan pengidentifikasi untuk gs.up.receive . Untuk permintaan bergabung, kami dapat menunjukkan EUI dari:

Ya, tetapi kami tidak memilikinya di muatan, kan? Ini adalah muatannya misalnya:

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

Ya, jika pengenal ada di payload, tunjukkan

Kami dapat pengidentifikasi dari bidang identifiers acara jika muatan kosong:

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

Tidak, saya pikir kita perlu kunci di sini. Banyak nilai numerik sehingga menjadi membingungkan. Juga karena ini adalah peta, tidak ada urutan tetap (kecuali jika Anda mengurutkan kunci dan mengambil nilainya).

👌.

Ya, tetapi kami tidak memilikinya di muatan, kan? Ini adalah muatannya misalnya:

Inilah yang saya miliki untuk 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"
  ]
}

Oke, ya, tunjukkan pada mereka. Saat ini mereka dapat menjadi nil , jadi perhitungkan itu, tetapi kita dapat mengubah GS untuk memecahkan kode payload jika itu belum terjadi.

@johanstokking

Gabung aliran dengan eui di mana join_request_payload tersedia:

Uplink dengan payload yang didekodekan:

Acara yang gagal:

SEBAGAI acara uplink/downlink:

Acara permintaan bergabung dengan gateway:

Uplink gateway dengan mac_payload :

Luar biasa

Satu permintaan lagi; tolong tambahkan FPort sebelum setiap kemunculan FRMPayload

Ditutup oleh https://github.com/TheThingsNetwork/lorawan-stack/pull/2477