Telemetry / Connected data platform

Making operational data agree with the device.

When dashboard values and meter readings disagree, fixing the chart is not enough. I worked through the pipeline, from incoming measurements to stored history, to make the operational view trustworthy.

My role
Data & platform engineer
Practice
Data engineering · IoT · Operations
Scope
Telemetry repair deployed

The context

Connected-device data becomes useful when people can rely on it to understand what is happening. In this project, scaling inconsistencies, missing history and corrupt readings meant the platform did not reliably agree with the devices.

The problem spanned acquisition, transformation, stored history and the latest values shown in dashboards. A correction at only one layer would leave the rest of the record inconsistent.

My contribution

  • Built and debugged telemetry bridge and historical backfill workflows between the broker and dashboard platform.
  • Corrected scaling on ingestion and repaired stored history against a defined cutover, avoiding repeated transformation of the same records.
  • Reconciled platform values with gateway and live device readings, and investigated competing publishers contaminating the data path.
  • Python
  • MQTT
  • ThingsBoard
  • Data transformation
  • Troubleshooting

The system, in view

  1. Device readingsSource measurements
  2. Ingestion & repairCorrect and reconcile
  3. Operational viewHistory and dashboards
Conceptual data path. Incoming data and stored history need consistent interpretation before they can support an accurate operational view.

The important decision

Repair the record without inventing a signal.

Correcting incoming measurements and stored history had to happen together. A defined cutover avoided transforming the same data twice. Genuine outages were kept as gaps rather than filled with invented flat readings, preserving the distinction between a measurement and missing information.

From design to implementation

The work combined a scaling stage in the telemetry bridge with recovery of historical measurements and transactions that had not reached the dashboard platform. Invalid points were removed rather than made to look like normal readings.

Reconciliation checked the platform against gateway records and independent live device reads. Investigating competing publishers helped explain why some values were still inconsistent even when an individual processing step appeared correct.

This case is a pipeline and historical-data repair. Wider platform database architecture is separate; the work is not presented as a completed database migration.

What the work established

Telemetry values reconciled with gateway and live device readings, covering ingestion correctness, historical recovery and the operational view.

The lesson

Data quality is a property of the entire path. A useful repair explains not only how new records are interpreted, but also how past records and genuine gaps should be understood.