Technical Documentation - Actual Runtime Implementation

System Flow in Simple Language

Imagine two couriers delivering messages from ESP32 to the server: HTTP courier and MQTT courier. Both carry similar message content, then the server stores each delivery, calculates delivery quality, and shows the comparison on the dashboard.

Technically, firmware in ESP32_Firmware/src/main.cpp sends periodic payloads to POST /api/http-data (HTTP) and broker topic iot/esp32/suhu (MQTT). HTTP path is handled by ApiController::storeHttp, MQTT path is handled by worker mqtt_worker.php, then both are stored idempotently in eksperimens.

How Data Flows in This System

Simple view: data moves from device (ESP32), enters server, is stored in database, gets statistical processing, and is finally shown on dashboard.

Technical view: firmware sendHTTP() and sendMQTT() push payloads; HTTP is accepted by ApiController::storeHttp, MQTT is accepted by callback in mqtt_worker.php; data is written via Eksperimen::updateOrCreate; dashboard calls StatisticsService from 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

For general readers: this page explains who sends the data, where it goes, what is calculated, and how the results are read on dashboard.

For technical readers: the system compares MQTT vs HTTP telemetry from ESP32, stores both in MySQL, then runs comparative statistics (summary, reliability, t-test) before rendering charts and analysis panels.

Actual Architecture (Code-Based)

Simple view: there are two delivery channels from ESP32, then both channels meet in database for joint analysis.

Technical view: the diagram below follows runtime paths that actually exist in this repository with no assumptions beyond code.

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

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

Simple view: both protocols start from sensor timestamp, but the travel pattern differs. HTTP waits for request response, while MQTT publishes and is then processed by subscriber worker.

Technical view: this timeline maps timestamp_esp, transmit phase, server receive moment, and where latency_ms is computed in backend ingest. HTTP path maps to sendHTTP() + ApiController::storeHttp; MQTT path maps to sendMQTT() + mqtt_worker.php.

Laravel Route Map (Current)

HTTP Controller and MQTT Worker

Simple view: HTTP gate is handled by Laravel, while MQTT gate is handled by a dedicated worker. Both validate data before storing it.

Technical view: API route uses throttle:http-data + ingest.key middleware. MQTT runs as separate subscriber process with manual validation, then both perform idempotent upsert into the same table.

Important note: this repository has no dedicated Laravel MQTT ingest controller. MQTT ingestion is handled by standalone process mqtt_worker.php.

JSON Payload Structure Used in Runtime

Simple view: payload is "package content" carried from ESP32 to server. It contains primary sensor data and additional fields for network-quality diagnostics.

Technical view: firmware payload builder (fillProtocolPayload()) always emits required telemetry fields plus diagnostics such as RSSI, TX duration, payload bytes, and send success/fail counters.

{
  "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
}

Step-by-Step Explanation for Each Metric

This section is intentionally two-layered: first paragraph for non-technical understanding, second paragraph for technical accuracy based on code.

Latency Calculation Mechanism

Both HTTP controller and MQTT worker use the same latency formula.

// 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));

• Latency value is stored in eksperimens.latency_ms.
• Absolute value (abs) is used, so negative clock drift becomes positive magnitude.
• Model accessor in Eksperimen also returns absolute latency_ms.

Power Calculation Mechanism (daya_mw)

Power is estimated inside firmware (estimateProtocolPower()) and sent as field daya. Backend stores it as 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 and MQTT have different protocol overhead values (HTTP is higher).
• Penalty increases as fail ratio rises (httpSendFail/mqttSendFail).
• Transmission duration, payload size, RSSI, and environment deltas affect the estimate.
• Formula is deterministic (current firmware path uses no random baseline).

Packet Delivery Ratio (Backend Reliability)

The backend does not persist a separate field named PDR, but sequence reliability is calculated as received / expected * 100 and used in total reliability score.

// 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

Implemented in StatisticsService::tTest() for latency_ms and 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 uses denominator (n-1).
• Minimum requirement: each group must have at least 2 rows.
• Edge case standardError == 0 is handled explicitly (constant groups).
• p_value uses approximation function (normal CDF for large df, coarse bins for small df).
• Dashboard renders separate T-test panels for latency and power.

Real Examples from One Data Cycle

This section makes research numbers easier to imagine. Example numbers below follow the same formula pattern used in runtime code.

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

Why Was This System Designed This Way?

Database Structure and Table Relations

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)

Query examples (runtime troubleshooting)

-- 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';

Flow: Data Ingest to Dashboard Rendering

Simple view: after data is saved into database, the system transforms it into concise numbers so users can quickly see which protocol is faster, more power-efficient, and more stable.

Technical view: DashboardController::index pulls protocol data from telemetry model, calls StatisticsService for summary/reliability/t-test, prepares chart payloads, then sends all results to resources/views/dashboard.blade.php.

1. ESP32 sends HTTP and MQTT payloads with full telemetry fields.
2. HTTP path enters ApiController; MQTT path enters mqtt_worker.php.
3. Both paths compute latency and perform idempotent upsert into eksperimens.
4. DashboardController@index fetches MQTT and HTTP samples (analysis window: 50, chart window: unlimited).
5. StatisticsService computes summary stats, reliability, and T-test.
6. Dashboard view renders metric cards, warning list, diagnostics panel, latency chart, power chart, and statistical analysis section.
7. Frontend auto-refresh updates cards, charts, and diagnostics periodically.

Validation Used by Backend Statistics and Ingest

System Limitations (Based on Current Code)

• p_value in T-test uses approximation, especially coarse for small df.
• Critical value is fixed at +/-1.96 in code, not dynamically adjusted by df.
• daya_mw is a firmware-side estimate, not direct electrical sensor measurement.
• Latency depends on ESP32 clock validity; NTP drift or unsynced epoch affects metric quality.
• Sequence reliability uses segmentation rules (reboot/jump handling), so very large jumps become new segments instead of continuous loss.
• MQTT ingestion depends on standalone worker process availability; if worker is down, MQTT telemetry is not persisted.
• This documentation is implementation-bound; update this page whenever telemetry schema, formulas, or runtime paths change.

Glossary / Glossary

Each term is written in two layers: simple explanation for general readers, followed by technical explanation based on actual repository implementation.