Protokol MQTT untuk IoT (Internet of Things) dan Penerapannya pada Alat Penakar Hujan Otomatis ARG Rekayasa BMKG

 

• Pengertian MQTT

MQTT adalah singkatan dari Message Queuing Telemetry Transport. Ini adalah protokol pesan ringan untuk digunakan dalam kasus di mana klien membutuhkan jejak kode kecil dan terhubung ke jaringan yang tidak dapat diandalkan atau jaringan dengan sumber daya bandwidth terbatas. Ini terutama digunakan untuk komunikasi mesin-ke-mesin (M2M) atau jenis koneksi Internet of Things.

• Sejarah

MQTT awalnya dibuat oleh Dr. Andy Stanford-Clark dan Arlen Nipper pada tahun 1999. Tujuan awal dari metode komunikasi adalah untuk memungkinkan perangkat pemantauan yang digunakan dalam industri minyak dan gas untuk mengirim data mereka ke server jarak jauh. Dalam banyak kasus, perangkat pemantauan tersebut digunakan di lokasi terpencil di mana segala jenis sambungan telepon rumah, sambungan kabel, atau sambungan transmisi radio akan sulit, atau tidak mungkin, untuk dibuat. Pada saat itu, satu-satunya pilihan untuk kasus seperti itu adalah komunikasi satelit, yang sangat mahal dan ditagih berdasarkan berapa banyak data yang digunakan. Dengan ribuan sensor di lapangan, industri membutuhkan bentuk komunikasi yang dapat menyediakan data yang cukup andal untuk digunakan, dengan menggunakan bandwidth minimal. MQTT distandarisasi sebagai open source di bawah Organisasi Kemajuan Standar Informasi Terstruktur (OASIS) pada tahun 2013. OASIS masih mengelola standar MQTT.

• Arsitektur MQTT

MQTT berjalan di atas TCP/IP menggunakan topologi PUSH/SUBSCRIBE. Dalam arsitektur MQTT Broker menerima komunikasi dari klien dan mengirimkan komunikasi tersebut ke klien lain. Klien tidak berkomunikasi secara langsung satu sama lain, melainkan terhubung ke broker. Setiap klien dapat berupa penerbit, pelanggan, atau keduanya.

MQTT adalah protokol yang digerakkan oleh peristiwa. Tidak ada transmisi data berkala atau berkelanjutan. MQTT membuat transmisi menjadi minimum. Seorang klien hanya mempublikasikan ketika ada informasi yang akan dikirim, dan broker hanya mengirimkan informasi kepada pelanggan saat data terbaru tiba.

• Arsitektur pesan

Cara lain MQTT meminimalkan transmisinya adalah dengan konstruksi pesan kecil yang didefinisikan secara ketat. Setiap pesan memiliki header tetap hanya 2 byte. Header opsional dapat digunakan tetapi meningkatkan ukuran pesan. Muatan pesan dibatasi hanya 256 MB. Tiga tingkat Kualitas Layanan (QoS) yang berbeda memungkinkan perancang jaringan untuk memilih antara meminimalkan transmisi data dan memaksimalkan keandalan.

• QoS 0 – Menawarkan jumlah minimum transmisi data. Dengan level ini, setiap pesan dikirimkan ke pelanggan satu kali tanpa konfirmasi. Tidak ada cara untuk mengetahui apakah pelanggan menerima pesan tersebut. Metode ini kadang-kadang disebut sebagai "api dan lupakan" atau "paling banyak sekali pengiriman." Karena tingkat ini mengasumsikan bahwa pengiriman selesai, pesan tidak disimpan untuk dikirim ke klien yang terputus yang kemudian terhubung kembali.
• QoS 1 – Broker mencoba mengirimkan pesan dan kemudian menunggu tanggapan konfirmasi dari pelanggan. Jika konfirmasi tidak diterima dalam jangka waktu tertentu, pesan akan dikirim lagi. Dengan menggunakan metode ini, pelanggan dapat menerima pesan lebih dari satu kali jika broker tidak menerima pengakuan pelanggan tepat waktu. Ini kadang-kadang disebut sebagai "setidaknya sekali pengiriman".
• QoS 2 – Klien dan broker menggunakan jabat tangan empat langkah untuk memastikan bahwa pesan diterima, dan hanya diterima sekali. Ini kadang-kadang disebut sebagai "tepat sekali pengiriman".

Untuk situasi di mana komunikasi dapat diandalkan tetapi terbatas, QoS 0 merupakan pilihan terbaik. Untuk situasi di mana komunikasi tidak dapat diandalkan, tetapi koneksi tidak terbatas pada sumber daya, maka QoS 2 akan menjadi pilihan terbaik. QoS 1 menyediakan semacam solusi terbaik dari kedua dunia tetapi mengharuskan aplikasi yang menerima data mengetahui cara menangani duplikat.

Untuk QoS 1 dan QoS 2, pesan disimpan atau diantrekan untuk klien yang offline dan yang memiliki sesi persisten yang ditetapkan. Pesan-pesan ini dikirim ulang (sesuai dengan tingkat QoS yang sesuai) setelah klien kembali online.

• Topik

Pesan dalam MQTT diterbitkan sebagai topik. Topik adalah struktur dalam hierarki menggunakan karakter garis miring (/) sebagai pembatas. Struktur ini menyerupai pohon direktori pada sistem file komputer. Struktur seperti sensor/OilandGas/Tekanan/ memungkinkan pelanggan untuk menentukan bahwa itu hanya boleh dikirim data dari klien yang mempublikasikan ke topik Tekanan, atau untuk pandangan yang lebih luas, mungkin semua data dari klien yang dipublikasikan ke sensor/topik Oil and Gas . Topik tidak dibuat secara eksplisit di MQTT. Jika broker menerima data yang dipublikasikan ke topik yang saat ini tidak ada, topik tersebut dibuat begitu saja, dan klien dapat berlangganan topik baru.

• Pesan yang disimpan

Untuk menjaga agar footprint tetap kecil, pesan yang diterima tidak disimpan di broker kecuali jika ditandai dengan bendera yang dipertahankan. Ini disebut pesan yang disimpan. Pengguna yang ingin menyimpan pesan yang diterima harus menyimpannya di tempat lain di luar protokol MQTT. Ada satu pengecualian.

Sebagai protokol yang digerakkan oleh peristiwa, mungkin, bahkan mungkin, bahwa pelanggan mungkin menerima sangat sedikit pesan untuk topik tertentu, bahkan dalam jangka waktu yang lama. Dalam struktur topik yang disebutkan sebelumnya, mungkin pesan ke topik Tekanan hanya dikirim ketika sensor mendeteksi bahwa tekanan telah melebihi jumlah tertentu. Dengan asumsi bahwa apa pun yang dipantau sensor itu tidak sering gagal, bisa berbulan-bulan, atau bahkan bertahun-tahun sebelum klien memublikasikan pesan ke topik itu.

Untuk memastikan bahwa pelanggan baru menerima pesan dari suatu topik, pialang dapat menyimpan pesan terakhir yang dikirim ke setiap topik. Ini disebut pesan yang disimpan. Setiap kali klien baru berlangganan suatu topik atau ketika klien yang ada kembali online, pesan yang disimpan dikirim ke pelanggan, sehingga memastikan bahwa langganan aktif, dan memiliki informasi terbaru.

• Wasiat

Jika komunikasi tidak dapat diandalkan, ada kemungkinan penerbit akan memutuskan sambungan dari jaringan tanpa peringatan. Penerbit dapat mendaftarkan pesan untuk dikirim ke pelanggan jika penerbit terputus secara tidak terduga, ini disebut wasiat dan wasiat terakhir. Pesan ini di-cache di broker dan dikirim ke pelanggan jika penerbit tidak terhubung dengan benar. Biasanya, pesan tersebut mencakup informasi yang memungkinkan penerbit yang terputus untuk diidentifikasi sehingga tindakan yang tepat dapat diambil.

• Pesan MQTT

Untuk menjaga agar protokol tetap kecil, hanya ada empat tindakan yang mungkin dilakukan dengan komunikasi apa pun: publikasikan, berlangganan, berhenti berlangganan, atau ping.

• Publikasikan – Mengirim blok data yang berisi pesan yang akan dikirim. Data ini spesifik untuk setiap implementasi tetapi dapat berupa sesuatu yang sederhana seperti indikasi aktif/nonaktif, atau nilai sensor tertentu, seperti suhu, tekanan, dll. Jika topik yang dipublikasikan tidak ada, topik dibuat di broker.
• Berlangganan – Mengubah klien menjadi pelanggan suatu topik. Topik dapat berlangganan secara khusus atau melalui wildcard yang memungkinkan langganan ke seluruh cabang topik atau bagian dari cabang topik mana pun. Untuk berlangganan, klien mengirimkan paket SUBSCRIBE dan menerima paket SUBACK sebagai balasannya. Jika ada pesan yang dipertahankan untuk topik tersebut, pelanggan baru akan menerima pesan itu juga.
• PING – Seorang klien dapat melakukan ping ke broker. Paket PINGREQ dikirim oleh pelanggan dan paket balasan PINGRESP dikirim sebagai balasan. Ping dapat digunakan untuk memastikan bahwa koneksi masih berfungsi dan sesi TCP tidak ditutup secara tiba-tiba oleh peralatan jaringan lain seperti router atau gateway.
• DISCONNECT – Pelanggan atau penerbit dapat mengirim pesan DISCONNECT ke broker. Pesan ini memberi tahu broker bahwa ia tidak perlu lagi mengirim atau mengantre pesan untuk pelanggan dan tidak akan lagi menerima data dari penerbit. Shutdown semacam ini memungkinkan klien untuk terhubung kembali menggunakan identitas klien yang sama seperti sebelumnya. Ketika klien terputus tanpa mengirim pesan pemutusan, wasiat dan wasiat terakhirnya dikirim ke pelanggan

Tujuan awal dari protokol MQTT adalah untuk membuat transmisi data sekecil mungkin dan paling efisien melalui jalur komunikasi yang mahal dan tidak dapat diandalkan. Dengan demikian, keamanan bukanlah perhatian utama selama desain dan implementasi MQTT.

• Keamanan

Namun, ada beberapa opsi keamanan yang tersedia dengan biaya transmisi data yang lebih banyak dan jejak yang lebih besar.

• Keamanan jaringan – Jika jaringan itu sendiri dapat diamankan, maka transmisi data MQTT yang tidak aman tidak relevan. Dalam hal ini, masalah keamanan harus terjadi dari dalam jaringan itu sendiri, mungkin melalui aktor yang buruk atau bentuk lain dari penetrasi jaringan.
• Nama pengguna dan kata sandi – MQTT mengizinkan nama pengguna dan kata sandi bagi klien untuk membuat koneksi dengan broker. Sayangnya, untuk menjaga lampu overhead, nama pengguna dan kata sandi dikirimkan dalam teks yang jelas. Pada tahun 1999, ini lebih dari cukup karena mencegat komunikasi satelit untuk apa yang pada dasarnya adalah pembacaan sensor yang tidak penting akan sangat sulit. Namun, hari ini, mencegat banyak jenis komunikasi jaringan nirkabel adalah hal yang sepele, membuat otentikasi seperti itu tidak berguna. Banyak kasus penggunaan memerlukan nama pengguna dan kata sandi bukan sebagai perlindungan terhadap pelaku yang beritikad buruk, tetapi sebagai cara untuk menghindari koneksi yang tidak disengaja.
• SSL/TLS – Berjalan di atas TCP/IP, solusi yang jelas untuk mengamankan transmisi antara klien dan broker adalah penerapan SSL/TLS. Sayangnya, ini menambah overhead yang cukup besar untuk komunikasi yang ringan.

• Aplikasi MQTT di BMKG 

Dasar

Melihat dari kebutuhan pengukuran curah hujan serta permasalahan yang ada, maka diperlukan suatu sistem penakar hujan yang dapat mengukur curah hujan secara otomatis yang datanya bisa diakses secara realtime baik secara langsung dari lokasi terpasangnya sistem ini maupun dari jarak jauh dengan teknologi internet of things (IoT). Selain itu data logger diproduksi di dalam negeri dan berbiaya rendah.

Perancangan dan pembuatan hasil rekayasa peralatan 

BMKG telah merancang, merekayasa dan membuat suatu sistem dengan perangkat penakar hujan otomatis yang mengukur curah hujan dengan sensor tipping bucket dan kemudian menyimpan dan akuisisi datanya pada datalogger produksi dalam negeri yang terintegrasi dengan modem komunikasi yang menggunakan teknologi Internet of Things (IoT).

Sistem Penakar Hujan Otomatis IoT yang terdiri dari :

• Sensor tipping bucket, merupakan sensor pengukur hujan yang terdiri dari corong pengumpul dan mengalirkan air hujan yang jatuh ke wadah berupa jungkat-jungkit kecil yang apabila terjungkit akan mengirimkan sinyal listrik,
• Panel surya, dengan kapasitas 30 WP sebagai sumber isi ulang baterai 
• Enclosure, merupakan kotak pengaman data logger, baterai, solar regulator dan modem komunikasi,
• Data logger, merupakan alat pengolahan dan akuisisi data hasil pembacaan sensor tipping bucket yang dapat dikonfigurasi secara nirkabel,
• Modem komunikasi, merupakan alat yang dipasang dalam rangkaian data logger untuk mengirimkan data hasil pengukuran curah hujan,
• Solar regulator, komponen pengatur pengisian ulang sumber catu daya (baterai),
• Baterai merupakan sumber catu daya sistem.

yang dicirikan oleh sistem yang datanya bisa diakses secara realtime baik secara langsung dari lokasi terpasangnya sistem ini maupun dari jarak jauh dengan teknologi Internet of Things (IoT).

Penjelasan tentang penakar hujan IoT sebagai berikut :

• Sistem Penakar Hujan Otomatis IoT menggunakan sistem solar panel sebagai pembangkit listrik sehingga penempatan Sistem Penakar Hujan Otomatis IoT dapat diletakkan dimana saja tidak bergantung pada sumber listrik PLN.
• Sistem Penakar Hujan Otomatis IoT tersedia sarana modem komunikasi yang memungkinkan Sistem Penakar Hujan Otomatis IoT mengirimkan data curah menggunakan 3 (tiga) protokol komunikasi, yaitu FTP, HTTP, dan MQTT.
• Sistem Penakar Hujan Otomatis IoT tersedia sarana modem komunikasi yang memungkinkan Sistem Penakar Hujan Otomatis IoT mengirimkan data curah hujan secara realtime menggunakan protokol komunikasi MQTT.
• Sistem Penakar Hujan Otomatis IoT tersedia data logger yang dapat dikonfigurasi secara nirkabel.

Sumber : Dok. Pribadi

Lokasi pemasangan alat penakar hujan otomatis IoT dan informasi tampilan

Lokasi pemasangan di wilayah Jawa Barat :

1. ARG Rekayasa Telaga Saat
2. ARG Rekayasa Sukajaya
3. ARG Rekayasa Pacet
4. ARG Rekayasa Bendung Ciawi
5. ARG Rekayasa Cilember
6. ARG Rekayasa Caringin
7. ARG Rekayasa Tanjungsari
8. ARG Rekayasa Tenjolaya
9. ARG Rekayasa Cibinong

Lokasi pemasangan di wilayah Banten :

1. ARG Rekayasa Cianten
2. ARG Rekayasa Bojongmenteng
3. ARG Rekayasa Sobang

serta contoh tampilan data lokasi di wilayah Jawa Barat ( ARG Cibinong ) dan Banten ( ARG Sobang ) pada HP / telepon genggam.

Tampilan pada Aplikasi MQTT Dash (Sumber : Dok. Pribadi)