check_min_distance_from_avg() computed the distance threshold as
range_avg * (1 ± ratio). Tibber prices can go negative during grid
oversupply, and multiplying a negative range_avg directly flips the
intended direction: e.g. avg * 1.05 makes a negative average MORE
negative (i.e. cheaper), which is the wrong direction for a
"most expensive" threshold check, and analogously wrong for
"cheapest" checks.
Compute the threshold as range_avg ± abs(range_avg) * ratio instead,
matching the sign-safe normalization pattern already used for
min_distance_from_avg in the period system
(coordinator/period_handlers/level_filtering.py). Behavior for
positive averages (the common case) is unchanged.
Used by find_cheapest_block, find_cheapest_hours, and plan_charging.
Impact: min_distance_from_avg now correctly filters cheapest/most
expensive windows during negative-price periods instead of silently
accepting windows in the wrong direction relative to the search range
average.
find_cheapest_block, find_cheapest_hours, and find_cheapest_schedule
accept an optional power_profile (fixed per-interval watt array
matching the requested duration/task length). When allow_relaxation
was enabled and no full-duration window could be found, the
duration-reduction relaxation phase silently reduced the interval
count without shrinking power_profile accordingly. Downstream code
(find_cheapest_contiguous_window, calculate_window_statistics,
_find_cheapest_window_in_pool) then truncated the profile from the
front to match, dropping trailing appliance-cycle phases and using
the wrong per-interval weights for both window selection and the
reported cost estimate.
Disable duration-reduction relaxation whenever a power_profile is
supplied (find_cheapest_schedule guards per-task via
any_task_has_power_profile); distance and level-filter relaxation
phases remain available since they don't affect interval count.
Impact: Services with a power_profile no longer silently pick a
shorter window with mismatched power weighting during relaxation;
they now correctly report no window found if the full duration isn't
available, preserving the accuracy of appliance-cycle cost estimates.
Add a real (non-mocked) end-to-end test exercising apply_must_finish_by
and resolve_search_range together with a range-filtering fake pool,
reproducing the exact scenario from GH #168: a naive must_finish_by
datetime combined with search_start_day_offset: 0. The underlying fix
already landed in db5d172 but had no test covering the full request
pipeline (only individual helpers were mocked in existing tests).
Release-Notes: skip
User-Impact: none
_find_cheapest_window_in_pool() scans for contiguous available blocks
when scheduling multiple tasks. When a block-in-progress hit a
temporal gap (e.g. from price-level filtering removing intervals from
the middle of the search range, or missing API data), the scanner
jumped to i = j + 1 instead of i = j, silently skipping the interval
right after the gap as a valid — sometimes cheaper — window start.
Distinguish 'unavailable slot' (correctly skipped via j + 1) from
'temporal gap' (must retry at j, since that slot was never actually
tested as a window start).
Impact: find_cheapest_schedule can now find the true cheapest window
for a task when the search range contains time gaps, instead of
occasionally picking a more expensive window right after such a gap.
apply_segment_constraints could add far more grid energy than requested when
max_cycles_per_day or min_charge_duration_minutes forced bridging across
expensive gaps between cheap intervals. With max_cycles_per_day=1, isolated
cheap intervals were merged into one continuous segment by filling every gap
in between, without ever trimming the surplus back down, resulting in
achieved_soc_percent far above 100%.
Add a post-bridging trim step that removes segment-edge intervals (highest
price first) until total grid energy matches the requested target again,
while still respecting max_cycles_per_day/min_charge_duration_minutes and
never dropping below the target itself (fixed-power mode's expected
last-interval rounding overshoot is preserved).
A related edge case is also fixed: trimming could previously remove an
interval required to satisfy a must_reach_by deadline, silently flipping
deadline_met to False even though the overall energy target was still
reached. Deadline-critical intervals are now passed through as
protected_starts and are never removed during trimming.
Fixes#167
Impact: plan_charging no longer overcharges the battery/EV past the
requested target SoC when max_cycles_per_day or min_charge_duration_minutes
is set, and must_reach_by deadlines are honored even when those constraints
require bridging across expensive price gaps.
Add UV_PRERELEASE=allow to the format, lint-check, and lint-fix scripts to enable pre-release features in Ruff.
Impact: Users can now utilize pre-release features during code formatting and linting processes.
Updated error messages in German, English, Norwegian, Dutch, and Swedish translations to remove unnecessary quotes around placeholders. This improves clarity and consistency in error reporting.
Impact: Users will see clearer error messages without quotes around variable placeholders.
Updated the default Home Assistant version in the bootstrap script and requirements file to ensure compatibility with the latest features and fixes.
Impact: Users will benefit from improved stability and new features available in Home Assistant 2026.4.4.
Updated the step value for number fields in the plan_charging service to allow any value instead of a fixed increment. This change enhances flexibility in user input.
Impact: Users can now specify any value within the defined range for charging plans.
---
refactor(translations): update error message formatting for entity attributes
Modified the error messages in multiple translation files to remove curly braces around entity attributes. This improves consistency in message formatting across languages.
Impact: Users will see cleaner error messages when attributes are not found.
* fix(services): preserve service call data through coordinator data fetch
In `_handle_find_block` and `_handle_find_hours`, the local `data`
variable holding the resolved service call data was rebound to the
coordinator data dict returned by `get_entry_and_data()`. As a result,
the subsequent calls to `validate_search_params(data)`,
`apply_must_finish_by(data, ...)` and `resolve_search_range(...)` read
search-range parameters from coordinator data instead of from the
service call, silently ignoring:
- must_finish_by
- search_scope
- search_start, search_end
- search_start_time, search_end_time
- search_start_day_offset, search_end_day_offset
- search_start_offset_minutes, search_end_offset_minutes
- include_current_interval
The functions fell back to the default range ("now → end of tomorrow")
for every call that depended on these parameters.
Rename the third return value of `get_entry_and_data()` to
`coordinator_data` so the service call `data` survives, restoring
deadline and search-scope semantics. `find_cheapest_schedule.py`
already uses `data_dict` for the same purpose and was not affected.
Verified locally against v0.31.0: a call with
`must_finish_by: 2026-06-01T20:00:00+02:00` now correctly produces
`search_end: 2026-06-01T20:00:00+02:00` (was end-of-tomorrow before).
* refactor(services): update data handling in find_cheapest_schedule service
Refactor the data retrieval process to use coordinator data instead of entry data for improved clarity and consistency.
Impact: Enhances maintainability of the service code without altering user-facing functionality.
---------
Co-authored-by: “WouterK” <kwaken.geringd0w@icloud.com”git config --global user.name “WouterK”git config --global user.email kwaken.geringd0w@icloud.com”>
Co-authored-by: Julian Pawlowski <jpawlowski@users.noreply.github.com>
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.
Track API failures over time in the repair manager and raise an api_outage
repair issue once fresh data has been missing for longer than two hours,
independent of the update interval. A genuine successful fetch clears it;
serving cached data as a fallback keeps the outage active. Expose the degraded
cache-fallback state via the connection binary sensor (using_cached_data,
last_successful_update) so users can tell when sensors run on locally cached
prices. Add the api_outage repair strings to all supported languages.
Impact: Users get a clear repair notice during prolonged Tibber outages and
can see when the integration is running on cached data.
Add a track_degraded parameter to IntervalPool.get_intervals so service calls
(track_degraded=False) never flip the coordinator's sensor-health flags or use
the covers-current-interval cache fallback; authentication errors still
propagate. All price-fetching services now go through
async_fetch_service_intervals and return a structured response with a
top-level success flag: success=false with reason="price_data_unavailable" on
a real API outage, and success=true (possibly empty) otherwise.
Impact: Action calls (get_price, find_cheapest_*, plan_charging) always return
the expected shape, never impair sensors during a Tibber outage, and let
automations distinguish an outage from "no data yet".
Some markets/accounts (e.g. NL hourly) return an empty
priceInfo(QUARTER_HOURLY).today while priceInfoRange still delivers the full
set of intervals. _check_price_info_empty required today's data and wrongly
classified such complete responses as empty, which blocked setup. It now
treats a response as valid when today OR yesterday data is present, since
priceInfoRange is the authoritative source the interval pool uses.
Additionally, "Empty data received" is now retried a few times with
exponential backoff, smoothing brief Tibber outages that transiently return
empty data within a single update cycle. Long outages are still absorbed by
the IntervalPool cache fallback, so the in-request retry count stays small.
Reported in #141.
Impact: Setup and updates no longer fail with "Empty data received" for NL
hourly accounts (and similar), and short Tibber blips are smoothed over.
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.
Updated the pytest-homeassistant-custom-component version to match the Home Assistant versioning scheme. Added a script to automate the update process for Home Assistant versions across the development environment.
Impact: Developers can now easily update Home Assistant versions and corresponding dependencies with a single command.
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
