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

Bugfix: incorrectly inverted value when setting zwave cover position #3376

Merged
merged 1 commit into from
Sep 15, 2016

Conversation

ej81
Copy link
Contributor

@ej81 ej81 commented Sep 13, 2016

Description:
Setting position for the zwave cover component submits the position to the open-zwave library as 100-position. This is not consistent with the rest of the code where the position is used as is. Setting the cover position to 80 sends the cover to position 20 and the state is read back correctly as 20.

This PR fixes the problem by removing the inversion in set_cover_position.

Related issue (if applicable): fixes #

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#

Example entry for configuration.yaml (if applicable):

Checklist:

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

If code communicates with devices, web services, or a:

  • Local tests with tox run successfully. Your PR cannot be merged unless tests pass
  • New dependencies have been added to the REQUIREMENTS variable (example).
  • New dependencies are only imported inside functions that use them (example).
  • New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
  • New files were added to .coveragerc.

If the code does not interact with devices:

  • Local tests with tox run successfully. Your PR cannot be merged unless tests pass
  • Tests have been added to verify that the new code works.

@turbokongen
Copy link
Contributor

@nunofgs @kuhlivisj @mib2011 @wokar Any of you experiencing this?

@balloob
Copy link
Member

balloob commented Sep 14, 2016

I wouldn't be surprised if this was an artifact from the rollershutter, which had things in reverse.

@balloob balloob added this to the 0.28.3 milestone Sep 14, 2016
@wokar
Copy link
Contributor

wokar commented Sep 14, 2016

Just tested my current 0.28.2 setup and I can confirm the behavior. Setting the rollershutter to 80 in the GUI opens it about 20% and after it stops the slider in the GUI jumps to 20.

After applying the patch it works as expected.

@balloob
Copy link
Member

balloob commented Sep 15, 2016

Alrighty, 🐬

@balloob balloob merged commit 70a79ef into home-assistant:dev Sep 15, 2016
hartmms pushed a commit to hartmms/home-assistant that referenced this pull request Sep 17, 2016
@home-assistant home-assistant locked and limited conversation to collaborators Mar 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants