Add `include_current_interval` parameter to `find_cheapest_block` and
`find_cheapest_schedule` services, controlling whether the currently
active price interval can be the start of the selected window.
Add power-profile weighting to `find_cheapest_contiguous_window`: accepts
an optional `power_profile` list that weights each interval's price by
relative power draw (e.g. heat-up phase heavier than steady state). Without
a profile the behaviour is unchanged (uniform weighting).
Extend search-range tests and add price-window unit tests covering weighted
and unweighted scenarios, edge cases, and sequential scheduling interactions.
Update scheduling-actions documentation with parameter and profile examples.
Impact: Users can now model appliances with non-uniform power draw (e.g. heat
pumps, washing machines) to find truly cheapest windows based on actual energy
cost rather than average price.
Accepts battery parameters (capacity, current/target SoC, max power) and
returns a cost-minimized charging schedule with per-interval power, SoC
progression, and total cost — no manual duration calculation needed.
Supports fixed, continuous (min_charge_power_w), and stepped
(charge_power_steps_w) charging modes, deadline-aware two-pass planning
(must_reach_soc + must_reach_by / must_reach_by_event), and round-trip
economics (expected_discharge_price, reserve_for_discharge,
max_cost_per_kwh) for arbitrage use cases. Includes min_charge_duration
and max_cycles_per_day constraints.
Groups deadline fields (must_reach_soc_*, must_reach_by,
must_reach_by_event) into a dedicated section so a deadline use case can
be configured in one place. Battery section lists capacity before the
percent SoC fields that depend on it. Response exposes stable reason
codes (already_at_target, energy_unreachable, energy_unreachable_by_
deadline, no_intervals_after_economic_filter, …) documented in the
service description and user docs.
automation-examples.md:
- Add info callout blocks with "Blueprint available" badges and
one-click import links for each appliance section (dishwasher,
washing machine, dryer, EV charging, pipeline)
- Update YAML examples to reflect current service API (remove
relaxation_applied template, fix indentation)
sensor-reference.md:
- Remove stale data-refs attributes from current_price_trend,
next_price_trend_change, and today_volatility anchors
examples/:
- Add examples/scripts/ directory with placeholder for
tibber_notify_residents.yaml script example
User-Impact: none
Replace workaround recommendations (2× find_cheapest_block) with the
new sequential: true parameter. Rewrite washer→dryer example as a single
find_cheapest_schedule call. Update quick reference tables.
Release-Notes: skip
Updated the dishwasher automation to include planning and execution steps using input_datetime helpers for better reliability across restarts. Clarified the use of find_cheapest_schedule for independent appliances and added caution regarding task order. Improved messaging in notifications for planned schedules.
Impact: Users can now schedule appliances more reliably, ensuring planned start times persist through Home Assistant restarts.
docs(sidebars): rename automation section for clarity
Changed the sidebar label from '🤖 Automations' to '🤖 Automations & Usage' to better reflect the content and improve user navigation.
Impact: Users will find it easier to locate automation-related documentation.
The old extension algorithm extended a single late-evening period forward
past midnight by appending qualifying intervals one-directionally. This
caused false extensions (e.g. peak 19:45–21:30 extended to 01:00 by
pulling in 14 declining-price intervals).
Replace with bidirectional bridging: two independently qualifying periods
on both sides of midnight are merged only when separated by a small gap
(≤4 intervals = 1 hour) and the combined period passes the CV quality
gate (≤25%). A period ending well before midnight is no longer touched.
User-Impact: none
Implement a new service that progressively relaxes user-defined filters to ensure a result is always returned when price data is available. This includes three phases: halving the minimum distance from average, expanding level filters, and reducing duration.
Impact: Users will receive results even when strict filters would otherwise yield no matches, improving the reliability of scheduling actions.
feat(pricing): enhance scheduling actions with new parameters
Introduce new parameters `smooth_outliers`, `min_distance_from_avg`, and `allow_relaxation` to scheduling actions, allowing for better control over price selection and ensuring results are meaningfully different from average prices.
Impact: Users can now fine-tune their scheduling actions to avoid marginal savings and ensure more uniform pricing within selected windows.
docs(scheduling): update documentation for new features
Revise the scheduling actions documentation to include new parameters and their effects, such as outlier smoothing and minimum distance from average, along with examples for better user understanding.
Impact: Users will have clearer guidance on how to utilize new features effectively in their automations.
test(scheduling): add tests for new relaxation logic
Implement unit tests to verify the behavior of the new relaxation logic in scheduling actions, ensuring that filters are correctly relaxed and results are returned as expected.
Impact: Increased test coverage and reliability of the scheduling features.
Improve the logic for trimming trailing gap-tolerance intervals in periods to prevent misleading period end shifts. Additionally, refine cross-day boundary validation for both best and peak periods to eliminate false extremes caused by inter-day reference shifts.
Impact: More accurate period calculations and reduced artifacts in reported price periods.
Enhanced descriptions for V-shaped and U-shaped price days to include their characteristics and how they are classified as 'valley' by the Day Pattern sensor.
Impact: Users gain a clearer understanding of price patterns and their implications for automation.
docs(glossary): update V-Shaped Day definition for clarity
Revised the definition of V-Shaped Day to include U-Shaped Day as an informal term, emphasizing the classification as 'valley' by the Day Pattern sensor.
Impact: Users receive a more comprehensive explanation of price day classifications.
docs(period-calculation): improve algorithm overview and phase descriptions
Added detailed explanations for each phase of the period calculation algorithm, including visual aids and clarifications on the importance of each phase.
Impact: Users can better understand the underlying logic of price period calculations.
docs(sensors-price-phases): refine sensor descriptions for clarity
Updated descriptions of price phase sensors to clarify the shapes and conditions they represent, including distinctions between V-shaped and U-shaped curves.
Impact: Users benefit from improved clarity on sensor classifications and their applications in automations.
Introduce additional sensors for current price phase, phase duration, and upcoming phase timings to enhance user visibility of pricing dynamics.
Impact: Users can now monitor current price phases and their durations, improving decision-making based on real-time pricing information.
Modified the TypeScript configuration files to set the ignoreDeprecations option to "6.0" for improved compatibility with future TypeScript versions.
User-Impact: none
Revised the descriptions and names for the previous interval price rank entities across multiple language translation files to enhance clarity and consistency.
Impact: Users will see improved terminology in the interface, making it clearer that the ranks refer to the previous interval's prices.
Updated the sensor reference documentation to remove obsolete price phase sensors, ensuring clarity and relevance for users.
Impact: Users will see a cleaner and more accurate list of available sensors.
Introduced comprehensive documentation for price phase sensors, detailing their functionality and usage. Updated links in existing documentation for clarity.
Impact: Users can now understand and utilize price phase sensors effectively in their configurations.
Introduced new documentation files covering various configuration aspects such as chart data export, currency display, general settings, peak price periods, price levels, price ratings, price trends, and volatility. Each section provides detailed explanations of settings, their impacts, and migration guidance for legacy features.
Impact: Users gain clear guidance on configuring the Tibber Prices integration, enhancing usability and understanding of features.
### Notes
- New files include config-chart-export.md, config-currency.md, config-general.md, config-peak-price.md, config-price-level.md, config-price-rating.md, config-price-trend.md, config-runtime-overrides.md, and config-volatility.md.
- Updated sidebar for improved navigation within the documentation.
Restructure configuration.md: separate "stored precision" from "default display
precision" tables to avoid confusion between internal representation and what is
shown in dashboards. Add note that HA shows its own unit-change dialog (delayed);
our repair issue appears immediately as step 1. Recommend deleting old statistics
data rather than re-labeling, which would leave wrong values with the new unit.
Update faq.md examples to use display precision values for consistency with the
documentation.
Enhance the documentation for volatility sensors by explaining that the maximum price rank will never reach 100% and providing a YAML automation example for managing device usage during peak pricing.
Impact: Users gain a clearer understanding of price rank behavior and practical automation guidance.
Updated the long descriptions and usage tips for the price trend change sensors in multiple languages (de, en, nb, nl, sv) to provide clearer guidance on detection mechanics and expected behavior during V-shaped price days.
Impact: Users will have a better understanding of how the sensors operate and can make more informed decisions regarding automation based on price trends.
Rename the three existing price rank sensors from price_rank_* to
current_interval_price_rank_* to clarify they rank the current
quarter-hour interval's price, not a daily aggregate — consistent with
current_interval_price_level / current_interval_price_rating naming.
Add 8 new rank sensors covering additional subjects and reference windows:
- next_interval_price_rank_{today,today_tomorrow}
- previous_interval_price_rank_{today,today_tomorrow}
- current_hour_price_rank_{today,today_tomorrow} (5-interval rolling avg)
- next_hour_price_rank_{today,today_tomorrow} (5-interval rolling avg)
All new sensors are disabled by default. The volatility calculator gains a
subject parameter (_get_subject_price / _get_subject_price_attr_key /
_get_rolling_hour_avg_price) to select which price to rank. Sensor key
routing in value_getters.py and attributes/__init__.py updated accordingly.
No migration entries needed — the original price_rank_* sensors were never
released to users.
All 5 translation files updated. sensor-reference.md regenerated (129 entities).
Impact: Users can now track price rank for the next interval (look-ahead),
the previous interval (logging), and rolling hourly averages — for both
same-day and two-day reference windows.
Convert four-space-indented list items (`- item`) to standard two-space
(`- item`) in AGENTS.md, CONTRIBUTING.md, README.md, and all Docusaurus
documentation pages (developer and user, including versioned snapshots).
No content changes.
Release-Notes: skip
Update sensors-volatility.md to cover the three new price rank sensors and the
IQR-based volatility attributes (typical price band / price spike count).
Section headers include technical terms in parentheses for experts:
"Typical Price Band Statistics (IQR)" and "Price Rank Sensors (Percentile Rank)".
Attribute tables list Tukey fence formulas and plain-language explanations
side-by-side.
Regenerate sensor-reference.md to include price_rank_today,
price_rank_tomorrow, and price_rank_today_tomorrow with translations for all
five supported languages.
Impact: Users have full documentation for the new sensors including examples,
formulas, and a multi-language lookup table.
Consistent naming with the period_count_* family introduced in the
previous commit (period_count_total, period_count_today,
period_count_tomorrow).
periods_remaining was the last attribute in the navigation triplet
using the old plural form. Renamed to period_count_remaining to follow
the established pattern: all countable period metrics use the
period_count_* prefix.
BREAKING CHANGE: periods_remaining renamed to period_count_remaining.
Impact: All four period count attributes now share the same prefix
(period_count_total, period_count_today, period_count_tomorrow,
period_count_remaining), making automation templates more predictable.
Removed periods_found_total and replaced with period_count_today /
period_count_tomorrow. The old attribute counted all periods including
yesterday (coordinator scope), causing a discrepancy vs. the displayed
list (sensor scope, today+tomorrow only).
Renamed periods_total → period_count_total for naming consistency with
the new per-day attributes. Recalculate period_position / period_count_total /
periods_remaining after the today+tomorrow filter so all three navigation
attributes reflect the filtered scope.
period_count_tomorrow is always present (0 when no tomorrow data or no
periods found), enabling automations without default(0) guards.
Removed internal periods_found key from relaxation metadata — it was
only consumed by add_calculation_summary_attributes which is now removed.
BREAKING CHANGE: periods_found_total removed (replace with
period_count_today + period_count_tomorrow). periods_total renamed to
period_count_total.
Impact: Period navigation attributes (position/total/remaining) now
correctly reflect today+tomorrow scope. Per-day counts allow automations
to distinguish "2 periods today, 0 tomorrow" from "1+1".
Introduces a new day_pattern.py module that analyses the 15-min price curve
for each calendar day (yesterday/today/tomorrow) and classifies its shape.
New sensors:
day_pattern_yesterday / day_pattern_today / day_pattern_tomorrow
EntityCategory.DIAGNOSTIC, SensorDeviceClass.ENUM
Patterns: valley, peak, double_valley, double_peak, flat, rising, falling, mixed
The detector uses centred-rolling smoothing, prominence-filtered extrema,
Kneedle-based knee detection, and monotone segment building.
Coordinator populates transformed_data["dayPatterns"] after priceInfo enrichment.
Impact: Users can trigger automations based on the shape of the day's price
curve, e.g. pre-heat when tomorrow is a valley day.
Wrap most user-guide code examples in collapsible details sections to reduce visual noise while keeping Mermaid diagrams expanded.
Standardized summary labels across the user docs to a small set of readable patterns and removed technical or awkward wording from visible collapse titles.
Impact: User documentation is easier to scan, with long examples hidden by default and more consistent expand/collapse labels.
New comprehensive documentation page for all 5 scheduling services:
- Decision flowchart for choosing the right service
- Detailed parameter reference with examples for each service
- Response format examples with realistic data
- Practical automation examples (overnight scheduling, EV charging,
peak price avoidance)
- Power profile and search range explanations
Also updated:
- actions.md: Added scheduling services overview, entry_id as optional
- automation-examples.md: Cross-reference to scheduling services guide
- Sidebar: Added scheduling-services to Reference category
Impact: Users have comprehensive documentation with a decision guide,
practical examples, and automation templates for the new services.
Disable autoCollapseCategories to prevent unwanted collapsing when
clicking an active category header twice.
Add hideOnScroll to navbar for more reading space on long pages.
Add category link targets in both sidebars so category headers are
clickable and navigate to the section overview page.
Impact: Sidebar navigation no longer collapses unexpectedly.
Category titles are now direct navigation links. Navbar hides while
scrolling, giving more screen space for content.
Add a comprehensive entity reference system that helps users find
entities across all 5 supported languages (EN, DE, NO, NL, SV).
Core components:
- Generator script (scripts/docs/generate-sensor-reference) that
builds sensor-reference.md from translation files with --check
mode for CI validation
- EntityRef component for compact inline entity annotations with
tooltip and version-aware linking to the reference table
- EntitySearch component with live filtering, clickable results,
keyboard navigation, "/" shortcut to focus, category filter chips,
match highlighting, copy-entity-ID button per row, back-links to
documentation pages, persistent row highlights, hash-based deep
linking, and mobile-responsive layout
- MDXComponents theme override for global component registration
Documentation updates:
- New sensor-reference.md page (115 entities x 5 languages)
- EntityRef annotations across 10 documentation pages
- Sidebar entry for quick navigation
- CI integration (docusaurus.yml + scripts/check)
- Ruff per-file-ignores for scripts/ (T201, INP001)
Impact: Users can now find any entity by its localized display name
regardless of their UI language. Inline EntityRef annotations link
directly to the multi-language lookup table with version-aware URLs.
All YAML code blocks >12-14 lines in example and concept pages are now
wrapped in HTML <details>/<summary> elements, reducing scroll depth
and making complex pages easier to navigate.
Pages affected:
- automation-examples.md: 9 blocks (heat pump, EV, battery automations)
- dashboard-examples.md: 6 blocks (button-card, mushroom, grid layouts)
- sensors.md: 7 blocks (practical examples, energy/tax templates, timing)
- icon-colors.md: 8 blocks (card_mod methods, complete dashboard, custom colors)
- period-calculation.md: 3 blocks (sensor attr reference, midnight example, automations)
Blocks left visible: short examples (<13 lines), Good/Bad comparisons,
Method 1 (primary recommended approach in icon-colors.md).
Impact: Users can scan page structure without scrolling past long YAML.
Code is still one click away, not hidden behind navigation.
New dedicated page for community-contributed examples, starting with
Dutch solar feed-in compensation (saldering) patterns adapted from
GitHub Discussion #105 (OdynBrouwer). Includes input_number helpers
for country-specific tax rates, template sensors for feed-in with
and without saldering, smart export automation, and dashboard card.
German spot price share template as starting point. Norwegian/Swedish
sections as placeholders for future contributions.
YAML code blocks use collapsible details elements to keep the page
scannable. Page is framed generically to accommodate any type of
community example in the future (not just country-specific).
Added cross-reference from sensors.md Energy Price section and new
"Community" sidebar category.
Impact: Users (especially Netherlands) can find ready-to-adapt template
examples for country-specific price calculations using the energy_price
and tax attributes. Framework ready for additional community examples.
Replace the inline KaTeX block in the Energy Price & Tax Breakdown
section with a plain inline equation string.
The previous expression caused a Docusaurus SSG runtime failure on the
sensors page (ReferenceError during static rendering).
Impact: User docs build now succeeds consistently for the sensors page.
