Skip to content

Conversation

@orandin
Copy link
Contributor

@orandin orandin commented Jan 3, 2026

For external program only:

  • If the target heating level (eco, comfort, ...) is returned by Overkiz API, it will be used instead of program name (external).

Proposed change

The external mode means the heater is managed by external controller (e.g. home assistant). However, it is currently impossible to know the current preset mode (eco, comfort, ...) in this mode. Automation is not possible (e.g. select all heaters in specific preset to set another preset)

The idea is to move condition to prioritize preset mode (eco/comfort...) instead of program name (external).

Screenshots :

Before After

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:

Copilot AI review requested due to automatic review settings January 3, 2026 10:52
@orandin orandin requested a review from iMicknl as a code owner January 3, 2026 10:52
Copy link

@home-assistant home-assistant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @orandin

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@home-assistant
Copy link

home-assistant bot commented Jan 3, 2026

Hey there @iMicknl, mind taking a look at this pull request as it has been labeled with an integration (overkiz) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of overkiz can trigger bot actions by commenting:

  • @home-assistant close Closes the pull request.
  • @home-assistant rename Awesome new title Renames the pull request.
  • @home-assistant reopen Reopen the pull request.
  • @home-assistant unassign overkiz Removes the current integration label and assignees on the pull request, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

@home-assistant home-assistant bot marked this pull request as draft January 3, 2026 10:53
@home-assistant
Copy link

home-assistant bot commented Jan 3, 2026

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR modifies the logic for determining the preset mode of Atlantic electrical heaters in the Overkiz integration. The change prioritizes the target heating level (eco, comfort, etc.) over the operating mode when determining the current preset, allowing users to see the actual heating level even when the heater is in external control mode.

Key changes:

  • Reordered conditional checks in the preset_mode property to check IO_TARGET_HEATING_LEVEL state before CORE_OPERATING_MODE
  • This enables automation based on actual preset modes (eco/comfort) rather than just "external" when heaters are externally controlled

@orandin orandin marked this pull request as ready for review January 3, 2026 10:56
@erwindouna
Copy link
Contributor

Why is this classified as a breaking change? It renders the integration no longer backwards incompatible? :)

Copy link
Member

@iMicknl iMicknl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @orandin!

@iMicknl
Copy link
Member

iMicknl commented Jan 3, 2026

Why is this classified as a breaking change? It renders the integration no longer backwards incompatible? :)

Technically, a breaking change is one that alters behavior for existing users of the integration. This change sits somewhat in between. It addresses an existing issue, which makes it feel like a bug fix, but it does introduce a different user-facing behavior.

I’ll check with the other core contributors whether this should be treated as a breaking change or documented as a bug fix instead.

If your PR contains a breaking change for existing users, it is important
to tell them what breaks, how to make it work again and why we did this.
This piece of text is published with the release notes, so it helps if you
write it towards our users, not us.

@erwindouna
Copy link
Contributor

Technically, a breaking change is one that alters behavior for existing users of the integration. This change sits somewhat in between. It addresses an existing issue, which makes it feel like a bug fix, but it does introduce a different user-facing behavior.

In my experience it would be considered a breaking change, if a user has to do something in order to fix it, or when a functionality no longer is available. If new behavior is implemented and works right away when updating, but doesn't affect the two mentioned points it's not a breaking change in my books - it's working as intended without any impact. :)

@orandin
Copy link
Contributor Author

orandin commented Jan 5, 2026

@iMicknl Would you prefer that I remove the breaking change section?

@iMicknl iMicknl force-pushed the orandin-preset-mode branch from eb1a9a1 to dbce337 Compare January 10, 2026 22:52
@iMicknl iMicknl added the bugfix label Jan 10, 2026
@iMicknl iMicknl merged commit b4360cc into home-assistant:dev Jan 10, 2026
36 checks passed
@iMicknl iMicknl changed the title Move condition to prioritize preset mode (eco/comfort...) instead of program name Move condition to prioritize preset mode (eco/comfort...) instead of program name in Overkiz Jan 10, 2026
@github-actions github-actions bot locked and limited conversation to collaborators Jan 11, 2026
@orandin orandin deleted the orandin-preset-mode branch January 12, 2026 22:49
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants