📊 Analysis Report Guide

Real-Time Energy Monitoring & Insights
📖 Overview

The Analysis page shows the report produced by the Analysis Engine — a single structured summary of grid quality, load, power factor, energy, system state and detected patterns, plus an overall Health Score. All thresholds and wording behind this report are configured on the Rules page.

Run / Refresh
1
▶ Run Analysis — triggers a fresh analysis over the current lookback window. The analysis runs in the background on the device — for a long lookback window this can take a few minutes rather than being instant — and the button shows a live "Running… Xs" status until it's done, when the new report appears automatically. This is the only way to get up-to-date results; nothing runs on a schedule without you pressing it.
2
↺ Refresh — reloads the last saved report without recalculating anything. Useful for coming back to a report you already generated, or after saving new rules but before you're ready to re-run.
If no analysis has ever been run, an error banner reads "No analysis result yet" — click Run Analysis to generate the first report.
Section headers

Every section below (Insights, Events, Grid, Load, …) can be collapsed by clicking its header — handy once you know what you're looking for and just want the Health Score and any alerts at a glance.

Color key
Good / Excellent / Stable Marginal / Warn / Fair Poor / Alert / Unstable / Critical Acceptable / Info No data
📜 Health Score

A single 0–100 number summarizing the whole period, shown in the circle at the top of the report.

Score & level
The number and its color-coded label — Excellent, Good, Fair or Poor — based on the level thresholds set in Rules → Health Score.
Delta
Small +N / −N next to the score, comparing this run to the most recent earlier report that is at least 6 hours old. Hover it to see the previous score and the date it was compared against. Running the analysis again right away will not show a delta — there is no qualifying earlier report yet, and that is expected, not a bug. The delta also disappears after any change that affects how the score itself is calculated — the component weights, the penalties, the detection thresholds, or the analysis period — and after an update to the analysis engine: scores produced under different rules are not comparable, and showing the difference between them would present a change of settings as a change in the grid. Changing the Excellent/Good/Fair level labels or their colour thresholds does not affect this — those only change how a given score is displayed, not the score itself, so the delta keeps comparing normally.
Components
Six colored markers — Voltage, PF, Load, Trend, Anomaly, Data — each showing that component's own 0–100 score, so you can see at a glance which one is dragging the total down.
Score deductions
Red markers below the component row — one per penalty actually applied (voltage alerts, voltage warnings, sustained low power factor, overheating), each showing how many points it took off. Voltage penalties are calculated from how many such events fall on an average day, not from their raw count over the period: previously a grid of identical quality collected three times the penalty on a 90-day report as on a 30-day one, and scores taken over different periods could not be compared with one another at all. The rate is measured against the data actually held in the database rather than against the analysis window you asked for, so a fresh installation is not handed an artificially low rate merely because Lookback days reaches further back than it has existed; a window shorter than a day counts as a day. The penalty for sustained low power factor takes the same threshold as the recommendation of the same name — Low duration warn (%) in Rules → Power Factor, still 10% by default — and moves with it. Penalties below half a point are not shown at all: a −0 marker would carry no information. The row is hidden when nothing was deducted.
Penalty caps
Two ceilings apply, and they apply in order. Each class of penalty first meets its own limit — Voltage alert cap and Voltage warning cap in Rules → Health Score, 25 and 10 by default — and only what survives that goes on to meet the overall limit on the sum of everything, Penalty cap. An amber marker then reads capped: −N of −M — the sum that was applied against the sum before any limiting — so the number in the circle is always accounted for. It appears whichever of the two ceilings did the work.
💡 Recommendation
A single actionable sentence, usually pointing at the lowest-scoring component and what it means in practice.
💡 A help icon sits beside the Health Score block in the app. It opens About the Health Score — a short explanation of the score, its components, the penalties and the delta — on the spot, without sending you anywhere else.
Key Insights

Short, plain-language cards summarizing the most notable findings of the run — one card per insight, colored by severity.

Positive Warn Alert Info

Empty state: "No analysis data yet" before the first run.

📜 Events

A log of the discrete events detected during the period — voltage sags/swells, load bursts, energy anomalies, data gaps, high temperature, and more. The list is ordered by severity first and, within one severity, newest first, so alerts stay at the top instead of being buried under older informational rows. Filter chips above the list narrow it to one type — Voltage, Load, or Energy — without changing that ordering or the counts shown elsewhere.

Severity dot
Red = alert, yellow = warn, blue = info — matches the same color key as everywhere else in the report.
Type, text, timestamp & duration
Each row shows the event type (e.g. voltage sag), the generated message text, when it started, and how long it lasted. The EVT_ identifiers follow that same order, so EVT_001 is the first row you see rather than the earliest event of the period.
Grid Quality
Avg Voltage
Average voltage for the period, with Min, Max, Std Dev and CV (coefficient of variation) shown below it.
Out of Range
The total number of voltage events recorded in the period, broken down below into Sags and Swells, each with its alert-severity share in brackets. Time out of range is the share of covered time spent outside the warn/alert thresholds — it is measured against the time actually recorded, so data gaps do not dilute it. An event is counted only once it has lasted at least the Sag min duration / Swell min duration set in Rules, so this card and the Events list always agree.
Voltage Spread (CV)
A status badge — stable, marginal or unstable — based on the CV thresholds set in Rules. It describes how widely voltage is scattered around its own average across the whole period, and nothing else.
Source Impedance
The resistance of the path from the transformer to your meter, in ohms, estimated from how far the voltage moves when your own load switches on and off. It answers the one question the cards above cannot: whether a sag arrived from the grid or was created inside your own installation. Roughly 0.3–0.8 Ω is normal; above 1.5 Ω the drop is no longer explained by an ordinary supply and the cause is likely a loose terminal, a corroded lug or undersized cable on your side. Spread and Samples below it describe how trustworthy the figure is — a spread comparable to the value itself means the reading is reported as insufficient data rather than guessed at.
💡 These two cards measure different things and can legitimately disagree. Voltage Spread is a period-wide statistic, so brief excursions barely move it: a hundred one-minute sags across a month amount to a fraction of a percent of the samples and leave CV almost unchanged. A reading of stable alongside a high event count is not a contradiction — it means your voltage sits calmly most of the time but does step outside the thresholds now and then. Read Out of Range for compliance with your limits, and Voltage Spread for how steady the supply is between those excursions.
Sag Timing
When sags happen, rather than how many. The bars show what share of each hour of the day was spent below the warning threshold, and the headline gives the three-hour window where they cluster most densely, highlighted in the chart. In window is the share of all below-threshold time falling inside it; Vs average is how much denser that is than an even spread across the day — anything from 2× upwards is reported as clustered. Hours are counted in your billing timezone, and a window may cross midnight.
💡 Source impedance turns those two readings into a decision. Multiply it by your own peak current to see how much of a sag you could possibly have caused: at 0.4 Ω and a 13.5 A peak that is about 5.4 V, so a supply arriving at 211 V would still read 206 V at your terminals, while a supply arriving at 230 V could never reach the sag threshold no matter what you switch on. If the sum falls short of your sags, the cause is upstream and there is nothing to tighten in your consumer unit. The figure is also worth checking every few months on its own: a value that drifts from 0.4 to 0.9 over a year is a connection beginning to degrade, visible here long before it announces itself any other way.
💡 Sag timing points at who is causing the drop. A tight evening cluster is the signature of a shared line under load: your neighbours switch on the same appliances at the same hour, and voltage falls for everyone on the feeder. An even spread across the day is not the reassuring result it looks like: a spread out verdict alongside a high sag count means the cause does not follow the daily consumption cycle at all, and something is dragging your voltage down around the clock — the state of the line itself, a long feeder, or an undersized transformer. A cluster at least switches off for most of the day. Read it together with source impedance: a low impedance with a sharp evening cluster is a network problem at peak, while a high impedance with sags scattered through the day points back at your own installation.
📈 Load Analysis
Average Load
Mean power draw over the period, in watts.
Peak (P95)
The robust 95th-percentile peak, with the absolute maximum shown as a secondary line beneath it.
Base Load
The robust 10th-percentile estimate of your always-on / idle consumption.
Profile
A badge such as morning peak or evening peak when a daily consumption pattern is detected, plus the percentage change in average load versus the previous period.
🔌 Input Capacity

Tracks how close your load runs to the limits of your own supply. The section stays empty until you enter a breaker rating or a contracted power in Rules → Input Capacity, because those figures describe your installation and cannot be guessed.

Peak Current
The highest current seen in the period, with the configured breaker rating below it and that peak expressed as a percentage of the rating. The status reads within limits while the peak stays clear of the rating, near limit once it reaches 90% of it, and exceeded if any event was recorded. The Out of Range row counts those events, with the alert-severity share in brackets.
Peak Power
The same reading against your contracted power. Note that this is deliberately the absolute maximum, not the P95 shown in Load Analysis: there the question is what level your load reaches routinely, so a single spike is noise; here the question is whether you crossed a limit at all, and a single spike is precisely what is being looked for.
Time out of range
The share of covered time spent past either limit. It counts only the minutes genuinely above the threshold — not the tail that hysteresis keeps an event open for — so raising the hysteresis setting merges events without inflating this figure. Measured against the time actually recorded, so gaps in the data do not dilute it.
These events cover thermal overloads only. Inrush from a compressor or pump lasts a second or two and never reaches the database, since the relay reports about once a minute — yet that is exactly what trips a breaker on its magnetic release. A quiet section here is not a promise that your breaker will hold.
💡 Capacity events are deliberately kept out of the Health Score. Exceeding a contracted limit is usually a matter of routine rather than an anomaly — an evening water heater produces it daily — and something that fires every day would look to the event-rate component like a steadily high anomaly rate, when nothing anomalous is actually happening. What matters here is the status in this section, not a silent deduction elsewhere.
📉 Power Factor
Average PF / Minimum PF
Mean and lowest power factor recorded over the period.
Below 0.70
Percentage of the period spent below the "poor" power factor threshold (threshold itself configurable in Rules).
Assessment
A status badge — good, acceptable or poor — plus a guessed load type (e.g. resistive vs. inductive) where the engine can infer one.
Reactive Energy
How much energy travelled back and forth between your home and the transformer over the period without doing any work, in kvarh. Nothing here needs acting on, and nothing is being charged for it — domestic tariffs bill active energy only, and this figure is included because it is interesting, not because it costs you anything. It is calculated as P × tan(arccos(pf)) integrated over time, skipping readings below 50 W where the power factor is mostly noise. The device does not report the direction of phase shift, so inductive and capacitive loads are summed together rather than distinguished.
💡 What a kvarh actually is. A var is the unit of reactive power, and a kvarh is a thousand of them held for an hour — the same construction as a kilowatt-hour, applied to a different quantity. Watts measure power that becomes work: heat, rotation, light. Vars measure power that flows into the load and straight back out again twice per cycle, because coils and capacitors store energy in a magnetic or electric field and then return it to the grid. Over a full cycle no work is done, yet the current is real and heats the wiring just the same. The two do not add up: they combine as the sides of a right triangle, S² = P² + Q², so 450 kWh alongside 112 kvarh is not 562 of anything. Industrial customers are billed for this, since reactive current occupies network capacity without generating revenue. Domestic meters count watt-hours only, which is why the number here stays a curiosity.
🔋 Energy Consumption & Forecast
Total
Total energy consumed over the whole period, in kWh.
Daily Avg
Average daily consumption, with the minimum and maximum single-day totals shown beneath it.
Trend
A badge — ↑ Rising, ↓ Falling or → Stable — with the slope in kWh/day, based on the Rules → Energy trend thresholds.
Forecast
Tomorrow / Next 30 days
Predicted consumption for the next day and next month, each with a min–max range below the headline number.
Confidence
The confidence interval percentage used for the forecast's range, as set in Rules → Forecast.
💡 The forecast block only appears once enough history has accumulated to satisfy the Window days setting in Rules → Forecast.
🌡 System State
Temperature
The relay's onboard temperature reading, with a status badge if it crosses the warn/alert thresholds set in Rules → System State.
Frequency
Grid frequency as reported by the device's system state, with a stability status badge.
💡 Both readings in this section describe this moment rather than the whole period. The device keeps no history for either, so they show the state of the relay when you pressed Run Analysis — not whether it ever overheated or the frequency ever drifted during the days covered by the rest of the report.
🔍 Detective Engine

Cards describing recurring daily patterns (e.g. a load spike that happens most evenings) and cause-effect correlations (e.g. voltage dropping whenever load surges past a certain point).

Pattern text
A plain-language description of what was found and when. A recurring peak load reads as "between HH:MM and HH:MM consumption regularly rises above N W", with the threshold rounded to the nearest ten watts so the sentence stays readable.
Confidence & occurrences
A confidence percentage with a small bar, and how many times the pattern was observed — both driven by the thresholds in Rules → Detective Engine.
💡 The window searched for patterns is set separately, by Pattern lookback days in Rules → Detective Engine (14 days by default), and does not follow the analysis period. That is why the number of days a recurring pattern is measured against stays put when you change the period of the report itself.

Empty state: "No patterns or correlations found."

💾 Data Coverage

Technical detail about how complete the underlying data was for this report — worth checking whenever a result looks off.

Period / Data points / Completeness
The number of days covered, how many data points were collected versus how many were expected, and the resulting completeness percentage.
Data gaps / Engine / Rules
The number of data gaps found, plus the Analysis Engine and Rules file versions used to generate this specific report — useful when comparing reports generated before and after a Rules change.
Gaps list
When gaps exist, each one is listed with its start → end timestamps and duration in minutes.