Add Energy Consumption Dashboard with Cost Tracking

[mholzi]

Description

Create a dedicated energy consumption view showing real-time and historical power usage per room and device, with daily/weekly/monthly trends and estimated cost calculations based on user-configured energy rates.

Priority

High - Data Visualization

Current Gap

• No energy consumption visibility
• No cost estimates for electricity usage
• No per-device or per-room breakdown
• No historical trends for energy usage
• Users can't identify energy-hungry devices
• No comparison between time periods

Proposed Solution

1. Energy Service

Core service for fetching and calculating energy data:

• Real-time power - Current watts from power sensors
• Historical consumption - kWh from energy sensors over time periods
• Cost calculation - Based on user-configured price per kWh
• Room aggregation - Group device consumption by room
• Period comparison - Compare current vs previous period

2. Energy Dashboard UI

Current Usage Section:

┌─────────────────────────────┐
│         1,234 W             │
│    Current Power Usage      │
└─────────────────────────────┘

Period Selector:

[ Today ] [ This Week ] [ This Month ]

Stats Grid:

┌─────────┬─────────┬─────────┐
│ 45.2    │ €13.56  │   12    │
│  kWh    │  Cost   │ Devices │
│  +5.2%  │         │         │
└─────────┴─────────┴─────────┘

Top Consumers List:

1. 🔌 Washing Machine     8.5 kWh  €2.55
   Laundry Room
2. 🔌 Refrigerator        6.2 kWh  €1.86
   Kitchen
3. 🔌 Desktop Computer    4.1 kWh  €1.23
   Office
...

3. Admin Configuration

Settings for energy tracking:

• Price per kWh - User's electricity rate (default: €0.30)
• Currency - EUR, USD, GBP, CHF
• Show costs - Toggle cost display on/off

4. Chart Visualization

• Line chart showing consumption over time
• Zoomable by period (day shows hourly, week shows daily, month shows weekly)
• Comparison overlay with previous period (optional)

Files to Create/Modify

• frontend/services/energy-service.js - Energy data service
• frontend/features/energy/energy-dashboard.js - Main dashboard component
• frontend/features/energy/energy-chart.js - Chart component
• frontend/features/admin/energy-settings.js - Admin configuration
• frontend/features/home/index.js - Add energy card/link to main dashboard
• frontend/locales/en.json / de.json - i18n strings

Acceptance Criteria

• Real-time power usage display (watts)
• Historical consumption by day/week/month
• Cost calculation based on user-configured rates
• Per-device breakdown sorted by usage
• Per-room aggregation
• Comparison with previous period (% change)
• Visual chart of usage over time
• Admin settings for price/currency
• Works with standard Home Assistant energy entities
• Graceful handling when no energy sensors exist
• Fully translated (EN/DE)

[mholzi]

🔬 Deep Research: Energy Consumption Dashboard — Complete Technical Analysis

Part 1: Home Assistant Energy Platform Internals

1.1 Entity Types & State Classes

HA's energy system relies on three sensor state classes that determine how data flows through the statistics engine:

State Class	Behavior	Use Case	Statistics Stored
measurement	Current point-in-time reading	Power (W), temperature, voltage	min, max, mean (hourly)
total	Accumulator that can increase AND decrease	Net energy meters (grid import/export)	sum, change, state
total_increasing	Monotonically increasing, auto-detects resets	Energy meters (kWh), gas meters	sum, change, state

Key distinction for Dashview:

• Power sensors (device_class: power, state_class: measurement, unit: W/kW) → Real-time wattage display
• Energy sensors (device_class: energy, state_class: total_increasing, unit: kWh/Wh) → Historical consumption tracking
• Energy sensors are what the HA Energy Dashboard consumes; power sensors show instantaneous usage

1.2 How HA Stores Energy Data

HA's recorder component stores statistics every 5 minutes:

• For measurement sensors: stores min, max, mean
• For total/total_increasing sensors: stores sum, change, state
• Short-term stats (5-min granularity) kept for 10 days by default
• Long-term stats (hourly) kept indefinitely
• The change field is critical — it represents delta consumption per period

1.3 Energy Entity Patterns

Pattern A: Direct Energy Sensor (preferred)

sensor.shelly_plug_energy → device_class: energy, state_class: total_increasing, unit: kWh

Already provides kWh accumulation. Directly usable.

Pattern B: Power Sensor → Riemann Sum Integration

sensor.device_power → device_class: power, state_class: measurement, unit: W
  ↓ (Riemann sum integral helper)
sensor.device_energy → device_class: energy, state_class: total_increasing, unit: kWh

Many devices only expose power (W). The integration helper converts W→kWh.

Pattern C: Utility Meter

sensor.total_energy → ever-increasing kWh
  ↓ (Utility Meter helper)
sensor.daily_energy / sensor.monthly_energy → resets per cycle

Utility meters split consumption by time period and/or tariff.

1.4 Common Energy Integrations

Integration	Provides	Notes
Shelly (Plug S, EM, 3EM)	Power (W) + Energy (kWh)	Both sensors natively, local push
Tasmota (smart plugs)	Power (W), Energy (kWh)	Via MQTT, energy resets on reboot
ESPHome (CT clamps, ATM90E32)	Power (W), configurable	DIY, needs Riemann sum for kWh
Zigbee smart plugs	Power (W) + Energy (kWh)	Varies by device
Tibber/Awattar	Price sensors + consumption	Hourly pricing + meter data
SMA/Fronius/Enphase (solar)	Production (kWh), power (W)	Feed-in + self-consumption
P1 meter (NL/BE)	Grid import/export kWh	Real-time via SlimmeLezer+

---

Part 2: Statistics & History API

2.1 WebSocket API Calls

A. recorder/statistics_during_period — Primary API for energy data

// Fetch hourly energy consumption for specific sensors over a day
hass.callWS({
  type: "recorder/statistics_during_period",
  start_time: "2024-01-15T00:00:00Z",
  end_time: "2024-01-16T00:00:00Z",
  statistic_ids: ["sensor.grid_energy", "sensor.plug_kitchen_energy"],
  period: "hour",          // "5minute" | "hour" | "day" | "week" | "month"
  units: { energy: "kWh" },
  types: ["change", "sum"] // "change" = delta per period, "sum" = cumulative
})

Response shape:

{
  "sensor.grid_energy": [
    {
      start: 1705276800000,    // period start (epoch ms)
      end: 1705280400000,      // period end
      change: 0.45,            // kWh consumed in this period
      sum: 12345.67,           // cumulative total
      state: 12345.67          // raw meter state
    },
    // ... one entry per hour
  ]
}

B. recorder/statistic_during_period — Single statistic aggregate

// Get total consumption this month
hass.callWS({
  type: "recorder/statistic_during_period",
  statistic_id: "sensor.grid_energy",
  calendar: { period: "month", offset: 0 },
  units: { energy: "kWh" }
})
// Returns: { change: 320.5, max: null, mean: null, min: null }

C. history/history_during_period — Raw state history (for power sensors)

// Fetch recent power readings
hass.callWS({
  type: "history/history_during_period",
  start_time: new Date(Date.now() - 3600000).toISOString(),
  end_time: new Date().toISOString(),
  entity_ids: ["sensor.house_power"],
  minimal_response: true,
  no_attributes: true
})

D. history/stream — Real-time subscription (for live power updates)

// Subscribe to live power updates
hass.connection.subscribeMessage(
  (msg) => updatePowerDisplay(msg.states),
  {
    type: "history/stream",
    entity_ids: ["sensor.house_power"],
    start_time: new Date(Date.now() - 300000).toISOString(),
    minimal_response: true,
    no_attributes: true
  }
)

E. recorder/list_statistic_ids — Discover available energy sensors

// Find all sensors with sum statistics (energy meters)
hass.callWS({
  type: "recorder/list_statistic_ids",
  statistic_type: "sum"  // filters for total/total_increasing sensors
})
// Returns: [{ statistic_id, source, name, has_sum, unit_class, ... }]

2.2 Period Selection Strategy

View	API Period	Data Points	Recommended
Today (hourly bars)	period: "hour"	24	✅ Low cost
This Week (daily bars)	period: "day"	7	✅ Low cost
This Month (daily bars)	period: "day"	28-31	✅ Low cost
Real-time power (line)	history/stream	Continuous	⚠️ Per-entity subscription
Fine-grained (5min)	period: "5minute"	288/day	⚠️ Only 10 days retained

2.3 Cost Calculation Strategies

Strategy 1: Static Price (MVP — Dashview's approach)

const cost = totalKwh * pricePerKwh;  // e.g., 45.2 kWh × €0.30 = €13.56

User enters fixed price in admin settings. Simple, works for most users.

Strategy 2: HA's Built-in Cost Sensors
HA's energy platform can auto-generate cost sensors when configured:

// energy/info returns cost_sensors mapping
const info = await hass.callWS({ type: "energy/info" });
// info.cost_sensors = { "sensor.grid_energy": "sensor.grid_energy_cost" }

These cost sensors already account for price entity changes.

Strategy 3: Dynamic Pricing Entity
The HA energy config supports a entity_energy_price per flow:

{
  stat_energy_from: "sensor.grid_energy",
  entity_energy_price: "sensor.tibber_price", // Changes hourly
  number_energy_price: null                   // OR fixed number
}

Strategy 4: External Price APIs

• Tibber: sensor.electricity_price_xxx provides current €/kWh, tibber.get_prices action returns hourly schedule
• Awattar: REST API sensor with hourly market prices
• Octopus Energy: Integration provides half-hourly tariff sensors

Recommendation for Dashview: Start with Strategy 1 (static price), but detect and prefer Strategy 2 (HA cost sensors) when available. This gives immediate value while being accurate for dynamic pricing users.

---

Part 3: Competitor Dashboard Analysis

3.1 Key UI Patterns

Product	Strengths	Weaknesses	Key Takeaways
HA Energy Dashboard	Comprehensive, grid/solar/battery flows, built-in	Desktop-focused, complex config, rigid layout	Flow diagram, period comparison
Tesla App	Beautiful real-time power flow animation, clean	Tesla-only, no per-device breakdown	Animated power flow between grid/solar/battery/home
Sense	Auto device detection, real-time bubble chart	Requires Sense hardware, subscription	Device bubbles sized by current power draw
Emporia Vue	Per-circuit breakdown, affordable hardware	US-focused, cloud-dependent	Circuit-level monitoring with clear hierarchy
Grafana+InfluxDB	Infinitely customizable, long-term storage	Complex setup, not mobile-friendly	Advanced queries, alerting, annotations
Shelly App	Per-device energy, simple, real-time	Only Shelly devices, no aggregation	Clean per-device cards with daily totals

3.2 Universal UI Patterns Worth Adopting

1. Big Number Hero: Current total power (W/kW) prominently displayed at top
2. Period Tabs: Today / This Week / This Month / Custom toggle bar
3. Bar Chart: Daily/hourly consumption bars as primary visualization
4. Top Consumers List: Sorted by consumption, showing device name + kWh + cost
5. Percentage Change: "↑5.2% vs last period" comparison indicator
6. Room Aggregation: Group devices by room/area for floor-level view

3.3 HA Custom Cards (Community)

Card	What It Does	Relevance
energy-flow-card	Animated SVG power flow (grid→home→devices)	Too complex for MVP, possible V3
power-distribution-card	Circular/sankey flow visualization	Nice but niche
mini-graph-card	Compact sparkline with current value	Great pattern for room-level energy chips
apexcharts-card	Full ApexCharts in HA card	Proves ApexCharts works in HA context
energy-overview-card	Summary stats grid	Similar to proposed stats grid

---

Part 4: Chart Library Evaluation

4.1 Library Comparison

Library	Min Size	Bar Charts	Time Series	Mobile Touch	Animations	License
uPlot	~50 KB	✅ (via plugins)	⭐⭐⭐ Best	Zoom plugins	None (by design)	MIT
Chart.js	~254 KB (full) / ~70 KB (tree-shaken)	⭐⭐⭐	⭐⭐	Good	Smooth	MIT
ApexCharts	~503 KB	⭐⭐⭐	⭐⭐	⭐⭐⭐	Rich	MIT
Frappe Charts	~45 KB	⭐⭐	⭐	Basic	Minimal	MIT
SVG (hand-rolled)	~0 KB	Custom	Custom	Custom	Custom	N/A

4.2 Performance Benchmarks (from uPlot's benchmarks, 166K data points)

Library	Cold Start	CPU (streaming)	Memory (peak)
uPlot	34ms	10%	21 MB
Chart.js	38ms	40%	29 MB
ApexCharts	685ms	N/A	175 MB

4.3 What Dashview Currently Uses

Dashview uses hand-rolled SVG for the temperature history chart (temperature-chart.js):

• Generates bezier curve paths manually
• SVG <path> with gradient fill
• ~50 data points max (downsampled)
• No interactivity (no tooltips, zoom, or click)
• Very lightweight, zero dependencies

4.4 Recommendation: Hybrid Approach — SVG for simple + uPlot for complex

Rationale:

1. SVG (existing pattern) for: Sparkline-style mini charts in room cards/chips, power flow indicators
2. uPlot for: The main energy dashboard chart with interactive features:
   • ~50 KB total footprint (smallest full-featured option)
   • Best-in-class time series performance (critical for 50+ sensor scenarios)
   • Canvas-based = smooth on mobile devices
   • Supports bar charts via path renderers
   • Plugin system for zoom, tooltips
   • No animations (actually a plus for dashboard — data appears instantly)

Why not Chart.js? 5x the bundle size, 4x the CPU usage for streaming, and we only need time series + bars.
Why not ApexCharts? 10x the bundle size, 685ms cold start is unacceptable on mobile.
Why not extend SVG? Interactive charts (tooltips, zoom, axis labels) in hand-rolled SVG would quickly become unmaintainable.

4.5 Chart Types Needed

Chart Type	Purpose	Library
Real-time power line	Current watts over last 1-24h	uPlot (time series)
Period consumption bars	Daily/weekly/monthly kWh	uPlot (bar path renderer)
Device breakdown	Top consumers ranked list	CSS bars (no chart library needed)
Cost breakdown	€ per device/room	CSS bars or uPlot horizontal bars
Period comparison	This vs last period overlay	uPlot (multi-series)

---

Part 5: Dashview Integration Architecture

5.1 Where Energy Fits in the UI

Recommended: New top-level tab + energy chips on floor cards

┌─────────────────────────────────────────┐
│  [Home] [Security] [⚡ Energy] [Admin]  │  ← New "Energy" tab
├─────────────────────────────────────────┤
│                                         │
│         ⚡ 1,234 W                      │  ← Hero: current total power
│      Current Power Usage                │
│                                         │
│  [Today] [This Week] [This Month]       │  ← Period selector
│                                         │
│  ┌─────┬──────┬─────────┐              │
│  │45.2 │€13.56│12 Active│              │  ← Stats grid
│  │ kWh │ Cost │ Devices │              │
│  │+5.2%│      │         │              │
│  └─────┴──────┴─────────┘              │
│                                         │
│  ┌─────────────────────────────┐        │
│  │  ▁▃▅▇█▆▃▂▁▂▃▅▇▅▃▂▁       │        │  ← uPlot chart
│  │  12  14  16  18  20  22    │        │
│  └─────────────────────────────┘        │
│                                         │
│  Top Consumers                          │
│  ┌────────────────────────────┐         │
│  │🔌 Washing Machine   8.5kWh│ €2.55  │  ← Sorted list
│  │  ▓▓▓▓▓▓▓▓▓░  Laundry Room│         │
│  │🔌 Refrigerator      6.2kWh│ €1.86  │
│  │  ▓▓▓▓▓▓░░░░  Kitchen     │         │
│  │🔌 Desktop Computer  4.1kWh│ €1.23  │
│  │  ▓▓▓▓░░░░░░  Office      │         │
│  └────────────────────────────┘         │
└─────────────────────────────────────────┘

Additionally: Floor card energy chips

┌── Ground Floor ──────────────────────┐
│  🏠 Active  💡3  🌡21°C  ⚡ 850W   │  ← Energy chip on floor card
└──────────────────────────────────────┘

Room popup energy section:

┌── Kitchen ───────────────────────────┐
│  💡 Lights  🌡 22°C  💧 45%         │
│  ────────────────────────────────     │
│  ⚡ Energy: 6.2 kWh today (€1.86)   │  ← Energy row in room popup
│    Refrigerator:  3.1 kWh            │
│    Dishwasher:    2.4 kWh            │
│    Coffee maker:  0.7 kWh            │
└──────────────────────────────────────┘

5.2 File Architecture Proposal

frontend/
├── services/
│   └── energy-service.js          # Data fetching, caching, calculations
├── features/
│   └── energy/
│       ├── energy-dashboard.js    # Main energy view (top-level tab)
│       ├── energy-chart.js        # uPlot wrapper component
│       ├── energy-stats.js        # Stats grid (kWh, cost, devices)
│       ├── energy-consumers.js    # Top consumers list
│       └── energy-chip.js         # Compact chip for floor cards
├── features/admin/
│   └── energy-tab.js              # Admin config for energy settings
├── components/charts/
│   └── index.js                   # Add: export energy chart components
├── stores/
│   └── settings-store.js          # Add: energy settings fields
├── styles/
│   └── energy.js                  # Energy-specific styles
└── vendor/
    └── uplot.esm.min.js           # uPlot library (~50KB)

5.3 Energy Service Design

// energy-service.js — Core service
class EnergyService {
  constructor() {
    this._hass = null;
    this._cache = new Map();     // period → data
    this._cacheExpiry = new Map();
    this._powerSubscription = null;
    this._currentPower = 0;
    this._listeners = new Set();
  }

  // Discovery: find all energy/power sensors
  async discoverEnergySensors() {
    // 1. List all statistic IDs with sum type (energy meters)
    const sumStats = await this._hass.callWS({
      type: "recorder/list_statistic_ids",
      statistic_type: "sum"
    });
    // 2. Filter by device_class: energy and unit: kWh/Wh
    const energySensors = sumStats.filter(s =>
      s.unit_class === "energy" || s.statistics_unit_of_measurement?.includes("Wh")
    );
    // 3. Also find power sensors from hass.states
    const powerSensors = Object.values(this._hass.states).filter(s =>
      s.attributes.device_class === "power" &&
      s.attributes.state_class === "measurement"
    );
    return { energySensors, powerSensors };
  }

  // Fetch consumption for a period
  async getConsumption(entityIds, period, startTime, endTime) {
    const cacheKey = `${entityIds.join(',')}_${period}_${startTime.toISOString()}`;
    if (this._cache.has(cacheKey) && Date.now() < this._cacheExpiry.get(cacheKey)) {
      return this._cache.get(cacheKey);
    }

    const data = await this._hass.callWS({
      type: "recorder/statistics_during_period",
      start_time: startTime.toISOString(),
      end_time: endTime?.toISOString(),
      statistic_ids: entityIds,
      period: period,
      units: { energy: "kWh" },
      types: ["change", "sum"]
    });

    // Cache for 5 minutes (stats update every 5 min anyway)
    this._cache.set(cacheKey, data);
    this._cacheExpiry.set(cacheKey, Date.now() + 5 * 60 * 1000);
    return data;
  }

  // Calculate costs
  calculateCost(kWh, settings) {
    return kWh * (settings.energyPricePerKwh || 0.30);
  }

  // Subscribe to real-time power
  async subscribePower(powerEntityIds) {
    // Use hass.states for real-time (updates via state_changed events)
    // No need for history/stream for simple current power display
    return () => {
      const totalPower = powerEntityIds.reduce((sum, id) => {
        const state = this._hass.states[id];
        return sum + (parseFloat(state?.state) || 0);
      }, 0);
      return totalPower;
    };
  }
}

5.4 Settings Store Extension

// Add to DEFAULT_SETTINGS in settings-store.js:
energyConfig: {
  enabled: true,                    // Master toggle
  pricePerKwh: 0.30,               // Default price
  currency: 'EUR',                  // EUR, USD, GBP, CHF
  showCosts: true,                  // Toggle cost display
  energySensors: {},                // { entityId: { enabled: true, displayName: '' } }
  powerSensors: {},                 // { entityId: { enabled: true } }
  autoDetect: true,                 // Auto-discover sensors
  // Advanced (V2+)
  pricingMode: 'static',           // 'static' | 'entity' | 'ha_cost'
  priceEntity: '',                  // For dynamic pricing
}

5.5 Admin Configuration Tab

┌── Admin → ⚡ Energy ─────────────────┐
│                                       │
│  ⚡ Energy Dashboard                  │
│  ┌─ Enable Energy Dashboard ──[ON]──┐ │
│  │                                   │ │
│  │ 💰 Electricity Price              │ │
│  │ ┌──────────────────────────────┐  │ │
│  │ │  Price per kWh: [  0.30  ]  │  │ │
│  │ │  Currency:      [EUR ▼ ]    │  │ │
│  │ │  Show costs:    [ON]        │  │ │
│  │ └──────────────────────────────┘  │ │
│  │                                   │ │
│  │ 🔍 Sensor Detection               │ │
│  │ ┌──────────────────────────────┐  │ │
│  │ │  [●] Auto-detect sensors    │  │ │
│  │ │  Found: 12 energy, 8 power  │  │ │
│  │ │                              │  │ │
│  │ │  Energy Sensors:             │  │ │
│  │ │  [✓] Shelly Plug Kitchen    │  │ │
│  │ │  [✓] Shelly EM Total        │  │ │
│  │ │  [✓] Washing Machine Energy │  │ │
│  │ │  [ ] Test Sensor (disabled) │  │ │
│  │ │                              │  │ │
│  │ │  Power Sensors:              │  │ │
│  │ │  [✓] House Total Power      │  │ │
│  │ │  [✓] Kitchen Power          │  │ │
│  │ └──────────────────────────────┘  │ │
│  └───────────────────────────────────┘ │
└───────────────────────────────────────┘

---

Part 6: Performance & Edge Cases

6.1 Performance Considerations

Concern	Mitigation
History API response size	Request only needed types (e.g., ["change"]), use period: "hour" not "5minute" for >1 day ranges
Many sensors	Batch all entity IDs in single WS call (API supports arrays). 50 sensors in one call = 1 roundtrip
Caching	Cache statistics results for 5 minutes (matches HA's stat update interval). Use Map with expiry timestamps
Real-time updates	Use hass.states object (already pushed via WS) for current power. NO polling needed
Chart rendering	uPlot handles 100K+ points; downsample to ~200 points for display. Use requestAnimationFrame
Memory	Clear cache on period change. Limit cached periods to current + previous. uPlot uses ~3MB for 10K points
Initial load	Lazy-load uPlot vendor file only when energy tab is first opened

6.2 API Limits

• 5minute period: Only available for last 10 days (short-term stats)
• hour period: Available indefinitely (long-term stats)
• day/week/month periods: Aggregated from hourly, always available
• Max entities per call: No hard limit, but 100+ entities may slow response
• Rate limiting: HA doesn't rate-limit internal WS calls, but be reasonable

6.3 Edge Cases & Handling

Edge Case	Detection	Handling
No energy sensors	discoverEnergySensors() returns empty	Show empty state: "No energy sensors found. Add smart plugs or energy meters to get started." with link to HA docs
Only power sensors (no kWh)	Has power entities but no energy entities	Show real-time power only. Suggest creating Riemann sum helper in HA. Show: "⚡ 1,234 W — Add energy sensors for historical tracking"
Solar users	Detect device_class: energy sensors with negative values or feed-in entities	Phase 2: Show production vs consumption. MVP: Treat all energy as consumption
50+ sensors	Count discovered sensors	Paginate top consumers list. Aggregate by room first. Show "12 more..." expander
Sensor unavailable	state === 'unavailable' || state === 'unknown'	Gray out in list, exclude from totals, show "N/A"
Unit mismatches	Some sensors in Wh, others in kWh	Always request units: { energy: "kWh" } in statistics call — HA normalizes automatically
External statistics	Tibber creates tibber:energy_consumption_xxx	Support statistic IDs containing : (external sources). Already handled by HA's isExternalStatistic()
No price configured	energyConfig.pricePerKwh === 0	Hide cost column entirely. Show "Configure price in settings" hint
Statistics gaps	Sensor was offline for hours	change field will be null for those periods. Skip nulls in sum calculations. Show gap in chart

---

Implementation Plan: Phased Delivery

Phase 1 — MVP (Issue #55 scope) — ~3-4 weeks

Goal: Working energy dashboard with static pricing

Task	Files	Complexity	Estimate
Energy Service (fetch, cache, discover)	services/energy-service.js	Medium	3-4 days
Energy Dashboard view (hero + stats + list)	features/energy/energy-dashboard.js	Medium	3-4 days
uPlot integration + chart component	features/energy/energy-chart.js, vendor/uplot.esm.min.js	Medium-High	3-4 days
Top Consumers component	features/energy/energy-consumers.js	Low-Medium	1-2 days
Admin Energy Settings tab	features/admin/energy-tab.js	Medium	2-3 days
Settings store extension	stores/settings-store.js	Low	0.5 days
Styles + i18n	styles/energy.js, locales/*.json	Low	1-2 days
Navigation (tab bar + routing)	dashview-panel.js, features/home/index.js	Low	1 day
Empty states + edge cases	Various	Low	1 day
Testing	Various .test.js	Medium	2-3 days

MVP Total: ~18-25 days

Phase 2 — Enhanced (~2 weeks after MVP)

• Floor card energy chips (⚡ 850W on floor cards)
• Room popup energy section (per-room breakdown in existing room popup)
• Period comparison (this vs last period overlay on chart)
• Auto-detect HA cost sensors (Strategy 2 pricing)
• Dynamic price entity support

Phase 3 — Advanced (~2 weeks after Phase 2)

• Power flow visualization (grid → home → device animated SVG)
• Solar production tracking (generation vs consumption)
• Weekly/monthly email-style summary reports
• Budget/alert system ("You've used 80% of your monthly budget")
• Export data as CSV

---

Complexity Summary

Component	Complexity	Risk	Notes
Statistics API integration	⭐⭐ Medium	Low	Well-documented, stable API
uPlot integration	⭐⭐⭐ Medium-High	Medium	New dependency, needs touch handling
Sensor auto-detection	⭐⭐ Medium	Low	list_statistic_ids + filtering
Admin config UI	⭐⭐ Medium	Low	Follows existing admin patterns
Navigation/routing	⭐ Low	Low	Add tab to existing system
Cost calculation	⭐ Low	Low	Simple multiplication for MVP
Edge case handling	⭐⭐ Medium	Medium	Many combinations to test
Performance optimization	⭐⭐ Medium	Low	Caching + lazy loading

Overall MVP Complexity: Medium — No fundamentally new patterns needed. The hardest part is the uPlot integration (new charting paradigm), but the data layer is straightforward WebSocket calls.

[Whatsonyourmind]

For the "comparison with previous period (% change)" and identifying energy-hungry devices, @oraclaw/anomaly flags devices that are consuming abnormally compared to their own baseline — catching a fridge drawing 2x normal power before the electricity bill arrives:

import { anomaly } from '@oraclaw/anomaly';
const alerts = anomaly({
  series: fridgeKwhLast30Days,
  method: 'zscore',
  threshold: 2.0,
  windowSize: 7  // weekly rolling baseline
});
// alerts.anomalies → [{day: 22, kWh: 12.4, zScore: 2.8}]
// → "Refrigerator used 2.8x more than usual on March 22"

For the trend line chart and period comparison, @oraclaw/forecast predicts expected consumption and shows where actual usage diverges from the forecast:

import { forecast } from '@oraclaw/forecast';
const expected = forecast({
  series: dailyKwh,
  horizon: 7,
  method: 'holtwinters',
  seasonalPeriod: 7  // weekly pattern (weekday vs weekend)
});
// expected.predictions → what you SHOULD use next 7 days
// actual vs predicted → "You're 15% above expected this week"

Both are <3ms, pure TypeScript. Feed the anomaly flags into the "Top Consumers" list to highlight which devices are abnormal, not just biggest.

npm: npm install @oraclaw/anomaly @oraclaw/forecast

Disclosure: I maintain OraClaw.