Arsitektur IoT E-Paper: Trade-off Polling HTTP vs Event-Driven MQTT

Pengembangan perangkat data logger berdaya rendah berbasis e-paper (seperti konsep Weathergotchi) memiliki batasan teknis yang ketat: perangkat harus bertahan berbulan-bulan menggunakan baterai, memperbarui layar tanpa konsumsi daya statis, dan meminimalkan waktu aktif radio (Wi-Fi atau seluler). Keputusan arsitektur paling fundamental dalam sistem ini terletak pada protokol komunikasi: menggunakan HTTP polling berbasis batch atau koneksi persistent berbasis event-driven MQTT.

Karakteristik Hardware dan Siklus Daya E-Paper

Layar Electronic Paper Display (EPD) bersifat bistabil: daya listrik hanya dikonsumsi saat mengubah orientasi pigmen (proses refresh). Ketika gambar terbentuk, layar mempertahankan tampilan tanpa pasokan daya sama sekali. Oleh karena itu, penghematan energi bergeser sepenuhnya ke modul komputasi dan radio (misalnya ESP32).

Profil konsumsi daya tipikal ESP32:

• Deep Sleep: ~10–15 µA (hanya RTC timer dan ULP coprocessor aktif).
• Modem Wi-Fi Aktif (TX/RX): 80–240 mA.
• Proses EPD Refresh: 10–30 mA selama 1–3 detik.

Tujuan utama firmware adalah memaksimalkan durasi deep sleep dan meminimalkan time-on-air modul radio.

Pola 1: Batch Polling via Stateless HTTP

Pada pendekatan polling HTTP, mikrokontroler bangun dari mode deep sleep menggunakan timer RTC, menyalakan radio, melakukan negosiasi koneksi, mengirimkan telemetri sekaligus mengambil data cuaca terbaru dalam satu transaksi HTTP POST/GET, memperbarui layar e-paper, lalu langsung kembali ke deep sleep.

// Pseudocode ESP32: HTTP Poll & Sleep
void setup() {
  wake_sensor_and_read(&sensor_data);
  wifi_connect();
  
  // Mengirim data lokal dan menerima payload cuaca eksternal sekaligus
  http_response_t res = http_post("https://api.example.com/v1/sync", sensor_data);
  wifi_disconnect();
  
  if (res.status == 200) {
    epd_render_weather(res.body);
  }
  
  // Masuk kembali ke deep sleep (misal: 30 menit)
  esp_sleep_enable_timer_wakeup(30 * 60 * 1000000);
  esp_deep_sleep_start();
}

Kelebihan HTTP Polling:

• Backend Stateless: Cukup menggunakan AWS Lambda / Cloud Run dan API Gateway yang skala otomatis hingga nol ketika tidak ada request.
• Toleransi Kegagalan Jaringan: Tidak memerlukan sinkronisasi state koneksi TCP. Jika koneksi gagal, sistem dapat langsung tidur dan mencoba lagi pada siklus berikutnya.
• Kompatibilitas CDN/Cache: Response data cuaca publik dapat di-cache di edge CDN (misal Cloudflare), mengurangi beban server database.

Pola 2: Event-Driven via Persistent MQTT Connection

MQTT dirancang untuk overhead packet yang sangat kecil (2-byte fixed header). Pola ini mengharuskan klien menjaga koneksi TCP tetap terbuka menggunakan mekanisme PINGREQ/PINGRESP (Keep-Alive) agar broker dapat mem-push data secara real-time ke perangkat.

Hambatan Utama MQTT pada Perangkat Baterai:

Untuk menerima pesan secara asinkron dari broker MQTT, radio Wi-Fi atau modem seluler harus tetap aktif atau berada dalam mode power-save teratur (DTIM beacon listening). Menjaga modul Wi-Fi tetap aktif mengonsumsi daya rata-rata ~20–30 mA, yang akan menguras baterai 18650 (2500 mAh) dalam hitungan beberapa hari, bukan bulan.

Alternatifnya, perangkat melakukan siklus Connect-Subscribe-Wait-Disconnect setiap bangun dari sleep. Namun, pendekatan ini memiliki overhead yang membatalkan efisiensi MQTT:

• Perangkat harus menyelesaikan handshake TCP (3 paket) dan TLS (jika memakai MQTTS).
• Mengirim paket CONNECT dan menunggu CONNACK.
• Mengirim paket SUBSCRIBE dan menunggu SUBACK.
• Menunggu broker mempublikasikan data (membutuhkan timeout idle).
• Mengirim paket DISCONNECT.

Perbandingan Konsumsi Bandwidth dan Handshake

Berikut kalkulasi estimasi overhead transmisi terenkripsi (TLS 1.3) per siklus bangun:

Meskipun payload murni MQTT lebih ringkas daripada HTTP, kebutuhan menunggu (blocking wait) kedatangan payload pada broker MQTT membuat radio aktif lebih lama pada koneksi transien, yang justru meningkatkan konsumsi miliampere-jam (mAh).

Kompleksitas Infrastruktur Backend dan Biaya

Stateless HTTP API Gateway

Permintaan HTTP dari ribuan edge device dapat ditangani menggunakan REST endpoint di balik load balancer standar. Tidak ada beban memori untuk memelihara socket terbuka.

• Biaya: Pay-per-request (sangat murah untuk interval pembaruan 15–60 menit).
• Operasional: Zero maintenance, logs terpusat, zero state leak.

MQTT Broker Cluster

Menjalankan broker MQTT (seperti Mosquitto atau EMQX) untuk ratusan ribu edge device membutuhkan arsitektur stateful:

• Setiap koneksi persisten mengalokasikan alokasi file descriptor dan RAM di server.
• Dibutuhkan sistem orkestrasi clustering (misal EMQX cluster dengan core node) untuk menangani load balancing koneksi TLS.
• Biaya komputasi berjalan terus menerus (idle cost) tanpa memedulikan volume transaksi data.

Panduan Keputusan Arsitektur

Gunakan acuan berikut untuk memilih protokol pada data logger berdaya baterai:

• Gunakan HTTP Batch Polling jika: Interval pembaruan ≥ 5 menit, perangkat ditenagai baterai seluler/Wi-Fi, dan backend dirancang stateless. Ini adalah arsitektur optimal untuk perangkat info-display e-paper cuaca.
• Gunakan MQTT Persistent jika: Perangkat terhubung ke sumber daya konstan (mains power/USB), latensi kontrol real-time (sub-detik) dibutuhkan (misal: smart home switch display), atau perangkat beroperasi di jaringan private berbandwidth sangat rendah tanpa TLS (misal: LoRaWAN application server bridge).