IoT Energy
Monitoring high-voltage transmission lines — from field sensors to one platform
A North American manufacturer of power line hardware needed a platform that turns the sensors it installs on high-voltage conductors into something grid operators can act on. Cloudnonic built it end to end in 2026: ingestion, data plane, API, web application and the AWS infrastructure underneath, with one engineering team.366+
Field devices registered on the platformAccelerometers, IMUs, weather stations and more21+
Transmission lines monitoredFor utilities in North America and Europe13+
Utilities and partners with their own tenantEach with its own users, roles, lines and alerts5+
Sensor types with their own processing chainFrom raw payload to engineering indicatorsYear2026 – Present
LocationUnited States
Tech StackFastAPI · React · PostgreSQL · AWS Lambda · Terraform
Project ScopeCloud infrastructure · Platform engineering · Full-stack development · Data and analytics
The problem
The client makes the hardware that holds up high-voltage lines: clamps, dampers, spacers. Over the years it added sensors to that hardware — accelerometers and inertial units on the conductor, bending-strain gauges, weather stations on the structures — so utilities could see how a line behaves in wind, ice and load.The sensors worked. What was missing was the platform behind them. Data reached the gateways and stopped there; every utility was a separate installation, and there was no single place to see fleet health, line status or an alert when a conductor started to move outside its limits.The brief was a product, not a project: multi-tenant from the first day, white-labelled so the manufacturer could sell it under its own brand, and able to absorb waveform payloads from hundreds of devices without losing a sample.What we built
A web application where lines, spans and assets live on a map, with every device clamped to a span and its connectivity state visible at a glance. Organizations, users and roles give each utility its own tenant; rules and alerts tell the right people when a reading crosses a threshold.On top of the raw data sit dashboards per sensor family: accelerometer indicators with X, Y and Z waveforms and their FFT spectra, bending-strain analysis, conductor and damper motion, weather-station readings, and a fleet-wide system health check. Each dashboard is filtered by organization, line, asset and device, and every chart exports.The application is translated, themeable and served as a static single-page app behind a CDN, so a new utility is a configuration change rather than a deployment.Ingestion built for bursts
Field gateways do not stream; they wake up, push a batch of several megabytes and go quiet. The ingestion path is serverless for exactly that reason: an HTTP API and an MQTT bridge accept the batches, Lambda functions validate and split them, and FIFO queues hand each sensor type to its own processing chain with a dead-letter queue and replay for anything that fails.Raw waveform payloads are archived as they arrive, partitioned by hour, so any indicator can be recomputed later from the original samples. Processed readings land in a PostgreSQL data plane partitioned for time series, read by the API through a dedicated role.Calibration lives in the catalog of each device type, and adding a new sensor model means a new entry and a processing chain — not a new platform.Owning the infrastructure
Everything runs on AWS and is defined in Terraform: the network, a Fargate cluster for the FastAPI core, RDS PostgreSQL and Redis in private subnets, Cognito with multi-factor authentication, KMS keys, Secrets Manager with rotated database roles, and CloudFront in front of the application.Each repository releases on its own cadence with a generated changelog, environments are isolated, and the client signs off on staging before anything reaches production. After go-live the platform runs under a maintenance agreement with a defined service level.How we work with the client
The engagement runs on a shared planning repository: domain model, architecture decisions, standards and a backlog the client can read. Decisions are recorded as they are made, so a reviewer six months later finds the reasoning, not just the code.Cloudnonic owns engineering across the four repositories — frontend, core API, ingestion and infrastructure — while the client owns product direction, acceptance and the commercial relationship with the utilities on the platform.Outcome
- Hundreds of field devices on more than twenty transmission lines reporting into one platform
- Vibration waveforms turned into indicators a line engineer reads in seconds
- Multi-tenant from day one: each utility sees only its lines, devices and alerts
- White-labelled, so the manufacturer sells the platform under its own brand
- Raw payloads archived by the hour and reprocessable at any time
- Staging sign-off per release and a maintenance agreement after go-live