Remove storing of last active schedules

[bouwew]

It is planned to move this functionality to the HA Integration (via RestoreState)

Summary by CodeRabbit

• Refactor

  • Simplified scheduling: removed internal last-active tracking and related time-parsing logic, streamlining schedule selection.

• Tests

  • Removed assertions tied to last-active tracking; updated one test to explicitly set a thermostat schedule off.

• Documentation

  • Changelog notes removal of last-active schedule storage and relocation of handling.

• Chores

  • Project version bumped to 1.8.3a0.

[coderabbitai]

Walkthrough

The PR removes the _last_active state and its helper, updates SmileAPI to no longer accept or use _last_active, and simplifies schedule resolution so schedules are queried from the helper at call time.

Changes

Cohort / File(s)	Summary
Core API cleanup plugwise/__init__.py, plugwise/smile.py	Removed _last_active parameter/attribute and its initialization; updated SmileAPI.__init__ signature; removed assignments/usages of self._last_active; set_schedule_state and determine_contexts now query _schedules() at runtime.
Helper refactoring plugwise/helper.py	Removed self._last_active attribute and the _last_used_schedule() method; deleted datetime/dateutil imports and last-active tracking; simplified _schedules() to return available/selected without per-location last-active state; updated docstrings.
Tests tests/test_adam.py, tests/test_anna.py	Removed assertions that inspected api._last_active; replaced some last-active assertions with explicit tinker operations where applicable.
Metadata / Changelog pyproject.toml, CHANGELOG.md	Bumped project version to 1.8.3a0; added changelog note that storing last-active schedules was removed (handled by HA integration).

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant SmileAPI
    participant SmileHelper

    rect rgba(214,234,248,0.7)
    Note over SmileAPI: Old flow (removed)
    Client->>SmileAPI: set_schedule_state(loc, name=None / OFF)
    SmileAPI->>SmileAPI: read self._last_active[loc]
    alt last_active present
        SmileAPI-->>Client: resolve schedule from _last_active
    else fallback
        SmileAPI->>SmileHelper: _schedules(loc)
        SmileHelper-->>SmileAPI: available, selected
        SmileAPI-->>Client: resolve schedule
    end
    end

    rect rgba(223,240,216,0.7)
    Note over SmileAPI,SmileHelper: New flow
    Client->>SmileAPI: set_schedule_state(loc, name=None / OFF)
    SmileAPI->>SmileHelper: _schedules(loc)
    SmileHelper-->>SmileAPI: available, selected
    SmileAPI-->>Client: resolve schedule (no _last_active)
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Clean up timeout-related, pass _request-function as an argument #637 — modifies SmileAPI construction/wiring and touches constructor parameters used here.
• Limit amount of __init__ arguments #764 — consolidates initializer arguments and changes SmileHelper/SmileAPI initialization, related to constructor/initialization refactors.

Suggested labels

quality

Suggested reviewers

• CoMPaTech

Poem

🐰 I hopped in code to clear the tracks,
The last-active log — gone from the stacks.
Schedules now fetched when called anew,
No dusty timestamps to chase or pursue.
Fresh hops, clean code, a brighter view.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Remove storing of last active schedules" directly and accurately describes the main objective of the changeset. The modifications across all affected files (__init__.py, helper.py, smile.py, tests, and CHANGELOG.md) consistently focus on removing the _last_active attribute, the _last_used_schedule helper method, and all related state tracking logic. The title is concise, clear, and avoids vague terminology or noise, making it immediately understandable to anyone scanning the project history that this PR eliminates the functionality for storing and tracking last active schedules.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch clean_last_active_schedule

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

plugwise/smile.py (1)

375-378: Consider using elif for clarity.

The two separate if statements are functionally correct since state can only be STATE_OFF or STATE_ON (validated at lines 319-320). However, using elif would make the mutual exclusivity explicit and slightly more efficient.

Apply this diff:

         if state == STATE_OFF:
             contexts.remove(subject)
-        if state == STATE_ON:
+        elif state == STATE_ON:
             contexts.append(subject)

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 93233e3 and 08863b8.

📒 Files selected for processing (5)

• plugwise/__init__.py (0 hunks)
• plugwise/helper.py (2 hunks)
• plugwise/smile.py (1 hunks)
• tests/test_adam.py (0 hunks)
• tests/test_anna.py (0 hunks)

💤 Files with no reviewable changes (3)

• tests/test_anna.py
• tests/test_adam.py
• plugwise/init.py

🧰 Additional context used

🧬 Code graph analysis (1)

plugwise/smile.py (2)

plugwise/helper.py (1)

• _schedules (895-929)

plugwise/legacy/helper.py (1)

• _schedules (408-433)

🔇 Additional comments (4)

plugwise/smile.py (2)

66-78: LGTM! Constructor correctly updated.

The removal of the _last_active parameter and its initialization aligns with the PR objective to move schedule state tracking to the HA Integration.

---

326-330: LGTM! Schedule determination logic correctly refactored.

The method now dynamically determines the active schedule via _schedules(loc_id) instead of relying on cached _last_active state. The early return when no active schedule is found prevents unnecessary processing.

plugwise/helper.py (2)

869-869: LGTM! Docstring correctly updated.

The docstring now accurately reflects the helper function's usage without referencing the removed _last_active_schedule functionality.

---

895-929: LGTM! Schedule selection logic correctly simplified.

The _schedules method now determines the active schedule directly from the XML data without maintaining cached _last_active state. The logic correctly:

• Iterates through schedule rules
• Identifies the active schedule for the given location (line 918)
• Returns OFF when no active schedule is found (lines 925-926)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (93233e3) to head (a4def9f).
⚠️ Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #806   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           21        21           
  Lines         3403      3344   -59     
=========================================
- Hits          3403      3344   -59     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c14ea5c and 6174a61.

📒 Files selected for processing (1)

• tests/test_anna.py (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

tests/test_anna.py (1)

tests/test_init.py (1)

• tinker_thermostat (792-825)

🪛 Gitleaks (8.28.0)

tests/test_anna.py

[high] 362-362: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Check commit

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud