Fixed AlexaPowerController to report power state for thermostats, to look if state is OFF return OFF, otherwise report ON as thermostats have multiple values for ON
* Move more constants to const.py
* Import constants directly from const
* ATTR_ENTITY_ID is not defined in media_player
* MEDIA_PLAYER_PLAY_MEDIA_SCHEMA is still in __init__.py
* Correct imports in tts
* PLATFORM_SCHEMA, SCHEMA is still defined in __init__.py
* Pandora imports several services
* Some additional fixes for move of const in media_player
* Fix hound lengths
* Alexa: implement auth and proactive ChangeReport messages
* refactor after rebase from dev to use the new AlexaDirective and Response classes
* move to aiohttp; cleanup
* better function name
* move endpoint to config
* allow passing token function
* remove uneeded state get
* use iterable directly
Co-Authored-By: abmantis <abmantis@users.noreply.github.com>
* missing delete from previous commit
* checks for when user has no auth config
* update cloud component
* PR suggestions
* string lint
* Revert "string lint"
This reverts commit a05a1f134c9ebc7a6e67c093009744f142256365.
* linters are now happier
* more happy linters
* use internal date parser; improve json response handling
* remove unused import
* use await instead of async_add_job
* protect access token update method
* add test_report_state
* line too long
* add docstring
* Update test_smart_home.py
* test accept grant api
* init prefs if None
* add tests for auth and token requests
* replace global with hass.data
* doc lint
* 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.
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
* 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
* Remove unit_of_measurement from climate base class.
* Updated google_assistant component and tests to use core temp units.
* Fixes
* Convert Alexa component to use core temp units for climate entities.
* Fix tests.
* Converted prometheus component.
* Remove unit_of_measurement from homekit thermostat tests.
* Small fix.
## Description:
More fixes flagged by pylint 2 that don't hurt to have before the actual pylint 2 upgrade (which I'll submit soon).
## Checklist:
- [ ] The code change is tested and works locally.
- [x] Local tests pass with `tox`. **Your PR cannot be merged unless tests pass**
* Implement thermostat support for Alexa
* util.temperature: Support interval conversions
* Use climate.ATTR_OPERATION_MODE for Alexa thermostat mode
* Switch coroutines to async/await
* Log all Alexa error events
* Accept and report both xy and RGB color for lights
* Fix demo light supported_features
* Add new XY color util functions
* Always make color changes available as xy and RGB
* Always expose color as RGB and XY
* Consolidate color supported_features
* Test fixes
* Additional test fix
* Use hue/sat as the hass core color interface
* Tests updates
* Assume MQTT RGB devices need full RGB brightness
* Convert new platforms
* More migration
* Use float for HS API
* Fix backwards conversion for KNX lights
* Adjust limitless min saturation for new scale
It turns out I misunderstood which media_player services are available
when a media player supports StepVolume. This PR maps the Alexa
StepSpeaker messages to the volume_up and volume_down services.
Currently Alexa allows you to specify the number of steps but the media
player volume_up and volume_down services don't support this. For now I
just look to see if the steps are +/- and call up/down accordingly.
* Refactor Alexa Smart Home API
Having an object per interface will make it easier to support
properties.
Ideally, properties are reported in context in all responses. However
current implementation reports them only in response to a ReportState
request. This seems to work sufficiently. As long as the device is
opened in the Alexa app, Amazon will poll the device state every few
seconds with a ReportState request.
* Report properties for some Alexa interfaces
Fixes (mostly) #11874.
Other interfaces will need properties implemented as well.
Implementing properties for just PowerController seems sufficient to
eliminate the "There was a problem." error for any device that supports
it, even if other interfaces are supported. Of course the additional
properties will be reported incorrectly in the Alexa app.
Includes a minor bugfix: `reportable` was previously placed incorrectly
in the responses, so Amazon was ignoring it.
Having an object per interface will make it easier to support
properties.
Ideally, properties are reported in context in all responses. However
current implementation reports them only in response to a ReportState
request. This seems to work sufficiently. As long as the device is
opened in the Alexa app, Amazon will poll the device state every few
seconds with a ReportState request.
* Send Alexa Smart Home responses to debug log
* Report scripts and groups as scenes to Alexa
The Alexa API docs have a couple display categories that sound relevant
to scenes or scripts:
ACTIVITY_TRIGGER: Describes a combination of devices set to a
specific state, when the state change must occur in a specific
order. For example, a “watch Neflix” scene might require the: 1. TV
to be powered on & 2. Input set to HDMI1.
SCENE_TRIGGER: Describes a combination of devices set to a specific
state, when the order of the state change is not important. For
example a bedtime scene might include turning off lights and
lowering the thermostat, but the order is unimportant.
Additionally, Alexa has a notion of scenes that support deactivation.
This is a natural fit for groups, and scripts with delays which can be
cancelled.
https://developer.amazon.com/docs/device-apis/alexa-discovery.html#display-categories
The mechanism to map entities to the Alexa Discovery response is
refactored since extending the data structures in MAPPING_COMPONENT to
implement supportsDeactivation would have added complication to what I
already found to be a confusing construct.
* Expose Alexa Smart Home via HTTP POST
Haaska uses the deprecated v2 Alexa Smart Home payload. Exposing the v3
implementation this way allows an easy path to upgrading Haaska and
reducing code duplication with Home Assistant Cloud.
* Expose Alexa Smart Home via HTTP POST
Haaska uses the deprecated v2 Alexa Smart Home payload. Exposing the v3
implementation this way allows an easy path to upgrading Haaska and
reducing code duplication with Home Assistant Cloud.
Pascal Vizeli
mcc05
Jack Wilsdon
Jason Hu
Joakim Plate
Fabian Affolter
Martin Gross
Abílio Costa
Mike Miller
Matthew Parlane
Andrew Hayworth
Phil Frost
Paulus Schoutsen
Ryan Wagoner
cdce8p
Jerad Meisner
Paulus Schoutsen
Ville Skyttä
iliketoprogram14
Michael Wei
Albert Lee
Adam Mills
Richard Lucas
Otto Winter
Phil Kates