MQTT IoT: Panduan Lengkap MQTT, Broker, Publish/Subscribe, QoS, dan Cara Kerjanya

Dalam sistem IoT Internet of Things, perangkat seperti sensor, mikrokontroler, gateway, dan server harus saling bertukar data.

Misalnya sebuah sensor suhu mengirimkan data:

Temperature = 29.5°C

Data tersebut kemudian perlu diterima oleh server atau aplikasi monitoring.

Salah satu protokol komunikasi yang banyak digunakan untuk kebutuhan tersebut adalah MQTT.

MQTT (Message Queuing Telemetry Transport) adalah protokol messaging ringan yang menggunakan model komunikasi publish/subscribe dan sangat cocok untuk perangkat dengan keterbatasan bandwidth, resource, atau koneksi jaringan.

Secara sederhana:

Sensor
   ↓
Publish Data
   ↓
MQTT Broker
   ↓
Subscribe
   ↓
Dashboard

Berbeda dengan komunikasi langsung seperti:

Device A ─────────→ Server

MQTT menggunakan broker sebagai perantara.

Device A
   ↓
 Publish
   ↓
MQTT Broker
   ↓
 Subscribe
   ↓
Device B

Konsep inilah yang membuat MQTT sangat menarik untuk digunakan dalam berbagai sistem IoT.

Materi ini adalah Level 15 dari Kurikulum Internet of Things Raja Putra Media tentang MQTT IoT secara lengkap, mulai dari pengertian MQTT, broker, client, topic, publish/subscribe, QoS, retained message, hingga contoh penerapannya.

Mengapa MQTT Penting dalam IoT?

Bayangkan terdapat 1.000 sensor yang harus mengirimkan data ke berbagai aplikasi.

Jika setiap sensor harus mengetahui alamat dan koneksi setiap aplikasi:

Sensor 1 → App A
Sensor 1 → App B
Sensor 2 → App A
Sensor 2 → App B
...

Arsitekturnya dapat menjadi kompleks.

MQTT menyederhanakan komunikasi tersebut:

                  ┌──→ Dashboard
                  │
Sensor ──→ Broker ┼──→ Database
                  │
                  └──→ Mobile App

Sensor hanya perlu mengetahui broker dan topic yang digunakan.

Aplikasi yang membutuhkan data cukup melakukan subscribe terhadap topic tersebut.

MQTT Termasuk Protokol IoT?

Ya.

MQTT sangat erat kaitannya dengan IoT karena dirancang untuk komunikasi machine-to-machine dan lingkungan dengan keterbatasan jaringan.

Karakteristik yang membuat MQTT cocok untuk IoT antara lain:

• overhead komunikasi relatif kecil;
• model publish/subscribe;
• komunikasi asynchronous;
• mendukung berbagai tingkat QoS;
• dapat digunakan pada jaringan yang tidak selalu stabil;
• mendukung banyak client;
• dan memisahkan publisher dari subscriber melalui broker.

Namun perlu dipahami:

MQTT bukan satu-satunya protokol untuk IoT.

Pada sistem tertentu, HTTP, WebSocket, CoAP, AMQP, atau protokol lainnya dapat lebih sesuai.

Pemilihan protokol harus mengikuti kebutuhan sistem.

Konsep Dasar MQTT

Untuk memahami MQTT, ada beberapa istilah yang harus dikuasai:

MQTT
│
├── Client
├── Broker
├── Topic
├── Publisher
├── Subscriber
├── Message
├── QoS
├── Retained Message
├── Last Will
└── Session

Mari kita bahas satu per satu.

1. MQTT Client

MQTT Client adalah perangkat atau aplikasi yang terhubung ke MQTT broker.

Client dapat berupa:

• ESP32;
• ESP8266;
• Raspberry Pi;
• komputer;
• server;
• smartphone;
• gateway;
• aplikasi monitoring;
• atau perangkat IoT lainnya.

Satu perangkat dapat bertindak sebagai publisher, subscriber, atau bahkan keduanya.

Contohnya:

ESP32
 ↓
MQTT Client
 ↓
MQTT Broker

2. MQTT Broker

MQTT Broker adalah pusat komunikasi yang menerima dan meneruskan pesan MQTT kepada client yang melakukan subscribe terhadap topic tertentu.

Arsitektur sederhananya:

Publisher
    │
    │ Publish
    ▼
┌─────────────┐
│ MQTT Broker │
└─────────────┘
    │
    ├──────→ Subscriber A
    │
    ├──────→ Subscriber B
    │
    └──────→ Subscriber C

Broker bertugas mengelola komunikasi antara publisher dan subscriber.

Contoh MQTT broker yang populer antara lain:

• Mosquitto;
• EMQX;
• HiveMQ;
• dan berbagai layanan MQTT cloud.

Dalam artikel ini, yang terpenting bukan nama produknya, tetapi memahami konsep broker terlebih dahulu.

3. Publisher

Publisher adalah client yang mengirimkan message ke sebuah topic.

Misalnya ESP32 membaca sensor suhu:

Temperature = 29.5

ESP32 kemudian melakukan:

PUBLISH
Topic:
home/livingroom/temperature

Payload:
29.5

ESP32 dalam contoh tersebut berperan sebagai publisher.

4. Subscriber

Subscriber adalah client yang menerima message dari topic yang telah di-subscribe.

Misalnya dashboard melakukan:

SUBSCRIBE
home/livingroom/temperature

Ketika ESP32 mengirim:

29.5

broker meneruskan message tersebut kepada subscriber.

5. Topic MQTT

Topic merupakan alamat logis yang digunakan MQTT untuk mengelompokkan pesan.

Contoh:

home/livingroom/temperature

Topic dapat dibuat secara hierarkis.

Misalnya:

home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature
home/bedroom/humidity

Dengan struktur tersebut, data menjadi lebih mudah dikelola.

Struktur Topic MQTT

Tidak ada satu struktur topic yang wajib digunakan untuk semua sistem.

Namun struktur yang konsisten sangat penting.

Misalnya untuk smart home:

home/{room}/{sensor}

Contohnya:

home/kitchen/temperature
home/kitchen/humidity
home/bedroom/temperature

Untuk industri:

factory/{line}/{machine}/{sensor}

Contoh:

factory/line1/machine01/temperature
factory/line1/machine01/vibration

Struktur topic sebaiknya dirancang sejak awal agar tidak menjadi masalah ketika jumlah perangkat bertambah.

Publish dan Subscribe MQTT

Inilah inti dari MQTT.

Publisher mengirim message:

PUBLISH
      ↓
Broker

Subscriber menerima message:

Broker
   ↓
SUBSCRIBE

Contoh:

ESP32
 │
 │ Publish
 ▼
MQTT Broker
 │
 ├────────→ Dashboard
 │
 ├────────→ Database
 │
 └────────→ Mobile App

ESP32 tidak perlu mengetahui siapa saja yang menerima datanya.

Inilah salah satu keunggulan model publish/subscribe.

Bagaimana Cara Kerja MQTT?

Sekarang mari kita lihat alurnya dari awal.

Misalnya kita memiliki:

ESP32 + DHT22

ESP32 membaca suhu.

Langkah 1 — ESP32 terhubung ke broker

ESP32
   ↓
CONNECT
   ↓
MQTT Broker

Broker memproses permintaan koneksi tersebut.

Langkah 2 — ESP32 melakukan authentication

Jika broker dikonfigurasi menggunakan authentication:

Username
Password / Credential
        ↓
MQTT Broker
        ↓
Authentication

Jika valid, koneksi dapat diterima.

Langkah 3 — ESP32 melakukan publish

ESP32 membaca:

29.5°C

Kemudian mengirim:

Topic:
home/room1/temperature

Payload:
29.5

Langkah 4 — Dashboard melakukan subscribe

Dashboard sebelumnya melakukan:

SUBSCRIBE
home/room1/temperature

Langkah 5 — Broker meneruskan message

Broker menerima message:

home/room1/temperature
29.5

Kemudian mencari client yang subscribe pada topic tersebut.

                ┌──→ Dashboard
                │
ESP32 → Broker ─┼──→ Database
                │
                └──→ Mobile App

Dengan demikian, satu message dapat dikonsumsi oleh beberapa aplikasi.

MQTT Publish/Subscribe vs Request/Response

Untuk memahami keunggulan MQTT, bandingkan dengan pola request/response.

Request/Response

Client
  │
  │ Request
  ▼
Server
  │
  │ Response
  ▼
Client

Client meminta data kepada server.

Sedangkan MQTT:

Publisher
    │
    ▼
 Broker
    │
    ▼
Subscriber

Publisher tidak perlu mengetahui subscriber.

Apa Keuntungan Model Publish/Subscribe?

Ada beberapa keuntungan.

Loose Coupling

Publisher dan subscriber tidak harus saling mengenal.

Scalability

Client dapat ditambahkan tanpa mengubah publisher secara langsung.

Asynchronous Communication

Publisher tidak harus menunggu subscriber memproses message.

Fleksibel

Satu topic dapat digunakan oleh banyak subscriber.

MQTT QoS

Salah satu konsep paling penting dalam MQTT adalah QoS (Quality of Service).

QoS menentukan tingkat jaminan delivery message.

MQTT memiliki tiga level:

QoS 0
QoS 1
QoS 2

Mari kita pahami.

QoS 0 — At Most Once

QoS 0 sering digambarkan sebagai:

At most once

Message dikirim tanpa mekanisme acknowledgment pada level MQTT untuk memastikan delivery.

Secara sederhana:

Publisher
   ↓
Message
   ↓
Broker

Jika message gagal sampai, message tersebut dapat hilang.

Keuntungannya:

• overhead rendah;
• komunikasi lebih ringan;
• cocok untuk data yang dikirim sangat sering dan kehilangan sebagian data masih dapat ditoleransi.

Contohnya sensor temperatur yang mengirim data setiap detik:

29.1
29.2
29.3
29.4
29.5

Jika satu data hilang, data berikutnya masih tersedia.

QoS 1 — At Least Once

QoS 1 menggunakan acknowledgment.

Tujuannya memastikan message sampai, tetapi message dapat diterima lebih dari sekali dalam kondisi tertentu.

Konsep sederhananya:

Publisher
   ↓
Message
   ↓
Broker
   ↓
ACK

Jika publisher tidak mendapatkan acknowledgment, message dapat dikirim ulang.

Akibatnya:

Message A
Message A

dapat terjadi.

Karena itu subscriber atau aplikasi harus mempertimbangkan kemungkinan duplicate message.

QoS 1 cocok ketika message lebih penting untuk diterima, tetapi duplicate masih dapat ditangani.

QoS 2 — Exactly Once

QoS 2 memberikan tingkat delivery yang paling tinggi dalam MQTT:

Exactly once

Tujuannya agar message diproses tepat satu kali dalam mekanisme QoS tersebut.

Namun konsekuensinya adalah komunikasi menjadi lebih kompleks dan memiliki overhead lebih tinggi dibandingkan QoS 0 dan QoS 1.

Karena itu QoS 2 tidak otomatis menjadi pilihan terbaik untuk semua sistem.

Perbandingan QoS MQTT

QoS	Jaminan	Risiko Duplicate	Overhead
QoS 0	At most once	Sangat rendah	Rendah
QoS 1	At least once	Bisa terjadi	Sedang
QoS 2	Exactly once	Ditujukan untuk menghindari duplicate delivery	Lebih tinggi

Pemilihan QoS harus mengikuti karakteristik data.

Jangan berpikir:

“Semakin tinggi QoS pasti semakin baik.”

Tidak selalu.

Contoh Pemilihan QoS

Misalnya sensor mengirim temperatur setiap 1 detik.

temperature = 29.5

Kehilangan satu data mungkin tidak menjadi masalah besar.

QoS 0 dapat dipertimbangkan.

Tetapi untuk event penting:

factory/machine01/emergency

kehilangan message dapat memiliki konsekuensi lebih besar.

Dalam situasi seperti ini, QoS yang lebih tinggi dapat dipertimbangkan sesuai kebutuhan sistem.

MQTT Retained Message

MQTT memiliki fitur retained message.

Konsepnya adalah broker dapat menyimpan message terakhir untuk sebuah topic sebagai retained message.

Misalnya:

Topic:
home/room1/temperature

Payload:
29.5

Retain:
true

Kemudian dashboard baru melakukan subscribe.

Broker dapat memberikan retained message tersebut kepada subscriber baru sesuai aturan MQTT.

Sehingga dashboard tidak harus menunggu sensor mengirim data berikutnya.

Contoh Retained Message

Tanpa retained message:

Dashboard
   ↓
Subscribe
   ↓
Menunggu data berikutnya

Dengan retained message:

Dashboard
   ↓
Subscribe
   ↓
Broker
   ↓
Last Retained Value
   ↓
29.5°C

Fitur ini berguna untuk berbagai informasi state atau nilai terakhir yang relevan.

MQTT Last Will and Testament

Fitur lain yang menarik adalah Last Will and Testament (LWT).

Tujuannya membantu memberitahukan client lain ketika sebuah koneksi MQTT terputus secara tidak normal.

Misalnya ESP32 memiliki status:

home/room1/status

Ketika online:

online

Jika koneksi terputus secara tidak normal, broker dapat mempublikasikan pesan Will yang telah ditentukan.

Misalnya:

offline

Dengan demikian dashboard dapat mengetahui bahwa perangkat tidak lagi terhubung.

Contoh Status Device

ESP32
  │
  ├── Status: online
  │
  │   Connection lost
  │
  ▼
Broker
  │
  ▼
home/room1/status
  │
  ▼
offline

Fitur ini sangat berguna untuk monitoring device.

MQTT Session

Client MQTT dapat memiliki session yang membantu broker mempertahankan informasi tertentu mengenai client sesuai konfigurasi dan versi MQTT yang digunakan.

Konsep session menjadi penting ketika perangkat memiliki koneksi yang tidak selalu stabil.

Contohnya:

Device
  ↓
Connect
  ↓
Disconnect
  ↓
Reconnect

Dalam desain sistem, pengelolaan session perlu disesuaikan dengan kebutuhan aplikasi.

MQTT Keep Alive

Bagaimana broker mengetahui bahwa client masih terhubung?

MQTT memiliki mekanisme Keep Alive.

Client dan broker menggunakan mekanisme komunikasi tertentu untuk mempertahankan atau memeriksa koneksi.

Secara konseptual:

Client
   ↓
Connection
   ↓
Broker
   ↑
Keep Alive

Jika koneksi tidak lagi aktif sesuai kondisi protokol, broker dapat menganggap koneksi tersebut terputus.

MQTT dan TCP/IP

MQTT secara umum berjalan di atas TCP/IP.

Struktur sederhananya:

MQTT
 ↓
TCP
 ↓
IP
 ↓
Network

TCP menyediakan transport yang reliable, sementara MQTT menyediakan messaging model yang sesuai untuk aplikasi IoT.

Untuk koneksi MQTT yang aman, MQTT dapat digunakan bersama TLS.

MQTT
 ↓
TLS
 ↓
TCP
 ↓
IP

Port MQTT

Dalam implementasi umum, MQTT tanpa TLS sering menggunakan:

1883

Sedangkan MQTT dengan TLS sering menggunakan:

8883

Namun port bukanlah mekanisme keamanan itu sendiri.

Mengganti nomor port tidak otomatis membuat MQTT menjadi aman.

Yang penting adalah konfigurasi authentication, authorization, encryption, firewall, dan kontrol akses yang tepat.

MQTT over TLS

Untuk sistem production, terutama ketika komunikasi melewati jaringan yang tidak sepenuhnya dipercaya, penggunaan TLS sangat penting untuk dipertimbangkan.

Alurnya:

ESP32
  ↓
MQTT
  ↓
TLS
  ↓
Internet
  ↓
MQTT Broker

Dengan TLS, komunikasi dapat memperoleh perlindungan terhadap penyadapan dan manipulasi sesuai konfigurasi keamanan yang digunakan.

MQTT Authentication

Broker dapat menerapkan authentication untuk menentukan apakah client diperbolehkan terhubung.

Misalnya:

Client ID
Username
Credential
      ↓
MQTT Broker
      ↓
Authentication

Jika valid:

CONNECTED

Jika tidak:

Connection Rejected

Untuk sistem yang lebih besar, pendekatan authentication dapat berkembang dari username/password menuju certificate atau mekanisme identity management lainnya.

MQTT Authorization

Authentication saja tidak cukup.

Misalnya ESP32 berhasil login.

Apakah ESP32 tersebut boleh:

Publish:
home/room1/temperature

Ya.

Tetapi apakah boleh:

Publish:
admin/system/shutdown

Belum tentu.

Karena itu diperlukan authorization.

Authentication
       ↓
Who are you?
       ↓
Authorization
       ↓
What are you allowed to access?

MQTT Topic Wildcard

MQTT mendukung wildcard untuk subscription.

Dua wildcard yang sangat penting adalah:

• +
• #

Single-Level Wildcard +

Misalnya:

home/+/temperature

Dapat mencocokkan:

home/room1/temperature
home/room2/temperature
home/kitchen/temperature

---

Multi-Level Wildcard #

Misalnya:

home/#

Dapat mencocokkan berbagai topic di bawah home.

Contoh:

home/room1/temperature
home/room1/humidity
home/room2/temperature

Wildcard sangat berguna untuk dashboard atau monitoring banyak perangkat.

Namun authorization tetap harus dirancang dengan hati-hati agar subscriber tidak mendapatkan akses yang terlalu luas.

Contoh Arsitektur MQTT IoT

Sekarang mari kita gabungkan komponen-komponen tersebut.

                    ┌──────────────┐
                    │  Dashboard   │
                    └──────▲───────┘
                           │
                       Subscribe
                           │
┌────────────┐        ┌────┴─────┐
│   Sensor   │ Publish│          │
│   ESP32    ├───────→│  Broker  │
└────────────┘        │  MQTT    │
                      └────┬─────┘
                           │
                           ├────→ Database
                           │
                           └────→ Mobile App

Dalam sistem nyata, komponen tambahan dapat berupa:

Sensor
 ↓
ESP32
 ↓
Wi-Fi
 ↓
MQTT Broker
 ↓
Backend
 ↓
Database
 ↓
Dashboard

Contoh Proyek MQTT dengan ESP32

Mari kita gunakan contoh sederhana.

Perangkat:

ESP32
DHT22
Wi-Fi
MQTT Broker

ESP32 membaca suhu.

Misalnya:

Temperature = 28.7°C

Kemudian melakukan publish:

Topic:
iot/esp32-01/temperature

Payload:
28.7

Dashboard melakukan:

SUBSCRIBE
iot/esp32-01/temperature

Alurnya:

DHT22
  ↓
ESP32
  ↓
Read Temperature
  ↓
Publish
  ↓
MQTT Broker
  ↓
Dashboard

Contoh Struktur Topic untuk Banyak Sensor

Jika kita memiliki 100 perangkat, sebaiknya topic dirancang secara konsisten.

Misalnya:

iot/device001/temperature
iot/device001/humidity

iot/device002/temperature
iot/device002/humidity

iot/device003/temperature
iot/device003/humidity

Untuk skala lebih besar:

iot/{site}/{device}/{sensor}

Contoh:

iot/factory-a/esp32-001/temperature
iot/factory-a/esp32-001/humidity

Struktur seperti ini dapat memudahkan filtering, authorization, monitoring, dan pengembangan sistem.

MQTT Payload

Payload adalah data yang dikirim melalui message.

Contoh paling sederhana:

29.5

Tetapi kita juga dapat menggunakan format terstruktur seperti JSON:

{
  "device": "ESP32-001",
  "temperature": 29.5,
  "humidity": 68
}

Dengan JSON, backend lebih mudah mengetahui konteks data.

Namun payload yang lebih besar juga berarti penggunaan bandwidth yang lebih besar.

Karena itu format data sebaiknya dipilih sesuai kebutuhan.

MQTT dan JSON

Contoh alurnya:

ESP32
 ↓
Read Sensor
 ↓
Create JSON
 ↓
MQTT Publish
 ↓
Broker
 ↓
Backend
 ↓
Database

Contoh payload:

{
  "temperature": 29.5,
  "humidity": 70
}

Backend kemudian dapat menyimpan:

timestamp
device_id
temperature
humidity

ke database.

MQTT untuk Monitoring Real-Time

Salah satu penggunaan MQTT yang sangat populer adalah monitoring.

Misalnya dashboard menampilkan:

Temperature
29.5°C

Humidity
68%

Device
ONLINE

Ketika sensor mengirim data baru:

29.6

dashboard dapat menerima update melalui MQTT tanpa harus melakukan polling terus-menerus.

MQTT vs HTTP untuk IoT

MQTT dan HTTP sama-sama dapat digunakan dalam sistem IoT, tetapi memiliki karakteristik berbeda.

Aspek	MQTT	HTTP
Model	Publish/Subscribe	Request/Response
Broker	Ya	Tidak secara native
Overhead	Relatif ringan	Relatif lebih besar
Real-time messaging	Sangat cocok	Bisa, tetapi pendekatannya berbeda
IoT telemetry	Sangat cocok	Cocok
Web API	Tidak utama	Sangat umum

Keduanya bahkan dapat digunakan bersama.

Contohnya:

Sensor
  ↓
MQTT
  ↓
Backend
  ↓
REST API
  ↓
Web Application

Jadi bukan berarti sebuah sistem harus memilih MQTT atau HTTP secara mutlak.

MQTT vs WebSocket

WebSocket menyediakan komunikasi dua arah antara client dan server melalui koneksi yang persistent.

MQTT memiliki model publish/subscribe dan broker.

Dalam beberapa aplikasi, keduanya bahkan dapat digunakan bersamaan.

Contohnya:

IoT Device
    ↓
   MQTT
    ↓
Backend
    ↓
 WebSocket
    ↓
Browser

MQTT menangani komunikasi IoT, sementara WebSocket dapat digunakan untuk mengirim update real-time ke browser.

Kapan Sebaiknya Menggunakan MQTT?

MQTT sangat cocok dipertimbangkan ketika sistem memiliki karakteristik seperti:

• banyak perangkat;
• komunikasi telemetry;
• data sensor;
• koneksi yang tidak selalu ideal;
• kebutuhan publish/subscribe;
• monitoring;
• komunikasi asynchronous;
• atau kebutuhan distribusi message ke banyak subscriber.

Contohnya:

Smart Home

Temperature
Humidity
Motion
Light

Smart Agriculture

Soil Moisture
Temperature
Humidity
Water Pump

Industrial IoT

Machine Temperature
Vibration
Pressure
Machine Status

Fleet Monitoring

GPS
Speed
Fuel
Vehicle Status

Kapan MQTT Bukan Pilihan Terbaik?

MQTT bukan solusi untuk semua masalah.

Misalnya jika kebutuhan utama adalah:

• komunikasi web request/response;
• REST API publik;
• transfer dokumen besar;
• atau sistem yang sudah memiliki arsitektur HTTP-centric.

HTTP dapat lebih sederhana.

Untuk komunikasi constrained device tertentu, protokol lain seperti CoAP juga dapat menjadi pilihan.

Jadi prinsipnya:

Pilih protokol berdasarkan kebutuhan, bukan karena MQTT sedang populer.

MQTT Security: Apa yang Harus Diamankan?

Dalam sistem MQTT production, beberapa aspek penting adalah:

Device Identity
      ↓
Authentication
      ↓
Authorization
      ↓
TLS
      ↓
Topic ACL
      ↓
Logging
      ↓
Monitoring

Jangan membuat broker MQTT terbuka ke internet tanpa authentication dan access control yang memadai.

MQTT yang mudah digunakan bukan berarti MQTT boleh dikonfigurasi tanpa keamanan.

MQTT dalam Arsitektur IoT Modern

MQTT sering menjadi salah satu lapisan komunikasi dalam arsitektur yang lebih besar.

Contohnya:

┌───────────────┐
│ IoT Devices   │
│ ESP32/ESP8266 │
└───────┬───────┘
        │
       MQTT
        │
┌───────▼───────┐
│ MQTT Broker   │
└───────┬───────┘
        │
   ┌────┴─────┐
   ↓          ↓
Backend     Stream
   ↓        Processing
Database      ↓
   ↓        Analytics
Dashboard

MQTT dengan demikian bukan seluruh sistem IoT.

Ia merupakan salah satu komponen penting yang menangani pertukaran message.

Kesalahan Umum Saat Belajar MQTT

Ada beberapa kesalahan yang sering dilakukan pemula.

1. Menganggap MQTT adalah Database

MQTT bukan database. Sebagaimana telah kami jelaskan pada pembahasan database IoT.

MQTT bertugas untuk komunikasi message.

MQTT
= Communication

Sedangkan:

Database
= Data Storage

Keduanya dapat bekerja bersama.

2. Menganggap Broker Menyimpan Semua Data Selamanya

Broker bukan pengganti database.

Broker memiliki mekanisme penyimpanan tertentu untuk kebutuhan MQTT seperti retained message dan session sesuai konfigurasi, tetapi telemetry historis umumnya perlu diteruskan ke sistem penyimpanan seperti database.

3. Menggunakan QoS 2 untuk Semua Data

QoS 2 bukan otomatis pilihan terbaik.

Pilih QoS berdasarkan:

• pentingnya data;
• toleransi kehilangan;
• kemungkinan duplicate;
• bandwidth;
• latency;
• dan kebutuhan aplikasi.

4. Tidak Membuat Struktur Topic

Jika sejak awal topic dibuat sembarangan:

temperature
temp1
sensor_temp
data_temperature

sistem akan sulit dikelola ketika jumlah device bertambah.

Buat struktur topic yang konsisten.

5. Mengabaikan Security

MQTT broker yang terbuka tanpa authentication dapat menjadi risiko serius.

Minimal pahami:

Authentication
Authorization
TLS
ACL
Monitoring

MQTT untuk Pemula: Urutan Belajar

Jika Anda baru mengenal MQTT, jangan langsung mempelajari seluruh fitur sekaligus.

Urutan yang lebih mudah:

1. MQTT Concept
      ↓
2. Client
      ↓
3. Broker
      ↓
4. Publisher
      ↓
5. Subscriber
      ↓
6. Topic
      ↓
7. Message
      ↓
8. QoS
      ↓
9. Retained Message
      ↓
10. Authentication
      ↓
11. TLS
      ↓
12. MQTT Architecture

Setelah memahami konsep, barulah masuk ke implementasi menggunakan ESP32 atau Raspberry Pi.

Contoh Alur Belajar Praktis

Untuk latihan pertama, gunakan:

ESP32
   +
Sensor
   +
MQTT Broker

Kemudian:

Tahap 1

ESP32 terhubung ke Wi-Fi.

Tahap 2

ESP32 terhubung ke broker.

Tahap 3

ESP32 melakukan publish.

Tahap 4

Laptop melakukan subscribe.

Tahap 5

Tambahkan dashboard.

Tahap 6

Simpan data ke database.

Tahap 7

Tambahkan authentication.

Tahap 8

Aktifkan TLS.

Dengan cara tersebut, pemahaman berkembang secara bertahap dari sederhana hingga production-oriented.

MQTT dan Edge Computing

MQTT juga dapat menjadi bagian dari arsitektur edge.

Misalnya:

Sensors
   ↓
ESP32
   ↓
Edge Gateway
   ↓
MQTT Broker
   ↓
Cloud

Edge gateway dapat melakukan:

• filtering;
• aggregation;
• local processing;
• protocol conversion;
• buffering;
• dan forwarding data.

Ini akan menjadi jembatan menuju pembahasan IoT tingkat lanjut.

MQTT dalam Sistem IoT Berskala Besar

Ketika jumlah perangkat bertambah:

10 Devices
      ↓
100 Devices
      ↓
1.000 Devices
      ↓
10.000 Devices

tantangannya juga berubah.

Kita mulai membutuhkan:

• device management;
• authentication;
• authorization;
• topic design;
• broker scalability;
• monitoring;
• load balancing;
• message persistence;
• data pipeline;
• security;
• dan observability.

Dengan demikian, belajar MQTT tidak berhenti pada:

“Bagaimana ESP32 mengirim data?”

Tetapi berkembang menjadi:

“Bagaimana membangun sistem messaging IoT yang aman, scalable, reliable, dan mudah dikelola?”

Kesimpulan

MQTT merupakan salah satu protokol komunikasi yang sangat penting untuk dipahami ketika mempelajari IoT.

Konsep dasarnya sebenarnya cukup sederhana:

Publisher
    ↓
MQTT Broker
    ↓
Subscriber

Namun di balik konsep tersebut terdapat berbagai fitur dan pertimbangan yang penting, seperti:

• MQTT client;
• broker;
• topic;
• publish;
• subscribe;
• payload;
• QoS 0, 1, dan 2;
• retained message;
• Last Will and Testament;
• session;
• authentication;
• authorization;
• TLS;
• ACL;
• monitoring;
• dan scalability.

Hal terpenting adalah memahami bahwa MQTT berfungsi sebagai mekanisme komunikasi, bukan sebagai database atau keseluruhan platform IoT.

Anda dapat membaca kembali Level 14 – IoT Security: Ancaman, Enkripsi, Authentication, dan Cara Mengamankan Perangkat. Tentang ancaman keamanan perangkat IoT, authentication, enkripsi, network security, hingga cara mengamankan perangkat dan data IoT.

Dalam sistem nyata, MQTT dapat menjadi bagian dari arsitektur:

Sensor
   ↓
Microcontroller
   ↓
MQTT
   ↓
Broker
   ↓
Backend
   ↓
Database
   ↓
Dashboard

Setelah memahami MQTT, kita sudah memiliki fondasi penting untuk membangun sistem IoT yang mampu mengirimkan data secara efisien dari perangkat menuju berbagai aplikasi. Maka saat ini kita dapat masuk ke salah satu penerapan IoT yang paling penting di dunia industri, yaitu Industrial IoT atau IIoT.

Materi tersebut akan dibahas pada Level 16 — Industrial IoT (IIoT): Teknologi, Arsitektur, dan Penerapannya di Industri.

Yang akan dibahas antara lain:

• teknologi,
• arsitektur,
• sensor,
• edge computing,
• MQTT,
• cloud,
• penerapannya di industri.