Utility monitoring portal
Substation
Transformer Monitoring Portal
Hourly transformer readings logged, queried and audited — instead of kept in a spreadsheet.
An hourly logging portal for substation power transformers: dissolved gas analysis, DTM and technical parameters across 27 fields and 24 slots a day, built on Next.js 16 and SQL Server.
- Substations
- 2
- Transformers
- 10
- Parameters in 3 groups
- 27
- Hourly slots per day
- 24
Runs on-site
Docker behind nginx
01Summary
A logging portal for substation power transformers. Engineers record dissolved gas analysis, DTM and technical parameters hour by hour across two substations and ten transformers — 27 parameters in 24 hourly slots per transformer per day — with site and transformer views, a dashboard, configurable parameters and a full audit trail. It replaces the spreadsheet the work was kept in.
- Hourly logging
- Configurable parameters
- Full audit trail
02The Problem
Transformer health was being tracked in a spreadsheet, which stops working at this scale:
27 parameters × 24 hourly slots × 10 transformers is where a spreadsheet starts losing readings.
Dissolved gas analysis shows trouble long before anything visible — but only if the trend is not missed.
Engineers need to look at one unit or one substation, not scroll one giant sheet.
Instrumentation changes, so the set of parameters cannot be a hardcoded form.
Regulated infrastructure needs an audit trail of who entered what, and when.
03My Role & Scope
End-to-end development, from architecture to deployment and ongoing production support.
- Hourly readingsReadings entered per transformer, per slot, across all 27 parameters.
- Site & transformer viewsLook at one transformer or a whole substation, plus a dashboard over the current state.
- Parameter administrationThe 27 fields are configuration, not a hardcoded form, because instrumentation changes.
- Users & auditRoles, password changes, a proper forbidden state and a full audit trail.
- SQL Server data layerKysely with tedious over JSON-backed reading columns, queried with ISJSON and JSON_VALUE.
- On-site deploymentDocker containers behind nginx, with compose files and a SQL Server setup script.
04Architecture
Server Components keep the client bundle to essentially the entry grid, and Server Actions remove a hand-written API layer that would only have talked to itself.
Engineers
Next.js 16
Auth & roles
Data access
SQL Server
05Key Features
Everything engineers need to log and review transformer health.
- Hourly entry gridAll 27 parameters for each transformer across 24 slots a day.
- Site & transformer viewsDrill into one unit or one substation.
- DashboardThe current state across both substations at a glance.
- Configurable parametersAdd or change fields as the instrumentation changes, without code.
- User administrationRoles, password changes and a proper forbidden state rather than a blank page.
- Audit trailEvery change recorded — for regulated infrastructure, the point rather than a nicety.
- JSON-backed readingsFlexible reading columns that SQL Server can still query inside.
- On-premises readyDocker, nginx and paths for a direct install or an existing reverse proxy.
06Engineering challenges & how I solved them
The technical choices, and why each one was forced.
The obvious ORMs could not do the job+
Symptom: The data had to live in SQL Server, and the readings table is backed by JSON columns.
Investigation: Drizzle has no SQL Server dialect at all, and Prisma cannot map a JSON column on SQL Server — both were out before the first line was written.
Fix: Used Kysely with tedious for type-safe queries, relying on SQL Server 2016+ ISJSON and JSON_VALUE to query inside the reading columns.
Authentication that works with SQL Server+
Investigation: Auth.js v5 was still in beta.
Fix: Chose better-auth for its first-class mssql support and admin plugin, covering roles and user administration.
Parameters that change with the instruments+
Fix: Made the 27 fields configuration rather than a hardcoded form, so adding or changing a parameter does not need a release.
Deploying to a box in a room, not the cloud+
Symptom: Substation IT is not a cloud environment.
Fix: Shipped as Docker containers behind nginx, with compose files, a SQL Server setup script and separate paths for a direct install or an existing reverse proxy.
A UI library detail worth writing down+
Fix: shadcn/ui on the Base UI build rather than Radix changes the component API — documented so it does not cost the next developer an afternoon.
Case study
The obvious ORMs could not do the job
Problem
The data had to live in SQL Server, and the readings table is backed by JSON columns.
Investigation
Drizzle has no SQL Server dialect at all, and Prisma cannot map a JSON column on SQL Server — both were out before the first line was written.
Solution
Used Kysely with tedious for type-safe queries, relying on SQL Server 2016+ ISJSON and JSON_VALUE to query inside the reading columns.
07Impact
What changed once readings left the spreadsheet.
- Substations
- 2
- Transformers
- 10
- Parameters in 3 groups
- 27
- Hourly slots per day
- 24
- The spreadsheet replaced by a portal that does not lose readings.
- Every reading for 10 transformers, 24 times a day, in one place.
- Parameters change with the instrumentation, without a code change.
- A full audit trail for regulated infrastructure.
- Runs on the substation's own hardware, not the cloud.
Next.js 16React 19Server ComponentsServer ActionsTypeScriptSQL ServerKyselybetter-authshadcn/uiTailwind CSS v4Dockernginx
Have a similar project?
Let's build something great together.
From shipping platforms to custom business tools — I can help turn your idea into reality.
- Free consultation
- Clear roadmap
- On-time delivery