Cara Menerapkan Penjadwalan Berbasis Peristiwa Menggunakan Unix Time dalam IoT Logic
Di bagian ini, kami akan mengonfigurasi timer di IoT Logic untuk mengontrol aktivasi keluaran pada perangkat. Ini akan berfungsi sebagai penjadwal dengan memanfaatkan waktu Unix untuk kontrol berbasis waktu.

Pertama, logika penjadwal dibangun berdasarkan waktu Unix, karena itu adalah satu-satunya parameter yang andal dan konsisten yang selalu dapat kami andalkan. Elemen kunci kedua adalah cap waktu dari paket valid yang diterima oleh platform. Penting untuk dicatat bahwa logika ini mengharuskan perangkat untuk terus-menerus mengirim paket data valid ke platform. Frekuensinya sendiri tidak kritis; namun, jika tidak ada pesan masuk yang diterima, maka menjadi tidak mungkin untuk mengevaluasi waktu atau memicu tindakan terjadwal apa pun.
Sekarang, beralih ke node perhitungan atribut logika yang diimplementasikan. Node ini mengambil:
Waktu peristiwa saat ini (current_time) dari paket terbaru
Waktu peristiwa sebelumnya (prev_time) dari paket sebelumnya
Kedua nilai dikonversi dari milidetik ke 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 akan kami gunakan untuk semua perhitungan.
Dari sini, sistem menghitung:
current_sod (detik dalam sehari)
prev_sod (detik dalam sehari untuk paket sebelumnya)
Ini dilakukan menggunakan operasi modulus, yang mengekstrak jumlah detik yang berlalu sejak tengah malam, secara efektif mengonversi waktu Unix menjadi referensi waktu dalam sehari.
Offset waktu mungkin terlihat dalam rumus-rumus ini. Offset ini ditentukan oleh zona waktu UTC tempat perhitungan dilakukan.
Dalam skenario pengujian, perhitungan dilakukan pada UTC -6, sehingga menghasilkan selisih 6 jam. Jika dikonversi ke detik, ini setara dengan: 6 jam × 60 menit × 60 detik = 21.600 detik.
Dengan menggunakan nilai-nilai ini, sistem mendeteksi transisi waktu, bukan keadaan berkelanjutan.
Contoh:
Kondisi nyala (misalnya, pukul 8 malam): Sistem memeriksa kapan waktu melewati ambang batas:
Kondisi mati (misalnya, pukul 5 pagi):
Ini memastikan bahwa tindakan hanya dipicu sekali pada saat transisi, bukan terus-menerus selama seluruh jendela waktu.
Setelah logika terpenuhi, node tindakan akan memicu perintah keluaran untuk mengubah status keluaran. Beberapa keterbatasan dapat muncul sepanjang alur ini, dan penting untuk menyorotinya agar dapat dipertimbangkan:
Tergantung pada data masuk:
Jika perangkat berhenti mengirim data, tidak ada tindakan yang akan dipicu. Inilah sebabnya pemantauan unit secara terus-menerus diperlukan. Jika perangkat terputus, macet, atau dalam mode tidur tanpa mengirim data valid, perubahan status tidak akan 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 pukul 20:58, pesan berikutnya akan tiba pada pukul 21:03. Pada saat itu, logika akan terpenuhi dan tindakan (misalnya, aktivasi output) akan dipicu.
Diperlukan penanganan zona waktu:
Karena waktu Unix berada dalam UTC, offset harus diterapkan agar selaras dengan waktu lokal yang diinginkan.
Tidak ada status penjadwalan persisten:
Sistem tidak menyimpan waktu pemicu di masa depan; sistem sepenuhnya bergantung pada perbandingan real-time antara paket masuk yang berurutan.
Solusi ini mensimulasikan penjadwal dalam sistem berbasis peristiwa dengan menggunakan cap waktu Unix dan mendeteksi transisi waktu antar paket data yang berurutan. Meskipun ini bukan penjadwal yang sesungguhnya, solusi ini menyediakan cara yang andal dan skalabel untuk menerapkan otomasi berbasis waktu tanpa memerlukan dukungan penjadwalan bawaan.
Terakhir diperbarui
Apakah ini membantu?