Belajar IoT Engineer - Time Series & Data Analytics IoT

#Pendahuluan

Di episode 8 data kalian sudah mengalir ke storage. Sekarang tibalah saat paling menarik: mengubah data menjadi wawasan. Telemetry yang tidak dianalisis hanyalah biaya storage; telemetry yang dianalisis adalah alat pengambil keputusan — kapan mesin perlu perawatan, sensor mana yang rusak, atau pola konsumsi energi di gedung.

Mengapa IoT membutuhkan pendekatan data khusus? Karena data IoT adalah time series: pasangan nilai dan timestamp yang terus bertambah. Database relasional biasa bisa menyimpannya, tapi tidak efisien untuk pola query yang selalu berdimensi waktu — itulah mengapa ada database khusus seperti InfluxDB.

#Model Data Time Series

InfluxDB menyimpan data dalam point dengan tiga komponen:

Tag dan field harus dibedakan dengan benar: tag untuk yang jarang berubah dan dipakai filter (device, site), field untuk nilai pengukuran (suhu, tekanan). Memakai suhu sebagai tag adalah kesalahan desain — nilai yang terus berubah tidak boleh di-index.

influx write --bucket telemetry \
  "environment,site=jakarta,device=ruang-01 temperature=26.5,humidity=61 1786900000"

#Query Agregasi dengan Flux

Flux adalah bahasa query InfluxDB 2.x. Pola query yang paling sering dipakai:

from(bucket: "telemetry")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "environment")
  |> filter(fn: (r) => r._field == "temperature")
  |> aggregateWindow(every: 5m, fn: mean)
  |> yield(name: "mean_5m")

Query ini mengambil data 24 jam terakhir dan menghitung rata-rata per jendela 5 menit. Ini pola downsampling yang kita sebut di episode 8: mereduksi resolusi untuk mengurangi volume data lama.

Pola lain yang sering dipakai:

from(bucket: "telemetry")
  |> range(start: -7d)
  |> filter(fn: (r) => r._field == "temperature")
  |> group(columns: ["device"])
  |> min()
  |> yield(name: "min")

Grouping berdasarkan device lalu menghitung nilai minimum tiap perangkat — cara cepat menemukan perangkat dengan suhu terendah/tertinggi.

#Deteksi Anomali

Anomali dalam data IoT bisa berarti sensor rusak, mesin bermasalah, atau — yang lebih serius — perangkat dibajak. Tiga pendekatan umum:

Contoh sederhana dengan statistik: nilai di luar ±3 standard deviation dari rata-rata 24 jam kemungkinan besar anomali.

from(bucket: "telemetry")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "environment")
  |> filter(fn: (r) => r._field == "temperature")
  |> stateCount(fn: (r) => r._value > 40.0, column: "high_count")
  |> filter(fn: (r) => r.high_count > 3)

Query ini menghitung berapa sampel berurutan melebihi 40°C. Jika lebih dari 3 beruntun, kemungkinan bukan noise — ini tanda untuk mengirim alert. Pendekatan ML untuk anomali kita bahas di episode 23.

#Membangun Dashboard

Dashboard menjawab pertanyaan dengan cepat: semua perangkat sehat? Pilihan tool umum: Grafana (favorit, terintegrasi InfluxDB), Chronograf (bawaan InfluxDB), atau dashboard platform cloud.

Setup Grafana + InfluxDB:

services:
  influxdb:
    image: influxdb:2.7
    ports: ["8086:8086"]
    environment:
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: admin123
      DOCKER_INFLUXDB_INIT_ORG: iot-lab
      DOCKER_INFLUXDB_INIT_BUCKET: telemetry
 
  grafana:
    image: grafana/grafana:latest
    ports: ["3000:3000"]

docker compose up -d

Di Grafana: tambahkan data source InfluxDB (URL http://influxdb:8086, token, org iot-lab), lalu buat panel dengan query:

from(bucket: "telemetry")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._field == "temperature")
  |> aggregateWindow(every: v.windowPeriod, fn: mean)

Dashboard yang baik menampilkan: health perangkat (online/offline), metrik utama (suhu, kelembapan), perangkat bermasalah, dan alert anomali.

#Praktik: Analisis Data dari Perangkat Kalian

Alur lengkap yang bisa kalian coba sekarang:

1. ESP32 mengirim telemetry ke broker/cloud (episode 5–7).
2. Pipeline menulis ke InfluxDB (episode 8).
3. Query rata-rata 5 menit untuk melihat tren suhu harian.
4. Deteksi outlier 3-sigma untuk menemukan pembacaan aneh.
5. Dashboard Grafana menampilkan hasilnya secara live.

mosquitto_pub -h localhost -t "sensor/ruang-01/telemetry" \
  -m '{"temperature":67.0,"humidity":20}'

Cek: apakah query outlier menangkap pembacaan 67°C ini? Jika ya, dashboard alerting berfungsi.

#Kesalahan Umum

1. Field dipakai sebagai tag — nilai berubah-ubah jadi index; query jadi lambat dan mahal.
2. Downsampling tidak dijadwalkan — data mentah menumpuk, biaya membengkak.
3. Alert hanya threshold statis — alarm spam di sekitar ambang; pakai hysteresis atau statistik bergulir.
4. Dashboard tanpa fokus — menampilkan segalanya tapi menjawab tidak ada pertanyaan.
5. Mengabaikan timestamps duplikat/out-of-order — pastikan deduplikasi dan urutan benar di pipeline.

#Penutup

Inti yang harus dibawa pulang:

• Data IoT adalah time series: measurement + tags + fields + timestamp.
• InfluxDB menyimpan dan men-query data berstempel waktu secara efisien.
• Pola query inti: agregasi/downsampling dan statistik per kelompok.
• Deteksi anomali: threshold → statistik → ML, sesuai kompleksitas pola.
• Dashboard yang baik menjawab satu pertanyaan utama, bukan memamerkan semua data.

Di episode 13 selanjutnya, kita akan menempatkan kecerdasan di perangkat: edge AI & TinyML — bagaimana menjalankan model machine learning di mikrokontroler dengan TensorFlow Lite Micro, kuantisasi model, dan praktik menjalankan inferensi pertama di ESP32. Perangkat kalian mulai "berpikir" sendiri!