Backend MQTT dan WebSocket untuk IoT Waktu Nyata

Backend IoT perlu menangani perangkat terputus, pembacaan terlambat, dan protokol kendali yang berbeda. Pada saat yang sama, operator perlu segera melihat kejadian penting. Keandalan tampilan bergantung pada cara backend menerima, menyimpan, dan meneruskan data.

Dalam beberapa proyek IoT, saya memisahkan penerimaan data, penyimpanan kondisi serta riwayat, dan pengiriman pembaruan ke pengguna. MQTT membawa telemetri perangkat. PostgreSQL dan penyimpanan deret waktu menyimpan riwayat. WebSocket mengirim perubahan yang sudah diperiksa ke dasbor.

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

Penerimaan telemetri perangkat melalui MQTT

Untuk meter air, meter kWh, dan meter gas, MQTT cocok. Perangkat bisa kirim data kecil sesering yang dibutuhkan, tersambung kembali setelah jaringan putus, dan tetap hemat bandwidth. Backend harus memperlakukan MQTT sebagai kanal ingest, bukan acuan data utama — satu tempat yang jadi pegangan data paling benar.

Setiap pesan perangkat perlu divalidasi sebelum mengubah status sistem. Backend memeriksa ID perangkat, struktur topik, waktu kejadian, skema muatan data, satuan pengukuran, dan informasi urutan kalau tersedia. Data meter kWh berbeda dari meter gas, dan keduanya berbeda dari kejadian seperti tombol darurat yang ditekan.

Saya biasanya menormalisasi telemetri masuk ke format kejadian baku:

• Identitas perangkat dan lokasi
• Tipe meter dan satuan pengukuran
• Payload mentah dan nilai hasil penguraian
• Stempel waktu dari perangkat dan server
• Kunci urutan atau duplikat
• Penanda kualitas seperti valid, kedaluwarsa, di luar rentang, atau duplikat

Dasbor jadi lebih simpel karena yang dikonsumsi kejadian yang sudah dinormalisasi, bukan muatan data spesifik vendor. Untuk cara menyatukan banyak protokol ke satu model data, lihat normalisasi telemetri IoT multiprotokol.

Memisahkan kondisi terbaru dari riwayat

Pisahkan kondisi terbaru dari riwayat kejadian. Tabel kondisi terbaru menjawab apa yang sedang terjadi, sedangkan riwayat menyimpan setiap pesan untuk pemeriksaan. Penggabungan keduanya dapat membuat pembaruan baru menimpa bukti yang masih dibutuhkan.

Kesalahan umum: telemetri yang datang tidak berurutan bisa menimpa nilai lebih baru dan membuat dasbor terlihat salah. Pola yang lebih aman adalah menyimpan telemetri mentah untuk riwayat, dan memelihara tabel status terbaru terpisah.

Perbarui status terbaru sesuai aturan urutan yang ditetapkan, menggunakan nomor urut atau stempel waktu yang dapat dipercaya. Status terkonfirmasi tetap perlu pemeriksaan itu agar konfirmasi lama tidak menimpa pembacaan baru. Tabel kejadian mentah tetap menyimpan setiap pesan untuk audit dan debugging.

Untuk dasbor terkini, backend memublikasikan status valid terakhir lewat WebSocket. Untuk laporan, sistem kueri telemetri historis. Untuk peringatan, sistem mengevaluasi rules terhadap status terbaru dan usia heartbeat terakhir.

WebSocket untuk dasbor terkini

WebSocket berguna ketika operator butuh visibilitas langsung. Dasbor yang polling tiap beberapa detik mungkin cukup untuk data meteran lambat, tetapi tidak cukup untuk peringatan seperti tombol darurat, kejadian panggilan perawat, atau alarm peralatan.

Lapisan WebSocket menerima kejadian operasional yang sudah diperiksa, bukan pesan mentah perangkat. Pembacaan meter air menjadi pembaruan setelah divalidasi. Panggilan perawat menjadi peringatan ruangan, dan alarm PLC menjadi perubahan status mesin. Antarmuka kemudian cukup memahami model internal tanpa menangani protokol setiap vendor.

Dasbor tingkat ruangan juga perlu otorisasi. Pos perawat mungkin melihat semua ruangan di bagiannya, sementara teknisi hanya melihat peralatan di area tugasnya. Autentikasi koneksi WebSocket dan saring kejadian di sisi server sebelum mengirim ke peramban. Tangani perubahan hak akses, masa berlaku sesi, dan penyambungan ulang secara eksplisit.

Panggilan perawat, code blue, dan tombol darurat

Panggilan perawat, code blue, dan tombol darurat memiliki kebutuhan respons berbeda dari pembacaan meter. Meter dapat menoleransi sebagian keterlambatan, sedangkan panggilan bantuan membutuhkan prioritas pengiriman serta konfirmasi yang jelas.

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

Arsitektur juga perlu redundansi di level alur kerja. Peringatan WebSocket berguna, tetapi harus dipasangkan dengan aturan eskalasi internal. Kalau peringatan 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 kejadian internal. Adapter menangani interval polling, koneksi terputus, pemetaan register, dan perilaku jalur pengganti yang aman. Soal kapan harus polling dan kapan berbasis kejadian, saya bahas terpisah di Polling Modbus vs berbasis kejadian.

Dasbor tidak boleh berasumsi PLC selalu online. Tampilkan kesehatan koneksi dan kapan perangkat terakhir terlihat.

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

Menghubungkan pengelolaan pengunjung 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. Dasbor kemudian menampilkan okupansi, status pengunjung, kesiapan ruangan, atau kejadian akses dalam satu tempat.

Pertahankan tanggung jawab setiap sistem. Sistem pengunjung mengelola kunjungan, dan sistem gedung mengelola akses serta peralatan. Lapisan integrasi hanya meneruskan kejadian yang diperlukan keduanya.

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

Pelajaran utama

Backend IoT waktu nyata berhasil ketika dirancang dengan asumsi banyak hal tidak pasti. Perangkat terputus. Protokol berbeda. Kejadian datang terlambat. Peringatan keselamatan butuh perlakuan khusus.

Dasbor harus menerima kejadian operasional yang sudah dinormalisasi, bukan noise mentah dari tiap vendor. MQTT menyediakan jalur penerimaan data; keandalan bergantung pada aturan pengiriman, konfirmasi, penyimpanan, dan pemulihan. WebSocket memberi operator visibilitas terkini. PostgreSQL, adapter, dan riwayat kejadian membuat sistem bisa diaudit.

Dengan pembagian ini, operator melihat kondisi terbaru yang dapat ditelusuri ke sumber dan riwayatnya. Tampilan cepat tetap disertai dasar pencatatan yang diperlukan untuk pemeriksaan.