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

Fix for stateless covers #22962

Merged
merged 6 commits into from Apr 15, 2019
Merged

Fix for stateless covers #22962

merged 6 commits into from Apr 15, 2019

Conversation

giefca
Copy link
Contributor

@giefca giefca commented Apr 10, 2019

Description:

Stateless covers didn't work with previous trait

Related issue (if applicable): fixes #22740

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.

If the code does not interact with devices:

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

cover.DOMAIN, cover.SERVICE_CLOSE_COVER, {
ATTR_ENTITY_ID: self.state.entity_id
}, blocking=True, context=data.context)
if position is not None:
Copy link
Member

Choose a reason for hiding this comment

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

merge this into else on line above and make it elif

cover.DOMAIN, cover.SERVICE_OPEN_COVER, {
ATTR_ENTITY_ID: self.state.entity_id
}, blocking=True, context=data.context)
if self.state.state != cover.STATE_CLOSED:
Copy link
Member

Choose a reason for hiding this comment

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

same

Copy link
Member

Choose a reason for hiding this comment

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

Also, we should remove this logic. This makes no sense. We get explicit commands from Google, not toggle commands. We should not have the current state influence how we handle it.

Copy link
Member

@balloob balloob left a comment

Choose a reason for hiding this comment

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

Please add a test

@balloob balloob added this to the 0.92.0 milestone Apr 10, 2019
@balloob
Copy link
Member

balloob commented Apr 10, 2019

I have reached out to Google about this issue, this is their suggested fix:

The easiest way to do this is to send willReportState:false and return the error code notSupported for queries. CommandOnly support is oncoming, but it's been delayed. Internally, it works the same way though

@@ -1050,6 +1051,8 @@ def query_attributes(self):
# open, even if that is currently incorrect.
if self.state.attributes.get(ATTR_ASSUMED_STATE):
response['openPercent'] = 50
elif self.state.state == STATE_UNKNOWN:
Copy link
Member

Choose a reason for hiding this comment

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

See my comment with the response from Google. We should raise NotSupported error instead when it's an assumed state or unknown state.

@giefca
Copy link
Contributor Author

giefca commented Apr 11, 2019

Accidentally closed the PR while pushing corrections.

@giefca giefca reopened this Apr 11, 2019
@ghost ghost added the in progress label Apr 11, 2019
@codecov
Copy link

codecov bot commented Apr 11, 2019

Codecov Report

Merging #22962 into dev will decrease coverage by 0.11%.
The diff coverage is 75%.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev   #22962      +/-   ##
==========================================
- Coverage   93.95%   93.84%   -0.12%     
==========================================
  Files         448      449       +1     
  Lines       36750    36767      +17     
==========================================
- Hits        34529    34503      -26     
- Misses       2221     2264      +43
Impacted Files Coverage Δ
homeassistant/components/google_assistant/trait.py 96.57% <75%> (+0.43%) ⬆️
homeassistant/components/mqtt/light/schema_json.py 73.06% <0%> (-20.67%) ⬇️
homeassistant/components/mqtt/lock.py 91.83% <0%> (-8.17%) ⬇️
homeassistant/loader.py 94.11% <0%> (-0.2%) ⬇️
homeassistant/helpers/service.py 93.19% <0%> (-0.08%) ⬇️
homeassistant/helpers/entity_component.py 96.18% <0%> (-0.03%) ⬇️
homeassistant/components/deconz/deconz_device.py 100% <0%> (ø) ⬆️
homeassistant/helpers/aiohttp_client.py 95.34% <0%> (ø) ⬆️
homeassistant/components/demo/media_player.py 95.42% <0%> (ø) ⬆️
...assistant/components/mqtt/light/schema_template.py 80.27% <0%> (ø) ⬆️
... and 9 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d078e50...3c506e2. Read the comment docs.

@@ -1049,7 +1050,9 @@ def query_attributes(self):
# Google will not issue an open command if the assumed state is
# open, even if that is currently incorrect.
if self.state.attributes.get(ATTR_ASSUMED_STATE):
response['openPercent'] = 50
response['willReportState'] = False
Copy link
Member

Choose a reason for hiding this comment

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

This is wrong. reportState is a sync attribute and we already set it to False. You need to raise an error instead

            raise SmartHomeError(
                ERR_FUNCTION_NOT_SUPPORTED,
                'Querying state is not supported')

Copy link
Member

Choose a reason for hiding this comment

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

And you need to raise that error when it's both assumed state and when it's unknown.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, but it won't fix the issue. It looks like google assistant is making a query before executing an open/close command. When we raise an error on query it raises the same error while executing the command. While CommandOnly is not available can we just assume openPercent = 50? It would allow us to open and close stateless covers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't raising the right error. Now with ERR_NOT_SUPPORTED it works. Stateless covers are moving but google assistant says otherwise due to the raised error.

cover.DOMAIN, cover.SERVICE_OPEN_COVER, {
ATTR_ENTITY_ID: self.state.entity_id
}, blocking=True, context=data.context)
if params['openPercent'] < 100:
Copy link
Member

Choose a reason for hiding this comment

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

These two checks can be removed? We should not get a position and not be able to deal with it. Google should return just 0 or 100 for covers that we won't support getting the state from.

Copy link
Contributor Author

@giefca giefca Apr 11, 2019

Choose a reason for hiding this comment

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

It can be removed, I can raise an error instead. I though it was better to open and close the cover with a position command even if it didn't support setting a position.

                raise SmartHomeError(
                    ERR_FUNCTION_NOT_SUPPORTED,
                    'Setting a position is not supported')

Copy link
Member

Choose a reason for hiding this comment

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

In what cases do we get here?

Copy link
Contributor Author

@giefca giefca Apr 13, 2019

Choose a reason for hiding this comment

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

We get here if we ask for a position and the cover doesn't support setting position. Raising this error may be less confusing for the user than a cover not doing what he asked.

@pergolafabio
Copy link

Hey, do you want is to test it again?

# Assumed state
trt = trait.OpenCloseTrait(hass, State('cover.bla', cover.STATE_OPEN, {
ATTR_ASSUMED_STATE: True,
}), BASIC_CONFIG)

assert trt.sync_attributes() == {}
assert trt.query_attributes() == {
Copy link
Member

Choose a reason for hiding this comment

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

Can you update the test to make sure that we raise for unknown and assumed state?

with pytest.raises(SmartHomeError):
    trt.query_attributes()

Copy link
Member

@balloob balloob left a comment

Choose a reason for hiding this comment

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

Awesome, thanks ! This will be part of the beta on Wednesday, released a week later 👍

@balloob balloob removed this from the 0.92.0 milestone Apr 15, 2019
@HarrisonPace
Copy link
Contributor

This PR isn't ideal:

As of the 0.92 update it will issue the command thanks to #22962, however it replies with "that mode isn't available for the "cover name"". Even though the command is sent and the cover opens. Very annoying to hear that each time.

I opened an issue here: #23226

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Google Assistant Covers, not working anymore with 91.0 open/close
5 participants