Lorawan-stack: Tampilkan pesan uplink terbaru dan up- & downlink fcount

Saya tidak yakin apakah ini sama, tetapi dengan cepat memeriksa keberadaan session NS, tanggal/waktu aktivasi, dan kemungkinan penghitung bingkai akan sangat membantu.

@rvolosatovs apakah kita menyimpan cap waktu "terakhir terlihat" di NS?

@rvolosatovs apakah kita menyimpan cap waktu "terakhir terlihat" di NS?

Tidak, tetapi dapat diturunkan dari RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

@rvolosatovs apakah kita menyimpan cap waktu "terakhir terlihat" di NS?

Tidak, tetapi dapat diturunkan dari RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

Itulah yang saya lakukan, tetapi saya pikir untuk fungsionalitas yang lengkap, kita perlu menghubungkan ke aliran acara untuk menjaga agar angka-angkanya diperbarui secara waktu nyata.

Itulah yang saya lakukan, tetapi saya pikir untuk fungsionalitas yang lengkap, kita perlu menghubungkan ke aliran acara untuk menjaga agar angka-angkanya diperbarui secara waktu nyata.

Sebelum saya melanjutkan dan mengimplementasikannya dengan cara ini, @htdvisser menurut Anda apakah pendekatan itu cukup menyeluruh? Peristiwa uplink downlink tidak berisi jumlah bingkai saat ini, jadi saya harus menaikkannya berdasarkan nilai awal yang saya dapatkan dari prop sesi di dalam perangkat akhir.

Itu bukan cara untuk pergi aku takut.

Apakah kita tidak mengirimkan penghitung bingkai? Itu akan menjadi masalah sebenarnya saat itu.

@rvolosatovs apakah kita menyimpan cap waktu "terakhir terlihat" di NS?

Tidak, tetapi dapat diturunkan dari RecentUplinks ( RecentUplinks[len(RecentUplinks)-1].ReceivedAt )

Itulah yang saya lakukan, tetapi saya pikir untuk fungsionalitas yang lengkap, kita perlu menghubungkan ke aliran acara untuk menjaga agar angka-angkanya diperbarui secara waktu nyata.

Sayangnya, itu tidak sesederhana kelihatannya pada pandangan pertama.

1. (ABP) Perangkat, yang ResetsFCnt==true dapat mengatur ulang FCnt itu sendiri
2. (OTAA) Perangkat dapat bergabung kembali, yang dengan sendirinya tidak akan mengatur ulang FCnt - FCnt akan diatur ulang atau ditingkatkan tergantung pada ID kunci sesi yang digunakan dalam uplink data yang diterima berikutnya
3. Nilai FCnt dalam uplink payload belum tentu perangkat yang sebenarnya FCnt , karena hanya 16 LSB yang dikirim di uplink, sedangkan frame counter mungkin berukuran 32-bit.

Semua ini ditangani oleh NS (dan 2. sebagian oleh AS), dan saya tentu tidak berpikir konsol akan melakukan hal yang sama.

Saya pikir jalan ke depan adalah menambahkan acara untuk (1.) - ns.device.reset dan (2.) - ns.device.confirm_session (atau mungkin ns.device.rejoin ?).
Untuk (3.) kita perlu mencari cara untuk mengirimkan nilai FCnt penuh ke konsol. Kami mungkin ingin memperkenalkan acara lain, misalnya ns.up.data.match , atau ns.up.data.handle yang menunjukkan keberhasilan pemrosesan uplink dan mencakup FCnt penuh (dan mungkin lebih). Perhatikan, bahwa ns.up.data.forward tidak terkait di sini dan hanya menunjukkan uplink yang dikirim ke AS, saat ini salah dipublikasikan pada setiap uplink, sekarang akan dipublikasikan hanya ketika benar-benar diteruskan ke AS(PR masuk), juga , payload uplink AS tidak berisi FCnt penuh, tetapi FCnt yang dikirim dalam uplink (jadi, 16 LSB)

Diblokir sampai kami sampai pada kesimpulan tentang acara NS untuk mendorong ini dan itu diimplementasikan di NS.

Ok saya mengerti bahwa ini memang tidak layak untuk saat ini. Lalu bagaimana dengan nilai last seen . Apakah menyimpan untuk mendapatkan nilai awal dari registri perangkat dan kemudian memperbaruinya melalui peristiwa perangkat yang relevan (seperti uplink, downlink yang dikonfirmasi, dll)?

Ok saya mengerti bahwa ini memang tidak layak untuk saat ini. Lalu bagaimana dengan nilai last seen . Apakah menyimpan untuk mendapatkan nilai awal dari registri perangkat dan kemudian memperbaruinya melalui peristiwa perangkat yang relevan (seperti uplink, downlink yang dikonfirmasi, dll)?

Ya, ns.up.data.receive , ns.up.join.receive , ns.up.rejoin.receive adalah yang Anda cari

~Diblokir oleh https://github.com/TheThingsNetwork/lorawan-stack/pull/2221 #2222~

NS sekarang menerbitkan acara ns.up.data.process , yang berisi uplink dengan FCnt penuh sebagai payload

Silakan gunakan nilai di uplink sebagai DevAddr dan FCntUp aktif sebenarnya dari perangkat

Untuk downlink saat ini kami tidak memiliki fungsi yang serupa, tetapi itu juga bukan fokus dari masalah ini, mari kita mulai hanya dengan FCnt uplink dan kemudian menambahkan downlink di tahap selanjutnya (Perhatikan, bahwa tergantung pada versi LoRaWAN kami mungkin sebenarnya memiliki 2 downlink yang berbeda penghitung bingkai - satu untuk NS dan satu untuk AS, jadi penghitung bingkai uplink juga tidak terlalu sepele.)

Setelah kita mengetahui uplink terakhir dalam aplikasi, mari kita ganti Linked dengan Last seen pada tampilan aplikasi (mirip dengan halaman gambaran umum gateway).

Setelah kita mengetahui uplink terakhir dalam aplikasi, mari kita ganti Linked dengan Last seen pada tampilan aplikasi (mirip dengan halaman gambaran umum gateway).

Pasti akan menyenangkan untuk menunjukkan informasi itu secara global untuk aplikasi, tetapi hal itu berarti bahwa konsol perlu menyelidiki semua perangkat akhir yang terkait dengan aplikasi satu demi satu, untuk dapat menunjukkan status terakhir terlihat awal. Saya tidak berpikir ini layak ketika kita harus mengasumsikan aplikasi dengan potensi ratusan atau ribuan perangkat akhir.

Dua hal yang bisa saya pikirkan:

1. Saya dapat menampilkan info yang terakhir terlihat saat tersedia melalui aliran masuk peristiwa pesan perangkat. Bergantung pada pengaturan aplikasi, ini bisa berarti bahwa tidak akan ada acara seperti itu yang tersedia pada waktu yang tepat (pikirkan perangkat akhir yang mengirim downlink setiap jam atau lebih jarang).
2. Kita bisa menggunakan ambang batas jumlah perangkat setelah itu kita berhenti menghitung nilai yang terlihat terakhir pada awalnya. Jika suatu aplikasi memiliki 100+ perangkat, kemungkinan besar peristiwa perangkat yang diperlukan juga akan segera tiba setelah memuat halaman aplikasi.

@htdvisser @rvolosatovs Apakah saya mungkin mengabaikan sesuatu? Atau, dapatkah Anda memikirkan cara apa pun untuk menggabungkan data itu dan membuatnya tersedia melalui titik akhir API?

ApplicationLinkStats hanya memiliki last_up_received_at dan last_downlink_forwarded_at :

https://github.com/TheThingsNetwork/lorawan-stack/blob/develop/api/applicationserver.proto#L56 -L69

Ditutup melalui #2585