MQTT on Nalar

FCM Adalah Jalur Wake-Up, Bukan Transport Real-Time

Sat, 19 Sep 2026 00:00:00 +0000

FCM Adalah Jalur Wake-Up, Bukan Transport Real-Time

Aplikasi mobile dapat mempertahankan WebSocket ketika aktif dan tetap membutuhkan Firebase Cloud Messaging saat sistem operasi menangguhkannya. Kedua mekanisme itu menangani kondisi kegagalan yang berbeda.

WebSocket, MQTT, dan SignalR mengasumsikan client dapat berpartisipasi dalam sesi komunikasi yang hidup. FCM justru berguna ketika asumsi itu tidak lagi berlaku: aplikasi mungkin berada di background, prosesnya mungkin tidak berjalan, atau koneksi persistennya sudah hilang.

Menganggap FCM sebagai transport real-time lain menyamarkan boundary tersebut. Desain yang lebih kuat memakai live channel selama tersedia dan memperlakukan push delivery sebagai sinyal agar aplikasi kembali aktif lalu merekonsiliasi state.

MQTT dan QUIC Menyelesaikan Bagian Berbeda dari Transport Chat

Sat, 19 Sep 2026 00:00:00 +0000

MQTT dan QUIC Menyelesaikan Bagian Berbeda dari Transport Chat

MQTT dan QUIC sering ditempatkan dalam tabel perbandingan yang sama ketika membahas chat real-time. Perbandingan itu praktis, tetapi mencampur dua layer protokol yang berbeda menjadi satu pilihan.

MQTT adalah protokol messaging pada application layer. Ia mendefinisikan konsep seperti client, broker, topic, subscription, retained message, session state, dan quality of service untuk delivery. QUIC adalah protokol transport aman di atas UDP. Ia menyediakan connection, stream, flow control, loss recovery, encryption, dan mekanisme connection migration.

MQTT over TLS pada ESP32: Enkripsi Transport dan Autentikasi Broker Adalah Batas yang Berbeda

Sat, 19 Sep 2026 00:00:00 +0000

ESP32 yang memindahkan koneksi MQTT dari port 1883 ke 8883 tidak sekadar berpindah port. Stream TCP sekarang diharapkan membawa MQTT di dalam TLS. Data dalam perjalanan terlindungi hanya jika client TLS juga memvalidasi sertifikat broker. Autentikasi username/password MQTT merupakan mekanisme terpisah: kredensial mengidentifikasi client kepada broker, sedangkan validasi sertifikat mengidentifikasi broker kepada ESP32.

Menyebut konfigurasi ini “MQTT dengan HTTPS” mencampur dua protokol aplikasi. MQTT tidak berubah menjadi HTTP ketika TLS ditambahkan. MQTT dapat berjalan melalui TCP biasa atau melalui koneksi TCP yang dilindungi TLS.

State Sensor MQTT ESP32: Mengirim Suhu dan Kelembapan DHT22 dalam Satu Pesan JSON

Sat, 19 Sep 2026 00:00:00 +0000

Satu pembacaan DHT22 menghasilkan suhu dan kelembapan relatif dari sampling yang sama. Mengirim keduanya melalui topic MQTT terpisah memang bekerja, tetapi cara itu juga membuat dua batas pesan independen. Subscriber dapat menerima suhu baru sebelum nilai kelembapan pasangannya tiba.

Memasukkan kedua pengukuran ke satu payload membuat hubungan tersebut eksplisit:

copied = false, 1600)" class="absolute right-3 top-3 z-10 rounded-lg border border-line-strong bg-surface px-2 py-1 font-mono text-[0.8rem] text-muted opacity-0 transition group-hover:opacity-100 hover:bg-ink hover:text-white dark:border-night-line dark:bg-night dark:text-night-muted dark:hover:bg-white dark:hover:text-ink">

{"temperature":25.34,"humidity":60.21}

MQTT tidak mewajibkan JSON. Bagian yang berguna adalah kedua pengukuran dikirim dalam satu publication dan dapat diperlakukan sebagai satu snapshot state sensor.