STUDI KOMPARASI PERFORMA PROTOKOL HTTP DENGAN MQTT PADA SISTEM SMARTHOME NEURONTHINGS

(1)

STUDI KOMPARASI PERFORMA PROTOKOL HTTP

DENGAN MQTT PADA SISTEM SMARTHOME

NEURONTHINGS

LAPORAN TUGAS AKHIR

Oleh:

Muhammad Redho Darmawan 105216012

FAKULTAS SAINS DAN ILMU KOMPUTER

PROGRAM STUDI ILMU KOMPUTER

UNIVERSITAS PERTAMINA

SEPTEMBER 2020

(2)

STUDI KOMPARASI PERFORMA PROTOKOL HTTP

DENGAN MQTT PADA SISTEM SMARTHOME

NEURONTHINGS

LAPORAN TUGAS AKHIR

Oleh:

Muhammad Redho Darmawan 105216012

FAKULTAS SAINS DAN ILMU KOMPUTER

PROGRAM STUDI ILMU KOMPUTER

UNIVERSITAS PERTAMINA

SEPTEMBER 2020

(3)

(4)

LEMBAR PENGESAHAN

Judul Tugas Akhir : Studi Komparasi Performa Protokol HTTP dengan MQTT pada Sistem Smarthome NeuronThings

Nama Mahasiswa : Muhammad Redho Darmawan

Nomor Induk Mahasiswa : 105216012

Program Studi : Ilmu Komputer

Fakultas : Sains dan Ilmu Komputer

Tanggal Lulus Sidang Tugas Akhir : 1 September 2020

Jakarta, 17 September 2020 MENGESAHKAN Pembimbing 1 Ade Irawan, Ph.D. 116130 MENGETAHUI, Ketua Program Studi

Muhamad Koyimatu NIP. 116108

(5)

(6)

ABSTRAK

Muhammad Redho Darmawan. 105216012. Studi Komparasi Performa Protokol HTTP den-gan MQTT pada Sistem Smarthome NeuronThings.

Perkembangan teknologi dan implementasiInternet of Things(IoT) mendorong berbagai bentuk sistem yang mendukung pengumpulan data dari berbagaidevicedengan jumlah yang banyak. Salah satu sistem yang dapat mengandalkan IoT adalah sistemsmart homeyang memungkinkan pengendalian jarak jauh dan pengawasan data untuk device yang ada di rumah. Sehingga, berbagai jenis protokol komunikasi data mulai diciptakan dan digunakan untuk mengakomodasi keperluan tersebut. Salah satu protokol tersebut adalah protokolMessage Queuing Telemetry

Transport(MQTT) yang memiliki keunggulan pada pengiriman pesan di jaringan yang kurang

stabil.

NeuronThings adalah salah satu sistem smart home yang dikembangkan di Universitas Per-tamina. NeuronThings menggunakan protokolHyperText Transfer Protocol(HTTP), protokol yang umumnya digunakan dalam komunikasi website, sebagai pengumpul data dari device

IoT ke server. Sehingga, implementasi HTTP akan dibandingkan dengan MQTT di sistem NeuronThings untuk melihat perbedaan performa pada latencydan message size di beberapa tingkatan benyaknyauser untuk melihat apakah penggunaan HTTP sudah tepat dibandingkan dengan menggunakan MQTT. Hasil pengujian menunjukkan bahwa MQTT memilikilatency

lebih cepat dibandingkan dengan HTTP pada saat jumlahusersemakin besar. Sedangkan

mes-sage sizeMQTT juga lebih kecil dibandingkan dengan HTTP hingga dua kali lipat dari besar

pesan MQTT.

Kata kunci: IoT, Protokol IoT, HTTP, MQTT, Perbandingan Performa,Response Time, Smart

Home.

(7)

ABSTRACT

Muhammad Redho Darmawan. 105216012. Comparative Study of HTTP and MQTT Proto-col Performances on NeuronThings Smarthome System.

Technological advancement and its implementation in Internet of Things (IoT) has pushed many types of system that supports collection of various data from many devices at once. Smart home is one of those systems that benefits from using IoT to remote control and supervise data on a device at home. Many protocols have been made to accommodate the needs. Message Queuing Telemetry Transport (MQTT) is one of those protocol that excels in delivering message on unstable network.

NeuronThings is a smart home system that is developed in Universitas Pertamina. Neuron-Things uses HyperText Transfer Protocol (HTTP), a common protocol used in conventional website communication, as the protocol used to gather data from IoT devices to server. Imple-mentation of HTTP in favor of MQTT leads to effort comparing both protocol in NeuronThings environment. Difference in latency and message size in several levels of users number to. The test result shows MQTT has lower latency compared to HTTP the greater the number of user. MQTT message size is also smaller than HTTP by two times the message size of MQTT. Keywords: IoT, IoT Protocol, HTTP, MQTT, Performance Comparison, Response Time, Smart Home.

(8)

KATA PENGANTAR

Segala puji dan syukur penulis panjatkan kepada Allah SWT yang telah memberikan rahmat dan nikmatnya, sehingga penulis dapat menyelesaikan laporan tugas akhir ini dengan baik dan sesuai dengan jadwal yang telah ditentukan.

Penulis ingin mengucapkan terima kasih kepada pembimbing tugas akhir, Bapak Ade Irawan, yang telah memberikan bimbingan, nasihat, dan masukan terhadap penulis selama penulisan laporan tugas akhir. Penulis juga mengucapkan terima kasih ke seluruh jajaran staf akademik, khususnya dosen program studi Ilmu Komputer Universitas Pertamina yang telah memberikan ilmu dan bimbingan selama penulis menjalankan perkuliahan di Universitas Pertamina. Uca-pan terima kasih juga diberikan kepada teman-teman program studi Ilmu Komputer, khususnya angkatan 2016, yang telah bersama-sama menjalani kegiatan perkuliahan bersama dan mem-bantu dalam penyelesaian laporan tugas akhir ini.

Laporan tugas akhir ini masih jauh dari kata sempurna. Sehingga, berbagai kritik dan saran akan sangat berharga untuk memperbaiki laporan tugas akhir ini menjadi lebih baik.

Jakarta, 19 Juni 2020

Muhammad Redho Darmawan

(9)

DAFTAR ISI

ABSTRAK i

ABSTRACT ii

KATA PENGANTAR iii

DAFTAR ISI iv

DAFTAR TABEL vii

DAFTAR GAMBAR viii

BAB I PENDAHULUAN 1 1.1 Latar Belakang . . . 1 1.2 Rumusan Masalah . . . 2 1.3 Batasan Masalah . . . 2 1.4 Tujuan Penelitian . . . 2 1.5 Manfaat Penelitian . . . 2

BAB II TINJAUAN PUSTAKA 3 2.1 IoT . . . 3

2.2 Protokol Data IoT . . . 3

2.2.1 HTTP . . . 4

2.2.2 MQTT . . . 6

2.2.3 Perbandingan HTTP dengan MQTT . . . 9

2.3 Standar Pengukuran Performa Protokol Data IoT . . . 10

BAB III METODE PENELITIAN 11 3.1 Bentuk Penelitian . . . 11

3.1.1 Pembelajaran Sistem dengan Protokol HTTP . . . 11

3.1.2 Pembelajaran Sistem dengan Protokol MQTT . . . 12

3.1.3 Penentuan Kriteria Komparasi . . . 13

(10)

3.1.4 Pengujian Sistem . . . 13

3.1.5 Analisis dan Evaluasi Hasil Pengujian . . . 16

BAB IV HASIL DAN PEMBAHASAN 17 4.1 Pengujian Performa HTTP . . . 17

4.1.1 EndpointSensor-Data/Blast . . . 17

4.1.2 EndpointPower-Usage/Blast . . . 17

4.1.3 EndpointBehavior-Dataset/Blast . . . 18

4.2 Hasil Pengujian Performa HTTP . . . 19

4.2.1 Pengujian 1User . . . 19

4.2.3 Pengujian 100User. . . 22

4.3 Pengujian Performa MQTT . . . 24

4.4 Hasil Pengujian Performa MQTT . . . 25

4.5 Pengujian Reliabilitas QoS Level 2 MQTT . . . 29

4.5.1 Pengujian QoS 0 MQTT . . . 29

4.6 Perbandingan Performa Protokol HTTP dan MQTT . . . 30

4.6.1 Rata-RataLatency . . . 30

4.6.2 Rata-RataMessage Size . . . 31

BAB V KESIMPULAN DAN SARAN 33 5.1 Kesimpulan . . . 33

5.2 Saran . . . 33

LAMPIRAN A NeuronThings 34

(11)

DAFTAR PUSTAKA 40

(12)

DAFTAR TABEL

Tabel 2.1 Perbandingan antara HTTP dan MQTT . . . 9

Tabel 3.1 Endpointuntuk pengujian performa HTTP di NeuronThings . . . 13

Tabel 3.2 Sampleruntuk pengujian performa MQTT di NeuronThings . . . 14

Tabel 4.1 Tabel Agregat Hasil Pengujian HTTP untuk 1User . . . 20

Tabel 4.5 Tabel Agregat Hasil Pengujian MQTT untuk 1User. . . 26

Tabel 4.6 Tabel Agregat Hasil Pengujian MQTT untuk 10User . . . 27

Tabel 4.9 Tabel Agregat Hasil Pengujian MQTT QoS 0 . . . 29

Tabel A.1 Endpointyang digunakan untuk mengirim data di NeuronThings . . . 34

(13)

DAFTAR GAMBAR

Gambar 2.1 Protokol HTTP . . . 4

Gambar 2.2 3-Way Handshake . . . 5

Gambar 2.3 Protokol MQTT . . . 6

Gambar 2.4 Contoh Tingkatan Topik di MQTT . . . 7

Gambar 2.5 Subskripsi Topik . . . 7

Gambar 2.6 Quality of Service Level0 di MQTT . . . 8

Gambar 3.1 Diagram Alir Penelitian . . . 11

Gambar 3.2 Implementasi MQTT di NeuronThings . . . 12

Gambar 3.3 Struktur Topik di Sistem MQTT NeuronThings . . . 12

Gambar 3.4 RancanganTest Planuntuk HTTP . . . 14

Gambar 3.5 RancanganTest Planuntuk MQTT . . . 15

Gambar 3.6 Konfigurasi untuk Membatasi Kecepatan saat MengujiTest Plan . . . 16

Gambar 3.7 Test Planuntuk Pengujian Reliabilitas QoS Level 2 MQTT . . . 16

Gambar 4.1 KonfigurasiEndpointuntukSensor Data . . . 17

Gambar 4.2 KonfigurasiEndpointuntukPower Usage . . . 18

Gambar 4.3 KonfigurasiEndpointuntukBehavior Dataset . . . 19

Gambar 4.4 Response Time Graphuntuk 1Userpada Protokol HTTP . . . 20

Gambar 4.8 Konfigurasisampler publisheruntuk pengiriman data sensor . . . 24

Gambar 4.9 Konfigurasisampler subscriberuntuk pengiriman data sensor . . . 25

Gambar 4.10 Response Time Graphuntuk 1SubscriberdanPublisherpada Protokol MQTT 25 Gambar 4.11 Response Time Graph untuk 10 Subscriber dan Publisher pada Protokol MQTT . . . 26

(14)

Gambar 4.12 Response Time Graph untuk 100Subscriber danPublisher pada Protokol

MQTT . . . 27

Gambar 4.13 Response Time Graph untuk 500Subscriber danPublisher pada Protokol MQTT . . . 28

Gambar 4.14 Perbandingan Rata-RataResponse Timedari Kedua Protokol dengan Penam-bahanPublishdanSubscribeyang berbeda . . . 31

Gambar 4.15 Besar Pesan yang Dikirimkan HTTP . . . 32

Gambar 4.16 Besar Pesan yang Dikirimkan MQTT . . . 32

Gambar A.1 Pengambilan Data di Sistem NeuronThings . . . 34

(15)

(16)

BAB I

PENDAHULUAN

1.1 Latar Belakang

Internet of Things (IoT) adalah interkoneksi berbagai barang sehari-hari pada sebuah jaringan internet yang dapat dibekali dengan kecerdasan buatan (Xia et al., 2012). Interkoneksi tersebut dimungkinkan karena adanya komunikasi dan pertukaran data antar perangkat. Perkembangan perangkat IoT semakin didukung dengan perkembangan fitur produk harian yang tidak terlepas dari kebutuhan koneksi internet. Hal tersebut mendorong munculnya protokol-protokol baru untuk membantu komu-nikasi antar perangkat pada sistem IoT.

Protokol komunikasi data pada sistem IoT digunakan untuk menghubungkan berbagai perangkat IoT yang cenderung menggunakan energi yang kecil dengan spesifikasi tidak terlalu kuat. Dengan protokol data, perangkat IoT dapat mengirimkan data secara point-to-point ke sistem utama IoT. Karakteristik dari sistem IoT memungkinkan berbagai jenis implementasi IoT ke berbagai skenario di dunia nyata. Sehingga, terdapat berbagai macam protokol komunikasi data yang dapat digunakan di sistem IoT.

ProtokolMessage Queuing Telemetry Transport(MQTT) adalah salah satu protokol yang cocok untuk digunakan di sistem IoT. MQTT sudah dicetuskan sejak 1999 oleh Andy Stanford-Clark dari IBM dan Arlen Nipper dari Arcom Control System Ltd. MQTT didesain untuk komunikasiMachine to Machine(M2M) yang ringan dan dapat beroperasi di jaringan yang terbatas (Naik, 2017). MQTT menggunakan sistempublishdansubscribeuntuk mengirimkan pesan antarclient. (Fysarakis et al., 2016). Pesan di MQTT dikirim (publish) dengan topik tertentu yang dapat di pilih (subscribe) oleh klien yang mebutuhkan data dengan topik tersebut (Fysarakis et al., 2016). Karakteristik MQTT untuk bekerja denganresourceyang lebih sedikit dan sistempublish/subscribemenjadikannya salah satu protokol komunikasi yang cocok diterapkan di IoT (Hou et al., 2016).

Protokol data yang digunakan oleh NeuronThings adalahHyperText Transfer Protocol(HTTP). HTTP adalah protokol yang sudah digunakan internet sejak tahun 1990 (Fielding et al., 1999). HTTP dapat menerapkan arsitekturRepresentational State Transfer(REST). REST adalah gaya arsitektur yang berpusat pada resource yang dapat diakses melaluiinterfaceyang seragam olehclientdan server (Feng et al., 2009). State pada REST digunakan untuk menentukan jenis manipulasi resource yang dapat dilakukan olehclientterhadap resource tersebut (Feng et al., 2009).

Smart homeadalah konsep rumah yang menggunakan IoT untukremote monitoringdan pengelo-laan berbagai alat dan sistem (Rouse, 2018). Dengan konsep ini, pengguna dapat melakukan mon-itoringdan pengelolaan alat dan sistem rumah melalui perangkat yang terhubung dengan jaringan smart home. NeuronThings adalah salah satu sistemsmart homeyang dikembangkan di Universitas Pertamina. NeuronThings menggunakan perangkat Android untuk melakukan pengendalian ke alat rumah tangga yang terhubung dengan jaringan internet.

Sistem NeuronThings menggunakan protokol HTTP untuk pengambilan data darideviceIoT dan juga pengendalian beberapa fungsi di aplikasi. Penggunaan protokol HTTP sebagai pengumpul in-formasi darideviceIoT menjadi salah satu pilihan yang cukup berbeda oleh sistem NeuronThings.

(17)

Protokol MQTT lebih umum direkomendasikan di sistem IoT akibat karakteristik dari MQTT untuk bekerja di jaringan yang kurang stabil denganresourceyang lebih sedikit (Hou et al., 2016). Sedan-gkan protokol HTTP lebih umum digunakan dalam komunikasi di website. Sehingga, penelitian ini akan mengukur perbedaan performa antara kedua protokol di lingkungan sistem NeuronThings. Apakah penggunaan protokol HTTP sudah tepat dibandingkan menggunakan MQTT di sistem Neu-ronThings.

1.2 Rumusan Masalah

Penelitian ini membandingkan performa protokol data HTTP yang digunakan di sistem Neu-ronThings dengan protokol MQTT. Sistem NeuNeu-ronThings dimodifikasi untuk implementasi protokol MQTT. MQTT adalah protokol yang lebih umum digunakan pada sistem IoT dibandingkan dengan HTTP. Sehingga, Rumusan masalah dari penelitian ini adalah: Bagaimana perbedaan performa an-tara protokol MQTT dengan HTTP yang saat ini digunakan sistem NeuronThings dilihat dari segi kecepatan dan penggunaanresource?

1.3 Batasan Masalah

Performa yang diamati pada penelitian ini dibatasi pada pengiriman data menggunakan kedua protokol antaradeviceIoT ke sistembackendNeuronThings.

1.4 Tujuan Penelitian

Tujuan yang hendak dicapai adalah:

1. Terlihatnya perbedaan performa yang signifikan antara protokol MQTT dan HTTP untuk sistem IoT yang diterapkan di NeuronThings.

2. Teridentifikasinya perbedaan-perbedaan mendasar antara kedua protokol di sistemsamrt home.

1.5 Manfaat Penelitian

Performa dan penggunaanresourcemenjadi pertimbangan dalam mendesain sistem IoT. Penggu-naan protokol yang tepat dapat mengurangi beban data yang dikirimkan ke sistem dari perangkat IoT. Sehingga, perbedaan performa antara kedua protokol dapat menjadi acuan bagi sistemsmart home memilih protokol yang lebih tepat untuk ekspansi sistem kedepan.

(18)

(19)

BAB II

TINJAUAN PUSTAKA

2.1 IoT

IoT adalah gaya komputer yang menghubungkan berbagaidevicesehari hari melalui internet yang biasanya dilengkapi oleh kecerdasan buatan (Xia et al., 2012). Keterhubungan antardevicedigunakan untuk mengumpulkan data dari berbagai tempat secarareal-time. Secara umum, IoT memiliki 3 (tiga) lapisan, yaitu:

1. Perception layer, lapisan yang berisi sensor dandeviceyang digunakan untuk mengumpulkan data,

2. Network layer, lapisan yang menghubungkan seluruh sensor dandevicedalam sebuah jaringan, 3. Application layer, lapisan yang berfungsi mengolah data sesuai dengan keinginan dariuser

aplikasi.

Untuk melakukan penelitian yang lebih mendalam, lapisan di lingkungan IoT dapat dirumuskan men-jadi 5 (lima) lapisan, yaitu: (Sethi and Sarangi, 2017)

1. Perception layer,

2. Transport layer, lapisan yang mengirim data dari sensor dan device di perception layer ke processing layer,

3. Processing layer, lapisan yang memproses data yang dikumpulkan dariperception layer.Layer ini mencakupdatabase,big data analysis, dll.

4. Application layer,

5. Business layer, lapisan yang mengontrol seluruh sistem IoT.

Berdasarkanlayerpada IoT, penelitian ini hanya terbatas kepada protokol data padaapplication layer yang digunakan untuk melakukan komunikasi antar komponen yang bekerja pada IoT.

2.2 Protokol Data IoT

Protokol data atau komunikasi IoT adalah protokol yang digunakan untuk mengirimkan data dari berbagai poin di jaringan IoT. Protokol data yang digunakan IoT harus memiliki kadar penggunaan resourceyang sedikit untuk menerima berbagai data dari poin-poin di jaringan IoT. Ada berbagai macam protokol yang dapat digunakan di sistem IoT. Pada penelitian ini, protokol yang akan dibahas adalah HTTP dan MQTT.

(20)

2.2.1 HTTP

HTTP adalah protokolapplication-levelyang digunakan untuk melakukan berbagai tugas pada sebuah objek (object oriented protocol) menggunakan berbagai metode request, header, dan kode error dari protokol HTTP (Fielding et al., 1999). HTTP menggunakan pesanrequestdariclient ke serveruntuk melakukan suatu tugas tertentu kepada sebuah objek di server yang akan dibalas dengan pesanresponse, pesan mengenai status pengerjaan tugas tersebut, dariserverkeclient.

Gambar 2.1. Protokol HTTP

HTTP memiliki beberapa komponen yang digunakan untuk melakukan request dan response. Beberapa komponen tersebut yaitu URI,requestdanresponse, dan metode HTTP.

Uniform Resource Identifier(URI)

URI, dikenal juga sebagai alamatWorld Wide Web(WWW), adalah bagian dari HTTP yang digu-nakan untuk mengidentifikasi sebuahresourceberdasarkan sebuah nama, lokasi, maupun karakteris-tik tertentu yang sudah ditentukan.

Metode HTTP

Pesan requestmemiliki beberapa metode pengiriman yang digunakan untuk identifikasi proses yang akan dilakukan oleh server. Sehingga, berbagai proses yang berbeda dapat dilakukan pada satu URI yang sama. Berbagai metode yang terdapat pada HTTP adalah (Fielding et al., 1999):

1. OPTIONS. Metode ini digunakan untuk merepresentasikanrequestinformasi berkaitan dengan pilihan komunikasi yang tersedia pada rangkaianrequest-resourceyang ada di Request URI. 2. GET. Metode yang digunakan untuk mengambil seluruh informasi yang teridentifikasi oleh

Re-quest URI. Responseakan mengirimkan balik informasi yang didapat dalam bentuk message-bodydi dalam pesanresponse.

(21)

3. HEAD. Digunakan untuk mendapatkan informasiheaderdari sebuahresponsetanpa message-bodyyang ada apabila menggunakan metode GET.

4. POST. Metode untuk melakukan perubahan data yang telah disetujui dan ditetapkan fungsinya oleh server.

5. PUT. Metode ini digunakan untuk modifikasi data apabila terdapatresourcedengan URI yang sama, atau membuatresourcebaru apabila URI darirequesttidak ada di server.

6. DELETE. Metode untuk menghapusresourcesesuai dengan URI yang ada di dalamrequest. 7. TRACE. Metode yang digunakan untuk melihat apa yang diterima oleh server dari hasil

re-quest. HHal ini digunakan untuk keperluan diagnosis dan analisis masalah yang terjadi dalam metoderequest.

Reliabilitas Pengiriman Menggunakan HTTP

HTTP adalah protokol yang menggunakan TCP sebagai protokol transpornya. Pengiriman pesan menggunakan HTTP dijamin menggunakan TCP3-way handshake. TCP3-way handshake adalah algoritma yang digunakan TCP untuk membuka dan menutup koneksi antara klien dan server. Al-goritma ini bekerja dengan mengirimkan 3 (tiga) pesan antara kedua pihak untuk memastikan bahwa klien dapat menyetujui parameter untuk membuka koneksi TCP antara kedua pihak (Peterson and Davie, 2012). Gambar 2.2 akan menunjukkan bagaimana algoritma ini bekerja.

Gambar 2.2.3-Way Handshake

Pesan SYN yang dikirimkan klien akan mengirimkansequence numberyang akan diterima oleh server. Server kemudian akan merespon dengan pesan berisi ACK atau pengakuansequence number tersebut dansequence numberdari server sendiri. Klien kemudian akan mengirimkan pesan terakhir berisi ACK untuk pengakuan klien terhadapsequence numbermilik server. Apabilahandshaketidak menerima respon yang diharapkan dalam jangka waktu tertentu, maka TCP akan melakukan transmit ulang untuk segmen tersebut.

(22)

2.2.2 MQTT

MQTT adalah protokol yang menggunakan teknikpublishdansubscribeke sebuah topik. Bebe-rapaclient dapat tersambung ke sebuah broker, server yang bertindak sebagai perantara antarclient, dan melakukansubscribemaupunpublishtopik yang diinginkan. Ketika sensor mengirimkan data ke broker dengan topik tertentu, broker akan memberikan data tersebut keclientyang sudah melakukan subscribeke topik tersebut.Clientdapat melakukansubscribeke lebih dari satu topik. Apabilaclient melakukandiconnectsecaramanualmaupun tidak sengaja, broker akan menyimpan informasi topik yang di-subscribeolehclient, tergantung konfigurasisubscribe client(Light, 2018)(Errata, 2015).

Gambar 2.3. Protokol MQTT

MQTT memiliki beberapa komponen dalam penerapannya, antara lain sistempublishdan sub-scribe, topik dansubscription, danquality of service.

PublishdanSubscribe

PublishdanSubscribeadalah metode yang digunakan oleh protokol MQTT untuk mengirimkan pesan. Secara umum terdapat tiga pihak yang ada di dalam komunikasi menggunakan MQTT, Pub-lisher, Broker,danSubscriber.

1. Publisheradalah entitas yang memiliki data yang dinginkan oleh entitas lain.Publisher memi-liki kemampuan untuk melakukanpublishdata tersebut kebroker.

2. Subscriber adalah entitas yang menginginkan data dari entitas lain. Subscriber memiliki ke-mampuan untuk melakukansubscribeke data yang dinginkan melaluibroker.

3. Broker adalah entitas yang akan menghubungkan antara publisher dengan subscriber. Bro-ker akan menerima pesan dari publisher. Apabila terdapatsubscriber yang menerima pesan tersebut, makabrokerakan menghubungkan pesan tersebut kesubscriber.

(23)

TopikdanSubscription

Pesan di MQTT dikirimkan dalam bentuk topik. Saat mengirimkan topik,publishertidak perlu untuk melakukan konfigurasi. Topik ditata menjadi beberapa tingkatan topik. Sehingga, berbagai macam topik dapat disusun berdasarkan tema umum yang meliputi topik tersebut.

Gambar 2.4. Contoh Tingkatan Topik di MQTT

Berdasarkan gambar 2.4, beberapa topik berisi data dari masing-masing sensor dapat ditempatkan dibawah satu topik umum. Setiap topik dapat diambil secara spesifik olehsubscriber. Berdasarkan topik yang disubscribe,Subscriberakan mendapatkan data yang sesuai dengan topik tersebut. Ada berbagai cara untuk mendapatkan data tersebut. Subscriberdapat mengambil secara langsung satu topik spesifik, yang akan mengambil secara spesifik data tersebut. Cara lain untuk mendapatkan data adalah dengan menggunakan tandawildcard.

Wildcarddibagi menjadi dua tanda, tanda pagar (#) untukmulti-level wildcarddan tanda tambah (+) untuksingle-level wildcard.Multi-level wildcardakan mengambil data dari topik yang dipilih dan seluruh anak topik dibawahnya. Sedangkansingle-level wildcardakan mengambil topik yang dipilih dan anak topik sebanyak satu tingkatan topik saja. Perbedaan ini dapat dilihat di gambar 2.5.

Gambar 2.5. Subskripsi Topik

(24)

Reliabilitas Pengiriman danQuality of Service(QoS)

MQTT juga menggunakan TCP sebagai protokol transpor yang digunakan. Sehingga, pembuatan koneksi diawal antara klien dengan broker akan menerapkan3-way handshake. Selain menggunakan 3-way handshake, MQTT juga memiliki berbagai tingkatan QoS yang digunakan untuk menjamin pengiriman pesan tersebut.

MQTT memiliki beberapa tingkatan QoS yang menentukan tingkatan untuk memastikan pesan terkirim dari kebroker/subscriber(Errata, 2015). Tingkatan tersebut yaitu:

1. QoS 0 akan mengirim satu kali pesan ke penerima. Pada tingkatan ini, tidak ada konfir-masi balik mengenai keberhasilan pesan mencapai penerima. Sehingga, pengirim hanya akan melakukan PUBLISH sekali ke penerima.

Gambar 2.6.Quality of Service Level0 di MQTT

2. QoS 1 akan mengirim minimal satu kali pesan ke penerima. Apabila pesan yang dikirim berhasil mencapai penerima, maka pesan konfirmasi akan dikirim balik ke pengirim. Pengirim melakukan PUBLISH ke penerima. Apabila pesan sampai ke penerima, paket PUBACK akan dikirim, berisi packet identifier dari pesan PUBLISH yang diterima, ke pengirim. Sehingga, pengirim akan mengetahui bahwa paket PUBLISH telah diterima oleh penerima. Saat paket PUBACK dikirim, penerima sudah memiliki paket PUBLISH secara penuh, sehingga paket tersebut dapat digunakan atau diteruskan ke penerima lainnya.

3. QoS 2 akan mengirim pesan tepat satu kali ke penerima. Tingkatan ini akan melakukan se-ragam pengecekan untuk memastikan pesan yang dikirim pengirim tidak terduplikasi. Proses

(25)

konfirmasi ini diawali dengan pengiriman paket PUBLISH oleh pengirim ke penerima. Sete-lah paket PUBLISH diterima, penerima akan mengirim paket PUBREC yang berisi packet identifier dari paket PUBLISH ke pengirim. Setelah menerima PUBREC, pengirim akan me-ngirim paket PUBREL yang berisipacket identifier yang identik dengan paket PUBLISH se-belumnya. Apabila paket PUBREL telah diterima, penerima akan mengirimkan paket terakhir, PUBCOMP, ke pengirim yang menandakan berakhirnya pengiriman paket PUBLISH tersebut. Pada tingkatan ini, penerimaan paket PUBLISH secara penuh dapat dilakukan di dua waktu yang berbeda. Penerimaan dapat dilakukan saat akan mengirimkan PUBREL atau PUBCOMP. Pemilihan metode ini bergantung dengan bagaimana QoS 2 diimplementasikan.

2.2.3 Perbandingan HTTP dengan MQTT

Berdasarkan pembahasan sebelumnya, HTTP dan MQTT memiliki perbedaan yang banyak dalam melakukan pengiriman pesan. Sehingga, tabel 2.1 berikut akan menunjuk perbandingan antara pro-tokol HTTP dan MQTT (Naik, 2017).

Tabel 2.1. Perbandingan antara HTTP dan MQTT

Kriteria HTTP MQTT

Sistem Pengiriman PublishdanSubscribe RequestdanResponse

Arsitektur Client - Broker Client - Server

Message Size Maksimal 256 MB Tidak dispesifikkan, tergantung konfig-urasi (1MB - 2GB pada umumnya) Metode Connect, Dissconnect, Publish,

Sub-scribe

Post, Get, Put, Patch, dll. Protokol Trasnpor TCP TCP

Reliabilitas QoS Level 0 - 2 Terbatas pada TCP

Encoding Format Biner Teks

Keamanan TLS/SSL TLS/SSL

Kedua protokol menggunakan TCP sebagai protokol transpornya. Sehingga, pengiriman pesan di-jamin melalui adanya3-way handshakeyang dilakukan kedua protokol pada inisiasi koneksi. Perbe-daan paling besar kedua protokol terlihat pada sistem pengiriman pesan. HTTP menggunakan sistem requestdanresponse yang akan membuka koneksi dan mengirimkan pesan lalu menutup koneksi.

(26)

Sedangkan MQTT menggunakan sistempublishdansubscribeyang akan membuka dan memperta-hankan koneksi selama pengiriman data hingga adanya perintah untuk memutuskan koneksi.

Besar pesan yang dapat dikirimkan oleh MQTT memiliki maksimal hingga 256 MB berdasarkan spesifikasinya. Sedangkan HTTP tidak memiliki maksimal besar pesan yang terdefinisi oleh spesi-fikasinya. Sehingga, MQTT tidak dapat mengirimkan pesan yang berukuran sangat besar diband-ingkan dengan HTTP yang dibatasi berdasarkan konfigurasi batas pesan yang dapat dikirmkan oleh HTTP.

Implementasi IoT menggunakan HTTP dapat diterapkan pada lingkungan IoT yang memiliki jumlah pengiriman data darideviceIoT yang tidak banyak. Penerapannya juga lebih mudah karena protokol HTTP sudah digunakan secara luas untuk menangani pengiriman pesan padawebsite kon-vensional. Sehingga, apabila lingkungan IoT tidak terlalu luas dan tidak selalu memerlukanupdate yang sangat konstan, protokol HTTP dapat digunakan.

Implementasi IoT dengan MQTT sudah lebih umum digunakan untuk menangani sistem IoT. MQTT cocok digunakan untuk lingkungan IoT yang memerlukan pengiriman data secara konstan dengandeviceIoT yang banyak pada sebuah sistem. Sehingga, lingkungan IoT yang besar dengan keperluanupdateyang konstan dapat menggunakan protokol MQTT.

2.3 Standar Pengukuran Performa Protokol Data IoT

Berdasarkan penelitian sebelumnya oleh Fysarakis et al. (2016) dan Naik (2017), beberapa kom-ponen yang dapat diukur dalam penelitian komparasi performa protokol data IoT, yaitu:

1. Message sizedanoverhead. Komponen ini akan melihat seberapa besarheaderyang dihasilkan dan pesan yang dikirimkan oleh tiap protokol. Semakin kecil pesan danheader, semakin baik performa protokol.

2. Bandwidth danlatency. Pengukuranbandwidth digunakan untuk mengetahui seberapa besar bandwidth yang digunakan oleh protokol untuk mengirim pesan. Semakin kecil bandwidth yang digunakan, semakin efisien penggunaan bandwidth oleh protokol tersebut. Sedangkan Latencydiukur untuk mengetahui waktu yang diperlukan dari sesaat sebelumrequestdikirim hingga bagian paling awal dariresponsediterima kembali.

3. Reliability. Komponen ini menilai reliabilitas protokol dalam mengirimkan pesan. Reliabilitas protokol dapat dilihat melalui bagaimana pesan dapat terjamin untuk mencapai tujuan pengiri-mannya melalui protokol tersebut.

(27)

(28)

BAB III

METODE PENELITIAN

3.1 Bentuk Penelitian

Penelitian ini menggunakan metode eksperimen. Penelitian dilakukan dengan melakukan eksper-imen menggunakan dua sistem backend NeuronThings. Sistem pertama menggunakan backend Neu-ronThings dengan protokol HTTP. Sistem kedua menggunakan sistem backend NeuNeu-ronThings dengan protokol MQTT. Kedua sistem backend akan diuji dan dibandingkan antara kedua sistem. Diagram alir penelitian dapat dilihat di gambar 3.1 berikut.

Gambar 3.1. Diagram Alir Penelitian

3.1.1 Pembelajaran Sistem dengan Protokol HTTP

Sistem backend NeuronThings mengimplementasikan protokol HTTP untuk mengamil data dari perangkat IoT. Tahap ini digunakan untuk mempelajari pengiriman data menggunakan protokol HTTP di NeuronThings.

Pada NeuronThings, setiapdeviceyang tersambung dengan Raspberry Pi akan mengirimkan data dari sensor setiap 1 menit ke server utama. Pesan ini dikirimkan dengan mengirimkan perintah POST darideviceyang akan diterima server dan dimasukkan ke dalamdatabase. Aplikasi dismartphone

(29)

akan melakukan permintaan GET ke server untuk mendapatkan data yang diinginkan. Sehingga, aplikasi tidak dapat secara langsung mendapatkan data darideviceIoT.

Penelitian ini akan menggunakan tiga endpoint dari NeuronThings, sesuai dengan tabel A.1. Ketigaendpoint tersebut akan menerima data daridevicedan membalikkan respon ke pengirim re-quest. Aktivitasdatabasedimatikan untuk melihat perbedaan performa pengiriman pesan oleh kedua protokol.

3.1.2 Pembelajaran Sistem dengan Protokol MQTT

Perancangan dan penerapan protokol MQTT akan dilakukan setelah pembelajaran sistem dengan protokol HTTP selesai. Kriteria sistem akan disesuaikan dengan sistem yang telah ada di sistem sebelumnya. Sehingga, informasi yang diberikan dengan menerapkan MQTT tetap sama dengan HTTP.

Berdasarkan sistem yang sudah ada di NeuronThings, maka implementasi MQTT di Neuron-Things dapat menggunakan broker Mosquito yang dipasang di server NeuronNeuron-Things. Broker tersebut akan melayanipublishdarideviceIoT dansubcribe daridatabaseserver NeuronThings sendiri dan permintaan darismartphone. Sehingga, beberapa permintaan darihandphonedapat diterima langsung melaluisubscribetopik data langsung ke server broker. Implementasi dari sistem ini dapat dilihat di gambar 3.2 berikut.

Gambar 3.2. Implementasi MQTT di NeuronThings

Implementasi dideviceIoT dapat menggunakanpackagepaho-mqtt yang tersedia di lingkungan python yang digunakan device NeuronThings. Publish topik dari setiap data disesuaikan dengan permintaan POST yang dikirimkan dengan protokol HTTP. Sehingga, struktur topik yang digunakan di sistem sesuai dengan gambar 3.3 berikut.

Gambar 3.3. Struktur Topik di Sistem MQTT NeuronThings

(30)

Setiapserial-keydandevice-idadalah komponen unik yang dimiliki oleh deviceIoT. Sehingga, setiap topikserial-keydandeviceidmewakili satudeviceIoT yang mengirimkan data ke server. Sub-scriberdapat dengan juga dapat mengakses data tersebut dengan memilih topik sesuai dengan serial-keydandevice-idyang sesuai dengandeviceIoT yang ia miliki.

3.1.3 Penentuan Kriteria Komparasi

Pengujian sistem akan menggunakan beberapa kriteria. Berdasarkan penelitian sebelumnya oleh Fysarakis et al. (2016) dan Naik (2017), terdapat beberapa kriteria komparasi yang dapat digunakan untuk mengukur performa protokol di IoT. Pada penelitian ini, kriteria yang akan digunakan adalah message size and overhead, danlatency. Pada Jmeter, tes pada kedua protokol mengukurlatency, besar paket yang dikirimkan oleh protokol, hinggaerror ratedari setiap transaksi. Sehingga, pen-gukuran dari setiap kriteria akan disesuaikan dengan penpen-gukuran yang didapatkan dari Jmeter.

3.1.4 Pengujian Sistem

Kedua sistem akan diuji dengan menggunakan lingkungan yang identik dengan kriteria komparasi yang sudah ditentukan sebelumnya. Pengujian akan menggunakansoftwareJMeter dari Apache untuk mengukur performa setiap protokol terhadap kriteria komparasi. Protokol MQTT tidak dapat secara langsung diukur menggunakan Jmeter. Sehingga, diperlukan tambahanpluginmqtt-jmeter dari EMQ X. Jmeter akan menguji kedua protokol dengantest planyang sudah disiapkan. Duatest planyang berbeda disiapkan untuk melakukan pengujian ke kedua protokol tersebut. Kedua test plan akan menggunakanramp-up timepada pengujian dengan 100 dan 500useruntuk memudahkan koneksi di awal pengujian.

Test PlanProtokol HTTP

Test planpengujian protokol HTTP akan menggunakan beberapaendpointyang digunakan untuk mengirim data ke server. Melalui HTTPsampleryang dimiliki Jmeter, akan dilakukanrequestke tiga endpointyang akan mengirim data darideviceIoT ke server. Ketigaendpointtersebut dapat dilihat di tabel 3.1

Tabel 3.1.Endpointuntuk pengujian performa HTTP di NeuronThings

Endpoint Metode

/api/sensor-data/blast PUT

/api/power-usage/blast POST

/api/behavior-dataset/blast POST

Setiapendpointmemiliki data yang berbeda beda sesuai dengan data yang dibutuhkan olehdatabase server. Sehingga, akan ada sedikit perbedaan padabody-datayang akan dikirimkan setiapendpoint. Ketigaendpointkemudian akan dieksekusi 50 kali iterasi dengandelayantara duarequestsebanyak 100ms dandelay antara dua iterasi sebanyak 10s untuk menggambarkan delay 1 menit pada blast data di sistem NeuronThings. Loopakan dimasukkan dan dijalankan di dalam sebuahthread group yang berfungsi mensimulasikan sebuahdeviceIoT. Jumlahthread yang akan diuji yaitu dari 1, 10, 100, hingga 500user. Setiap samplerpada tes ini juga dilengkapi dengan HTTP header manager

(31)

untuk memberikan token yang digunakan mengautentikasi proses ke server. Konfigurasi daritest plan HTTP ini dapat dilihat pada gambar 3.4

Gambar 3.4. RancanganTest Planuntuk HTTP

Test PlanProtokol MQTT

Test planpengujian protokol MQTT akan menggunakan plugin tambahan dari EMQ X yaitu mqtt-jmeter. Menggunakan plugin tersebut, pengujian akan menggunakan MQTT Pub dan Subsampler untuk mensimulasikanpublisherdansubcriberdari setiap klien.Sampleryang akan digunakan sesuai dengan tabel 3.2.

Tabel 3.2.Sampleruntuk pengujian performa MQTT di NeuronThings

Sampler Jenis Klien Topic

MQTT Sub SD Subscriber sensor-data/threadNum/# MQTT Sub PU Subscriber power-usage/threadNum/# MQTT Sub BD Subscriber behavior-dataset/threadNum/# MQTT Pub SD Publisher sensor-data/threadNum MQTT Pub PU Publisher power-usage/threadNum MQTT Pub BD Publisher behavior-dataset/threadNum

Setiap variabel threadNum mewakili setiapdeviceyang disimulasikan. Jumlah dari tiapsampler kemudian disesuaikan di konfigurasithread padatest plandimulai dari 1, 10, 100, dan 500device sebanyak 50 kaliloop pengiriman data. Gambar 3.5 adalah konfigurasi test planuntuk pengujian MQTT dengan Jmeter.

(32)

Gambar 3.5. RancanganTest Planuntuk MQTT

Pada thread deviceuntuk subscriber, terdapat sebuah loop yang berisi tiga sampler subscribe dengan QoS level 2 untuk mewakili tigaendpointyang digunakan oleh protokol HTTP. Ketiga sam-pler ini akansubscribe ke masing masing topik sesuai dengan tabel 3.2 sebelumnya. QoS level 2 digunakan oleh setiapsampleruntuk memastikan bahwa data yang diambil tepat satu dari broker.

Thread deviceuntukpublishermemilikisampleryang digunakan untukpublishdata sesuai den-gan data yang dikirimkan oleh endpoint dengan protokol HTTP. Data dimasukkan didalam pesan yang akan dikirimkan tiap topik dalam bentuk JSON. Padathreadini, setiapsampler publish memi-liki delay 100ms diantara ketiga jenissampler(Pub SD, PU, dan BD) dan delay selama 10s diantara dualoop. Praktik ini digunakan untuk mengurangi beban broker di server yang kurang kuat untuk melayani langsung seluruh permintaan pada satu waktu dan mensimulasikandelay 1 menit antara blastdata di sistem NeuronThings.

Test PlanPengujian Reliabilitas MQTT QoS Level 2

Pengujian ini dilakukan untuk mengetahui reliabilitas yang didapatkan dari QoS 2 yang disedi-akan oleh MQTT. Sehingga, pesan yang disedi-akan diterima hingga kesubscriberadalah tepat satu pesan tanpa ada duplikasi.

Test planakan berisi transaksi normal dengan menggunakan MQTTsubsriberdanpublisher sam-pler sebanyak 10 user. Namun, kecepatan koneksi akan dibatasi melalui berkas konfigurasi Jme-ter. Pengaturan ini dilakukan dengan melakukan pembatasan kecepatan yang digunakan saat tes di-lakukan. Konfigurasi tersebut dapat dilihat pada gambar 3.6 berikut.

(33)

Gambar 3.6. Konfigurasi untuk Membatasi Kecepatan saat MengujiTest Plan Test planakan mensimulasikan jaringan dengan kecepatan maksimal GPRS sebesar 171 kbit/s. Angka 21888 didapatkan dari perhitungan dengan mengubah 171 kbit menjadi satuan bit untuk mewakilicharacter per secondyang digunakan Jmeter. Kemudian, setiap tingkatan QoS akan dites menggunakantest plansesuai dengan gambar 3.7.

Gambar 3.7.Test Planuntuk Pengujian Reliabilitas QoS Level 2 MQTT

Setiapthreadakan berisi 10useruntukpublisherdansubscriber. Iterasi akan dilakukan sebanyak 50 kali yang berlaku untuk kedua jenissampler. Delay 5s diantara inisiasisubscriberdanpublisher digunakan untuk memastikan keseluruhansubscribersudah memiliki koneksi denganbroker.

3.1.5 Analisis dan Evaluasi Hasil Pengujian

Penelitian ini menggunakan metode analisis kuantitatif. Metode analisis digunakan dalam per-bandingan hasil pengujian kedua sistem. Analisis berupa perper-bandingan antara kedua protokol berdasarkan kriteria yang didapatkan dari hasil tes menggunakan Jmeter. Sehingga, perbedaan performa kedua

(34)

protokol dapat terlihat. Tahap ini juga mencakup evaluasi dan simpulan terhadap hasil penelitian.

(35)

(36)

BAB IV

HASIL DAN PEMBAHASAN

4.1 Pengujian Performa HTTP

Menggunakantest planyang sudah disiapkan, pengujian performa untuk setiapendpoint harus disesuaikan dengan kriteriaendpoint tersebut. Setiap endpoint memiliki parameter yang berbeda-beda agar diterima oleh server. Sehingga, diperlukan konfigurasi yang berberbeda-beda diantara ketiga end-pointtersebut. Setiapendpointakan tertuju ke domain api-test.neurondigital.tech denganport8080. Konfigurasi dari setiapendpointadalah sebagai berikut.

4.1.1 EndpointSensor-Data/Blast

Pada konfigurasi sensor data blast, endpoint yang dituju adalah /api/sensor-data/blast dengan metode PUT. Parameter yang dimiliki olehrequestterdiri dari 5 data. Data tersebut berkaitan dengan data angka serialdeviceIoT dan data yang dikumpulkan dari sensordevice. Data-data tersebut terdiri atas value1, nilai temperatur yang diukur oleh sensor, value2, nilai yang berasal dari sensor untuk deteksi gerakan, value3, nilai kelembapan, dan value4 yang mengukur tingkat cahaya yang ada di ruangan. Nilai data dari setiap parameter masih dalam bentuk statis. Konfigurasi langsung di Jmeter dapat dilihat di gambar 4.1

Gambar 4.1. KonfigurasiEndpointuntukSensor Data

4.1.2 EndpointPower-Usage/Blast

Power usage blast akan mengirimkan data ke endpoint /api/power-usage/blast dengan metode POST. Parameter yang dimiliki oleh request ini berbeda dibanding parameter yang dimiliki oleh

(37)

sensor datablast. Walaupun terdiri dari 5 parameter juga, parameter dipower usage blastterdiri dari data iddevicebeserta dua switch yang diasumsikan dimiliki oledevicebeserta data arus listrik yang diambil dari kedua switch tersebut. Sehingga, data listrik tersebut dapat disimpan untuk digunakan oleh server memprediksi konsumsi listrik yang dihasilkan. Nilai data dari setiap parameter masih dalam bentuk statis. Konfigurasi langsung di Jmeter dapat dilihat di gambar 4.2

Gambar 4.2. KonfigurasiEndpointuntukPower Usage

4.1.3 EndpointBehavior-Dataset/Blast

Perbedaan antarabehavior dataset blastdenganpower usage blastmemiliki beberapa kesamaan pada parameternya.Behavior dataset blastakan mengirimkan data parameter keendpoint /api/behavior-dataset/blast dengan metode POST. Perbedaan parameter denganpower usage blastterletak pada data status1 dan status2 yang hanya bisa diisi oleh 0 dan 1. Nilai data dari setiap parameter juga masih dalam bentuk statis. Konfigurasi langsung di Jmeter dapat dilihat di gambar 4.3

(38)

Gambar 4.3. KonfigurasiEndpointuntukBehavior Dataset 4.2 Hasil Pengujian Performa HTTP

Pengujian performa HTTP dilakukan dengan menggunakan Jmeter sebanyak 1, 10, 100, dan 500 useryang disimulasikan. Server yang digunakan adalah server NoSQL yang digunakan oleh Neu-ronThings. Berikut adalah hasil dari setiaptest planyang mewakili jumlah deviceyang melakukan pengiriman data.

4.2.1 Pengujian 1User

Pengujian dengan 1 user pada test plan HTTP menunjukkan beberapa spike dengan response timeyang cukup tinggi. Response timeyang dicapai berkisar diantara 66ms. Namun, median dari ketigaendpoint tersebut berkisar pada 46ms. Grafik response time selama pengujian dapat dilihat pada gambar 4.4 dibawah.

(39)

Gambar 4.4.Response Time Graphuntuk 1Userpada Protokol HTTP

Pada gambar 4.4, dapat dilihat beberapa fluktuasi yang terjadi di ketigaendopinttersebut. Penye-bab dari fluktuasi yang terdapat di pengujian dapat berasal dari koneksi internet yang dipakai dalam pengujian kurang steril. Selain adanya fluktuasi, pengujian berjalan tanpa kendala. Walaupun memi-liki variasi response time yang cukup tinggi, median ketigaendpoint tidak tinggi. Median ketiga endpointberkisar pada 44ms untuk sensor data, 42ms untukpower usage, dan 51ms untukbehavior dataset. Tabel agregat dari hasil pengujian dapat dilihat pada tabel 4.1.

Tabel 4.1. Tabel Agregat Hasil Pengujian HTTP untuk 1User

Label

POST SD

POST PU

POST BD

TOTAL

# Samples

50

150 Average

71

52

73

66 Median

44

42

51

46 90% Line

155

59

138

144 95% Line

156

130

174

171 99% Line

219

176

497

219 Min

40

38

46

38 Max

219

176

497

497 Error %

0.00%

Throughput

0.07531

0.0753

0.22512

Received KB/sec

0.01

0.02

0.05 Sent KB/sec

0.05

0.15

Pengujian dengan 10userjuga menunjukkan performa yang lebih stabil dibandingkan pengujian sebelumnya. Sesuai dengan gambar 4.5 yang menunjukkan grafikresponse timedari hasil pengujian, rata-rataresponse time lebih rendah dibandingkan dengan pengujian sebelumnya. Namun, median dari ketigaendpointrelatif sama dengan pengujian sebelumnya.

(40)

Berdasarkan gambar 4.5, lebih sedikit fluktuasi response time yang terjadi selama pengujian dibandingkan dengan pengujian sebelumnya. Hal ini dapat disebabkan oleh kualitas koneksi ke server yang bervariasi antara kedua pengujian. Sehingga, pengujian dengan 1usermemiliki fluktuasi yang lebih beragam dibandingkan dengan pengujian 10user. Rata-rataresponse timedari sensor datablast danpower usageadalah 49ms dan 47ms secara berurutan. Endpoint behavior dataset blast menda-patkan rata-rataresponse time yang lebih tinggi dibandingkan kedua endpoint sebelumnya dengan rata-rata 59ms. Ketiga endpoint mencatatkan rata-rata response time yang lebih rendah daripada pengujian sebelumnya. Namun, median dari ketigaendpoint tersebut tetap sama dengan pengujian sebelumnya. Tabel agregat hasil pengujian dapat dilihat pada tabel 4.2 berikut.

Label

POST SD

POST PU

POST BD

TOTAL

# Samples

500

500 1500

Average

49

47

59

52 Median

43

51

46 90% Line

71

66

73

70 95% Line

80

75

89

82 99% Line

121

103

134

124 Min

37

45

37 Max

197

130 1058

1058

Error %

0.00%

Throughput

0.75396

0.754 0.75401

2.25385

Received KB/sec

0.15

0.45 Sent KB/sec

0.49

0.53

1.54

Universitas Pertamina - 21

(41)

Pengujian dengan 100usermemilikiresponse timeyang lebih beragam dibandingkan kedua pen-gujian sebelumnya. Terdapat beberapaspike selama pengujian ketigaendpoint. Rata-rataresponse timeketigaendpointsecara umum lebih tinggi dibandingkan pengujian sebelumnya.Behavior dataset blasttetap menjadi endpoint dengan rata-rata response time yang lebih tinggi dibandingkan kedua endpointlainnya. Grafikresponse timedapat dilihat pada gambar 4.6 berikut.

Berdasarkan gambar 4.6,response timedari ketigaendpointlebih fluktuatif dibandingkan dengan kedua pengujian sebelumnya. . Ketigaendpointmemperlihatkan variasi fluktuasiresponse timeyang lebih tinggi dibandingkan pengujian sebelumnya. Berdasarkan Tabel agregat hasil pengujian pada tabel 4.3, beberapa koneksi keendpoint dapat mencapairesponse timeselama 1040ms di beberapa bagian tertentu selama pengujian. Rata-rataresponse time dari ketiga endpoint relatif lebih tinggi dibandingkan pengujian sebelumnya. Namun, median dariresponse timerelatif tetap sama dengan pengujian sebelumnya. Sensor datablastdanpower usage blast mengalami kenaikan rata-rata re-sponse timemenjadi 94ms dan 79ms secara berurutan. Sedangkan,behavior dataset blastmemiliki rata-rata yang lebih tinggi denganresponse time 120ms. Pada pengujian, error ratedari endpoint sensor data danbehavior datasetmelaporkan 0.08% dan 0.04% secara berurutan.Error ratetersebut menjadi laporan pertama adanya kehilanganerrorpada pengiriman paket dariendpointke server.

(42)

Label

POST SD

POST PU

POST BD

TOTAL

# Samples

5000

15000

Average

94

79

120

97 Median

43

53

46 90% Line

59

57

82

66 95% Line

70

66

116

86 99% Line

1045

1040

1333

1059

Min

36

44

36 Max

21005

15058

21005

Error %

0.08%

0.00%

0.04%

Throughput

6.44437

6.44491

6.44527

19.275 Received KB/sec

1.27

1.32

3.9 Sent KB/sec

4.14

4.54

4.55

13.2

Pengujian dengan 500 user memiliki variasi response time yang lebih beragam dibandingkan pengujian sebelumnya. Ketiga endpoint memiliki rata-rata response timedan median yang relatif lebih tinggi dibandingkan dengan pengujian sebelumnya. Grafik yang memperlihatkanresponse time tersebut dapat dilihat di gambar 4.7 berikut.

Gambar 4.7 menunjukkanresponse time yang mulai naik sejak awal pengujian. Rata-rata Re-sponse timeketigaendpointberkisar di 94ms untuk sensor data, 90ms untukpower usage, dan 126ms untukbehavior dataset. Berdsarkan tabel agregat pengujian di tabel 4.4, median dari ketigaendpoint relatif lebih tinggi dibandingkan dengan pengujian sebelumnya. Behavior datasetmemiliki perbe-daan median paling tinggi menjadi 80ms, dibandingkan dengan 53ms di pengujian sebelumnya. Pada pengujian ini, terdapat benyak fluktuasi selama pengujian yang mengakibatkan median dan rata-rata

(43)

response timeketigaendpointmenjadi lebih tinggi dibandingkan pengujian sebelumnya. Penambahan jumlahuser menyebabkan lebih banyaknyarequestyang didapatkan oleh server secara bersamaan. Sehingga, lebih banyak koneksi yang memilikiresponse timelebih tinggi dibandingkan dengan pen-gujian sebelumnya yang hanya melayani 100user.

Label

POST SD

POST PU

POST BD

TOTAL

# Samples

25000

75000

Average

93

90

126

103 Median

52

49

80

58 90% Line

108

103

155

128 95% Line

229

235

285

259 99% Line

1057

1052

1090

1066

Min

36

44

36 Max

21003

21002

21004

Error %

0.00%

0.01%

0.03%

0.02%

Throughput

31.72798

31.72935

31.72681

94.88518

Received KB/sec

6.2

6.48

6.5

19.12 Sent KB/sec

20.42

22.37

22.39

64.98

4.3 Pengujian Performa MQTT

Menggunakantest planMQTT yang sudah disiapkan, konfigurasi untuksubscriberdanpublisher diperlukan untuk menyesuaikan data sesuai dengan informasi yang diharapkan oleh server. Konfig-urasi data yang dikirimkan olehpublisher disamakan dengan data yang dikirimkan oleh protokol HTTP untuk melihat besar pesan dibandingkan dengan HTTP. Konfigurasisampler publisher dan subscriber dari sensor data sebagai gambaran untuk konfigurasi lainnya dapat dilihat pada gambar 4.8 dan 4.9.

Gambar 4.8. Konfigurasisampler publisheruntuk pengiriman data sensor

(44)

Gambar 4.9. Konfigurasisampler subscriberuntuk pengiriman data sensor 4.4 Hasil Pengujian Performa MQTT

Pada pengujian dengan 1subscriber danpublisher dengan protokol MQTT, menunjukkan per-forma yang relatif stabil untuk ketigasampler publisher dan subscriber. Sesuai dengan grafik re-sponse timepada gambar 4.10, tidak banyak fluktuasi yang dialami olehsampler publishermaupun subscriber.

Gambar 4.10.Response Time Graphuntuk 1SubscriberdanPublisherpada Protokol MQTT Rata-rataresponse timeyang dicatat masing-masingsamplertidak terlalu berbeda antara keenam sampler. Pada sampler publish, MQTT Pub SD, MQTT Pub PU, dan MQTT Pub BD mencatat rata-rataresponse timeselama 41ms, 40ms, dan 40ms secara berurutan. Sedangkan untuk sampler subscribe, MQTT Sub SD, MQTT Sub PU, dan MQTT Sub BD memiliki rata-rata response time 40ms, 38ms, dan 38ms secara berurutan. Secara umum, tidak banyak fluktuasi yang tinggi terjadi pada pengujian dengan 1user. Tabel berisi agregat pengujian dapat dilihat di tabel 4.5.

Pengujian dengan 10subscriber danpublisherdengan protokol MQTT menunjukkan performa yang relatif sama dengan dengan pengujian sebelumnya dengan 1user. ketigasampleruntuk masing-masing publisher dan subscriber tidak mengalami banyak fluktuasi dengan tambahan menjadi 10 user.Response timeselama pengujian dapat dilihat pada gambar 4.11 berikut.

(45)

Tabel 4.5. Tabel Agregat Hasil Pengujian MQTT untuk 1User

Label MQTT Connect MQTT Pub SD MQTT Sub SD MQTT Pub PU MQTT Sub PU MQTT Pub BD MQTT Sub BD MQTT DisConnect TOTAL

# Samples 2 55 50 50 55 50 55 2 319 Average 838 41 40 38 40 38 40 52 44 Median 838 40 38 38 40 38 40 23 39 90% Line 838 42 41 39 41 39 41 81 41 95% Line 838 44 42 40 42 39 42 81 42 99% Line 838 61 112 42 43 54 43 81 81 Min 838 37 37 36 38 36 37 23 23 Max 838 70 112 42 44 54 56 81 838 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 2.38663 0.08199 0.08216 0.08215 0.082 0.08216 0.08201 0.02775 0.4664 Received KB/sec 0.03 0 0.01 0.01 0 0.01 0 0 0.03 Sent KB/sec 0 0.01 0 0 0.01 0 0.01 0 0.02

Gambar 4.11.Response Time Graphuntuk 10SubscriberdanPublisherpada Protokol MQTT Rata-rata response timeyang dicatat masing-masing sampler tidak jauh berbeda dibandingkan dengan pengujian sebelumnya.Sampler publish, MQTT Pub SD, PU, dan BD masing-masing menc-etak rata-rataresponse timesebesar 39ms, 38ms, dan 38ms. Sedangkan,sampler subscribe, MQTT Sub SD, PU, dan BD mencatatkan rata-rataresponse time39ms, 37ms, dan 38ms secara berurutan. Tidak banyak fluktuasi yang terjadi selama pengujian. Namun, fluktuasi lebih banyak terjadi diband-ingkan dengan percobaan sebelumnya. Hal ini dapat disebabkan oleh penambahanuseratau koneksi internet yang kurang steril. Salah satunya terjadi pada awal inisiasi pengujian. Hal ini kemungki-nan dapat dipengaruhi akibat inisiasi koneksi yang dilakukansamplerke broker yang mengakibatkan adanya peningkatan sementararesponse time. Keseluruhan agregat hasil pengujian dapat dilihat di tabel 4.6.

(46)

# Samples 40 1100 1000 1100 1000 1100 1000 40 6380 Average 516 39 39 38 37 38 38 19 41 Median 478 37 36 37 36 37 36 18 36 90% Line 872 41 39 40 39 41 39 21 40 95% Line 882 53 52 46 45 50 47 21 52 99% Line 892 96 110 91 89 86 84 47 109 Min 76 33 33 33 33 33 33 17 17 Max 892 282 114 109 111 114 115 47 892 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 44.79283 1.63716 1.64031 1.63717 1.6401 1.63699 1.6401 0.53879 9.31096 Received KB/sec 0.48 0.03 0.23 0.03 0.33 0.03 0.32 0.01 0.87 Sent KB/sec 0 0.23 0 0.32 0 0.32 0 0 0.85 4.4.3 Pengujian 100User

Pengujian dengan 100subscriberdanpublishermenunjukkan performa yang relatif sama dengan pengujian sebelumnya. Fluktuasi diawal pengujian relatif lebih kecil dibandingkan dengan pengu-jian sebelumnya. Hal in disebabkan adanyaramp-up timeselama 100s yang digunakan untuk untuk memastikan setiapdevice dapat terkoneksi dengan broker. Selain fluktuasi yang lebih kecil, ketiga samplerdari masing-masingpublisherdansubscribertidak jauh berbeda dibandingkan dengan pen-gujian sebelumnya. Grafikresponse timedapat dilihat pada gambar 4.12.

Gambar 4.12.Response Time Graphuntuk 100SubscriberdanPublisherpada Protokol MQTT Grafik 4.6 menunjukkan fluktuasi mayoritas terlihat lebih mencolok selama masaramp-up. Masa ini digunakan untuk memastikan keseluruhan 200samplerterhubung ke broker. Berdasarkan agregat pengujian pada tabel 4.7, rata-rataresponse timedi luar masaramp-uprealtif sama dengan pengujian sebelumnya. Padasampler publish, MQTT Pub SD, PU, dan BD memiliki rata-rata response time masing-masing 37ms. Sedangkan, rata-rataresponse timeuntuksampler subscribe, MQTT Sub SD, PU, dan BD adalah 37ms hingga 38ms.

(47)

# Samples 200 5500 5000 5500 5000 5500 5000 200 31900 Average 48 37 38 37 37 37 37 19 37 Median 39 36 36 36 36 36 36 19 36 90% Line 43 40 40 40 39 40 39 21 40 95% Line 47 42 46 42 41 42 41 22 42 99% Line 111 61 90 56 56 59 58 34 64 Min 34 31 32 31 31 31 31 16 16 Max 815 280 279 117 258 277 278 44 815 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 2.02276 7.15965 7.08203 7.15957 7.08118 7.1599 7.08143 1.17217 40.82468 Received KB/sec 0.02 0.14 0.98 0.14 1.4 0.14 1.38 0.01 3.82 Sent KB/sec 0 0.99 0 1.42 0 1.39 0 0 3.74 4.4.4 Pengujian 500User

Pada pengujian dengan menggunakan 500subscriberdanpublisher, terdapat fluktuasi yang lebih terlihat pada masa ramp-up time, sama dengan pengujian sebelumnya. Performa keseluruhan dari pengujian relatif sama dengan pengujian sebelumnya. Tidak ada perbedaan yang banyak antara sam-pler subscribedanpublish, sesuai dengan grafikresponse timepada gambar 4.13.

Gambar 4.13.Response Time Graphuntuk 500SubscriberdanPublisherpada Protokol MQTT Berdasarkan gambar 4.13 dan agregat pengujian pada tabel 4.8, pengujian dapat dijalankan den-gan baik. Pada awal pengujian terdapat fluktuasi akibat inisiasi yang dilakukan untuk koneksidevice ke broker selama masaramp-up. Rata-rata dari setiap sampler juga tidak terlalu berbeda diband-ingkan dengan pengujian sebelumnya. Sampler subscribe, MQTT Sub SD, PU, dan BD memiliki rata-rata 36ms. Sedangkan,sampler publishMQTT Pub SD, PU, dan BD mencatat rata-rata 37ms masing-masing. Berdasarkan data tersebut, pengujian untuk 500subscriberdanpublisherrelatif ber-jalan dengan baik.

(48)

Label MQTT Connect MQTT Pub SD MQTT Sub SD MQTT Pub PU MQTT Sub PU MQTT Pub BD MQTT Sub BD MQTT DisConnect TOTAL # Samples 2000 55000 50000 55000 50000 55000 50000 2000 319000 Average 44 37 36 37 36 37 36 19 36 Median 39 36 36 36 36 36 36 19 36 90% Line 43 40 39 40 39 40 39 20 40 95% Line 47 43 42 43 42 43 42 21 42 99% Line 71 54 55 54 54 53 53 30 54 Min 34 31 31 31 31 31 31 16 16 Max 920 313 316 319 318 298 302 68 920 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 20.08617 71.50751 69.52469 71.49719 69.52014 71.49375 69.5129 11.67863 407.625 Received KB/sec 0.22 1.4 9.64 1.4 13.78 1.4 13.51 0.13 38.12 Sent KB/sec 0 9.92 0 14.17 0 13.89 0 0 37.34

4.5 Pengujian Reliabilitas QoS Level 2 MQTT

Pengujian reliabilitas ini akan mengirimkan pesan yang identik dengan tes yang sudah dijalankan sebelumnya. Perbedaan tes ini terletak pada penggunaan QoS 0 hingga 2 untuk dengan batasan kapasitas tertentu untuk membandingkan reliabilitas antara QoS 0 hingga QoS 2.

4.5.1 Pengujian QoS 0 MQTT

Pengujian dengan QoS 0 menunjukkan ada beberapa pesan dari publisher yang tidak berhasil didapatkan olehsubscribermenggunakan QoS 0. Hasil pengujian dapat dilihat melalui tabel 4.9.

Tabel 4.9. Tabel Agregat Hasil Pengujian MQTT QoS 0

# Samples 20 500 491 500 491 500 491 11 3004 Average 351 0 20 0 19 0 20 22 12 Median 292 0 19 0 19 0 19 19 17 90% Line 685 1 21 1 21 1 21 22 20 95% Line 703 1 23 1 23 1 25 22 22 99% Line 704 24 57 1 41 1 67 43 57 Min 37 0 16 0 16 0 17 19 0 Max 704 27 104 1 74 1 127 43 704 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 23.39181 0.24115 0.23684 0.24115 0.23682 0.24114 0.23682 0.70427 1.41602 Received KB/sec 0.25 0 0.03 0 0.05 0 0.05 0.01 0.14 Sent KB/sec 0 0.03 0 0.05 0 0.05 0 0 0.13

Jumlah totaldissconnecthanya dilakukan oleh 11sampler. Sehingga, masih terdapat 9sampler subsriberyang belum menutup koneksinya. Pada QoS 0, latency daripublishertidak dapat direkam. karena tidak adanya pesan yang dikirimkan balik ke pengirim pesan pada QoS 0.

4.5.2 Pengujian QoS 1 MQTT

Pengujian dengan QoS 1 menunjukkan ada beberapa pesan dari publisher yang tidak berhasil didapatkan olehsubscriber menggunakan QoS 1. Seperti pengujian pada QoS 0, terdapat beberapa sampleryang tidak melakukandissconnect. Hasil pengujian dapat dilihat melalui tabel 4.10.

Pada pengujian ini, terdapat 8sampler subscriberyang tidak menyelesaikan iterasinya. Sehingga, hanya 12sampler, 10sampler publisherdan 2sampler subscriber, yang dapat menyelesaikan tugas-nya.

(49)

# Samples 20 500 492 500 492 500 492 12 3008 Average 374 19 19 20 22 20 19 21 22 Median 282 19 18 18 18 19 18 19 18 90% Line 672 21 20 21 21 21 20 21 21 95% Line 683 23 22 23 22 24 21 21 24 99% Line 684 43 31 57 238 64 60 43 80 Min 70 17 16 16 16 17 17 18 16 Max 684 60 76 293 465 309 245 43 684 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 19.92032 0.24081 0.237 0.24081 0.23699 0.24081 0.237 0.77121 1.41595 Received KB/sec 0.21 0 0.03 0 0.05 0 0.05 0.01 0.14 Sent KB/sec 0 0.03 0 0.05 0 0.05 0 0 0.13 4.5.3 Pengujian QoS 2 MQTT

Pengujian dengan QoS 2 menunjukkan seluruh pesan yang dikirimkan oleh publisher berhasil diterima olehsubscriber. Hasil pengujian dapat dilihat melalui tabel 4.11.

# Samples 20 500 500 500 500 500 500 20 3040 Average 332 51 52 40 40 53 53 22 50 Median 267 37 37 37 36 37 37 19 37 90% Line 664 40 39 40 39 40 40 31 40 95% Line 683 46 50 46 46 57 60 33 51 99% Line 684 107 115 108 258 494 494 45 268 Min 38 34 34 34 34 34 34 18 18 Max 684 4764 4763 267 266 2596 2596 45 4764 Error % 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% Throughput 23.39181 0.23966 0.23967 0.23966 0.23966 0.23966 0.23966 0.88992 1.42432 Received KB/sec 0.25 0 0.03 0 0.05 0 0.05 0.01 0.14 Sent KB/sec 0 0.03 0 0.05 0 0.05 0 0 0.12

Berdasarkan pengujian, seluruh pesan berhasil dikirimkan dengan menggunakan QoSlevel2. Hal ini ditandai dengan keseluruhansamplerberhasil melakukandissconnect terhadapbroker. Diband-ingkan dengan pengujian sebelumnya,latencymaksimal dan rata-rata yang dihasilkan QoS 2 relatif lebih besar dibandingkan dengan kedua tingkatan QoS sebelumnya. Sehingga, reliabilitas QoS mem-pengaruhi perolehanlatencydari protokol MQTT.

4.6 Perbandingan Performa Protokol HTTP dan MQTT

Berdasarkan pengujian di kedua protokol, dapat dilihat perbedaan performa antara protokol HTTP dan MQTT.

4.6.1 Rata-RataLatency

Response timeyang dicatat oleh Jmeter menunjukkan perbedaan performa antara kedua protokol. Perbedaan keduanya dapat dilihat pada gambar 4.14.

(50)

Gambar 4.14. Perbandingan Rata-Rata Response Time dari Kedua Protokol dengan Penambahan PublishdanSubscribeyang berbeda

Gambar 4.14 menunjukkan rata-rata response time yang dicatatkan oleh kedua protokol. Re-sponse time yang didapatkan tidak berbeda jauh denganlatency yang dicatatkan pada Jmeter. Se-hingga, response time akan digunakan sebagai latency dari kedua protokol. Berdasarkan gambar 4.14, protokol HTTP memiliki rata-rata latency yang lebih rendah dibandingkan dengan protokol MQTT saat pengujian menggunakan 1 dan 10 user. Hal ini dapat disebabkan oleh beberapa hal. Kapasitas server adalah salah satu hal yang dapat mempengaruhi perbedaan waktulatencytersebut. Pada API HTTP, Setiaprequestakan langsung melakukan proses yang ditetapkan oleh server. Se-hingga, apabila kapasitas server tidak dapat memenuhi permintaan tersebut, keberhasilanrequestdari HTTP akan berkurang denganlatencyyang lebih tinggi. Rendahnya latency pada protokol MQTT dapat disebabkan oleh sistempublishdansubscribe. Pada MQTT, koneksi antaradevicedengan bro-ker akan dibuat terlebih dahulu. Hinggadevicememerintahkan diskoneksi dengan broker atau akibat masalah lainnya, koneksi akan tetap dijaga. Sehingga, pengiriman pesan menjadi lebih efisien pada jangka waktu yang lama untuk pengiriman pesan terus menerus.

4.6.2 Rata-RataMessage Size

Berdasarkan besarmessage sizeyang dikirimkan dan diterima oleh kedua protokol, MQTT memi-liki keunggulan yang terlihat jelas dibandingkan dengan HTTP. Perbedaan besar pesan dari kedua protokol dapat dilihat pada gambar 4.15 dan gambar 4.16.

(51)

Gambar 4.15. Besar Pesan yang Dikirimkan HTTP

Gambar 4.16. Besar Pesan yang Dikirimkan MQTT

Pada kedua gambar tersebut, dapat dilihat adanya kolombytesdansent bytes. Kolombytes meru-pakan besar pesan yang didapatkan dari server. Sedangkansent bytesmerupakan besar pesan yang dikirimkan ke server. Berdasarkan kedua gambar tersebut, protokol MQTT memiliki besar pesan yang lebih kecil dibandingkan dengan HTTP. Pada protokol MQTT, koneksi dibangun di awal ko-munikasi antaraclientdengan broker. Setelah itu, kegiatanpublishdansubscribeakan mengirimkan pesan dengan besar pesan untuk mengirimkan pesan darideviceIoT ke server dengan kisaran sebesar 218 bytes untuk mengirimkan data tersebut. Pada protokol HTTP, setiap koneksi dari setiap koneksi memiliki besar pesan dengan kisaran 650 bytes.

(52)

(53)

BAB V

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Berdasarkan hasil pengujian kedua protokol, implementasi protokol MQTT pada sistem Neu-ronThings dapat memberikan performa yang lebih baik dibandingkan dengan protokol HTTP apa-bila memiliki jumlah device yang banyak. Koneksi MQTT relatif lebih fluktuatif di awal inisi-asi antarasubscriber danpublisher dengan broker. Apabila koneksi sudah terbangun antara subc-sriber/publisher dengan broker, pengiriman data relatif lebih stabil. Dibandingkan dengan MQTT, HTTP melakukan koneksi dengan server pada saatrequesttersebut dilakukan. Sehingga, semakin banyakrequestyang terjadi pada satu waktu dapat menyebabkanerrorpada beberaparequest terse-but. Khususnya pada request dengan proses database yang memerlukan waktu yang lebih lama dibandingkan denganrequestdata sederhana. MQTT memiliki keunggulan dalam perbedaanlatency apabiladeviceyang terlibat memiliki jumlah yang banyak dan melakukanupdatesecara berkala. Pada segimessage sizedari masing-masing protokol, MQTT memiliki rata-rata besar pesan yang lebih ke-cil hingga dua kali lipat dari protokol HTTP untuk mengirimkan data darideviceIoT ke server. Hasil ini sesuai dengan berbagai penelitian sebelumnya yang telah dilakukan untuk membandingkan kedua protokol.

5.2 Saran

Saran untuk penelitian ke depan meliputi beberapa hal. Pengujian yang dilakukan pada peneli-tian ini berfokus pada pengiriman data darideviceIoT ke server NeuronThings. Sehingga, peneli-tian untuk melihat performa MQTT yang diimplementasikan di aplikasi NeuronThings dapat men-jadi pengembangan selanjutnya. Aplikasi NeuronThings menggunakan berbagaiendpoint API dan Google Firebase untuk melakukan berbagai fungsi di aplikasi tersebut. Implementasi MQTT ke fungsi-fungsi tersebut dapat menjadi salah satu langkah untuk melihat apakah MQTT dapat diap-likasikan pada aplikasi tersebut beserta dengan perbandingan performa pengerjaan fungsi aplikasi terhadap performa sistem yang sudah ada.

Berbagai aspek lain dapat digunakan untuk memperdalam penelitian ini. Salah satunya adalah optimasi lebih lanjut pada struktur topik yang digunakan MQTT dan fungsi yang dilakukan HTTP. Hal ini dapat dilakukan untuk melihat apakah hasil yang lebih baik dapat dicapai oleh kedua protokol tersebut. Selain optimasi, masalah keamanan data juga dapat menjadi ekspansi penelitian berikutnya terkait performa dan keamanan kedua protokol di sistem NeuronThings.

(54)

(55)

LAMPIRAN A

NeuronThings

NeuronThings adalah sistem home automation yang dikembangkan di Universitas Pertamina. NeuronThings menggunakan perangkat Android untuk melakukan pengendalian ke alat rumah tangga yang terhubung dengan jaringan internet. Device IoT NeuronThings memiliki sekumpulan sensor yang tersambung dengandevice Raspberry Pi. Device ini akan mengirimkan data secara berkala melalui internet ke server utama yang akan mengolah data tersebut untuk pengendalian alat rumah tangga dan pengolahan data menggunakanmachine learninguntuk mendapatkan pola penggunaan alat rumah tangga.

Gambar A.1. Pengambilan Data di Sistem NeuronThings

Pada sistem NeuronThings, setiap data yang diambil darideviceIoT, dari data penggunaan alat elektronik, listrik, dan berbagai data lainnya, akan dikirim ke server NeuronThings. Pengiriman data tersebut menggunakanrequestPOST yang dinisiasi olehdeviceIoT ke server setiap 1 menit. Terdapat 3 kalirequestyang akan dilakukan olehdeviceIoT. Ketigarequesttersebut dapat dilihat pada tabel A.1.

Tabel A.1. Endpointyang digunakan untuk mengirim data di NeuronThings

Endpoint Kegunaan Metode

/api/sensor-data/blast Node API untuk memasukkanblast data ke tabel basis data berisi data sensor yang akan diperbarui setiap 1 menit

PUT /api/power-usage/blast Node API untuk memasukkanblast data ke tabel basis data

berisi penggunaan listrik yang digunakan per bulan dan tabel

datasetuntuk analisis penggunaan listrik. Setiap bulan, tabel per penggunaan per bulan akan dihapus dan digantikan den-gan data bulan baru.

POST

/api/behavior-dataset/blast Node API untuk memasukkanblast data ke tabel basis data berisi data sensor yang disimpan. Data tersebut digunakan untuk membangundataset machine learning.

POST

Setelah memasukkan data ke server untuk diolah dan disimpan, sistem NeuronThings juga melayani berbagairequestyang dapat diakses melalui aplikasimobileNeuronThings. Requestdiinisiasi oleh aplikasi yang akan mengirimkanrequestGET ke server. Berbagai data dapat dilihat dari aplikasi ini,

(56)

dimulai dari data penggunaan hingga data olahanmachine learningmengenai prediksi penggunaan listrik dan alat elektronik.

(57)

(58)

Form TA-2 Bimbingan Tugas Akhir