Smart Home for Alexa Voice Service

With Smart Home for AVS, you can add custom voice control of your device's hardware functionality and support connected endpoints. Developers can integrate the Alexa APIs directly or use the AVS Device SDK.

If you want to voice control your device with a skill, you can build a separate Smart Home or custom skill and maintaining a separate cloud service. For more details, see Smart Home Development Options.

Smart home capabilities

The following smart home capabilities are available to AVS devices and their connected endpoints:

  • Alexa.PowerController: Control and report on the power state of a device.
  • Alexa.ToggleController: Model properties of an endpoint that can be set to on or off, such as the oscillation feature of a fan.
  • Alexa.RangeController: Model properties of an endpoint that can be set to one of a range of continuous values, such as the speed settings on a blender or a fan.
  • Alexa.ModeController: Model properties of an endpoint that can be set to one of a discrete set of values, such as the wash cycle mode of a washing machine.

Developers who integrate with AVS can assert support for these additional capabilities and use the pre-built voice and interaction models.

The following resources can help you to get started with smart home functionality functionality:

To take advantage of the smart home functionality you must transition from the Capabilities API to Alexa.Discovery API. This API also depends on the following interfaces:

Connected endpoints

The AVS documentation refers to the entity that maintains the HTTP/2 connection to Alexa as the "device," "client," or "product." In basic integrations, the device is the only entity that is the subject of user interactions and exchanges of messages with Alexa.

AVS also enables connecting additional "endpoints" to Alexa. (The endpoint isn't the same use of the term as "URI endpoint" for API connections.) These connected endpoints don't maintain their own direct connections to Alexa, instead rely on the HTTP/2 device to proxy events and directives on their behalf.

From the Alexa perspective, the device and all other connected endpoints are all "endpoints". The device reports both itself and connected endpoints in the same endpoints list in Alexa.Discovery. Where certain capability interfaces, mechanics, or fields apply only to the device maintaining the HTTP/2 connection, the documentation makes that clear. Otherwise, "endpoint" can refer to either the device or any connected endpoints.

Topology

Connected endpoints are analogous to those described by the Smart Home Skills Kit. When an endpoint connects through a skill, it requires that the developer maintains a cloud services, called an Amazon Web Service (AWS) Lambda function. That cloud service exchanges events and directives with Alexa on behalf of any endpoints. Therefore, the skill maintains the connection between the cloud service and the endpoint.

If the endpoint connects to an AVS device, the device takes the place of the cloud service, informing Alexa about the endpoint through Alexa.Discovery. Capability interfaces suitable for a connected endpoint include an endpoint object in events and directives, so that when the device exchanges messages with Alexa on behalf of the endpoint, both the device and Alexa know which connected endpoint the message is about. For more details, see Envelope Version and the documentation for individual capability interfaces.

Think of the device as a proxy for the endpoint, offering an abstraction layer to connected endpoints for AVS. Unlike the cloud service in a traditional smart home skill integration, the device is also itself an endpoint.

Endpoint types and connectivity

Endpoints may be physical or virtual. A physical endpoint might be a light bulb, thermostat, camera, or smart lock. A virtual endpoint might be a piece of software running on the device, like an installed app.

Endpoints might be separate physical entities or integrated components. For instance, a light bulb could be separate, perhaps in a ceiling lighting fixture. Alternatively, it could be integrated into the HTTP/2 device and modeled as a connected endpoint for separate control and targeting.

Alexa-defined JSON events and directives may be passed raw between the device and endpoint or translated into a different protocol, format, encoding, or signal. The only requirement is that the semantics are preserved.

If a connected endpoint is aware of Alexa, the endpoint could run software to understand and use Alexa events and directives. In such cases, the HTTP/2 device can pass messages between the endpoint and Alexa without translation, over whatever connection exists between the device and the endpoint.

By contrast, if a connected endpoint isn't Alexa-specific, the HTTP/2 device should translate the Alexa messages into the appropriate signal. For example, a TurnOn directive for a particular light bulb endpoint. The directive might then be translated into the appropriate Zigbee signal that turns on the light bulb. This applies to virtual endpoints as well. For instance, if the device receives a directive to control an Android app that is also installed on the device, it might need to translate that directive into the appropriate Android API, then translate any response into the corresponding Alexa event.

Was this page helpful?

Last updated: Jul 06, 2023