Backend MQTT dan WebSocket untuk IoT Real-Time

Backend MQTT dan WebSocket untuk IoT Real-Time

Backend IoT bukan cuma dashboard dengan angka live. Bagian tersulit adalah menangani device yang disconnect, sensor yang telat mengirim data, sistem kontrol yang pakai protokol berbeda, dan pengguna yang berharap dashboard bereaksi seketika saat sesuatu yang penting terjadi.

Di beberapa proyek freelance IoT dan integrasi, pola yang paling berhasil adalah memisahkan tiga tanggung jawab: ingest — tahap menerima dan mencatat data yang masuk dari device — penyimpanan state yang awet, dan pengiriman update ke pengguna. MQTT menangani telemetri dari device. PostgreSQL dan time-series storage menyimpan history. WebSocket mengirim live update ke dashboard.

Kalau Anda masih ragu kapan memakai masing-masing, lihat MQTT vs WebSocket untuk IoT real-time. PLC, nurse call, visitor management, dan sistem kontrol gedung diintegrasikan lewat adapter — bukan memaksa setiap vendor ke satu model.

Ingest MQTT untuk telemetri device

Untuk water meter, kWh meter, dan gas meter, MQTT cocok. Device bisa publish data kecil sesering yang dibutuhkan, reconnect setelah jaringan putus, dan tetap hemat bandwidth. Backend harus memperlakukan MQTT sebagai channel ingest, bukan source of truth — satu tempat yang jadi pegangan data paling benar.

Setiap pesan device perlu divalidasi sebelum mengubah state sistem. Backend memeriksa device ID, struktur topic, timestamp, skema payload, unit pengukuran, dan informasi urutan kalau tersedia. Data kWh meter berbeda dari gas meter, dan keduanya berbeda dari event seperti tombol panic yang ditekan.

Saya biasanya menormalisasi telemetri masuk ke format event kanonikal:

• Identitas device dan lokasi
• Tipe meter dan unit pengukuran
• Payload mentah dan nilai hasil parsing
• Timestamp dari device dan server
• Kunci sequence atau duplikat
• Flag kualitas seperti valid, stale, di luar range, atau duplikat

Dashboard jadi lebih simpel karena yang dikonsumsi event yang sudah dinormalisasi, bukan payload spesifik vendor. Untuk cara menyatukan banyak protokol ke satu model data, lihat normalisasi telemetri IoT multi-protokol.

Menyimpan last known state terpisah dari history

Bayangkan whiteboard di kantor yang menunjukkan status "hari ini," dan logbook terpisah yang mencatat setiap kejadian dari awal. Kalau keduanya digabung jadi satu, coretan baru bisa menimpa catatan lama yang justru lebih penting. Itu masalahnya kalau setiap nilai dashboard langsung disimpan sebagai state device.

Kesalahan umum: telemetri yang datang tidak berurutan bisa menimpa nilai lebih baru dan membuat dashboard terlihat salah. Pola yang lebih aman adalah menyimpan telemetri mentah untuk history, dan memelihara tabel latest-state terpisah.

Tabel latest-state hanya diperbarui ketika event masuk lebih baru dari state yang diketahui saat ini, atau ketika device secara eksplisit melaporkan state yang terkonfirmasi. Tabel raw event tetap menyimpan setiap pesan untuk audit dan debugging.

Untuk dashboard live, backend mempublikasi state valid terakhir lewat WebSocket. Untuk laporan, sistem query telemetri historis. Untuk alert, sistem mengevaluasi rules terhadap state terbaru dan usia heartbeat terakhir.

WebSocket untuk dashboard live

WebSocket berguna ketika operator butuh visibilitas langsung. Dashboard yang polling tiap beberapa detik mungkin cukup untuk data meteran lambat, tapi tidak cukup untuk alert seperti tombol darurat, event nurse call, atau alarm peralatan.

Layer WebSocket harus subscribe ke business event, bukan pesan device mentah. Event water meter menjadi update dashboard hanya setelah validasi dan normalisasi state. Event nurse call menjadi alert ruangan urgent. Alarm PLC menjadi event status mesin. Dengan begitu, frontend tidak perlu paham protokol tiap device.

Dashboard tingkat ruangan juga perlu otorisasi. Nurse station mungkin melihat semua ruangan di bagiannya, sementara teknisi hanya melihat peralatan di area tugasnya. Koneksi WebSocket harus mengautentikasi pengguna sekali, lalu memfilter event di sisi server sebelum mengirim ke browser.

Nurse call, code blue, dan tombol panic

Sistem IoT yang berkaitan dengan keselamatan butuh mindset berbeda dari telemetri biasa. Water meter bisa toleransi pembacaan yang telat. Code blue, nurse call, atau tombol panic darurat tidak bisa.

Untuk event-event ini, backend harus memprioritaskan latensi rendah, konfirmasi pengiriman, dan jejak audit. Sistem harus mencatat siapa yang memicu event, di mana terjadi, kapan alert diterima, siapa yang mengonfirmasi, dan kapan ditutup. Kalau dashboard terputus, event harus tetap ada di database dan tersedia ketika operator tersambung lagi.

Arsitektur juga perlu redundansi di level workflow. Alert WebSocket berguna, tapi harus dipasangkan dengan aturan eskalasi internal. Kalau alert tidak dikonfirmasi dalam batas waktu, sistem harus meneruskannya ke orang atau tim berikutnya yang bertanggung jawab.

Integrasi PLC di pabrik

Integrasi pabrik rumitnya beda lagi. PLC mungkin sudah mengontrol mesin, konveyor, sensor, atau lini produksi. Backend tidak boleh mencoba mengganti logika kontrol itu. Backend harus mengamati, menormalisasi, dan melaporkan.

Adapter penting di sini. PLC adapter menerjemahkan data spesifik vendor ke model event internal. Adapter menangani interval polling, connection loss, pemetaan register, dan perilaku fallback yang aman. Soal kapan harus polling dan kapan event-driven, saya bahas terpisah di Polling Modbus vs event-driven.

Dashboard tidak boleh berasumsi PLC selalu online. Tampilkan kesehatan koneksi dan kapan device terakhir terlihat.

Pola yang sama berlaku untuk dashboard yang menghubungkan sistem kontrol dari brand berbeda. Setiap brand punya API, protokol, atau model datanya sendiri. Layer integrasi memetakan sistem-sistem itu ke satu tampilan operasional, sambil tetap menampilkan identitas device asli dan sistem sumbernya untuk keperluan troubleshooting.

Menghubungkan visitor management dengan sistem gedung

Salah satu cerita integrasi paling praktis adalah menghubungkan visitor management dengan kontrol gedung. Pengunjung check-in, sistem memvalidasi kunjungan, dan sistem akses atau kontrol ruangan terkait mendapat informasi yang dibutuhkannya. Dashboard kemudian menampilkan okupansi, status pengunjung, kesiapan ruangan, atau event akses dalam satu tempat.

Kuncinya: jangan buat satu sistem vendor menjadi master untuk semuanya. Visitor management harus tetap menjadi sistem pengunjung. Kontrol gedung harus tetap menjadi sistem gedung. Layer integrasi hanya menyinkronkan event yang dibutuhkan kedua sistem.

Karena itu, simpan correlation ID. Ketika check-in pengunjung memicu event akses atau kontrol ruangan, dashboard bisa melacak rantainya: check-in pengunjung, permintaan akses, respons sistem kontrol, update status ruangan, dan setiap exception. Inilah yang mengubah kumpulan integrasi menjadi platform operasional.

Pelajaran utama

Backend IoT real-time berhasil ketika dirancang dengan asumsi banyak hal tidak pasti. Device terputus. Protokol berbeda. Event datang terlambat. Alert keselamatan butuh perlakuan khusus.

Dashboard harus menerima business event yang sudah dinormalisasi, bukan noise mentah dari tiap vendor. MQTT memberi backend jalur ingest yang andal. WebSocket memberi operator visibilitas live. PostgreSQL, adapter, dan history event membuat sistem bisa diaudit.

Hasilnya dashboard yang bukan cuma real-time secara visual, tapi bisa dipercaya secara operasional.