Skip to content

Conversation

@Bre77
Copy link
Owner

@Bre77 Bre77 commented Feb 8, 2026

Proposed change

Add a preconditioning schedule calendar entity to the Teslemetry integration. This is stacked on top of the charging schedule calendar PR (t-calendar-charge-schedule) and reuses the shared helper code introduced there (Schedule dataclass, get_rrule_days, async_get_sorted_schedule_events).

Key implementation details:

  • Preconditioning events are instantaneous (start == end time), unlike charging schedules which have a duration
  • One-time schedules do not get an rrule; only recurring schedules produce a FREQ=WEEKLY recurrence rule
  • The entity is disabled by default (_attr_entity_registry_enabled_default = False)

Note: Platform.CALENDAR was registered in the base PR. PR home-assistant#145848 (tariff calendars) also adds it -- whichever merges first wins.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to developer documentation pull request:
  • Link to frontend pull request:

Checklist

  • I understand the code I am submitting and can explain how it works.
  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.
  • Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

Bre77 and others added 2 commits February 8, 2026 15:32
Add a calendar entity for vehicle charging schedules, including
shared helper code (Schedule dataclass, rrule generation, event
sorting) that will be reused by a follow-up preconditioning PR.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add a calendar entity for vehicle preconditioning schedules.
Preconditioning events are instantaneous (start == end) and only
recurring schedules get an rrule.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@Bre77 Bre77 force-pushed the t-calendar-charge-schedule branch from 6f5f702 to 3da20be Compare February 9, 2026 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant