Bug: fix google_assistant 'allow_unlock' config option#18874
Bug: fix google_assistant 'allow_unlock' config option#18874balloob merged 1 commit intohome-assistant:devfrom
Conversation
|
Figured I would comment here as well. This change doesn't appear to fix the issue for me. Behavior is identical to #18848 for me |
|
^ Thanks for the report. I've done more testing, and I agree it's actually not fixed. The |
The `Config` object specific to the `google_assistant` component had a default value for `allow_unlock`. We were not overriding this default when constructing the Config object during `google_assistant` component setup, whereas we do when setting up the `cloud` component. To fix, we thread the `allow_unlock` parameter down through http setup, and ensure that it's set correctly. Moreover, we also change the ordering of the `Config` parameters, and remove the default. Future refactoring should not miss it, as it is now a required parameter.
61f7a61 to
d06a781
Compare
|
For any reviewers out there, I believe this is ready for review now. |
|
Happy to test but not sure how to? Is there a zip file I could place in custom_components? |
|
@omriasta - Thank you, I appreciate that. I do believe it's fixed now - I was able to reproduce the bug and work on it directly - but your confirmation would be nice. Here's a zip file: You should be able to unzip that into custom_components. Make sure to move the zipfile out of |
|
Thanks, just tested and have success! |
|
Spoke too soon....for some reason, now when I unlock the door using hass or Google assistant, the status is not updated in hass...the UI shows that the door is still locked and will not let me lock it again.... Google assistant will relock if i try through there...very odd |
Since you have a Schlage BE469, that's actually a different bug - #18737 has a fix for that. If Google successfully unlocked your door when you asked, then this patch does what it was supposed to do. 😄 |
|
Just put the zwave.py in custom_components/lock and now it's working correctly and updating. Thanks for all your help!!! |
…k` (#18874) The `Config` object specific to the `google_assistant` component had a default value for `allow_unlock`. We were not overriding this default when constructing the Config object during `google_assistant` component setup, whereas we do when setting up the `cloud` component. To fix, we thread the `allow_unlock` parameter down through http setup, and ensure that it's set correctly. Moreover, we also change the ordering of the `Config` parameters, and remove the default. Future refactoring should not miss it, as it is now a required parameter.
Description
I failed to thread the
allow_unlockpreference down from where we actually read thegoogle_assistantpreferences, through to theConfigobject that holds preferences in the http view. This was done correctly for thecloudcomponent, but I missed it here. This PR also removes the default value for this parameter on theConfigobject, which is how it was missed before. As a required param, future refactoring will not miss it.Related issue (if applicable): fixes #18848
Checklist:
tox. Your PR cannot be merged unless tests pass