Lorawan-stack: Gunakan wizard untuk membuat perangkat akhir

Masalah utama dengan implementasi bentuk perangkat saat ini adalah bahwa semuanya digabungkan bersama. Hal ini menyebabkan

1. Skema validasi yang rumit dan panjang
2. Tidak ada cara langsung untuk menonaktifkan bidang tertentu berdasarkan konfigurasi tumpukan
3. Tidak ada cara langsung untuk mengubah bidang formulir/judul bidang sesuai dengan nilai yang dipilih
4. Kompleksitas yang tidak perlu di js sdk untuk pembuatan/pembaruan/penghapusan batch serta logika rollback pembuatan

Saya mengusulkan untuk mengimplementasikan formulir perangkat sebagai formulir multi-langkah. Ini bisa terlihat seperti ini:

Pendekatan tersebut membahas semua masalah yang disebutkan di atas:

1. Alih-alih satu skema kompleks, kami mendefinisikan yang kecil untuk setiap langkah.
2. Cukup nonaktifkan seluruh langkah jika komponen yang bertanggung jawab tertentu tidak tersedia di tumpukan. Terlebih lagi, kami dapat memberi tahu pengguna tentang ini melalui deskripsi/pemberitahuan.
3. Sesuaikan setiap langkah tergantung pada nilai yang dikirimkan sebelumnya. Misalnya, ubah label Join EUI menjadi App EUI untuk versi lorawan 1.0.x .
4. Tidak perlu permintaan batch. Pengguna menjadi bertanggung jawab untuk membuat perangkat dalam komponen yang berbeda. Namun kami mungkin ingin menyimpan penghapusan batch untuk kenyamanan.

Perangkat pengeditan dapat diimplementasikan sebagai tumpukan akordeon:

Dimana setiap akordeon mengembang dengan bentuk yang berdiri sendiri.

Selain formulir perangkat, kami juga dapat menggunakan wizard untuk formulir aplikasi untuk:

1. Buat aplikasi di is
2. Tautkan aplikasi ke as

cc @kschiffer @johanstokking @htdvisser

Kedengarannya bagus bagi saya, terutama jika kita dapat mengelompokkan bidang untuk komponen bersama-sama dalam satu langkah. Dengan begitu, kita dapat dengan mudah melewati/menonaktifkan langkah saat komponen tidak tersedia.

Referensi https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 juga; bahkan jika JS tersedia, pengguna dapat melewati bidang JS.

Saya datang dengan diagram seperti itu:

Setiap simpul adalah langkah

• Langkah-langkah dengan garis putus-putus tidak mengirimkan formulir tetapi menyimpannya di negara bagian setempat untuk langkah selanjutnya.
• Lainnya mengirim permintaan ke server pada pengiriman.

Kelihatannya rumit, tetapi implementasi saat ini memiliki ruang status yang lebih besar terkait validasi/pengajuan/pembuatan topeng bidang/dll.

Pertimbangkan diagram sebagai proposisi awal untuk memulai diskusi.

Saya pikir ini adalah awal yang baik.

• Mungkin alurnya akan lebih baik jika Join Server didahulukan.
• Hal penting yang kami belum benar-benar membuat kemajuan apa pun adalah pra-pengisian kolom dari template perangkat di repositori perangkat #263. Saya pikir itu benar-benar dapat menyederhanakan proses penyebaran produksi.

Dan beberapa hal kecil:

• DevEUI tidak dilarang untuk perangkat ABP (dapat diatur secara opsional)
• Perangkat LoRaWAN 1.0.x tidak memiliki NwkKey , hanya AppKey
• FNwkSIntKey disebut NwkSKey (ke arah pengguna)
• Server Aplikasi tidak mendapatkan NwkKey atau AppKey

Ya, awal yang bagus.

• Mungkin alurnya akan lebih baik jika Join Server didahulukan.

Saya setuju dengan ini. Jika mode aktivasi adalah OTAA dan cluster JS diaktifkan, pada halaman JS pengguna mendapatkan pilihan untuk memasukkan kunci root dan menyimpannya di cluster JS. (jika mereka menonaktifkannya, NS menggunakan pencarian JS, sama seperti ketika tidak ada JS di cluster yang diaktifkan)

• "Mode aktivasi" ada di payload - dalam diagram Anda, ini sesuai dengan sebenarnya 2 bidang - multicast bool dan supports_join bool . Ada 3 opsi yang memungkinkan, karena multicast && supports_join tidak valid.
• frequency_plan -> frequency_plan_id

• resets_f_cnt adalah opsional, false secara default.

• FNwkSIntKey harus ditampilkan sebagai NwkKey hanya untuk <1.1

• FNwkSIntKey tidak ada dalam pengaturan ABP NS untuk >= 1.1
• multicast perangkat hanya perlu AppSKey - NS tidak memerlukan kunci apa pun agar perangkat multicast berfungsi, hanya AS

@htdvisser

Mungkin alurnya akan lebih baik jika Join Server didahulukan.

Mengapa?

Hal penting yang kami belum benar-benar membuat kemajuan apa pun adalah pra-pengisian kolom dari template perangkat di repositori perangkat #263. Saya pikir itu benar-benar dapat menyederhanakan proses penyebaran produksi.

Bagi saya sepertinya di luar cakupan masalah ini

DevEUI tidak dilarang untuk perangkat ABP (dapat diatur secara opsional)

Apakah kita ingin mengaturnya untuk perangkat ABP juga? Saya akan mengatakan semakin sedikit bidang yang kita miliki, semakin baik. Namun, dibutuhkan kita bisa menambahkannya.

FNwkSIntKey disebut NwkSKey (terhadap pengguna)

Jadi labelnya harus NwkSKey untuk 1.0.x dan 1.1.x ? Inilah yang kami miliki atm di konsol:

• Perangkat LoRaWAN 1.0.x tidak memiliki NwkKey, hanya AppKey
• Server Aplikasi tidak mendapatkan NwkKey atau AppKey

Tetap

@johanstokking

Jika mode aktivasi adalah OTAA dan cluster JS diaktifkan, pada halaman JS pengguna mendapatkan pilihan untuk memasukkan kunci root dan menyimpannya di cluster JS. (jika mereka menonaktifkannya, NS menggunakan pencarian JS, sama seperti ketika tidak ada JS di cluster yang diaktifkan).

Jadi ini hanya masalah mengizinkan pengguna untuk melewati langkah pengiriman server bergabung? Tidak ada permintaan ke js sama sekali?

Mengenai https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 , dapatkah Anda juga menentukan di mana bidang-bidang ini termasuk dalam diagram?

@rvolosatovs

Mode aktivasi" dalam payload - dalam diagram Anda, ini sesuai dengan sebenarnya 2 bidang - multicast bool dan support_join bool. Ada 3 opsi yang memungkinkan, karena multicast && support_join tidak valid.

Hanya untuk mengklarifikasi:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - multicast
   Apakah ini benar?

resets_f_cnt adalah opsional, salah secara default.

Saya pikir masih baik untuk menunjukkannya kepada pengguna. Haruskah mengizinkan pengguna mengaturnya untuk perangkat multicast?

FNwkSIntKey harus disajikan sebagai NwkKey hanya untuk <1.1

Maksudnya NwkSKey ?

frekuensi_rencana -> frekuensi_rencana_id
FNwkSIntKey tidak ada dalam pengaturan ABP NS untuk >= 1.1

Tetap

Diagram yang diperbarui:

@htdvisser

Mungkin alurnya akan lebih baik jika Join Server didahulukan.

Mengapa?

Ya saya datang kembali ini; Saya pikir lebih masuk akal untuk memasukkan versi MAC sebelum memasukkan kunci. Jadi saya mendukung aliran saat ini. Jika versi MAC dimasukkan (saat NS diaktifkan), kita tidak perlu meminta NwkKey karena itu 1.1.x.

Hal penting yang kami belum benar-benar membuat kemajuan apa pun adalah pra-pengisian kolom dari template perangkat di repositori perangkat #263. Saya pikir itu benar-benar dapat menyederhanakan proses penyebaran produksi.

Bagi saya sepertinya di luar cakupan masalah ini

Ini di luar jangkauan memang.

DevEUI tidak dilarang untuk perangkat ABP (dapat diatur secara opsional)

Apakah kita ingin mengaturnya untuk perangkat ABP juga? Saya akan mengatakan semakin sedikit bidang yang kita miliki, semakin baik. Namun, dibutuhkan kita bisa menambahkannya.

Ya, kami ingin memintanya secara opsional. Semakin banyak informasi identifikasi yang kami miliki tentang perangkat akhir, semakin baik. Ini juga diperlukan dalam roaming pasif stateful. Alasan kami tidak memaksa pengguna untuk memasukkan DevEUI, karena jika tidak ada DevEUI, kami tidak ingin pengguna memasukkan nilai palsu.

FNwkSIntKey disebut NwkSKey (terhadap pengguna)

Jadi labelnya harus NwkSKey untuk 1.0.x dan 1.1.x ? Inilah yang kami miliki atm di konsol:

Ini NwkSKey untuk 1.0.x dan FNwkSIntKey untuk 1.1.x.

Jika mode aktivasi adalah OTAA dan cluster JS diaktifkan, pada halaman JS pengguna mendapatkan pilihan untuk memasukkan kunci root dan menyimpannya di cluster JS. (jika mereka menonaktifkannya, NS menggunakan pencarian JS, sama seperti ketika tidak ada JS di cluster yang diaktifkan).

Jadi ini hanya masalah mengizinkan pengguna untuk melewati langkah pengiriman server bergabung? Tidak ada permintaan ke js sama sekali?

Memang.

Contohnya adalah perangkat yang menampilkan modem Semtech yang menggunakan Server Gabung Semtech. Kita hanya perlu mengetahui EUI dalam kasus itu.

Mengenai #1134, dapatkah Anda juga menentukan di mana bidang-bidang ini termasuk dalam diagram?

Mereka termasuk dalam langkah JS; bidang ini menjadi JS, jika JS diaktifkan di cluster dan jika pengguna ingin menyediakan perangkat di JS.

Bidang ini opsional.

Hanya untuk mengklarifikasi:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - multicast
   Apakah ini benar?

Dengan ketat:

1. OTAA: supports_join
2. ABP: !supports_join && !multicast
3. Multicast: multicast

Tidak valid adalah supports_join && multicast , tetapi ini (atau harus) divalidasi di NS.

resets_f_cnt adalah opsional, salah secara default.

Saya pikir masih baik untuk menunjukkannya kepada pengguna. Haruskah mengizinkan pengguna mengaturnya untuk perangkat multicast?

Tidak, ini bukan untuk multicast. resets_f_cnt merujuk ke uplink, tetapi tidak ada uplink di multicast.

FNwkSIntKey harus disajikan sebagai NwkKey hanya untuk <1.1

Maksudnya NwkSKey ?

Seharusnya NwkSKey memang.

@bafonins silakan lihat jawaban @johanstokking .
Sehubungan dengan multicast - alamat perangkat juga diperlukan

• Menambahkan bidang dari https://github.com/TheThingsNetwork/lorawan-stack/issues/1134
• Menambahkan DevEUI ke perangkat abp/multicast
• Menambahkan Device Address ke perangkat multicast
  

Alamat Perangkat masih hilang dari pengaturan Server Jaringan perangkat multicast

Alamat Perangkat masih hilang dari pengaturan Server Jaringan perangkat multicast

Diperbarui

Multicast dapat berupa 1.0.x dan 1.1.x. Memasukkan informasi sesi ( DevAddr dan kunci) sama untuk multicast seperti untuk ABP.

Juga resets_join_nonces dapat diatur dalam JS dengan 1.1.x

Memisahkan pembuatan perangkat pasti diperlukan dan cara yang bagus untuk mendapatkan alur dan implementasi yang lebih dekat dengan persyaratan backend, sekaligus mengurangi kerumitan bagi pengguna.

Beberapa pemikiran dan tantangan yang saya lihat:

• Kita harus menambahkan fungsionalitas untuk membatalkan seluruh aliran, yang mengakibatkan penghapusan entri registri apa pun yang telah dibuat.
  
  
  
  • Demikian juga, pergi ke langkah sebelumnya perlu menempatkan formulir dalam "mode pembaruan" (harus relatif mudah karena titik akhir sama, kecuali untuk IS)
  
  
• Satu masalah yang saya lihat adalah langkah Server Aplikasi yang sangat dangkal (apakah ini akan berubah nanti?) dan menambahkan opsi format muatan di sana juga tidak terlalu sesuai dengan kebutuhan pengguna saat membuat perangkat.
  
  
  
  • Solusinya mungkin menggabungkan langkah AS dan JS mengingat keduanya cukup mudah dan tidak saling bergantung. Saya menyadari ini bertentangan dengan pemisahan berdasarkan komponen tetapi saya pikir ini akan menyederhanakan seluruh aliran dengan abstraksi yang masuk akal. Terutama mengingat bahwa kami tidak mengomunikasikan koneksi apa pun ke komponen tumpukan masing-masing dalam langkah-langkahnya.
  
  
• Bergantung pada konfigurasi tumpukan, kita mungkin berakhir dengan wizard yang hanya memiliki satu atau dua langkah, yang merupakan anti-pola untuk wizard.
  
  
  
  • Untuk kasus hanya satu langkah, kita cukup menyembunyikan/menghapus aspek wizard
  
  
  • Untuk dua langkah, saya pikir kita harus hidup dengan masalah ini
  
  
• Harus dipertimbangkan bahwa solusi wizard akan sedikit meningkatkan _time-to-complete_ untuk cerita pengguna
  
  
  
  • Ini bisa menjadi masalah dalam situasi di mana banyak perangkat perlu dibuat dengan tangan, meskipun kami akan memperkenalkan fitur pembuatan batch untuk kasus penggunaan ini dan CLI/scripting dapat membantu dengan situasi seperti itu juga.
  
  
  • Namun, pertimbangkan perbedaannya dengan pembuatan perangkat konsol V2 dan bagaimana pengguna dapat melihat perubahan ini
  
  
• Saya suka solusi "edit tersegmentasi" yang sesuai untuk pengaturan umum
• Diagram alir sangat membantu dan kami harus terus memperbaruinya 👍

Kompleksitas yang tidak perlu di js sdk untuk pembuatan/pembaruan/penghapusan batch serta logika rollback pembuatan

Saya pikir fungsionalitas yang ada di SDK untuk memisahkan dan menggabungkan permintaan perangkat masih cukup berharga, bahkan jika kami tidak menggunakannya dalam kasus ini

@johanstokking untuk perangkat multicast NS hanya membutuhkan SNwkSIntKey dalam 1.1 untuk perhitungan MIC. FNwkSIntKey dan NwkSEncKey , pada kenyataannya, seharusnya tidak diizinkan untuk mengatur IMO.

• Kita harus menambahkan fungsionalitas untuk membatalkan seluruh aliran, yang mengakibatkan penghapusan entri registri apa pun yang telah dibuat.
  
  
  
  • Demikian juga, pergi ke langkah sebelumnya perlu menempatkan formulir dalam "mode pembaruan" (harus relatif mudah karena titik akhir sama, kecuali untuk IS)
  
  

Saya tidak berpikir kita harus membuat apa pun sebelum mencapai Finish atau semacamnya. Bolak-balik dalam wizard dan menutup jendela browser seharusnya tidak menghasilkan perangkat yang setengah jadi.

• Satu masalah yang saya lihat adalah langkah Server Aplikasi yang sangat dangkal (apakah ini akan berubah nanti?) dan menambahkan opsi format muatan di sana juga tidak terlalu sesuai dengan kebutuhan pengguna saat membuat perangkat.

Kami akan menambahkan konfigurasi untuk paket aplikasi di sini (yaitu pengaturan multicast jarak jauh, transfer blok data terfragmentasi, opsi modem Semtech, dll). Jadi ya itu dangkal sekarang tapi itu akan diperpanjang.

• Solusinya mungkin menggabungkan langkah AS dan JS mengingat keduanya cukup mudah dan tidak saling bergantung. Saya menyadari ini bertentangan dengan pemisahan berdasarkan komponen tetapi saya pikir ini akan menyederhanakan seluruh aliran dengan abstraksi yang masuk akal. Terutama mengingat bahwa kami tidak mengomunikasikan koneksi apa pun ke komponen tumpukan masing-masing dalam langkah-langkahnya.

Untuk diri kita di masa depan, saya akan merekomendasikan untuk memisahkan mereka. Menggabungkannya juga membuat rendering hal-hal pada halaman tersebut bergantung pada ketersediaan komponen yang menambah kompleksitas pada aliran yang sudah kompleks.

• Bergantung pada konfigurasi tumpukan, kita mungkin berakhir dengan wizard yang hanya memiliki satu atau dua langkah, yang merupakan anti-pola untuk wizard.

  • Untuk kasus hanya satu langkah, kita cukup menyembunyikan/menghapus aspek wizard
  • Untuk dua langkah, saya pikir kita harus hidup dengan masalah ini

• Harus dipertimbangkan bahwa solusi wizard akan sedikit meningkatkan _time-to-complete_ untuk cerita pengguna

  • Ini bisa menjadi masalah dalam situasi di mana banyak perangkat perlu dibuat dengan tangan, meskipun kami akan memperkenalkan fitur pembuatan batch untuk kasus penggunaan ini dan CLI/scripting dapat membantu dengan situasi seperti itu juga.
  • Namun, pertimbangkan perbedaannya dengan pembuatan perangkat konsol V2 dan bagaimana pengguna dapat melihat perubahan ini

Pemisahan komponen dan skenario penerapan fleksibel adalah salah satu perubahan utama dibandingkan dengan V2, jadi sangat masuk akal jika ini efektif di Konsol V3.

Memang, untuk membuat perangkat dalam jumlah besar, orang harus tetap menggunakan API dan CLI.

Tidak ada skenario dengan satu langkah, selalu ada setidaknya dua langkah.

Bagaimana dengan merender tab alih-alih halaman? Dengan cara itu masih satu halaman tetapi semuanya mudah diakses tanpa bolak-balik dalam langkah-langkah.

@johanstokking

Saya tidak berpikir kita harus membuat apa pun sebelum mencapai Finish atau semacamnya.

Jika kita membuat permintaan yang sebenarnya hanya pada langkah terakhir, maka itu berarti kita akan membuat 3-4 permintaan. Bagaimana kami menangani kesalahan yang dikembalikan oleh komponen yang berbeda? Menangani ini, menavigasi pengguna ke langkah yang salah/menyetel ulang toko/dll. kompleks. Itulah mengapa saya menyarankan untuk mengirimkan nilai pada setiap langkah, karena setiap langkah yang berurutan dapat mengandalkan nilai yang dikirimkan sebagai valid.

Bolak-balik dalam wizard dan menutup jendela browser seharusnya tidak menghasilkan perangkat yang setengah jadi.

Saya menentang mengizinkan pengguna untuk mengedit data di wizard (untuk langkah-langkah yang menghasilkan pengiriman). Mb, hanya bidang opsional yang disimpan dalam satu komponen (dan tidak ada komponen lain yang memerlukannya), katakan name , description . Jika tidak, penanganan ini menjadi cukup rumit.

@kschiffer

Bergantung pada konfigurasi tumpukan, kita mungkin berakhir dengan wizard yang hanya memiliki satu atau dua langkah, yang merupakan anti-pola untuk wizard.

Nah, kami terbuka untuk solusi alternatif. Ada proposisi?

Jika kita membuat permintaan yang sebenarnya hanya pada langkah terakhir, maka itu berarti kita akan membuat 3-4 permintaan. Bagaimana kami menangani kesalahan yang dikembalikan oleh komponen yang berbeda? Menangani ini, menavigasi pengguna ke langkah yang salah/menyetel ulang toko/dll. kompleks. Itulah mengapa saya menyarankan untuk mengirimkan nilai pada setiap langkah, karena setiap langkah yang berurutan dapat mengandalkan nilai yang dikirimkan sebagai valid.

OKE. Tidak apa-apa, selama Konsol dapat menangani perangkat yang ada di ER tetapi tidak dapat ditemukan di JS/NS/AS karena langkah itu gagal atau pengguna menutup tab atau semacamnya.

Saya menentang mengizinkan pengguna untuk mengedit data di wizard (untuk langkah-langkah yang menghasilkan pengiriman). Mb, hanya bidang opsional yang disimpan dalam satu komponen (dan tidak ada komponen lain yang memerlukannya), katakan name , description . Jika tidak, penanganan ini menjadi cukup rumit.

Apa maksudmu?

Perhatikan bahwa AS, misalnya, tidak memerlukan bidang apa pun, hanya perlu perangkat yang ada. Jadi, jika AS ada di sana, meskipun pengguna tidak memasukkan nilai apa pun untuk AS, ia tetap harus membuat perangkat (kosong) di AS.

Apa maksudmu?

Maaf. Ini untuk saran @kschiffer :

Demikian juga, pergi ke langkah sebelumnya perlu menempatkan formulir dalam "mode pembaruan" (harus relatif mudah karena titik akhir sama, kecuali untuk IS)

Bolak-balik dalam wizard dan menutup jendela browser seharusnya tidak menghasilkan perangkat yang setengah jadi.

Saya akan menganggap ini sebagai perbaikan di masa depan. Untuk saat ini kami hanya dapat menampilkan pemberitahuan kepada pengguna tentang alur yang belum selesai. Nantinya, pengguna dapat mengedit/menghapus perangkat di halaman pengaturan umum.

Nah, kami terbuka untuk solusi alternatif. Ada proposisi?

Yah, saya pikir mengingat _edge-casiness_ dari situasi khusus ini, tidak apa-apa untuk hidup dengan masalah ini. Kata-kata Anda menyarankan bahwa saya tidak boleh mengatakan masalah tanpa solusi yang diusulkan, tetapi saya ingin memberi orang lain kesempatan untuk mengemukakan beberapa jika saya tidak dapat segera menemukannya.

Saya menentang mengizinkan pengguna untuk mengedit data di wizard (untuk langkah-langkah yang menghasilkan pengiriman). Mb, hanya bidang opsional yang disimpan dalam satu komponen (dan tidak ada komponen lain yang memerlukannya), katakan name , description . Jika tidak, penanganan ini menjadi cukup rumit.

Ini sekali lagi akan melanggar praktik terbaik untuk pola wizard. Pengguna mungkin ingin merevisi atau hanya memeriksa bidang sebelumnya, terutama mengingat bahwa ini saling bergantung. Saya baik-baik saja dengan tidak menyertakan fungsi ini pada awalnya, tetapi pada akhirnya harus ditambahkan (seperti dalam: terus melacak dalam suatu masalah).

Jika tidak, penanganan ini menjadi cukup rumit.

Secara umum, kebutuhan untuk menerapkan logika frontend yang kompleks seharusnya tidak memengaruhi komitmen kami terhadap UX.

Saya akan menganggap ini sebagai perbaikan di masa depan. Untuk saat ini, kami hanya dapat menampilkan pemberitahuan kepada pengguna tentang alur yang belum selesai. Nantinya, pengguna dapat mengedit/menghapus perangkat di halaman pengaturan umum.

Tidak optimal tetapi dapat diterima bagi saya, selama kami akan meningkatkan ini pada akhirnya.

Seperti yang dibahas secara offline, inilah proposal awal;

Buat perangkat

1. Pengaturan Umum
   
   
   
   • bidang
     
     
     
     
     
     • ids
     
     
     
     • Opsional name
     
     
     
     • Opsional description
     
     
     
     • Opsional attributes
     
     
     
     • Mode aktivasi yang diperlukan: OTAA, ABP atau Multicast
     
     
     
     • Jika NS dalam cluster
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • Langkah ini membuat perangkat hanya dalam IS. Dengan begitu, kita tahu bahwa pengidentifikasinya gratis
   
   
   • Mode aktivasi digunakan dalam status sesi
   
   
   • Jika bukan NS dalam cluster, untuk kesederhanaan dalam wizard, Anda dapat menggunakan versi tertinggi yang diketahui (yaitu sekarang masing-masing 1.1.0 dan 1.1.0-A) dalam status sesi
   
   

2. pengaturan LoRaWAN

   • Jika NS dalam cluster: Fields
     
     
     
     • lorawan_version (wajib)
     
     
     • lorawan_phy_version (wajib)
     
     
     • supports_join disetel jika Mode Aktivasi adalah OTAA (wajib)
     
     
     • multicast disetel jika Mode Aktivasi multicast
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (wajib)
     
     
     • mac_settings.supports_32_bit_f_cnt
     
     
     • mac_settings.factory_preset_frequencies
     
     
     • mac_settings.ping_slot_data_rate_index.value
     
     
     • mac_settings.ping_slot_frequency
     
     
     • mac_settings.ping_slot_periodicity.value
     
     
     • mac_settings.rx2_data_rate_index.value
     
     
     • min_frequency
     
     
     • max_frequency
     
     
   • Jika NS dalam cluster: Kolom jika mode aktivasi adalah OTAA
     
     
     
     • Kotak centang apakah akan menggunakan JS eksternal (default dicentang)
     
     
   • Kolom jika mode aktivasi adalah ABP atau Multicast
     
     
     
     • Jika NS atau AS dalam cluster: session.dev_addr
     
     
     • Jika NS atau AS dalam cluster: hasilkan session.keys.session_key_id
     
     
     • Jika NS dalam cluster: session.keys.f_nwk_s_int_key.key - diperlukan
     
     
     • Jika NS dalam cluster: session.keys.s_nwk_s_int_key.key (jika LW >= 1.1.0) - diperlukan
     
     
     • Jika NS dalam cluster: session.keys.nwk_s_enc_key.key (jika LW >= 1.1.0) - diperlukan
     
     
     • Jika AS dalam cluster: session.keys.app_s_key.key - diperlukan
     
     
     • Jika NS dalam cluster: session.last_conf_f_cnt_down
     
     
     • Jika NS dalam cluster: session.last_n_f_cnt_down
     
     
   • Jika NS dalam cluster: Kolom jika mode aktivasi adalah ABP
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • Jika NS atau AS dalam cluster: Kolom jika mode aktivasi adalah ABP
     
     
     
     • session.last_f_cnt_up - ini diperlukan untuk keamanan
     
     

   • Jika NS dalam cluster: Kolom jika mode aktivasi adalah ABP atau OTAA

     • mac_settings.adr_margin
     • mac_settings.class_b_timeout
     • mac_settings.class_c_timeout
     • mac_settings.desired_adr_ack_delay_exponent.value
     • mac_settings.desired_adr_ack_limit_exponent.value
     • mac_settings.desired_max_duty_cycle.value
     • mac_settings.desired_rx1_data_rate_offset
     • mac_settings.desired_rx1_delay.value
     • mac_settings.desired_rx2_data_rate_index.value
     • mac_settings.desired_rx2_frequency
     • mac_settings.max_duty_cycle.value
     • mac_settings.rx1_data_rate_offset
     • mac_settings.rx1_delay.value
     • mac_settings.status_count_periodicity
     • mac_settings.status_time_periodicity
     • mac_settings.supports_32_bit_f_cnt
     • mac_settings.use_adr

   • Ini menetapkan perangkat dalam NS dan AS (jika dalam cluster). Jika kami memiliki perangkat OTAA, kami tidak memiliki apa pun untuk diatur dalam AS pada saat ini, tetapi saya masih akan meminta konsistensi

3. Jika AS dalam cluster: Pengaturan aplikasi
   
   
   
   • bidang
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • Ini mengatur perangkat di AS
   
   
4. Jika JS dalam cluster dan jika OTAA dan jika tidak menggunakan JS eksternal: Pengaturan keamanan
   
   
   
   • bidang
     
     
     
     
     
     • Hasilkan root_keys.root_key_id
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (jika LW >= 1.1.)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • Ini mengatur perangkat di JS
   
   

Perbarui perangkat

Di sini, saya akan menggunakan pendekatan tab, pada dasarnya dengan langkah-langkah wizard sebagai tab.

Kuncinya di sini adalah itu;

• ids , supports_join , multicast adalah hanya-baca
• Mode aktivasi dievaluasi dalam urutan ini:
  
  
  
  • OTAA: jika tidak ada NS di cluster, atau jika NS di cluster dan NS mengatakan supports_join
  
  
  • ABP: membutuhkan NS di cluster (dan hanya relevan dalam kasus itu): !supports_join && !multicast
  
  
  • Multicast: membutuhkan NS dalam cluster (dan hanya relevan dalam kasus itu): !supports_join && multicast (walaupun multicast seharusnya cukup)
  
  

Beberapa kasus penggunaan untuk mendukung dalam memperbarui perangkat:

• Konsol dapat memiliki NS, AS, dan JS di cluster, tetapi perangkat mungkin tidak berada di NS, AS, atau JS (Konsol mendapat 404). Ini adalah kasus yang valid dan Konsol harus menangani ini. Contoh kasus adalah perangkat yang diklaim, yang perangkatnya diatur dalam ER dan JS, tetapi tidak (belum) di NS dan AS
• Berdasarkan yang sebelumnya: atur pengaturan LoRaWAN dan Aplikasi dari perangkat yang hanya ada di ER dan JS (yaitu atur di NS dan AS)
• Mengubah lorawan_version dan lorawan_phy_version (ini mengubah batasan)
• Mengubah opsi "JS eksternal"; yaitu katakanlah Anda memiliki perangkat yang sudah ada tetapi Anda ingin mengonfigurasi kunci root di cluster-JS. Kemudian, Anda hapus centang pada kotak centang ini dan pengguna harus dapat mengatur kunci root di tab Pengaturan keamanan
• Melalui impor massal, perangkat dapat dibuat di JS dan memiliki kunci root, tetapi tidak diekspos. Seperti hari ini, pengguna seharusnya dapat melihat bahwa kunci root ada di sana ( root_keys != nil ) tetapi tidak terbuka ( root_keys.app_key == null dll). Pengguna harus dapat membiarkan kunci root tetap utuh

Hal-hal umum

• Untuk kunci, bidang input atau tombol hasilkan acak
• Perbedaan antara JS eksternal dan kunci root yang tidak diekspos;
  
  
  
  • JS eksternal adalah di mana JS tidak berada di cluster yang sama dengan NS. Ini memungkinkan untuk membuat perangkat OTAA tetapi tidak harus masuk ke pengaturan Keamanan, karena kuncinya dikonfigurasi di tempat lain
  
  
  • Kunci root yang tidak terekspos adalah tempat perangkat berada di JS cluster-lokal, tetapi JS tidak mengekspos kunci root. Ini untuk keamanan, yaitu dalam hal elemen aman, di mana JS memiliki akses ke kunci root tetapi tidak mengeksposnya
  
  

Saya pikir https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 sudah berisi semua yang diperlukan untuk NS.
Saya pikir semua mac_settings harus tersedia untuk disetel untuk semua perangkat non-multicast.
Untuk perangkat multicast hanya yang berikut ini yang masuk akal:

• "mac_settings.factory_preset_frequencies"
• "mac_settings.ping_slot_data_rate_index.value"
• "mac_settings.ping_slot_frequency"
• "mac_settings.ping_slot_periodicity.value"
• "mac_settings.rx2_data_rate_index.value"
• "mac_settings.rx2_frekuensi"

Mungkin beberapa hal untuk memperjelas

Membuat:

1. Pengaturan Umum
   Sebuah. Saat kami membuat perangkat di UGD, kami tidak menetapkan alamat NS/AS/JS. Apakah kami memperbarui pendaftaran ER ketika perangkat diatur di dalamnya? Bagaimana jika kita menggunakan JS eksternal?
   B. Apakah kita menyimpan mode aktivasi di UGD?
   C. Apakah kami menyimpan versi phy/mac di UGD?
2. pengaturan LoRaWAN
   Sebuah. Bagaimana dengan supports_class_b ?
3. Pengaturan aplikasi
   Sebuah. Ya, ini bisa berarti kita menyetel perangkat pada AS dua kali

Memperbarui:

• Mode aktivasi: akan jauh lebih mudah jika kita menyimpannya di ER
• Apakah kita hanya melihat alamat 404 atau juga alamat NS/AS/JS di UGD?
• Saya pikir akan menyenangkan untuk dapat menghapus pendaftaran NS/AS/JS individu misalnya ketika mengubah "JS eksternal" menjadi true , atau untuk mengatur ulang status perangkat di NS

Hal-hal umum:

• _"JS eksternal adalah tempat JS tidak berada dalam cluster yang sama dengan NS"_: Saya pikir ini harus seperti "join_server_address tidak sama dengan alamat JS di konfigurasi konsol"

Jika kita berbicara tentang bidang tingkat atas:
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 seluruh potongan ini termasuk dalam NS (tetapi tidak semua ini diperlukan)

m{in,ax}_frequency tidak berlaku untuk multicast

@rvolosatovs

Saya pikir #579 (komentar) sudah berisi semua yang diperlukan untuk NS.

Saya pikir semua mac_settings harus tersedia untuk disetel untuk semua perangkat non-multicast.
Untuk perangkat multicast hanya yang berikut ini yang masuk akal:

Salah satu masalah dengan masalah ini adalah jumlah informasi yang terkubur dalam komentar.

Bisakah Anda menambahkan _persis_ bidang di tempat yang tepat? Saya baik-baik saja jika Anda menyalin seluruh daftar poin-poin saya sehingga kami secara bertahap mengerjakannya sampai kami memiliki versi final.

@htdvisser

1. Pengaturan Umum
   Sebuah. Saat kami membuat perangkat di UGD, kami tidak menetapkan alamat NS/AS/JS. Apakah kami memperbarui pendaftaran ER ketika perangkat diatur di dalamnya? Bagaimana jika kita menggunakan JS eksternal?

Saya pikir kita harus memperbarui alamat ketika kita mengatur perangkat di AS/NS/JS.

B. Apakah kita menyimpan mode aktivasi di UGD?

Tidak, kami tidak memiliki bidang untuk itu saat ini, kami tidak benar-benar membutuhkannya dan itu menciptakan ruang untuk inkonsistensi.

C. Apakah kami menyimpan versi phy/mac di UGD?

Tidak, lihat dokumentasi API. Sekali lagi, saya tidak melihat kebutuhan dan itu menciptakan ruang untuk inkonsistensi.

Sebuah. Bagaimana dengan supports_class_b ?

Ya, saya kira kita harus menambahkan itu, menunggu #19. @rvolosatovs harap sertakan ini dalam versi yang diperbarui jika relevan.

1. Pengaturan aplikasi
   Sebuah. Ya, ini bisa berarti kita menyetel perangkat pada AS dua kali

Ya, itu tidak sakit

Memperbarui:

• Mode aktivasi: akan jauh lebih mudah jika kita menyimpannya di ER

Ya, tetapi saya tidak yakin apakah kita harus mencari kemudahan dan apakah itu berlaku sepenuhnya. Kita harus memilikinya tersedia di jalur panas.

Juga, itu hanya akan mudah jika kita bisa memulai dari awal yang bersih. Namun, kita harus kompatibel ke belakang, menambahkan heuristik ketika lorawan_version tidak ada di ER, memperkenalkan dapatkan bersyarat dari NS, dll.

• Apakah kita hanya melihat alamat 404 atau juga alamat NS/AS/JS di UGD?

Kami hanya bisa mendapatkan 404 jika ada set alamat, jika tidak, tidak ada yang bisa didapat. Kita harus menafsirkan keduanya sebagai "tidak dalam registri itu". Kami tidak dapat membuat kesalahan di sini (seperti yang kami lakukan sebelumnya), tepatnya karena pembuatan dalam IS dan AS/NS/JS tidak terjadi secara bersamaan, dan pengguna harus dapat memulihkan inkonsistensi yang dibuat oleh Konsol.

• Saya pikir akan lebih baik untuk dapat menghapus pendaftaran NS/AS/JS individu misalnya ketika mengubah "JS eksternal" menjadi true , atau untuk mengatur ulang status perangkat di NS

Ya, mari kita lakukan nanti

• _"JS eksternal adalah tempat JS tidak berada dalam cluster yang sama dengan NS"_: Saya pikir ini harus seperti "join_server_address tidak sama dengan alamat JS di konfigurasi konsol"

Ya, itu memang cara untuk memeriksanya. join_server_address juga bisa dikosongkan, menggunakan interop.

@bafonins apakah Anda masih memiliki sumber grafiknya?
Karena sudah banyak pekerjaan yang dilakukan untuk membangunnya, saya pikir kita harus memperbaruinya untuk membuatnya lengkap untuk memiliki representasi yang jelas?
Kami juga dapat bekerja untuk memperbarui bagian NS secara offline agar tidak mengacaukan diskusi di sini.

Saya memperbarui grafik dengan semua bidang NS yang mungkin
Kolom yang berwarna merah adalah wajib

@rvolosatovs kami bertujuan untuk menentukan alur dan bidang yang kami sajikan di Konsol saat membuat dan memperbarui perangkat.

Dengan demikian,

• Kita seharusnya tidak mengizinkan perubahan mac_state.lorawan_version
• Kita bisa melakukan mac_state.ping_slot_periodicity melalui CLI untuk saat ini
• Harap pikirkan tentang bagaimana pengguna akan mengatur supports_class_b , supports_class_c dan mac_state.device_class ; mana yang merupakan bagian dari pembuatan, mana yang merupakan bagian dari pembaruan, bagaimana hubungan satu sama lain?
• Kita seharusnya tidak mengubah penghitung individu; tombol "setel ulang penghitung bingkai" (yang afaik dapat menjadi tindakan terpisah, seperti yang kita miliki di Konsol V2, yang mengatur penghitung ke 0 )
• Kita harus hati-hati memilih pengaturan mana yang kita inginkan di Konsol mac_settings dan mac_state.desired_parameters ; @htdvisser dapatkah Anda berpikir bersama di sini?

Saya mengubah urutan di https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858. Silakan bekerja secara bertahap pada daftar itu.

Bisakah Anda menambahkan bidang yang tepat di tempat yang tepat?

Saya menjawab pertanyaan ini - yaitu saya menyajikan semua bidang, yang dapat diatur dan harus diatur pada NS. Atau setidaknya begitulah saya memahami pertanyaan Anda.

Mengenai apa yang seharusnya ada di konsol, semua mac_state mungkin hanya dapat disetel melalui CLI, namun kami mungkin mengharuskannya untuk perangkat ABP/multicast dan/atau perangkat OTAA, yang didaftarkan dengan sesi yang ada, dan, maka status MAC.
Saya akan memperbarui komentar Anda.

Kita seharusnya tidak mengubah penghitung individu; tombol "setel ulang penghitung bingkai" (yang afaik dapat menjadi tindakan terpisah, seperti yang kita miliki di Konsol V2, yang menyetel penghitung ke 0)

Kami harus dapat mengatur penghitung bingkai downlink untuk ABP dan multicast - jika tidak, NS tidak dapat mengirim downlink
Untuk penghitung bingkai uplink juga sangat berguna dari sudut pandang keamanan untuk ABP

Perbarui perangkat

Di sini, saya akan menggunakan pendekatan tab, pada dasarnya dengan langkah-langkah wizard sebagai tab.

Mari kita gunakan pendekatan akordeon di sini, seperti yang disajikan dalam komentar pertama dari @bafonins :

Ini akan memberi kita lebih sedikit masalah dengan ruang horizontal, dan memungkinkan untuk membedakan mode dengan tombol Edit / Create .

@rvolosatovs

Kami harus dapat mengatur penghitung bingkai downlink untuk ABP dan multicast - jika tidak, NS tidak dapat mengirim downlink
Untuk penghitung bingkai uplink juga sangat berguna dari sudut pandang keamanan untuk ABP

Jika ini sederhana kita bisa melakukannya. Faktanya, dua/tiga kotak input mungkin lebih sederhana daripada tombol reset yang memicu tindakan tertentu.

Mengenai apa yang seharusnya ada di konsol, semua mac_state mungkin hanya dapat disetel melalui CLI, namun kami mungkin mengharuskannya untuk perangkat ABP/multicast dan/atau perangkat OTAA, yang didaftarkan dengan sesi yang ada, dan, maka status MAC.

Saya mengerti. Saya pikir kita harus memisahkan "perangkat ABP baru dan reset" dari "perangkat ABP yang sudah ada yang sudah ada di jaringan".

Yang pertama harus lengkap, jadi harus menyertakan beberapa mac_state (yaitu frekuensi reset pabrik, penundaan RX1, setelan RX2, dll) tetapi tidak mac_state.desired_parameters .

Yang terakhir harus dilakukan melalui migrasi dan kita dapat menambahkan pengaturan fine tuning nanti di Konsol; untuk saat ini CLI harus digunakan.

Terima kasih telah memperbarui

pengaturan LoRaWAN

• Jika NS dalam cluster: Fields
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

Apakah ini diperlukan untuk OTAA? Bukankah ini hanya untuk ABP dan Multicast?

@johanstokking

pengaturan LoRaWAN

• Jika NS dalam cluster: Fields
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

Apakah ini diperlukan untuk OTAA? Bukankah ini hanya untuk ABP dan Multicast?

Semua pengaturan MAC bersifat opsional berdasarkan desain.
Satu-satunya kasus di mana ini "diperlukan" adalah perangkat multicast kelas B, yang disebabkan oleh spesifikasi operasi kelas B.
Selain itu, factory_preset_frequencies kemungkinan diperlukan untuk ABP untuk hasil terbaik, tetapi tidak ada yang mencegah perangkat OTAA untuk memiliki set itu.

Semua pengaturan MAC bersifat opsional berdasarkan desain.
Satu-satunya kasus di mana ini "diperlukan" adalah perangkat multicast kelas B, yang disebabkan oleh spesifikasi operasi kelas B.

oke

Selain itu, factory_preset_frequencies kemungkinan diperlukan untuk ABP untuk hasil terbaik, tetapi tidak ada yang mencegah perangkat OTAA untuk memiliki set itu.

Ini tidak efektif untuk OTAA; frekuensi gabungan default diperlukan oleh spesifikasi, dan saluran masuk melalui perintah join-accept dan MAC. Tidak boleh ada konfigurasi frekuensi preset out-of-band untuk perangkat OTAA.

@bafonins dapatkah Anda memberikan pembaruan status dan garis waktu tentang masalah ini?

Untuk app_s_key dan skip_payload_crypto , inilah masalahnya;

• AS menghormati bidang skip_payload_crypto dari perangkat akhir. Jika true , AS tidak melakukan enkripsi dan dekripsi muatan
  
  
  
  • AS juga akan mendapatkan skip_payload_crypto pada tingkat aplikasi (melalui Tautan, seperti pemformat muatan), yang lebih diutamakan daripada pengaturan perangkat akhir
  
  
• Mungkin selalu ada app_s_key di AS, tetapi mungkin dibungkus, yaitu session.keys.app_s_key.key tidak disetel (tetapi encrypted_key dan kek_label disetel)
  
  
  
  • Ketika AS tidak memiliki KEK, yaitu tidak dapat membuka kunci terenkripsi. Sekarang, kesalahan itu. Kami mungkin hanya akan mengembalikan app_s_key terenkripsi apa adanya kepada klien
  
  
• Di Konsol, jika skip_payload_crypto diatur true (pada perangkat akhir atau tautan aplikasi), jangan repot-repot dengan app_s_key : nonaktifkan, tidak peduli