Updated the description for Norway and Sweden's fee structures to specify that the energy price unit depends on the display mode, enhancing clarity for users implementing templates.
Impact: Users will have a clearer understanding of how to handle energy price units in their configurations.
Revise the Germany section to focus on feed-in compensation for exported PV energy and provide detailed steps for creating input number helpers and template sensors.
Impact: Users can better understand and implement feed-in compensation calculations in their Home Assistant setups.
Clarify the unit display modes for energy prices and provide guidance on template normalization for user-specific setups.
Impact: Users gain clearer instructions on adapting energy price calculations to their local currency display settings.
Explain the top-level success flag and the price_data_unavailable reason for
get_price, find_cheapest_*, and plan_charging, and clarify that an empty
result with success=true (e.g. tomorrow's prices not yet published) is not an
error. Note that day-ahead prices usually arrive around 13:00 but can be
delayed into the afternoon or evening.
Impact: Automation authors can reliably tell a temporary API outage apart from
normally missing data.
Updated the translations for various price phase sensors in the sensor reference documentation to ensure consistency and accuracy across multiple languages.
Impact: Users will see improved clarity in the documentation for price phase sensors in their preferred language.
Add warnings to indicate that scheduling actions and the plan_charging action are experimental and subject to change. This informs users to use them with caution and report any issues.
Impact: Users are aware of the experimental nature of these features, promoting careful usage.
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.
