Dokumentasi Teknis - Implementasi Runtime Aktual

Alur Sistem Secara Sederhana

Bayangkan ada dua kurir yang mengantar pesan dari ESP32 ke server: kurir HTTP dan kurir MQTT. Keduanya membawa isi pesan yang sama, lalu server menyimpan hasil kiriman, menghitung kualitas pengiriman, dan menampilkan perbandingan keduanya di dashboard.

Secara teknis, firmware di ESP32_Firmware/src/main.cpp mengirim payload periodik ke POST /api/http-data (HTTP) dan ke broker topic iot/esp32/suhu (MQTT). Jalur HTTP diproses ApiController::storeHttp, jalur MQTT diproses worker mqtt_worker.php, lalu keduanya tersimpan idempotent ke tabel eksperimens.

Bagaimana Data Mengalir di Sistem Ini

Bahasa sederhana: data bergerak dari alat (ESP32), masuk ke server, disimpan di database, dihitung statistiknya, lalu ditampilkan di dashboard.

Versi teknis: sendHTTP() dan sendMQTT() di firmware mengirim payload; HTTP diterima ApiController::storeHttp, MQTT diterima callback di mqtt_worker.php; data masuk Eksperimen::updateOrCreate; dashboard memanggil StatisticsService dari DashboardController::index.

[ESP32 Sensor Read]
        |
        +--> HTTP -> /api/http-data -> ApiController -> eksperimens
        |
        +--> MQTT -> Broker -> mqtt_worker.php -> eksperimens
                                              |
                                              v
                                    StatisticsService (summary, reliability, t-test)
                                              |
                                              v
                                    DashboardController -> dashboard.blade.php

System Overview

Untuk pembaca awam: halaman ini menjelaskan siapa mengirim data, ke mana data pergi, apa yang dihitung, dan bagaimana hasilnya dibaca di dashboard.

Untuk pembaca teknis: sistem membandingkan telemetry MQTT vs HTTP dari ESP32, menyimpan keduanya ke MySQL, lalu mengeksekusi statistik komparatif (summary, reliability, t-test) sebelum render chart dan panel analisis.

Arsitektur Aktual (Berbasis Kode)

Versi awam: ada dua jalur pengiriman dari ESP32, lalu kedua jalur bertemu di database untuk dianalisis bersama.

Versi teknis: diagram berikut mengikuti jalur runtime yang benar-benar ada di repository ini tanpa asumsi tambahan di luar kode.

ESP32 Firmware (main.cpp)
   |-- HTTP JSON -> POST /api/http-data
   |                 -> middleware(throttle:http-data, ingest.key)
   |                 -> ApiController::storeHttp()
   |                 -> Eksperimen::updateOrCreate(device_id, 'HTTP', packet_seq)
   |
   |-- MQTT JSON -> topic iot/esp32/suhu
                     -> Mosquitto Broker (202.154.58.51:1883)
                     -> mqtt_worker.php subscribe()
                     -> Eksperimen::updateOrCreate(device_id, 'MQTT', packet_seq)

Dashboard (/)
   -> DashboardController::index()
   -> StatisticsService (summary, reliability, t-test)
   -> dashboard.blade.php (cards, warnings, diagnostics, charts, t-test)

Optional simulation branch
   /simulation endpoints -> ApplicationSimulationService
   -> simulated_eksperimens table
   -> /?source=simulation dashboard source

Timeline Visual: HTTP Request/Response vs MQTT Publish/Subscribe

Versi awam: kedua protokol berangkat dari titik waktu sensor yang sama, tetapi pola perjalanannya berbeda. HTTP menunggu balasan request, sedangkan MQTT publish lalu diproses subscriber worker.

Versi teknis: timeline ini memetakan timestamp_esp, fase transmit, momen server menerima data, dan langkah latency_ms dihitung pada backend ingest. Jalur HTTP terkait sendHTTP() + ApiController::storeHttp; jalur MQTT terkait sendMQTT() + mqtt_worker.php.

Peta Route Laravel (Aktual)

Controller HTTP dan Worker MQTT

Versi awam: pintu HTTP dijaga oleh Laravel, sedangkan pintu MQTT dijaga oleh worker khusus. Keduanya mengecek data sebelum menyimpan.

Versi teknis: route API menggunakan middleware throttle:http-data + ingest.key. MQTT berjalan sebagai proses subscriber tersendiri dengan validasi manual, lalu keduanya melakukan upsert idempotent ke tabel yang sama.

Catatan penting: repository ini tidak memiliki controller Laravel khusus MQTT ingest. Ingestion MQTT ditangani proses mandiri mqtt_worker.php.

Struktur JSON Payload yang Dipakai Runtime

Versi awam: payload adalah "isi paket" yang dibawa dari ESP32 ke server. Di dalamnya ada data utama sensor dan data tambahan untuk diagnosis kualitas jaringan.

Versi teknis: builder payload firmware (fillProtocolPayload()) selalu mengirim field telemetry wajib ditambah field diagnostik seperti RSSI, TX duration, payload bytes, dan counter keberhasilan/kegagalan kirim.

{
  "device_id": 1,
  "protokol": "HTTP",
  "packet_seq": 171234,
  "suhu": 28.125,
  "kelembapan": 60.45,
  "timestamp_esp": 1772021517,
  "daya": 812.34,
  "rssi_dbm": -60,
  "tx_duration_ms": 45.2,
  "payload_bytes": 208,
  "uptime_s": 7200,
  "free_heap_bytes": 265000,
  "sensor_age_ms": 980,
  "sensor_read_seq": 444,
  "send_tick_ms": 9876543,
  "sensor_reads": 445,
  "http_success_count": 320,
  "http_fail_count": 4,
  "mqtt_success_count": 318,
  "mqtt_fail_count": 6
}

Penjelasan Bertahap untuk Setiap Metrik

Bagian ini sengaja ditulis dua lapis: paragraf pertama untuk pemahaman awam, paragraf kedua untuk akurasi teknis sesuai kode.

Mekanisme Perhitungan Latency

Controller HTTP dan worker MQTT menggunakan formula latency yang sama.

// app/Http/Controllers/ApiController.php and mqtt_worker.php
$timestampServer = Carbon::now('UTC');
$timestampEsp = Carbon::createFromTimestampUTC((int) $validated['timestamp_esp']);
$latencyMs = abs((float) $timestampServer->floatDiffInMilliseconds($timestampEsp));

• Nilai latency disimpan di eksperimens.latency_ms.
• Menggunakan nilai absolut (abs), sehingga drift jam negatif tetap menjadi magnitude positif.
• Accessor model pada Eksperimen juga mengembalikan latency_ms absolut.

Mekanisme Perhitungan Daya (daya_mw)

Daya diestimasi di firmware (estimateProtocolPower()) lalu dikirim sebagai field daya. Backend menyimpannya ke daya_mw.

// ESP32_Firmware/src/main.cpp
float totalCurrentMa = wifiBaseCurrentMa
    + sensorCurrentMa
    + cpuCurrentMa
    + signalPenalty
    + payloadCurrent
    + txDurationCurrent
    + protocolOverhead
    + protocolReliabilityPenalty
    + thermalCurrent
    + humidityCurrent
    + retryPenalty;
float powerMw = voltage * totalCurrentMa;
return max(0.0f, powerMw);

• HTTP dan MQTT memakai protocol overhead yang berbeda (HTTP lebih tinggi).
• Penalty naik saat rasio gagal meningkat (httpSendFail/mqttSendFail).
• Durasi transmisi, ukuran payload, RSSI, dan delta lingkungan memengaruhi estimasi.
• Formula bersifat deterministik (jalur firmware saat ini tidak memakai baseline acak).

Packet Delivery Ratio (Reliability Backend)

Backend tidak menyimpan field terpisah bernama PDR, namun sequence reliability dihitung sebagai received / expected * 100 dan dipakai di skor reliability total.

// app/Services/StatisticsService.php
$missing = max(0, $expected - $received);
$rate = ($received / $expected) * 100;

// combineReliability() when packet_seq exists
return ($sequenceRate * 0.55) + ($completenessRate * 0.25) + ($transmissionRate * 0.20);

Independent Sample T-Test

Diimplementasikan di StatisticsService::tTest() untuk latency_ms dan daya_mw.

// app/Services/StatisticsService.php (core path)
$pooledVariance = (($n1 - 1) * $var1 + ($n2 - 1) * $var2) / $df;
$standardError = sqrt(max(0, $pooledVariance) * ((1 / $n1) + (1 / $n2)));
$tValue = ($mean1 - $mean2) / $standardError;
$criticalValue = 1.96;
$isSignificant = abs($tValue) > $criticalValue;

• Sample variance memakai denominator (n-1).
• Syarat minimum: tiap grup minimal memiliki 2 baris.
• Edge case standardError == 0 ditangani eksplisit (grup konstan).
• p_value memakai fungsi aproksimasi (normal CDF untuk df besar, bin kasar untuk df kecil).
• Dashboard menampilkan panel T-test terpisah untuk latency dan power.

Contoh Nyata dari Satu Siklus Data

Tujuan bagian ini adalah membuat angka-angka penelitian lebih mudah dibayangkan. Angka contoh di bawah menggunakan pola rumus yang sama dengan kode runtime.

timestamp_esp   = 1772021517   (UTC second)
timestamp_server= 1772021518.320 (UTC with millisecond)
latency_ms      = abs(1772021518.320 - 1772021517) * 1000
                = 1320 ms

Assume: protocol=HTTP, rssi=-60, payload=210 bytes, tx=80 ms,
cpu=240MHz, fail ratio HTTP=10%, temp=28C, humidity=60%, success=true.

totalCurrentMa ~ 72 + 2 + 26.4 + 9.75 + 42 + 14.4 + 20 + 3 + 2.7 + 0.5 + 0
               ~ 192.75 mA
powerMw = 3.30 * 192.75 ~ 636.08 mW

Kenapa Sistem Ini Dibuat Seperti Ini?

Struktur Database dan Relasi Tabel

devices (id PK)
  |-< eksperimens.device_id FK (1:N)
  |-< simulated_eksperimens.device_id FK (1:N)
  '- 1:1 device_firmware_profiles.device_id FK (unique)

app_settings (standalone key-value runtime overrides)

Contoh query (troubleshooting runtime)

-- Latest real rows by protocol
SELECT id, device_id, protokol, packet_seq, latency_ms, daya_mw, timestamp_server
FROM eksperimens
WHERE protokol IN ('MQTT', 'HTTP')
ORDER BY COALESCE(timestamp_server, created_at) DESC
LIMIT 20;

-- Required field completeness audit for MQTT scope
SELECT
  COUNT(*) AS total_rows,
  SUM(CASE WHEN suhu IS NULL THEN 1 ELSE 0 END) AS missing_suhu,
  SUM(CASE WHEN kelembapan IS NULL THEN 1 ELSE 0 END) AS missing_kelembapan,
  SUM(CASE WHEN packet_seq IS NULL THEN 1 ELSE 0 END) AS missing_packet_seq
FROM eksperimens
WHERE UPPER(protokol) = 'MQTT';

Alur: Data Masuk sampai Render Dashboard

Versi awam: setelah data disimpan di database, sistem mengolahnya menjadi angka ringkas agar pengguna bisa langsung melihat siapa yang lebih cepat, lebih hemat daya, dan lebih stabil.

Versi teknis: DashboardController::index mengambil data protocol dari model telemetry, memanggil StatisticsService untuk summary/reliability/t-test, menyusun payload chart, lalu mengirim semua hasil ke resources/views/dashboard.blade.php.

1. ESP32 mengirim payload HTTP dan MQTT dengan field telemetry lengkap.
2. Jalur HTTP masuk ke ApiController; jalur MQTT masuk ke mqtt_worker.php.
3. Kedua jalur menghitung latency dan melakukan idempotent upsert ke eksperimens.
4. DashboardController@index mengambil sampel MQTT dan HTTP (window analisis: 50, window chart: tidak terbatas).
5. StatisticsService menghitung summary stats, reliability, dan T-test.
6. View dashboard me-render metric cards, warning list, panel diagnostik, chart latency, chart power, dan section analisis statistik.
7. Auto-refresh frontend memperbarui cards, charts, dan diagnostics secara periodik.

Validasi pada Ingest dan Statistik Backend

Batasan Sistem (Berdasarkan Kode Saat Ini)

• p_value pada T-test memakai aproksimasi, terutama kasar untuk df kecil.
• Critical value di kode bersifat tetap (+/-1.96), tidak menyesuaikan df secara dinamis.
• daya_mw adalah estimasi sisi firmware, bukan pembacaan sensor listrik langsung.
• Latency bergantung pada validitas jam ESP32; drift NTP atau epoch tidak sinkron akan menurunkan kualitas metrik.
• Sequence reliability memakai aturan segmentasi (reboot/jump handling), sehingga lompatan sangat besar diperlakukan sebagai segmen baru, bukan loss kontinu.
• Ingestion MQTT bergantung pada proses worker mandiri; jika worker down, telemetry MQTT tidak tersimpan.
• Dokumentasi ini implementation-bound; update halaman ini saat schema telemetry, formula, atau runtime path berubah.

Glossary / Daftar Istilah

Setiap istilah ditulis dua lapis: penjelasan sederhana untuk pembaca umum, lalu penjelasan teknis sesuai implementasi kode di repository ini.