📨 MQTT: Protokol Standar IoT

Publish/subscribe, broker, topic, QoS, retain, dan Last Will & Testament.

Arsitektur MQTT publisher broker subscriber

Publisher tidak tahu siapa subscriber-nya — broker yang menghubungkan

📌 1. Kenapa MQTT?

MQTT (Message Queuing Telemetry Transport) dirancang untuk jalur sempit dan perangkat terbatas: header hanya 2 byte, koneksi TCP jangka panjang, dan model publish/subscribe.

Broker — server pusat yang menerima pesan dan meneruskannya (mis. Mosquitto, AWS IoT Core).
Topic — "alamat" pesan, hierarkis dengan /, mis. home/kamar/temp.
Publisher — mengirim pesan ke topic (sensor).
Subscriber — mendaftar topic dan menerima pesan yang cocok (dashboard, rules engine).

💡 Keajaiban pub/sub: publisher tidak perlu tahu siapa yang menerima. Tambah 10 dashboard baru? Sensor tidak perlu diubah — cukup subscribe.

📌 2. Publish/Subscribe Dasar

Dua klien: sensor (publisher) dan dashboard (subscriber) dengan wildcard +.

# PUBLISHER: sensor suhu
pub = MQTTClient("sensor-01")
pub.connect()

# SUBSCRIBER: dashboard
sub = MQTTClient("dashboard-01")
sub.connect()

def on_message(client, userdata, msg):
    print("TERIMA  [%s] %s" % (msg["topic"], msg["payload"]))

# Wildcard '+': cocokkan SATU level apa pun
sub.subscribe("home/+/temp", on_message)

for i in range(3):
    suhu = read_sensor("dht22_temp")
    # Payload dict otomatis di-serialize ke JSON
    pub.publish("home/kamar/temp", {"suhu": suhu, "ts": now()}, qos=1)
    print("KIRIM   [home/kamar/temp] suhu=%.1f" % suhu)
    delay(10)

pub.disconnect()
sub.disconnect()

Output:

📌 3. Topic & Wildcard

Wildcard	Arti	Cocok dengan
`home/kamar/temp`	Exact	`home/kamar/temp` saja
`home/+/temp`	`+` = satu level apa pun	`home/kamar/temp`, `home/rumah/temp`
`home/#`	`#` = semua level di bawahnya	`home/kamar/temp`, `home/rumah/led`, ...

topic_matches("home/+/temp", "home/kamar/temp")  # True
topic_matches("home/#",      "home/a/b/c")       # True
topic_matches("#",           "apa/saja")          # True
topic_matches("home/+/temp", "a/b/c")            # False

⚠️ Konvensi penting: hindari spasi dan karakter khusus di topic. Struktur yang konsisten (mis. lokasi/ruang/parameter) membuat wildcard dan rules engine mudah dipakai.

📌 4. QoS: Level Garansi Pengiriman

QoS	Garansi	Use Case
0	Fire & forget — bisa hilang	Data yang boleh hilang (suhu tiap menit)
1	Minimal sekali — bisa duplikat	Telemetri penting, alarm
2	Persis sekali — tanpa duplikat	Pembayaran, counter (mahal, lambat)

QoS efektif = minimum dari QoS publisher dan subscriber. QoS 2 memakai 4-step handshake — jarang dipakai di IoT skala besar.

📌 5. Retain: Pesan yang Disimpan Broker

Pesan dengan flag retain=True disimpan broker. Setiap subscriber BARU yang cocok langsung menerimanya — berguna untuk "status terakhir" (mis. saklar: ON/OFF).

pub = MQTTClient("sensor-01"); pub.connect()
sub = MQTTClient("dashboard-01"); sub.connect()

def on_message(client, userdata, msg):
    print("TERIMA  [%s] %s" % (msg["topic"], msg["payload"]))

# Publish dengan retain: broker MENYIMPAN pesan terakhir
pub.publish("home/kamar/temp", "27.5", retain=True)
print("(belum ada subscriber — pesan disimpan broker)")
print()

# Subscriber baru langsung menerima pesan retained
sub.subscribe("home/kamar/#", on_message)
print()
print("Retained topic di broker:", sorted(broker.retained))

pub.disconnect(); sub.disconnect()

Output:

📌 6. Last Will & Testament (LWT)

Setiap klien bisa mendaftarkan "pesan wasiat": jika klien mati mendadak (baterai habis, jaringan putus) tanpa disconnect() yang sopan, broker mempublikasikan pesan itu. Ini cara sistem tahu bahwa sebuah device hilang.

pub = MQTTClient("sensor-01"); pub.connect()
sub = MQTTClient("monitor-01"); sub.connect()

def on_message(client, userdata, msg):
    print("TERIMA  [%s] %s" % (msg["topic"], msg["payload"]))

sub.subscribe("home/kamar/status", on_message)

# Daftarkan wasiat: jika sensor MATI, broker teriak "OFFLINE"
pub.set_will("home/kamar/status", "OFFLINE", retain=True)
pub.publish("home/kamar/status", "ONLINE", retain=True)
delay(5)

print("... sensor kehilangan koneksi (mati mendadak) ...")
pub.disconnect()   # LWT dipicu — broker mempublikasikan "OFFLINE"
sub.disconnect()

Output:

Kombinasi retain + LWT adalah pola standar: topic status selalu berisi kondisi terakhir device — ONLINE atau OFFLINE.

🧠 Latihan

Buat 2 publisher (sensor-01 suhu, sensor-02 RTH) dan 1 subscriber dengan filter home/#. Berapa pesan yang diterima?
Implementasi "saklar lampu" dengan retain: publish home/lampu/state = "ON"/"OFF" bergantian 4 kali, lalu subscriber baru — apa yang diterimanya pertama kali?
Uji topic_matches(): buat 5 pasangan (filter, topic) dan cetak hasilnya. Setidaknya 2 harus False.
Jelaskan: kenapa LWT penting untuk sistem keamanan (mis. kamera CCTV)? Apa yang terjadi jika tidak ada LWT?