v1.12.0 — Anomaly model status API

✨ Added

• `GET /api/anomaly/models` — reports each metric's Layer 2 (anomaly digest) training status: when it last trained, how many rows it used, and its current alert threshold. Lets anyone monitoring the app check on the anomaly model without a database client.

📝 Docs

• `docs/DESIGN_SPEC.md` §11.6 documents the new endpoint and what it deliberately leaves out (fitted model coefficients, which have no meaning outside the app itself).

v1.11.0 — Anomaly digest (Layer 2)

✨ Added

• Context-aware anomaly digest (Layer 2 of the anomaly-detection design). Each metric (power/gas/water) now gets its own model of what a "normal" day looks like given that day's calendar position, weather, occupancy, and (for power) EV charging — so a cold, fully-occupied winter day is judged against a cold-and-occupied baseline, not a flat year-round average. A day is flagged only if it exceeds that household's own historical 99th-percentile deviation.
• Runs nightly, independent of the existing leak/health alerts. Anything flagged sends one Telegram summary and is recorded for later review — this is a digest, not an interrupt, so it never touches the persistent alert banner.
• Reuses the existing anomaly-alerts Telegram configuration — no new setup required if leak/health alerts are already configured. Needs 90+ days of settled history per metric before it starts training; does nothing until then.

📝 Docs

• docs/DESIGN_SPEC.md §11.6 documents the model (features, training, and the schema's kind='context' column reuse) and a new §12 limitation on its current scope (daily granularity only, fixed 99th-percentile threshold).

v1.10.0 — Health/staleness alerts

✨ Added

• Health/staleness monitoring (Layer 2 of the anomaly-alerting system). A new hourly check watches whether each metric's live data is still arriving at all — catches a stalled poller or an unreachable meter, independently of the poller itself. A metric with no live-data history (nothing configured for it) is never checked. Uses the same Telegram/banner delivery as the water leak alerts added in v1.8.0.
• Self-hosted: new health-check service in docker-compose.yml.

🐛 Fixed

• The leak-alert acknowledge endpoint could have applied the "not a leak" threshold adjustment to the wrong setting if a health alert happened to share the same metric name as a leak alert. Fixed before it could ever reach a real deployment.

v1.9.0 — Visual redesign

✨ Added

• New visual design. Overview tab gets a cost-band headline and per-category summary cards with sparklines; stat tiles animate on refresh; the energy-flow diagram and Sankey chart carry updated styling. Purely visual — no behavior or API changes.

📝 Docs

• All 4 README screenshots regenerated against synthetic demo data to match the new look.
• README: clarified that three features (not one or two) make outbound network calls, all opt-in and off by default; added a "Leak alerts" section; updated the feature-toggle list and module layout reference.

v1.8.0 — Water leak alerts

✨ Added

• Water leak detection (Layer 1 of a planned multi-layer anomaly system). Watches for volume accumulated within an unbroken run of continuous flow — a real leak, stuck valve, or burst pipe doesn't pause; normal household use does. Checked every ~20s poll cycle, not on a daily/hourly rollup, so detection isn't delayed by data settling later.
• Occupancy-aware thresholds. A much lower "away" threshold engages automatically after several consecutive near-zero gas+water days (reusing the existing absence detector), unless a logged Occupancy entry says otherwise. Never inferred from live consumption alone — that would be circular.
• Telegram alerts + persistent in-app banner. New Settings → Leak alerts card: chat ID, thresholds, and a "Send test message" button. The banner is authoritative (always shows, no network needed) and persists until acknowledged; Telegram delivery is best-effort with a short timeout and automatic retry on the next poll if a send fails. A leak keeps nagging on an escalating schedule (immediate, then 15/30/60 min) until acknowledged or the flow actually stops. Dismissing an alert as "not a leak" nudges that household's threshold up so the same false positive won't repeat.
• New environment variables: OMNIMETER_TELEGRAM_BOT_TOKEN, OMNIMETER_TELEGRAM_CHAT_ID (see .env.example). Off by default, same opt-in pattern as weather and the update check.

📝 Docs

• docs/DESIGN_SPEC.md — new §11 covering the detector design, persistence, and delivery model, plus updated outbound-call counts elsewhere in the doc.

v1.7.2

🐛 Fixed

• v1.7.1's "today's figures are a projection" note wasn't actually showing. The backend correctly flagged the data, but the frontend code that renders the note on the Overview flow diagram and the Self-Sufficiency tab wasn't included in that release. It's there now.

v1.7.1

✨ Added

• "Today" date-range preset, on every tab — a genuine calendar-day-so-far view (midnight to now), not the trailing 24h window "1d" gives you. Positioned leftmost, ahead of "1d".

🐛 Fixed

• Today's solar/self-sufficiency figures are now clearly labeled as a projection, not an actual. Solar isn't metered in the common case (most inverters aren't reachable locally), so it's modeled from a seasonal yield curve — a model with no concept of elapsed time, so it always returns a full day's total regardless of what time it actually is. Selecting "Today" early in the day was showing the whole day's projected solar output as if already produced. The Overview flow diagram and the Self-Sufficiency tab now show a clear note whenever the selected range includes today.

v1.6.0

🐛 Fixed

• Phantom "meter reset" in the data-quality report. A CSV export taken mid-period pads its remaining slots with 0. Because the meter columns are cumulative counters, that padding read as one enormous drop, and the per-granularity check reported a meter reset that never happened. Those trailing rows are now recognised as padding and removed at import.
  • Your totals were never wrong — the rollup already skipped negative deltas. Only the data-quality finding was spurious.
  • Zeros between real readings are left alone: those are a meter dropout, already handled separately.
  • A row counts as padding only when every value column is absent or zero, so a genuine zero reading in one column (an empty battery's state of charge, for example) is never mistaken for it.
  • The number of rows dropped is logged on import.

📝 Docs

• DESIGN_SPEC.md §3.3 now documents export padding at both ends of a file — the leading collapse-to-anchor and this new trailing removal — and why each is lossless.

v1.5.4

🔧 Maintenance

• The Android app is now versioned and released independently of the main web app -- see android/README.md. Look for android-vX.Y.Z tags for the Android app; this repo's regular vX.Y.Z releases (like this one) no longer carry an APK.

v1.5.3

📝 Docs

• Android app README now states its prerequisite explicitly: you need an OmniMeter instance already running and reachable from your phone before installing this app -- it's a client, not a setup tool.