⬆️ Improvements & 🐛 Bug fixes
If you are updating from v3.24 please see previous release 3.25, 3.26, 3.27, v3.28
Release v3.29
✨Extended Window — scroll back through history at the selected period's scale
Horizontal scrolling into the past without changing the scale you're looking at. The new card-level extended_window_multiplier renders N× the selected period and opens scrolled to the newest part:
show_date_picker: true
extended_window_multiplier: 2- The screen shows exactly the period you picked — same scale, same bucket density as a card without scrolling. No more "zoomed crop of a bigger chart".
- Scroll back (scrollbar or mouse wheel) through the extra (N−1) periods of history behind it.
- Follows the date picker: on a Week view, one extra week is scrollable behind the current one; switch to Day and it's one extra day — nothing to reconfigure. Works with
hours_to_showandgraph_startwindows too. - The picker's header and arrows stay on the selected period — scrolling is a peek; the arrows remain the navigation.
- Forecast-aware: with forecast entities (
data_attributearrays orforecast_horizondata reaching into the future) the chart opens with the current period in view — right edge at "now", scroll right for the forecast, left for history. Previously it opened on the furthest forecast point, leaving "now" off-screen. Withgraph_startset, the forecast tail is now rendered too (scrollable) instead of being cut off at the period end, and the viewport spans the full selected period so the scale stays stable through the day. (show_full_periodkeeps its "whole period, cut at its end" contract and is not extended.) - Period Comparison, annotations and the now-line keep working;
previous_periodghosts still shift by the selected period, not the extended render window. - Bounded by design (N ≤ 10): memory and recorder load stay predictable — this is why it's a multiplier rather than infinite scroll.
- Editor: Chart → Graph Data → Extended Window (× field next to Visible Window).
1/empty = off; overrides Visible Window while active.
✨ entity variable in entity-level templates — toggles, colors and names
Entity-level templates now receive the row's own entity id as a ready-made entity variable — first shipped for the display toggles (show_graph, show_state, show_in_legend, …) and now extended to the entity-level string fields: color, name, tooltip_name, icon, icon_color, state_color. One generic template can be copy-pasted across 20 entities unchanged:
show_graph: "{{ area_id(entity) == states('input_select.selected_zone') }}"
name: "{{ device_attr(entity, 'name_by_user') or device_attr(entity, 'name') }}"
color: "{{ state_attr('sensor.entity_colors','entities')[device_attr(entity, 'name')] | default('red') }}"Previously every template needed a hand-written {% set entity = 'sensor.…' %} line — with three templated toggles on twenty entities, that was sixty lines of boilerplate to keep in sync (and per-entity colors/names from a central registry were simply impossible without it). Templates that mention entity are evaluated once per entity (Home Assistant renders them with a per-entity variables payload); templates that don't still share a single deduplicated subscription, and templates that set their own {% set entity %} shadow the variable — existing cards are unaffected either way. Bonus: templated names now resolve in the chart tooltip immediately instead of one refresh late, and a templated tooltip_name renders its result instead of the raw template text.
✨ point_size — pick your own data point size
The dots drawn by the Data Points toggle were always auto-sized from the line width. The new entity-level point_size sets their radius in pixels:
entities:
- entity: sensor.temperature
show_points: true
point_size: 5- Leave it unset and nothing changes — dots keep scaling with
line_widthas before. - Also applies to the dot markers in scatter and radar modes (via YAML; in scatter, set it on the first entity — the one that styles the dots).
- Editor: the Point Size field appears right under the Data Points toggle whenever it is enabled.
✨ State Map labels in the chart tooltip
Entities with a state_map now show the mapped label in the timeline tooltip instead of a bare number: a media player reads YouTube, a door sensor reads on — previously the tooltip printed 1.0. When values are aggregated the nearest entry's label is used; entities without a map are untouched. Auto-detected maps (binary sensors, selects in step mode) use Home Assistant's localized state names — the same names the state-timeline tooltip shows — while labels you set yourself are always used verbatim.
✨ Custom Scale Rules now drive the axis and tooltip too
When an auto_scale_rules entry rescales the chart (say, a group_by: date card dropping to hourly buckets for a Day view), the X-axis and tooltip used to keep the base scale's presentation: a hand-set x_axis_interval: 1d left the axis nearly empty, and a datetime_format: DD MMM YYYY tooltip showed no time-of-day for hourly points (#308).
While a rule is active, the card-level x_axis_interval and datetime_format are now suspended — automatic ticks and locale-aware date+time formatting take over, matching the rule's scale. Prefer full control? Each rule accepts its own overrides:
auto_scale_rules:
- up_to_hours: 24
group_by: hour
x_axis_interval: 4h # optional — otherwise automatic while the rule is active
datetime_format: "HH:mm" # optional — otherwise locale date+timeCards without auto_scale_points (or when no rule matches the window) are untouched — your explicit axis settings apply exactly as before.
🛠 Fixes & reliability
Stale-translation fix — cached translations.js no longer survives an update
The line now always reaches the "now" line — every calendar grouping
With date / week / month / year grouping, the in-progress cell is stamped at its start — so on a Week view the line's last point sat at today 00:00 while the now-line (correctly) stood at the current time, up to a full day apart. v3.27 fixed this for hour cells only; now every calendar grouping moves the in-progress cell's tip to "now" (lines and steps — bars keep their cell geometry, where the now-line walks through the current bar instead). Relative windows (hours_to_show) get the same treatment — a subtle gate previously skipped exactly the live windows this exists for. Past periods are never touched.
Templated show_graph: false now hides comparison ghosts too
When a display toggle held a Jinja template — e.g. show_graph: "{{ states('input_boolean.x') == 'on' }}" — the resolved value was applied to the main series only: its Period Comparison ghost kept the raw template text internally and stayed visible, so a hidden main left an orphaned previous-period line on the chart. Resolved template toggles now propagate to the main's ghosts as well (ghost-specific switches like the per-comparison Fill / Show Average / Hide on Load are untouched), so main and ghosts appear and disappear together — same as clicking them in the legend.