Protokol MQTT: Pengertian, Cara Kerja, QoS, dan Contoh Penerapan
Protokol MQTT (Message Queuing Telemetry Transport) adalah protokol komunikasi ringan yang menjadi standar de facto di dunia Internet of Things. Hampir semua platform IoT — dari ESP32, Raspberry Pi, PLC industri, hingga layanan cloud — mendukung MQTT. Panduan ini membahas protokol MQTT dari dasar: pengertian, cara kerja publish/subscribe, broker, topik, QoS, fitur penting seperti retained message dan Last Will, keamanan, hingga contoh penerapannya.
Daftar isi:
- Apa itu protokol MQTT?
- Cara kerja MQTT: publish/subscribe
- Topik dan wildcard
- Quality of Service (QoS)
- Retained message, Last Will, keep alive, sesi
- Fitur baru MQTT 5.0
- MQTT broker
- Keamanan MQTT
- MQTT vs HTTP vs CoAP
- Lanjut praktik
- FAQ
Apa Itu Protokol MQTT?
MQTT adalah protokol pesan berbasis model publish/subscribe yang berjalan di atas TCP/IP. Perangkat tidak saling berkomunikasi langsung, melainkan melalui perantara yang disebut broker. Header pesannya sangat kecil (minimal 2 byte), sehingga hemat bandwidth dan cocok untuk perangkat berdaya rendah maupun jaringan yang tidak stabil.
| Aspek | Keterangan |
|---|---|
| Pencipta | Andy Stanford-Clark (IBM) dan Arlen Nipper (Arcom), tahun 1999, untuk pemantauan pipa minyak via satelit |
| Standar | OASIS: MQTT 3.1.1 (2014, juga ISO/IEC 20922) dan MQTT 5.0 (2019) |
| Transport | TCP/IP; bisa juga lewat WebSocket untuk aplikasi web |
| Port standar | 1883 (tanpa enkripsi) dan 8883 (MQTT over TLS) |
| Model komunikasi | Publish/subscribe melalui broker, bersifat asinkron |
Analogi Sederhana: MQTT seperti Grup WhatsApp
Bayangkan sebuah grup WhatsApp keluarga. Grup adalah broker, anggota yang mengirim pesan adalah publisher, anggota yang membaca adalah subscriber, dan tema obrolan adalah topik. Pengirim tidak perlu tahu nomor HP setiap anggota — cukup kirim ke grup, dan semua yang tergabung akan menerimanya. Begitu pula di MQTT: ESP32 A cukup mengirim “Hidup” ke topik lampu/kamar, dan ESP32 B yang berlangganan topik itu otomatis menerima dan menyalakan lampu.
Cara Kerja Protokol MQTT: Model Publish/Subscribe
- Publisher — perangkat atau aplikasi yang mengirim pesan ke broker dengan label topik tertentu.
- Subscriber — perangkat atau aplikasi yang berlangganan topik tertentu ke broker.
- Broker — server pusat yang menerima semua pesan, menyaringnya berdasarkan topik, lalu meneruskannya ke subscriber yang sesuai.
Alurnya: (1) publisher dan subscriber masing-masing terhubung ke broker; (2) subscriber mendaftarkan topik yang diminati; (3) publisher mengirim pesan ke sebuah topik; (4) broker langsung meneruskan pesan ke semua subscriber topik tersebut. Karena pengirim dan penerima tidak saling bergantung (decoupled), sistem mudah dikembangkan: menambah dashboard baru cukup dengan subscribe, tanpa mengubah perangkat sensor.
Keunggulan utama: pesan kecil dan efisien, komunikasi dua arah, bisa menangani ribuan perangkat per broker, dan tetap andal di jaringan yang putus-sambung.
Topik dan Wildcard pada Protokol MQTT
Topik adalah string hierarkis yang dipisahkan garis miring (/), berfungsi sebagai “alamat” pesan. Contoh: suhu/ruang1, sensor/kelembapan/tanah, atau pabrik/line1/motor3/arus.
Contoh penerapan: sebuah ESP32 yang mengontrol lampu berlangganan topik home/office/lamp. Ketika aplikasi, Node-RED, atau Home Assistant mengirim pesan on atau off ke topik tersebut, ESP32 langsung menyalakan atau mematikan lampu.
| Wildcard | Arti | Contoh | Cocok dengan |
|---|---|---|---|
+ | Tepat satu level | rumah/+/suhu | rumah/kamar1/suhu, rumah/dapur/suhu |
# | Semua level di bawahnya (harus di akhir) | rumah/# | Semua topik yang diawali rumah/ |
Praktik baik penamaan topik: gunakan huruf kecil dan pola konsisten (lokasi/perangkat/parameter), jangan diawali “/”, hindari spasi, dan ingat bahwa topik bersifat case-sensitive.
Payload (isi pesan) formatnya bebas: teks (Suhu: 25.5°C), angka (25.5), JSON ({"suhu": 25.5, "unit": "C"}), atau data biner. JSON paling umum dipakai karena mudah diolah.
Quality of Service (QoS) pada Protokol MQTT
QoS menentukan tingkat jaminan pengiriman pesan. QoS berlaku per “lompatan”: dari publisher ke broker, dan dari broker ke subscriber. Subscriber menerima pesan dengan QoS terendah antara QoS saat publish dan QoS saat subscribe.
| Level | Jaminan | Alur paket | Cocok untuk |
|---|---|---|---|
| QoS 0 — at most once | Dikirim sekali, tanpa konfirmasi; bisa hilang | PUBLISH | Data sensor periodik yang tidak kritis |
| QoS 1 — at least once | Pasti sampai, tetapi bisa terduplikasi | PUBLISH → PUBACK | Data penting dan perintah ke aktuator |
| QoS 2 — exactly once | Tepat sekali, tanpa duplikasi; paling lambat | PUBLISH → PUBREC → PUBREL → PUBCOMP | Transaksi kritis (misalnya penagihan, perintah yang tidak boleh ganda) |
Pada QoS 1, pengirim menyimpan pesan sampai menerima PUBACK dan mengirim ulang bila tidak ada konfirmasi. Pada QoS 2, terjadi jabat tangan empat langkah: penerima membalas PUBREC, pengirim mengirim PUBREL, lalu penerima menutup dengan PUBCOMP. Pilih QoS terendah yang memenuhi kebutuhan, karena QoS lebih tinggi menambah lalu lintas dan latensi.
Fitur Penting Protokol MQTT: Retained Message, Last Will, Keep Alive, dan Sesi
- Retained message — broker menyimpan pesan terakhir sebuah topik, sehingga subscriber baru langsung menerima nilai terakhir tanpa menunggu publish berikutnya. Cocok untuk status perangkat.
- Last Will and Testament (LWT) — pesan “wasiat” yang didaftarkan saat connect. Jika client terputus tidak normal, broker otomatis mengirim pesan ini, misalnya
offline. - Keep alive — interval (detik) di mana client wajib berkomunikasi; bila terlewati, broker menganggap client terputus dan menjalankan LWT.
- Persistent session — dengan clean session = false (MQTT 3.1.1) atau session expiry (MQTT 5), broker menyimpan langganan dan pesan QoS 1/2 selama client offline.
- Client ID — setiap client wajib memiliki ID unik; dua client dengan ID sama akan saling memutus koneksi.
Fitur Baru MQTT 5.0
| Fitur | Manfaat |
|---|---|
| Reason codes | Setiap ACK membawa kode alasan, sehingga penyebab gagal lebih mudah dilacak |
| Shared subscriptions | Beban pesan dibagi ke beberapa subscriber (load balancing) |
| Message expiry | Pesan otomatis kedaluwarsa bila tidak terkirim dalam waktu tertentu |
| Topic alias | Topik panjang diganti angka pendek untuk menghemat bandwidth |
| User properties | Metadata tambahan (key-value) pada setiap pesan |
MQTT Broker
Broker adalah pusat komunikasi MQTT: menerima pesan, mengelola langganan, menyimpan retained message, dan mengatur autentikasi. Pilihan populer:
| Broker | Jenis | Cocok untuk | Panduan bisaioti |
|---|---|---|---|
| Eclipse Mosquitto | Open source, ringan | Belajar, Raspberry Pi, server lokal | Windows · Raspberry Pi/Linux |
| HiveMQ Cloud | Layanan cloud (ada paket gratis) | Akses lewat internet dengan TLS | Tutorial HiveMQ Cloud |
| EMQX | Open source & cloud, skala besar | Jutaan koneksi, klaster | — |
Coba broker dalam dua menit dengan klien bawaan Mosquitto:
# Terminal 1 – subscribe
mosquitto_sub -h localhost -t "test/topic" -v
# Terminal 2 – publish
mosquitto_pub -h localhost -t "test/topic" -m "Halo, MQTT!"Keamanan Protokol MQTT
MQTT awalnya dirancang untuk jaringan tertutup, sehingga tanpa konfigurasi tambahan data dikirim sebagai teks biasa tanpa login. Untuk sistem nyata, terapkan:
- Enkripsi TLS di port 8883 agar data tidak bisa disadap.
- Autentikasi username/password atau sertifikat klien untuk setiap perangkat.
- Otorisasi (ACL) — batasi topik yang boleh di-publish dan di-subscribe setiap client.
- Jangan kirim data sensitif ke broker publik (
broker.hivemq.com,test.mosquitto.org) karena siapa pun bisa membacanya. - Pisahkan jaringan perangkat IoT/OT dari jaringan kantor dan perbarui broker secara berkala.
Protokol MQTT vs HTTP vs CoAP
| Aspek | MQTT | HTTP | CoAP |
|---|---|---|---|
| Model | Publish/subscribe via broker | Request/response | Request/response (+ observe) |
| Transport | TCP | TCP | UDP |
| Overhead | Sangat kecil (header 2 byte) | Besar (header teks) | Kecil (header 4 byte) |
| Komunikasi real-time dua arah | Sangat baik | Terbatas (perlu polling/WebSocket) | Baik |
| Cocok untuk | Telemetri dan kontrol IoT/IIoT | Web, REST API | Perangkat sangat terbatas di jaringan lossy |
Pembahasan lengkap kapan memilih masing-masing protokol ada di artikel MQTT vs HTTP vs CoAP dan panduan protokol komunikasi IoT.
Contoh Penerapan Protokol MQTT
- Monitoring IoT — sensor suhu/kelembapan mengirim data ke broker, dashboard menampilkannya secara real-time.
- Smart home — kontrol lampu, AC, dan pintu dari aplikasi ponsel atau Home Assistant.
- Industri 4.0 — PLC dan gateway mengirim data mesin ke cloud, misalnya MQTT bawaan Modicon M262 dan Omron NX1P2 ke cloud IoT.
- Telemetri kendaraan dan energi — data lokasi, konsumsi energi, dan alarm dikirim dari lapangan ke pusat kontrol.
Lanjut Praktik: Panduan MQTT di bisaioti
| Ingin mencoba… | Baca panduan |
|---|---|
| MQTT di komputer dengan Python dan Mosquitto | Tutorial MQTT Python: Paho & Mosquitto |
| Broker cloud aman (TLS) dari Python | Tutorial HiveMQ Cloud Python |
| ESP32 kirim data sensor & kontrol LED | Tutorial MQTT ESP32 |
| Dashboard Node-RED dari data ESP32 | ESP32 + MQTT + Node-RED |
| ESP32 di lingkungan industri | Kirim data sensor ESP32 ke MQTT broker (seri industri) |
| Menginstal broker | Mosquitto di Windows · Mosquitto di Raspberry Pi |
Soal Diskusi untuk Kelas dan Pelatihan
- Mengapa model publish/subscribe lebih cocok untuk IoT skala besar dibanding request/response?
- Jelaskan peran client, broker, dan topik. Apa yang terjadi jika broker mati?
- Kapan Anda memilih QoS 0, 1, atau 2? Berikan contoh kasus masing-masing.
- Bagaimana retained message dan Last Will membantu dashboard mengetahui status perangkat?
- Sebutkan tiga fitur baru MQTT 5.0 dan manfaatnya bagi sistem industri.
- Apa risiko memakai broker publik, dan bagaimana cara mengamankan komunikasi MQTT?
- Rancang struktur topik untuk pabrik dengan 3 line produksi dan 10 mesin per line.
FAQ Protokol MQTT
Apakah MQTT hanya untuk IoT?
Tidak. MQTT juga dipakai di aplikasi chat, telemetri kendaraan, dan sistem notifikasi. Namun karakteristiknya yang ringan membuatnya paling populer di IoT dan IIoT.
Apa beda MQTT 3.1.1 dan MQTT 5.0?
MQTT 5.0 menambahkan reason codes, shared subscriptions, message expiry, topic alias, dan user properties. Sebagian besar broker modern mendukung keduanya, sementara library perangkat kecil seperti PubSubClient masih memakai 3.1.1.
Apakah MQTT bisa berjalan tanpa internet?
Bisa. Cukup jalankan broker (misalnya Mosquitto) di jaringan lokal; semua perangkat di LAN yang sama dapat berkomunikasi tanpa koneksi internet.
Port berapa yang dipakai MQTT?
Port 1883 untuk koneksi tanpa enkripsi dan 8883 untuk MQTT over TLS. Untuk WebSocket, port tergantung konfigurasi broker (misalnya 8884 pada HiveMQ Cloud).
Kesimpulan
Protokol MQTT sederhana, hemat sumber daya, dan fleksibel — itulah sebabnya menjadi tulang punggung komunikasi IoT modern. Dengan memahami publish/subscribe, topik, QoS, retained message, Last Will, dan praktik keamanan, Anda siap membangun sistem IoT yang andal. Mulailah praktik dari tutorial MQTT Python atau tutorial MQTT ESP32, atau ikuti Training IoT Profesional bisaioti untuk belajar terarah.
Referensi
- OASIS, “MQTT Version 5.0” – docs.oasis-open.org
- OASIS, “MQTT Version 3.1.1” – docs.oasis-open.org
- MQTT.org, “MQTT: The Standard for IoT Messaging” – mqtt.org
- HiveMQ, “MQTT Essentials” – hivemq.com/mqtt
- Eclipse Mosquitto – mosquitto.org
Baca Juga: ESP32: Panduan Komprehensif untuk Pemula hingga Ahli (IoT, Pemrograman, & Proyek) dan Training ESP32 Berbasis IoT.
