Analysis: one selected period, one set of numbers, on every page

The dashboards told several stories at once. Overview asked for full
calendar years, meter detail for a fixed 12-month window that was really
13, Trends for 24 months with an Apply button, and the energy pages for
60. Each page derived "today" from UTC, so the first hours of a local day
belonged to yesterday. A missing tariff, a month nobody measured and a
genuine zero all rendered as 0. And a virtual meter -- the one thing the
spreadsheet leans on hardest -- was excluded from analysis outright:
MeterPeriodService returned null for it and the page offered a flow
diagram instead.

docs/DASHBOARD_ANALYSIS_CHANGE_BRIEF.md is the work order. Every choice it
left open is settled in docs/ANALYSIS_IMPLEMENTATION_NOTE.md as D-01..D-58
plus amendments A-01..A-30; code, tests and release notes cite those ids.

The analysis layer

Core/Analysis holds the pure rules: period presets resolved once in the
instance zone into a local date range and a half-open UTC range, bucket
plans, calendar-unit comparisons, coverage runs with a resolution class,
normalized quantities and units, the totals policy, the virtual formula
parser/validator/evaluator, and the cost calculator. "Now" comes from
TimeProvider; services never read the clock.

Normalization now writes, in the same transaction as consumption and by
diff, per-meter rollups by local day and month plus coverage runs and a
rollup state (AnalysisDataWriter). AnalysisReader answers a request from
those tables -- month rollups for month and year buckets, day rollups
otherwise, at most two partial edge days from consumption -- and
CostReader prices the result month by month. Pages, /api/v1 and the CSV
export read nothing else. The unused continuous aggregates are dropped.

The reader's statement count per request is constant whether it covers one
meter or a thousand. On a synthetic 1,000-meter, ten-year instance the
brief's target request (100 meters, ten years, monthly) takes 374 ms
against a two-second target, and the Overview went from 48,244 SQL
statements per load to 205.

Missing is not zero

Every bucket carries a status -- available, partial, missing, unresolved,
invalid, pending -- derived from coverage, never from the amount, with
provenance and a reason code beside it. A true zero is a number and a bar
on the baseline; an unknown bucket is a gap that says why; a month whose
data only exists monthly says so instead of inventing daily detail; a
scope with no tariff says "not priced" instead of 0. Rows whose interval
closes after now are reported separately rather than counted.

Virtual meters are analysis subjects

A virtual meter stores a canonical definition -- expression over m<id>
references, result kind, unit and cost rule -- validated on save and on
read for syntax, unknown or self references, loops and unit/kind rules.
It is evaluated on read from its sources' rollups over their joint
coverage: a missing source makes the bucket missing, an observed zero is
a valid input, a non-finite result is invalid with its dependency path,
and the page lists each source's contribution. Topology links are
topology only and never rewrite a saved calculation; expression-less
meters from older installs are converted once at startup. The editor has
Sum, Difference and Advanced modes with a live preview.

Totals and the bill

Per energy type the totals policy separates use, grid import, export,
generation and runtime, marks breakdown meters as breakdowns and virtual
meters as views, and never adds across units. The bill follows it: grid
import where there is one, separately priced subsections at their own
price, feed-in only on export meters, standing charges once per scope per
local day, manual costs once on their start day, categories as
non-overlapping covers whose composition reconciles to the bill. The
seeded demo's yearly totals now match the spreadsheet.

Pages and navigation

The period lives in the URL and every page reads the same contract, so a
link, a reload and the browser's Back button keep it. Shared components
carry it: page header with breadcrumbs, period toolbar, theme-aware chart
with an accessible table beside it, metric cards, comparison and
availability states, attention items that each link to the one action
that fixes them. Meter detail leads with an Analysis tab and resolves its
tabs by key; the energy page has Overview, History, Flow and Meters; the
old cost-only Trends page is a general Analysis page over portfolio, type,
category, meter or a meter comparison. Records tabs are paged server-side
instead of showing the latest 200. Everything is English and German,
light and dark, down to 360px.

Some figures change on purpose; docs/RELEASE_NOTES.md lists each one and
what the first start after the update does (it rebuilds all analysis data
before the web server listens). docs/SDD.md and CLAUDE.md describe the
system as it now is.

Tests: 1,733 Core and 746 integration, all green, plus an opt-in
performance suite with a synthetic 1,000-meter generator.

README.md

@@ -16,27 +16,71 @@ full design.
 - **Immutable raw readings** on a TimescaleDB hypertable; a normalized, append-only **consumption**
   layer on top — reproducible, auditable.
 - **Seven measurement modes** (cumulative/generation registers, burner runtime, tank/consumable,
-  direct delta, instant rate, virtual). Handles meter swaps, counter resets, tank dip-sticks with
-  calibration, and **virtual meters** defined by an expression (PV self-consumption, savings, net).
+  direct delta, instant rate, virtual). Handles meter swaps, counter resets and tank dip-sticks with
+  calibration.
+- **Virtual meters** with a validated formula over other meters: sum, difference or free formula,
+  e.g. `Solar 1 + Solar 2`, or self-consumption as `Haus − Netz`. They are analysed exactly like
+  physical meters: history, comparisons, source contributions, and costs where a cost rule applies.
+  They are computed from their sources on every read, so they never go stale. A missing source month
+  reads "no data", never a silent zero.
 - **Tariff engine** with time-ranged price history (unit/base/feed-in), scoped global / per type /
-  per meter; **cost categories** decoupled from energy types; meterless manual costs.
-- **Continuous aggregates** (daily/monthly/yearly, local timezone) so dashboards never scan raw.
-- **Dashboard**: cost KPIs with period-over-period deltas, "what costs most", a "what cost more/
-  less" difference view, trends, a **PV/Solar panel** (generation, self-consumption, autarky %,
-  savings), an **oil/consumable panel** (tank gauge, deliveries, burner runtime, effective L/h,
-  forecast-to-empty) and a **per-meter detail view** (raw readings, consumption, sources, tariff
-  timeline, events), one-click reference-data load, CSV dry-run.
-- **Per-energy-type flow pages** (Electricity, Water, …): a **Sankey diagram** of the meter chain —
-  a downstream meter is a *subsection* of an upstream one (main → car, pool, garden, …), arrow
-  thickness ∝ amount, with an auto-computed "Other/unmetered" remainder. Meters can have several
-  upstreams (a merge, e.g. grid + solar → house).
-- **Admin UI**: full create/edit/delete for energy types, meters (with consumption recompute on
-  mode/baseline change, and cycle-safe upstream-meter wiring), ingest sources, tariffs, cost
-  categories, and MQTT/Home-Assistant connectors; a "Test connection" for Home Assistant;
-  effective-settings view.
+  per meter. The bill counts each energy type's grid import (or its household use), not every meter
+  that happens to exist. Standing charges are counted once per scope. **Cost categories** are
+  decoupled from energy types. Meterless manual costs are supported. The currency is configurable.
+- **Rollups by local day and month**, written together with the consumption, so dashboards never
+  scan raw readings. The Settings page shows how far each meter's analysis data is built.
+- **One period everywhere**: every page shares a period toolbar (month to date, last month, year
+  to date, previous year, last 12/24 months, all history, custom dates), a bucket size (day, week,
+  month or year) and a comparison (previous period, previous year, or any calendar year). The
+  selection lives in the URL, so reload, Back and shared links keep it.
+- **Pages:**
+  - **Overview** of the selected period: cost with its composition, one card per energy type,
+    history chart, "what changed", and attention items with a direct fix.
+  - **Analysis** page to explore the portfolio, an energy type, a cost category, one meter or up to
+    six meters side by side, by quantity or cost.
+  - **Energy type** pages with Overview, History, a **Sankey flow** of the meter chain, and a meter
+    list. A downstream meter is a *subsection* of an upstream one (main → car, pool, garden, …), and
+    the unmetered remainder is shown as "Other".
+  - A **meter hub** with tabs for Analysis, Readings, Normalized data, Events, Tariffs and Sources
+    (Calculation for virtual meters). The record tabs are paged over the full history.
+  - **Solar** (generation, self-consumption, feed-in, autarky, savings, with setup help for missing
+    meter roles) and **Tanks & consumables** (last dipstick, estimate now, deliveries, burner
+    runtime, forecast).
+- **Honest numbers**: a true zero, missing data, data that is only monthly, and a missing price
+  are shown differently everywhere, in cards, charts, tables and the **CSV export** of any view.
+- **Admin UI**: full create/edit/delete for energy types, meters (with a calculation editor and
+  live preview for virtual meters, friendly meter roles, and a recompute when a change needs one),
+  ingest sources, tariffs (unit check; "Add tariff" links from a missing price open the editor
+  prefilled), cost categories, and MQTT/Home-Assistant connectors. Includes a "Test connection" for
+  Home Assistant and an effective-settings view.
+- English and German UI, light and dark theme, usable down to phone width.
 - **REST API + OpenAPI/Swagger**, API-key auth, reverse-proxy trust (Authelia/Traefik).
 - **JSON config export/import** for portability; Docker Compose + multi-arch image.
 
+## Upgrading to 0.4.0
+
+0.4.0 reworks the dashboards and how analysis and costs are computed. Read
+[`docs/RELEASE_NOTES.md`](docs/RELEASE_NOTES.md) first: some figures change on purpose. Back up the
+database (`pg_dump`), then start the new image once and let it finish:
+
+- **The first start rebuilds every meter's analysis data** (normalization revision 3): consumption,
+  the new day/month rollups and coverage. This happens before the web server listens, so the app is
+  unreachable while it runs and Compose may report the container unhealthy. Let it finish rather
+  than killing it. The time grows with the number of raw readings: about 0.1 s per monthly meter,
+  ~0.6 s per meter with ten years of daily readings, ~1.4 s per meter with a year of hourly
+  readings. A 1,000-meter test dataset (1.3 M readings) took about six minutes. Progress is logged,
+  and a meter that fails is retried at the next start.
+- **Virtual meters without a formula** get the sum their links imply stored as an explicit formula.
+  The log names the meters converted and those that still need configuration.
+- **The bill changes**: the grid meter is billed instead of every meter of a type, feed-in is
+  credited only on a grid-export meter, a missing tariff is "not priced" instead of 0, and standing
+  charges count once per scope. The seeded demo now matches the spreadsheet's yearly costs.
+- **The REST API only adds fields**: see the release notes for `costStatus`, `costAvailability`,
+  `costRule`, `notCosted`, `missingPrices`, `status` and `latestMonth`.
+- **Rolling back** to 0.3.0: the old version ignores the new tables and never read the dropped
+  continuous aggregates. Consumption stays as 0.4.0 booked it until each meter next ingests a
+  reading. Stored virtual-meter formulas remain; 0.3.0 ignores them and sums links again.
+
 ## Upgrading to 0.3.0
 
 This release changes where consumption lands. Back the database up first (`pg_dump`), then start the
@@ -89,6 +133,8 @@ Configuration is via environment variables (`Section__Key` double-underscore map
 | `ConnectionStrings__Default` | PostgreSQL/Timescale connection string |
 | `MeterVault__TimeZone` | IANA timezone for buckets, display **and month attribution** (default `Europe/Berlin`). Changing it re-derives every meter's stored consumption at the next start, and historical monthly figures can shift. It must be an id both .NET and PostgreSQL know; anything else falls back to UTC and is reported in the log. |
 | `MeterVault__Locale` | Default UI language, `en` or `de` (default `en`). Each visitor can switch it from the app bar; the choice is remembered in a cookie. |
+| `MeterVault__Currency` | Currency code of every amount (default `EUR`). Tariffs in another currency are reported as not fitting, never converted. |
+| `MeterVault__RawRetentionDays` | Shown on the Settings page but **not enforced**: raw readings are kept, because every recompute rebuilds a meter from them. |
 | `MeterVault__ApiKeys__0` | An API key accepted on the `X-Api-Key` header |
 | `MeterVault__AllowAnonymousApi` | `true` to open the REST API without a key (trusted LAN only) |
 | `MeterVault__ReverseProxyTrust` | `true` to honour `X-Forwarded-User` behind an auth proxy |