Blueprints are kept in the repository for development but are not yet
ready for distribution. Commented out the install and remove calls in
async_setup and async_remove_entry so they are not copied to the user's
HA config directory on integration setup.
Release-Notes: skip
User-Impact: none
Two fixes in all 4 home_connect_alt blueprints:
1. home_connect_alt.start_program uses its own `device_id` field (not HA's
standard target mechanism) and `program_key` (not `program`). The
previous `target: entity_id:` was silently ignored, causing the service
call to fail due to missing required `device_id`. Fixed by:
- Removing `target: entity_id:` block
- Adding `data.device_id: "{{ device_id(program_entity) }}"`
- Renaming `program:` to `program_key:`
- Adding `| int` filter to numeric option values
2. Same remote_start_sensor description fix as the non-alt variants
(RemoteControlActive → RemoteControlStartAllowed).
Also reset blueprint version from v2.0.0 to v1.0.0.
Release-Notes: skip
Released-Bug: no
The input field described the wrong binary sensor entity. The automation
correctly triggers on `RemoteControlStartAllowed`, but the label and
description still referenced `RemoteControlActive`.
Updated all 4 home_connect (non-alt) blueprints:
- dishwasher_home_connect.yaml
- washing_machine_home_connect.yaml
- dryer_home_connect.yaml
- laundry_day_pipeline_home_connect.yaml
Also reset blueprint version from v2.0.0 to v1.0.0 (version was bumped
prematurely, blueprints not yet released).
Release-Notes: skip
Released-Bug: no
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.
Keep raw Tibber API levels for best/peak period filtering while leaving smoothed levels in priceInfo for display-oriented sensors. Also make relaxation retry each flex step with the configured level filter before falling back to level_filter="any", and add regression tests for both paths.
Impact: Best-price periods no longer extend into expensive intervals because of level smoothing, and adjacent best/peak windows stay separated as expected.
Add a `price_source` field (total | energy | tax, default: total) to both
services, allowing users to choose which price component is used as the
primary chart series.
- get_chartdata: all 9 interval.get("total") calls now use price_source
- get_apexcharts_yaml: price_source forwarded through all 4 JS
data_generator calls; yaxis template variables resolve to
yaxis_min_energy / yaxis_min_tax when price_source != "total"
- Metadata-only path: always computes yaxis_suggested_energy and
yaxis_suggested_tax alongside the main yaxis bounds so the
chart_metadata sensor can expose the correct axis scale for any source
- chart_metadata sensor: exposes yaxis_min_energy, yaxis_max_energy,
yaxis_min_tax, yaxis_max_tax as new attributes
- services.yaml + all 5 language files (en, de, nb, nl, sv): price_source
field and selector options added
Impact: Users can now chart the raw energy (spot) price or the tax component separately, with correct Y-axis scaling in ApexCharts.
Co-authored-by: Copilot <copilot@github.com>
Add a dedicated type-check-tests helper, wire it into check-all behind --with-test-types, and align the affected tests with current typing and helper contracts.
Impact: No direct user-facing change.
User-Impact: none
Recompute merged relaxed periods from raw intervals, harden numeric period option normalization, update day-volatility handling for zero or negative averages, and expose day context on period binary sensors.
Add focused regressions for overlap merges, cache invalidation, day statistics, and visible binary sensor attributes.
Impact: Best and peak period entities stay consistent on negative-price days, refresh correctly when same-day prices change, and expose the documented day context attributes.
Always treat prices at or below zero as valid best-price intervals, rescue short
negative cores with directly adjacent cheap shoulders before min-length filtering,
and block geometric or shape-based widening for periods that already contain a
negative-price core.
Impact: Negative best-price periods no longer expand into positive edge intervals on days with extreme negative prices.
Introduce a new settings file to define permissions for various script executions.
Impact: Enables controlled execution of linting, type-checking, and testing scripts.
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
Bundle automation and script blueprints into the integration and
install them automatically at HA startup via _install_blueprints().
Remove them cleanly when the last config entry is removed.
Automation blueprints (standalone):
- dishwasher, washing_machine, dryer — smart plug and Home Connect
variants (HC: door/remote-start sensors; HC Alt: program selector)
Automation blueprints (pipeline):
- laundry_day_pipeline — chains washer → dryer for multiple loads,
HC and HC Alt variants
Other automation blueprints:
- ev_charging, heat_pump_price_level, heat_pump_smart_boost,
home_battery, water_heater, laundry_day_pipeline (smart plug)
Script blueprint:
- notify_residents — presence-aware dispatcher for up to 10 residents
with auto-discovered mobile_app notify services, iOS/Android push
settings, and per-resident notify overrides
Notification UX across all blueprints:
- Apple Watch-optimised titles (~25 chars) and messages (most
important info first, middle-dot separators, emoji anchors)
- Customisable notification titles via blueprint inputs (standalone)
- Comma-separated notify services for simple multi-target delivery
- Advanced script path for presence filtering and platform push data
Impact: Users get ready-to-use blueprints installed automatically
with the integration for scheduling appliances during cheap Tibber
price windows. No manual import required.
Read the version field from manifest.json at import time via a new
INTEGRATION_VERSION constant in const.py. Pass it as sw_version to
DeviceInfo in TibberPricesEntity so the current integration version
is visible in the HA device registry.
Impact: Device page in HA now shows the installed integration version
under firmware/software version.
Add entity_resolver module that lets all service parameters accept
HA entity references in place of literal values. The entity's current
state (or a specific attribute via the @attr syntax) is resolved at
call time and coerced to the expected Python type.
Syntax:
"sensor.washing_duration" → uses entity state
"sensor.washing_duration@run_minutes" → uses entity attribute
Apply or_entity_ref() and resolve_entity_references() to all five
service handlers (get_price, find_cheapest_block, find_cheapest_hours,
find_cheapest_schedule, get_chartdata) for every parameter where a
dynamic value from another entity is useful (duration, start/end times,
offsets, etc.).
Add five new translation keys for entity-resolution error messages
(invalid_entity_reference, entity_not_found, entity_attribute_not_found,
entity_state_unavailable, entity_value_conversion_failed) across all
five language files.
Fix pytest warning filter to suppress AsyncMock cleanup noise, and
update test_resource_cleanup to mock hass.config_entries.async_entries
so the blueprint-removal path in async_remove_entry does not raise.
Impact: Automations and scripts can pass sensor entity IDs as service
parameters (e.g. duration from a sensor) instead of having to use
template-based workarounds.
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
When sequential: true, tasks are placed in declaration order instead of
being sorted by duration. Each task's search window starts after the
previous task ends (plus gap_minutes). If a task cannot be placed, all
subsequent tasks in the chain are also marked unscheduled.
Adds 12 tests covering ordering, chaining, gap enforcement, and
chain-breaking behavior.
Impact: Users can now schedule dependent appliances (e.g., washing
machine → dryer) in a single find_cheapest_schedule call with guaranteed
order, instead of chaining two find_cheapest_block calls.
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.
Removed unnecessary sections from the get_apexcharts_yaml service and added new fields for search tuning and cost estimation in chartdata services. This improves the clarity and usability of the service definitions.
Impact: Users will benefit from a more concise and organized service structure, enhancing the overall experience.
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.
Improve the filtering of peak periods to eliminate cross-day artifacts and ensure that only genuine high-price windows are retained. This includes adjustments to the criteria for peak classification and the introduction of validation against previous day's prices for overnight intervals.
Impact: Users will experience more accurate peak pricing data, reducing misleading peak classifications on flat days.
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.
Include the MermaidChart extension to enhance diagramming capabilities within the development environment.
Impact: Users can now create and visualize diagrams directly in their code editor.
Updated pattern names for clarity and consistency in the codebase. The changes include renaming constants and updating related logic to reflect the new terminology.
Impact: Improved readability and understanding of day pattern classifications for developers.
Refactor the pattern classification logic to include start and end prices for better accuracy in identifying day patterns. This change improves the classification of price patterns, particularly for cases involving valleys and peaks.
Impact: Users will experience more accurate price pattern classifications, leading to better decision-making based on price trends.
The Copilot backend relies on the AI to reproduce the footer text exactly,
which leads to subtle differences (URL parameter order, whitespace, emoji
encoding) compared to the git-cliff template in cliff.toml.
Fix: define CANONICAL_FOOTER as a single bash constant and pipe all three
backends (copilot, git-cliff, manual) through ensure_canonical_footer(),
which strips any existing BMAC footer block and appends the canonical one.
Also tell the AI not to generate a footer at all, since it is now added
programmatically. The manual backend gains a footer it previously lacked.
User-Impact: none
The PRICE_INFO endpoint returns all available intervals (~384) regardless
of the requested range. When fetching multiple missing ranges, subsequent
calls are redundant if the first response already covers them.
After each fetch, track returned timestamps and skip ranges that are
already covered by previously fetched data.
Impact: Reduces redundant Tibber API calls, especially after restarts or
cache invalidation when multiple gaps exist in the interval pool.
