Meter-Reading and Outage-Reporting Field App for an Electricity Section Office (Flutter)

GridMeter is an offline-first mobile application plus a small section-office server that digitises the two things an urban electricity section office in Karnataka still does on paper: the monthly meter-reading round and the outage complaint register. Meter readers walk hundreds of consumer premises every billing cycle, writing kWh readings in a notebook; clerks later type them into the billing system, and every transcription is a chance for a wrong bill. Outages reach the office as phone calls that a lineman writes into a register, so restoration times and reliability figures are nobody's responsibility.

The Flutter app gives each meter reader a daily route of consumers. A reading is captured with the meter photo, GPS fix and timestamp, stored first in a local SQLite database (drift), and flagged automatically when it looks wrong — zero consumption after months of usage, or a spike beyond three times the three-month average. Linemen open, assign and close outage tickets through a simple lifecycle (Intimated → Crew Assigned → Restored), from which the system computes SAIFI and SAIDI per month. Everything queues in a sync engine and reaches the section-office server (Node.js/Express + MySQL) whenever the network returns; the clerk gets a web console for bill-file CSV export and anomaly review.

Flutter/Dart is an industry-standard cross-platform framework used here beyond the Android/Java core taught in 22MCA263; the backend uses exactly the JavaScript, DBMS and web-technology skills of the VTU MCA 2022 scheme, which makes the project easy to defend in the 22MCA44 viva.

Meter reading and outage handling in a small electricity section office are still paper processes. Readings recorded on round-sheets are transcribed at the office, producing wrong bills, late cycles and disputes that cannot be settled because no photo or location evidence exists. Outage complaints arrive by phone into a handwritten register with no status, owner or restoration time, so consumers call repeatedly and the section cannot compute the SAIFI and SAIDI reliability indices it is judged by. Field staff frequently work where mobile data fails, so any app that assumes connectivity fails exactly when it is needed. The section needs an offline-first mobile system in which readings and outages are captured once, at the point of work, with photographic and GPS evidence, validated by automatic anomaly rules, and synchronised safely to a section-office server that exports billing-cycle files and reliability reports — without storing Aadhaar or any other government identity number.

Abstract

This project builds an offline-first field application for an electricity distribution section office: meter readers capture photo-verified readings on a local SQLite store, linemen run outage tickets through a tracked lifecycle, and a sync engine reconciles everything with a Node.js/Express + MySQL server once connectivity returns. The clerk console exports billing-cycle CSV files and computes SAIFI/SAIDI reliability indices from outage data.

Introduction

Every Indian discom, BESCOM among them, bills consumers from monthly meter readings. In a typical section office serving 8,000–15,000 consumers, readings are still taken on paper round-sheets and re-typed at the office, so billing cycles start late and wrong bills lead to reconnections-for-dispute visits. Outages are reported by phone into a register with no status history, so consumers call repeatedly and reliability figures are reconstructed at month-end from dog-eared pages. Field staff work inside buildings, basements and rural pockets where mobile data is unreliable — which is why any field app for this domain must work fully offline.

Existing System and Its Limitations

• Readings are written on paper round-sheets, then keyed into the billing system by clerks — transcription errors, late billing, disputed bills.
• No photo or GPS evidence, so a contested reading cannot be verified.
• Outage complaints live in a phone-and-register workflow: no ticket status, no restoration timestamps, no accountability.
• SAIFI/SAIDI are computed manually at month end, if at all.
• Gap: utility-grade field suites target large discom IT departments and cost lakhs; nothing lightweight exists for a single section office to trial.

Proposed System

• A Flutter app with a drift/SQLite local store holds the reader's daily route, so a full day's round completes with zero network.
• Each reading captures value, meter photo, GPS fix and timestamp; anomaly rules (zero consumption, spike > 3x the trailing three-month average, backward reading) flag records for supervisor review before export.
• Outage tickets move through Intimated → Crew Assigned → Restored with timestamps, consumer callback notes and cause codes, giving real SAIFI and SAIDI per month.
• A sync engine queues every local mutation, uploads with idempotency keys, retries with exponential backoff and resolves conflicts by a documented rule (server-verified reading wins; consumer master edits are last-write-wins with an audit row).
• The Express + MySQL server exposes role-based REST endpoints (reader, lineman, clerk, admin) and a monthly bill-file CSV export that plugs into the existing billing process instead of replacing it.

Feasibility Study

• Technical: Flutter compiles one Dart codebase to Android (and iOS later); drift gives type-safe SQLite with stream queries; Express + MySQL is the same stack taught in 22MCA24/22MCA21. The sync design needs no exotic infrastructure.
• Economic: Zero licence cost. The server runs on the office's existing PC; phones are the readers' own handsets (Android 8+).
• Operational: The reading screen is one thumb-reachable form; a reader trains in 20 minutes. The office keeps its billing system — the app feeds it data — so adoption risk stays low.

In scope

• One section office with multiple readers and linemen; Android 8+ phones; 8,000-consumer-scale data.
• Daily route assignment, reading capture (value, photo, GPS, timestamp), anomaly flagging and supervisor clearance.
• Outage ticket lifecycle with cause codes, restoration timestamps and monthly SAIFI/SAIDI computation.
• Offline mutation queue with background sync, retry and conflict handling; full audit table of every synced change.
• Clerk web console: consumer master, route management, bill-file CSV export, anomaly review, reliability report.

Out of scope (v1)

• Prepaid and smart-meter protocols (DLMS/MDM integration) — readings arrive manually in v1.
• Online payment collection and the discom's core billing engine (the CSV export feeds it instead).
• iOS build and push notifications (WhatsApp/SMS fan-out to consumers is a listed future item).
• Transformer/feeder-level asset management beyond the cause-code field.

The project follows the iterative and incremental SDLC model: a thin end-to-end slice (capture one reading, sync it, see it in the console) exists by week 6, and every later increment thickens it. For a system whose hardest problem — offline synchronisation — is discovered only through use, incremental delivery with a working demo every fortnight beats a single-shot waterfall.

Testing approach: unit tests for the anomaly rules, SAIFI/SAIDI arithmetic and conflict resolver (pure Dart, flutter test); widget tests for the reading form; Mocha/Chai API tests including duplicate idempotency keys and role abuse; and a scripted field test that walks a route in airplane mode, restores the network mid-round and verifies that exactly one copy of every reading lands in MySQL.

The system is a three-tier architecture with an explicit offline-first layer inside the mobile tier — the design decision that defines this project.

1. Mobile tier (Flutter/Dart): widgets render from Riverpod state providers; a repository layer writes first to the local drift/SQLite store. The reading screen captures value, photo, GPS and timestamp in one gesture flow. Every mutation also appends a row to a local sync_queue table, and the workmanager-driven background worker drains that queue whenever connectivity returns.
2. Application tier (Node.js/Express): JWT-authenticated REST endpoints grouped by role. The sync endpoint accepts batches keyed by client-generated idempotency keys, deduplicates them, applies server-side validation (anomaly rules, route ownership) and records every accepted change in a server-side sync audit table.
3. Data tier (MySQL 8): normalised schema for users, routes, consumers, readings, outage tickets, bill runs and the sync audit; InnoDB transactions wrap bill-file generation.

flowchart TD
  R["Reader / lineman phone"] --> W["Flutter widgets (Riverpod state)"]
  W --> RP["Repository layer"]
  RP --> LDB[("Local drift/SQLite store")]
  RP --> SQ["sync_queue table + workmanager worker"]
  SQ -->|"HTTPS + JWT, batched, idempotent"| API["Express REST API"]
  API --> MW["JWT verify + role middleware"]
  MW --> SV["Sync service: dedupe, validate, audit"]
  SV --> DB[("MySQL 8")]
  CL["Clerk web console"] --> API
  SV --> CSV["Bill-file CSV + SAIFI/SAIDI reports"]

ER diagram

erDiagram
  USER ||--o{ READING : records
  CONSUMER ||--o{ READING : "is read in"
  ROUTE ||--o{ CONSUMER : groups
  CONSUMER ||--o{ OUTAGE_TICKET : reports
  USER ||--o{ OUTAGE_TICKET : resolves
  BILL_RUN ||--o{ READING : consumes
  USER ||--o{ SYNC_AUDIT : "changes tracked for"

  USER {
    string id PK
    string name
    string role
    string passwordHash
  }
  ROUTE {
    string id PK
    string name
    date assignedDate
    string readerId FK
  }
  CONSUMER {
    string id PK
    string rrNumber UK
    string name
    string address
    string routeId FK
    string mobile
  }
  READING {
    string id PK
    string consumerId FK
    string billRunId FK
    decimal unitsKwh
    string photoHash
    decimal latitude
    decimal longitude
    datetime takenAt
    string anomalyFlag
    string status
  }
  OUTAGE_TICKET {
    string id PK
    string consumerId FK
    string status
    string causeCode
    datetime intimatedAt
    datetime restoredAt
  }
  BILL_RUN {
    string id PK
    string cycle
    date exportedAt
  }
  SYNC_AUDIT {
    string id PK
    string idempotencyKey UK
    string entity
    datetime appliedAt
  }

Outage ticket state machine

flowchart LR
  I["Intimated"] --> CA["Crew Assigned"]
  CA --> FB["Field Visit"]
  FB --> RS["Restored"]
  FB -->|"cause needs senior"| ES["Escalated"]
  ES --> RS

The consumer master deliberately stores only the RR (revenue register) number and mobile number — never Aadhaar, PAN or bank details — so a stolen backup leaks nothing sensitive.

• Meter-photo OCR to auto-read the register digits and cross-check the typed value.
• Smart/prepaid-meter ingestion (DLMS/MDM) so readings arrive automatically and the app becomes exception-only.
• Consumer-facing outage updates over SMS/WhatsApp with ticket status and expected restoration time.
• Route optimisation so the daily round follows the actual street sequence instead of the register order.
• Payment-link generation against disputed bills and a multi-section SaaS deployment with a central discom dashboard.