Making the Telemetry Pipeline Measurable: An Edge IoT Testbed and Dataset for End-to-End Latency, Provenance, and Energy-Aware Benchmarking

• IoT evaluation often lacks real-world data early in design, while synthetic traces rarely capture pipeline timing, mediation effects, or edge energy use.The pipeline is commonly treated as an opaque conduit rather than a measurable object.Source: §1 · pp. 1–2
• Datasets and testbeds often omit event provenance and stage-level timing, while reporting energy separately from telemetry collected in the same windows.The paper frames timeliness and energy as functional edge constraints, not secondary attributes.Source: §1 · p. 2
• The contribution is an integrated engineering artifact, not a new messaging protocol, latency attribution method, energy attribution model, or provenance mechanism.The demonstrated deployment measures indoor environmental conditions and does not validate agricultural, healthcare, or industrial applications.Source: §1 · p. 2
• The artifact combines a role-based edge testbed, stage-level telemetry metadata, aligned energy measurements, and a reproducible dual-format dataset workflow.Raw Avro events and curated, partitioned Parquet tables are produced through a deterministic transformation pipeline.Source: §1 · p. 2

Design goals and academic testbed requirements

• Academic and large-scale testbeds emphasize repeatability, heterogeneity, openness, and broad experimentation, while this work emphasizes measurement discipline at the edge.The cited examples include smart-building and city-scale facilities.Source: §2 · p. 3

Low-cost, minimalistic, and remotely accessible testbeds

• Accessible and remote testbeds lower deployment and development barriers; this work instead foregrounds provenance, timeliness, and energy alignment as dataset features.The discussion contrasts its emphasis with minimalistic MQTT platforms and remote-access systems.Source: §2 · p. 3

Technology- and protocol-oriented measurement testbeds

• Technology-focused rigs characterize wireless performance, whereas this work instruments Source–Broker–Aggregator timing and message correlation across the telemetry pipeline.The comparison is complementary in scope, not a claim of measured superiority over other testbeds.Source: §2 · p. 3

Virtualized and emulated IoT environments

• Virtualized platforms emphasize programmable constraints or reproducible security experiments; this work pairs fine-grained timing and operational energy with raw and tabular data.The cited examples include IOTier and Gotham.Source: §2 · p. 3

Energy-aware and batteryless IoT testbeds

• Batteryless IoT work records and replays synchronized energy traces, while this testbed co-publishes plug-level consumption with telemetry and timing metadata.Its metering includes upstream consumption of compute-and-sense nodes, including adapter effects.Source: §2 · p. 4

Synthesis and gap addressed by this paper

• The paper targets joint release of fine-grained pipeline measurements, telemetry-aligned energy signals, and replayable plus analytics-friendly datasets.Its qualitative positioning claims differences in emphasis and artifact organization, not measured advantages in accuracy, efficiency, or scalability.Source: §2 · p. 4

3.1 Abstract Model

• An Edge Node must communicate and require power, and may provide perception, computing, or networking capabilities.The capability categories are not mutually exclusive; cloud and fog layers are outside the model's scope.Source: §3.1 · p. 4

3.2 Abstract Testbed Architecture

• The abstract testbed uses MQTT-based communication among gateway, sensing, actuating, brokering, and orchestration nodes to inspect data enriched with energy, timing, and provenance.The gateway routes network traffic; sensing nodes publish measurements, actuators consume events, brokers mediate messages, and computing nodes can aggregate or trigger actions.Source: §3.2 · pp. 6–7

• The testbed comprises seven edge nodes: three computing-and-perception nodes, three smart plugs, and one networking gateway.Each Raspberry Pi is powered through a dedicated Shelly Plug S, allowing per-node measurement that includes adapter and conversion losses.Source: §4.1 · p. 7
• Three Raspberry Pi 4 computers acquire and publish measurements from DHT11/DHT22, Enviro-board, and MCP9808 sensors while supporting local preprocessing.The Enviro board includes BME280 and LTR-559 sensors; the Raspberry Pis run Linux and provide GPIO and I²C interfaces.Source: §4.1 · p. 7
• Three Shelly Plug S devices provide switching and integrated power, voltage, and current metering for connected loads.The Sercomm H300S gateway connects all edge nodes for intra-testbed communication and backhaul access.Source: §4.1 · p. 7

4.2.1 Telemetry Message (schema)

• The TelemetryMessage envelope supports readings across contexts and embeds correlation identifiers plus scheduled and stage-level timing metadata.Readings can represent sensed, measured, or transformed values; contexts include physical sensors, virtual sensors, and software subsystems.Source: §4.2.1 · pp. 9–10

4.2.2 Broker

• Mosquitto on a Raspberry Pi uses a custom plugin to add high-precision message ingress and egress timestamps for tracing and provenance.The transport is MQTT.Source: §4.2.2 · p. 10

4.2.3 Source

• The Source schedules sensing cycles, assigns correlation IDs, transforms and Avro-serializes readings, then publishes the payload to MQTT.The scheduler triggers every five seconds, aligned to the Unix epoch.Source: §4.2.3 · p. 10

4.2.4 Device Manager

• The Device Manager registers sensors that initialize successfully, report support, and can be read; some sensors may repeat values when polled too frequently.The five-second polling interval is described as conservative for this testbed’s sensors.Source: §4.2.4 · p. 10

4.2.5 Aggregator

• The Aggregator consumes telemetry, validates and enriches deserialized messages, reserializes them, and persists the resulting Avro binary in SQLite.Periodic snapshots are transformed into tabular time-series data and stored as Parquet; the transformation supports reconstruction of TelemetryMessage objects.Source: §4.2.5 · pp. 10–11

4.2.6 Additional Details

• Raspberry Pi nodes can run Source and optionally Aggregator services, while computation-constrained Shelly devices implement only the Source role.Shelly devices use JavaScript timers with best-effort alignment to epoch boundaries.Source: §4.2.6 · p. 11

4.2.7 Timeliness

• Recorded stage timestamps are events rather than start/end pairs, so selected timestamp differences estimate intervals, not destination-handler execution time.Cross-node latency estimates also include relative clock error, and the capture reports no validated error bound.Source: §4.2.7 · p. 11

5 Testbed Demonstration

• The demonstration combines environmental measurements, node/OS monitoring, energy metering, and pipeline-stage timestamps in raw and curated tabular forms.It aims to document dataset contents and provide a reproducible first-pass exploration of recorded measurement characteristics.Source: §5 · p. 11
• The captured summaries describe one configuration and do not establish causal effects or performance bounds.The demonstration is explicitly descriptive, not a controlled characterization of the telemetry pipeline.Source: §5 · p. 11
• Message rate, payload size, MQTT QoS, subscriber count, broker/CPU load, and network conditions are not systematically varied.Source: §5 · p. 11

5.1 Dataset

• The dataset combines environmental, node/OS, electrical power and energy, and pipeline-stage telemetry in raw-event and processed-tabular representations.Both representations derive from the same TelemetryMessage envelope.Source: §5.1 · p. 12
• The raw-to-tabular transformation is deterministic and streaming, normalizing Avro records into readings_long and stages_long tables.The tables contain one row per message-context-metric and per message-stage, respectively; stage keys are event timestamps rather than start/end pairs.Source: §5.1 · p. 12
• The capture spans six devices across four dates and 71 date-hour partitions, and its exported readings are numeric with no missing active values.The OS/os case distinction encodes a platform boundary between Raspberry Pi and Shelly telemetry.Source: §5.1 · p. 12
• The released processed dataset contains 7,721,273 readings_long rows and 2,669,334 stages_long rows.Source: §5.1 · p. 12
• OS- and energy-related contexts dominate the dataset, while environmental sensor contexts occur less frequently, reflecting metric-cardinality and sensing-capability differences.The processed tables preserve raw event semantics for provenance and timeliness analyses while supporting efficient exploratory queries and reproducible benchmarking.Source: §5.1 · pp. 12–13

5.2.1 Windowed environmental signals (10-minute aggregates)

• The 10-minute windowed table contains 2,157 rows, and MCP9808 temperature means near the interval’s end cluster around 22.18–22.26°C.Windows frequently reach n = 120 at the nominal 5-second cadence; boundary windows have smaller sample counts.Source: §5.2.1 · pp. 13, 15, Table 2 · p. 13, Figure 4 · p. 13

5.2.2 Distribution of measurement contexts

• 7,721,273 samples span the contexts shown; OS contributes 4,893,702 (63.4%), while environmental contexts are less frequent, including BME280 at 148,260.OS and os intentionally distinguish Raspberry Pi OS telemetry from Shelly device telemetry, so case should be preserved when grouping.Source: §5.2.2 · p. 15, Table 3 · p. 15, Figure 8 · p. 15

5.2.3 End-to-end latency by device type

• 227.38 ms for ShellyPlusPlugSV2 and 83.51 ms for RaspberryPi are the estimated mean end-to-end latencies; p99 exceeds 500 ms for both device types.The end-to-end estimate refers to the instrumented telemetry path, with interpretation dependent on timestamp endpoints and clock limitations.Source: §5.2.3 · p. 16, Table 4 · p. 16, Figure 9 · p. 16

5.2.4 Stage-to-stage latency breakdown (RaspberryPi)

• 30.42 ms is the largest mean RaspberryPi inter-stage interval, ending at broker.ingress; source.transform has a 514.41 ms p99 despite a mean near 21 ms.Several intervals are sub-millisecond, including aggregator.deserialize at 0.025 ms mean.Source: §5.2.4 · p. 16, Table 5 · p. 17, Figure 10 · p. 17

5.2.5 Daily energy signature

• The three ShellyPlusPlugSV2 devices average approximately 0.0348–0.0378 kWh/day, with CV near 81%; these calendar-day aggregates include partial days.They are not normalized full-day consumption estimates, and observation coverage can contribute to the reported variability.Source: §5.2.5 · pp. 17–18, Table 6 · p. 18, Figure 11 · p. 18

5.2.6 Energy versus data volume

• Daily energy ranges approximately from 0.003 to 0.068 kWh/day across the displayed days, but the association with message counts is descriptive, not causal.The 2025-04-28 export has missing message counts despite small energy values; background node consumption is not separated from telemetry work.Source: §5.2.6 · pp. 18–19, Table 7 · p. 18, Figure 12 · p. 19

6.1 Implications of the observed dataset characteristics

• RaspberryPi messages average 83.51 ms end-to-end latency (median 60.66 ms), versus 227.38 ms (median 155.47 ms) for ShellyPlusPlugSV2; p99 exceeds 500 ms for both.The device-class differences are descriptive, not a controlled comparison of hardware or MQTT performance; latency tails can be analyzed by stage but do not establish root causes or isolate persistence cost.Source: §6.1 · p. 19
• For RaspberryPi telemetry, the largest mean intervals are broker.ingress (30.42 ms), source.transform (20.98 ms), and aggregator.initiate (13.66 ms); aggregator.deserialize averages 0.025 ms.These are intervals between recorded events, not handler execution times or measures of serialization, deserialization, or instrumentation overhead; source.transform has a p99 of 514.41 ms.Source: §6.1 · pp. 19–20
• OS accounts for 63.4% of samples, while environmental contexts occur less frequently, making context imbalance an analytic factor.The long-format view makes the skew visible and supports filtering, stratification, or reweighting; OS and os labels distinguish Raspberry Pi and Shelly sources.Source: §6.1 · p. 20
• Daily energy means for three Shelly devices cluster around 0.0348–0.0378 kWh/day, with CV near 81%; observed aggregates have unequal coverage.Message counts align with the configured 5-second schedule (17,280 messages/day), but 2025-04-28 has energy recorded while message count is missing; partial windows and workload or reporting variation may affect interpretation.Source: §6.1 · p. 20

6.2 Value of the dual representation and reproducible transformation

• The deterministic, streaming transformation co-releases replayable Avro events and partitioned Parquet tables, which can be reconstituted into TelemetryMessage objects.Raw events preserve message semantics for replay; the tabular representation supports exploratory analysis through predicate pushdown and time-based partitioning, allowing movement between systems-level inspection and data analysis.Source: §6.2 · p. 20

6.3 Limitations and threats to validity

• The capture covers three Raspberry Pi nodes and three smart plugs on one local gateway and broker; clock offsets and platform timestamp granularity are not independently quantified.Cross-node timing uncertainty is therefore unquantified, and results may differ with larger deployments, other network conditions, multi-hop links, or WAN/cloud paths.Source: §6.3 · p. 21
• Stage intervals are inferred from event timestamps along a fixed pipeline order, so they do not separate queueing, scheduling, transport, and handler execution or establish durable persistence latency.Plug readings include adapter losses and background node activity, exclude the gateway, and support temporal association rather than causal energy attribution; overhead and comparative validation are also unquantified, and identifiers do not provide authenticated provenance or a complete causal audit trail.Source: §6.3 · p. 21

6.4 Directions for extension

• Extensions proposed include explicit stage start/end timestamps, independent clock and meter calibration, overhead measurements, controlled workload variation, broader protocol and power diversity, and fog/cloud instrumentation.A diagnosis case study with a known fault is also proposed to assess practical diagnostic value.Source: §6.4 · p. 21

• The artifact co-releases heterogeneous telemetry with Source, Broker, and Aggregator stage timestamps, plug-level energy readings, and replayable Avro and analysis-ready partitioned Parquet views.The tabular views come from a deterministic transformation workflow.Source: §7 · p. 21
• The demonstrated dataset shows device-class separation in end-to-end latency, non-trivial tail behavior, stage-dependent variability, measurement-context skew, and energy summaries with data-volume co-variation.These observations characterize the released capture rather than validate a general latency or energy model.Source: §7 · p. 21
• The released corpus and analysis structure provide reusable inputs for subsequent benchmarking and diagnostic studies, but broader claims require controlled workloads, calibrated timing, overhead measurements, and concrete diagnosis cases.Source: §7 · p. 22
• Proposed extensions include explicit stage start/end timestamps, greater protocol and power diversity, and controlled stress conditions to examine distributional shifts under contention and loss.Source: §7 · p. 22