Memilih Protokol IoT untuk Fleet Monitoring: MQTT, HTTP, atau LoRaWAN

Dalam banyak rapat teknis, pilihan protokol diputuskan lebih cepat daripada yang seharusnya. Seseorang menyebut MQTT karena pernah memakainya, seseorang lain menyebut LoRaWAN karena hemat daya, dan diskusi selesai sebelum siapa pun menanyakan berapa sering data perlu dikirim.

Padahal ketiga protokol ini menjawab persoalan yang berbeda. Memilih yang salah tidak langsung terasa — sistemnya tetap jalan — tetapi tagihan, konsumsi baterai, atau keterlambatan data akan menagih di kemudian hari.

HTTP: sederhana, mahal untuk data kecil yang sering

HTTP adalah protokol yang sama dengan yang dipakai browser Anda. Setiap pengiriman data adalah permintaan mandiri: buka koneksi, kirim header, kirim isi, terima balasan, tutup.

Kelebihannya nyata. Hampir setiap bahasa pemrograman dan setiap perangkat mendukungnya. Debugging mudah karena bisa diuji dengan alat biasa. Menembus firewall perusahaan tanpa negosiasi khusus.

Masalahnya muncul saat data kecil dikirim sering. Header HTTP saja bisa beberapa ratus byte, sementara isi pesan posisi kendaraan mungkin hanya 50 byte. Anda membayar lebih banyak untuk amplop daripada untuk surat. Dikalikan 100 unit yang mengirim tiap 30 detik, selama sebulan, selisihnya menjadi biaya data yang nyata.

Masuk akal ketika: pengiriman jarang (beberapa menit sekali atau lebih), jumlah unit sedikit, atau saat perangkat harus berbicara dengan sistem lama yang hanya menyediakan REST API.

MQTT: dirancang untuk banyak perangkat yang bicara terus

MQTT bekerja dengan cara yang berbeda. Perangkat membuka satu koneksi ke server perantara (broker) dan mempertahankannya. Setelah koneksi berdiri, mengirim pesan hanya butuh beberapa byte tambahan, bukan header lengkap.

Perbedaan ini besar. Untuk armada yang mengirim posisi setiap beberapa detik, MQTT bisa memangkas konsumsi data secara signifikan dibanding HTTP.

Beberapa hal yang membuatnya cocok untuk fleet monitoring:

• Koneksi tetap terbuka, sehingga server juga bisa mengirim perintah ke perangkat kapan saja — misalnya mengubah interval pelaporan atau meminta posisi sekarang juga. Dengan HTTP, perangkat harus rajin bertanya, yang boros.
• Tingkat jaminan pengiriman bisa dipilih. Data posisi rutin boleh dikirim sekali tanpa konfirmasi. Peringatan mesin panas sebaiknya dijamin sampai. MQTT membedakan keduanya lewat pengaturan QoS.
• Pesan terakhir bisa disimpan. Dashboard yang baru dibuka bisa langsung menerima kondisi terakhir tiap unit tanpa menunggu siklus laporan berikutnya.
• Pesan perpisahan otomatis. Jika perangkat mati mendadak, broker bisa mengirimkan pesan yang sudah disiapkan sebelumnya. Status "offline" muncul tanpa perlu menebak dari waktu tunggu.

Konsekuensi yang perlu diterima: ada komponen tambahan yang harus dijalankan dan dijaga, yaitu broker. Ia perlu dipantau, diamankan, dan dipikirkan ketahanannya. Untuk armada berukuran serius, biaya pengelolaan ini sepadan. Untuk sepuluh unit yang melapor tiap lima menit, mungkin berlebihan.

LoRaWAN: jangkauan jauh dengan data yang sangat sedikit

LoRaWAN berada di kategori yang berbeda. Ia bukan pengganti MQTT atau HTTP, melainkan jaringan radio tersendiri yang tidak memakai seluler sama sekali.

Kekuatannya ada dua: jangkauan bisa mencapai beberapa kilometer di area terbuka, dan konsumsi daya sangat rendah sehingga perangkat bisa hidup bertahun-tahun dengan satu baterai.

Harga dari kekuatan itu adalah kapasitas. Pesan LoRaWAN hanya sekitar puluhan byte, dan aturan penggunaan frekuensi membatasi seberapa sering perangkat boleh mengudara. Mengirim data setiap sepuluh detik bukan hal yang bisa dilakukan.

Masuk akal ketika: aset bergerak lambat atau diam, seperti kontainer, genset, tangki, alat berat di area tambang, atau sensor di gudang. Cukup tahu posisi dan kondisi beberapa kali sehari, dan tidak ada listrik untuk mengisi ulang.

Tidak masuk akal ketika: Anda perlu melihat kendaraan bergerak hampir real-time di peta kota.

Cara memilih tanpa terjebak tren

Alih-alih memulai dari nama protokol, mulailah dari empat pertanyaan tentang kondisi Anda sendiri:

Seberapa sering data perlu diperbarui? Kalau jawabannya "beberapa detik", LoRaWAN gugur. Kalau jawabannya "dua kali sehari", MQTT mungkin kompleksitas yang tidak perlu.

Apakah perangkat punya sumber listrik? Kendaraan punya aki. Kontainer di halaman tidak. Ini sering langsung menentukan pilihan.

Apakah server perlu mengirim perintah ke perangkat? Kalau ya, protokol dengan koneksi tetap seperti MQTT jauh lebih praktis.

Berapa banyak unit, dan akan bertambah berapa? Selisih biaya antar protokol nyaris tidak terasa pada sepuluh unit, dan sangat terasa pada seribu. Rancang untuk jumlah dua tahun ke depan, bukan jumlah hari ini.

Kombinasi sering lebih tepat daripada satu pilihan

Sistem yang matang jarang memakai satu protokol untuk semua hal. Pola yang lazim di lapangan:

Kendaraan aktif memakai perangkat seluler dengan MQTT untuk pelaporan posisi berfrekuensi tinggi. Aset diam di area yang sama memakai sensor LoRaWAN yang melapor beberapa kali sehari. Keduanya bermuara ke satu server yang menyeragamkan format data. Sistem lain di perusahaan — ERP, sistem penggajian, aplikasi pelanggan — mengambil data dari server itu lewat REST API biasa, karena di lapisan itu HTTP justru pilihan paling tepat.

Yang menentukan keberhasilan bukan protokol mana yang dipilih, melainkan apakah lapisan penyeragaman di tengah dirancang dengan benar. Protokol bisa diganti belakangan tanpa terlalu menyakitkan. Struktur data yang berantakan jauh lebih mahal untuk diperbaiki.