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

Correct expose_by_default interaction with expose_domains #17745

Merged
merged 1 commit into from
Nov 6, 2018

Conversation

glentakahashi
Copy link
Contributor

@glentakahashi glentakahashi commented Oct 24, 2018

Home Assistant release with the issue:

0.80.3

Last working Home Assistant release (if known):

Operating environment (Hass.io/Docker/Windows/etc.):

Component/platform:

https://www.home-assistant.io/components/google_assistant/#expose_by_default

Description of problem:
Based on the documentation here: https://www.home-assistant.io/components/google_assistant/#expose_by_default it seems that expose_by_default means all devices should be exposed unless explicitly set to false, and that regardless if this is set domains in exposed_domains should be exposed.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

google_assistant:
  project_id: xxx
  api_key: xxx
  expose_by_default: false
  exposed_domains:
    - switch
    - light

Traceback (if applicable):


Additional information:

Based on the documentation here: https://www.home-assistant.io/components/google_assistant/#expose_by_default it seems that expose_by_default means all devices should be exposed unless explicitly set to false, and that regardless if this is set domains in exposed_domains should be exposed.
@homeassistant
Copy link
Contributor

Hi @glentakahashi,

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!

@homeassistant homeassistant added cla-needed integration: google_assistant core merging-to-master This PR is merging into the master branch and should probably change the branch to `dev`. small-pr PRs with less than 30 lines. labels Oct 24, 2018
@ghost ghost added the in progress label Oct 24, 2018
@rohankapoorcom
Copy link
Member

Unclear to me whether this is actually needed or not, but regardless it should be targeted at the dev branch not master

@glentakahashi glentakahashi changed the base branch from master to dev October 25, 2018 07:41
@balloob balloob removed the merging-to-master This PR is merging into the master branch and should probably change the branch to `dev`. label Oct 26, 2018
@balloob
Copy link
Member

balloob commented Oct 26, 2018

It's an and check so that people don't expose domains that we don't support.

@glentakahashi
Copy link
Contributor Author

That doesn't make sense to me. The documentation for expose_by_default says:

Expose devices in all supported domains by default. If set to false, you need to either expose domains or add the expose configuration option to each entity in entity_config and set it to true.

I'm understanding this as, an entity will be exposed if:

  1. expose_by_default is true and is not manually excluded
  2. expose_by_default is false and either:
  3. the domain is exposed by exposed_domains
  4. the device is manually exposed in the entity_config

Right now (using and) the logic is coded to expose things if:

  1. expose_by_default is true, the domain is in exposed_domains, and is not manually excluded
  2. expose_by_default is false and the device is manually exposed in entity_config

So which one is right here? If the docs are wrong I can make a PR to fix those, but in my opinion the docs behavior is the more intuitive one and this PR will adjust the code to work like that.

@balloob
Copy link
Member

balloob commented Nov 1, 2018

If a domain is not in expose_by_default, it's not supported. So no need to route entities through the GA flow and then make it generate a ton of warnings.

@balloob balloob closed this Nov 1, 2018
@ghost ghost removed the in progress label Nov 1, 2018
@glentakahashi
Copy link
Contributor Author

glentakahashi commented Nov 1, 2018

@balloob I still believe either the documentation or code needs changing here. The documentation doesn't match up with how the code works. Take this example. Let's say I have three devices in three domains, one of which is unsupported:

Devices:

  • bedroom_light - LIGHT
  • bedroom_switch - SWITCH
  • bedroom_test - TEST

Current behavior:

expose_by_default: true

LIGHT, SWITCH are exposed

expose_by_default: true
exposed_domains: LIGHT

only LIGHT is exposed

expose_by_default: false
exposed_domains: LIGHT

no devices are exposed

expose_by_default: false
exposed_domains: LIGHT
devices:
  bedroom_switch:
    expose: true

only SWITCH is exposed

Using OR behavior:

expose_by_default: true

LIGHT, SWITCH are exposed

expose_by_default: true
exposed_domains: LIGHT

LIGHT, SWITCH are exposed

expose_by_default: false
exposed_domains: LIGHT

LIGHT is exposed

expose_by_default: false
exposed_domains: LIGHT
devices:
  bedroom_switch:
    expose: true

LIGHT, SWITCH are exposed

To me, use cases #3 and #4 are what seem wrong in the current behavior. I see someone updated the documentation today to make it clear this is how it works (home-assistant/home-assistant.io#7292) but I think the config can still be improved.

In my opinion, if not the OR behavior above there are a few other alternatives:

Lastly, currently the code itself doesn't protect against unsupported domains in GA either. The only line of code that uses the filtered set of domains is in the default configuration above. To actually support this, I think instead in const.py there should be a list of supported_domains and that is intersected with the provided exposed_domains and device sets. Right now, if I were to add a exposed_domains: TEST, the code would actually expose the TEST domain to GA.

Sorry for the long post, but just want to clear this up.

@balloob balloob reopened this Nov 2, 2018
@ghost ghost assigned balloob Nov 2, 2018
@ghost ghost added the in progress label Nov 2, 2018
@balloob
Copy link
Member

balloob commented Nov 2, 2018

I'm sorry, looks like you're right.

@balloob balloob merged commit 34d7758 into home-assistant:dev Nov 6, 2018
@ghost ghost removed the in progress label Nov 6, 2018
@glentakahashi glentakahashi deleted the patch-1 branch November 12, 2018 14:23
glentakahashi added a commit to glentakahashi/home-assistant.io that referenced this pull request Nov 12, 2018
Now that home-assistant/core#17745 has been merged, the original documentation is back to being correct so the docs changes should be reverted once the version with home-assistant/core#17745 has been released.
frenck pushed a commit to home-assistant/home-assistant.io that referenced this pull request Nov 19, 2018
* Revert #7292

Now that home-assistant/core#17745 has been merged, the original documentation is back to being correct so the docs changes should be reverted once the version with home-assistant/core#17745 has been released.

* Add missing quote
@balloob balloob mentioned this pull request Nov 29, 2018
@balloob
Copy link
Member

balloob commented Dec 4, 2018

we need to revert this change because it's causing issues #18856

@glentakahashi
Copy link
Contributor Author

oh no! Sorry about the issues that this is causing. Would you be okay with me putting out another PR with better functionality + testing after you revert?

balloob added a commit that referenced this pull request Dec 6, 2018
@balloob balloob mentioned this pull request Dec 6, 2018
@balloob
Copy link
Member

balloob commented Dec 6, 2018

If we do so, it should be done as a non breaking change.

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.

5 participants