Smart Power Monitor

What the numbers mean

1 kWh = one “unit” on your electricity bill = a 1000 W load running for one hour.

Slab tariff

A slab is a price band. Instead of one flat rate, the utility charges more per unit as you consume more. The default tariff here:

“Telescopic” means the rates stack. At 250 units you do not pay 250 × ₹6.00. Each band is charged at its own rate:

first 100 units x Rs 3.50  =  Rs  350.00
next  100 units x Rs 4.50  =  Rs  450.00
next   50 units x Rs 6.00  =  Rs  300.00
                              -----------
energy charge              =  Rs 1100.00
+ fixed charge                Rs   50.00
+ 5% tax                      Rs   57.50
                              -----------
total                         Rs 1207.50

Edit the bands in Settings → Tariff & Billing. Leave “up to” empty on the last row to mean “and above”. If your utility charges one flat rate, untick Use telescopic slab tariff.

Fixed charge & tax

The fixed charge is billed every period regardless of consumption — even at zero units. It covers the meter, the line to your premises, maintenance and billing admin. Your bill may call it fixed charge, demand charge, service charge or minimum charge.

Tax applies to the subtotal, so the fixed charge is taxed too:

subtotal = energy charge + fixed charge
tax      = subtotal x tax%
total    = subtotal + tax

Many states scale the fixed charge by sanctioned load (e.g. ₹50 per kW, so a 3 kW connection pays ₹150). This app uses one flat figure per period — enter the already-multiplied amount. Set it to 0 if your tariff has none.

Consequence: at zero consumption the bill still shows ₹52.50, not ₹0. That is correct — it is what the utility would charge.

How the prediction works

No AI, no trained model. It is a simple moving average with linear extrapolation — a deterministic, closed-form calculation over your own recorded history.

Notation

Formula

1.  units so far
    E_used = SUM( E_i )   for i = s .. d

2.  baseline daily rate - mean of the last 7 COMPLETE days,
    clipped so the window never starts before the period
    W = [ max(d - 7, s) , d - 1 ]
    Ebar = SUM( E_i for i in W ) / |W|

3.  extrapolate over the days that remain
    N_left = |P| - (d - s + 1)
    E_proj = E_used + Ebar * N_left

4.  price it with the same tariff as the real bill
    Bill_pred = T( E_proj )

Today is excluded from the window because it is still in progress and would drag the mean down.

Cold start (first day of a period)

There is no complete day yet, so today's partial usage is scaled up by the fraction of the day elapsed:

f    = (3600*h + 60*m + s) / 86400
Ebar = E_today / f          only when f > 0.02

The f > 0.02 guard (about 29 minutes) stops a near-zero denominator producing an absurd figure.

Why it cannot just scale the current bill

Because T is piecewise-linear and increasing, T(E_proj) is not T(E_used) × E_proj/E_used. Going from 190 to 210 units costs more per unit than going from 90 to 110. The projected unit count has to go through the slabs — you cannot multiply the current bill by a ratio.

Properties

• Deterministic — same inputs, same output. Nothing to train or persist.
• O(1) — two indexed SQL aggregates, no iteration.
• Self-correcting — as the period ends N_left approaches 0, so the estimate converges onto the real bill. Error is largest at the start of a period.
• Assumes stationarity — a flat unweighted mean assumes the coming days resemble the last 7. It cannot anticipate the first hot week of summer, guests, or a holiday.
• Weekday-blind — a Mon–Fri window projected across a weekend will be off if weekend usage differs.

Improvement path, all still closed-form: weighted moving average (recent days weighted higher) → weekday/weekend segmentation → same-month-last-year seasonal comparison. None of these need machine learning.

Billing periods & automatic billing

A period runs from your configured billing day to the day before the next one. With billing day 15, a period is 15 Aug → 14 Sep. With billing day 1 it is simply the calendar month.

Consumption is accumulated per local day from the Pico's cumulative energy counter, stored as deltas — so a device reboot does not double-count, and a counter reset is detected and handled.

• Current estimated bill — units used so far, through the slab tariff.
• Predicted bill — projected units, through the same tariff.
• Automatic billing — on the first day of a new period the previous period is billed and the invoice e-mailed. Toggle it in Settings.

Every bill is viewable at /bill/<id> (printable) and can be re-sent from the Billing tab.

Alerts

Each type has its own cooldown, so a sustained fault sends one e-mail per cooldown window rather than one every two seconds. Alerts appear as a toast, in the Alerts tab, and by e-mail if enabled.

Hardware

What the device LCD shows

The 16x2 display cycles through three pages, one every 3 seconds:

V:231.4 I:2.15
P:480.2W PF:0.96

Energy:1.234kWh
Cost: 4.32

WiFi OK  -58dB
192.168.1.77

The cost on page 2 uses the ₹/kWh rate the server pushes back with every telemetry reply — change the tariff here and the LCD follows within seconds. Other states: WiFi lost / Reconnecting..., Zero calibrating, Rebooting....

Calibration

1. Zero the current sensor. With no load connected, press Calibrate zero on the Dashboard. This also runs automatically at boot.
2. Voltage. Measure real mains with a multimeter, then adjust VCALIBRATION in main.ino: new = old × (measured / displayed)
3. Current. Run a known load such as a 100 W bulb and adjust ICALIBRATION the same way against a clamp meter.

Trim the ZMPT101B's on-board pot until its output sits near 1.65 V with no clipping before calibrating voltage.

API

Set DEVICE_TOKEN in .env to require the Pico to send a matching X-Device-Token header on /api/telemetry. Off by default.

Data & retention

• The Pico posts telemetry every 2 seconds; the browser receives it live over a WebSocket.
• A reading is written to the database every 30 seconds for the history graphs, and pruned after 14 days.
• Daily totals, alerts and bills are kept indefinitely.
• Everything lives in power_monitor.db — back that one file up.