Fakultas Ilmu Komputer
Universitas Brawijaya 1578
Implementasi Gateway berbasis NRF24L01 dan ESP8266 pada Protokol
Message Queue Telemetry Transport - Sensor Network (MQTT-SN)
Harry Mulya1, Sabriansyah Rizkiqa Akbar2, Edita Rosana Widasari3 Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya
Email: 1harry.mulya10@gmail.com, 2sabrian@ub.ac.id, 3editarosanaw@ub.ac.id Abstrak
Wireless Sensor Network (WSN) merupakan jaringan nirkabel yang terdiri dari beberapa sensor node. WSN dapat diimplementasikan menggunakan protokol Message Queue Telemetry Transport (MQTT). MQTT adalah protokol yang berjalan diatas protokol TCP/IP, sehingga setiap node yang tidak memiliki antarmuka jaringan tidak dapat menggunakan protokol ini. protokol Message Queue Telemetry Transport - Sensor Node (MQTT-SN) diciptakan untuk menghubungkan perangkat-perangkat tersebut. Gateway merupakan perantara antara sensor node yang berjalan di protokol MQTT-SN dengan broker yang berjalan di protokol MQTT. Advertisement dan discovery merupakan mekanisme yang digunakan agar client dapat melacak identitas gateway, sehingga client dapet terkoneksi dengan gateway. Mekanisme ini sangat penting karena merupakan proses pertama sebelum melakukan proses lainnya seperti proses publishing. Pada penelitian ini penulis mencoba menerapkan mekanisme tersebut pada mikrokontroler arduino pro-mini dan NRF24L01 sebagai modul komunikasinya. Hasil dari penelitian ini adalah client mampu mengenali ID gateway yang ada dan gateway berhasil meneruskan data dari client sampai ke broker, yang ditandai diterimanya data oleh subscriber.
Kata Kunci: Wireless sensor network, MQTT-SN, NRF24L01, gateway, advertise, discovery
Abstract
Wireless Sensor Network (WSN) is a wireless network that consists of multiple sensor nodes. WSN can be implemented using a Message Queue Protocol Telemetry Transport (MQTT). MQTT is a protocol that runs of the TCP / IP protocol, so each node that doesn't have a network interface can't use this protocol. Message Queue Telemetry Transport protocol - Sensor Node (MQTT-SN) was created to connect the devices. The gateway is an intermediary between the sensor nodes that run in the MQTT-SN protocol with the broker that runs on the MQTT protocol. Advertisement and discovery is a mechanism used for the client to traces the identity of the gateway, so the client can connect with the gateway. This mechanism is very important because it is the first process before doing other processes such as publishing process. Therefore, this research proposed to implement the mechanism on microcontroller arduino pro-mini and NRF24L01 as communication module. The result of this research is the client able to recognize the existing gateway ID and gateway managed to pass data onto the client to the broker, which marked the receipt of the data by the subscriber.
Keywords: Wireless sensor network, MQTT-SN, NRF24L01, gateway, advertise, discovery
1. PENDAHULUAN
Dewasa ini teknologi Wireless Sensor Network (WSN) telah digunakan sebagai salah satu teknologi populer dari konsep Internet of Things (IoT) (Khalil, 2014), Wireless Sensor Network (WSN) merupakan jaringan nirkabel yang terdiri dari beberapa sensor node yang diletakkan di banyak tempat berbeda untuk memantau kondisi suatu area dan
mendistribusikan informasi yang di dapat secara nirkabel. WSN dapat di implementasikan dengan berbagai protokol, salah satunya adalah protokol Message Queue Telemetry Transport (MQTT).
Protokol Message Queue Telemetry Transport (MQTT) adalah protokol yang menggunakan konsep publish/subscribe dalam melakukan pengiriman data. MQTT menerapkan model client/server, dimana server pusat atau yang biasa disebut “broker” bertugas
menerima dan meneruskan pesan ke klien sehingga seluruh node terlibat dalam proses komunikasi (Prada, 2016). MQTT pada prinsip kerjanya berjalan diatas protokol TCP/IP, yang artinya setiap node yang tidak memiliki antarmuka jaringan tidak dapat menggunakan protokol ini (A. & H, 2007). Seiring semakin banyaknya kebutuhan untuk menghubungkan banyak perangkat atau node yang tidak memiliki antarmuka jaringan maka munculah sebuah protokol Message Queue Telemetry Transport – Sensor Node (MQTT-SN).
Message Queue Telemetry Transport – Sensor Node (MQTT-SN) yaitu protokol yang prinsip kerjanya seperti MQTT, namun secara spesifik MQTT-SN mampu di implementasikan pada jaringan sensor yang tidak memiliki antarmuka jaringan (Govindan & Azad, 2015). Untuk menghubungkan sensor node yang berjalan di protokol MQTT-SN dengan broker yang berjalan di protokol MQTT maka dibutuhkan sebuah perantara yang bisa mengubah format data dari MQTT-SN ke MQTT. Perantara ini biasa disebut “Gateway”. Agar client dapat terkoneksi dengan gateway maka dibutuhkan sebuah mekanisme agar client bisa melacak identitas dari gateway. Pada protokol MQTT-SN mekanisme tersebut dinamakan advertisement dan discovery.
MQTT-SN diciptakan khusus untuk diimplementasikan pada perangkat xbee. Xbee adalah modul komunikasi yang memanfaatkan gelombang frekuensi radio 2.4Ghz. Selain xbee ada pula perangkat lain yang sama-sama menggunakan frekuensi radio 2.4Ghz, yaitu NRF24L01. Modul ini memiliki 3 pilihan opsi data rate (250Kbps,1Mbps, dan 2Mbps) disamping itu modul juga memiliki konsumsi daya yang rendah dibandingkan xbee, yaitu 22uA pada posisi standby. Selain itu, NRF24L01 memiliki harga yang lebih rendah dibandingkan dengan modul Xbee dan Bluetooth (Nordic Semiconductor, 2014) sehingga cocok untuk diterapkan pada jaringan WSN.
Gateway dapat mengunakan modul wireless-fidelity untuk terhubung dengan broker. Hal ini dapat meningkatka fleksibilitas pada gateway. ESP8266 adalah modul wireless-fidelity yang umum digunakan pada perangkat mikrokontroler. Hal ini dikarenakan ESP8266 memiliki ukuran yang kecil dan konsumsi daya yang relatif hemat.
Oleh karena itu penelitian ini bertujuan untuk mengimplementasikan protokol
MQTT-SN pada node yang menggunakan modul komunikasi RF24L01 dan ESP8266 dan merancang mekanisme agar client bisa mengenali ID gateway yang aktif, serta agar client dapat tetap terhubung dengan gateway dalam jangka waktu lama.
2. PERANCANGAN DAN
IMPLEMENTASI
2.1 Perancangan Format Pesan
Setiap sub-sistem dapat saling berkomunikasi dengan cara mengirim sebuah pesan. Pesan ini memiliki berbagai macam jenis tergantung tujuannya. Berikut ini format pesan yang digunakan dalam penelitian ini yang terdiri dari format pesan advertise, searchgw, gwinfo, connect dan connack.
Tabel 1 Format Pesan Yang Digunakan
Dari tabel 1 diatas terlihat bahsa masing masing pesan memiliki muatan atau field yang berbeda beda sehingga ukuran dari tiap pesan juga berbeda. Ada satu kesamaan yaitu octet ke-0 dan ke-1 selalu diisi dengan length dan msgtype, adapun penjelasan dari tiap tiap field nya adalah sebagai berikut.
1. Length
Field ini selalu ada pada setiap jenis pesan, dan selalu diletakan di octet pertama. Field Length mengindikasikan seberapa panjang pesan yang dikirim. Nilai yang dikirim berupa nilai hexadesimal, sebagai contoh nilai 0x04 mengindikasikan jumlah total panjang pesan adalah 5 octet.
2. MsgType
Field ini selalu ada pada setiap jenis pesan, dan selalu diletakan di octet kedua. Field MsgType mengindikasikan jenis pesan yang dikirim, atau dapat juga dikatakan sebagai identitas untuk mengenali pesan apa yang dikirim/diterima. Adapun macam-macam ID dari tiap pesannya dijelaskan pada tabel 2 berikut.
Tabel 2 Keterangan MsgType Field
Nilai (Hexa) Nilai (Integer) Jenis Pesan
0x00 0 Advertise 0x01 1 Searchgw 0x02 2 GWinfo 0x04 4 Connect 0x05 5 Connack 3. ClientID
Field ClientID adalah field yang berisikan ID dari pengirim pesan tersebut.
4. GwID
Field GwID adalah field yang berisikan informasi dari ID gateway yang sedang aktif dan dikirim oleh gateway yang bersangkutan kepada client secara broadcast.
5. Duration
Field duration adalah field yang berisikan informasi keterangan waktu dengan satuan detik. Field ini berukuran 2 octet atau 16 bit sehingga waktu maksimal yang bisa dikirim adalah 2^16 detik atau 65.536 detik. Octet 4 merupakan MSB-nya dan octet 5 merupakan LSB-nya.
6. Flags
Flags merupakan field yang khusus digunakan untuk menaruh informasi-informasi tertentu yang sekiranya dibutuhkan sebagai penanda.
7. ProtocolID
Field protocolID merupakan field yang berisikan informasi dari revisi protokol yang sedang digunakan.
8. Radius
Radius adalah field yang berisikan informasi seberapa besar hop atau lompatan yang diijinkan dari suatu pesan yang dikirim. 9. ReturnCode
Field returnCode adalah field yang berisi informasi balasan dari suatu permintaan, Adapaun penjelasan isi dari field ini dapat dilihat dari tabel 3 berikut.
Tabel 3 Keterangan ReturnCode
Nilai Keterangan
0x00 Permintaan diterima 0x01 Permintaan ditolak
0x02 Permintaan ditolak, ID topik tidak valid
0x03 Permintaan ditolak, permintaan tidak didukung
0x04 –
0xFF Reserved / belum didefinisikan
2.2 Perancangan Gateway
Perangkat keras yang digunakan dalam perancangan gateway adalah Adalah arduino, NRF24L01, dan ESP8266. Ardunio berfungsi sebagai pengontrol bagi perangkat perangkat lainnya, sedangkan NRF24L01 berfungsi untuk berkomunikasi dengan client, dan ESP8266 untuk berkomunikasi dengan broker, dan yang terakhir adalah LCD display untuk menampilkan informasi yang didapat. Perangkat tersebut perlu dirangkai agar dapat bekerja menjadi sebuah sistem. Diagram blok dari perancangan perangkat keras gateway dapat diilustrasikan pada gambar 5.1.
Gambar 1 Perancangan Perangkat Keras Node
Gateway
Seperti yang sudah dijelaskan pada bab landasan kepustakaan, NRF24L01 berkomunikasi menggunakan antarmuka SPI (Serial Peripheral Interface), sedangkan pada ESP8266 menggunakan antarmuka UART (Universal Asynchronous Receiver-Transmitter), dan LCD display menggunakan antarmuka paralel untuk proses komunikasinya dengan mikrokontroler. Antarmuka-antarmuka tersebut sudah didukung oleh arduino pro-mini dan khusus untuk SPI dan UART sudah jalur/pin komunikasinya sudah disediakan oleh arduino sehingga tidak dapat dipindahkan ke pin lain. Untuk pin yang perlu disambungkan dapat dilihat pada skematik di gambar 2.
Perancangan perangkat lunak merupakan tahapan yang tidak kalah penting dari perancangan perangkat keras karena keduanya merupakan tahapan penting agar tahapan implementasi berjalan sesuai harapan. Perancangan perangkat lunak pada gateway adalah perancangan yang meliputi algoritma yang disesuaikan dengan kebutuhan fungsional dari gateway tersebut. Algoritma yang akan diterapkan pada gateway dapat dijabarkan pada diagram alir di gambar 3.
Gambar 2 Diagram Skematik Perangkat Keras Gateway
Gambar 3 Flowchart program gateway
Pada Gambar 3 menunjukkan bahwa proses pada WSN gateway dimulai dari tahap sistem gateway yang mengenali adanya pesan masuk
atau tidak, apabila terdapat pesan masuk maka gateway akan menyimpan pesan tersebut ke buffer lalu memeriksa pesan tersebut apakah pesan tipe 1 (searchGW), apabila benar pesan tipe 1 maka gateway akan mengirimkan pesan advertise, jika tidak maka akan diperiksa lagi apakah pesan tersebut adalah tipe pesan 4 (connect), jika benar pesan tipe 4 maka gateway akan memeriksa apakah ID client tersebut sudah ada dalam list node yang terkoneksi, jika tidak maka gateway akan menambahkan ID tersebut ke daftar, namun apabila tidak teridentifikasi adanya pesan masuk maka gateway akan memeriksa apakah pesan advertise terakhir dikirim lebih dari 15 menit yang lalu, jika ya maka gateway akan mengirimkan pesan advertise.
2.3 Perancangan Client
Perangkat keras yang digunakan dalam perancangan client adalah Adalah arduino, NRF24L01, dan LCD display. Ardunio berfungsi sebagai pengontrol bagi perangkat perangkat lainnya, sedangkan NRF24L01 berfungsi untuk berkomunikasi dengan gateway, dan LCD display untuk menampilkan informasi yang didapat. Perangkat tersebut perlu dirangkai agar dapat bekerja menjadi sebuah sistem. Diagram blok dari perancangan perangkat keras client dapat diilustrasikan pada gambar 4.
Gambar 4 Perancangan Perangkat Keras node
Client
Seperti yang sudah dijelaskan pada bab landasan kepustakaan, NRF24L01 berkomuni-kasi menggunakan antarmuka SPI (Serial Peripheral Interface), sedangkan LCD display menggunakan antarmuka paralel untuk proses komunikasinya dengan mikrokontroler. Antarmuka-antarmuka tersebut sudah didukung oleh arduino pro-mini dan khusus untuk SPI jalur/pin komunikasinya sudah disediakan oleh arduino sehingga tidak dapat dipindahkan ke pin lain. Untuk pin yang perlu disambungkan dapat dilihat pada skematik di gambar 5.
Gambar 5 Diagram Skematik Perangkat keras node client
Perancangan perangkat lunak merupakan tahapan yang tidak kalah penting dari perancangan perangkat keras karena keduanya merupakan tahapan penting agar tahapan implementasi berjalan sesuai harapan. Perancangan perangkat lunak pada client adalah perancangan yang meliputi algoritma yang disesuaikan dengan kebutuhan fungsional dari client tersebut. Algoritma yang akan diterapkan pada client dapat dijabarkan pada diagarm alir di gambar 6.
Pada gambar 6 menunjukkan bahwa proses pada client dimulai dari tahap inisialisai, lalu client akan memeriksa apakah client sudah terkoneksi, jika belum maka client akan memanggil fungsi connecting, jika sudah maka client akan memeriksa apakah waktu hidup gateway habis atau belum, jika habis maka client akan menganggap koneksi telah terputus dan client akan menghapus ID gateway tersebut dari daftar ID yang aktif, jika waktu hidup gateway belum habis maka client akan memeriksa apakah ada pesan masuk atau tidak ? jika ada maka client akan memanggil fungsi recvMsg. Waktu hidup gateway adalah waktu antara pesan advertise terakhir dengan waktu pesan advertise berikutnya. Seperti yang sudah dijelaskan pada sub-bab sebelumnya, waktu ini terdapat pada salah satu field pesan advertise yaitu fieldduration.
Gambar 6 Flowchart Program Main Pada Client
2.4 Perancangan Topologi Sistem
Penentuan topologi sistem sangatlah penting, karena hal ini berpengaruh pada prinsip kerja sistem. pada perancangan sistem ini topologi yang di gunakan adalah seperti gambar berikut.
Gambar 7 Topologi Sistem
Pada gambar 7 menjelaskan bahwa client terhubung dengan gateway menggunakan frekuensi radio pada frekuensi 2,4 Ghz. Gateway terhubung dengan broker pada jaringan TCP/IP berbasis wireless atau lebih dikenal wireless-fidelity. Topologi seperti ini cocok untuk menerapkan 2 protokol sekaligus yaitu MQTT dan MQTT-SN sesuai dengan
Broker
Gateway
Client
Jaringan TCP/IP
tujuan penelitian ini.
2.5 Implementasi Format Pesan
Tahap implementasi format pesan dilakukan di kedua sub-sistem yakni gateway dan client. Format pesan yang diimplementasikan harus sesuai dengan yang dirancang sebelumnya, adapun format pesan yang telah dirancang adaah pesan advertise, pesan searchgw, pesan gwinfo, pesan connect dan pesan connack
2.6 Implementasi Gateway
Tahap implementasi perangkat keras dari node gateway ini disesuaikan dengan perancangan yang telah dilakukan sebelumnya. Gateway terdiri dari arduino sebagai mikrokontrolernya, lalu ada NRF24L01 dan ESP8266 sebagai modul komonikasinya, dan terkahir adalah LCD display untuk menampilkan informasi yang didapat. Untuk lebih jelasnya hasil implementasi gateway tersebut bisa dilihat pada gambar 8 berikut ini.
Gambar 8 Hasil Implementasi Perangkat Keras
Gateway
2.7 Implementasi Client
Tahap implementasi perangkat keras dari nodeclient ini disesuaikan dengan perancangan yang telah dilakukan sebelumnya. Client terdiri dari arduino sebagai mikrokontrolernya, lalu ada NRF24L01 sebagai modul komonikasinya, dan terkahir adalah LCD display untuk menampilkan informasi yang didapat. Untuk lebih jelasnya hasil implementasi client tersebut bisa dilihat pada gamabr 9 berikut ini.
Gambar 9 Implementasi perangkat keras node
client
2.8 Implementasi Topologi Sistem
Sesuai dengan perancangan yang telah dilakukan sebelumnya, topologi yang digunakan adalah client terhubung langsung degan gateway menggunakan NRF24L01, sedangkan gateway terhubung dengan broker menggunakan jaringan wifi.
Gambar 10 Tampilan Hotspot Pada Komputer
Broker
Pada gambar 10 terlihat bahwa gateway yang menggunakan modul WiFi ESP8266 berhasil terkoneksi dengan laptop yang sekaligus berfungsi sebagai broker. Gateway yang memliki alamat MAC 5c:cf:7f:82:c7:5d ini mendapatkan alamat IP secara dinamis, sedangkan broker yang sekaligus berfungsi sebagai akses point ini memiliki alamat IP statis yaitu 192.168.137.1.
3. PENGUJIAN
3.1 Pengujian Tahap Pencarian Gateway Oleh Client
Pengujian ini bertujuan untuk mengetahui persentase keberhasilan client untuk mengenali ID gateway yang sedang aktif di area tersebut. Hasil dari pengujian ini ditampilkan pada serial
monitor berupa ID yang berhasil dikenali oleh client untuk kemudian dicocokan dengan id sesungguhnya pada gateway.
Gambar 11 Hasil Pengujian Tahap Pencarian
Gateway Oleh Client
Pada gambar 11 menjelaskan hasil tampilan pada serial monitor yang menampilkan ID Gateway yang berhasil dikenali. Pada pengujian ini yang didapatkan pada client yaitu data yang diterima dengan tipe pesan 2, dan client mendapatkan pesan GWINFO berupa id GW : BF. Serta apabila ID Gateway belum terdaftar maka ID Gateway tersebut akan ditambahkan pada list.
Pengujian percobaan pencarian id gateway dilakukan sebanyak 10 kali dengan hasil ID gateway yang berbeda-beda pada setiap pengujiannya, hasil tersebut dapat dilihat pada tabel 4 berikut ini.
Tabel 4 Tabel Hasil Percobaan Pencarian ID
Gateway
Pada pengujian yang dilakukan untuk percobaan pencarian ID Gateway dari 10 kali percobaan yang dilakukan. Pada setiap percobaan Client berhasil mengenali ID Gateway yang ada dan ID yang terdeteksi sesuai dengan ID pada Gateway, sehingga persentase keberhasilannya adalah 100%.
3.2 Pengujian Tahap Client Menjalin Koneksi Dengan Gateway
Pengujian ini bertujuan untuk mengetahui persentase keberhasilan dan rerata waktu yang dibutuhkan dalam proses menjalin koneksi dengan gateway.
Hasil dari pengujian ini ditampilkan pada serial monitor berupa ID yang berhasil dikenali dan waktu yang dibutuhkan mulai dari client
mengirim pesan connect sampai mendapat pesan balasan berupa pesan connack dalam satuan µS (microsecond).
Gambar 12 Hasil Pengujian dari koneksi client
dengan gateway
Pada gambar 12 menjelaskan hasil tampilan pada serial monitor pada saat client menjalani koneksi dengan gateway. Pada percobaan ini client mendapatkan pesan GWINFO dengan ID GW : A7 dan terkoneksi dengan gateway A7 dengan waktu 12308us. Selain ditampilkan pada serial monitor ID gateway juga ditampilkan pada LCD untuk mempermudah pemantauan.
Pengujian percobaan client terkoneksi dengan gateway ini dilakukan sebanyak 10 kali dengan tingkat keberhasilan dan waktu yang berbeda pada setiap pengujiannya, hasil tersebut dapat dilihat pada tabel 5 berikut ini.
Tabel 5 Tabel Hasil percobaan koneksi client dan
gateway
Dari data hasil percobaan yang didapat terlihat bahwa client mampu terkoneksi dengan gateway pada setiap percobaannya sehingga persentase keberhasilannya adalah 100%. Waktu yang dibutuhkan untuk menjalin koneksi cenderung sama pada setiap percobaannya, hanya pada percobaan ke-2 dan ke-5 memiliki sedikit perbedaan yaitu selisih 8 µS. Hal ini terjadi karena kondisi pengujian yang cenderung sama yaitu belum ada client lain yang sedang terhubung ke gateway sehingga gateway dalam keadaan idle sehingga baris
Percobaan ke- ID pada gateway ID yang terdeteksi Kesesuaian
1 BD BD Ya 2 BF BF Ya 3 B2 B3 Ya 4 A1 A1 Ya 5 A5 A5 Ya 6 E9 E9 Ya 7 E7 E7 Ya 8 3A 3A Ya 9 5B 5B Ya 10 DD DD Ya
Percobaan ke- Berhasil Terkoneksi Waktu (µS)
1 Ya 123.408 2 Ya 123.400 3 Ya 123.408 4 Ya 123.408 5 Ya 123.400 6 Ya 123.408 7 Ya 123.408 8 Ya 123.408 9 Ya 123.408 10 Ya 123.408
program yang dieksekusi cenderung sama dengan rerata waktu yang dibutuhkan adalah 123.406 µS.
3.3 Pengujian Tahap Menjalin Ulang Koneksi Dengan Gateway Baru
Pengujian ini bertujuan untuk mengetahui kemampuan client dalam memperbarui daftar ID gateway yang sedang aktif di sekitar client dan menjalin ulang koneksi agar ketika salah satu gatewaydown / mati, client bisa langsung terkoneksi dengan gateway yang lain.
Hasil dari pengujian ini ditampilkan pada serial monitor berupa ID gateway yang sudah terkoneksi beserta ID dari gateway yang baru aktif, ditampilkan juga status bahwa client berhasil menjalin koneksi dengan gateway lain. Pada pengujian ini dapat dijelaskan pada Gambar 13 yang menunjukkan bahwa tahap client menjalin hubungan dengan gateway yang baru yang sebelumnya terkoneksi dengan gateway A7 menjadi gateway E9.
Gambar 13 Tampilan serial monitor saat client
melakukan pergantian gateway
Pengujian tahap client menjalin ulang dengan gateway baru ini dilakukan sebanyak 10 kali dengan tingkat keberhasilan perpindahan gateway lama dengan gateway baru dengan keterangan ID Gateway yang didapatkan dari setiap percobaannya, hasil tersebut dapat dilihat
pada tabel 6 berikut ini.
Tabel 6 Hasil Percobaan saat terkoneksi dengan
gateway baru
Dari data hasil percobaan yang didapat terlihat bahwa client mampu mengenali gateway yang baru aktif dengan ID gateway yang berbeda-beda setelah client terkoneksi dengan sebuah gateway. Hasil ini juga membuktikan bahwa client mampu mempertahankan koneksi saat gateway tiba-tiba mati dengan cara menjalin koneksi ke gateway lain yang ID-nya telah dikenali sebelumnya dengan persentase keberhasilan mencapai 100% dari 10 kali percobaan yang dilakukan. 3.4 Pengujian Tahap Pemeliharaan
Koneksi
Pengujian ini bertujuan untuk mengetahui kemampuan gateway dalam memelihara koneksi ke client agar koneksi tidak terputus.
Hasil dari pengujian ini bisa dipantau melalui serial monitor pada sisi client. Informasi yang bisa didapat antara lain ID gateway yang terkoneksi, jumlah pesan advertise yang diterima, dan total waktu client tersebut terkoneksi pada gateway yang dimaksud. Keterangan tersebut terdapat pada Gambar 14.
Gambar 14 Tampilan serial monitor saat client
terkoneksi dengan gateway
Percobaan ke- ID gateway lama ID gateway baru Berhasil beralih gateway
1 A7 E9 Ya 2 E9 BD Ya 3 BD BF Ya 4 BF A3 Ya 5 A3 DD Ya 6 DD D4 Ya 7 D4 E1 Ya 8 E1 E2 Ya 9 E2 1B Ya 10 1B B4 Ya
Dan berikut merupakan hasil yang didapat dari percobaan ini adalah data berupa durasi saat client terhubung dengan client yang telah terkoneksi selama 1.453 menit yang ditampilkan secara detail pada Gambar 15.
Gambar 15 Tampilan serial monitor saat client
telah terkoneksi selama 1.453 menit
Dari data hasil percobaan yang didapat terlihat bahwa client masih terkoneksi dengan gateway hingga 1.453 menit atau setara 24 jam 13 menit. Hal ini membuktikan bahwa gateway mampu menjaga koneksi terhadap client dengan cara mengirimkan pesan advertise secara rutin hingga 1 hari penuh.
3.5 Pengujian Tahap Gateway Menjalin Koneksi Dengan Broker
Pengujian ini bertujuan untuk mengetahui rerata waktu yang dibutuhkan oleh gateway untuk terhubung dengan broker MQTT.
Hasil dari pengujian ini berupa waktu yang dibutuhkan gateway dari mulai pertama nyala hingga terkoneksi dengan broker yang ditampilkan pada LCD yang terpasang pada gateway ditampilkan pada Gambar 16.
Tabel ringkasan hasil percobaan dari koneksi gateway dengan broker yang dilakukan dengan keterangan percobaan dan waktu yang dibutuhkan dapat dilihat pada tabel 7 berikut ini.
Gambar 16 Tampilan LCD gateway saat
terkoneksi
Tabel 7 Tabel hasil percobaan koneksi gateway dan
broker
Dari data hasil percobaan koneksi datewa dan broker yang didapat terlihat bahwa waktu yang dibutuhkan untuk terkoneksi dengan broker cenderung sama dengan rerata waktu 6.085ms.
3.6 Pengujian Tahap Publish Data Oleh Client Ke Broker
Pengujian ini bertujuan untuk mengetahui persentase keberhasilan gateway dalam menjalanka tugsanya untuk meneruskan pesan publish dari client ke broker untuk selanjutnya bisa didistribusikan oleh broker.
Hasil pengujian publish data dari client ke broker yang didapat dari setiap percobaan pengiriman dijelaskna pada Gambar 17 yang merupakan LCD yang menampilnya data berupa angka acak pada client dan pada gateway. Pada Gambar 18 merupakan data yang berhasil dikirim oleh client dapat dilihat pada aplikasi yang digunakan subscriber.
Percobaan ke- Waktu yang dibutuhkan
1 6.102 2 6.082 3 6.072 4 6.123 5 6.076 6 6.105 7 6.072 8 6.072 9 6.072 10 6.078
Gambar 17 Tampilan LCD saat client mem-publish data
Gambar 18 Tampilan daftar data yang berhasil
diterima oleh subscriber
Berikut ini tabel ringkasan hasil percobaan pada pengiriman data dari client sampai ke subscriber, dari tingkat keberhasilan dan kesesuaian data yang dikirim dan diterima dapat disajikan dalam tabel 8.
Tabel 8 Tabel hasil percobaan publish data oleh
client ke broker
Dari data hasil percobaan yang didapat
terlihat bahwa gateway mampu untuk meneruskan data dari client ke broker tanpa ada kerusakan data dan dengan persentase keberhasilan yaitu 100%.
4. KESIMPULAN
Berdasarkan perancangan, implementasi, pengujian, dan analisis yang telah dilakukan, maka penulis menyimpulkan:
1. Protokol MQTT-SN dapat diimplemen-tasikan pada node yang menggunakan modul komunikasi NRF24L01 dan ESP8266 dengan bantuan library RF24. 2. Client mampu mengenali ID gateway
dengan cara menerapkan mekanisme discovery pada protokol MQTT-SN, yaitu client mengirim pesan searchGW secara broadcast dan gateway membalas dengan pesan GWinfo yang terdapat ID miliknya pada pesan tersebut, selain itu client juga mampu mengenali lebih dari 1 gateway secara bersamaan untuk keperluan backup jika gateway tersebut down agar bisa langsung terkoneksi ke gateway lainnya. 3. Koneksi antara gateway dan client dapat
tetap terjaga dengan mekanisme advertise, yaitu gateway akan mengirim pesan advertise secara berkala kepada client dan client akan menganggap koneksi terputus jika pesan advertise diterima dengan rentang waktu melebihi yang diatur sebelumnya dalam pesan tersebut.
DAFTAR PUSTAKA
Weiss, B. et al., 2013. A Publish/Subscribe Messaging System For Wireless Sensor Communication.
A., S. C. & H, T. L., 2007. MQTT for sensor networks (MQTTs) Protocol Specification V.1.2.
Avraham, Z., 2013. Building WSN with MQTT, RPI and Arduino.
Azzahidin, M. A., 2016. Implementasi Wireless Sensor Network Publisher Menggunakan Protokol Message Queue Telemetry Transport – Sensor Network (MQTT-SN). Bröring, A. et al., 2011. New generation sensor
web enablement. Volume 11.
Govindan, K. & Azad, A. P., 2015. End-to-end Service Assurance in loT MQTT-SN . Percobaan ke- Data yang dikirim Data yang diterima Berhasil diterima Data sesuai
1 102 102 Ya Ya 2 143 143 Ya Ya 3 142 142 Ya Ya 4 79 79 Ya Ya 5 160 160 Ya Ya 6 52 52 Ya Ya 7 3 3 Ya Ya 8 124 124 Ya Ya 9 114 114 Ya Ya 10 32 32 Ya Ya
Khalil, N., 2014. Wireless Sensors Networks for Internet of Things.
Nordic Semiconductor, 2014. Difference between NRF24L01, XBee and RF. s.l., s.n. Prada, M., 2016. Communication with Resource-Constrained Devices Through MQTT for Control Education
