> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/id/faq-and-troubleshooting/gps-devices/parking-detection-logic.md).
# Logika Deteksi tempat parkir
Deteksi tempat parkir menggabungkan kecepatan, waktu tidak aktif, dan status pengapian untuk menandai akhir perjalanan. Konfigurasikan ambang batas per perangkat untuk deteksi berhenti yang akurat.
## Pengantar
Deteksi tempat parkir adalah pengaturan inti yang menentukan perjalanan, perhentian, idle, dan peristiwa lain yang terkait gerakan untuk sebuah unit di Navixy. Logikanya menggabungkan kecepatan, waktu inaktivitas minimum, dan, jika tersedia, data tambahan seperti pengapian atau status sensor gerakan.
Sebelum meninjau Laporan atau Aturan peringatan, pastikan perangkat mengirim data yang konsisten dan bahwa konfigurasi sesuai dengan operasi nyata Armada.
Konfigurasikan ini dari **Deteksi tempat parkir**. Ini secara langsung memengaruhi:
* Laporan perjalanan
* Laporan perhentian
* Kelebihan diam
* Perhentian di dalam atau di luar geofence
* Aturan yang bergantung pada status gerakan atau status parkir
Platform hanya menafsirkan data yang diterimanya. Frekuensi pelaporan rendah, derau GPS, status pengapian yang salah, atau data gerakan yang tidak andal akan memengaruhi hasil.
## Konfigurasi utama
Dalam **Deteksi tempat parkir**, Anda menentukan kapan platform harus menganggap unit sebagai Parkir.
* **Deteksi minimum inaktivitas**: Waktu minimum unit harus tetap idle sebelum platform menandainya sebagai Parkir. Jika ini diatur ke 5 menit, kondisi harus bertahan selama 5 menit penuh sebelum status berubah. Rentang yang diizinkan: 1 hingga 1.440 menit.
* **Kecepatan idle maksimum**: Ambang batas kecepatan yang digunakan untuk menganggap unit sebagai idle. Jika ini diatur ke 3 km/jam, platform menganggap kecepatan di bawah 3 km/jam sebagai idle. Jika ini diatur ke 0, deteksi kecepatan idle dinonaktifkan.
* **Pertimbangkan status pengapian**: Menyertakan status mesin dalam **Deteksi tempat parkir**. Agar ini bekerja dengan benar, sensor pengapian harus terhubung secara fisik dan dikonfigurasi di bawah **Sensor dan tombol**. Jika Anda mengaktifkan ini tanpa sensor yang valid, hasilnya mungkin tidak tepat.
* **Pertimbangkan sensor gerakan**: Menyertakan gerakan yang dilaporkan perangkat selain kecepatan dan waktu. Ini dapat membantu ketika derau GPS menyebabkan gerakan palsu, tetapi hanya jika data sensor andal.
## Cara kerja logika tanpa pengapian atau sensor gerakan
Jika opsi ini dinonaktifkan, platform hanya menggunakan kecepatan dan waktu:
1. Kecepatan turun di bawah **Kecepatan idle maksimum**.
2. Platform mulai menghitung waktu.
3. Jika **Deteksi minimum inaktivitas** terpenuhi, unit ditandai sebagai parkir.
4. Jika sebuah paket tiba dengan kecepatan di atas ambang batas, hitungan direset.
Contoh:
Jika inaktivitas diatur ke 5 menit dan kecepatan diatur ke 3 km/jam, platform harus menerima data di bawah 3 km/jam selama 5 menit terus-menerus sebelum menandai unit sebagai parkir. Satu paket di atas ambang batas akan mengatur ulang hitungan.
## Cara perubahan logika saat mempertimbangkan pengapian
Kecepatan saja tidak selalu dapat membedakan antara berhenti operasional, lalu lintas, menunggu dengan mesin menyala, atau akhir perjalanan. Pengapian menambahkan konteks dan membantu memisahkan skenario ini.
Saat opsi ini diaktifkan, platform mengevaluasi kecepatan, waktu, dan status mesin. Jika status pengapian terbalik, hilang, atau terputus-putus, deteksi dapat salah.
Contoh:
Unit telah berada pada 0 km/jam selama beberapa menit.
* **Pengapian mati** → platform dapat memastikan parkir dengan kepastian lebih besar
* **Pengapian menyala** → mungkin sedang menunggu dengan mesin menyala, yang dapat memicu aturan seperti Kelebihan diam
* **Pengapian salah dikonfigurasi** → platform dapat salah menafsirkan kedua kasus
## Cara perubahan logika saat mempertimbangkan sensor gerakan
Saat opsi ini diaktifkan, platform menggunakan status gerakan yang dilaporkan perangkat untuk melengkapi data kecepatan dan waktu.
Ini membantu ketika unit berhenti tetapi derau GPS menimbulkan pergeseran posisi kecil atau kecepatan rendah palsu. Dalam kasus itu, sensor dapat memastikan bahwa unit sebenarnya tidak bergerak.
Jika sensor melaporkan data yang salah, efeknya bisa sebaliknya: perjalanan terpisah, perhentian tertunda, atau gerakan palsu saat unit diam. Validasi sensor sebelum mengaktifkannya.
## Nilai yang disarankan
Gunakan nilai ini sebagai titik awal untuk operasi perkotaan:
* **Deteksi minimum inaktivitas**: 3 hingga 5 menit
* **Kecepatan idle maksimum**: 3 hingga 6 km/jam
Ini bukan nilai universal. Nilai tersebut bergantung pada operasi dan pada apa yang Anda anggap sebagai perhentian.
* Untuk operasi yang perhentian singkatnya penting, waktu yang lebih rendah dapat digunakan.
* Untuk operasi dengan lalu lintas sering atau rute lambat, gunakan waktu yang lebih tinggi untuk mengurangi derau dalam laporan.
* Validasi ambang batas kecepatan dengan data nyata. Jika GPS melaporkan antara 1 dan 4 km/jam saat unit berhenti, ambang batas yang terlalu rendah dapat mencegah deteksi yang benar.
## Praktik terbaik
* **Konfigurasikan Deteksi tempat parkir terlebih dahulu**: Sebelum meninjau Aturan peringatan seperti Kelebihan diam atau perhentian di geofence, validasi bahwa deteksi dasar bekerja dengan benar.
* **Validasi pengapian sebelum mengaktifkannya**: Sensor harus ada di bawah **Sensor dan tombol** dan melaporkan nilai yang benar. Jika tidak, hal itu dapat memengaruhi perjalanan, perhentian, dan Aturan peringatan.
* **Jangan aktifkan sensor gerakan tanpa memvalidasi data**: Pertama, pastikan perangkat mengirim status ini dengan benar. Jika tidak, hal itu dapat memengaruhi perekaman perjalanan dan deteksi perhentian.
* **Tinjau frekuensi pelaporan**: Jika perangkat mengirim data setiap 60 detik, waktu inaktivitas 1 menit tidak sesuai. Waktu minimum harus lebih lama daripada interval pelaporan.
* **Validasi dengan laporan nyata**: Setelah mengubah konfigurasi, tinjau laporan dari hari operasi:
* Laporan perjalanan
* Laporan perhentian
* Laporan parkir, jika berlaku
* **Dokumentasikan perubahan**: Catat nilai sebelumnya, nilai baru, tanggal, alasan, dan perangkat yang terdampak. Jika tidak, akan sulit menjelaskan perubahan berikutnya dalam laporan.
Jika Anda melihat perjalanan terpisah, perhentian semu, atau peristiwa yang tidak sesuai dengan operasi, sesuaikan nilainya dan validasi lagi.
## Kasus umum
* **Unit berhenti tetapi tampak bergerak**: Ambang batas **Kecepatan idle maksimum** mungkin terlalu rendah, atau mungkin ada derau GPS. Jika perangkat melaporkan antara 1 dan 4 km/jam saat unit diam, naikkan ambang batas.
* **Terlalu banyak perjalanan singkat muncul**: Ambang batas **Deteksi minimum inaktivitas** terlalu rendah. Platform menutup perjalanan karena lampu lalu lintas atau jeda singkat. Tingkatkan waktunya dan tinjau lagi.
* **Unit tampak parkir meskipun bergerak perlahan**: Ambang batas **Kecepatan idle maksimum** terlalu tinggi. Jika unit beroperasi pada kecepatan rendah dan ambang batas berada di atasnya, platform menafsirkannya sebagai idle.
* **Kelebihan diam tidak terpicu**: Aturan peringatan bergantung pada status parkir yang dikonfirmasi terlebih dahulu dan pada status pengapian yang diterima dengan benar. Jika **Deteksi tempat parkir** tidak bekerja dengan benar, Aturan peringatan tidak akan terpicu meskipun pengapian menyala. Tinjau **Deteksi tempat parkir** terlebih dahulu, lalu Aturan peringatan.
* **Perbedaan antara idle platform dan idle perangkat keras**: Idle platform bergantung pada logika Navixy, Deteksi tempat parkir, dan status pengapian yang diterima. Idle perangkat keras berasal dari peristiwa yang dihasilkan langsung oleh perangkat.
* **Perjalanan tidak direkam dengan benar saat menggunakan sensor gerakan**: Jika sensor melaporkan data yang salah, perjalanan mungkin tidak dibatasi seperti yang diharapkan. Tinjau data sensor terlebih dahulu.
* **Deteksi berubah setelah mengaktifkan pengapian**: Sebelum menganggap ini masalah platform, tinjau status pengapian yang diterima dari perangkat.
## Rekomendasi untuk mencegah celah rute
Tinjau item ini terlebih dahulu:
* Deteksi minimum inaktivitas
* Kecepatan idle maksimum
* Frekuensi pelaporan perangkat
* Kecepatan yang dilaporkan selama periode tersebut
* Kualitas sinyal GPS
* Penggunaan GPS atau LBS
* Status pengapian, jika berlaku, dan konfigurasinya di bawah **Sensor dan tombol**
* Sensor gerakan, jika berlaku, dan apakah melaporkan dengan benar
* Aturan platform dan perangkat keras aktif pada waktu yang sama
Platform menerapkan logika yang dikonfigurasi pada data yang diterimanya. Jika paket tiba dengan frekuensi rendah, derau, atau nilai yang tidak konsisten, hasilnya akan mencerminkan kondisi tersebut.
## Catatan akhir
**Deteksi tempat parkir** tidak mengoreksi data perangkat. Ini hanya menafsirkan data masuk berdasarkan nilai yang dikonfigurasi. Jika pengapian atau sensor gerakan diaktifkan, data itu juga menjadi bagian dari logika.
Sebelum menyesuaikan aturan atau laporan, pastikan perangkat mengirim cukup data yang konsisten agar sesuai dengan operasi nyata.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://navixy.com/docs/expert-center/id/faq-and-troubleshooting/gps-devices/parking-detection-logic.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.