> 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 Parkir

### Pendahuluan

Deteksi parkir adalah pengaturan inti yang menentukan perjalanan, pemberhentian, idle, dan peristiwa lain yang terkait dengan pergerakan untuk suatu unit di Navixy. Logikanya menggabungkan kecepatan, waktu tidak aktif minimum, dan, jika tersedia, data tambahan seperti status kontak atau sensor gerak.

Sebelum meninjau laporan atau peringatan, pastikan perangkat mengirimkan data yang konsisten dan bahwa konfigurasi sesuai dengan operasi nyata armada.

<img src="/files/a1bca27ef51e8b7729c16c6c8c352f645bf56ba0" alt="" height="336" width="624">

Konfigurasikan ini dari **Deteksi Parkir**. Hal ini secara langsung memengaruhi:

* Laporan perjalanan
* Laporan pemberhentian
* Idle berlebihan
* Pemberhentian di dalam atau di luar geofence
* Aturan yang bergantung pada status bergerak atau parkir

<img src="/files/feb8bc79dae01b0977325de5c80ce594b42e11fa" alt="" height="519" width="624">

Platform hanya menafsirkan data yang diterimanya. Frekuensi pelaporan yang rendah, noise GPS, status kontak yang salah, atau data gerak yang tidak andal akan memengaruhi hasil.

### Konfigurasi utama

Di **Deteksi Parkir**, Anda menentukan kapan platform harus menganggap suatu unit sedang parkir.

<img src="/files/e372c2535115885e459fc34062bdd349f36dec86" alt="" height="404" width="624">

* **Deteksi ketidakaktifan minimum**: Waktu minimum unit harus tetap tidak bergerak sebelum platform menandainya sebagai parkir. Jika ini disetel ke 5 menit, kondisi harus berlangsung selama penuh 5 menit sebelum status berubah. Rentang yang diizinkan: 1 hingga 1440 menit.
* **Kecepatan idle maksimum**: Ambang kecepatan yang digunakan untuk menganggap unit sedang idle. Jika ini disetel ke 3 km/jam, platform menganggap kecepatan di bawah 3 km/jam sebagai idle. Jika ini disetel ke 0, deteksi kecepatan idle dinonaktifkan.
* **Perhitungkan status kontak**: Menyertakan status mesin dalam **Deteksi Parkir**. Agar ini berfungsi dengan benar, sensor kontak harus terhubung secara fisik dan dikonfigurasikan di **Sensor dan Tombol**. Jika Anda mengaktifkan ini tanpa sensor yang valid, hasilnya mungkin tidak akurat.
* **Perhitungkan sensor gerak**: Menyertakan pergerakan yang dilaporkan perangkat selain kecepatan dan waktu. Ini dapat membantu saat noise GPS menyebabkan pergerakan palsu, tetapi hanya jika data sensor dapat diandalkan.

### Bagaimana logikanya bekerja tanpa kontak atau sensor gerak

<img src="/files/09d39bb19a8583926a7d01623939323ce2d52733" alt="" height="405" width="624">

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 ketidakaktifan minimum** terpenuhi, unit ditandai sebagai parkir.
4. Jika sebuah paket datang dengan kecepatan di atas ambang, hitungan diatur ulang.

Contoh:

Jika ketidakaktifan disetel ke 5 menit dan kecepatan disetel ke 3 km/jam, platform harus menerima data di bawah 3 km/jam selama 5 menit berturut-turut sebelum menandai unit sebagai parkir. Satu paket di atas ambang akan mengatur ulang hitungan.

### Bagaimana logikanya berubah saat memperhitungkan kontak

Kecepatan saja tidak selalu dapat membedakan antara pemberhentian operasional, kemacetan, menunggu dengan mesin menyala, atau akhir perjalanan. Kontak menambahkan konteks dan membantu memisahkan skenario-skenario ini.

Saat opsi ini diaktifkan, platform mengevaluasi kecepatan, waktu, dan status mesin. Jika status kontak terbalik, hilang, atau terputus-putus, deteksi dapat menjadi salah.

Contoh:

Unit telah berada pada 0 km/jam selama beberapa menit.

* **Kontak mati** → platform dapat memastikan parkir dengan kepastian yang lebih tinggi
* **Kontak menyala** → mungkin sedang menunggu dengan mesin menyala, yang dapat memicu aturan seperti idle berlebihan
* **Kontak dikonfigurasikan secara salah** → platform dapat salah menafsirkan kedua kasus

### Bagaimana logikanya berubah saat memperhitungkan sensor gerak

Saat opsi ini diaktifkan, platform menggunakan status pergerakan yang dilaporkan oleh perangkat untuk melengkapi data kecepatan dan waktu.

Ini membantu saat unit berhenti tetapi noise GPS menciptakan pergeseran posisi kecil atau kecepatan rendah palsu. Dalam kasus itu, sensor dapat mengonfirmasi bahwa unit sebenarnya tidak bergerak.

Jika sensor melaporkan data yang salah, dampaknya bisa sebaliknya: perjalanan terpecah, pemberhentian terlambat, atau pergerakan palsu saat unit diam. Validasi sensor sebelum mengaktifkannya.

### Nilai yang direkomendasikan

Gunakan nilai ini sebagai titik awal untuk operasi perkotaan:

* **Deteksi ketidakaktifan minimum**: 3 hingga 5 menit
* **Kecepatan idle maksimum**: 3 hingga 6 km/jam

Nilai-nilai ini bukan nilai universal. Nilai tersebut bergantung pada operasi dan pada apa yang Anda anggap sebagai pemberhentian.

* Untuk operasi yang memperhatikan pemberhentian singkat, waktu yang lebih rendah dapat digunakan.
* Untuk operasi dengan kemacetan yang sering atau rute lambat, gunakan waktu yang lebih tinggi untuk mengurangi noise dalam laporan.
* Validasi ambang kecepatan dengan data nyata. Jika GPS melaporkan antara 1 dan 4 km/jam saat unit berhenti, ambang yang terlalu rendah dapat mencegah deteksi yang benar.

### Praktik terbaik

* **Konfigurasikan Deteksi Parkir terlebih dahulu**: Sebelum meninjau peringatan seperti idle berlebihan atau pemberhentian di geofence, validasi bahwa deteksi dasar bekerja dengan benar.
* **Validasi kontak sebelum mengaktifkannya**: Sensor harus ada di bawah **Sensor dan Tombol** dan melaporkan nilai yang benar. Jika tidak, ini dapat memengaruhi perjalanan, pemberhentian, dan peringatan.
* **Jangan aktifkan sensor gerak tanpa memvalidasi data**: Pertama pastikan perangkat mengirimkan status ini dengan benar. Jika tidak, ini dapat memengaruhi pencatatan perjalanan dan deteksi pemberhentian.
* **Tinjau frekuensi pelaporan**: Jika perangkat mengirim data setiap 60 detik, waktu tidak aktif 1 menit tidak sesuai. Waktu minimum harus lebih panjang daripada interval pelaporan.
* **Validasi dengan laporan nyata**: Setelah mengubah konfigurasi, tinjau laporan dari hari operasional:
  * Laporan perjalanan
  * Laporan pemberhentian
  * Laporan parkir, jika berlaku
* **Dokumentasikan perubahan**: Catat nilai sebelumnya, nilai baru, tanggal, alasan, dan perangkat yang terdampak. Jika tidak, akan sulit menjelaskan perubahan laporan di kemudian hari.

Jika Anda melihat perjalanan terpecah, pemberhentian hantu, atau peristiwa yang tidak sesuai dengan operasi, sesuaikan nilainya dan validasi lagi.

### Kasus umum

* **Unit berhenti tetapi tampak bergerak**: **Kecepatan idle maksimum** mungkin terlalu rendah, atau mungkin ada noise GPS. Jika perangkat melaporkan antara 1 dan 4 km/jam saat unit diam, naikkan ambang.
* **Terlalu banyak perjalanan singkat muncul**: **Deteksi ketidakaktifan minimum** terlalu rendah. Platform menutup perjalanan karena lampu lalu lintas atau jeda singkat. Tingkatkan waktunya dan tinjau lagi.
* **Unit tampak parkir meskipun bergerak lambat**: **Kecepatan idle maksimum** terlalu tinggi. Jika unit beroperasi pada kecepatan rendah dan ambang berada di atasnya, platform menafsirkannya sebagai idle.
* **Idle berlebihan tidak terpicu**: Peringatan bergantung pada status parkir yang terlebih dahulu terkonfirmasi dan pada status kontak yang diterima dengan benar. Jika **Deteksi Parkir** tidak berfungsi dengan benar, peringatan tidak akan terpicu meskipun kontak menyala. Tinjau **Deteksi Parkir** terlebih dahulu, lalu peringatannya.
* **Perbedaan antara idle platform dan idle perangkat keras**: Idle platform bergantung pada logika Navixy, deteksi parkir, dan status kontak yang diterima. Idle perangkat keras berasal dari peristiwa yang dihasilkan langsung oleh perangkat.
* **Perjalanan tidak tercatat dengan benar saat menggunakan sensor gerak**: Jika sensor melaporkan data yang salah, perjalanan mungkin tidak dibatasi sesuai harapan. Tinjau data sensor terlebih dahulu.
* **Deteksi berubah setelah mengaktifkan kontak**: Sebelum menganggap ini sebagai masalah platform, tinjau status kontak yang diterima dari perangkat.

### Rekomendasi untuk mencegah celah rute

Tinjau item berikut terlebih dahulu:

* Deteksi ketidakaktifan minimum
* Kecepatan idle maksimum
* Frekuensi pelaporan perangkat
* Kecepatan yang dilaporkan selama periode tersebut
* Kualitas sinyal GPS
* Penggunaan GPS atau LBS
* Status kontak, jika berlaku, dan konfigurasinya di bawah **Sensor dan Tombol**
* Sensor gerak, jika berlaku, dan apakah melaporkan dengan benar
* Aturan platform dan perangkat keras aktif pada saat yang sama

Platform menerapkan logika yang dikonfigurasikan pada data yang diterimanya. Jika paket tiba dengan frekuensi rendah, noise, atau nilai yang tidak konsisten, hasilnya akan mencerminkan kondisi tersebut.

### Catatan akhir

**Deteksi Parkir** tidak memperbaiki data perangkat. Platform hanya menafsirkan data masuk berdasarkan nilai yang dikonfigurasikan. Jika kontak atau sensor gerak diaktifkan, data tersebut juga menjadi bagian dari logika.

Sebelum menyesuaikan aturan atau laporan, pastikan perangkat mengirimkan 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://navixy.com/docs/expert-center/id/faq-and-troubleshooting/gps-devices/parking-detection-logic.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
