Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use TADO_MODE for temperature overrides in tado climate component. #29014

Merged
merged 4 commits into from Nov 25, 2019

Conversation

@michaelarnauts
Copy link
Contributor

michaelarnauts commented Nov 24, 2019

Breaking Change:

Temperature overrides are now cancelled when the schedule dictates that the temperature should be lowered (or raised, depending on your climate), like during the night. The current behavior caused my house to be heated during the night a few times since I forgot to set set the mode back to auto, after changing the temperature during a cold evening. This restores the behavior like it was before the big Climate 1.0 PR from Home Assistant 0.95 and makes it consistent with the Tado device and Tado App.

Description:

Since the "Climate 1.0 PR", when you make a temperature override, the operation mode is switched to "Manual", making the smart schedules that you could create in the app useless, since they will never apply anymore until you manually switch back to auto. The default behaviour of the Tado Mobile app and the Tado device is to use "Tado Mode", meaning that the override is only valid until the next schedule change.

This has been reported here https://community.home-assistant.io/t/setup-failed-for-tado/105570/175 and here #25714

Current behavior:

  • Changing the temperature from Home Assistant sets the mode in Tado to "Manual". The schedule will not be used anymore, for example to set the temperature lower during the night, until you set the mode back to "Auto" mode yourself.
  • When changing the temperature from the Tado app or the device, the state remains in "Auto", but when you do the same from Home Assistant, the state is set to "Manual". This is inconsistent behaviour.
  • A workaround that is now suggested is to create an automation to set the mode back to "Auto" when you want the schedule to change the temperature, but this requires you to recreate the schedule you already have as a Home Assistant automation, forcing you to setup your schedule twice. I don't like this workaround.

New behavior:

  • Changing the temperature from Home Assistant sets the mode in tado to "Tado Mode". The schedule will still be used to change the temperature. This is the pre 0.95 behavior, and also matches the default behaviour of the tado device and the tado app.

Asking for feedback from @ejaviga @andersonshatch @wmalgadey since you've all recently contributed to the Tado component.

Related issue (if applicable): fixes #25714

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist

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. Update and include derived files by running python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
  • Untested files have been added to .coveragerc.

If the code does not interact with devices:

  • Tests have been added to verify that the new code works.
@andersonshatch

This comment has been minimized.

Copy link
Contributor

andersonshatch commented Nov 24, 2019

I agree in principal with the change, and have this patched in my local custom component because I did not want temp/mode changes to apply perpetually, only until the next schedule change.

I was planning to open a PR to fetch the desired overlay mode from the tado APIs though, rather than just assuming one way or the other though just hadn't gotten around to it yet. That way, the user's preference -- apply forever, until next change, or timer -- as specified in tado, would apply to any changes made in home assistant too. (Possibly needs a change in the tado library to get this info, I forget)

@michaelarnauts

This comment has been minimized.

Copy link
Contributor Author

michaelarnauts commented Nov 24, 2019

I agree in principal with the change, and have this patched in my local custom component because I did not want temp/mode changes to apply perpetually, only until the next schedule change.

I was planning to open a PR to fetch the desired overlay mode from the tado APIs though, rather than just assuming one way or the other though just hadn't gotten around to it yet. That way, the user's preference -- apply forever, until next change, or timer -- as specified in tado, would apply to any changes made in home assistant too. (Possibly needs a change in the tado library to get this info, I forget)

I've also looked at using the stored preference at tado, but this requires the py-tado library to fetch the defaultOverlay, but that library doesn't seem really active (there are open merge requests from May). Since I've recently noticed this issue, I wanted to have a fix as soon as possible and try to fetch it from the api in a later PR.

@bruvv

This comment was marked as spam.

Copy link

bruvv commented Nov 24, 2019

I really need this ;) please merge

@cicero200272

This comment was marked as spam.

Copy link

cicero200272 commented Nov 25, 2019

👍

Copy link
Member

pvizeli left a comment

We search a code owner for this integration. Do you have interest?

For me is that fine.

@michaelarnauts

This comment has been minimized.

Copy link
Contributor Author

michaelarnauts commented Nov 25, 2019

We search a code owner for this integration. Do you have interest?

For me is that fine.

Sure, I will add my name to the manifest.

@pvizeli pvizeli merged commit c21c167 into home-assistant:dev Nov 25, 2019
11 checks passed
11 checks passed
CI #20191125.34 succeeded
Details
CI (FullCheck Mypy) FullCheck Mypy succeeded
Details
CI (FullCheck Pylint) FullCheck Pylint succeeded
Details
CI (Overview CheckFormat) Overview CheckFormat succeeded
Details
CI (Overview Lint) Overview Lint succeeded
Details
CI (Overview Validate) Overview Validate succeeded
Details
CI (Tests PyTest Python36) Tests PyTest Python36 succeeded
Details
CI (Tests PyTest Python37) Tests PyTest Python37 succeeded
Details
cla-bot Everyone involved has signed the CLA
codecov/patch Coverage not affected when comparing 94f8e63...a05026b
Details
codecov/project 94.47% (target 90%)
Details
@lock lock bot locked and limited conversation to collaborators Nov 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
6 participants
You can’t perform that action at this time.