Add timetables controls

[swann05]

What does this PR do?

Add a timetable selector for each room and a global one
Add a refresh button for each room and a global one

Related Issue

Fixes #

Type of Change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation
• CI / tooling

Affected Generation(s)

• V2 - GW Bridge
• V3 Classic (HomeKit)
• Tado X (Matter)
• All / not generation-specific

Testing

Test on my instance, works perfectly

Checklist

• Pre-commit passes (ruff, mypy, hassfest, HACS)
• No debug logging left in
• Tested on real hardware or described why not applicable

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[sourcery-ai]

Reviewer's Guide

Implements timetable selection and refresh controls per zone and at home level, wiring them through new cached timetable state, API client methods, command merging, and executor support for batched timetable updates.

Sequence diagram for setting a zone timetable via new controls

sequenceDiagram
    actor User
    participant ZoneSelect as ZoneSelectEntity
    participant Coordinator as TadoHijackCoordinator
    participant ApiManager
    participant CommandMerger
    participant Executor as TadoV3Executor
    participant Client as TadoClient
    participant TadoApi

    User->>ZoneSelect: choose option (one_day/three_day/seven_day)
    ZoneSelect->>Coordinator: async_set_timetable(zone_id, timetable_type)
    Coordinator->>Coordinator: data_manager.timetable_cache[zone_id] = {id, type}
    Coordinator->>Coordinator: async_update_listeners()
    Coordinator->>Coordinator: _save_timetable_cache()
    Coordinator->>ApiManager: queue_command("set_timetable_zone", TadoCommand(CommandType.SET_TIMETABLE, data))

    ApiManager->>CommandMerger: add(TadoCommand)
    ApiManager->>ApiManager: _process_batch(commands)
    ApiManager->>CommandMerger: merged = result()
    ApiManager->>Executor: _execute_zone_properties(merged)

    Executor->>Executor: _safe_execute("timetable_zone", client.set_active_timetable(zone_id, timetable_id))
    Executor->>Client: set_active_timetable(zone_id, timetable_id)
    Client->>TadoApi: PUT /schedule/activeTimetable {id: timetable_id}
    TadoApi-->>Client: 200 OK

Loading

Sequence diagram for refreshing all timetables from the API

sequenceDiagram
    actor User
    participant HomeButton as HomeRefreshAllTimetablesButton
    participant Coordinator as TadoHijackCoordinator
    participant Client as TadoClient
    participant TadoApi

    User->>HomeButton: press
    HomeButton->>Coordinator: async_refresh_all_timetables()
    Coordinator->>Coordinator: [generation == GEN_CLASSIC]
    Coordinator->>Coordinator: zone_ids = [zid for zones_meta if HEATING/HOT_WATER]
    Coordinator->>Coordinator: asyncio.gather(async_refresh_timetable(zone_id))

    loop for each zone_id
        Coordinator->>Client: get_active_timetable(zone_id)
        Client->>TadoApi: GET /schedule/activeTimetable
        TadoApi-->>Client: timetable {id, type}
        Client-->>Coordinator: timetable entry
        Coordinator->>Coordinator: data_manager.timetable_cache[zone_id] = entry
        Coordinator->>Coordinator: async_update_listeners()
        Coordinator->>Coordinator: _save_timetable_cache()
    end

Loading

File-Level Changes

Change	Details	Files
Persist and expose timetable cache via the coordinator and data manager to support UI entities and bulk operations.	Add timetable_cache dict to DataManager and expose it on the coordinator after updates Restore timetable_cache from Home Assistant storage during async_setup and persist changes via a new _save_timetable_cache helper Notify listeners when timetable cache is changed to keep entities in sync	custom_components/tado_hijack/coordinator.py custom_components/tado_hijack/helpers/data_manager.py
Add API- and command-layer support for getting/setting active timetables, including batched execution.	Extend TadoClient with get_active_timetable and set_active_timetable HTTP methods Introduce CommandType.SET_TIMETABLE and merge logic in CommandMerger with last-write-wins semantics per zone Have ApiManager pass merged timetable data into the v3 executor, which now executes timetable updates via the client	custom_components/tado_hijack/helpers/client.py custom_components/tado_hijack/helpers/command_merger.py custom_components/tado_hijack/helpers/api_manager.py custom_components/tado_hijack/helpers/tadov3/executor.py custom_components/tado_hijack/models.py
Expose new home- and zone-level timetable select and refresh entities, gated to GEN_CLASSIC and heating/hot water zones where applicable.	Extend create_home_button and create_home_select helpers to accept an is_supported_fn predicate Add a home-level timetable_type_all_zones select and refresh_all_timetables button, both limited to GEN_CLASSIC Add per-zone timetable_type select and refresh_timetable button entities for heating and hot-water zones in GEN_CLASSIC, backed by timetable_cache and coordinator methods	custom_components/tado_hijack/definitions.py custom_components/tado_hijack/coordinator.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The timetable cache is handled inconsistently: some places use self.data_manager.timetable_cache while others (e.g. value_fn for timetable_type select) check hasattr(c, "timetable_cache"); it would be more robust to consistently read/write via data_manager.timetable_cache and avoid relying on a transient timetable_cache attribute on the coordinator.
• In the new timetable-related selectors/buttons you duplicate timetable-type strings and ID mappings in several places (e.g. hard-coded ONE_DAY/THREE_DAY/SEVEN_DAY and type_to_id), consider centralising these into a shared mapping or enum to reduce the risk of them drifting out of sync.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The timetable cache is handled inconsistently: some places use `self.data_manager.timetable_cache` while others (e.g. `value_fn` for `timetable_type` select) check `hasattr(c, "timetable_cache")`; it would be more robust to consistently read/write via `data_manager.timetable_cache` and avoid relying on a transient `timetable_cache` attribute on the coordinator.
- In the new timetable-related selectors/buttons you duplicate timetable-type strings and ID mappings in several places (e.g. hard-coded `ONE_DAY`/`THREE_DAY`/`SEVEN_DAY` and `type_to_id`), consider centralising these into a shared mapping or enum to reduce the risk of them drifting out of sync.

## Individual Comments

### Comment 1
<location path="custom_components/tado_hijack/definitions.py" line_range="1929" />
<code_context>
+    ),
+    create_zone_select(
+        key="timetable_type",
+        value_fn=lambda c, zid: (
+            c.data_manager.timetable_cache.get(zid, {}).get("type", "ONE_DAY").lower()
+            if hasattr(c, "timetable_cache")
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Zone timetable select `value_fn` mixes `hasattr` on `c.timetable_cache` with reading `c.data_manager.timetable_cache` and returns `None` fallback.

`value_fn` guards with `hasattr(c, "timetable_cache")` but actually reads `c.data_manager.timetable_cache`, so the check doesn’t protect the cache being used. It also falls back to `None`, unlike the home-level select which defaults to `"one_day"`. Please simplify this to always use `c.data_manager.timetable_cache` and apply a consistent default (e.g. `"one_day"`) when the zone entry is missing, and drop the redundant `hasattr` check.
</issue_to_address>

### Comment 2
<location path="custom_components/tado_hijack/definitions.py" line_range="1902" />
<code_context>
         optimistic_key="horizontal_swing",
         supported_generations={GEN_CLASSIC},
     ),
+    create_home_select(
+        key="timetable_type_all_zones",
+        value_fn=lambda c: (
</code_context>
<issue_to_address>
**question (bug_risk):** Home-level timetable select derives its value from the first cached zone, which may not reflect the state of all zones.

Using `next(iter(c.data_manager.timetable_cache.values()), {})` means this entity’s state is effectively taken from a single arbitrary zone. When zones differ, the reported “all zones” timetable may not match most or even any zones. Consider defining an explicit aggregation rule (e.g., require uniform timetables, use the majority timetable, or expose a mixed/indeterminate state), or making this entity write-only for bulk changes so it doesn’t present a misleading single-source-of-truth state.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (bug_risk): Zone timetable select value_fn mixes hasattr on c.timetable_cache with reading c.data_manager.timetable_cache and returns None fallback.

value_fn guards with hasattr(c, "timetable_cache") but actually reads c.data_manager.timetable_cache, so the check doesn’t protect the cache being used. It also falls back to None, unlike the home-level select which defaults to "one_day". Please simplify this to always use c.data_manager.timetable_cache and apply a consistent default (e.g. "one_day") when the zone entry is missing, and drop the redundant hasattr check.

[sourcery-ai]

question (bug_risk): Home-level timetable select derives its value from the first cached zone, which may not reflect the state of all zones.

Using next(iter(c.data_manager.timetable_cache.values()), {}) means this entity’s state is effectively taken from a single arbitrary zone. When zones differ, the reported “all zones” timetable may not match most or even any zones. Consider defining an explicit aggregation rule (e.g., require uniform timetables, use the majority timetable, or expose a mixed/indeterminate state), or making this entity write-only for bulk changes so it doesn’t present a misleading single-source-of-truth state.