Belajar IoT Engineer - Arsitektur IoT End-to-End

#Pendahuluan

Setelah di episode 1 kita memahami peran IoT Engineer dan rantai nilainya — perangkat, koneksi, data, aplikasi — pada episode ini kita merangkai semuanya menjadi satu gambar utuh: arsitektur IoT end-to-end.

Mengapa arsitektur penting dipahami sebelum menulis firmware? Karena hampir semua kegagalan proyek IoT bukan disebabkan kode yang salah, melainkan desain yang salah di awal: memilih protokol yang tidak cocok, mengirim terlalu banyak data ke cloud, atau tidak menyiapkan jalur saat internet putus. Memahami arsitektur sejak awal adalah investasi yang membayar berkali-kali lipat di fase produksi.

#Empat Lapisan Utama

Arsitektur IoT klasik tersusun dari empat lapisan. Perhatikan alur datanya:

1. Device Layer — sensor mengukur dunia fisik, MCU mengubahnya menjadi data digital. Contoh: DHT22 mengukur suhu, ESP32 membacanya lewat GPIO.
2. Connectivity/Gateway Layer — jembatan antara perangkat dan cloud. Bisa berupa router WiFi, gateway LoRa, atau perangkat yang mengubah protokol.
3. Cloud Platform Layer — tempat data diterima, divalidasi, disimpan, dan diatur. Ini adalah AWS IoT, Azure IoT Hub, atau layanan serupa.
4. Application Layer — dashboard, notifikasi, dan analitik yang mengubah data menjadi keputusan.

Lapisan kelima yang kian penting adalah Edge Layer — pemrosesan yang terjadi di dekat perangkat, sebelum data mencapai cloud.

#Alur Data End-to-End

Ikuti satu pembacaan suhu dari sensor pabrik sampai dashboard:

1. Sensing — sensor membaca suhu 32,4°C.
2. Processing lokal — MCU memvalidasi nilai (masih dalam rentang wajar), lalu memformatnya menjadi JSON.
3. Transmission — firmware mengirim lewat MQTT ke topik factory/boiler/temperature dengan QoS 1.
4. Ingestion — gateway meneruskan ke cloud IoT platform; platform menerapkan policy dan menyimpan timestamp.
5. Storage — data masuk ke time series database (InfluxDB/TimescaleDB) untuk analitik.
6. Consumption — dashboard Grafana menampilkan grafik; jika suhu melewati ambang 85°C, alarm terpicu.

{
  "device_id": "boiler-01",
  "temperature": 32.4,
  "humidity": 61.2,
  "ts": 1786900000
}

Perhatikan field ts — timestamp sangat penting dalam IoT karena data dikirim tidak selalu berurutan. Tanpa timestamp, urutan data di cloud akan kacau.

#Edge Layer: Pemrosesan di Dekat Perangkat

Edge computing adalah pemrosesan data di dekat sumbernya, bukan di cloud. Bayangkan sensor getaran mesin yang menghasilkan 1.000 sampel per detik: mengirim semuanya ke cloud akan memakan bandwidth dan biaya besar. Lebih baik edge memproses secara lokal — menghitung nilai RMS, mendeteksi pola abnormal — lalu hanya mengirim ringkasannya.

Kapan edge diperlukan?

Aturan praktis: proses apa yang bisa diselesaikan secara lokal, selesaikan di lokal. Edge layer akan kita bedah lebih dalam di episode 10 dan 14.

#Pola Arsitektur yang Umum

Dalam praktik, arsitektur IoT mengikuti beberapa pola. Pilih sesuai kebutuhan:

Contoh nyata: smart home menggunakan gateway-aggregation — semua sensor Zigbee melapor ke hub, hub yang terhubung internet. Smart meter biasanya direct-to-cloud atau LPWAN. Mesin pabrik memakai edge-first untuk kontrol real-time.

#Praktik: Mendesain Arsitektur

Mari mendesain satu studi kasus: monitoring suhu & kelembapan gudang. Sebelum menulis kode, jawab empat pertanyaan desain:

1. Di mana perangkat berada dan apa sumber dayanya? Gudang punya listrik dan WiFi — bisa langsung ke cloud tanpa gateway.
2. Seberapa sering dan seberapa besar datanya? Kirim setiap 5 menit, payload kecil (±100 byte). Biaya cloud akan sangat murah.
3. Apa konsekuensi jika internet putus? Penyimpanan gudang rusak perlahan — masih toleran 10 menit tanpa data. Buffer di perangkat cukup.
4. Apa yang harus segera bereaksi? Alarm suhu gudang — butuh notifikasi, tapi tidak butuh kontrol real-time.

Keputusan desainnya:

Sensor BME280 → ESP32 (buffer lokal, kirim 5 menit sekali)
    → MQTT over TLS (WiFi) → AWS IoT Core
    → Rule engine → InfluxDB (time series)
    → Grafana (dashboard) + SNS (alarm suhu)

Arsitektur ini sederhana, murah, dan cukup: tanpa gateway, tanpa edge — karena persyaratannya memang tidak membutuhkan keduanya.

#Penutup

Inti yang harus dibawa pulang:

• Arsitektur IoT punya empat lapisan: device, connectivity/gateway, cloud, application — plus edge layer yang kian penting.
• Data mengalir: sensing → processing lokal → transmission → ingestion → storage → consumption.
• Edge dipakai saat latensi, bandwidth, atau offline menjadi masalah; cloud untuk analitik dan agregasi lintas perangkat.
• Pilih pola arsitektur (direct-to-cloud, gateway, edge-first, hybrid) berdasarkan persyaratan, bukan tren.
• Desain dimulai dari pertanyaan: lokasi & daya, frekuensi data, konsekuensi offline, dan kebutuhan reaksi.

Di episode 3 selanjutnya, kita akan turun ke lapisan paling bawah: hardware & sensors dasar — memahami MCU seperti ESP32 dan STM32, GPIO, sensor, aktuator, dan praktik membaca sensor pertama. Pastikan ESP32 kalian siap, karena kita mulai menulis firmware sungguhan!