cataseven/Statistics-Graph-Chart-Card

A built-in date navigation panel that lets users browse historical data by Day, Week, Month, or Year — without leaving the dashboard.

type: custom:statistics-graph-chart-card
show_date_picker: true
date_picker_position: top
entities:
  - entity: sensor.temperature_living
    color: "#ff6b35"

The date picker bar shows the current period label with arrow buttons to move forward/backward:

• D / W / M / Y — switch between Day, Week, Month, and Year views
• ◀ ▶ — navigate to the previous/next period
• 📅 — open the calendar popup for direct date selection

Layout: the ‹ period › navigator and the D/W/M/Y + 📅 shortcuts can each sit left / center / right:

date_picker_nav_position: center
date_picker_shortcuts_position: right

Click the calendar icon to open a panel with:

• Calendar grid — click two dates to select a custom range
• Quick presets — Today, Yesterday, This/Last Week, This/Last Month, This/Last Year, Last 7 Days, Last 30 Days, Last 12 Months, Last 2 / 3 / 5 Years (v4.04)

The calendar stays open after selection so you can adjust the range. Click the 📅 icon again to close it.

Cards with the same date_picker_group share their date selection. You don't need a visible date picker on every card — only one card needs show_date_picker: true. Other cards in the same group will follow along automatically.

# Card 1: Has the visible date picker — this is the "controller"
show_date_picker: true
date_picker_group: bedroom

# Card 2: No visible picker — just follows Card 1
date_picker_group: bedroom

# Card 3: Also follows Card 1
date_picker_group: bedroom

Changing the date on Card 1 updates all three cards. Cards 2 and 3 show no picker UI but their data range follows the group selection.

This is ideal for dashboards where you want one date picker controlling multiple charts without repeating the picker bar on every card.

The same mechanism exists for the other on-card controls: interval_picker_group for the Interval Picker, and pph_picker_group / group_by_picker_group for the on-card Points/Hour and Group By pickers — each group is independent.

Control which period buttons appear with date_picker_modes:

# Show only Month and Year
date_picker_modes:
  - month
  - year

# Lock to Month — buttons hidden, navigation centered
date_picker_modes:
  - month

When only one mode is listed, the D/W/M/Y buttons are hidden entirely and the navigation (◀ label ▶) is centered for a minimal look. The 📅 calendar icon stays visible on the right.

The arrows jump period by period — for a quick peek into the recent past without leaving the current view, add extended_window_multiplier:

show_date_picker: true
extended_window_multiplier: 2   # render 2× the period, scroll back through the extra half

The card renders N× the selected period but opens showing exactly the period you picked, at its own scale and bucket density — then you can scroll horizontally into the extra history (scrollbar or mouse wheel, per scroll_mode). It follows the picker: on a Week view one extra week sits behind the current one; switch to Day and it's one extra day. The picker's header and arrows stay on the selected period — scrolling is a peek, the arrows remain the navigation. Also works without the date picker (extends hours_to_show or graph_start periods the same way).

With forecast data (data_attribute entities or forecast_horizon data whose points reach into the future — weather, prices): the chart opens with the current period in view (right edge at "now"), with the forecast reachable by scrolling right and history by scrolling left. This also works together with graph_start: normally graph_start cuts the window at the period's end, but with the multiplier active the forecast tail is rendered and scrollable, and the viewport spans the full selected period (so the scale doesn't creep as the day progresses). show_full_period is the exception — it keeps its "whole period, cut at its end" contract.

A Statistics Graph Chart Controller is a one-row card that contains only the date-picker bar and drives every chart card that shares its group. Add it from the card picker (Statistics Graph Chart Controller), or turn any card into one with chart_mode: controller. It fetches no data and needs no entities.

# the controller
type: custom:statistics-graph-chart-controller
sync_group: home
card_header: Period
date_picker_modes: [day, week, month, year, last_1h, last_6h, last_12h, last_24h, last_7d, last_30d]   # the default set
date_picker_default_mode: last_24h    # optional: open here on every load

# a chart it drives — no picker of its own, just the same group
type: custom:statistics-graph-chart-card
sync_group: home
entities:
  - entity: sensor.living_room_temperature

• One bar, one active state — calendar periods (D/W/M/Y with ◀ ▶, the calendar popup with presets and custom ranges) and rolling windows (1H, 6H, 12H, 24H, 7D, 30D …) share the bar. Choose the buttons with date_picker_modes; date_picker_nav_position / date_picker_shortcuts_position align them.
• Reset — the ↺ button returns to date_picker_default_mode (or the first visible mode) and clears a custom range. A controller shows it by default (date_picker_reset: false hides it); a normal chart card gets it with date_picker_reset: true.
• Rolling hours are exact — 1H, 6H and 12H count elapsed hours, so a window that crosses a daylight-saving change is still 1, 6 or 12 hours long.
• Late joiners — a chart card that loads after the controller asks for the current period when it connects, so it never starts out of step. The selection is remembered per group in the browser.
• sync_group fills the picker group keys that are left empty (date_picker_group, pph_picker_group, group_by_picker_group, and interval_picker_group on chart cards), so one name is enough on both sides. Chart cards in a controlled group should not show a date picker of their own — if one does, both are masters and the last click wins.
• The controller can also host the Resolution and Group By pickers (Overlay tab in the editor, or show_pph_picker: true / show_group_by_picker: true). Reset clears those overrides too.
• A controller that has no remembered selection yet (first use in a browser, or the editor preview) asks its group for the current period before it broadcasts anything, so opening the card picker never resets a live dashboard.
• Layout: the card reports one row (rows: auto, full width in Sections view by default); override with grid_options. Chart-only options are ignored.
• Cards still running an older card version ignore the 1H/6H/12H modes when a controller selects them (they keep their own mode and follow the offset only).

Editor — the controller's editor shows the Calendar tab (Sync Group, Reset Button, Visible Modes, Default Mode, Window Step, alignment), the Overlay tab reduced to the Resolution / Group By pickers, and the Card Settings panel. On a regular card, Chart Mode → Controller does the same.

Alongside the calendar modes, the picker offers rolling windows that always end at now: last_1h, last_6h, last_12h, last_24h, last_3d, last_7d, last_15d, last_30d, last_90d, last_180d, last_12m, last_2y, last_3y, last_5y. Unlike Day / Week / Month / Year (which snap to calendar boundaries), these show the last N up to the current moment, and the ◀ ▶ arrows jump a full N back/forward (e.g. the previous 7 days).

Use them two ways:

# Always open on the last 7 days
show_date_picker: true
date_picker_default_mode: last_7d

# Offer rolling buttons in the picker bar (shown as 24H / 7D / 30D …)
show_date_picker: true
date_picker_modes:
  - day
  - last_7d
  - last_30d

• As Default Mode (date_picker_default_mode) a rolling window is forced as the starting view on every load.
• As Visible Modes (date_picker_modes) the rolling options appear as extra buttons — 1H, 6H, 12H, 24H, 3D, 7D, 15D, 30D, 90D, 180D, 12M, 2Y, 3Y, 5Y — next to D/W/M/Y. Calendar modes are on by default; rolling buttons are off until you add them. In the editor the two families are shown under separate Calendar periods / Rolling windows headings, and on the picker bar a thin divider separates the D/W/M/Y buttons from the rolling ones so the two aren't mistaken for each other. (v3.30)
• The label reads e.g. Last 7 days at the current window, switching to a date range (May 16 – May 23) once you navigate back.
• The multi-year windows last_2y, last_3y and last_5y are anchored to the same day and time two, three or five calendar years back, so the arrows step a full 2 / 3 / 5 years. Pair them with auto_scale_points: true so the card buckets by month instead of trying to draw every interval, and expect last/first/diff/max aggregates to read from daily rows past roughly a year (the card logs a one-off console note when that happens). (v4.04)

date_picker_step controls how many units make up one "window". Default 1 = the legacy behavior (each click moves one day, one week, one month, etc.). When you set it higher, the picker becomes a rolling N-unit window and prev/next buttons jump a full N units at a time.

# Last 4 weeks, prev/next jumps 4 weeks
show_date_picker: true
date_picker_step: 4
date_picker_modes:
  - week

# Last 30 days, prev/next jumps 30 days
date_picker_step: 30
date_picker_modes:
  - day

The label adapts automatically: step > 1 shows the date range (Mar 11 – Apr 7), step = 1 keeps the existing single-period labels (April 2026, Apr 1 – Apr 7).

Editor: General Settings → Calendar tab → Date Navigation → Window Step (appears next to Visible Modes when the date picker is enabled)

General Settings → Calendar tab → Date Navigation → Date Picker toggle. Position and Group options appear on the same row. The Group field is always editable — even when the Date Picker toggle is off — so you can assign a group to cards that don't show their own picker. When enabled, a Visible Modes section appears below with D/W/M/Y checkboxes plus the rolling options (24H / 3D / 7D … 12M / 2Y / 3Y / 5Y), and a Default Mode dropdown that also lists the rolling windows. The Date Nav and Shortcuts dropdowns control where the navigator and the mode buttons sit in the bar.

• Cannot be used together with energy_date_sync — enabling one disables the other
• Date picker state is persisted in localStorage and restored on page reload
• When viewing the current period, the X-axis extends to the end of the period with empty space after the current time
• Cards with only date_picker_group (no show_date_picker) use their normal hours_to_show until a sync event arrives from a card in the same group

Append each entity's Home Assistant area to its label. Handy when a card mixes rooms, and essential with integrations like Advanced History that hand several entities the same friendly name (three Heating Temperature sensors, one per room, otherwise indistinguishable):

type: custom:statistics-graph-chart-card
include_area_names: true   # default false
entities:
  - entity: sensor.lounge_heating    # friendly_name: "Heating Temperature"  (area: Lounge)
  - entity: sensor.office_heating    # friendly_name: "Heating Temperature"  (area: Office)
  - entity: sensor.fridge            # friendly_name: "Fridge Temp"          (area: Kitchen)
  - entity: sensor.lounge_lamp       # friendly_name: "Lounge Lamp Power"    (area: Lounge)

Legend result:

Heating Temperature · Lounge
Heating Temperature · Office
Fridge Temp · Kitchen
Lounge Lamp Power              ← already says "Lounge", not doubled up

• Every entity that has an area gets it — there is no duplicate detection. A rule that only fired on collisions would make your legend change shape whenever an unrelated entity was added or removed; if you switch this on, you want the areas.
• The area is taken from the entity's own area registry entry; if it has none, the card falls back to the entity's device area. If neither resolves, the name is left unchanged.
• A friendly name that already contains its area (e.g. Lounge Heating Temperature in the Lounge) isn't doubled up.
• An explicit name: (including template names) is your own label and is never modified.
• Applies to the state row, legend, tooltip, stats, exports and the editor's entity list, so every surface agrees.
• Comparison ghosts inherit the parent's suffix — Heating Temperature · Lounge (previous period).
• Off by default. Resolution is a couple of registry key-lookups per configured entity, so the cost is negligible.

General Settings → Chart tab → Visual Options → the Area names toggle (next to the legend options).

When a card plots two attributes of the same entity, both series carry that entity's friendly name — so the legend and the tooltip show the same label twice and there is no way to tell which line is which:

entities:
  - entity: climate.lounge_heating
    attribute: current_temperature     # legend: "Lounge Heating"
  - entity: climate.lounge_heating
    attribute: temperature             # legend: "Lounge Heating"   ← identical

Two card-level options qualify the label with the attribute, everywhere the name appears — state row, legend, tooltip, stats and exports:

include_attribute_name: true      # "Lounge Heating · Current temperature"
use_only_attribute_name: true     # "Current temperature"

Details:

• Only rows that actually plot an attribute change. An entity graphed on its own state has no attribute name, so it is left exactly as it was — which means you can turn these on for a whole card without touching its ordinary series.
• An explicit name: always wins, as everywhere else in the card.
• The attribute label comes from Home Assistant's own translated attribute name when your HA version provides one, so a German dashboard reads Zieltemperatur. Otherwise the attribute key is humanised: current_temperature → Current Temperature. The runtime attribute picker uses the same label, so the dropdown and the chart always name an attribute the same way (v3.32).
• With ref_entity, both halves of the combined name are qualified — Current Temperature - Target Temperature rather than one attribute minus a bare entity name.
• Rows using data_attribute (an attribute array such as a forecast) are never renamed after attribute:, since that is not what they plot.
• If you switch attributes with the runtime attribute picker, the label follows.
• The two options are alternatives, not a stack. In the visual editor, switching one on turns the other off; in YAML, use_only_attribute_name wins if you set both.
• It cooperates with include_area_names: the "name already contains its area" rule is evaluated against the label you will actually see, so Lounge Heating keeps its area suppressed while Current temperature correctly gains · Lounge.

General Settings → Chart tab → Visual Options → the Attribute names and Attribute names only toggles, next to Area names.

Syncs the card's time range with Home Assistant's Energy dashboard date picker or the energy-period-selector-plus custom card.

type: custom:statistics-graph-chart-card
energy_date_sync: true
entities:
  - entity: sensor.energy_consumption
    color: "#ff4757"
    aggregate_func: sum
  - entity: sensor.solar_production
    color: "#2ecc71"
    aggregate_func: sum

Place the card on the same dashboard as an Energy date picker. When the user selects a day, week, month, or custom range, this card automatically updates to show the same period.

• HA's built-in Energy dashboard date picker (DAY / WEEK / MONTH / YEAR)
• energy-period-selector-plus custom card
• Any card that uses HA's energy data collection system

Chart Settings → Calendar tab → Date Navigation → Energy Date Sync toggle, with the Key input next to it for energy_collection_key (v4.02).

• When energy_date_sync is active, it overrides hours_to_show and the interval picker selection
• Running several dashboards with separate energy-date-selection cards? Bind each card to its own picker with energy_collection_key — same key as that dashboard's selection card (HA requires the key to start with energy_) (v4.02)
• Period changes made in the Energy dashboard are picked up instantly — no polling, no refresh delay
• If the Energy panel hasn't loaded yet, the card retries every 2 seconds for up to 60 seconds

Extends the X-axis to cover a complete calendar period, leaving empty space after the current time. A dashed vertical "now" line marks where live data ends.

graph_start_hour: 0
hours_to_show: 24
show_full_period: true    # X-axis: 00:00 → 23:59, empty after now

The end of the period is determined by graph_start:

show_full_period also works with energy_date_sync: true. When the energy date picker selects a current period (today, this week, this month), the X-axis extends to the full period end. Past periods display in full as before.

energy_date_sync: true
show_full_period: true    # energy picker "This Month" → X-axis: Apr 1 → May 1

This is especially useful for:

• Imported data (energy, gas) that arrives with a few days delay — the graph shows the gap instead of filling it with the last known value
• Day comparison with offset — today's card shows a partial day with empty space; yesterday's card (offset: 24) shows a complete day
• Weekly/monthly dashboards — see the full period at a glance with the "now" marker
• Energy dashboard — combine with energy_date_sync to see the full billing period

Editor: General Settings → Calendar tab → Time Window → Show Full Period checkbox

Visualize data over weeks, months, and years with calendar-aware grouping and native HA statistics.

group_by: week
graph_start: month         # this month's weeks
aggregate_func: change     # consumption per week
graph_type: bar

group_by: month
graph_start: year          # start from Jan 1

group_by: year
hours_to_show: 87600       # ~10 years
aggregate_func: change     # annual consumption
graph_type: bar

When group_by is set to date, week, month, or year, the card fetches data using native HA statistics periods (period: 'day', 'week', 'month'). Year mode fetches monthly data and aggregates client-side. This enables Home Assistant's native change column for counters (a change series on a sensor without that column — state_class: measurement — reads hourly rows instead, like diff, max, first and last on such sensors (v4.06)) and bypasses the database retention limit — you can display a full year of data even if your recorder purge is set to 10 days.

A daily series and a monthly total of the same sensor — or a daily temperature line with monthly energy bars — can share one chart. Each entity may carry its own group_by; the chart's time grid is the finest grouping in use, and every series grouped coarser than that grid is drawn as calendar cells on it:

type: custom:statistics-graph-chart-card
graph_start: year
group_by: date
entities:
  - entity: sensor.heat_pump_energy
    name: Monthly
    graph_type: bar
    aggregate_func: change
    group_by: month            # monthly cells on the daily grid
    y_axis: secondary          # kWh on the right axis
  - entity: sensor.outside_temperature
    name: Temperature
    aggregate_func: avg        # daily mean, drawn on top

• The monthly bars span their whole calendar month (real spans on the daily axis, not equal-width slots); a window that starts mid-month gets a partial first cell. List the coarse entity first so it draws behind the finer ones.
• The tooltip shows the day's values and the containing month's total; stacking never mixes different grids.
• The grid follows the finest grouping: group_by: month on the card with group_by: date on one entity gives a daily grid where the other entities become monthly cells — the same chart as date on the card with month on them. Only raw/interval cannot be set per entity, and nothing changes while the card is grouped by raw.
• Y axis: a monthly total is ~30× a daily value in the same unit, so give it y_axis: secondary (its ticks sit at the same heights as the left axis, both zeros on the shared baseline) or independent (private hidden scale). Editor: Entities → entity → Data → Group By.

Even in interval mode with short ranges (hours_to_show ≤ 24), the card auto-routes to long-term statistics in three cases:

1. Any entity declares statistic_id explicitly — the user vouches that the entity has long-term statistics available. Useful for entities that exist only in the statistics database (Gazpar, Linky, etc.) or for forcing the route.
2. hours_to_show > 240 (≈ 10 days, the typical recorder retention) — statistics is the only source that can serve the range, so the card switches automatically.
3. Missing recorder coverage (v4.06) — when the raw history of a data_source: auto sensor does not reach the start of the window (no recorded state at or before the window start, or a recorded state followed by a gap of at least 2 hours / a quarter of the window during which the long-term statistics show the value moving), that sensor is read from 5-minute statistics for that refresh. A sensor that simply did not change stays on raw history; data_source: history opts out.

In both cases the route is conditional on every relevant entity having long-term statistics available — meaning a state_class of measurement, total, or total_increasing, or an explicit statistic_id. If any entity in the card lacks LTS, the route falls back to the regular history API to keep that entity working.

When the requested range exceeds 10 days but some entities lack LTS, a console warning is printed once listing the offending entities and explaining how to enable state_class in HA.

Date picker, synced picker groups and the Controller card (v4.04) — a picker view of a day or less (Day, 24H, 12H, 6H, 1H, today so far, or a short custom range) that reaches no further back than about 10 days is treated like a short hours_to_show card and reads raw recorder history, so short spikes keep their real height. Longer views (Week, Month, 7D, 30D …), older days, cards that contain an energy counter (total / total_increasing), a statistic_id, a ref_entity or a price_entity, and Energy-dashboard sync keep using long-term statistics. If the recorder no longer holds the start of the window (a purge_keep_days shorter than the window, a purged or re-created sensor, or statistics written for hours the recorder never recorded), the card switches that sensor to statistics by itself — on picker days and, since v4.06, on every short hours_to_show / interval-picker window. Set data_source: statistics to keep the smoother statistics view on picker days.

Statistics store 5-minute averages, which flatten bursts shorter than a few minutes. On long views, use aggregate_func: max when the peak matters more than the average. Statistics averages are also weighted by time: a 5-minute row holds the value averaged over the minutes it was valid, whereas a bucket built from raw history averages the readings recorded inside it, each counting once. A sensor that changes rarely (a setpoint held for 59 minutes, then changed once) shows the new reading as that hour's avg on raw history and the time-weighted value on statistics, so the same hour can read differently on a 24-hour and a 48-hour card. Sensors that report at a steady pace give the same number either way.

When graph_start is set, hours_to_show is ignored — the calendar period directly determines the start:

Editor: General Settings → Calendar tab → Time Window → Graph Start

A heating season, a school year or a fiscal year does not start on 1 January. year_start_month moves the start of the Year period:

show_date_picker: true
date_picker_default_mode: year
year_start_month: 7              # 1 Jul → 30 Jun, header reads 2026/27
group_by: month
entities:
  - entity: sensor.gas_consumption
    aggregate_func: change
    graph_type: bar
    compare: last_year           # ghost = 1 Jul 2025 → 30 Jun 2026

The same key shifts graph_start: year (with show_full_period the axis then runs to 30 June). It only moves the window: the month buckets, the tick labels and the Month / Week periods stay on the calendar. Every card in a date_picker_group should carry the same value — the group shares mode and offset, each card computes its own window. Editor: Chart Settings → Calendar → Time Window → Year Starts In.

graph_start: tomorrow sets the window to tomorrow 00:00 → end of day — ideal for next-day spot prices (Nord Pool, EPEX, Tibber) via data_attribute. The window extends into the future automatically without show_full_period.

type: custom:statistics-graph-chart-card
card_header: Tomorrow Spot Prices
graph_start: tomorrow
group_by: hour
entities:
  - entity: sensor.nord_pool_fi_contract_current_price
    data_attribute: tomorrow_hourly
    data_time_field: start
    data_value_field: value
    graph_type: bar
    decimals: 2
    unit: c/kWh

Manual control over tick spacing:

x_axis_interval: 2h    # Every 2 hours (00:00, 02:00, 04:00…)
x_axis_interval: 1d    # Daily (midnight)
x_axis_interval: 1w    # Weekly (Mondays)
x_axis_interval: 1M    # Monthly (1st of month)

Available presets in the editor: Auto, 1H–12H, 1D, 2D, 7D, 1W, 2W, 1M, 3M.

Editor: General Settings → X-Axis → X Axis Interval

By default the card draws its axes and grid deliberately subtler than Home Assistant's built-in charts: labels use the theme's secondary text colour with some transparency, and the grid is a faint neutral grey. If you would rather have the card look exactly like the core statistics-graph card next to it, switch the axis style:

axis_style: native

native takes the label colour, size and grid colour from the same theme variables Home Assistant's charts use (--primary-text-color at 12 px for the labels and date markers, --divider-color for the grid), so the card follows light, dark and custom themes without any fixed colours in your YAML. Options you set explicitly (x_axis_color, x_grid_opacity, …) still override the preset, and the editor placeholders show which value applies.

(v4.04) native also covers the per-entity legend — the one you get with show_in_legend on an entity. Its names and values switch to --primary-text-color at full strength, and the values grow to the same 12 px as the axis labels, instead of the card's dimmer, smaller look. The MIN / AVG / MAX labels stay small and dim so the value still reads first, and the compact legend (show_legend) is unchanged — it was already using the theme's main text colour at 12 px.

There is no legend-only switch. If you want the dimmer legend back you have to go back to axis_style: subtle, which also returns the axes and grid to the card's own look — write the individual axis options out explicitly if you want to keep the native axes.

Editor: Card Settings → Card Styling → Axis Style

Control the appearance of horizontal (Y) and vertical (X) grid lines independently.

y_grid_style: solid      # dashed (default), solid, dotted, long-dash
y_grid_width: 0.5         # thickness in px (default: 1)
y_grid_color: "rgba(255,255,255,0.1)"  # any CSS color or {{ template }}
y_grid_opacity: 0.3       # 0–1 (default: 0.15)

x_grid_style: dotted
x_grid_width: 0.5
x_grid_color: "var(--divider-color)"
x_grid_opacity: 0.3

Editor: Y Axis tab → Grid section, X Axis tab → Grid section

The X-axis automatically adapts to the group_by setting:

• Week — Ticks on Mondays: "3 Mar", "10 Mar"
• Month — Ticks on the 1st: "Jan", "Feb" (with year when spanning multiple years)
• Date — Daily ticks: "3 Mar", "4 Mar"
• Hour — Hourly ticks; midnight shows date instead of "00:00"

In interval mode, midnight labels also show the date for any view longer than 12 hours.

Everything week-shaped on the card follows Home Assistant's "First day of the week" user setting (your profile page) — no YAML, no card option.

• Weekly buckets — group_by: week buckets start on your configured weekday
• Date picker — the Week view's window and the calendar popup's day grid both start on that day
• X-axis ticks — weekly tick marks (automatic weekly labels and x_axis_interval: 1w) land on that weekday
• Box Plot — weekly box buckets align to the same boundary

Automatic (the setting's default) derives the first day from your language, exactly like the rest of HA — Monday for most European locales, Sunday for en-US.

Home Assistant's recorder computes weekly long-term statistics Monday-anchored on the server — there is no Sunday-based weekly row to fetch. When your week starts on any day other than Monday, the card transparently fetches daily statistics rows instead and builds the weekly buckets client-side, so totals and change aggregates stay correct. Nothing to configure. The same applies when the card's time zone differs from the Home Assistant server's: daily, weekly and monthly rows are stamped at the server's midnight, so the card then reads hourly statistics (for windows up to a year) and builds the day / week / month cells in the card's own zone.

Compare the same sensor across different time periods by adding multiple entity entries with different offset values. Each offset shifts that entity's data backward in time while keeping it aligned on the same graph.

hours_to_show: 168
entities:
  - entity: sensor.energy_consumption
    name: "This week"
    offset: 0
    color: "#ff4757"
  - entity: sensor.energy_consumption
    name: "Last week"
    offset: 168
    color: "#378ADD"
  - entity: sensor.energy_consumption
    name: "2 weeks ago"
    offset: 336
    color: "#2ecc71"

• offset: 168 means "fetch data from 168 hours (7 days) before the current display window"
• The fetched data is time-shifted forward to align with the current window on the X axis
• All rendering features work at full quality — line, bar, step, fill, gradient, points, tooltips, stacking, zoom
• Each entity with an offset gets its own API call with the correct time range

Instead of a fixed number, you can point offset to any HA entity whose state is a number (in hours). The card reads the entity's current state and re-fetches history automatically when it changes.

entities:
  - entity: sensor.energy_consumption
    name: "Current"
  - entity: sensor.energy_consumption
    name: "Comparison"
    offset: input_number.comparison_offset
    color: "#378ADD"

This works with any entity type — input_number, template sensors, or any sensor that outputs a numeric state. Combine with HA template sensors for fully dynamic comparisons:

# In HA configuration.yaml
template:
  - sensor:
      - name: "Dynamic Offset"
        state: "{{ 24 if now().weekday() < 5 else 168 }}"
        unit_of_measurement: "h"

Entity → Advanced tab → Advanced Calculations → Offset (in hours).

• Offset entities do not receive live WebSocket updates (they show historical data)
• The state row, sparkline, and gauge correctly display the last value from the offset time window — not the live entity state
• Works with all chart modes that support multiple entities
• Can be combined with value_transform, value_factor, and all other entity options
• Each offset generates a separate cache entry, so switching between views is fast

Overlay a faded "ghost" of the same entity from a previous period underneath the main series — today vs yesterday, this week vs last week, this month vs last month — with a single per-entity compare option. Unlike a manual Time Offset entry, compare needs no duplicate entity: the ghost inherits the main entity's whole configuration and stays in lock-step with it. Since v3.26, compare also accepts a list of comparisons — one ghost per entry, each reaching further back via periods_back — see Multiple comparisons below.

type: custom:statistics-graph-chart-card
card_header: Power — Today vs Yesterday
hours_to_show: 24
entities:
  - entity: sensor.power_consumption
    compare: yesterday

For full styling control, use the object form — every sub-option is optional:

type: custom:statistics-graph-chart-card
card_header: Energy — This Week vs Last Week
hours_to_show: 168
group_by: date
entities:
  - entity: sensor.energy_daily
    name: Energy
    graph_type: bar
    aggregate_func: change
    color: "#2ecc71"
    compare:
      period: last_week      # which period the ghost shows
      color: "#9b59b6"       # empty = faded main color
      opacity: 0.6           # 0.05–1
      line_style: solid      # dashed (default) | solid | dotted
      line_width: 1.5        # empty = same as main
      show_fill: true
      show_points: false
      show_in_legend: true   # empty = inherit the main entity's setting
      show_delta: true       # Δ% next to the main value in the tooltip

In the tooltip, each comparison row is preceded by a small line showing that ghost value's actual date and time (hover 15 Jul, 14:00 and the previous-period row is headed by 14 Jul, 14:00 for yesterday), so it is always clear which moment is being compared.

layout: sequential turns the overlay into a timeline: the X axis doubles backward and the previous period is drawn where it actually happened, directly before the live window — past on the left (dashed), present on the right (solid), meeting in the middle.

entities:
  - entity: sensor.temperature
    compare:
      period: previous_period
      layout: sequential

Notes:

• Works with period: previous_period on line/bar (timeline) charts; other periods and chart modes keep the overlay drawing.
• The tooltip shows each half's real date and time, and show_delta does not apply (the two halves never share an X position).
• Brush zoom works across the whole extended axis — you can zoom into the past half, the seam, or the live half, and the Y axis follows the visible data as usual.

compare also accepts a list of comparison objects — one ghost series per entry. Each entry takes the full sub-option set above plus periods_back, which sets how many periods back that ghost reaches:

type: custom:statistics-graph-chart-card
card_header: Power — vs the last two periods
hours_to_show: 24
entities:
  - entity: sensor.power_consumption
    compare:
      - periods_back: 1        # previous period
      - periods_back: 2        # two periods ago
      - periods_back: 3
        line_style: dotted
        color: "#9b59b6"

• Follows the date picker. With the picker on Week, the entries above show the last three weeks; switch to Year and the same config shows the last three years — calendar-aligned in Month/Year modes, leap years handled.
• Each ghost is distinct. Later entries fade progressively by default (opacity 0.45 → 0.30 → 0.20 …), and legend entries beyond the first read "Name (previous period ×2)", "… ×3", and so on.
• Per-ghost tooltip. Every ghost row is headed by its own date sub-header, and with multiple comparisons each ghost row carries its own Δ% against the current value. With a single comparison the tooltip looks exactly as in v3.25 — one date sub-header and the Δ% next to the main value.
• Every entry still takes the full style set (period, color, opacity, line_style, line_width, show_fill, show_average, show_points, show_in_legend, show_delta, hide_on_load), and hiding the main series from the legend hides all of its ghosts.
• Existing single string/object compare configs are untouched — the list form is purely additive.

• The ghost is drawn faded and dashed under the main series and is named "<main name> (previous period)" — the suffix follows the dashboard language.
• previous_period shifts by the current window length. In the date picker's Month / Year modes the shift is calendar-aware: July compares against June, wall-clock aligned, and month-end dates are clamped (Mar 31 → Feb 28/29). yesterday, last_week and the picker's Day / Week modes shift by whole days, wall-clock anchored at the window start (23 or 25 hours across a daylight-saving change); a number of hours stays exact.
• A main entity with its own offset compares against the previous period of its shifted window.
• Clicking the entity in the legend or its state row toggles the main series and its ghosts together.
• (improved in v3.28) Under stacked: true, ghosts stack with each other — the previous period appears as its own faded stacked column next to the current one (one ghost stack per comparison entry, honoring stack_group). Ghosts never stack onto the current period and stay excluded from the tooltip's grand Total.
• (new in v3.28) With stacked comparisons the tooltip also shows the previous period's stack total — e.g. "Aktuell Total (previous period)", fully translated — and the current stack's Total row carries a Δ% against it.
• Ghost values go through exactly the same aggregation pipeline as the main entity (aggregate_func, points_per_hour, group_by, transforms) — the comparison is truly like-for-like.
• Timeline and State Timeline charts (State Timeline since v4.02). Ignored for candlestick, fixed_value, and data_attribute entities, and in sparkline mode.

Per-entity → Graph tab → Period Comparison section (shown in Timeline and State Timeline modes). Redesigned as a list in v3.26:

• The section starts empty with an Add Comparison button; each click adds one comparison row and steps the default Periods Back automatically (1, 2, 3 …).
• Each row holds a period select (labels now read Previous Period / Day Before / Week Before / Month Before / Year Before — only the labels changed, the YAML values are still previous_period, yesterday, last_week, last_month, last_year), a Periods Back input, line style, color, opacity, a Layout dropdown (Overlay | Sequential — enabled while the period is Previous Period, v4.02), a Show Δ% in tooltip toggle, and a delete button.
• Legacy string/object compare configs load into the list unchanged, and a one-row list commits back to the legacy short form — your YAML stays as compact as before.

Some sensors expose a forecast value — their current state represents what is predicted for N hours in the future, not what is happening right now. Typical examples:

• sensor.solcast_pv_forecast_leistung_in_1_stunde — PV power expected in 1 hour
• A template sensor whose state is "temperature in 3 hours"
• A weather forecast exposed as a numeric future-hour prediction

Plotting these directly is misleading: the line shows each prediction at the time it was recorded, not at the time it is predicting. forecast_horizon: N fixes this by shifting each recorded data point forward by N hours on the X-axis so every point lands at the moment it is forecasting.

type: custom:statistics-graph-chart-card
graph_start_hour: now
show_full_period: true
entities:
  - entity: sensor.solcast_pv_forecast_leistung_in_1_stunde
    name: "Forecast +1h"
    forecast_horizon: 1

The result: a line that extends 1 hour into the future past the "now" marker, representing the forecast for each upcoming moment. The X-axis end is automatically extended by the largest forecast_horizon across all entities so shifted points stay visible.

The forecast_horizon value should match the actual prediction horizon the sensor represents:

Setting a value that doesn't match the sensor's real horizon will still shift the line — but the displayed time no longer corresponds to what the sensor is actually predicting.

Some forecast integrations (Solcast PV, EPEX spot prices, weather APIs) expose future data through entity attributes — a single sensor whose attributes contain an array of timestamped points covering the next 24–48 hours. Combined with data_attribute, you can plot this future data directly. But what if you want to see tomorrow's forecast on today's chart timeline for an at-a-glance comparison?

A negative forecast_horizon shifts each point backward in time. Setting -24 moves tomorrow's points 24 hours earlier so they appear at today's clock positions:

type: custom:statistics-graph-chart-card
show_legend: true
entities:
  - entity: sensor.solcast_pv_forecast_tomorrow
    data_attribute: detailedHourly
    data_time_field: period_start
    data_value_field: pv_estimate
    name: "Tomorrow's forecast (shown today)"
    forecast_horizon: -24

The X-axis stays anchored to today — only the data slides into view. Combine with the live PV sensor (no horizon) on the same chart to see today's reality next to tomorrow's prediction, both aligned to the same hours.

forecast_horizon and offset are orthogonal:

• offset shifts the fetch window backward (for past-period overlay comparison)
• forecast_horizon shifts the display forward (positive) or backward (negative)

Both can be used on the same entity. Example: overlay yesterday's 1-hour forecast sensor onto today's timeline, shifted 1h forward:

entities:
  - entity: sensor.solcast_pv_forecast_leistung_in_1_stunde
    offset: 24            # fetch yesterday's recordings
    forecast_horizon: 1   # show them shifted 1h forward
    name: "Yesterday's +1h forecast"

Entity → Advanced tab → Forecast Horizon (in hours, supports decimals — including negative values).

• Leave empty (or 0) to disable — the sensor plots at its recording time as before
• The fetch window is extended backward by the largest horizon so past recordings can be retrieved and shifted forward into the visible future range
• Works with live state updates — new recordings appear on the chart at recording time + horizon
• Multiple entities can use different horizons — the X-axis is extended to cover the largest one

Change the data resolution and the bucketing strategy directly on the card — no editor round-trip.

type: custom:statistics-graph-chart-card
show_pph_picker: true
show_group_by_picker: true
group_by_picker_position: right
entities:
  - entity: sensor.power

• Each dropdown starts on Auto (…), showing your configured value; picking anything else overrides it for this card only.
• Selections persist across reloads and take priority over Auto Scale while active.
• The Group By picker offers Interval, Hour, 2H / 3H / 4H / 6H / 12H, Date, Week, Month and Year.

Each picker has its own, fully independent sync group — same mechanism as date_picker_group:

# Controller card
show_pph_picker: true
pph_picker_group: page

# Receiver cards — no picker shown, still follow
pph_picker_group: page

pph_picker_group and group_by_picker_group don't interact: a card can follow one page-wide resolution group and a different bucketing group (or none).

General Settings → Overlay tab → Card Overlays → Points/Hour Picker and Group By Picker rows. The Group fields are always editable, even while the toggles are off.

group_by: raw turns bucketing off entirely: every recorded sample is drawn at its exact timestamp, with no averaging and no resampling — points_per_hour is ignored.

type: custom:statistics-graph-chart-card
group_by: raw
hours_to_show: 24
entities:
  - entity: binary_sensor.front_door
    name: Front Door
    graph_type: step
    state_map:
      - value: "off"
      - value: "on"

• Step charts of binary / state sensors — a door, pump, or heating-demand signal changes state at precise moments; bucketing smears those edges. Raw mode preserves every transition exactly where it happened.
• Sensors that record few, meaningful samples where a value interpolated into buckets would be misleading.

The Group By dropdown offers "Raw (no grouping)" whenever at least one entity uses graph_type: step — and always when the config already contains group_by: raw.

Apply a JavaScript expression to every data point before graphing. The transform has access to the current value and series-level statistics, making it possible to normalize, compare, and reshape data in ways that weren't possible before.

All variables are computed after value_factor is applied, before the transform runs.

Display cumulative meter readings as relative consumption starting from zero:

entities:
  - entity: sensor.gas_meter
    value_transform: "return x - first;"

A gas meter reading 2200, 2210, 2225, 2240 becomes 0, 10, 25, 40.

A common use case: a single power sensor reports positive values for export and negative values for import. Use two entity entries with different transforms to separate them:

entities:
  - entity: sensor.grid_power
    name: "Grid Export"
    color: "#2ecc71"
    value_transform: "return x > 0 ? x : 0"

  - entity: sensor.grid_power
    name: "Grid Import"
    color: "#e74c3c"
    value_transform: "return x < 0 ? -x : 0"

Besides the value variables, the expression also receives four read-only time variables:

They make a per-entity time filter possible without a template entity — pair them with return … : null to draw a series only over the part of the X axis you want.

If your expression declares its own t, now, hour or weekday (with var, let or const), the card compiles it without the time variables so your own names keep working exactly as before.

Entity → Advanced tab → Advanced Calculations → Value Transform — a monospace text input field. Enter the expression directly (e.g., return x - first).

• The expression must be valid JavaScript and include a return statement
• Returning null leaves a visible gap at that point: the line breaks there rather than joining across the hole, and the tooltip, moving averages and range band all respect it. An expression that throws or returns a non-number does the same (changed in v4.04 — these points used to be removed, which let the line connect straight over them)
• Applied to every data point individually — both historical and live values
• Works with all chart modes, aggregation functions, and other entity options
• Context variables (first, min, etc.) are only available when processing a full data series — in the state row live value display, all context variables equal x

Multiply a series by the value of another entity over time — turn a kWh consumption chart into a money chart using a dynamic price sensor (Nordpool, EPEX, Tibber, a utility tariff helper). Per-entity price_entity needs no template sensor and no duplicate entity: the card bills the consumption itself.

type: custom:statistics-graph-chart-card
card_header: Energy Cost
hours_to_show: 168
group_by: date
entities:
  - entity: sensor.energy_meter
    name: Cost
    graph_type: bar
    aggregate_func: change
    price_entity: sensor.electricity_price
    unit: "€"
    decimals: 2

• The price is read as a step function from the price entity's own history — each price is valid from the moment it was recorded until the next change. Long windows automatically use long-term statistics (hourly mean) for the price series.
• The multiplication happens per consumption slice, before bucketing — every slice of consumption is billed at the price that was active at that moment, so each bucket is the exact sum Σ(valueᵢ × priceᵢ).
• Designed for aggregate_func: change on cumulative energy counters — set unit to your currency so the state row, tooltip, and axis all read as money.
• price_attribute reads an attribute of the price entity instead of its state — dot notation is supported for nested paths (e.g. raw_today.0.value).
• A state change of the tariff entity auto-refreshes the card, so a price update redraws the cost immediately.
• Period Comparison ghosts are billed at their own period's prices — last week's ghost uses last week's tariffs, keeping the comparison honest.
• Not applied to fixed_value or data_attribute entities.

Multiplying the period's total consumption by the average price is only correct when consumption is flat. With time-of-use tariffs the expensive hours tend to be exactly the high-consumption hours, so average × total systematically misstates the bill. Billing every slice at its own momentary price reproduces what the utility actually charges.

Entity → Advanced tab → Advanced Calculations → Price Entity and Price Attribute inputs.

Plot the combination of two entities — most often their difference — without creating a template sensor. ref_entity names the second entity and ref_op says how to combine them:

type: custom:statistics-graph-chart-card
hours_to_show: 24
entities:
  # indoor − outdoor, the classic delta. ref_op defaults to subtract,
  # and with no name: the series is labelled "Indoor − Outdoor" automatically.
  - entity: sensor.indoor_temperature
    ref_entity: sensor.outdoor_temperature

  - entity: sensor.solar_production
    name: Net export
    ref_entity: sensor.house_consumption
    ref_op: subtract

  # the reference can come from an attribute (e.g. a weather entity)
  - entity: sensor.pool_temperature
    ref_entity: weather.home
    ref_attribute: temperature
    ref_op: divide

The reference entity's own history is fetched alongside your data and read as a step function: every sample of the main entity is combined with the reference value that was valid at that moment. The math runs before bucketing, so avg over a bucket is the average of the difference, and min/max are the smallest/largest instantaneous gap — not min(A) − min(B).

• Reversed operators. reverse_subtract gives B − A and reverse_divide gives B ÷ A. This is not the same as swapping the two entity ids: the main entity supplies the timeline the reference is sampled onto, plus the unit, aggregation, data source, colour and offset. Keep the better-sampled sensor as entity: and flip the arithmetic instead (e.g. COP = heat ÷ power while power stays the main series).

• subtract / add / reverse_subtract combine levels — or, with a delta aggregation, whole buckets. With avg, min, max, last, first or median the reference is sampled at each of the main entity's readings. With change, diff, sum or delta (v4.03) the two entities are first aggregated the same way, then combined per bucket — the way to add two daily-production meters into one monthly total:

  entities:
    - entity: sensor.goodwe_today_s_pv_generation
      name: Total production
      ref_entity: sensor.solaredge_production_today
      ref_op: add
      aggregate_func: sum
      graph_type: bar
  group_by: month

  A bucket in which one side has no data counts that side as 0, so a month with only one inverter reporting still shows the other's production; price_entity is applied to both sides. The bucket-wise path needs an entity: series in a bucketed chart — a statistic_id-only or attribute series still renders empty with a console warning. multiply / divide are allowed with every aggregation — that is exactly what price_entity does.

• Carry-forward, but nothing invented. The reference is held until it next changes — the same rule Home Assistant itself uses for a state, and the same one price_entity follows. That is what makes a step-shaped reference (a setpoint, an input_number, a mode) work. What the card will not do is invent a value before the reference's first sample: that stretch is a gap. Since the card carries values across gaps by default, a reference that dies mid-window shows as a flat line — add break_on_null: true if you would rather the line break there.

• Both operands should share a unit for subtract/add; the result keeps the main entity's unit. For multiply/divide set unit yourself.

• value_factor and invert apply to the main entity only, before the combination.

• The state row and the trend arrow follow the combined series, not the bare main entity.

• Not available on data_attribute (forecast-array) or fixed_value rows.

• Only one reference and one operator per entity. For multi-operand formulas (A − B − C) you still need a template sensor — a general cross-entity expression is planned for a later release.

Note: data_value_expression + data_vars do not do this. They only apply to an attribute-array data source, and data_vars resolves each name to the referenced entity's current state — a constant, not a series. Use ref_entity for math against another entity over time.

Editor: Entity → Advanced → Reference Entity, Operation, Reference Attribute.

The Range Band feature draws a shaded min/max area behind each line entity, showing how much the value fluctuated within each aggregation bucket.

When points_per_hour aggregates multiple raw data points into a single graph point, the displayed value is typically the average (or whichever aggregate_func you've chosen). The range band shows the full min → max spread of raw values that were combined — so you can see both the trend and the volatility.

entities:
  - entity: sensor.outdoor_temperature
    show_range_band: true
    color: "#ff4757"
  - entity: sensor.indoor_temperature
    show_range_band: false
    color: "#378ADD"

• Temperature: narrow band = stable climate, wide band = fluctuating (e.g. HVAC cycling)
• Energy: see consumption spikes vs steady draw within each time bucket
• Sensor noise: distinguish real signal changes from noisy sensor readings

Entity → Graph tab → Line section → Range Band toggle (next to Data Points). Timeline mode only.

When hovering, an additional row shows the range: Range: 21.2 → 22.8 °C.

Overlay one or more simple moving-average (SMA) lines on top of any entity — a smoothed trend line that averages the last N buckets. Add as many as you like, each with its own period, color, and width. Perfect for separating signal from noise on busy sensors (CPU load, power, prices) or for classic short/long crossover views (e.g. MA7 vs MA26).

entities:
  - entity: sensor.keenetic_router_cpu_load
    graph_type: bar
    moving_averages:
      - period: 7          # short MA — averages the last 7 buckets
        color: "#ffffff"
        show_label: true   # draw a small "MA7" tag on the line
      - period: 26         # long MA — averages the last 26 buckets
        color: "#f1c40f"
        width: 2           # optional line thickness (px)
        show_label: true   # draw "MA26"

Each line's period is a number of buckets, and the bucket size comes from the chart's timeframe — points_per_hour in interval mode, or group_by (hour / date / week / month / year). So with group_by: hour, period: 26 averages the last 26 hourly buckets (MA26). With points_per_hour: 12 (one bucket every 5 minutes), period: 26 covers the last ~130 minutes.

A 26-bucket average normally needs 26 buckets of history before it can produce its first value. If your visible window only holds a handful of buckets (e.g. hours_to_show: 24 with group_by: hour → 24 buckets), a plain MA26 would never have enough data to draw.

This card solves that by extending the history fetch backward automatically by the amount the longest moving average needs — independent of the visible window. The MA is computed over that extended range and then trimmed to the window, so MA26 draws fully across a 24-hour view without you having to widen hours_to_show or scroll. The visible chart, axis, statistics, and extrema are unchanged — only the moving-average lines use the extra look-back.

The look-back applies to entities whose data comes from History or long-term statistics. Synthetic sources (fixed_value, data_attribute) average only what's in the window.

When the entity is drawn as candlesticks, each moving average uses the close of every candle (otherwise it averages the bucket value), so an MA over candles behaves like the moving averages on a trading chart.

Turn on show_label for any line to draw a small MA7, MA26 … tag right at the end of that line, so you can tell several averages apart at a glance:

    moving_averages:
      - period: 7
        color: "#ffffff"
        show_label: true

The label text is the period prefixed with MA (MA7, MA26, …). It's drawn at the end of the line and clamped inside the chart, so it never spills outside the plot, with a subtle background halo so it stays readable over the line and the data. It's off by default — flip the Label switch next to the color picker, or set show_label: true in YAML.

• Each moving average is plotted against the entity's own Y axis, so it lines up with the bars / line / candles it summarizes.
• Lines render in their configured color; leave color empty to fall back to a default. width defaults to a thin line.
• Timeline mode only.

Per-entity → Graph tab → Moving Averages (just below the Graph card). Click Add Moving Average to add a line, set its Period and Color, flip Label to print an MA7-style tag on the line, and use the ✕ button to remove one.

When a sensor goes unavailable or unknown, the card normally keeps the line continuous by carrying the last known value forward across the gap. That's great for short blips (brief WiFi drops, bucket-level reporting irregularity) but can hide genuine multi-hour outages behind a flat line. The per-entity break_on_null option lets you opt in to a visible break instead.

entities:
  - entity: sensor.steady_sensor
    # default — continuous line, last known value carried across any gap

  - entity: sensor.flakey_sensor
    break_on_null: true
    # short blips still connect, but longer outages appear as gaps

  - entity: sensor.very_specific
    break_on_null: true
    carry_forward_ms: 900000   # advanced — 15 min threshold

A pure "zero carry-forward" mode turns out to be too aggressive on real-world sensors. When bucket width is finer than the sensor's natural sample interval (a common setup at high points_per_hour), dozens of buckets between two real samples end up empty even though the sensor is perfectly healthy. The time-based threshold distinguishes "I'm waiting for the next sample" from "the device has been gone for a while" — which is the distinction users actually want to see.

Entity → Graph tab → Graph section → Break on Gaps toggle (next to Show Average and Data Labels). Shown in every chart mode — carry-forward affects the bucketed data, so it matters wherever those buckets are drawn.

• Changed in v3.25 — an empty bucket now carries the previous bucket's last recorded sample (its exit state) forward, not the previous bucket's aggregated value. With aggregate_func: first or max, a momentary spike no longer smears across the quiet buckets that follow it; with avg, the carried value is the last actual reading instead of the previous bucket's average.
• Does not affect value_transform scripts that return null — those buckets are already null before carry-forward logic runs, so they stay a visible gap either way.
• Works independently per entity, so you can mix well-behaved sensors (continuous line) with flakey ones (visible gaps) on the same card.

Read chart data directly from an entity attribute instead of history. The attribute must contain an array of objects with time and value fields. The X-axis automatically extends into the future when data contains future timestamps.

Ideal for energy spot prices, weather forecasts, and solar production predictions. No history or statistics API calls are made for these entities.

entities:
  - entity: sensor.epex_spot_price
    data_attribute: data
    data_time_field: start_time
    data_value_field: price_per_kwh
    value_factor: 2
    graph_type: step
    name: "Electricity Price"

Common configurations:

Compatible with existing value_factor, value_transform, aggregate_func, and group_by. The calendar group_by modes (hour, date, week, month, year) regroup the array when the requested cell is coarser than its native spacing — 96 quarter-hourly prices under group_by: hour become 24 hourly values combined with aggregate_func — and pass it through untouched otherwise, so an already-hourly array stays as published. interval (the default) and raw never regroup; the fixed 2h–12h modes are not supported for attribute arrays. points_per_hour does not apply — it controls fetching, and an attribute source fetches nothing. The time and value field names support nested paths via dot notation (e.g. forecast.0.temperature or integrated.0.value).

Sometimes the value you want isn't a single field — you need to combine several fields from each element, fold in other entities (fees, tax rates, tariffs), and apply a formula. Set data_value_expression instead of data_value_field: a small arithmetic expression evaluated for every array element, with the element's own fields in scope plus any names you map in data_vars.

entities:
  - entity: sensor.tibber_hourly_cost
    name: Electricity
    graph_type: bar
    data_attribute: nodes
    data_time_field: from
    data_time_unit: iso
    data_value_expression: "(unitPrice - unitPriceVAT) * 100 * consumption * (1 + mwst)"
    data_vars:
      mwst: input_number.vat_rate