Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Support for alexa Smart Home Skill API.
|
|
|
|
|
|
|
|
API documentation:
|
|
|
|
https://developer.amazon.com/docs/smarthome/understand-the-smart-home-skill-api.html
|
|
|
|
https://developer.amazon.com/docs/device-apis/message-guide.html
|
|
|
|
"""
|
|
|
|
|
2018-10-29 19:52:34 +00:00
|
|
|
from collections import OrderedDict
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
from datetime import datetime
|
2017-09-16 19:35:28 +00:00
|
|
|
import logging
|
2017-11-01 03:28:17 +00:00
|
|
|
import math
|
2017-09-16 19:35:28 +00:00
|
|
|
from uuid import uuid4
|
|
|
|
|
2018-01-21 06:35:38 +00:00
|
|
|
from homeassistant.components import (
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
alert, automation, binary_sensor, climate, cover, fan, group, http,
|
|
|
|
input_boolean, light, lock, media_player, scene, script, sensor, switch)
|
2017-09-16 19:35:28 +00:00
|
|
|
from homeassistant.const import (
|
2018-10-25 14:46:43 +00:00
|
|
|
ATTR_DEVICE_CLASS, ATTR_ENTITY_ID, ATTR_SUPPORTED_FEATURES,
|
Add support for locks in google assistant component (#18233)
* 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.
2018-11-06 09:39:10 +00:00
|
|
|
ATTR_TEMPERATURE, ATTR_UNIT_OF_MEASUREMENT, CLOUD_NEVER_EXPOSED_ENTITIES,
|
|
|
|
CONF_NAME, SERVICE_LOCK, SERVICE_MEDIA_NEXT_TRACK, SERVICE_MEDIA_PAUSE,
|
|
|
|
SERVICE_MEDIA_PLAY, SERVICE_MEDIA_PREVIOUS_TRACK, SERVICE_MEDIA_STOP,
|
2017-11-17 17:14:22 +00:00
|
|
|
SERVICE_SET_COVER_POSITION, SERVICE_TURN_OFF, SERVICE_TURN_ON,
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
SERVICE_UNLOCK, SERVICE_VOLUME_SET, STATE_LOCKED, STATE_ON, STATE_UNLOCKED,
|
|
|
|
TEMP_CELSIUS, TEMP_FAHRENHEIT)
|
|
|
|
import homeassistant.core as ha
|
|
|
|
import homeassistant.util.color as color_util
|
|
|
|
from homeassistant.util.decorator import Registry
|
|
|
|
from homeassistant.util.temperature import convert as convert_temperature
|
2018-03-30 06:49:08 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
from .const import CONF_ENTITY_CONFIG, CONF_FILTER
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
_LOGGER = logging.getLogger(__name__)
|
|
|
|
|
2017-10-07 20:31:57 +00:00
|
|
|
API_DIRECTIVE = 'directive'
|
2017-11-17 17:14:22 +00:00
|
|
|
API_ENDPOINT = 'endpoint'
|
2017-10-07 20:31:57 +00:00
|
|
|
API_EVENT = 'event'
|
2018-01-26 18:40:39 +00:00
|
|
|
API_CONTEXT = 'context'
|
2017-10-07 20:31:57 +00:00
|
|
|
API_HEADER = 'header'
|
|
|
|
API_PAYLOAD = 'payload'
|
2017-11-17 17:14:22 +00:00
|
|
|
|
2018-01-26 18:40:39 +00:00
|
|
|
API_TEMP_UNITS = {
|
|
|
|
TEMP_FAHRENHEIT: 'FAHRENHEIT',
|
|
|
|
TEMP_CELSIUS: 'CELSIUS',
|
|
|
|
}
|
|
|
|
|
2018-10-29 19:52:34 +00:00
|
|
|
# Needs to be ordered dict for `async_api_set_thermostat_mode` which does a
|
|
|
|
# reverse mapping of this dict and we want to map the first occurrance of OFF
|
|
|
|
# back to HA state.
|
|
|
|
API_THERMOSTAT_MODES = OrderedDict([
|
|
|
|
(climate.STATE_HEAT, 'HEAT'),
|
|
|
|
(climate.STATE_COOL, 'COOL'),
|
|
|
|
(climate.STATE_AUTO, 'AUTO'),
|
|
|
|
(climate.STATE_ECO, 'ECO'),
|
|
|
|
(climate.STATE_OFF, 'OFF'),
|
|
|
|
(climate.STATE_IDLE, 'OFF'),
|
|
|
|
(climate.STATE_FAN_ONLY, 'OFF'),
|
|
|
|
(climate.STATE_DRY, 'OFF')
|
|
|
|
])
|
2018-03-30 06:49:08 +00:00
|
|
|
|
2018-01-23 18:45:28 +00:00
|
|
|
SMART_HOME_HTTP_ENDPOINT = '/api/alexa/smart_home'
|
|
|
|
|
2018-01-05 20:33:22 +00:00
|
|
|
CONF_DESCRIPTION = 'description'
|
|
|
|
CONF_DISPLAY_CATEGORIES = 'display_categories'
|
2017-09-16 19:35:28 +00:00
|
|
|
|
2018-01-21 06:35:38 +00:00
|
|
|
HANDLERS = Registry()
|
2018-01-29 00:43:27 +00:00
|
|
|
ENTITY_ADAPTERS = Registry()
|
2018-08-20 12:18:07 +00:00
|
|
|
EVENT_ALEXA_SMART_HOME = 'alexa_smart_home'
|
2017-09-16 19:35:28 +00:00
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-07-20 08:45:20 +00:00
|
|
|
class _DisplayCategory:
|
2018-01-26 05:06:57 +00:00
|
|
|
"""Possible display categories for Discovery response.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-discovery.html#display-categories
|
|
|
|
"""
|
|
|
|
|
|
|
|
# Describes a combination of devices set to a specific state, when the
|
|
|
|
# state change must occur in a specific order. For example, a "watch
|
2018-01-29 22:37:19 +00:00
|
|
|
# Netflix" scene might require the: 1. TV to be powered on & 2. Input set
|
|
|
|
# to HDMI1. Applies to Scenes
|
2018-01-26 05:06:57 +00:00
|
|
|
ACTIVITY_TRIGGER = "ACTIVITY_TRIGGER"
|
|
|
|
|
|
|
|
# Indicates media devices with video or photo capabilities.
|
|
|
|
CAMERA = "CAMERA"
|
|
|
|
|
2018-10-25 14:46:43 +00:00
|
|
|
# Indicates an endpoint that detects and reports contact.
|
|
|
|
CONTACT_SENSOR = "CONTACT_SENSOR"
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
# Indicates a door.
|
|
|
|
DOOR = "DOOR"
|
|
|
|
|
|
|
|
# Indicates light sources or fixtures.
|
|
|
|
LIGHT = "LIGHT"
|
|
|
|
|
2018-10-26 21:43:31 +00:00
|
|
|
# Indicates an endpoint that detects and reports motion.
|
|
|
|
MOTION_SENSOR = "MOTION_SENSOR"
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
# An endpoint that cannot be described in on of the other categories.
|
|
|
|
OTHER = "OTHER"
|
|
|
|
|
|
|
|
# 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. Applies to Scenes
|
|
|
|
SCENE_TRIGGER = "SCENE_TRIGGER"
|
|
|
|
|
|
|
|
# Indicates an endpoint that locks.
|
|
|
|
SMARTLOCK = "SMARTLOCK"
|
|
|
|
|
|
|
|
# Indicates modules that are plugged into an existing electrical outlet.
|
|
|
|
# Can control a variety of devices.
|
|
|
|
SMARTPLUG = "SMARTPLUG"
|
|
|
|
|
|
|
|
# Indicates the endpoint is a speaker or speaker system.
|
|
|
|
SPEAKER = "SPEAKER"
|
|
|
|
|
|
|
|
# Indicates in-wall switches wired to the electrical system. Can control a
|
|
|
|
# variety of devices.
|
|
|
|
SWITCH = "SWITCH"
|
|
|
|
|
|
|
|
# Indicates endpoints that report the temperature only.
|
|
|
|
TEMPERATURE_SENSOR = "TEMPERATURE_SENSOR"
|
|
|
|
|
|
|
|
# Indicates endpoints that control temperature, stand-alone air
|
|
|
|
# conditioners, or heaters with direct temperature control.
|
|
|
|
THERMOSTAT = "THERMOSTAT"
|
|
|
|
|
|
|
|
# Indicates the endpoint is a television.
|
|
|
|
TV = "TV"
|
|
|
|
|
|
|
|
|
|
|
|
def _capability(interface,
|
|
|
|
version=3,
|
|
|
|
supports_deactivation=None,
|
2018-01-26 18:40:39 +00:00
|
|
|
retrievable=None,
|
|
|
|
properties_supported=None,
|
2018-01-26 05:06:57 +00:00
|
|
|
cap_type='AlexaInterface'):
|
|
|
|
"""Return a Smart Home API capability object.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-discovery.html#capability-object
|
|
|
|
|
|
|
|
There are some additional fields allowed but not implemented here since
|
|
|
|
we've no use case for them yet:
|
|
|
|
|
|
|
|
- proactively_reported
|
|
|
|
|
|
|
|
`supports_deactivation` applies only to scenes.
|
|
|
|
"""
|
|
|
|
result = {
|
|
|
|
'type': cap_type,
|
|
|
|
'interface': interface,
|
|
|
|
'version': version,
|
|
|
|
}
|
|
|
|
|
|
|
|
if supports_deactivation is not None:
|
|
|
|
result['supportsDeactivation'] = supports_deactivation
|
|
|
|
|
2018-01-26 18:40:39 +00:00
|
|
|
if retrievable is not None:
|
|
|
|
result['retrievable'] = retrievable
|
|
|
|
|
|
|
|
if properties_supported is not None:
|
|
|
|
result['properties'] = {'supported': properties_supported}
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
return result
|
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
class _UnsupportedInterface(Exception):
|
|
|
|
"""This entity does not support the requested Smart Home API interface."""
|
|
|
|
|
|
|
|
|
|
|
|
class _UnsupportedProperty(Exception):
|
|
|
|
"""This entity does not support the requested Smart Home API property."""
|
|
|
|
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
class _AlexaError(Exception):
|
|
|
|
"""Base class for errors that can be serialized by the Alexa API.
|
|
|
|
|
|
|
|
A handler can raise subclasses of this to return an error to the request.
|
|
|
|
"""
|
|
|
|
|
|
|
|
namespace = None
|
|
|
|
error_type = None
|
|
|
|
|
|
|
|
def __init__(self, error_message, payload=None):
|
|
|
|
Exception.__init__(self)
|
|
|
|
self.error_message = error_message
|
|
|
|
self.payload = None
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaInvalidEndpointError(_AlexaError):
|
|
|
|
"""The endpoint in the request does not exist."""
|
|
|
|
|
|
|
|
namespace = 'Alexa'
|
|
|
|
error_type = 'NO_SUCH_ENDPOINT'
|
|
|
|
|
|
|
|
def __init__(self, endpoint_id):
|
|
|
|
msg = 'The endpoint {} does not exist'.format(endpoint_id)
|
|
|
|
_AlexaError.__init__(self, msg)
|
|
|
|
self.endpoint_id = endpoint_id
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaInvalidValueError(_AlexaError):
|
|
|
|
namespace = 'Alexa'
|
|
|
|
error_type = 'INVALID_VALUE'
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaUnsupportedThermostatModeError(_AlexaError):
|
|
|
|
namespace = 'Alexa.ThermostatController'
|
|
|
|
error_type = 'UNSUPPORTED_THERMOSTAT_MODE'
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaTempRangeError(_AlexaError):
|
|
|
|
namespace = 'Alexa'
|
|
|
|
error_type = 'TEMPERATURE_VALUE_OUT_OF_RANGE'
|
|
|
|
|
|
|
|
def __init__(self, hass, temp, min_temp, max_temp):
|
|
|
|
unit = hass.config.units.temperature_unit
|
|
|
|
temp_range = {
|
|
|
|
'minimumValue': {
|
|
|
|
'value': min_temp,
|
|
|
|
'scale': API_TEMP_UNITS[unit],
|
|
|
|
},
|
|
|
|
'maximumValue': {
|
|
|
|
'value': max_temp,
|
|
|
|
'scale': API_TEMP_UNITS[unit],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
payload = {'validRange': temp_range}
|
|
|
|
msg = 'The requested temperature {} is out of range'.format(temp)
|
|
|
|
|
|
|
|
_AlexaError.__init__(self, msg, payload)
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaBridgeUnreachableError(_AlexaError):
|
|
|
|
namespace = 'Alexa'
|
|
|
|
error_type = 'BRIDGE_UNREACHABLE'
|
|
|
|
|
|
|
|
|
2018-07-20 08:45:20 +00:00
|
|
|
class _AlexaEntity:
|
2018-01-29 00:43:27 +00:00
|
|
|
"""An adaptation of an entity, expressed in Alexa's terms.
|
|
|
|
|
|
|
|
The API handlers should manipulate entities only through this interface.
|
|
|
|
"""
|
|
|
|
|
2018-08-22 07:17:29 +00:00
|
|
|
def __init__(self, hass, config, entity):
|
|
|
|
self.hass = hass
|
2018-01-26 05:06:57 +00:00
|
|
|
self.config = config
|
|
|
|
self.entity = entity
|
2018-01-29 00:43:27 +00:00
|
|
|
self.entity_conf = config.entity_config.get(entity.entity_id, {})
|
|
|
|
|
|
|
|
def friendly_name(self):
|
|
|
|
"""Return the Alexa API friendly name."""
|
|
|
|
return self.entity_conf.get(CONF_NAME, self.entity.name)
|
|
|
|
|
|
|
|
def description(self):
|
|
|
|
"""Return the Alexa API description."""
|
|
|
|
return self.entity_conf.get(CONF_DESCRIPTION, self.entity.entity_id)
|
|
|
|
|
|
|
|
def entity_id(self):
|
|
|
|
"""Return the Alexa API entity id."""
|
|
|
|
return self.entity.entity_id.replace('.', '#')
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
def display_categories(self):
|
|
|
|
"""Return a list of display categories."""
|
|
|
|
entity_conf = self.config.entity_config.get(self.entity.entity_id, {})
|
|
|
|
if CONF_DISPLAY_CATEGORIES in entity_conf:
|
|
|
|
return [entity_conf[CONF_DISPLAY_CATEGORIES]]
|
|
|
|
return self.default_display_categories()
|
|
|
|
|
|
|
|
def default_display_categories(self):
|
|
|
|
"""Return a list of default display categories.
|
|
|
|
|
|
|
|
This can be overridden by the user in the Home Assistant configuration.
|
|
|
|
|
|
|
|
See also _DisplayCategory.
|
|
|
|
"""
|
|
|
|
raise NotImplementedError
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def get_interface(self, capability):
|
|
|
|
"""Return the given _AlexaInterface.
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
Raises _UnsupportedInterface.
|
|
|
|
"""
|
|
|
|
pass
|
|
|
|
|
|
|
|
def interfaces(self):
|
|
|
|
"""Return a list of supported interfaces.
|
2018-01-26 18:40:39 +00:00
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
Used for discovery. The list should contain _AlexaInterface instances.
|
|
|
|
If the list is empty, this entity will not be discovered.
|
2018-01-26 05:06:57 +00:00
|
|
|
"""
|
|
|
|
raise NotImplementedError
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
def serialize_properties(self):
|
|
|
|
"""Yield each supported property in API format."""
|
|
|
|
for interface in self.interfaces():
|
|
|
|
for prop in interface.serialize_properties():
|
|
|
|
yield prop
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-07-20 08:45:20 +00:00
|
|
|
class _AlexaInterface:
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Base class for Alexa capability interfaces.
|
|
|
|
|
|
|
|
The Smart Home Skills API defines a number of "capability interfaces",
|
|
|
|
roughly analogous to domains in Home Assistant. The supported interfaces
|
|
|
|
describe what actions can be performed on a particular device.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/message-guide.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def __init__(self, entity):
|
|
|
|
self.entity = entity
|
|
|
|
|
|
|
|
def name(self):
|
|
|
|
"""Return the Alexa API name of this interface."""
|
|
|
|
raise NotImplementedError
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def properties_supported():
|
|
|
|
"""Return what properties this entity supports."""
|
|
|
|
return []
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def properties_proactively_reported():
|
|
|
|
"""Return True if properties asynchronously reported."""
|
|
|
|
return False
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def properties_retrievable():
|
|
|
|
"""Return True if properties can be retrieved."""
|
|
|
|
return False
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def get_property(name):
|
|
|
|
"""Read and return a property.
|
|
|
|
|
|
|
|
Return value should be a dict, or raise _UnsupportedProperty.
|
|
|
|
|
|
|
|
Properties can also have a timeOfSample and uncertaintyInMilliseconds,
|
|
|
|
but returning those metadata is not yet implemented.
|
|
|
|
"""
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def supports_deactivation():
|
|
|
|
"""Applicable only to scenes."""
|
|
|
|
return None
|
|
|
|
|
|
|
|
def serialize_discovery(self):
|
|
|
|
"""Serialize according to the Discovery API."""
|
|
|
|
result = {
|
|
|
|
'type': 'AlexaInterface',
|
|
|
|
'interface': self.name(),
|
|
|
|
'version': '3',
|
|
|
|
'properties': {
|
|
|
|
'supported': self.properties_supported(),
|
|
|
|
'proactivelyReported': self.properties_proactively_reported(),
|
2018-01-29 01:00:34 +00:00
|
|
|
'retrievable': self.properties_retrievable(),
|
2018-01-29 00:43:27 +00:00
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
# pylint: disable=assignment-from-none
|
|
|
|
supports_deactivation = self.supports_deactivation()
|
|
|
|
if supports_deactivation is not None:
|
|
|
|
result['supportsDeactivation'] = supports_deactivation
|
|
|
|
return result
|
|
|
|
|
|
|
|
def serialize_properties(self):
|
|
|
|
"""Return properties serialized for an API response."""
|
|
|
|
for prop in self.properties_supported():
|
|
|
|
prop_name = prop['name']
|
2018-07-09 09:44:50 +00:00
|
|
|
# pylint: disable=assignment-from-no-return
|
|
|
|
prop_value = self.get_property(prop_name)
|
|
|
|
if prop_value is not None:
|
|
|
|
yield {
|
|
|
|
'name': prop_name,
|
|
|
|
'namespace': self.name(),
|
|
|
|
'value': prop_value,
|
|
|
|
}
|
2018-01-29 00:43:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
class _AlexaPowerController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.PowerController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-powercontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.PowerController'
|
|
|
|
|
2018-01-29 01:00:34 +00:00
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'powerState'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'powerState':
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
|
|
|
if self.entity.state == STATE_ON:
|
|
|
|
return 'ON'
|
|
|
|
return 'OFF'
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
|
|
|
|
class _AlexaLockController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.LockController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-lockcontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.LockController'
|
|
|
|
|
2018-01-29 01:00:34 +00:00
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'lockState'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'lockState':
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
|
|
|
if self.entity.state == STATE_LOCKED:
|
|
|
|
return 'LOCKED'
|
2018-07-23 08:16:05 +00:00
|
|
|
if self.entity.state == STATE_UNLOCKED:
|
2018-01-29 01:00:34 +00:00
|
|
|
return 'UNLOCKED'
|
|
|
|
return 'JAMMED'
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
|
|
|
|
class _AlexaSceneController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.SceneController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-scenecontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def __init__(self, entity, supports_deactivation):
|
|
|
|
_AlexaInterface.__init__(self, entity)
|
|
|
|
self.supports_deactivation = lambda: supports_deactivation
|
|
|
|
|
|
|
|
def name(self):
|
|
|
|
return 'Alexa.SceneController'
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaBrightnessController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.BrightnessController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-brightnesscontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.BrightnessController'
|
|
|
|
|
2018-01-29 01:00:34 +00:00
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'brightness'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'brightness':
|
|
|
|
raise _UnsupportedProperty(name)
|
2018-02-12 06:36:22 +00:00
|
|
|
if 'brightness' in self.entity.attributes:
|
|
|
|
return round(self.entity.attributes['brightness'] / 255.0 * 100)
|
|
|
|
return 0
|
2018-01-29 01:00:34 +00:00
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
|
|
|
|
class _AlexaColorController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.ColorController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-colorcontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.ColorController'
|
|
|
|
|
2018-11-11 16:43:01 +00:00
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'color'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'color':
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
|
|
|
hue, saturation = self.entity.attributes.get(
|
|
|
|
light.ATTR_HS_COLOR, (0, 0))
|
|
|
|
|
|
|
|
return {
|
|
|
|
'hue': hue,
|
|
|
|
'saturation': saturation / 100.0,
|
|
|
|
'brightness': self.entity.attributes.get(
|
|
|
|
light.ATTR_BRIGHTNESS, 0) / 255.0,
|
|
|
|
}
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
|
|
|
|
class _AlexaColorTemperatureController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.ColorTemperatureController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-colortemperaturecontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.ColorTemperatureController'
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaPercentageController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.PercentageController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-percentagecontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.PercentageController'
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaSpeaker(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.Speaker.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-speaker.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.Speaker'
|
|
|
|
|
|
|
|
|
2018-02-06 00:02:08 +00:00
|
|
|
class _AlexaStepSpeaker(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.StepSpeaker.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-stepspeaker.html
|
|
|
|
"""
|
|
|
|
|
2018-02-06 00:02:08 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.StepSpeaker'
|
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
class _AlexaPlaybackController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.PlaybackController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-playbackcontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.PlaybackController'
|
|
|
|
|
|
|
|
|
2018-01-29 06:22:04 +00:00
|
|
|
class _AlexaInputController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.InputController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-inputcontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-01-29 06:22:04 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.InputController'
|
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
class _AlexaTemperatureSensor(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.TemperatureSensor.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-temperaturesensor.html
|
|
|
|
"""
|
|
|
|
|
2018-08-22 07:17:29 +00:00
|
|
|
def __init__(self, hass, entity):
|
|
|
|
_AlexaInterface.__init__(self, entity)
|
|
|
|
self.hass = hass
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.TemperatureSensor'
|
|
|
|
|
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'temperature'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'temperature':
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
2018-08-22 07:17:29 +00:00
|
|
|
unit = self.entity.attributes.get(ATTR_UNIT_OF_MEASUREMENT)
|
2018-03-30 06:49:08 +00:00
|
|
|
temp = self.entity.state
|
|
|
|
if self.entity.domain == climate.DOMAIN:
|
2018-08-22 07:17:29 +00:00
|
|
|
unit = self.hass.config.units.temperature_unit
|
2018-03-30 06:49:08 +00:00
|
|
|
temp = self.entity.attributes.get(
|
|
|
|
climate.ATTR_CURRENT_TEMPERATURE)
|
|
|
|
return {
|
|
|
|
'value': float(temp),
|
|
|
|
'scale': API_TEMP_UNITS[unit],
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-10-25 14:46:43 +00:00
|
|
|
class _AlexaContactSensor(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.ContactSensor.
|
|
|
|
|
|
|
|
The Alexa.ContactSensor interface describes the properties and events used
|
|
|
|
to report the state of an endpoint that detects contact between two
|
|
|
|
surfaces. For example, a contact sensor can report whether a door or window
|
|
|
|
is open.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-contactsensor.html
|
|
|
|
"""
|
|
|
|
|
2018-10-25 14:46:43 +00:00
|
|
|
def __init__(self, hass, entity):
|
|
|
|
_AlexaInterface.__init__(self, entity)
|
|
|
|
self.hass = hass
|
|
|
|
|
|
|
|
def name(self):
|
|
|
|
return 'Alexa.ContactSensor'
|
|
|
|
|
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'detectionState'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'detectionState':
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
|
|
|
if self.entity.state == STATE_ON:
|
|
|
|
return 'DETECTED'
|
|
|
|
return 'NOT_DETECTED'
|
|
|
|
|
|
|
|
|
2018-10-26 21:43:31 +00:00
|
|
|
class _AlexaMotionSensor(_AlexaInterface):
|
|
|
|
def __init__(self, hass, entity):
|
|
|
|
_AlexaInterface.__init__(self, entity)
|
|
|
|
self.hass = hass
|
|
|
|
|
|
|
|
def name(self):
|
|
|
|
return 'Alexa.MotionSensor'
|
|
|
|
|
|
|
|
def properties_supported(self):
|
|
|
|
return [{'name': 'detectionState'}]
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name != 'detectionState':
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
|
|
|
if self.entity.state == STATE_ON:
|
|
|
|
return 'DETECTED'
|
|
|
|
return 'NOT_DETECTED'
|
|
|
|
|
|
|
|
|
2018-03-30 06:49:08 +00:00
|
|
|
class _AlexaThermostatController(_AlexaInterface):
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
"""Implements Alexa.ThermostatController.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/device-apis/alexa-thermostatcontroller.html
|
|
|
|
"""
|
|
|
|
|
2018-08-22 07:17:29 +00:00
|
|
|
def __init__(self, hass, entity):
|
|
|
|
_AlexaInterface.__init__(self, entity)
|
|
|
|
self.hass = hass
|
|
|
|
|
2018-03-30 06:49:08 +00:00
|
|
|
def name(self):
|
|
|
|
return 'Alexa.ThermostatController'
|
|
|
|
|
|
|
|
def properties_supported(self):
|
|
|
|
properties = []
|
|
|
|
supported = self.entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
|
|
|
|
if supported & climate.SUPPORT_TARGET_TEMPERATURE:
|
|
|
|
properties.append({'name': 'targetSetpoint'})
|
|
|
|
if supported & climate.SUPPORT_TARGET_TEMPERATURE_LOW:
|
|
|
|
properties.append({'name': 'lowerSetpoint'})
|
|
|
|
if supported & climate.SUPPORT_TARGET_TEMPERATURE_HIGH:
|
|
|
|
properties.append({'name': 'upperSetpoint'})
|
|
|
|
if supported & climate.SUPPORT_OPERATION_MODE:
|
|
|
|
properties.append({'name': 'thermostatMode'})
|
|
|
|
return properties
|
|
|
|
|
|
|
|
def properties_retrievable(self):
|
|
|
|
return True
|
|
|
|
|
|
|
|
def get_property(self, name):
|
|
|
|
if name == 'thermostatMode':
|
|
|
|
ha_mode = self.entity.attributes.get(climate.ATTR_OPERATION_MODE)
|
|
|
|
mode = API_THERMOSTAT_MODES.get(ha_mode)
|
|
|
|
if mode is None:
|
|
|
|
_LOGGER.error("%s (%s) has unsupported %s value '%s'",
|
|
|
|
self.entity.entity_id, type(self.entity),
|
|
|
|
climate.ATTR_OPERATION_MODE, ha_mode)
|
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
return mode
|
|
|
|
|
2018-08-22 07:17:29 +00:00
|
|
|
unit = self.hass.config.units.temperature_unit
|
2018-03-30 06:49:08 +00:00
|
|
|
if name == 'targetSetpoint':
|
2018-07-09 09:44:50 +00:00
|
|
|
temp = self.entity.attributes.get(climate.ATTR_TEMPERATURE)
|
2018-03-30 06:49:08 +00:00
|
|
|
elif name == 'lowerSetpoint':
|
|
|
|
temp = self.entity.attributes.get(climate.ATTR_TARGET_TEMP_LOW)
|
|
|
|
elif name == 'upperSetpoint':
|
|
|
|
temp = self.entity.attributes.get(climate.ATTR_TARGET_TEMP_HIGH)
|
2018-07-09 09:44:50 +00:00
|
|
|
else:
|
2018-03-30 06:49:08 +00:00
|
|
|
raise _UnsupportedProperty(name)
|
|
|
|
|
2018-07-09 09:44:50 +00:00
|
|
|
if temp is None:
|
|
|
|
return None
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
return {
|
2018-03-30 06:49:08 +00:00
|
|
|
'value': float(temp),
|
2018-01-29 00:43:27 +00:00
|
|
|
'scale': API_TEMP_UNITS[unit],
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
@ENTITY_ADAPTERS.register(alert.DOMAIN)
|
|
|
|
@ENTITY_ADAPTERS.register(automation.DOMAIN)
|
2018-02-22 07:42:23 +00:00
|
|
|
@ENTITY_ADAPTERS.register(group.DOMAIN)
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(input_boolean.DOMAIN)
|
|
|
|
class _GenericCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
"""A generic, on/off device.
|
|
|
|
|
|
|
|
The choice of last resort.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.OTHER]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
return [_AlexaPowerController(self.entity)]
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(switch.DOMAIN)
|
|
|
|
class _SwitchCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.SWITCH]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
return [_AlexaPowerController(self.entity)]
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-03-30 06:49:08 +00:00
|
|
|
@ENTITY_ADAPTERS.register(climate.DOMAIN)
|
|
|
|
class _ClimateCapabilities(_AlexaEntity):
|
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.THERMOSTAT]
|
|
|
|
|
|
|
|
def interfaces(self):
|
2018-11-06 13:17:56 +00:00
|
|
|
supported = self.entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
|
|
|
|
if supported & climate.SUPPORT_ON_OFF:
|
|
|
|
yield _AlexaPowerController(self.entity)
|
2018-08-22 07:17:29 +00:00
|
|
|
yield _AlexaThermostatController(self.hass, self.entity)
|
|
|
|
yield _AlexaTemperatureSensor(self.hass, self.entity)
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(cover.DOMAIN)
|
|
|
|
class _CoverCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.DOOR]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
yield _AlexaPowerController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
supported = self.entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
|
|
|
|
if supported & cover.SUPPORT_SET_POSITION:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaPercentageController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(light.DOMAIN)
|
|
|
|
class _LightCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.LIGHT]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
yield _AlexaPowerController(self.entity)
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
supported = self.entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
|
|
|
|
if supported & light.SUPPORT_BRIGHTNESS:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaBrightnessController(self.entity)
|
2018-03-18 22:00:29 +00:00
|
|
|
if supported & light.SUPPORT_COLOR:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaColorController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
if supported & light.SUPPORT_COLOR_TEMP:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaColorTemperatureController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(fan.DOMAIN)
|
|
|
|
class _FanCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.OTHER]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
yield _AlexaPowerController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
supported = self.entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
|
|
|
|
if supported & fan.SUPPORT_SET_SPEED:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaPercentageController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(lock.DOMAIN)
|
|
|
|
class _LockCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.SMARTLOCK]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
return [_AlexaLockController(self.entity)]
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(media_player.DOMAIN)
|
|
|
|
class _MediaPlayerCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.TV]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
yield _AlexaPowerController(self.entity)
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
supported = self.entity.attributes.get(ATTR_SUPPORTED_FEATURES, 0)
|
|
|
|
if supported & media_player.SUPPORT_VOLUME_SET:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaSpeaker(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-02-06 00:02:08 +00:00
|
|
|
step_volume_features = (media_player.SUPPORT_VOLUME_MUTE |
|
|
|
|
media_player.SUPPORT_VOLUME_STEP)
|
|
|
|
if supported & step_volume_features:
|
|
|
|
yield _AlexaStepSpeaker(self.entity)
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
playback_features = (media_player.SUPPORT_PLAY |
|
|
|
|
media_player.SUPPORT_PAUSE |
|
|
|
|
media_player.SUPPORT_STOP |
|
|
|
|
media_player.SUPPORT_NEXT_TRACK |
|
|
|
|
media_player.SUPPORT_PREVIOUS_TRACK)
|
|
|
|
if supported & playback_features:
|
2018-01-29 00:43:27 +00:00
|
|
|
yield _AlexaPlaybackController(self.entity)
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-01-29 06:22:04 +00:00
|
|
|
if supported & media_player.SUPPORT_SELECT_SOURCE:
|
|
|
|
yield _AlexaInputController(self.entity)
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(scene.DOMAIN)
|
|
|
|
class _SceneCapabilities(_AlexaEntity):
|
|
|
|
def description(self):
|
|
|
|
# Required description as per Amazon Scene docs
|
|
|
|
scene_fmt = '{} (Scene connected via Home Assistant)'
|
|
|
|
return scene_fmt.format(_AlexaEntity.description(self))
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.SCENE_TRIGGER]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
|
|
|
return [_AlexaSceneController(self.entity,
|
|
|
|
supports_deactivation=False)]
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(script.DOMAIN)
|
|
|
|
class _ScriptCapabilities(_AlexaEntity):
|
2018-01-26 05:06:57 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
return [_DisplayCategory.ACTIVITY_TRIGGER]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
2018-01-26 05:06:57 +00:00
|
|
|
can_cancel = bool(self.entity.attributes.get('can_cancel'))
|
2018-01-29 00:43:27 +00:00
|
|
|
return [_AlexaSceneController(self.entity,
|
|
|
|
supports_deactivation=can_cancel)]
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
@ENTITY_ADAPTERS.register(sensor.DOMAIN)
|
|
|
|
class _SensorCapabilities(_AlexaEntity):
|
2018-01-26 18:40:39 +00:00
|
|
|
def default_display_categories(self):
|
|
|
|
# although there are other kinds of sensors, all but temperature
|
|
|
|
# sensors are currently ignored.
|
|
|
|
return [_DisplayCategory.TEMPERATURE_SENSOR]
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
def interfaces(self):
|
2018-01-26 18:40:39 +00:00
|
|
|
attrs = self.entity.attributes
|
2018-08-22 07:17:29 +00:00
|
|
|
if attrs.get(ATTR_UNIT_OF_MEASUREMENT) in (
|
2018-01-26 18:40:39 +00:00
|
|
|
TEMP_FAHRENHEIT,
|
|
|
|
TEMP_CELSIUS,
|
|
|
|
):
|
2018-08-22 07:17:29 +00:00
|
|
|
yield _AlexaTemperatureSensor(self.hass, self.entity)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
|
2018-10-25 14:46:43 +00:00
|
|
|
@ENTITY_ADAPTERS.register(binary_sensor.DOMAIN)
|
|
|
|
class _BinarySensorCapabilities(_AlexaEntity):
|
|
|
|
TYPE_CONTACT = 'contact'
|
2018-10-26 21:43:31 +00:00
|
|
|
TYPE_MOTION = 'motion'
|
2018-10-25 14:46:43 +00:00
|
|
|
|
|
|
|
def default_display_categories(self):
|
|
|
|
sensor_type = self.get_type()
|
|
|
|
if sensor_type is self.TYPE_CONTACT:
|
|
|
|
return [_DisplayCategory.CONTACT_SENSOR]
|
2018-10-26 21:43:31 +00:00
|
|
|
if sensor_type is self.TYPE_MOTION:
|
|
|
|
return [_DisplayCategory.MOTION_SENSOR]
|
2018-10-25 14:46:43 +00:00
|
|
|
|
|
|
|
def interfaces(self):
|
|
|
|
sensor_type = self.get_type()
|
|
|
|
if sensor_type is self.TYPE_CONTACT:
|
|
|
|
yield _AlexaContactSensor(self.hass, self.entity)
|
2018-10-26 21:43:31 +00:00
|
|
|
elif sensor_type is self.TYPE_MOTION:
|
|
|
|
yield _AlexaMotionSensor(self.hass, self.entity)
|
2018-10-25 14:46:43 +00:00
|
|
|
|
|
|
|
def get_type(self):
|
|
|
|
"""Return the type of binary sensor."""
|
|
|
|
attrs = self.entity.attributes
|
|
|
|
if attrs.get(ATTR_DEVICE_CLASS) in (
|
|
|
|
'door',
|
|
|
|
'garage_door',
|
|
|
|
'opening',
|
|
|
|
'window',
|
|
|
|
):
|
|
|
|
return self.TYPE_CONTACT
|
2018-10-26 21:43:31 +00:00
|
|
|
if attrs.get(ATTR_DEVICE_CLASS) == 'motion':
|
|
|
|
return self.TYPE_MOTION
|
2018-10-25 14:46:43 +00:00
|
|
|
|
|
|
|
|
2018-07-20 08:45:20 +00:00
|
|
|
class _Cause:
|
2018-01-23 08:01:18 +00:00
|
|
|
"""Possible causes for property changes.
|
|
|
|
|
|
|
|
https://developer.amazon.com/docs/smarthome/state-reporting-for-a-smart-home-skill.html#cause-object
|
|
|
|
"""
|
|
|
|
|
|
|
|
# Indicates that the event was caused by a customer interaction with an
|
|
|
|
# application. For example, a customer switches on a light, or locks a door
|
|
|
|
# using the Alexa app or an app provided by a device vendor.
|
|
|
|
APP_INTERACTION = 'APP_INTERACTION'
|
|
|
|
|
|
|
|
# Indicates that the event was caused by a physical interaction with an
|
|
|
|
# endpoint. For example manually switching on a light or manually locking a
|
|
|
|
# door lock
|
|
|
|
PHYSICAL_INTERACTION = 'PHYSICAL_INTERACTION'
|
|
|
|
|
|
|
|
# Indicates that the event was caused by the periodic poll of an appliance,
|
|
|
|
# which found a change in value. For example, you might poll a temperature
|
|
|
|
# sensor every hour, and send the updated temperature to Alexa.
|
|
|
|
PERIODIC_POLL = 'PERIODIC_POLL'
|
|
|
|
|
|
|
|
# Indicates that the event was caused by the application of a device rule.
|
|
|
|
# For example, a customer configures a rule to switch on a light if a
|
|
|
|
# motion sensor detects motion. In this case, Alexa receives an event from
|
|
|
|
# the motion sensor, and another event from the light to indicate that its
|
|
|
|
# state change was caused by the rule.
|
|
|
|
RULE_TRIGGER = 'RULE_TRIGGER'
|
|
|
|
|
|
|
|
# Indicates that the event was caused by a voice interaction with Alexa.
|
|
|
|
# For example a user speaking to their Echo device.
|
|
|
|
VOICE_INTERACTION = 'VOICE_INTERACTION'
|
|
|
|
|
|
|
|
|
2018-01-05 20:33:22 +00:00
|
|
|
class Config:
|
|
|
|
"""Hold the configuration for Alexa."""
|
|
|
|
|
|
|
|
def __init__(self, should_expose, entity_config=None):
|
|
|
|
"""Initialize the configuration."""
|
|
|
|
self.should_expose = should_expose
|
|
|
|
self.entity_config = entity_config or {}
|
2017-11-18 05:10:24 +00:00
|
|
|
|
|
|
|
|
2018-01-23 18:45:28 +00:00
|
|
|
@ha.callback
|
|
|
|
def async_setup(hass, config):
|
|
|
|
"""Activate Smart Home functionality of Alexa component.
|
|
|
|
|
|
|
|
This is optional, triggered by having a `smart_home:` sub-section in the
|
|
|
|
alexa configuration.
|
|
|
|
|
|
|
|
Even if that's disabled, the functionality in this module may still be used
|
|
|
|
by the cloud component which will call async_handle_message directly.
|
|
|
|
"""
|
|
|
|
smart_home_config = Config(
|
|
|
|
should_expose=config[CONF_FILTER],
|
|
|
|
entity_config=config.get(CONF_ENTITY_CONFIG),
|
|
|
|
)
|
|
|
|
hass.http.register_view(SmartHomeView(smart_home_config))
|
|
|
|
|
|
|
|
|
|
|
|
class SmartHomeView(http.HomeAssistantView):
|
|
|
|
"""Expose Smart Home v3 payload interface via HTTP POST."""
|
|
|
|
|
|
|
|
url = SMART_HOME_HTTP_ENDPOINT
|
|
|
|
name = 'api:alexa:smart_home'
|
|
|
|
|
|
|
|
def __init__(self, smart_home_config):
|
|
|
|
"""Initialize."""
|
|
|
|
self.smart_home_config = smart_home_config
|
|
|
|
|
2018-10-01 06:52:42 +00:00
|
|
|
async def post(self, request):
|
2018-01-23 18:45:28 +00:00
|
|
|
"""Handle Alexa Smart Home requests.
|
|
|
|
|
|
|
|
The Smart Home API requires the endpoint to be implemented in AWS
|
|
|
|
Lambda, which will need to forward the requests to here and pass back
|
|
|
|
the response.
|
|
|
|
"""
|
|
|
|
hass = request.app['hass']
|
2018-10-01 06:52:42 +00:00
|
|
|
message = await request.json()
|
2018-01-23 18:45:28 +00:00
|
|
|
|
|
|
|
_LOGGER.debug("Received Alexa Smart Home request: %s", message)
|
|
|
|
|
2018-10-01 06:52:42 +00:00
|
|
|
response = await async_handle_message(
|
2018-01-23 18:45:28 +00:00
|
|
|
hass, self.smart_home_config, message)
|
2018-01-26 05:06:57 +00:00
|
|
|
_LOGGER.debug("Sending Alexa Smart Home response: %s", response)
|
2018-01-23 18:45:28 +00:00
|
|
|
return b'' if response is None else self.json(response)
|
|
|
|
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
class _AlexaDirective:
|
|
|
|
def __init__(self, request):
|
|
|
|
self._directive = request[API_DIRECTIVE]
|
|
|
|
self.namespace = self._directive[API_HEADER]['namespace']
|
|
|
|
self.name = self._directive[API_HEADER]['name']
|
|
|
|
self.payload = self._directive[API_PAYLOAD]
|
|
|
|
self.has_endpoint = API_ENDPOINT in self._directive
|
2018-08-20 12:18:07 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
self.entity = self.entity_id = self.endpoint = None
|
2017-10-07 20:31:57 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
def load_entity(self, hass, config):
|
|
|
|
"""Set attributes related to the entity for this request.
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
Sets these attributes when self.has_endpoint is True:
|
2018-08-20 12:18:07 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
- entity
|
|
|
|
- entity_id
|
|
|
|
- endpoint
|
2018-08-20 12:18:07 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
Behavior when self.has_endpoint is False is undefined.
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
Will raise _AlexaInvalidEndpointError if the endpoint in the request is
|
|
|
|
malformed or nonexistant.
|
|
|
|
"""
|
|
|
|
_endpoint_id = self._directive[API_ENDPOINT]['endpointId']
|
|
|
|
self.entity_id = _endpoint_id.replace('#', '.')
|
2018-08-20 12:18:07 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
self.entity = hass.states.get(self.entity_id)
|
|
|
|
if not self.entity:
|
|
|
|
raise _AlexaInvalidEndpointError(_endpoint_id)
|
2018-08-20 12:18:07 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
self.endpoint = ENTITY_ADAPTERS[self.entity.domain](
|
|
|
|
hass, config, self.entity)
|
|
|
|
|
|
|
|
def response(self,
|
|
|
|
name='Response',
|
|
|
|
namespace='Alexa',
|
|
|
|
payload=None):
|
|
|
|
"""Create an API formatted response.
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
Async friendly.
|
|
|
|
"""
|
|
|
|
response = _AlexaResponse(name, namespace, payload)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
token = self._directive[API_HEADER].get('correlationToken')
|
|
|
|
if token:
|
|
|
|
response.set_correlation_token(token)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
if self.has_endpoint:
|
|
|
|
response.set_endpoint(self._directive[API_ENDPOINT].copy())
|
|
|
|
|
|
|
|
return response
|
|
|
|
|
|
|
|
def error(
|
|
|
|
self,
|
|
|
|
namespace='Alexa',
|
|
|
|
error_type='INTERNAL_ERROR',
|
|
|
|
error_message="",
|
|
|
|
payload=None
|
|
|
|
):
|
|
|
|
"""Create a API formatted error response.
|
|
|
|
|
|
|
|
Async friendly.
|
|
|
|
"""
|
|
|
|
payload = payload or {}
|
|
|
|
payload['type'] = error_type
|
|
|
|
payload['message'] = error_message
|
|
|
|
|
|
|
|
_LOGGER.info("Request %s/%s error %s: %s",
|
|
|
|
self._directive[API_HEADER]['namespace'],
|
|
|
|
self._directive[API_HEADER]['name'],
|
|
|
|
error_type, error_message)
|
|
|
|
|
|
|
|
return self.response(
|
|
|
|
name='ErrorResponse',
|
|
|
|
namespace=namespace,
|
|
|
|
payload=payload
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
|
|
class _AlexaResponse:
|
|
|
|
def __init__(self, name, namespace, payload=None):
|
|
|
|
payload = payload or {}
|
|
|
|
self._response = {
|
|
|
|
API_EVENT: {
|
|
|
|
API_HEADER: {
|
|
|
|
'namespace': namespace,
|
|
|
|
'name': name,
|
|
|
|
'messageId': str(uuid4()),
|
|
|
|
'payloadVersion': '3',
|
|
|
|
},
|
|
|
|
API_PAYLOAD: payload,
|
|
|
|
}
|
2017-10-07 20:31:57 +00:00
|
|
|
}
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
@property
|
|
|
|
def name(self):
|
|
|
|
"""Return the name of this response."""
|
|
|
|
return self._response[API_EVENT][API_HEADER]['name']
|
2017-10-07 20:31:57 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
@property
|
|
|
|
def namespace(self):
|
|
|
|
"""Return the namespace of this response."""
|
|
|
|
return self._response[API_EVENT][API_HEADER]['namespace']
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
def set_correlation_token(self, token):
|
|
|
|
"""Set the correlationToken.
|
2018-01-26 18:40:39 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
This should normally mirror the value from a request, and is set by
|
|
|
|
_AlexaDirective.response() usually.
|
|
|
|
"""
|
|
|
|
self._response[API_EVENT][API_HEADER]['correlationToken'] = token
|
2017-10-07 20:31:57 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
def set_endpoint(self, endpoint):
|
|
|
|
"""Set the endpoint.
|
2017-10-07 20:31:57 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
This should normally mirror the value from a request, and is set by
|
|
|
|
_AlexaDirective.response() usually.
|
|
|
|
"""
|
|
|
|
self._response[API_EVENT][API_ENDPOINT] = endpoint
|
|
|
|
|
|
|
|
def _properties(self):
|
|
|
|
context = self._response.setdefault(API_CONTEXT, {})
|
|
|
|
return context.setdefault('properties', [])
|
|
|
|
|
|
|
|
def add_context_property(self, prop):
|
|
|
|
"""Add a property to the response context.
|
|
|
|
|
|
|
|
The Alexa response includes a list of properties which provides
|
|
|
|
feedback on how states have changed. For example if a user asks,
|
|
|
|
"Alexa, set theromstat to 20 degrees", the API expects a response with
|
|
|
|
the new value of the property, and Alexa will respond to the user
|
|
|
|
"Thermostat set to 20 degrees".
|
|
|
|
|
|
|
|
async_handle_message() will call .merge_context_properties() for every
|
|
|
|
request automatically, however often handlers will call services to
|
|
|
|
change state but the effects of those changes are applied
|
|
|
|
asynchronously. Thus, handlers should call this method to confirm
|
|
|
|
changes before returning.
|
|
|
|
"""
|
|
|
|
self._properties().append(prop)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
def merge_context_properties(self, endpoint):
|
|
|
|
"""Add all properties from given endpoint if not already set.
|
|
|
|
|
|
|
|
Handlers should be using .add_context_property().
|
|
|
|
"""
|
|
|
|
properties = self._properties()
|
|
|
|
already_set = {(p['namespace'], p['name']) for p in properties}
|
|
|
|
|
|
|
|
for prop in endpoint.serialize_properties():
|
|
|
|
if (prop['namespace'], prop['name']) not in already_set:
|
|
|
|
self.add_context_property(prop)
|
|
|
|
|
|
|
|
def serialize(self):
|
|
|
|
"""Return response as a JSON-able data structure."""
|
|
|
|
return self._response
|
|
|
|
|
|
|
|
|
|
|
|
async def async_handle_message(
|
|
|
|
hass,
|
|
|
|
config,
|
|
|
|
request,
|
|
|
|
context=None,
|
|
|
|
enabled=True,
|
|
|
|
):
|
|
|
|
"""Handle incoming API messages.
|
|
|
|
|
|
|
|
If enabled is False, the response to all messagess will be a
|
|
|
|
BRIDGE_UNREACHABLE error. This can be used if the API has been disabled in
|
|
|
|
configuration.
|
2017-09-16 19:35:28 +00:00
|
|
|
"""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
assert request[API_DIRECTIVE][API_HEADER]['payloadVersion'] == '3'
|
|
|
|
|
|
|
|
if context is None:
|
|
|
|
context = ha.Context()
|
|
|
|
|
|
|
|
directive = _AlexaDirective(request)
|
|
|
|
|
|
|
|
try:
|
|
|
|
if not enabled:
|
|
|
|
raise _AlexaBridgeUnreachableError(
|
|
|
|
'Alexa API not enabled in Home Assistant configuration')
|
|
|
|
|
|
|
|
if directive.has_endpoint:
|
|
|
|
directive.load_entity(hass, config)
|
|
|
|
|
|
|
|
funct_ref = HANDLERS.get((directive.namespace, directive.name))
|
|
|
|
if funct_ref:
|
|
|
|
response = await funct_ref(hass, config, directive, context)
|
|
|
|
if directive.has_endpoint:
|
|
|
|
response.merge_context_properties(directive.endpoint)
|
|
|
|
else:
|
|
|
|
_LOGGER.warning(
|
|
|
|
"Unsupported API request %s/%s",
|
|
|
|
directive.namespace,
|
|
|
|
directive.name,
|
|
|
|
)
|
|
|
|
response = directive.error()
|
|
|
|
except _AlexaError as err:
|
|
|
|
response = directive.error(
|
|
|
|
error_type=err.error_type,
|
|
|
|
error_message=err.error_message)
|
2018-03-30 06:49:08 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
request_info = {
|
|
|
|
'namespace': directive.namespace,
|
|
|
|
'name': directive.name,
|
|
|
|
}
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
if directive.has_endpoint:
|
|
|
|
request_info['entity_id'] = directive.entity_id
|
|
|
|
|
|
|
|
hass.bus.async_fire(EVENT_ALEXA_SMART_HOME, {
|
|
|
|
'request': request_info,
|
|
|
|
'response': {
|
|
|
|
'namespace': response.namespace,
|
|
|
|
'name': response.name,
|
|
|
|
}
|
|
|
|
}, context=context)
|
|
|
|
|
|
|
|
return response.serialize()
|
2017-09-16 19:35:28 +00:00
|
|
|
|
2017-10-07 20:31:57 +00:00
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.Discovery', 'Discover'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_discovery(hass, config, directive, context):
|
2017-09-23 15:15:46 +00:00
|
|
|
"""Create a API formatted discovery response.
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
Async friendly.
|
|
|
|
"""
|
2017-10-07 20:31:57 +00:00
|
|
|
discovery_endpoints = []
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
for entity in hass.states.async_all():
|
Add support for locks in google assistant component (#18233)
* 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.
2018-11-06 09:39:10 +00:00
|
|
|
if entity.entity_id in CLOUD_NEVER_EXPOSED_ENTITIES:
|
|
|
|
_LOGGER.debug("Not exposing %s because it is never exposed",
|
|
|
|
entity.entity_id)
|
|
|
|
continue
|
|
|
|
|
2018-01-05 20:33:22 +00:00
|
|
|
if not config.should_expose(entity.entity_id):
|
2017-11-18 05:10:24 +00:00
|
|
|
_LOGGER.debug("Not exposing %s because filtered by config",
|
|
|
|
entity.entity_id)
|
|
|
|
continue
|
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
if entity.domain not in ENTITY_ADAPTERS:
|
2017-09-16 19:35:28 +00:00
|
|
|
continue
|
2018-08-22 07:17:29 +00:00
|
|
|
alexa_entity = ENTITY_ADAPTERS[entity.domain](hass, config, entity)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
2017-10-07 20:31:57 +00:00
|
|
|
endpoint = {
|
2018-01-29 00:43:27 +00:00
|
|
|
'displayCategories': alexa_entity.display_categories(),
|
2017-09-16 19:35:28 +00:00
|
|
|
'additionalApplianceDetails': {},
|
2018-01-29 00:43:27 +00:00
|
|
|
'endpointId': alexa_entity.entity_id(),
|
|
|
|
'friendlyName': alexa_entity.friendly_name(),
|
|
|
|
'description': alexa_entity.description(),
|
2017-11-17 17:14:22 +00:00
|
|
|
'manufacturerName': 'Home Assistant',
|
2017-09-16 19:35:28 +00:00
|
|
|
}
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-01-29 00:43:27 +00:00
|
|
|
endpoint['capabilities'] = [
|
|
|
|
i.serialize_discovery() for i in alexa_entity.interfaces()]
|
|
|
|
|
|
|
|
if not endpoint['capabilities']:
|
2018-01-26 18:40:39 +00:00
|
|
|
_LOGGER.debug("Not exposing %s because it has no capabilities",
|
|
|
|
entity.entity_id)
|
|
|
|
continue
|
2017-10-07 20:31:57 +00:00
|
|
|
discovery_endpoints.append(endpoint)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response(
|
|
|
|
name='Discover.Response',
|
|
|
|
namespace='Alexa.Discovery',
|
|
|
|
payload={'endpoints': discovery_endpoints},
|
|
|
|
)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
|
2017-10-07 20:31:57 +00:00
|
|
|
@HANDLERS.register(('Alexa.PowerController', 'TurnOn'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_turn_on(hass, config, directive, context):
|
2017-09-16 19:35:28 +00:00
|
|
|
"""Process a turn on request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-18 05:10:24 +00:00
|
|
|
domain = entity.domain
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
if domain == group.DOMAIN:
|
2018-02-22 07:42:23 +00:00
|
|
|
domain = ha.DOMAIN
|
2017-11-18 05:10:24 +00:00
|
|
|
|
2017-12-24 23:05:56 +00:00
|
|
|
service = SERVICE_TURN_ON
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
if domain == cover.DOMAIN:
|
2017-12-24 23:05:56 +00:00
|
|
|
service = cover.SERVICE_OPEN_COVER
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(domain, service, {
|
2017-09-16 19:35:28 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
|
2017-10-07 20:31:57 +00:00
|
|
|
@HANDLERS.register(('Alexa.PowerController', 'TurnOff'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_turn_off(hass, config, directive, context):
|
2017-09-16 19:35:28 +00:00
|
|
|
"""Process a turn off request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-18 05:10:24 +00:00
|
|
|
domain = entity.domain
|
|
|
|
if entity.domain == group.DOMAIN:
|
|
|
|
domain = ha.DOMAIN
|
|
|
|
|
2017-12-24 23:05:56 +00:00
|
|
|
service = SERVICE_TURN_OFF
|
|
|
|
if entity.domain == cover.DOMAIN:
|
|
|
|
service = cover.SERVICE_CLOSE_COVER
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(domain, service, {
|
2017-09-16 19:35:28 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-09-16 19:35:28 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-09-16 19:35:28 +00:00
|
|
|
|
|
|
|
|
2017-10-07 20:31:57 +00:00
|
|
|
@HANDLERS.register(('Alexa.BrightnessController', 'SetBrightness'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_brightness(hass, config, directive, context):
|
2017-10-07 20:31:57 +00:00
|
|
|
"""Process a set brightness request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
|
|
|
brightness = int(directive.payload['brightness'])
|
2017-09-16 19:35:28 +00:00
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_TURN_ON, {
|
2017-10-07 20:31:57 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
2017-11-01 03:28:17 +00:00
|
|
|
light.ATTR_BRIGHTNESS_PCT: brightness,
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-01 03:28:17 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.BrightnessController', 'AdjustBrightness'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_adjust_brightness(hass, config, directive, context):
|
2018-01-27 19:58:27 +00:00
|
|
|
"""Process an adjust brightness request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
|
|
|
brightness_delta = int(directive.payload['brightnessDelta'])
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
# read current state
|
|
|
|
try:
|
|
|
|
current = math.floor(
|
|
|
|
int(entity.attributes.get(light.ATTR_BRIGHTNESS)) / 255 * 100)
|
|
|
|
except ZeroDivisionError:
|
2017-11-01 11:16:05 +00:00
|
|
|
current = 0
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
# set brightness
|
2017-11-01 11:16:05 +00:00
|
|
|
brightness = max(0, brightness_delta + current)
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_TURN_ON, {
|
2017-11-01 03:28:17 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
light.ATTR_BRIGHTNESS_PCT: brightness,
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-01 03:28:17 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.ColorController', 'SetColor'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_color(hass, config, directive, context):
|
2017-11-01 03:28:17 +00:00
|
|
|
"""Process a set color request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-01 11:16:05 +00:00
|
|
|
rgb = color_util.color_hsb_to_RGB(
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
float(directive.payload['color']['hue']),
|
|
|
|
float(directive.payload['color']['saturation']),
|
|
|
|
float(directive.payload['color']['brightness'])
|
2017-11-01 11:16:05 +00:00
|
|
|
)
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_TURN_ON, {
|
2018-03-18 22:00:29 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
light.ATTR_RGB_COLOR: rgb,
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-01 03:28:17 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.ColorTemperatureController', 'SetColorTemperature'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_color_temperature(hass, config, directive, context):
|
2017-11-01 03:28:17 +00:00
|
|
|
"""Process a set color temperature request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
|
|
|
kelvin = int(directive.payload['colorTemperatureInKelvin'])
|
2017-11-01 03:28:17 +00:00
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_TURN_ON, {
|
2017-11-01 03:28:17 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
light.ATTR_KELVIN: kelvin,
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-01 03:28:17 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(
|
|
|
|
('Alexa.ColorTemperatureController', 'DecreaseColorTemperature'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_decrease_color_temp(hass, config, directive, context):
|
2017-11-01 03:28:17 +00:00
|
|
|
"""Process a decrease color temperature request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-01 03:28:17 +00:00
|
|
|
current = int(entity.attributes.get(light.ATTR_COLOR_TEMP))
|
|
|
|
max_mireds = int(entity.attributes.get(light.ATTR_MAX_MIREDS))
|
|
|
|
|
|
|
|
value = min(max_mireds, current + 50)
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_TURN_ON, {
|
2017-11-01 03:28:17 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
light.ATTR_COLOR_TEMP: value,
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-01 03:28:17 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-01 03:28:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(
|
|
|
|
('Alexa.ColorTemperatureController', 'IncreaseColorTemperature'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_increase_color_temp(hass, config, directive, context):
|
2018-01-26 05:06:57 +00:00
|
|
|
"""Process an increase color temperature request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-01 03:28:17 +00:00
|
|
|
current = int(entity.attributes.get(light.ATTR_COLOR_TEMP))
|
|
|
|
min_mireds = int(entity.attributes.get(light.ATTR_MIN_MIREDS))
|
|
|
|
|
|
|
|
value = max(min_mireds, current - 50)
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_TURN_ON, {
|
2017-11-01 03:28:17 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
light.ATTR_COLOR_TEMP: value,
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-10-07 20:31:57 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.SceneController', 'Activate'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_activate(hass, config, directive, context):
|
2018-01-26 05:06:57 +00:00
|
|
|
"""Process an activate request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2018-02-22 07:42:23 +00:00
|
|
|
domain = entity.domain
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(domain, SERVICE_TURN_ON, {
|
2017-11-17 17:14:22 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
2018-01-23 08:01:18 +00:00
|
|
|
payload = {
|
|
|
|
'cause': {'type': _Cause.VOICE_INTERACTION},
|
|
|
|
'timestamp': '%sZ' % (datetime.utcnow().isoformat(),)
|
|
|
|
}
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response(
|
2018-01-23 08:01:18 +00:00
|
|
|
name='ActivationStarted',
|
|
|
|
namespace='Alexa.SceneController',
|
|
|
|
payload=payload,
|
|
|
|
)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
2018-01-26 05:06:57 +00:00
|
|
|
@HANDLERS.register(('Alexa.SceneController', 'Deactivate'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_deactivate(hass, config, directive, context):
|
2018-01-26 05:06:57 +00:00
|
|
|
"""Process a deactivate request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2018-02-22 07:42:23 +00:00
|
|
|
domain = entity.domain
|
2018-01-26 05:06:57 +00:00
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(domain, SERVICE_TURN_OFF, {
|
2018-01-26 05:06:57 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2018-01-26 05:06:57 +00:00
|
|
|
|
|
|
|
payload = {
|
|
|
|
'cause': {'type': _Cause.VOICE_INTERACTION},
|
|
|
|
'timestamp': '%sZ' % (datetime.utcnow().isoformat(),)
|
|
|
|
}
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response(
|
2018-01-26 05:06:57 +00:00
|
|
|
name='DeactivationStarted',
|
|
|
|
namespace='Alexa.SceneController',
|
|
|
|
payload=payload,
|
|
|
|
)
|
|
|
|
|
|
|
|
|
2017-11-17 17:14:22 +00:00
|
|
|
@HANDLERS.register(('Alexa.PercentageController', 'SetPercentage'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_percentage(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a set percentage request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
|
|
|
percentage = int(directive.payload['percentage'])
|
2017-11-17 17:14:22 +00:00
|
|
|
service = None
|
|
|
|
data = {ATTR_ENTITY_ID: entity.entity_id}
|
|
|
|
|
|
|
|
if entity.domain == fan.DOMAIN:
|
|
|
|
service = fan.SERVICE_SET_SPEED
|
|
|
|
speed = "off"
|
|
|
|
|
|
|
|
if percentage <= 33:
|
|
|
|
speed = "low"
|
|
|
|
elif percentage <= 66:
|
|
|
|
speed = "medium"
|
|
|
|
elif percentage <= 100:
|
|
|
|
speed = "high"
|
|
|
|
data[fan.ATTR_SPEED] = speed
|
|
|
|
|
|
|
|
elif entity.domain == cover.DOMAIN:
|
|
|
|
service = SERVICE_SET_COVER_POSITION
|
|
|
|
data[cover.ATTR_POSITION] = percentage
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
|
|
|
entity.domain, service, data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.PercentageController', 'AdjustPercentage'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_adjust_percentage(hass, config, directive, context):
|
2018-01-27 19:58:27 +00:00
|
|
|
"""Process an adjust percentage request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
|
|
|
percentage_delta = int(directive.payload['percentageDelta'])
|
2017-11-17 17:14:22 +00:00
|
|
|
service = None
|
|
|
|
data = {ATTR_ENTITY_ID: entity.entity_id}
|
|
|
|
|
|
|
|
if entity.domain == fan.DOMAIN:
|
|
|
|
service = fan.SERVICE_SET_SPEED
|
|
|
|
speed = entity.attributes.get(fan.ATTR_SPEED)
|
|
|
|
|
|
|
|
if speed == "off":
|
|
|
|
current = 0
|
|
|
|
elif speed == "low":
|
|
|
|
current = 33
|
|
|
|
elif speed == "medium":
|
|
|
|
current = 66
|
|
|
|
elif speed == "high":
|
|
|
|
current = 100
|
|
|
|
|
|
|
|
# set percentage
|
|
|
|
percentage = max(0, percentage_delta + current)
|
|
|
|
speed = "off"
|
|
|
|
|
|
|
|
if percentage <= 33:
|
|
|
|
speed = "low"
|
|
|
|
elif percentage <= 66:
|
|
|
|
speed = "medium"
|
|
|
|
elif percentage <= 100:
|
|
|
|
speed = "high"
|
|
|
|
|
|
|
|
data[fan.ATTR_SPEED] = speed
|
|
|
|
|
|
|
|
elif entity.domain == cover.DOMAIN:
|
|
|
|
service = SERVICE_SET_COVER_POSITION
|
|
|
|
|
|
|
|
current = entity.attributes.get(cover.ATTR_POSITION)
|
|
|
|
|
|
|
|
data[cover.ATTR_POSITION] = max(0, percentage_delta + current)
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
|
|
|
entity.domain, service, data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.LockController', 'Lock'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_lock(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a lock request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_LOCK, {
|
2017-11-17 17:14:22 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
response = directive.response()
|
|
|
|
response.add_context_property({
|
2018-02-12 07:20:54 +00:00
|
|
|
'name': 'lockState',
|
|
|
|
'namespace': 'Alexa.LockController',
|
|
|
|
'value': 'LOCKED'
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
})
|
|
|
|
return response
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
# Not supported by Alexa yet
|
|
|
|
@HANDLERS.register(('Alexa.LockController', 'Unlock'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_unlock(hass, config, directive, context):
|
2018-01-27 19:58:27 +00:00
|
|
|
"""Process an unlock request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(entity.domain, SERVICE_UNLOCK, {
|
2017-11-17 17:14:22 +00:00
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
2018-08-20 12:18:07 +00:00
|
|
|
}, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.Speaker', 'SetVolume'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_volume(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a set volume request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
volume = round(float(directive.payload['volume'] / 100), 2)
|
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
media_player.ATTR_MEDIA_VOLUME_LEVEL: volume,
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, SERVICE_VOLUME_SET,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
2018-01-29 06:22:04 +00:00
|
|
|
@HANDLERS.register(('Alexa.InputController', 'SelectInput'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_select_input(hass, config, directive, context):
|
2018-01-29 06:22:04 +00:00
|
|
|
"""Process a set input request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
media_input = directive.payload['input']
|
|
|
|
entity = directive.entity
|
2018-01-29 06:22:04 +00:00
|
|
|
|
|
|
|
# attempt to map the ALL UPPERCASE payload name to a source
|
|
|
|
source_list = entity.attributes[media_player.ATTR_INPUT_SOURCE_LIST] or []
|
|
|
|
for source in source_list:
|
|
|
|
# response will always be space separated, so format the source in the
|
|
|
|
# most likely way to find a match
|
|
|
|
formatted_source = source.lower().replace('-', ' ').replace('_', ' ')
|
|
|
|
if formatted_source in media_input.lower():
|
|
|
|
media_input = source
|
|
|
|
break
|
|
|
|
else:
|
|
|
|
msg = 'failed to map input {} to a media source on {}'.format(
|
|
|
|
media_input, entity.entity_id)
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
raise _AlexaInvalidValueError(msg)
|
2018-01-29 06:22:04 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
media_player.ATTR_INPUT_SOURCE: media_input,
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2018-01-29 06:22:04 +00:00
|
|
|
entity.domain, media_player.SERVICE_SELECT_SOURCE,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2018-01-29 06:22:04 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2018-01-29 06:22:04 +00:00
|
|
|
|
|
|
|
|
2017-11-17 17:14:22 +00:00
|
|
|
@HANDLERS.register(('Alexa.Speaker', 'AdjustVolume'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_adjust_volume(hass, config, directive, context):
|
2018-01-27 19:58:27 +00:00
|
|
|
"""Process an adjust volume request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
volume_delta = int(directive.payload['volume'])
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
current_level = entity.attributes.get(media_player.ATTR_MEDIA_VOLUME_LEVEL)
|
|
|
|
|
|
|
|
# read current state
|
|
|
|
try:
|
|
|
|
current = math.floor(int(current_level * 100))
|
|
|
|
except ZeroDivisionError:
|
|
|
|
current = 0
|
|
|
|
|
|
|
|
volume = float(max(0, volume_delta + current) / 100)
|
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
media_player.ATTR_MEDIA_VOLUME_LEVEL: volume,
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, media_player.SERVICE_VOLUME_SET,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
2018-02-06 00:02:08 +00:00
|
|
|
@HANDLERS.register(('Alexa.StepSpeaker', 'AdjustVolume'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_adjust_volume_step(hass, config, directive, context):
|
2018-02-06 00:02:08 +00:00
|
|
|
"""Process an adjust volume step request."""
|
2018-02-17 13:54:15 +00:00
|
|
|
# media_player volume up/down service does not support specifying steps
|
|
|
|
# each component handles it differently e.g. via config.
|
|
|
|
# For now we use the volumeSteps returned to figure out if we
|
|
|
|
# should step up/down
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
volume_step = directive.payload['volumeSteps']
|
|
|
|
entity = directive.entity
|
2018-02-06 00:02:08 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
}
|
|
|
|
|
2018-02-17 13:54:15 +00:00
|
|
|
if volume_step > 0:
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2018-02-17 13:54:15 +00:00
|
|
|
entity.domain, media_player.SERVICE_VOLUME_UP,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2018-02-17 13:54:15 +00:00
|
|
|
elif volume_step < 0:
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2018-02-17 13:54:15 +00:00
|
|
|
entity.domain, media_player.SERVICE_VOLUME_DOWN,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2018-02-06 00:02:08 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2018-02-06 00:02:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.StepSpeaker', 'SetMute'))
|
2017-11-17 17:14:22 +00:00
|
|
|
@HANDLERS.register(('Alexa.Speaker', 'SetMute'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_mute(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a set mute request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
mute = bool(directive.payload['mute'])
|
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
media_player.ATTR_MEDIA_VOLUME_MUTED: mute,
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, media_player.SERVICE_VOLUME_MUTE,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.PlaybackController', 'Play'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_play(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a play request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, SERVICE_MEDIA_PLAY,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.PlaybackController', 'Pause'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_pause(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a pause request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, SERVICE_MEDIA_PAUSE,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.PlaybackController', 'Stop'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_stop(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a stop request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, SERVICE_MEDIA_STOP,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.PlaybackController', 'Next'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_next(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a next request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, SERVICE_MEDIA_NEXT_TRACK,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2017-11-17 17:14:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.PlaybackController', 'Previous'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_previous(hass, config, directive, context):
|
2017-11-17 17:14:22 +00:00
|
|
|
"""Process a previous request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2017-11-17 17:14:22 +00:00
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
|
|
|
}
|
|
|
|
|
2018-08-20 12:18:07 +00:00
|
|
|
await hass.services.async_call(
|
2017-12-29 17:44:06 +00:00
|
|
|
entity.domain, SERVICE_MEDIA_PREVIOUS_TRACK,
|
2018-08-20 12:18:07 +00:00
|
|
|
data, blocking=False, context=context)
|
2017-11-17 17:14:22 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response()
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
|
2018-08-22 07:17:29 +00:00
|
|
|
def temperature_from_object(hass, temp_obj, interval=False):
|
2018-03-30 06:49:08 +00:00
|
|
|
"""Get temperature from Temperature object in requested unit."""
|
2018-08-22 07:17:29 +00:00
|
|
|
to_unit = hass.config.units.temperature_unit
|
2018-03-30 06:49:08 +00:00
|
|
|
from_unit = TEMP_CELSIUS
|
|
|
|
temp = float(temp_obj['value'])
|
|
|
|
|
|
|
|
if temp_obj['scale'] == 'FAHRENHEIT':
|
|
|
|
from_unit = TEMP_FAHRENHEIT
|
|
|
|
elif temp_obj['scale'] == 'KELVIN':
|
|
|
|
# convert to Celsius if absolute temperature
|
|
|
|
if not interval:
|
|
|
|
temp -= 273.15
|
|
|
|
|
|
|
|
return convert_temperature(temp, from_unit, to_unit, interval)
|
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.ThermostatController', 'SetTargetTemperature'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_target_temp(hass, config, directive, context):
|
2018-03-30 06:49:08 +00:00
|
|
|
"""Process a set target temperature request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2018-03-30 06:49:08 +00:00
|
|
|
min_temp = entity.attributes.get(climate.ATTR_MIN_TEMP)
|
|
|
|
max_temp = entity.attributes.get(climate.ATTR_MAX_TEMP)
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
unit = hass.config.units.temperature_unit
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id
|
|
|
|
}
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
payload = directive.payload
|
|
|
|
response = directive.response()
|
2018-03-30 06:49:08 +00:00
|
|
|
if 'targetSetpoint' in payload:
|
2018-08-22 07:17:29 +00:00
|
|
|
temp = temperature_from_object(hass, payload['targetSetpoint'])
|
2018-03-30 06:49:08 +00:00
|
|
|
if temp < min_temp or temp > max_temp:
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
raise _AlexaTempRangeError(hass, temp, min_temp, max_temp)
|
2018-03-30 06:49:08 +00:00
|
|
|
data[ATTR_TEMPERATURE] = temp
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
response.add_context_property({
|
|
|
|
'name': 'targetSetpoint',
|
|
|
|
'namespace': 'Alexa.ThermostatController',
|
|
|
|
'value': {'value': temp, 'scale': API_TEMP_UNITS[unit]},
|
|
|
|
})
|
2018-03-30 06:49:08 +00:00
|
|
|
if 'lowerSetpoint' in payload:
|
2018-08-22 07:17:29 +00:00
|
|
|
temp_low = temperature_from_object(hass, payload['lowerSetpoint'])
|
2018-03-30 06:49:08 +00:00
|
|
|
if temp_low < min_temp or temp_low > max_temp:
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
raise _AlexaTempRangeError(hass, temp_low, min_temp, max_temp)
|
2018-03-30 06:49:08 +00:00
|
|
|
data[climate.ATTR_TARGET_TEMP_LOW] = temp_low
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
response.add_context_property({
|
|
|
|
'name': 'lowerSetpoint',
|
|
|
|
'namespace': 'Alexa.ThermostatController',
|
|
|
|
'value': {'value': temp_low, 'scale': API_TEMP_UNITS[unit]},
|
|
|
|
})
|
2018-03-30 06:49:08 +00:00
|
|
|
if 'upperSetpoint' in payload:
|
2018-08-22 07:17:29 +00:00
|
|
|
temp_high = temperature_from_object(hass, payload['upperSetpoint'])
|
2018-03-30 06:49:08 +00:00
|
|
|
if temp_high < min_temp or temp_high > max_temp:
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
raise _AlexaTempRangeError(hass, temp_high, min_temp, max_temp)
|
2018-03-30 06:49:08 +00:00
|
|
|
data[climate.ATTR_TARGET_TEMP_HIGH] = temp_high
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
response.add_context_property({
|
|
|
|
'name': 'upperSetpoint',
|
|
|
|
'namespace': 'Alexa.ThermostatController',
|
|
|
|
'value': {'value': temp_high, 'scale': API_TEMP_UNITS[unit]},
|
|
|
|
})
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
await hass.services.async_call(
|
2018-08-20 12:18:07 +00:00
|
|
|
entity.domain, climate.SERVICE_SET_TEMPERATURE, data, blocking=False,
|
|
|
|
context=context)
|
2018-03-30 06:49:08 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return response
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.ThermostatController', 'AdjustTargetTemperature'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_adjust_target_temp(hass, config, directive, context):
|
2018-03-30 06:49:08 +00:00
|
|
|
"""Process an adjust target temperature request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
2018-03-30 06:49:08 +00:00
|
|
|
min_temp = entity.attributes.get(climate.ATTR_MIN_TEMP)
|
|
|
|
max_temp = entity.attributes.get(climate.ATTR_MAX_TEMP)
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
unit = hass.config.units.temperature_unit
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
temp_delta = temperature_from_object(
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
hass, directive.payload['targetSetpointDelta'], interval=True)
|
2018-03-30 06:49:08 +00:00
|
|
|
target_temp = float(entity.attributes.get(ATTR_TEMPERATURE)) + temp_delta
|
|
|
|
|
|
|
|
if target_temp < min_temp or target_temp > max_temp:
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
raise _AlexaTempRangeError(hass, target_temp, min_temp, max_temp)
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
ATTR_TEMPERATURE: target_temp,
|
|
|
|
}
|
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
response = directive.response()
|
2018-03-30 06:49:08 +00:00
|
|
|
await hass.services.async_call(
|
2018-08-20 12:18:07 +00:00
|
|
|
entity.domain, climate.SERVICE_SET_TEMPERATURE, data, blocking=False,
|
|
|
|
context=context)
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
response.add_context_property({
|
|
|
|
'name': 'targetSetpoint',
|
|
|
|
'namespace': 'Alexa.ThermostatController',
|
|
|
|
'value': {'value': target_temp, 'scale': API_TEMP_UNITS[unit]},
|
|
|
|
})
|
2018-03-30 06:49:08 +00:00
|
|
|
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return response
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
@HANDLERS.register(('Alexa.ThermostatController', 'SetThermostatMode'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_set_thermostat_mode(hass, config, directive, context):
|
2018-03-30 06:49:08 +00:00
|
|
|
"""Process a set thermostat mode request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
entity = directive.entity
|
|
|
|
mode = directive.payload['thermostatMode']
|
2018-04-18 18:19:05 +00:00
|
|
|
mode = mode if isinstance(mode, str) else mode['value']
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
operation_list = entity.attributes.get(climate.ATTR_OPERATION_LIST)
|
|
|
|
ha_mode = next(
|
|
|
|
(k for k, v in API_THERMOSTAT_MODES.items() if v == mode),
|
|
|
|
None
|
|
|
|
)
|
|
|
|
if ha_mode not in operation_list:
|
|
|
|
msg = 'The requested thermostat mode {} is not supported'.format(mode)
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
raise _AlexaUnsupportedThermostatModeError(msg)
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
data = {
|
|
|
|
ATTR_ENTITY_ID: entity.entity_id,
|
|
|
|
climate.ATTR_OPERATION_MODE: ha_mode,
|
|
|
|
}
|
|
|
|
|
2018-10-31 15:09:13 +00:00
|
|
|
response = directive.response()
|
2018-03-30 06:49:08 +00:00
|
|
|
await hass.services.async_call(
|
|
|
|
entity.domain, climate.SERVICE_SET_OPERATION_MODE, data,
|
2018-08-20 12:18:07 +00:00
|
|
|
blocking=False, context=context)
|
2018-10-31 15:09:13 +00:00
|
|
|
response.add_context_property({
|
|
|
|
'name': 'thermostatMode',
|
|
|
|
'namespace': 'Alexa.ThermostatController',
|
|
|
|
'value': mode,
|
|
|
|
})
|
2018-03-30 06:49:08 +00:00
|
|
|
|
2018-10-31 15:09:13 +00:00
|
|
|
return response
|
2018-03-30 06:49:08 +00:00
|
|
|
|
|
|
|
|
2018-01-26 18:40:39 +00:00
|
|
|
@HANDLERS.register(('Alexa', 'ReportState'))
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
async def async_api_reportstate(hass, config, directive, context):
|
2018-01-26 18:40:39 +00:00
|
|
|
"""Process a ReportState request."""
|
Refactor Alexa API, fix thermostats (#17969)
* 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
2018-10-30 02:16:35 +00:00
|
|
|
return directive.response(name='StateReport')
|