> 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/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md). # Cara mengimplementasikan Penjadwalan berbasis peristiwa menggunakan waktu Unix di IoT Logic Jadwalkan aksi output berbasis pengatur waktu di IoT Logic menggunakan stempel waktu Unix. Picu perintah perangkat pada waktu yang tepat dengan pelaporan perangkat kontinu diaktifkan. Di bagian ini, konfigurasikan timer di IoT Logic untuk mengendalikan aktivasi output pada perangkat. Ini berfungsi sebagai penjadwal dengan menggunakan waktu Unix untuk kontrol berbasis waktu.
Pertama, logika penjadwalan dibangun berdasarkan waktu Unix, karena itu adalah satu-satunya parameter yang andal dan konsisten yang selalu dapat kita andalkan. Elemen kunci kedua adalah stempel waktu paket valid yang diterima oleh platform Navixy.\ Penting untuk dicatat bahwa logika ini mengharuskan perangkat terus-menerus mengirim paket data valid ke platform. Frekuensinya sendiri tidak kritis; namun, jika tidak ada Pesan masuk yang diterima, menjadi mustahil untuk mengevaluasi waktu atau memicu tindakan terjadwal apa pun. \ Sekarang, Bergerak ke node perhitungan atribut logika yang diterapkan.\ Node ini mengambil: * Waktu kejadian saat ini (current\_time) dari paket terbaru * Waktu kejadian sebelumnya (prev\_time) dari paket sebelumnya Kedua nilai dikonversi dari milidetik menjadi detik.
Penting untuk dicatat bahwa **genTime** disediakan dalam waktu Unix (milidetik) dan harus dibagi 1000 untuk memperoleh waktu Unix dalam detik, yang merupakan format yang digunakan untuk semua perhitungan. \ Dari sini, sistem menghitung: * current\_sod (detik dalam sehari) * prev\_sod (detik dalam sehari untuk paket sebelumnya) Ini dilakukan menggunakan operasi modulo, yang mengekstrak jumlah detik yang berlalu sejak tengah malam, yang secara efektif mengonversi waktu Unix menjadi referensi waktu dalam sehari. 
time % 86400
Offset waktu dapat terlihat dalam rumus ini. Offset ini ditentukan oleh zona waktu UTC tempat perhitungan dilakukan. Dalam skenario pengujian, perhitungan dilakukan pada UTC -6, yang menghasilkan selisih 6 jam. Saat dikonversi menjadi detik, ini setara dengan:\ 6 jam × 60 menit × 60 detik = 21.600 detik. {% code overflow="wrap" %} ``` current_sod = (current_time - offset_time) % 86400 prev_sod = (prev_time - offset_time) % 86400 ``` {% endcode %} \ Dengan nilai-nilai ini, sistem mendeteksi transisi waktu, bukan keadaan kontinu. \ Misalnya: * Kondisi menyalakan (mis., pukul 20.00):Sistem memeriksa kapan waktu melampaui ambang batas: 
prev_sod < 72000 AND current_sod >= 72000
* Kondisi mematikan (mis., pukul 05.00): 
prev_sod < 18000 AND current_sod >= 18000
Ini memastikan bahwa tindakan hanya dipicu satu kali pada saat transisi, bukan terus-menerus selama seluruh jendela waktu. \ Setelah logika terpenuhi, node aksi akan memicu perintah output untuk mengubah status output.\ Beberapa keterbatasan dapat muncul sepanjang aliran ini, dan penting untuk menyorotnya agar dapat dipertimbangkan:
* **Tergantung pada data masuk:** Jika perangkat berhenti mengirim data, tidak ada tindakan yang dipicu. Inilah alasan pemantauan unit secara terus-menerus diperlukan. Jika perangkat terputus, terganggu, atau dalam Mode Sleep tanpa mengirim data valid, perubahan status tidak pernah terdeteksi.
* **Tidak ada jaminan waktu eksekusi yang tepat:** Tindakan dieksekusi ketika paket data berikutnya tiba setelah ambang batas terpenuhi, bukan tepat pada waktu yang dijadwalkan. Misalnya, jika perangkat melaporkan setiap 5 menit dan paket terakhir diterima pada 20:58, Pesan berikutnya akan tiba pada 21:03. Pada saat itu, logika akan terpenuhi dan tindakan (mis., aktivasi output) akan dipicu.
* **Penanganan zona waktu diperlukan:** Karena waktu Unix berada dalam UTC, offset harus diterapkan untuk menyesuaikannya dengan waktu lokal yang diinginkan.
* **Tidak ada status penjadwalan persisten:** Sistem tidak menyimpan waktu pemicu di masa depan; sistem sepenuhnya bergantung pada perbandingan waktu nyata antara paket masuk berurutan. Solusi ini mensimulasikan penjadwal dalam sistem berbasis peristiwa dengan menggunakan stempel waktu Unix dan mendeteksi transisi waktu antara paket data berurutan. Meskipun ini bukan penjadwal yang sebenarnya, solusi ini menyediakan cara yang andal dan skalabel untuk menerapkan otomatisasi berbasis waktu tanpa memerlukan dukungan penjadwalan bawaan. --- # 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/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-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.