* Add workaround to use notification state for zwave lock state
There are several zwave lock models out there which do not seem to
update the lock state on non-rf events (see #11934#14632#14534 for
examples) including kwikset smartkey zwave plus locks (which I own).
In these cases it seems that the notifications for non-rf events the
access_control value is updated but not the primary value for the
lock state, which is what is used to set the is_locked property. To
properly have the lock state accurate for all types of notifications
on these models we need to use the access_control field. This commit
adds a workaround for the 4 models reported to exhibit this behavior
so that home-assistant will reliably set the lock state for all
device notifications.
* Add YRD220 as per adrum to workaround list
* Inline constants
* Add support for locks in google assistant component
This is supported by the smarthome API, but there is no documentation
for it. This work is based on an article I found with screenshots of
documentation that was erroneously uploaded:
https://www.androidpolice.com/2018/01/17/google-assistant-home-can-now-natively-control-smart-locks-august-vivint-first-supported/
Google Assistant now supports unlocking certain locks - Nest and August
come to mind - via this API, and this commit allows Home Assistant to
do so as well.
Notably, I've added a config option `allow_unlock` that controls
whether we actually honor requests to unlock a lock via the google
assistant. It defaults to false.
Additionally, we add the functionNotSupported error, which makes a
little more sense when we're unable to execute the desired state
transition.
https://developers.google.com/actions/reference/smarthome/errors-exceptions#exception_list
* Fix linter warnings
* Ensure that certain groups are never exposed to cloud entities
For example, the group.all_locks entity - we should probably never
expose this to third party cloud integrations. It's risky.
This is not configurable, but can be extended by adding to the
cloud.const.NEVER_EXPOSED_ENTITIES array.
It's implemented in a modestly hacky fashion, because we determine
whether or not a entity should be excluded/included in several ways.
Notably, we define this array in the top level const.py, to avoid
circular import problems between the cloud/alexa components.
* Add config flow step for manual input
Remove support for loading discovery config from json file
* Small cleanup
Fix all translations to step user instead of step init
* Revert to using step_init
* Small cleanup
Add test_gateway that was forgotten in a previous PR
* Fix hound comment
* Fix empty pydocstring
* Remove FFmpeg input tests
* Not needed here
* Removing tests for removed functionality
* Minor lint
* Fix tests to reflect removed config option
* Remove async service registration by request
* More lint
* Unused imports
* Make it a non-breaking change
* Update ffmpeg.py
* Allow Microsoft face detection to handle updating entities when no face is detected
* Remove microsoft_face_detect_no_face_detected.json and hard code in simple empty list into the tests
* Ignore min_cycle_duration when manually controlling the thermostat.
* style
* Generic thermostat: add minimum cycle duration to keep-alive tests.
There was a bug in previous versions of the code, that would not execute
the keep-alive action if the minimum cycle duration hasn't passed.
This test verifies that the keep-alive action is executed correctly.
* Generic thermostat: added tests to verify that changing the
thermostat mode manually triggers the switch, regardless of
minimum cycle duration.
* Updated tests to use `common` module instead of the deprecated `climate`
* Change of behaviour. Allow user to configure either a position topic or a state topic but not
both.
* optimistic mode in set_cover and tests added
* optimistic mode in set_cover_position using percentage_position
* fixes accroding to Martin review.
* added validation schema for set_position_topic and get_position_topic
* check only set_position_topic in supported_features.
* Multidoc string fix.
* Add problem text to message if available
* Revert "Add problem text to message if available"
This reverts commit 7be519bf7fb58356b80bfa459ca4ae229ccd483c.
* Cleanup setup
* Add message template support
* Fix for failing test
* Added tests
* Refactor changes
* Fix lint violation
* Fix failing tests
* Unify handling for message and done_message parameter and sending function
* Update tests
* Fix lint warnings
We were erroneously reporting the _previous_ mode. So if the thermostat was off
and the user asks, "Alexa, set the thermostat to heat", the thermostat would be
set to heat but Alexa would respond, "The thermostat is off."
Bug caught by @Thunderbird2086 at
https://github.com/home-assistant/home-assistant/pull/17969#issuecomment-434654345
* Change date at sunset
* Fix tests to actually run and add fix to component
* Make tests pass
* Use get_astral_event_next instead of get_astral_event_date
* Revert to using get_astral_event_date
* Make tox happy: reset state on tearDown
* Switch mailgun webhooks to the webhook api
* Change mailgun strings to indicate application/json is in use
* Lint
* Revert Changes to .translations.
* Don't fail if the API key isn't set
* Refactor Alexa API to use objects for requests
This introduces _AlexaDirective to stand in for the previous model of passing
basic dict and list data structures to and from handlers. This gives a more
expressive platform for functionality common to most or all handlers.
I had two use cases in mind:
1) Most responses should include current properties. In the case of locks and
thermostats, the response must include the properties or Alexa will give the
user a vague error like "Hmm, $device is not responding." Locks currently work,
but thermostats do not. I wanted a way to automatically include properties in
all responses. This is implemented in a subsequent commit.
2) The previous model had a 1:1 mapping between Alexa endpoints and Home
Assistant entities. This works most of the time, but sometimes it's not so
great. For example, my Z-wave thermostat shows as three devices in Alexa: one
for the temperature sensor, one for the heat, and one for the AC. I'd like to
merge these into one device from Alexa's perspective. I believe this will be
facilitated with the `endpoint` attribute on `_AlexaDirective`.
* Include properties in all Alexa responses
The added _AlexaResponse class provides a richer vocabulary for handlers.
Among that vocabulary is .merge_context_properties(), which is invoked
automatically for any request directed at an endpoint. This adds all supported
properties to the response as recommended by the Alexa API docs, and in some
cases (locks, thermostats at least) the user will get an error "Hmm, $device is
not responding" if properties are not provided in the response.
* Fix setting temperature with Alexa thermostats
Fixes https://github.com/home-assistant/home-assistant/issues/16577
