Sistem Monitoring Suhu dan Kelembaban Ruang Server Berbasis IoT Menggunakan Simulasi ESP32 dan Sensor DHT22 pada ThingsBoard Cloud

 LAPORAN PRAKTIKUM INTERNET OF THINGS

MENCOBA PLATFORM IoT CLOUD SIAP PAKAI DENGAN WOKWI

 

Studi Kasus:

Sistem Monitoring Suhu dan Kelembaban Ruang Server Berbasis IoT

Menggunakan Simulasi ESP32 dan Sensor DHT22 pada ThingsBoard Cloud

 

Disusun oleh:

Georvin Octianno                   24051204185

Ali Syava Ramadhan              24051204121

Ubaidillah Maulidul Ula         24051204115

Adie Tirta Satria                     24051204108

BAB I
PENDAHULUAN

1.1  Latar Belakang

Perkembangan Internet of Things (IoT) telah mendorong munculnya berbagai platform cloud yang berperan sebagai pusat pengumpulan, penyimpanan, dan pengolahan data dari perangkat di lapangan. Akan tetapi, kenyataan yang dihadapi di dunia IoT saat ini adalah bahwa hampir seluruh platform IoT cloud merupakan entitas komersial yang menarik bayaran kepada pemakainya. Fasilitas free trial memang disediakan, namun pada umumnya sangat dibatasi hanya pada fungsi-fungsi dasar, baik dari sisi jumlah perangkat, kuota pesan per bulan, jumlah datastream, maupun lamanya penyimpanan data historis.

Permasalahan kedua muncul dari sisi perangkat keras. Pembelajaran IoT secara konvensional menuntut ketersediaan mikrokontroler, sensor, kabel, dan perangkat pendukung lain yang tidak selalu terjangkau oleh setiap mahasiswa. Kendala teknis seperti driver USB yang tidak terdeteksi, sambungan kabel yang longgar, atau sensor yang rusak sering kali menghabiskan waktu praktikum yang seharusnya digunakan untuk memahami arsitektur sistem.

Praktikum ini menjawab kedua permasalahan tersebut dengan memanfaatkan ThingsBoard Cloud sebagai platform IoT dan Wokwi sebagai simulator perangkat keras berbasis web. ThingsBoard dipilih karena menawarkan tangga paket yang lebih landai dibandingkan kompetitornya, sekaligus menyediakan Community Edition yang sepenuhnya open source dan dapat dipasang sendiri tanpa biaya apabila masa paket cloud berakhir. Wokwi dipilih karena memungkinkan simulasi ESP32 beserta sensor DHT22 secara penuh di dalam peramban, lengkap dengan koneksi WiFi virtual, sehingga seluruh rantai komunikasi dapat diuji tanpa perangkat fisik.

Sebagai konteks penerapan, dipilih studi kasus pemantauan suhu dan kelembaban ruang server. Ruang server dipilih karena memiliki ambang batas operasional yang dapat dirujuk secara teknis dan memiliki konsekuensi yang jelas apabila dilanggar, yaitu perangkat mengalami panas berlebih, umur pakai memendek, hingga berhenti beroperasi. Studi kasus ini juga memberikan alasan yang kuat atas keberadaan mekanisme alarm dan notifikasi pada tahap lanjutan praktikum.

1.2  Rumusan Masalah

Berdasarkan latar belakang di atas, rumusan masalah yang diangkat dalam praktikum ini adalah sebagai berikut:

1. Bagaimana cara mendaftarkan dan mengonfigurasi sebuah perangkat IoT pada platform ThingsBoard Cloud dengan menggunakan kredensial MQTT Basic?

2. Bagaimana cara memverifikasi bahwa jalur komunikasi MQTT antara klien dan platform telah terbuka sebelum program pada perangkat ditulis?

3. Bagaimana memprogram ESP32 yang disimulasikan di Wokwi agar dapat membaca sensor DHT22 dan mengirimkan datanya secara berkala ke ThingsBoard Cloud?

4. Bagaimana membuktikan bahwa perubahan nilai pada sensor benar-benar tercermin pada data telemetry yang tersimpan di cloud?

5. Bagaimana menyajikan telemetry melalui dashboard dan mengolahnya menjadi alarm suhu ruang server?

6. Bagaimana mengirimkan peringatan kondisi kritis melalui webhook Discord ketika layanan email tidak dapat digunakan?

1.3  Tujuan Praktikum

Tujuan yang hendak dicapai melalui praktikum ini adalah:

1. Memahami karakteristik platform IoT cloud komersial beserta keterbatasan paket gratisnya, dan mampu membandingkan beberapa platform berdasarkan batasan tersebut.
2. Mampu mendaftarkan perangkat pada ThingsBoard Cloud serta membedakan dan memilih jenis kredensial yang sesuai di antara Access Token, X.509, dan MQTT Basic.
3. Memahami struktur protokol MQTT yang meliputi broker, port, topik, dan payload berformat JSON.
4. Mampu melakukan pengujian konektivitas secara berlapis, yaitu menguji jalur komunikasi dari PC terlebih dahulu sebelum menuliskan program pada perangkat.
5. Mampu membangun program pada ESP32 untuk tersambung ke jaringan WiFi dan broker MQTT, membaca sensor DHT22, serta menyusun data menjadi payload JSON.
6. Mampu memverifikasi bahwa data yang dikirim perangkat benar-benar diterima dan tersimpan sebagai telemetry di platform cloud.

 

BAB II
LANDASAN TEORI

2.1  Internet of Things

Internet of Things merupakan konsep yang menghubungkan objek-objek fisik ke jaringan internet sehingga objek tersebut mampu mengumpulkan dan bertukar data. Sebuah sistem IoT pada umumnya tersusun atas empat lapisan, yaitu lapisan perangkat yang berisi sensor dan aktuator, lapisan konektivitas yang menangani protokol komunikasi, lapisan platform yang menyimpan dan mengolah data, serta lapisan aplikasi yang menyajikan informasi kepada pengguna. Praktikum ini menerapkan keempat lapisan tersebut melalui pembacaan sensor, komunikasi MQTT, pemrosesan ThingsBoard, serta penyajian dashboard dan notifikasi Discord.

2.2  Platform IoT Cloud dan Permasalahannya

Kenyataan yang ada di dunia IoT saat ini adalah bahwa semua platform IoT merupakan entitas komersial yang akan menarik bayaran kepada pemakai. Fasilitas free trial tersedia, namun sangat dibatasi pada fungsi-fungsi dasar. Terdapat tiga alternatif solusi yang dapat ditempuh untuk mengatasi keterbatasan tersebut, yaitu:

1. Menginstal platform IoT open source pada premis atau server lokal berbasis PC, seperti OpenBalena, ThingsBoard, Node-RED, dan OpenRemote.
2. Menggabungkan beberapa layanan gratis dengan kemampuan pemrograman yang memadai, misalnya memanfaatkan Google Colab dengan bahasa Python.
3. Melakukan pemrograman penuh pada PC dengan berbagai bahasa pemrograman serta memanfaatkan gateway internet yang relatif murah, misalnya broker MQTT HiveMQ.

 

2.3  ThingsBoard Community Edition

ThingsBoard Community Edition merupakan versi yang 100% open source dan gratis, dengan keunggulan berupa jumlah perangkat dan aset yang tidak terbatas, pembaruan perangkat lunak tanpa batas, kesempatan untuk ikut berkontribusi, serta dukungan komunitas. Pilihan instalasinya meliputi Docker pada Linux atau macOS, Docker pada Windows, Ubuntu Server 20.04, 22.04, atau 24.04 dengan PostgreSQL atau Cassandra, server CentOS/RHEL (termasuk Alma, Rocky, dan Oracle Linux), Windows 10/11, serta Raspberry Pi dengan RAM minimal 4 GB untuk PostgreSQL atau 8 GB untuk Cassandra. Keberadaan versi ini memberikan jalan keluar apabila masa berlaku paket cloud berakhir di tengah pengerjaan proyek, dengan konsekuensi alamat broker berubah menjadi alamat server lokal.

2.4  Protokol MQTT

MQTT (Message Queuing Telemetry Transport) adalah protokol komunikasi ringan yang bekerja dengan pola publish dan subscribe. Terdapat tiga komponen utama dalam arsitekturnya, yaitu publisher yang mengirimkan pesan, subscriber yang menerima pesan, dan broker yang bertindak sebagai perantara. Pesan dikelompokkan berdasarkan topik, sehingga publisher dan subscriber tidak perlu saling mengenal secara langsung.

Pada ThingsBoard, alamat broker yang digunakan adalah mqtt.thingsboard.cloud dengan port 1883 untuk koneksi tanpa enkripsi. Topik baku untuk pengiriman data telemetry adalah v1/devices/me/telemetry. Kata me pada topik tersebut bukan placeholder yang perlu diganti dengan nama perangkat, melainkan menunjuk pada perangkat yang sedang terhubung saat itu. Identitas perangkat ditentukan oleh kredensial yang digunakan ketika melakukan koneksi, bukan oleh isi topik. Payload yang dikirimkan berformat JSON, misalnya {"suhu":50, "kelembaban":80}, dengan setiap kunci JSON menjadi satu key telemetry di platform.

Broker MQTT hanya mengizinkan satu koneksi aktif untuk setiap Client ID. Apabila klien kedua tersambung dengan Client ID yang sama, broker akan memutus klien pertama. Sifat ini menjadi penting ketika aplikasi pengujian di PC dan perangkat menggunakan kredensial yang sama.

2.5  Mikrokontroler ESP32

ESP32 adalah mikrokontroler produksi Espressif Systems yang dilengkapi modul WiFi dan Bluetooth terintegrasi. Kemampuan WiFi bawaan inilah yang menjadikan ESP32 banyak dipakai pada proyek IoT, karena perangkat dapat langsung terhubung ke jaringan tanpa modul tambahan. Dalam praktikum ini digunakan varian ESP32 DevKit yang merupakan papan pengembangan paling umum, dengan pustaka WiFi.h untuk koneksi jaringan dan PubSubClient untuk komunikasi MQTT.

2.6  Sensor DHT22

DHT22 merupakan sensor digital yang mampu mengukur suhu dan kelembaban relatif sekaligus. Di dalamnya terdapat dua elemen pengukur. Elemen pertama berupa termistor, yaitu resistor yang nilai hambatannya berubah mengikuti suhu. Elemen kedua berupa lapisan polimer di antara dua pelat, yang kapasitansinya berubah seiring banyaknya uap air yang terserap.

Kedua perubahan fisik tersebut dibaca oleh chip pengendali di dalam sensor, dikonversi menjadi nilai digital, lalu dikirimkan ke mikrokontroler sebagai deretan bit melalui satu jalur data tunggal. Pustaka DHT.h bertugas menerjemahkan deretan bit tersebut menjadi nilai suhu dalam derajat Celsius dan kelembaban dalam persen.

2.6  Wokwi sebagai Simulator Perangkat Keras

Wokwi adalah simulator rangkaian elektronika berbasis web yang mendukung berbagai mikrokontroler, termasuk ESP32. Wokwi menyediakan jaringan WiFi virtual dengan SSID Wokwi-GUEST tanpa kata sandi, sehingga program yang membutuhkan koneksi internet tetap dapat diuji. Nilai sensor dapat diatur secara manual melalui panel pengaturan yang muncul ketika komponen diklik saat simulasi berjalan, atau melalui atribut pada berkas diagram.json.

Hal penting yang perlu dipahami adalah bahwa dari sudut pandang program, simulasi dan perangkat nyata bersifat identik. Pemanggilan dht.readTemperature() tidak mengetahui dan tidak mempermasalahkan apakah nilai yang diterimanya berasal dari termistor sungguhan atau dari pengaturan di Wokwi. Inilah yang memungkinkan seluruh rantai sistem diuji tanpa membeli perangkat apa pun, dan apabila kelak dipasang pada perangkat keras nyata, baris program tidak perlu diubah selain nama dan kata sandi jaringan WiFi.

2.7  MQTTX sebagai Klien Uji MQTT

MQTTX adalah aplikasi klien MQTT lintas platform bersifat open source yang dikembangkan oleh EMQ. Aplikasi ini menyediakan antarmuka grafis untuk membuat koneksi ke broker, mempublikasikan pesan ke topik tertentu, dan berlangganan topik. Pada praktikum ini MQTTX menggantikan MQTT.fx yang digunakan pada modul, karena versi terbaru MQTT.fx telah berbayar, sedangkan fungsi yang dibutuhkan, yaitu mempublikasikan pesan uji ke broker ThingsBoard, tersedia sepenuhnya pada MQTTX.

BAB III
IMPLEMENTASI DAN PEMBAHASAN

3.1  Alat dan Bahan

Perangkat lunak, layanan, dan sumber daya yang digunakan dalam praktikum ini beserta perannya masing-masing disajikan pada Tabel 3.1.

Tabel 3.1 Alat dan bahan yang digunakan beserta perannya

Komponen	Jenis	Peran dalam sistem
Wokwi	Simulator berbasis web	Menggantikan ESP32 dan DHT22 fisik; tempat program ditulis, rangkaian disusun, dan simulasi dijalankan
ThingsBoard Cloud	Platform IoT cloud (paket Free)	Menerima, menyimpan, dan menampilkan data; berperan sebagai sisi server
MQTTX v1.13.1	Klien MQTT desktop (Windows x86-64)	Alat uji untuk memverifikasi jalur komunikasi sebelum program ditulis
ESP32 DevKit C v4	Mikrokontroler (simulasi)	Membaca sensor dan mengirim data melalui MQTT
DHT22	Sensor (simulasi)	Sumber nilai suhu dan kelembaban
Google Chrome	Peramban web	Antarmuka untuk mengakses Wokwi dan ThingsBoard
Akun Google	Akun pengguna	Registrasi dan masuk ke ThingsBoard Cloud serta Wokwi
Koneksi internet	Jaringan	Menghubungkan PC, simulator Wokwi, dan broker ThingsBoard
Discord dan webhook	Layanan pesan dan endpoint HTTP	Menerima peringatan suhu kritis pada channel teks

 

Perlu dicatat bahwa MQTTX bukan merupakan bagian dari sistem akhir. Perangkat lunak ini berperan sebagai alat diagnostik yang hanya digunakan pada tahap pengujian jalur komunikasi. Setelah ESP32 berjalan, MQTTX justru harus diputus agar tidak berebut Client ID dengan perangkat.

3.2  Arsitektur Sistem

Arsitektur sistem yang dibangun ditunjukkan pada Gambar 3.1. Sensor DHT22 membaca kondisi suhu dan kelembaban lingkungan, lalu mengirimkan hasilnya ke ESP32 melalui satu jalur data digital pada GPIO 15. ESP32 menyusun kedua nilai tersebut menjadi payload berformat JSON, kemudian mempublikasikannya melalui jaringan WiFi ke broker MQTT pada alamat mqtt.thingsboard.cloud port 1883 dengan topik v1/devices/me/telemetry. Broker meneruskan pesan tersebut ke ThingsBoard Cloud, yang mencocokkan kredensial pengirim dengan perangkat terdaftar lalu menyimpan isinya sebagai telemetry.

Gambar 3.1 Arsitektur sistem monitoring suhu dan kelembaban ruang server

Jalur bergaris putus dari PC dengan MQTTX menunjukkan jalur pengujian yang digunakan sebelum perangkat diprogram. Jalur ini menggunakan broker, topik, dan kredensial yang sama dengan perangkat. Data telemetry kemudian divisualisasikan melalui dashboard dan diproses oleh rule chain untuk menghasilkan alarm. Notifikasi dikembangkan melalui webhook Discord sebagai pengganti layanan email yang dinonaktifkan pada akun pengujian.

 

3.3  Perancangan Rangkaian

Sensor DHT22 memiliki empat kaki, namun hanya tiga di antaranya yang digunakan. Pemetaan sambungan antara sensor dan ESP32 disajikan pada Tabel 3.3.

Tabel 3.3 Pemetaan sambungan DHT22 ke ESP32 DevKit

Kaki DHT22	Pin ESP32	Keterangan
VCC	3V3	Sumber tegangan 3,3 volt (kabel merah)
SDA	15 (GPIO 15)	Jalur data digital satu kabel (kabel hijau)
NC	Tidak disambung	Not Connected, memang tidak digunakan
GND	GND	Jalur ground bersama (kabel hitam)

 

Nomor pin 15 yang dipilih harus konsisten dengan deklarasi #define DHTPIN 15 di dalam program. Penggunaan pin lain mengharuskan penyesuaian pada baris tersebut. Label D2 dan D3 pada papan ESP32 DevKit di Wokwi sengaja dihindari karena keduanya merujuk ke jalur data flash internal.

3.4  Penyesuaian terhadap Modul

Pelaksanaan praktikum mengikuti alur pada modul dengan beberapa penyesuaian. Seluruh penyesuaian beserta alasannya dirangkum pada Tabel 3.4.

Tabel 3.4 Penyesuaian pelaksanaan praktikum terhadap modul

Aspek	Modul	Praktikum ini	Alasan
Nama perangkat	Modul5_Test1	Praktikum_Modul5	Identitas proyek sendiri
Client ID	workshop_IOT_informatika	wokwi_praktikum_modul5	Kredensial MQTT Basic harus unik di seluruh server; nilai pada modul dipakai bersama oleh satu kelas
User Name	informatika	georvin	Sama dengan alasan di atas
Password	1234567890	praktikum123	Sama dengan alasan di atas
Klien MQTT di PC	MQTT.fx	MQTTX v1.13.1	Versi terbaru MQTT.fx berbayar; MQTTX gratis dengan fungsi setara
Paket ThingsBoard	Maker (masa uji coba)	Free	Paket yang diperoleh saat registrasi; tidak memiliki tanggal kedaluwarsa
Keluaran Serial Monitor	Temperature dan Humidity	Payload JSON yang dikirim	Memudahkan pencocokan antara data terkirim dan data tersimpan
Saluran notifikasi	Email melalui ThingsBoard	Webhook Discord melalui REST API call	Pengiriman email pada akun uji dinonaktifkan oleh batas API; fungsi peringatan dipertahankan melalui Discord

 

3.5  Langkah Kerja

Secara garis besar, langkah kerja meliputi persiapan sisi server pada ThingsBoard (3.5.1 dan 3.5.2), pengujian komunikasi dari PC menggunakan MQTTX (3.5.3 sampai 3.5.5), pembangunan dan pengujian perangkat pada Wokwi (3.5.6 sampai 3.5.12), kemudian penyajian dashboard, pemrosesan alarm, serta pengiriman notifikasi Discord (3.5.13 sampai 3.5.23).

3.5.1  Registrasi Akun ThingsBoard Cloud

1. Akses dan login ke alamat https://thingsboard.cloud.
2. Pastikan peran yang tertera di pojok kanan atas halaman Home adalah Tenant administrator, yaitu peran pemilik ruang kerja yang berhak membuat perangkat, dashboard, dan rule chain.
3. Periksa informasi langganan di pojok kanan atas. Pada akun yang digunakan tertera Current subscription: Free dengan Status: Active, seperti terlihat pada Gambar 3.2.

Gambar 3.2 Halaman Home ThingsBoard Cloud setelah berhasil masuk

4. Periksa kuota akun pada panel Usage di bagian bawah halaman. Paket Free memberikan batas 5 perangkat, 5 aset, 5 pengguna, 5 dashboard, dan 2 customer, dengan pemakaian awal 0 kecuali 1 pengguna, yaitu akun pemilik.

3.5.2  Membuat Perangkat dan Kredensial MQTT Basic

1. Pada menu di sisi kiri, klik Entities, lalu pilih Devices. Halaman daftar perangkat terbuka dan masih kosong.
2. Klik tombol + Add device di pojok kanan atas. Sebagai alternatif, tombol Add device pada panel Devices di halaman Home memiliki fungsi yang sama. Dialog Add new device muncul pada langkah pertama, yaitu Device details.
3. Isi formulir Device details sesuai Tabel 3.5. Tampilan formulir sebelum diisi ditunjukkan pada Gambar 3.3.

Gambar 3.3 Formulir Device details pada dialog Add new device

Tabel 3.5 Isian formulir Device details

Kolom	Isian	Keterangan
Name	Praktikum_Modul5	Wajib diisi; nama perangkat yang mudah dikenali
Label	Dikosongkan	Opsional
Device profile	default	Nilai bawaan, tidak diubah
Is gateway	Nonaktif	Perangkat ini bukan gateway
Owner	Terisi otomatis	Email akun pemilik, tidak diubah
Groups	Dikosongkan	Opsional
Description	Dikosongkan	Opsional

 

4. Klik tombol Next: Credentials. Jangan menekan tombol Add pada tahap ini.
5. Halaman Credentials terbuka dengan pilihan Credentials type. Secara bawaan, tab Access token terpilih dan sistem membangkitkan sebuah token acak (Gambar 3.4).

Gambar 3.4 Tab Access token terpilih secara bawaan beserta token acak

6. Tab X.509 meminta sertifikat dalam format PEM dan menampilkan pesan Certificate is required apabila kolomnya kosong (Gambar 3.5). Jenis kredensial ini tidak digunakan.

Gambar 3.5 Tab X.509 yang meminta sertifikat berformat PEM

7. Klik tab MQTT Basic. Tiga kolom isian muncul, yaitu Client ID, User Name, dan Password, disertai pesan merah Client ID and/or User Name are necessary (Gambar 3.6).

Gambar 3.6 Tab MQTT Basic sebelum diisi

8. Isi ketiga kolom sesuai Tabel 3.6. Ketik nilainya secara manual dan jangan menekan ikon panah melingkar di sisi kanan kolom, karena ikon tersebut membangkitkan nilai acak yang panjang dan sulit disalin ke dalam program.

Tabel 3.6 Isian kredensial MQTT Basic

Kolom	Isian	Keterangan
Client ID	wokwi_praktikum_modul5	Identitas klien MQTT
User Name	georvin	Nama pengguna MQTT
Password	praktikum123	Kata sandi MQTT

 

9. Pastikan pesan merah telah hilang. Klik ikon mata pada kolom Password untuk memeriksa kebenaran kata sandi yang diketik (Gambar 3.7).

Gambar 3.7 Kredensial MQTT Basic yang telah diisi

10. Catat ketiga nilai kredensial pada tempat yang aman. Nilai yang sama akan digunakan kembali pada konfigurasi MQTTX dan pada program ESP32.
11. Klik tombol Add. Perangkat dibuat dan dialog Device created. Let's check connectivity! muncul (Gambar 3.8). Dialog ini menampilkan petunjuk pengujian koneksi melalui baris perintah, yang terdiri atas:

a.      tab MQTT dengan pilihan sistem operasi Windows, MacOS, Linux, dan Docker, berisi langkah memasang mosquitto_pub dan contoh perintah pengiriman telemetry ke mqtt.thingsboard.cloud port 1883;

b.     tab CoAP yang berisi contoh perintah curl untuk Linux (Gambar 3.9);

c.      bagian State yang menunjukkan status Inactive dan tabel Latest telemetry yang masih kosong karena belum ada data yang dikirim.

Gambar 3.8 Dialog Device created. Let's check connectivity! pada tab MQTT

Gambar 3.9 Tab CoAP pada dialog pengecekan konektivitas

12. Biarkan opsi Do not show again dalam keadaan nonaktif, jangan menekan tombol Generate dashboard with AI, lalu klik Close.
13. Perangkat Praktikum_Modul5 muncul pada daftar dengan Device profile default dan State Inactive (Gambar 3.10). Status Inactive merupakan kondisi wajar karena perangkat belum pernah mengirimkan data.

Gambar 3.10 Perangkat Praktikum_Modul5 terdaftar dengan status Inactive

3.5.3  Mengunduh dan Memasang MQTTX

1. Buka alamat https://mqttx.app/downloads pada peramban. Pada bagian Desktop, klik x86-64 | v1.13.1.win64.exe untuk mengunduh installer Windows 64-bit (Gambar 3.11).

Gambar 3.11 Halaman unduhan MQTTX dengan pilihan versi Desktop dan CLI

2. Jalankan berkas installer yang telah diunduh dan ikuti petunjuk instalasi hingga selesai. Apabila Windows SmartScreen menampilkan peringatan, pilih More info, kemudian Run anyway. Lalu buka aplikasi MQTTX

Gambar 3.12 Tampilan awal MQTTX sebelum koneksi dibuat

3.5.4  Membuat Profil Koneksi MQTTX

1. Klik tombol + New Connection. Formulir pembuatan koneksi baru muncul. Lalu Isi bagian General sesuai Tabel 3.7. Kolom lain dibiarkan pada nilai bawaan.

Tabel 3.7 Isian profil koneksi MQTTX

Kolom	Isian	Keterangan
Name	ThingsBoard Praktikum	Label koneksi di dalam aplikasi (bebas)
Client ID	wokwi_praktikum_modul5	Hapus nilai acak bawaan, ganti dengan Client ID perangkat
Host	mqtt:// dan mqtt.thingsboard.cloud	Protokol dipilih pada menu tarik-turun di kiri kolom; nama domain ditulis tanpa http:// atau https://
Port	1883	Port MQTT tanpa enkripsi
Username	georvin	Sama dengan User Name perangkat
Password	praktikum123	Sama dengan Password perangkat
SSL/TLS	Nonaktif	Nilai bawaan
Clean Session	Aktif	Nilai bawaan
Keep Alive	60	Nilai bawaan dalam detik

 

2. Klik tombol Connect di pojok kanan atas formulir.
3. Koneksi berhasil ditandai dengan nama ThingsBoard Praktikum@mqtt... berwarna hijau pada daftar Connections dan ikon daya berwarna merah di pojok kanan atas, yang berfungsi sebagai tombol pemutus koneksi (Gambar 3.13). Area pesan masih kosong dan kotak payload berisi contoh bawaan {"msg": "hello"}.

Gambar 3.13 MQTTX berhasil terhubung ke broker ThingsBoard

3.5.5  Mengirim Data Uji dan Memverifikasi Telemetry

1. Pada bagian bawah panel pesan, pastikan format payload adalah JSON dan tingkat QoS adalah 0.
2. Klik kolom Topic, yaitu baris abu-abu bertuliskan Topic yang terletak tepat di atas kotak payload, lalu ketik v1/devices/me/telemetry.
3. Hapus isi bawaan kotak payload, lalu ketik {"suhu":50, "kelembaban":80}. Lalu pastikan topik dan payload berada pada kolom yang terpisah. Gambar 3.14 menunjukkan kesalahan penempatan, yaitu topik ikut tertulis di dalam kotak payload sementara kolom Topic masih menampilkan teks petunjuk berwarna abu-abu. Gambar 3.15 menunjukkan penempatan yang benar.

Gambar 3.14 Penempatan yang salah: topik tertulis di dalam kotak payload

Gambar 3.15 Penempatan yang benar: topik pada kolom Topic dan payload pada kotak payload

4. Klik ikon kirim berbentuk pesawat kertas berwarna hijau di pojok kanan bawah. Pesan yang terkirim muncul sebagai balon hijau bertuliskan Topic: v1/devices/me/telemetry QoS: 0 beserta isi payload dan penanda waktu 2026-10-09 15:02:40:907 (Gambar 3.16).

Gambar 3.16 Pesan uji berhasil dipublikasikan dari MQTTX

5. Kembali ke tab ThingsBoard pada halaman Devices. Kolom State mungkin masih menampilkan Inactive karena daftar perangkat tidak memperbarui dirinya secara otomatis (Gambar 3.17).

Gambar 3.17 Daftar perangkat sebelum diperbarui masih menunjukkan status Inactive

6. Klik ikon refresh berbentuk panah melingkar di sebelah kiri ikon kaca pembesar, atau tekan F5. Status perangkat berubah menjadi Active (Gambar 3.18).

Gambar 3.18 Status perangkat berubah menjadi Active setelah daftar diperbarui

7. Klik baris Praktikum_Modul5 untuk membuka panel Device details, lalu pilih tab Latest telemetry. Lalu amati isi tabel Telemetry. Terdapat dua key, yaitu kelembaban bernilai 80 dan suhu bernilai 50, dengan waktu pembaruan 2026-10-09 15:02:41 yang sesuai dengan waktu pengiriman dari MQTTX (Gambar 3.19). Hasil ini membuktikan bahwa kredensial, alamat broker, topik, dan format payload sudah benar.

Gambar 3.19 Data uji dari MQTTX tersimpan pada tab Latest telemetry

8. Setelah pengujian selesai, putuskan koneksi MQTTX dengan menekan ikon daya berwarna merah, atau tutup aplikasinya.

3.5.6  Membuat Proyek Wokwi

1. Buka alamat https://wokwi.com pada tab baru. Lalu setelah berhasil masuk kita diarahkan ke halaman your project(Gambar 3.20).

Gambar 3.20 Halaman Your Projects pada Wokwi setelah berhasil masuk

2. Klik tombol + NEW PROJECT. Halaman pemilihan papan pada alamat wokwi.com/projects/new menampilkan daftar papan berbasis ESP32 (Gambar 3.21). Klik papan ESP32

Gambar 3.21 Sebagian daftar papan pada halaman pembuatan proyek baru

3. Halaman Start a new project ESP32 muncul (Gambar 3.22). Pada bagian Beginner templates, klik ARDUINO.

Gambar 3.22 Pemilihan template Arduino untuk papan ESP32

4. Proyek baru terbuka pada alamat wokwi.com/projects/new/esp32. (Gambar 3.23).

Gambar 3.23 Proyek ESP32 baru dengan template Arduino

5. Klik tombol SAVE di pojok kiri atas, isi nama proyek Praktikum Modul 5 IoT ThingsBoard, lalu simpan. Setelah tersimpan, alamat pada address bar berubah menjadi wokwi.com/projects/477389906579101697 dan nama proyek tampil di sebelah tombol SHARE (lihat Gambar 3.24). Catat alamat tersebut sebagai tautan permanen proyek.

3.5.7  Menyusun Rangkaian ESP32 dan DHT22

Rangkaian dapat disusun melalui dua cara, yaitu secara grafis menggunakan tombol penambah komponen atau dengan menuliskan konfigurasi pada berkas diagram.json.

Cara 1: Melalui antarmuka grafis

1. Pada panel Simulation, klik tombol + berwarna biru di bagian atas. Lalu pilih komponen DHT22. Sensor muncul pada kanvas (Gambar 3.24).

Gambar 3.24 Sensor DHT22 ditambahkan ke kanvas simulasi

2. Buat tiga sambungan berikut:

a.      kaki VCC ke pin 3V3;

b.     kaki GND ke pin GND;

c.      kaki SDA ke pin 15.

Gambar 3.25 Rangkaian DHT22 dan ESP32 yang disambungkan secara grafis

Cara 2: Melalui berkas diagram.json

1. Klik tab diagram.json, pilih seluruh isi berkas dengan Ctrl+A, lalu hapus dengan tombol Delete. Setelahnya ketik atau tempel konfigurasi pada Kode 3.1.

Kode 3.1 Isi berkas diagram.json

{   "version": 1,   "author": "Georvin",   "editor": "wokwi",   "parts": [     { "type": "board-esp32-devkit-c-v4", "id": "esp",       "top": 0, "left": 0, "attrs": {} },     { "type": "wokwi-dht22", "id": "dht1",       "top": -100, "left": 150, "attrs": {} }   ],   "connections": [     [ "dht1:VCC", "esp:3V3",   "red",   [ "v0" ] ],     [ "dht1:GND", "esp:GND.1", "black", [ "v0" ] ],     [ "dht1:SDA", "esp:15",    "green", [ "v0" ] ],     [ "esp:TX", "$serialMonitor:RX", "", [] ],     [ "esp:RX", "$serialMonitor:TX", "", [] ]   ],   "dependencies": {} }

Gambar 3.26 Rangkaian yang terbentuk dari konfigurasi diagram.json

Keterangan: bagian parts mendefinisikan komponen beserta posisinya pada kanvas, sedangkan bagian connections mendefinisikan kabel dalam format pin asal, pin tujuan, warna, dan jalur kabel. Dua sambungan terakhir menghubungkan TX dan RX ESP32 ke Serial Monitor. ESP32 DevKit memiliki beberapa pin GND (GND.1, GND.2, dan seterusnya) yang secara kelistrikan terhubung pada jalur ground yang sama, sehingga pemilihan GND.1 hanya berpengaruh pada kerapian gambar kabel.

3.5.8  Mendaftarkan Pustaka Program

Program membutuhkan tiga pustaka eksternal, yaitu DHT sensor library dari Adafruit untuk membaca sensor, Adafruit Unified Sensor sebagai dependensinya, dan PubSubClient dari Nick O'Leary untuk komunikasi MQTT.

1. Klik tanda panah ke bawah (▼) di sebelah kanan tab Library Manager, pilih opsi untuk membuat berkas baru, lalu beri nama libraries.txt. Setelahnya isi berkas tersebut dengan tiga baris pada Kode 3.2.

Kode 3.2 Isi berkas libraries.txt

DHT sensor library Adafruit Unified Sensor PubSubClient

 

2. Save tab libraries.txt muncul di antara tab diagram.json dan Library Manager (Gambar 3.29).

Gambar 3.29 Berkas libraries.txt berisi daftar pustaka yang dibutuhkan

3.5.9  Menulis Program pada sketch.ino

1. Klik tab sketch.ino. Lalu ketik atau tempel kode program pada Kode 3.3.

Kode 3.3 Kode program sketch.ino

1  #include <WiFi.h>  2  #include <PubSubClient.h>  3  #include "DHT.h"  4    5  #define DHTPIN 15  6  #define DHTTYPE DHT22  7    8  const char* ssid        = "Wokwi-GUEST";  9  const char* password    = ""; 10   11  const char* mqtt_server = "mqtt.thingsboard.cloud"; 12  const char* mqtt_clid   = "wokwi_praktikum_modul5"; 13  const char* mqtt_user   = "georvin"; 14  const char* mqtt_pass   = "praktikum123"; 15  const char* mqtt_topic  = "v1/devices/me/telemetry"; 16   17  WiFiClient espClient; 18  PubSubClient client(espClient); 19  DHT dht(DHTPIN, DHTTYPE); 20  unsigned long lastMsg = 0; 21   22  void setup_wifi() { 23    delay(10); 24    Serial.println(); 25    Serial.print("Connecting to "); 26    Serial.println(ssid); 27   28    WiFi.mode(WIFI_STA); 29    WiFi.begin(ssid, password, 6); 30   31    while (WiFi.status() != WL_CONNECTED) { 32      delay(500); 33      Serial.print("."); 34    } 35   36    Serial.println(""); 37    Serial.println("WiFi connected"); 38    Serial.print("IP address: "); 39    Serial.println(WiFi.localIP()); 40  } 41   42  void reconnect() { 43    while (!client.connected()) { 44      Serial.print("Attempting MQTT connection..."); 45      if (client.connect(mqtt_clid, mqtt_user, mqtt_pass)) { 46        Serial.println("Thingsboard is Connected !!"); 47      } else { 48        Serial.print("failed, rc="); 49        Serial.print(client.state()); 50        Serial.println(" try again in 5 seconds"); 51        delay(5000); 52      } 53    } 54  } 55   56  void setup() { 57    Serial.begin(115200); 58    dht.begin(); 59    setup_wifi(); 60    client.setServer(mqtt_server, 1883); 61  } 62   63  void loop() { 64    if (!client.connected()) { 65      reconnect(); 66    } 67    client.loop(); 68   69    unsigned long now = millis(); 70    if (now - lastMsg > 5000) { 71      lastMsg = now; 72   73      float suhu = dht.readTemperature(); 74      float kelembaban = dht.readHumidity(); 75   76      if (isnan(suhu) || isnan(kelembaban)) { 77        Serial.println("Gagal membaca sensor DHT!"); 78        return; 79      } 80   81      char payload[64]; 82      snprintf(payload, sizeof(payload), 83               "{\"suhu\":%.1f,\"kelembaban\":%.1f}", suhu, kelembaban); 84   85      Serial.print("Kirim: "); 86      Serial.println(payload); 87      client.publish(mqtt_topic, payload); 88    } 89  }

Fungsi setiap bagian program dijelaskan pada Tabel 3.8.

Tabel 3.8 Penjelasan bagian-bagian program sketch.ino

Baris	Bagian	Fungsi
1–3	Pustaka	Memuat pustaka WiFi untuk koneksi jaringan, PubSubClient untuk komunikasi MQTT, dan DHT untuk membaca sensor
5–6	Konstanta sensor	Menetapkan pin data sensor pada GPIO 15 dan tipe sensor DHT22
8–9	Konfigurasi WiFi	SSID jaringan virtual Wokwi-GUEST dengan kata sandi kosong
11–15	Konfigurasi MQTT	Alamat broker, Client ID, username, password, dan topik telemetry
17–20	Objek global	Klien TCP, klien MQTT, objek sensor, dan variabel penanda waktu pengiriman terakhir
22–40	setup_wifi()	Mengaktifkan mode station, menyambung ke Wokwi-GUEST pada kanal 6, menunggu hingga terhubung, lalu mencetak alamat IP
42–54	reconnect()	Mencoba koneksi ke broker dengan kredensial MQTT Basic; apabila gagal, mencetak kode status (rc) dan mencoba lagi setiap 5 detik
56–61	setup()	Memulai komunikasi serial 115200 baud, menginisialisasi sensor, menyambung WiFi, dan menetapkan alamat broker port 1883
63–67	loop(): koneksi	Menyambung ulang apabila koneksi MQTT terputus dan menjalankan client.loop() untuk menjaga sesi tetap hidup
69–71	loop(): pewaktu	Menjalankan pengiriman setiap 5000 milidetik menggunakan millis() tanpa menghentikan program
73–79	loop(): pembacaan	Membaca suhu dan kelembaban; apabila hasilnya bukan angka (nan), pengiriman pada putaran tersebut dilewati
81–83	loop(): payload	Menyusun payload JSON dengan key suhu dan kelembaban, masing-masing satu angka di belakang koma
85–87	loop(): pengiriman	Mencetak payload ke Serial Monitor dan mempublikasikannya ke topik telemetry

3.5.10  Menjalankan Simulasi

1. Pastikan koneksi MQTTX telah diputus. Lalu klik tombol play berwarna hijau di bagian atas panel Simulation.
2. Setelah kompilasi berhasil, simulasi berjalan. Tombol play berubah menjadi tombol restart, stop, dan pause, sedangkan pewaktu simulasi muncul di pojok kanan atas panel. Keluaran yang diperoleh pada simulasi pertama ditunjukkan pada Kode 3.4.

Kode 3.4 Keluaran Serial Monitor pada simulasi pertama

ets Jul 29 2019 12:21:46   rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:1156 load:0x40078000,len:11456 ho 0 tail 12 room 4 load:0x40080400,len:2972 entry 0x400805dc   Connecting to Wokwi-GUEST .... WiFi connected IP address: 10.10.0.2 Attempting MQTT connection...Thingsboard is Connected !! Kirim: {"suhu":24.0,"kelembaban":40.0} Attempting MQTT connection...Thingsboard is Connected !!

Tabel 3.9 Arti baris keluaran Serial Monitor

Keluaran	Arti
ets Jul 29 2019 hingga entry 0x400805dc	Pesan boot bawaan ROM ESP32 saat dinyalakan (POWERON_RESET)
Connecting to Wokwi-GUEST	Fungsi setup_wifi() mulai menyambung ke jaringan virtual
....	Setiap titik menandakan 500 milidetik menunggu koneksi WiFi
WiFi connected dan IP address: 10.10.0.2	ESP32 berhasil terhubung ke WiFi dan memperoleh alamat IP
Attempting MQTT connection...Thingsboard is Connected !!	Autentikasi MQTT Basic ke broker ThingsBoard berhasil
Kirim: {"suhu":24.0,"kelembaban":40.0}	Payload JSON dipublikasikan ke topik telemetry, berulang setiap 5 detik

 

Gambar 3.31 Simulasi berjalan dengan Serial Monitor menampilkan pengiriman data

3.5.11  Memverifikasi Data Simulasi di ThingsBoard

1. Biarkan simulasi Wokwi tetap berjalan. Pindah ke tab ThingsBoard, buka Entities, pilih Devices, lalu klik baris Praktikum_Modul5. Setelahnya pilih tab Latest telemetry pada panel Device details.
2. Amati bahwa nilai kelembaban berubah dari 80 menjadi 40.0 dan nilai suhu berubah dari 50 menjadi 24.0, dengan waktu pembaruan 2026-10-09 15:29:24 (Gambar 3.32).

Gambar 3.32 Telemetry berubah menjadi nilai yang dikirim dari simulasi Wokwi

3.5.12  Menguji Perubahan Nilai Sensor

1. Pastikan simulasi sedang berjalan, ditandai dengan pewaktu simulasi yang terus bertambah. Klik badan sensor DHT22 pada kanvas, panel Editing DHT22 muncul di bagian atas kanvas dengan dua penggeser, yaitu Temperature bernilai 24.0°C dan Humidity bernilai 40.0% (Gambar 3.33).

Gambar 3.33 Panel pengaturan DHT22 dengan nilai bawaan

2. Geser penggeser Temperature ke kanan hingga menunjukkan 36.8°C (Gambar 3.34).

Gambar 3.34 Nilai suhu diubah menjadi 36,8 °C dan terkirim melalui Serial Monitor

3. Buka tab ThingsBoard dan periksa Latest telemetry. Nilai suhu berubah menjadi 36.8 dengan waktu pembaruan 2026-10-09 16:01:40 (Gambar 3.35).

Gambar 3.35 Nilai suhu 36,8 °C tercermin pada telemetry ThingsBoard

Keterangan: dalam konteks studi kasus ruang server, nilai 36,8 °C berada di atas ambang 35 °C sehingga tergolong kondisi critical sesuai Tabel 3.2. Penggeser yang sama digunakan untuk memicu tingkat kondisi pada pengujian alarm dan notifikasi Discord. Selain melalui penggeser, nilai awal sensor dapat ditetapkan melalui atribut pada diagram.json, misalnya "attrs": { "temperature": "36", "humidity": "75" }, sehingga simulasi langsung dimulai dengan nilai tersebut.

3.5.13  Membuat Dashboard Suhu dan Kelembaban

Setelah perubahan sensor terbukti tercermin pada Latest telemetry, data disajikan pada dashboard agar kondisi ruang server dapat dipantau tanpa membuka rincian perangkat satu per satu. Sumber data tetap menggunakan perangkat Praktikum_Modul5 yang telah dibuat sebelumnya.

1. Buka ThingsBoard, pilih Monitor, kemudian Dashboards. Klik + Add dashboard, isi Title dengan Dashboard Suhu Ruang Server, dan klik Add. Kolom lain dibiarkan pada nilai bawaan.

Gambar 3.36 Formulir pembuatan Dashboard Suhu Ruang Server

2. Buka dashboard tersebut. Jika tombol Save dan Cancel belum terlihat, klik ikon pensil untuk masuk ke mode edit. Tombol Add widget muncul pada bagian atas kanvas.

Gambar 3.37 Dashboard kosong dalam mode edit

3. Klik Add widget, ketik thermometer pada pencarian, buka bundle Analogue gauges, lalu pilih Thermometer scale.

Gambar 3.38 Pemilihan widget Thermometer scale pada bundle Analogue gauges

4. Pada mode Basic, pilih Datasource berupa Device dan tentukan Praktikum_Modul5. Hapus key bawaan temperature, lalu pilih key suhu. Jika key belum muncul, jalankan Wokwi hingga satu payload diterima ThingsBoard.

Gambar 3.39 Pengaturan datasource termometer sebelum key temperature diganti menjadi suhu

5. Pada Gauge appearance, ubah Units title menjadi Suhu dan Units menjadi °C. Aktifkan penampilan nilai, biarkan digits bernilai 3, lalu atur Ticks min menjadi 0 dan max menjadi 60. Pengaturan warna dan tampilan lainnya dibiarkan seperti bawaan. Klik Add.

Gambar 3.40 Pengaturan tampilan termometer sebelum skala bawaan disesuaikan

6. Klik Add widget kembali, buka bundle Charts, lalu pilih Line chart untuk menampilkan perubahan kelembaban terhadap waktu.

Gambar 3.41 Pilihan Line chart pada bundle Charts

7. Pilih Device Praktikum_Modul5. Pada bagian Series, gunakan Key kelembaban, Label Kelembapan, Units %, serta Decimals 0. Y axis dan Color dibiarkan pada nilai bawaan. Klik Add.

Gambar 3.42 Konfigurasi Line chart menggunakan key kelembaban

8. Atur posisi kedua widget, kemudian klik Save. Biarkan Wokwi berjalan dan periksa pembaruan nilai. Grafik dapat diperbesar dengan ikon layar penuh untuk melihat waktu dan nilai setiap titik data.

Gambar 3.43 Grafik kelembaban menampilkan nilai 40% beserta waktu penerimaan data

Key suhu dan kelembaban harus sama dengan key pada payload ESP32. Label tampilan Kelembapan hanya mengubah judul yang dilihat pengguna dan tidak mengganti key telemetry di dalam sistem.

3.5.14  Membuat Rule Chain dan Menguji Klasifikasi Suhu

1. Buka Data processing, pilih Rule chains, kemudian klik + Add rule chain dan Create new rule chain. Isi Name dengan Wokwi_DHT_Alarm dan klik Add. Root Rule Chain yang sudah ada tidak dihapus atau dijadikan ulang.

Gambar 3.44 Menu pembuatan rule chain baru

2. Buka Wokwi_DHT_Alarm. Dari kategori Filter, tarik node switch ke kanvas dan beri nama setAlarm. Pilih bahasa TBEL, hapus contoh script, kemudian masukkan Kode 3.5.

Kode 3.5 Script klasifikasi suhu ruang server pada node setAlarm

 1  if (msg.suhu > 27 && msg.suhu <= 30) {

 2      return ['minor'];

 3  } else if (msg.suhu > 30 && msg.suhu <= 35) {

 4      return ['major'];

 5  } else if (msg.suhu > 35) {

 6      return ['critical'];

 7  } else {

 8      return ['normal'];

 9  }

 

Gambar 3.45 Jendela pengaturan node switch sebelum script bawaan diganti

Batas 27 °C, 30 °C, dan 35 °C mengikuti rancangan ambang suhu ruang server. Dengan demikian, nilai 36,8 °C yang sebelumnya hanya diverifikasi pada telemetry kini diproses sebagai kondisi critical. Script ini digunakan pada jalur Post telemetry yang membawa nilai suhu sensor.

3. Aktifkan debug sementara melalui tombol Disabled, lalu pilih All messages agar pesan dapat ditelusuri pada Events. Tulisan Disabled menunjukkan status debug, bukan berarti node tidak berfungsi.
4. Klik Test switch function, pilih Message type Post telemetry, lalu masukkan payload pada Kode 3.6. Metadata dibiarkan seperti bawaan.

Kode 3.6 Payload uji fungsi switch

 1  {

 2      "suhu": 36.8,

 3      "kelembaban": 40

 4  }

 

Gambar 3.46 Payload suhu 36,8 °C pada jendela pengujian fungsi switch

5. Klik Test. Output yang diperoleh adalah ["critical"], karena suhu berada di atas 35 °C. Simpan hasil pengaturan dan klik Add untuk menempatkan node pada kanvas.

Gambar 3.47 Hasil pengujian switch menghasilkan jalur critical

6. Tarik koneksi dari titik kanan Input ke titik kiri setAlarm. Koneksi dari Input tidak memerlukan label. Simpan rule chain dengan tombol centang di pojok kanan bawah.

3.5.15  Membentuk Alarm dan Membersihkan Kondisi Normal

1. Pada kategori Action, tambahkan node create alarm dan beri nama create alarm critical. Biarkan Use message alarm data tidak dicentang dan Details script seperti bawaan. Isi Alarm type dengan Suhu Ruang Server, lalu gulir ke bawah dan pilih Severity Critical. Propagate dibiarkan nonaktif.

Gambar 3.48 Konfigurasi node create alarm dengan tipe Suhu Ruang Server

2. Tambahkan node create alarm untuk jalur minor dan major dengan cara yang sama. Pilih Severity Minor dan Major sesuai masing-masing jalur, tetapi gunakan Alarm type yang sama persis, yaitu Suhu Ruang Server.
3. Tambahkan node clear alarm dengan nama clear alarm normal. Isi Alarm type dengan Suhu Ruang Server dan biarkan Details script seperti bawaan. Tipe yang sama diperlukan agar alarm aktif pada perangkat dapat dibersihkan.
4. Tarik keluaran setAlarm ke create alarm critical. Pada Add link, ketik critical dan pastikan teks telah menjadi chip label sebelum menekan Add. Jika tombol Add masih abu-abu, tekan Esc lalu Enter sebagaimana pada pengujian antarmuka ini.

Gambar 3.49 Label critical masih berupa teks sehingga tombol Add belum aktif

Gambar 3.50 Label critical telah menjadi chip sehingga sambungan dapat disimpan

5. Ulangi sambungan setAlarm ke node minor menggunakan label minor, ke node major menggunakan label major, dan ke clear alarm menggunakan label normal. Semua label ditulis dengan huruf kecil sesuai hasil return pada script.
6. Klik centang untuk menyimpan rule chain. Aktifkan All messages hanya selama pemeriksaan, kemudian nonaktifkan setelah fungsi terverifikasi.

Ketiga node create alarm menggunakan tipe yang sama agar perubahan severity mengacu pada alarm suhu perangkat yang sama. Jalur normal tidak membuat alarm baru, melainkan menandai kondisi aktif sebagai selesai. Tampilan riwayat alarm tetap dipertahankan untuk keperluan evaluasi.

3.5.16  Menghubungkan Pemrosesan Alarm ke Root Rule Chain

Wokwi_DHT_Alarm belum menerima data hanya karena sudah dibuat. Data telemetry perlu diteruskan dari jalur penerimaan yang sudah berjalan. Pada implementasi ini, pengolahan alarm ditempatkan setelah penyimpanan time series agar dashboard tetap memperoleh data.

1. Kembali ke daftar Rule chains dan buka Root Rule Chain. Jangan menghapus atau mengubah node bawaan yang sudah menerima dan menyimpan telemetry.

Gambar 3.51 Root Rule Chain dengan penambahan node penghubung ke pemrosesan alarm

2. Dari kategori Flow, tarik node rule chain ke sebelah kanan Save Timeseries. Isi Name dengan ke alarm, biarkan Forward message to the originator’s default rule chain nonaktif, lalu pilih Wokwi_DHT_Alarm pada kolom Rule chain.

Gambar 3.52 Node ke alarm diarahkan ke Wokwi_DHT_Alarm

3. Hubungkan keluaran Save Timeseries ke masukan ke alarm dengan label Success. Klik Add pada dialog koneksi, lalu simpan Root Rule Chain dengan tombol centang.

Gambar 3.53 Jalur Success dari Save Timeseries menuju node ke alarm

Urutannya menjadi penerimaan telemetry, penyimpanan time series, lalu pemrosesan alarm. Susunan ini tidak memindahkan Root ke chain baru dan tidak memutus jalur penyimpanan yang telah digunakan dashboard.

3.5.17  Menguji Alarm dari Perubahan Sensor

1. Jalankan Wokwi dan tunggu sampai muncul WiFi connected serta Thingsboard is Connected !!. Klik sensor DHT22 dan naikkan Temperature menjadi 38 °C; kelembaban pada contoh dibiarkan 40%.

Gambar 3.54 Pengujian simulasi Wokwi pada suhu 38 °C

2. Periksa Serial Monitor. Payload terbaru harus memuat suhu 38.0 dan kelembaban 40.0. Tunggu satu atau beberapa siklus pengiriman agar data diterima dan diproses di ThingsBoard.

Gambar 3.55 Serial Monitor menampilkan pengiriman suhu 38 °C dan kelembaban 40%

3. Buka Monitor, lalu Alarms. Alarm berasal dari Praktikum_Modul5, bertipe Suhu Ruang Server, dengan Severity Critical dan status Active Unacknowledged. Untuk jalur lain, gunakan suhu di atas 27–30 °C untuk minor serta di atas 30–35 °C untuk major.

Gambar 3.56 Daftar alarm suhu menampilkan kejadian Critical dan Major

4. Turunkan suhu ke 27 °C atau lebih rendah untuk menguji jalur normal. Periksa bahwa alarm aktif berubah menjadi Cleared. Status Cleared Unacknowledged berarti kondisi telah selesai, tetapi pengguna belum mengakui riwayat alarm tersebut.

Jika alarm tidak muncul, periksa penyimpanan kedua rule chain, koneksi Success dari Save Timeseries, Alarm type, serta kecocokan label keluaran. Pengujian fungsi switch saja tidak membuat alarm karena belum menjalankan seluruh jalur data dari perangkat.

3.5.18  Menambahkan Tabel Alarm pada Dashboard

1. Buka Dashboard Suhu Ruang Server, masuk ke mode edit, kemudian klik Add widget. Cari alarm, buka bundle Alarm widgets, dan pilih Alarms table.
2. Pada Time window, pilih Use widget time window. Biarkan Display time window aktif dengan rentang Realtime - last 30 days. Pada Alarm source pilih Device dan tentukan Praktikum_Modul5.

Gambar 3.57 Pengaturan widget Alarms table dengan sumber perangkat Praktikum_Modul5

3. Untuk pemeriksaan awal, biarkan filter status, severity, dan tipe pada nilai bawaan agar alarm aktif maupun riwayat tidak tersembunyi. Klik Add, letakkan tabel di bawah widget sensor, kemudian klik Save.

Dashboard kini menyatukan kondisi terkini melalui termometer, riwayat kelembaban melalui grafik, dan kejadian abnormal melalui tabel alarm. Ketiganya memakai sumber perangkat yang sama sehingga informasi sensor dan status alarm dapat dibaca dalam satu tampilan.

3.5.19  Memeriksa Layanan Notifikasi dan Menentukan Saluran Alternatif

Pengiriman notifikasi semula diuji melalui node to email dan send email seperti pada modul. Pada pengujian tersebut, pesan berhasil terbentuk dengan nama perangkat dan nilai kelembaban, tetapi node pengirim menolak pengiriman dengan pesan Email sending is disabled due to API limits!. Halaman Platform → API usage menampilkan Emails 0 / -1 dengan status Disabled. Kondisi ini dicatat sebagai pembatasan layanan pada akun pengujian; angka tersebut tidak digunakan untuk menyimpulkan bahwa kuota telah habis atau berlaku untuk seluruh akun Free.

Agar fungsi peringatan tetap dapat digunakan, saluran notifikasi diganti dengan webhook Discord. Pemicu operasional mengikuti kondisi critical pada rancangan suhu ruang server, yaitu suhu di atas 35 °C. Dengan demikian, penggantian tidak hanya memindahkan tujuan pesan email kelembaban, tetapi menyelaraskan notifikasi akhir dengan alarm suhu yang telah dibentuk.

1. Putuskan atau hentikan jalur email yang gagal agar tidak terus dipanggil selama pengujian. Pertahankan jalur penyimpanan telemetry dan node-node alarm suhu.
2. Gunakan keluaran critical dari setAlarm sebagai sumber pesan Discord. Jalur critical tetap dihubungkan ke create alarm critical dan ditambah satu sambungan lain menuju penyusun pesan Discord.

Percabangan dibuat pada keluaran switch, bukan langsung dari Input. Input menunjuk ke satu node awal; satu keluaran switch dapat meneruskan pesan ke beberapa node dengan label yang sama. Karena itu, jalur pembentukan alarm tidak perlu diputus ketika jalur Discord ditambahkan.

3.5.20  Menyiapkan Channel dan Webhook Discord

1. Buka Discord dan masuk ke akun kelompok. Buat server jika belum tersedia melalui tombol tambah dan Create My Own. Pada dokumentasi ini digunakan server Praktikum IoT dan channel teks #general.
2. Buka menu nama server, pilih Server Settings, kemudian Integrations dan Webhooks. Klik New Webhook, beri nama ThingsBoard Alarm, dan pilih channel #general.

Gambar 3.58 Pengaturan webhook ThingsBoard Alarm pada Discord

3. Klik Copy Webhook URL dan simpan alamat tersebut sementara untuk konfigurasi node pengirim. Jangan menampilkan URL lengkap atau token webhook pada laporan, tangkapan layar, maupun tempat publik.

Webhook bertindak sebagai pintu masuk pesan ke channel tanpa login interaktif pada setiap pengiriman. Hak akses untuk membuat webhook diperlukan pada server tersebut. Jika URL bocor, webhook perlu dihapus atau dibuat ulang agar token lama tidak dapat disalahgunakan.

3.5.21  Menyusun Payload Notifikasi Discord

1. Buka kembali Wokwi_DHT_Alarm. Dari kategori Transformation, tarik node script dan beri nama susun pesan discord. Pilih JavaScript, lalu ganti script bawaan dengan Kode 3.7.

Kode 3.7 Script penyusun pesan Discord

 1  var text = "PERINGATAN SUHU RUANG SERVER\n" +

 2             "Device : " + metadata.deviceName + "\n" +

 3             "Suhu : " + msg.suhu + " derajat Celsius\n" +

 4             "Kelembaban : " + msg.kelembaban + " persen\n" +

 5             "Status : CRITICAL, di atas ambang 35 derajat";

 6  

 7  var newMsg = {};

 8  newMsg.content = text;

 9  

10  return {msg: newMsg, metadata: metadata, msgType: msgType};

 

Gambar 3.59 Node susun pesan discord menggunakan bahasa JavaScript

2. Aktifkan All messages jika diperlukan untuk pengujian, lalu klik Add. Hubungkan keluaran setAlarm ke node susun pesan discord menggunakan label critical, tanpa menghapus sambungan critical ke node create alarm.

Objek baru memiliki key content yang dibaca Discord sebagai isi pesan. Tanda \n membentuk baris baru, metadata.deviceName menyediakan nama perangkat, sedangkan msg.suhu dan msg.kelembaban mengambil nilai sensor dari payload. Transformasi ditempatkan pada cabang Discord agar perubahan struktur data tidak mengganggu cabang alarm.

3.5.22  Mengirim Pesan melalui REST API Call

1. Dari kategori External, tarik node rest api call dan beri nama kirim ke discord. Tempel URL webhook yang telah disalin pada kolom URL.
2. Pilih Request method POST. Biarkan Query parameters kosong. Pada Headers, isi Header dengan Content-Type dan Value dengan application/json. Pengaturan lain dibiarkan pada nilai bawaan.

Gambar 3.60 Konfigurasi REST API call menggunakan HTTP POST; token webhook disamarkan

3. Hubungkan keluaran susun pesan discord ke kirim ke discord menggunakan label Success. Simpan node dan rule chain dengan tombol centang.

Alur akhirnya adalah Input → setAlarm. Jalur minor dan major menuju pembentuk alarm sesuai tingkatnya, jalur normal menuju clear alarm, sedangkan jalur critical bercabang menuju create alarm critical dan susun pesan discord. Penyusun pesan meneruskan hasil melalui Success ke REST API call. Notifikasi dikirim sebagai permintaan HTTP ke Discord, bukan melalui SMTP atau layanan email ThingsBoard.

3.5.23  Memverifikasi Notifikasi dan Menelusuri Pengiriman

1. Jalankan Wokwi dan pastikan koneksi MQTT berhasil. Atur suhu DHT22 menjadi 38 °C dan kelembaban 40%, kemudian tunggu hingga Serial Monitor mencetak payload tersebut.
2. Buka server Praktikum IoT dan channel #general pada Discord. Periksa pesan dari ThingsBoard Alarm yang memuat nama Praktikum_Modul5, suhu 38 derajat Celsius, kelembaban 40 persen, serta status CRITICAL di atas ambang 35 derajat.

Gambar 3.61 Pesan peringatan suhu kritis diterima pada channel Discord

3. Setelah pesan diterima, turunkan suhu ke kondisi normal atau hentikan simulasi. Jangan membiarkan suhu kritis terlalu lama karena konfigurasi ini mengirim pesan pada setiap telemetry yang melewati jalur critical.
4. Jika pesan tidak muncul, aktifkan debug All messages pada setAlarm, susun pesan discord, dan kirim ke discord. Buka Events, pilih Event type Debug, lalu perbarui daftar. Telusuri apakah pesan keluar melalui critical, berhasil ditransformasikan melalui Success, dan diterima node REST API call.

Bukti pada Gambar 3.61 menunjukkan dua pesan dengan isi yang sama selama nilai suhu masih 38 °C. Hal ini konsisten dengan pemicu berbasis setiap pesan telemetry, bukan hanya saat alarm baru dibuat. Tidak dilakukan pengukuran latensi Discord secara khusus; keberhasilan dinilai dari kecocokan isi pesan yang diterima dengan nilai sensor yang diuji.

Setelah pemeriksaan selesai, nonaktifkan debug agar pencatatan tidak berlangsung tanpa kebutuhan. Untuk penggunaan jangka panjang, diperlukan cooldown atau pemicu perubahan status sehingga peringatan tetap informatif dan tidak menjadi spam.

3.6  Hasil Pengujian

Ringkasan hasil pengujian setiap bagian sistem disajikan pada Tabel 3.10. Pengujian komunikasi, dashboard, alarm, dan notifikasi Discord memberikan hasil sesuai fungsi yang diuji. Pengiriman email dicatat sebagai layanan yang terblokir oleh batas API, bukan sebagai pengiriman yang berhasil.

Tabel 3.10 Ringkasan hasil pengujian

No	Pengujian	Hasil yang diharapkan	Hasil yang diperoleh	Status
1	Autentikasi MQTT Basic dari MQTTX	Koneksi diterima broker	Terhubung, ikon daya merah (Gambar 3.13)	Berhasil
2	Publish data uji dari MQTTX	Telemetry suhu 50 dan kelembaban 80 tersimpan	Tersimpan pada 15:02:41 (Gambar 3.19)	Berhasil
3	Perubahan status perangkat	Inactive menjadi Active	Active setelah daftar diperbarui (Gambar 3.18)	Berhasil
4	Koneksi WiFi ESP32	Terhubung dan memperoleh alamat IP	WiFi connected, IP 10.10.0.2 (Kode 3.4)	Berhasil
5	Koneksi MQTT ESP32	Pesan Thingsboard is Connected muncul	Pesan muncul pada Serial Monitor (Kode 3.4)	Berhasil
6	Pengiriman data berkala	Telemetry diperbarui setiap 5 detik	Telemetry 24.0 dan 40.0 pada 15:29:24 (Gambar 3.32)	Berhasil
7	Respons perubahan nilai sensor	Telemetry mengikuti nilai baru dalam 5 detik	Suhu 36.8 pada 16:01:40 (Gambar 3.35)	Berhasil
8	Dashboard sensor	Widget menampilkan telemetry perangkat	Termometer suhu dan Line chart disiapkan; grafik kelembaban 40% tampil (Gambar 3.43)	Berhasil
9	Klasifikasi suhu	Suhu 36,8 °C menghasilkan critical	Output ["critical"] pada uji fungsi switch (Gambar 3.47)	Berhasil
10	Pembentukan alarm	Telemetry diproses menjadi alarm	Alarm Critical dan Major tercatat (Gambar 3.56)	Berhasil
11	Tabel alarm dashboard	Sumber alarm sesuai perangkat	Alarms table diarahkan ke Praktikum_Modul5 (Gambar 3.57)	Diatur
12	Pengiriman email	Pesan diterima alamat tujuan	Ditolak: Email sending is disabled due to API limits!	Terblokir layanan
13	Notifikasi Discord	Peringatan kritis diterima channel	Pesan suhu 38 °C dan kelembaban 40% diterima (Gambar 3.61)	Berhasil
14	Pemicu notifikasi berulang	Perilaku pengiriman dapat dikenali	Dua pesan sejenis muncul saat suhu tetap kritis (Gambar 3.61)	Teramati

 

3.7  Pembahasan

Hasil pengujian menunjukkan bahwa rantai komunikasi dari sensor hingga cloud telah berfungsi dan dilengkapi dengan dashboard, alarm suhu, serta notifikasi Discord. Terdapat beberapa hal yang layak dibahas lebih lanjut dari implementasi ini.

Pertama, metode pengujian berlapis terbukti bermanfaat. Ketika simulasi Wokwi sempat gagal terhubung akibat gangguan jaringan, penyebabnya dapat segera dipastikan bukan berasal dari kredensial maupun sisi server, karena keduanya sudah terbukti bekerja pada tahap pengujian MQTTX. Tanpa langkah tersebut, proses penelusuran kesalahan harus dilakukan terhadap empat kemungkinan sekaligus, yaitu kredensial, broker, program, dan jaringan.

Kedua, pemilihan key JSON harus konsisten di seluruh sistem. Payload yang dikirim menggunakan key suhu dan kelembaban, sehingga rule chain dan penyusun pesan Discord merujuk pada msg.suhu serta msg.kelembaban, bukan msg.temperature atau msg.humidity. Ketidakkonsistenan penamaan merupakan salah satu kesalahan yang paling sering terjadi dan tidak menghasilkan pesan galat yang jelas.

Ketiga, penempatan logika pengambilan keputusan pada sisi server merupakan keputusan arsitektur yang penting. ESP32 dirancang hanya mengirimkan angka mentah tanpa mengetahui ambang batas apa pun. Dengan demikian, apabila ambang batas perlu diubah, perubahan cukup dilakukan pada rule chain tanpa perlu memprogram ulang perangkat yang sudah terpasang di lapangan.

Keempat, aturan satu koneksi untuk setiap Client ID pada broker MQTT terlihat nyata selama praktikum. Aturan ini sebenarnya merupakan mekanisme pengaman, karena mencegah dua perangkat berbeda mengaku sebagai perangkat yang sama. Konsekuensinya, alat uji dan perangkat yang memakai kredensial identik tidak boleh dijalankan bersamaan.

Kelima, dashboard, alarm, dan notifikasi merupakan fungsi yang saling melengkapi. Widget menyajikan telemetry yang tersimpan, sedangkan jalur Success dari Save Timeseries meneruskan data ke Wokwi_DHT_Alarm. Kecocokan key suhu dan kelembaban serta label minor, major, critical, dan normal memastikan pesan diproses melalui jalur yang benar.

Keenam, pembatasan layanan email tidak menghentikan fungsi peringatan sistem. Node REST API call mengirimkan payload dengan key content ke webhook Discord melalui HTTP POST. Bukti penerimaan pesan pada suhu 38 °C menunjukkan bahwa alur sensor, cloud, klasifikasi, dan notifikasi telah terhubung tanpa perubahan program ESP32.

Ketujuh, notifikasi Discord dipicu oleh setiap telemetry pada kondisi critical, bukan hanya ketika alarm baru terbentuk. Karena perangkat mengirimkan data setiap lima detik, suhu kritis yang bertahan dapat menghasilkan pesan berulang. Cooldown atau pemicu perubahan kondisi diperlukan untuk penggunaan operasional, disertai pengamanan URL webhook.

 

 

BAB IV
PENUTUP

4.1  Kesimpulan

Berdasarkan implementasi dan pengujian yang telah dilakukan, dapat ditarik kesimpulan sebagai berikut:

1. Perangkat berhasil didaftarkan pada ThingsBoard Cloud dengan kredensial MQTT Basic. Jenis kredensial ini dipilih karena didukung secara langsung oleh pustaka PubSubClient pada ESP32, sementara X.509 memerlukan penanganan TLS yang jauh lebih berat untuk lingkungan simulasi.
2. Jalur komunikasi MQTT berhasil diverifikasi melalui pengiriman data manual dari MQTTX ke topik v1/devices/me/telemetry. Data uji berupa suhu 50 dan kelembaban 80 tersimpan pada tab Latest telemetry, yang membuktikan bahwa kredensial, alamat broker, topik, dan format payload telah benar sebelum program perangkat ditulis.
3. Program pada ESP32 yang disimulasikan di Wokwi berhasil membaca sensor DHT22 dan mengirimkan data secara otomatis setiap lima detik ke ThingsBoard Cloud. Keberhasilan ini ditandai dengan pesan Thingsboard is Connected pada Serial Monitor dan perubahan nilai telemetry menjadi 24.0 dan 40.0.
4. Responsivitas sistem terbukti melalui pengujian sebab-akibat. Perubahan nilai suhu dari 24,0 °C menjadi 36,8 °C pada sensor tercermin pada telemetry ThingsBoard dalam waktu kurang dari lima detik, sehingga rantai data dari ujung ke ujung dinyatakan berfungsi.
5. Metode pengujian berlapis terbukti efektif dalam mempersempit ruang penelusuran kesalahan. Dengan memastikan sisi server berfungsi terlebih dahulu, kegagalan yang terjadi pada tahap berikutnya dapat segera dipastikan bersumber dari program atau koneksi jaringan.
6. Broker MQTT hanya mengizinkan satu koneksi aktif untuk setiap Client ID, sehingga alat uji dan perangkat yang menggunakan kredensial yang sama tidak dapat dijalankan secara bersamaan.
7. Penempatan logika pengambilan keputusan pada sisi server memungkinkan perubahan ambang batas dilakukan tanpa memprogram ulang perangkat, sehingga sistem menjadi lebih mudah dirawat.
8. Dashboard dikembangkan dengan termometer suhu, grafik kelembaban, dan sumber tabel alarm dari perangkat yang sama. Klasifikasi ruang server diterapkan pada rule chain, dan pengujian suhu 36,8 °C menghasilkan keluaran critical.
9. Alarm Critical dan Major tercatat pada ThingsBoard. Jalur normal menggunakan clear alarm dengan Alarm type yang sama untuk menangani kondisi ketika suhu kembali normal.
10. Notifikasi menggunakan Discord sebagai pengganti email yang diblokir oleh batas API pada akun pengujian. Pesan yang memuat suhu 38 °C dan kelembaban 40% berhasil diterima pada channel tujuan.
11. Pengiriman berulang ketika suhu tetap kritis menunjukkan perlunya pembatasan frekuensi notifikasi dan perlindungan token webhook pada pengembangan berikutnya.

4.2  Saran

Beberapa saran yang dapat diberikan untuk pengembangan dan pelaksanaan praktikum berikutnya adalah:

1. Pastikan kredensial yang digunakan bersifat unik dan berbeda dari contoh pada modul, karena kredensial MQTT Basic berlaku di seluruh server ThingsBoard Cloud dan dapat menimbulkan konflik antarpengguna.
2. Jalankan hanya satu klien MQTT dalam satu waktu untuk setiap Client ID. Putuskan MQTTX sebelum menjalankan simulasi Wokwi.
3. Biasakan menyimpan proyek Wokwi setiap selesai melakukan satu perubahan, karena perubahan yang belum disimpan akan hilang apabila halaman dimuat ulang.
4. Siapkan dokumentasi berupa tangkapan layar untuk setiap tahap sebagai cadangan apabila demonstrasi langsung terkendala jaringan pada saat presentasi.
5. Untuk pengembangan lebih lanjut, notifikasi Discord perlu dilengkapi pembatasan frekuensi, cooldown, atau pengiriman hanya ketika kondisi berubah agar channel tidak dipenuhi pesan berulang selama suhu tetap kritis.
6. Sistem ini dapat dikembangkan menjadi implementasi nyata dengan mengganti nama dan kata sandi jaringan WiFi serta menggunakan perangkat ESP32 dan sensor DHT22 fisik, tanpa perlu mengubah struktur program yang telah dibangun.
7. Jaga kerahasiaan URL webhook Discord dan samarkan token pada dokumentasi. Buat webhook baru apabila URL pernah terekspos.
8. Gunakan debug hanya saat pengujian dan bedakan keberhasilan menyusun payload dari keberhasilan menerima pesan pada layanan tujuan.

DAFTAR PUSTAKA

Adafruit Industries. DHT Sensor Library. Tersedia di https://github.com/adafruit/DHT-sensor-library. Diakses pada 9 Oktober 2026.

Discord. Developer Documentation: Webhook Resource. Tersedia di https://discord.com/developers/docs/resources/webhook.

EMQ Technologies. MQTTX: Your All-in-one MQTT Client Toolbox. Tersedia di https://mqttx.app/. Diakses pada 9 Oktober 2026.

Modul 5 Praktikum Internet of Things. Mencoba Platform IoT Cloud Siap Pakai dengan Wokwi. Program Studi Informatika.

MQTT.org. MQTT: The Standard for IoT Messaging. Tersedia di https://mqtt.org/. Diakses pada 9 Oktober 2026.

O'Leary, N. PubSubClient: Arduino Client for MQTT. Tersedia di https://github.com/knolleary/pubsubclient. Diakses pada 9 Oktober 2026.

ThingsBoard. ThingsBoard Documentation. Tersedia di https://thingsboard.io/docs/. Diakses pada 9 Oktober 2026.

Wokwi. Wokwi Documentation. Tersedia di https://docs.wokwi.com/. Diakses pada 9 Oktober 2026.

A