Fix set temperature action in AVM FRITZ!SmartHome

[mib1185]

Proposed change

The current logic ignores given temperature attribute in set_temperature as long as a hvac_mode is specified, which leads to the following decisions:

• when temperature=n and hvac_mode=off is given, than hvac mode is set to off
• when temperature=n and hvac_mode=heat is given, than hvac mode is set to heat (without respecting the temperature)
• when temperature=n and no hvac_mode is given, than target temperature is set to n

The fixed logic is as follows:

• when temperature=n and hvac_mode=off is given, than hvac mode is set to off
• when temperature=n and hvac_mode=heat is given, than target temperature is set to n
• when temperature=n and no hvac_mode is given, than target temperature is set to n

Type of change

• [ ] Dependency upgrade
• [x] 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: #126044
• Link to documentation pull request:

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] I have followed the perfect PR recommendations
• [x] The code has been formatted using Ruff (ruff format homeassistant tests)
• [x] Tests have been added to verify that the new code works.

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

• [ ] Documentation added/updated for www.home-assistant.io

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:

• [ ] I have reviewed two other open pull requests in this repository.

[home-assistant[bot]]

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

Code owner commands

Code owners of fritzbox 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 fritzbox 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.

[PeteRager]

The requirements look incorrect. What I'd expect is:

if hvac_mode and temperature are provided:

• if current hvac_mode != requested hvac_mode then set hvac mode to requested mode
• Set the temperature

So for example, if the system is in cool mode and the action specifies heat and 72 degrees. I'd expect the mode to change to heat and temperature to be set of 72. In the current code, the mode will not be changed and the cooling temperature is set to 72.

[mib1185]

These are thermostats, so they just support off and heat. Further we consider every actual set target temperature as mode heat and a target temperature 0.0 as mode off. So when we have any temperature (which is mandatory for the set_temperature action) and mode heat than we just set the temperature, because the mode is automatically considered as heat. If we have mode off in the action call, than we set it to 0.0, those to off.

[PeteRager]

These are thermostats, so they just support off and heat. Further we consider every actual set target temperature as mode heat and a target temperature 0.0 as mode off. So when we have any temperature (which is mandatory for the set_temperature action) and mode heat than we just set the temperature, because the mode is automatically considered as heat. If we have mode off in the action call, than we set it to 0.0, those to off.

That makes sense, however when I read this statement from the description

when temperature=n and hvac_mode=heat is given, than hvac mode is set to heat (without respecting the temperature)

It sounds like it ignores the temperature. What am I missing?

[mib1185]

when temperature=n and hvac_mode=heat is given, than hvac mode is set to heat (without respecting the temperature)

It sounds like it ignores the temperature. What am I missing?

This is the current (wrong) behaviour, which this PR is supposed to fix 😉

[frenck]

This PR cannot be cleanly merged into the current stable branches for the patch release (it causes conflicts). Therefore, I've removed the PR from the patch release and will ship as part of 2024.10.0 instead.

../Frenck

[mib1185]

uhhh ... ok, thx for letting me know :+1: