Mempelajari edge computing untuk IoT: mengapa memproses data di dekat perangkat, peran edge gateway, pemrosesan lokal, mode offline dengan buffering, serta praktik memindahkan sebagian pipeline ke perangkat dan hanya mengirim ringkasan ke cloud.

Di episode 8 kita membangun pipeline yang mengirim semua telemetry ke cloud. Di episode ini kita mempertanyakan asumsi itu: apakah semua data harus dikirim ke cloud? Jawabannya: tidak selalu — dan semakin banyak sistem produksi memilih memproses sebagian data di edge, dekat dengan perangkat.
Mengapa edge penting? Tiga alasan utama: latensi (kontrol mesin butuh respons milidetik, bukan detik), bandwidth & biaya (mengirim 1.000 sampel/detik ke cloud mahal), dan ketersediaan (perangkat di lapangan tidak selalu punya internet).
| Keputusan | Edge | Cloud |
|---|---|---|
| Latensi milidetik (kontrol, keselamatan) | ✓ | ✗ |
| Data volum besar (audio, video, getaran) | ✓ ringkas dulu | ✗ mahal |
| Perangkat offline (fleet di lapangan) | ✓ buffer lokal | ✗ |
| Agregasi lintas banyak perangkat | ✗ | ✓ |
| ML berat, analitik mendalam | ✗ | ✓ |
| Model yang perlu diperbarui terpusat | ✗ | ✓ |
Aturan praktis dari episode 2 kembali berlaku: proses secara lokal apa yang bisa diselesaikan secara lokal. Edge mengurangi latensi, biaya, dan ketergantungan pada jaringan — sementara cloud tetap menjadi otak untuk agregasi dan keputusan lintas perangkat.
Dua tingkat edge yang umum:
| Tingkat | Perangkat | Contoh Tugas |
|---|---|---|
| Edge device | MCU di perangkat (ESP32) | Baca sensor, filter noise, kirim ringkasan |
| Edge gateway | Raspberry Pi, industrial PC | Agregasi banyak perangkat, protokol translation, model ML kecil |
Tugas yang cocok dijalankan di edge: filtering (buang data tidak berguna), agregasi (rata-rata per menit), deteksi (event melampaui ambang), buffering (simpan saat offline), dan inference ringan (model TinyML — episode 13).
Kita ubah firmware dari episode 5: alih-alih mengirim setiap pembacaan, firmware menghitung rata-rata per menit dan hanya mengirim ringkasannya. Ini memangkas traffic 60x jika sensor dibaca tiap detik.
#include <Arduino.h>
#include <WiFi.h>
#include <PubSubClient.h>
unsigned long windowStart = 0;
const unsigned long WINDOW_MS = 60000; // agregasi per 1 menit
float sumTemp = 0;
int sampleCount = 0;
void accumulateSample(float t) {
sumTemp += t;
sampleCount++;
}
void publishSummary() {
if (sampleCount == 0) return;
float avg = sumTemp / sampleCount;
char payload[64];
snprintf(payload, sizeof(payload),
"{\"device\":\"ruang-01\",\"avg_temp\":%.1f,\"samples\":%d}",
avg, sampleCount);
mqtt.publish("sensor/ruang-01/summary", payload);
sumTemp = 0;
sampleCount = 0;
}
void loop() {
mqtt.loop();
float t = readSensor(); // fungsi baca sensor dari episode 3
accumulateSample(t);
unsigned long now = millis();
if (now - windowStart >= WINDOW_MS) {
windowStart = now;
publishSummary();
}
delay(1000); // baca sensor tiap detik
}Hasilnya: dari 60 pesan per menit menjadi 1 pesan per menit. Payload juga lebih kecil karena hanya membawa rata-rata dan jumlah sampel.
Perangkat di lapangan akan kehilangan internet. Firmware produksi wajib punya mode offline: terus bekerja, menyimpan data, dan mengirimnya saat koneksi pulih.
| Strategi | Cara Kerja | Cocok Untuk |
|---|---|---|
| Buffer in-memory | Simpan di RAM saat offline | Offline singkat (menit) |
| Buffer di flash/EEPROM | Tulis ke storage non-volatile | Offline lama (jam–hari) |
| Backfill dengan timestamp | Kirim ulang dengan waktu asli | Analitik butuh urutan benar |
#include <Arduino.h>
#include <LittleFS.h>
void storeTelemetry(const char *payload) {
File f = LittleFS.open("/buffer.txt", FILE_APPEND);
if (f) {
f.println(payload);
f.close();
}
}
void flushBuffer() {
if (WiFi.status() != WL_CONNECTED) return;
File f = LittleFS.open("/buffer.txt", FILE_READ);
while (f.available()) {
String line = f.readStringUntil('\n');
mqtt.publish("sensor/ruang-01/buffered", line.c_str());
}
f.close();
LittleFS.remove("/buffer.txt");
}Tip
Kunci buffering offline: kirim ulang dengan timestamp asli (bukan waktu tiba). Data yang terlambat beberapa jam tetap masuk di posisi kronologis yang benar di time series database — ini alasan field ts dari perangkat wajib ada sejak episode 8.
Edge juga ideal untuk deteksi event — mengirim notifikasi hanya saat sesuatu penting terjadi, bukan mengirim semua data:
void checkAlarm(float t) {
static bool alarmActive = false;
if (t > 45.0f && !alarmActive) {
alarmActive = true;
mqtt.publish("alerts/ruang-01", "{\"level\":\"high_temp\",\"temp\":45.2}");
} else if (t < 40.0f) {
alarmActive = false; // kembali normal, siapkan alarm berikutnya
}
}Pola ini (hysteresis — alarm hanya menyala saat melampaui ambang, mati saat kembali di bawah ambang lebih rendah) mencegah notifikasi berulang di sekitar nilai ambang.
Inti yang harus dibawa pulang:
Di episode 11 selanjutnya, kita akan mengamankan seluruh perjalanan yang sudah dibangun: IoT security fundamentals — secure boot, TLS, identitas perangkat, dan keamanan update — plus praktik hardening perangkat pertama kalian. Karena perangkat yang tidak aman adalah pintu masuk ke jaringan apa pun!