MQTT, HTTP, atau Modbus TCP? Memilih Protokol Data Logger yang Tepat

Sensor sudah terpasang, data logger merekam, dan koneksi seluler aktif — tetapi protokol komunikasi data logger yang membawa data ke server menentukan seberapa efisien bandwidth terpakai, bagaimana sistem menangani koneksi yang terputus, dan seberapa mudah data terintegrasi dengan dashboard atau platform cloud. Memilih protokol yang salah di lapisan aplikasi bisa menyebabkan konsumsi bandwidth berlebihan, kehilangan data saat gangguan koneksi, atau ketidakcocokan dengan platform monitoring.

Artikel ini membandingkan tiga protokol yang paling sering ditemui dalam telemetri stasiun monitoring: MQTT, HTTP/REST, dan Modbus TCP.

Mengapa Protokol Antara Data Logger dan Server Penting?

Konektivitas fisik — seluler, satelit, atau Ethernet — adalah pipa yang membawa data. Tetapi protokol komunikasi yang berjalan di atas koneksi tersebut menentukan bagaimana data sensor distrukturkan, dikirim, dan dikonfirmasi penerimaannya. Dua stasiun dengan koneksi seluler identik bisa memiliki efisiensi bandwidth yang sangat berbeda jika satu menggunakan MQTT dan lainnya HTTP.

Ketika stasiun mengirim data setiap menit alih-alih setiap 15 menit, overhead per pesan dari protokol yang dipilih terakumulasi secara signifikan. Untuk stasiun bertenaga surya di lokasi terpencil, overhead ini langsung memengaruhi waktu aktif modem dan konsumsi daya.

MQTT: Publish-Subscribe untuk Telemetri Efisien

MQTT (Message Queuing Telemetry Transport) beroperasi dengan model publish-subscribe: data logger mem-publish pembacaan sensor ke topic yang dinamai pada broker, dan subscriber yang berwenang — server, dashboard, layanan alarm — menerima data tersebut.

Keunggulan utama MQTT untuk telemetri monitoring:

• Header minimal: Fixed header MQTT dimulai dari hanya 2 byte, menjadikannya salah satu protokol paling hemat bandwidth untuk mengirim payload sensor kecil.
• Koneksi persisten: MQTT mempertahankan koneksi TCP yang terbuka antara data logger dan broker, menghindari overhead pembentukan koneksi baru untuk setiap transmisi.
• Tiga level QoS: QoS 0 mengirim tanpa konfirmasi (fire-and-forget), QoS 1 menjamin pengiriman setidaknya sekali dengan acknowledgment, dan QoS 2 memastikan pengiriman tepat sekali melalui handshake empat langkah.
• Persistent session: Dengan persistent session dan QoS 1 atau 2, broker MQTT dapat mengantri pesan untuk data logger yang terputus dan mengirimkannya saat koneksi pulih — mengurangi kehilangan data selama gangguan konektivitas.
• Last Will and Testament (LWT): Data logger dapat mendaftarkan pesan “offline” yang broker otomatis publikasikan jika koneksi terputus — memungkinkan alert putus koneksi langsung di dashboard.

Platform IoT cloud utama — termasuk AWS IoT Core dan Azure IoT Hub — menggunakan MQTT sebagai protokol perangkat utama mereka.

HTTP/REST: Familiar tetapi Berat untuk Koneksi Terbatas

HTTP menggunakan model request-response: data logger menginisiasi setiap transmisi data sebagai HTTP POST request, dan server merespons dengan status code.

HTTP/REST sering menjadi pilihan default karena familiar bagi developer web, tetapi ada konsekuensi untuk telemetri monitoring:

• Overhead header besar: Tiap HTTP request membawa 200 hingga 800+ byte header — method line, host, content-type, authorization, dan field lainnya — sebelum payload sensor yang sebenarnya. Bandingkan dengan 2 byte minimum header MQTT.
• Tidak ada publish-subscribe bawaan: HTTP standar tidak mendukung push notification dari server ke perangkat; data logger harus melakukan polling atau menggunakan ekstensi seperti WebSocket untuk komunikasi dua arah.
• Tidak ada store-and-forward bawaan: Jika POST request gagal karena gangguan koneksi, firmware data logger harus menangani logika retry dan buffering lokal secara mandiri.

HTTP tetap menjadi pilihan yang valid ketika stasiun monitoring terhubung ke infrastruktur web yang sudah ada dengan koneksi stabil, atau ketika integrasi REST API diperlukan oleh platform yang tidak mendukung MQTT.

Modbus TCP: Memperluas Field Bus ke Jaringan

Modbus TCP membungkus Modbus application data unit standar ke dalam paket TCP/IP, menggunakan port 502 secara default. Bagi engineer yang sudah familiar dengan Modbus RTU di field bus, Modbus TCP terasa sebagai ekstensi alami.

Namun ada perbedaan penting untuk telemetri upstream:

• Model polling master-slave: Server atau sistem SCADA melakukan polling ke data logger untuk nilai register tertentu, bukan data logger yang mengirim data sesuai jadwalnya sendiri.
• Dirancang untuk LAN: Modbus TCP dirancang untuk jaringan lokal industri yang andal, dengan koneksi persisten dan latensi rendah.
• Tidak ada mekanisme disconnection handling: Modbus TCP tidak menyediakan publish-subscribe, message queuing, atau penanganan graceful disconnection. Jika koneksi TCP terputus, siklus polling berhenti sampai koneksi pulih.

Modbus TCP tetap kuat untuk skenario di mana data logger terhubung via LAN ke SCADA atau HMI lokal. Tetapi untuk transmisi WAN melalui koneksi seluler yang intermittent, keterbatasan ini menjadi signifikan.

Perbandingan Protokol: Bandwidth, Keandalan, dan Kompatibilitas

Kriteria	MQTT	HTTP/REST	Modbus TCP
Model komunikasi	Publish-subscribe	Request-response	Master-slave polling
Overhead header minimum	2 byte	200–800+ byte	7 byte (MBAP header)
Koneksi	Persisten	Per-request (HTTP/1.1)	Persisten (LAN)
QoS bawaan	3 level (0, 1, 2)	Tidak ada	Tidak ada
Store-and-forward	Ya (via broker)	Tidak ada	Tidak ada
Disconnection handling	LWT + persistent session	Retry manual	Tidak ada
Dukungan cloud platform	Native (AWS, Azure, dll.)	Didukung (sekunder)	Tidak native (butuh gateway)
Cocok untuk koneksi intermittent	Sangat baik	Cukup (dengan retry logic)	Kurang ideal

Riset yang dipublikasikan menunjukkan bahwa MQTT dapat menggunakan bandwidth per pesan yang jauh lebih sedikit dibandingkan HTTP untuk payload sensor kecil, terutama karena header biner kompaknya dibandingkan header berbasis teks HTTP.

Memilih Protokol yang Tepat untuk Stasiun Monitoring

Pemilihan protokol bergantung pada kondisi deployment dan kebutuhan integrasi:

MQTT — pilihan kuat untuk sebagian besar stasiun monitoring jarak jauh bertenaga surya pada koneksi seluler intermittent. Kombinasi QoS 1 dan persistent session memberikan pengiriman data yang andal dengan overhead bandwidth rendah. Ideal untuk stasiun AWLR, extensometer, weather station, dan AQMS yang berlokasi di area terpencil.

HTTP/REST — cocok ketika stasiun monitoring terintegrasi dengan infrastruktur web yang sudah ada dan koneksi stabil tersedia. Berguna juga ketika platform monitoring mewajibkan format API tertentu yang berbasis REST.

Modbus TCP — tetap menjadi standar untuk stasiun yang terhubung via LAN ke sistem SCADA atau HMI lokal di lingkungan pabrik atau plant. Tidak disarankan sebagai satu-satunya protokol upstream untuk transmisi WAN jarak jauh.

Platform monitoring regulasi mungkin mewajibkan format submission data atau API tertentu — selalu verifikasi persyaratan platform sebelum memfinalisasi pilihan protokol.

Kapan Mempertimbangkan Protocol Gateway

Banyak deployment menggunakan pendekatan hybrid: Modbus RTU di field bus untuk komunikasi sensor-ke-data-logger, lalu MQTT atau HTTP untuk transmisi upstream ke cloud. Protocol gateway atau data logger multi-protokol dapat menjembatani kedua sisi ini — menjalankan Modbus RTU di sisi field sambil menggunakan MQTT untuk komunikasi cloud.

Fortuna Argatech menyediakan data logger dan gateway yang menangani transmisi data upstream untuk seluruh lini produk — dari monitoring air limbah SPARING hingga stasiun peringatan dini banjir AWLR. Pemilihan protokol yang tepat untuk kondisi lapangan spesifik Anda merupakan bagian dari perencanaan konektivitas stasiun monitoring yang perlu dipertimbangkan sejak tahap desain sistem.

Untuk konsultasi teknis tentang arsitektur telemetri dan pemilihan protokol untuk proyek monitoring Anda, hubungi tim engineering Fortuna Argatech.