Perbandingan protokol ringan untuk perangkat IoT biasanya berujung pada tiga nama: CoAP, MQTT, dan LwM2M. Ketiganya bisa berjalan di mikrokontroler dengan RAM di bawah 64 KB, tetapi cara kerja dan biaya implementasinya berbeda jauh. Pilihan yang tepat bergantung pada pola komunikasi, jumlah perangkat, dan siapa yang akan mengelola server.
Dasar perbandingan: apa yang sebenarnya dihemat protokol ringan
Semua protokol di daftar ini memakai UDP atau TCP dengan header kecil, lalu menambahkan mekanisme sendiri untuk keandalan. CoAP memakai UDP dengan model request-response mirip HTTP. MQTT memakai TCP dengan model publish-subscribe lewat broker. LwM2M berjalan di atas CoAP sebagai lapisan manajemen perangkat.
Karena itu, membandingkan ketiganya secara langsung agak mirip membandingkan kurir, kantor pos, dan sistem administrasi pengiriman. Yang satu mengatur cara paket berpindah, yang lain mengatur bagaimana status paket dipantau. Memahami perbedaan lapisan ini membuat pemilihan jadi lebih masuk akal.
CoAP: request-response di atas UDP
CoAP mempertahankan gaya REST. Setiap sumber daya punya URL, dan klien mengirim GET, POST, PUT, atau DELETE. Untuk perangkat yang hanya sesekali melaporkan sensor, pola ini hemat karena koneksi tidak perlu dijaga terus-menerus.
Kelemahan UDP adalah paket bisa hilang atau datang tidak berurutan. CoAP menutupinya dengan pesan CON (confirmable) yang harus diakui penerima, plus mekanisme retransmisi dengan backoff. Untuk data sensor yang dikirim tiap beberapa menit, ini biasanya cukup.
CoAP juga mendukung observe, sehingga klien bisa berlangganan perubahan nilai sumber daya tanpa polling. Fitur ini berguna pada aktuator yang statusnya perlu dipantau, misalnya relay atau katup. Namun implementasi observe di sisi server kadang tidak konsisten antar library, jadi uji dulu sebelum dipakai di produksi.
Kapan CoAP masuk akal
- Perangkat mengirim data ke endpoint HTTP-like yang sudah ada, sehingga integrasi ke backend relatif mudah lewat proxy CoAP-to-HTTP.
- Jumlah perangkat dalam ratusan, bukan puluhan ribu, sehingga pengelolaan koneksi masih bisa ditangani server biasa.
- Perangkat berada di jaringan dengan latency rendah dan kehilangan paket kecil, misalnya LAN pabrik.
- Firmware dibatasi ketat, misalnya mikrokontroler 32 KB flash, karena implementasi CoAP minimal bisa jauh lebih kecil dari stack MQTT.
MQTT: publish-subscribe lewat broker
MQTT memisahkan pengirim dan penerima melalui broker. Perangkat cukup membuka satu koneksi TCP ke broker, lalu publish ke topik atau subscribe ke topik. Model ini cocok ketika satu pembacaan sensor harus sampai ke beberapa konsumen sekaligus, misalnya dasbor, basis data, dan sistem peringatan.
Koneksi TCP yang dijaga tetap hidup memakan RAM dan daya, terutama jika keepalive diatur pendek. Di perangkat bertenaga baterai, MQTT dengan koneksi permanen sering jadi pilihan mahal. Sebagian implementasi mengakalinya dengan koneksi singkat atau memakai MQTT-SN di atas UDP, tetapi dukungan broker untuk MQTT-SN belum seluas MQTT biasa.
QoS di MQTT memberi tingkatan jaminan pengiriman. QoS 0 paling ringan tetapi bisa hilang, QoS 1 menjamin setidaknya sekali sampai, QoS 2 menjamin tepat sekali dengan biaya handshake tambahan. Pilih tingkat paling rendah yang masih memenuhi kebutuhan; banyak proyek sensor cukup dengan QoS 0 atau 1.
Jika perangkat Anda memakai Wi-Fi dan mengirim data lewat internet, membandingkan MQTT dengan HTTP perlu dilakukan lebih dulu karena keduanya sering dipakai di jalur yang sama. Ulasan MQTT vs HTTP untuk perangkat IoT membahas biaya koneksi dan pola pengiriman data dari sisi itu.
Kapan MQTT masuk akal
- Banyak konsumen membaca data yang sama, sehingga arsitektur pub-sub menghemat jalur komunikasi.
- Perangkat berada di balik NAT atau firewall ketat dan tidak bisa menerima koneksi masuk, karena koneksi keluar ke broker selalu bisa dibuka.
- Butuh pengiriman perintah dari server ke perangkat dengan latensi rendah, misalnya kontrol aktuator.
- Tim sudah familiar dengan broker seperti Mosquitto atau EMQX dan tidak ingin menulis server sendiri.
LwM2M: manajemen perangkat di atas CoAP
LwM2M menambahkan model objek dan sumber daya yang terstandar di atas CoAP. Artinya, bukan hanya transport yang diatur, tetapi juga cara perangkat melaporkan inventaris, melakukan registrasi ke server manajemen, dan menerima perintah konfigurasi. Ini berguna ketika perangkat dipasang di lapangan dan perlu diperbarui dari jarak jauh.
Biaya implementasinya paling tinggi di antara ketiganya. Anda perlu server LwM2M yang mendukung bootstrap, registrasi, dan manajemen objek. Untuk prototipe kecil, beban ini sering tidak sepadan. Untuk armada perangkat yang tersebar dan harus dikelola oleh tim operasi, justru di sinilah nilai LwM2M terlihat.
Fitur seperti firmware update over the air dan pemantauan status koneksi sudah punya definisi objek tersendiri, sehingga integrasi antar vendor lebih mudah selama keduanya mengikuti spesifikasi. Tanpa standar ini, setiap proyek cenderung membuat protokol manajemen sendiri.
| Aspek | CoAP | MQTT | LwM2M |
|---|---|---|---|
| Transport | UDP | TCP | UDP (via CoAP) |
| Model | Request-response | Publish-subscribe | Manajemen objek |
| Koneksi | Tidak permanen | Umumnya permanen | Tidak permanen |
| Kebutuhan server | Proxy atau endpoint | Broker | Server manajemen |
| Cocok untuk | Sensor sesekali | Banyak konsumen data | Armada perangkat terkelola |
Konsumsi daya dan memori di mikrokontroler
Angka pasti bergantung pada library dan konfigurasi, tetapi polanya cukup jelas. CoAP umumnya paling ringan karena tidak menjaga koneksi. MQTT lebih berat karena TCP dan keepalive, meskipun sebagian beban bisa ditekan dengan interval yang lebih longgar. LwM2M berada di atas CoAP, jadi konsumsi dayanya mirip CoAP ditambah biaya registrasi dan pembaruan objek.
Di sisi memori, stack CoAP minimal bisa berjalan di puluhan kilobyte flash. Stack MQTT dengan TLS membutuhkan ruang lebih besar, terutama untuk handshake dan buffer. Jika board yang Anda pakai pas-pasan, pertimbangkan pilihan board sejak awal; panduan memilih board mikrokontroler untuk proyek IoT membahas kebutuhan flash dan RAM untuk skenario seperti ini.
Keandalan dan penanganan kegagalan
CoAP mengandalkan retransmisi di level pesan. Jika perangkat mati saat menunggu ACK, data bisa hilang tanpa jejak kecuali aplikasi menyimpan antrean sendiri. MQTT dengan QoS 1 atau 2 dan sesi persisten bisa menyimpan pesan di broker saat perangkat offline, lalu mengirimkannya ketika perangkat kembali. Untuk data yang tidak boleh hilang, perbedaan ini penting.
LwM2M menyediakan mekanisme registrasi ulang dan pelaporan status, sehingga server tahu kapan perangkat terakhir terlihat. Ini memudahkan deteksi perangkat mati di lapangan tanpa harus menebak dari data sensor yang berhenti.
Di semua pilihan, keandalan tetap bergantung pada firmware. Antrean pesan, penyimpanan sementara di flash, dan strategi reconnect perlu dirancang sejak awal. Rujukan tips memulai firmware mikrokontroler berguna untuk menyusun struktur kode yang siap menghadapi koneksi putus-nyambung.
Kemudahan implementasi dan ekosistem
MQTT punya ekosistem paling luas. Hampir semua bahasa punya klien matang, broker tersedia dalam paket siap pakai, dan banyak penyedia cloud menerima MQTT secara langsung. Untuk tim kecil yang ingin cepat jalan, ini sering jadi faktor penentu.
CoAP lebih terbatas tetapi cukup mapan di lingkungan perangkat hemat daya. Library tersedia untuk banyak platform, meski kualitas dan kelengkapan fitur observe bervariasi. Integrasi ke backend biasanya lewat proxy, dan di sinilah pekerjaan tambahan muncul.
LwM2M paling niche. Pilihannya masuk akal jika Anda memang membutuhkan manajemen armada dengan standar terbuka, misalnya pada produk yang akan dipakai klien enterprise. Untuk proyek hobi atau internal, biasanya terlalu berat.
Ringkasan pemilihan
Untuk sensor baterai yang melaporkan data sesekali, CoAP biasanya paling hemat. Untuk sistem dengan banyak konsumen data dan kebutuhan perintah dua arah, MQTT lebih praktis. Untuk armada perangkat yang harus dikelola dari jarak jauh dengan pembaruan firmware dan inventaris, LwM2M memberi struktur yang tidak perlu Anda rancang sendiri.
Jika nanti perangkat Anda juga perlu menyajikan data ke halaman web internal, urusan penyajian di sisi server bisa dikerjakan terpisah, misalnya dengan membuat pagination PHP tanpa library tambahan untuk daftar perangkat atau log pembacaan. Untuk dokumentasi teknis yang perlu diarsipkan, menyimpan halaman ke berkas seperti pada cara menyimpan halaman web ke PDF untuk arsip bisa membantu tim mempertahankan catatan konfigurasi.
Pertanyaan yang Sering Diajukan
Bisakah CoAP dan MQTT dipakai bersamaan dalam satu proyek?
Bisa. Sebagian arsitektur memakai CoAP untuk komunikasi perangkat ke gateway, lalu gateway meneruskan data ke broker MQTT agar konsumen di sisi server cukup berlangganan satu topik. Biayanya adalah satu lapisan konversi yang harus dirawat.
Apakah LwM2M wajib memakai CoAP?
Spesifikasi LwM2M memang dibangun di atas CoAP sebagai transport utama. Ada upaya membawa LwM2M ke transport lain, tetapi dukungan di implementasi nyata masih terbatas dibanding kombinasi standar ini.
Protokol mana yang paling aman untuk perangkat di jaringan publik?
Ketiganya bisa diamankan, umumnya dengan DTLS untuk CoAP dan LwM2M, serta TLS untuk MQTT. Yang lebih menentukan adalah pengelolaan kunci, pembaruan sertifikat, dan konfigurasi di sisi server. Konsultasikan dengan tim keamanan untuk kebutuhan spesifik Anda.