We are happy to announce tunable lighting control, a new feature in the Smart Home Skill API now available in the US with support for the UK and Germany coming soon. This is great news for those of you targeting color-changing lights or tunable white lights.

Today we are happy to announce lock control and query, a new feature in the Smart Home Skill API now available in the US, with support for the UK and Germany coming soon. This feature is supported with locks from August, Yale, Kwikset, and Schlage as well as hub support from SmartThings and Wink. Now any developer targeting devices with locking behavior can enable customers to issue a voice command such as, “Alexa, lock the front door.” In addition, developers can build in support for customers asking for the status of a smart locking device with a voice command such as, “Alexa, is the front door locked?”

Much like the recently announced thermostat query feature, the lock query feature simplifies development efforts by enabling specific voice interactive experiences straight from the Smart Home Skill API. This is accomplished under the new Alexa.ConnectedHome.Query namespace.

Developers can report errors using the same namespace. These errors are then used to guide the customer with the proper corrective actions. It’s crucial that developers return meaningful and correct errors so that customers can feel confident about the status of their locks. For example, if the smart locking device is unable to provide a stateful value because a door is open, developers should report this in their directive response as shown below.

Today we are happy to announce support for thermostat query, a new feature for Alexa skills developed using the Smart Home Skill API. The feature is now available in the US, with support for the UK and Germany coming soon. With thermostat query, customers can issue a voice command to an Alexa-enabled device, such as the Amazon Echo or Echo Dot, and hear Alexa say the response. For example, a customer with a single thermostat could say, “Alexa, what is the temperature in the house?” and Alexa would respond with the current inside temperature. This complements thermostat commands that already allow customers to set the temperature value.

This new feature simplifies development efforts by enabling specific voice interactive experiences straight from the Smart Home Skill API. In the past, smart home skill developers had to create two skills (one for smart home, the other for custom voice interactions to allow querying data) to provide this overall experience.

Today’s post comes from J. Michael Palermo IV, Sr. Evangelist at Amazon Alexa. You will learn why you should use a custom slot instead of the soon to be deprecated AMAZON.LITERAL.

We’ve been listening to your feedback for Alexa feature requests and questions. As such, this post provides details around the deprecation of literal slots. By the time you finish reading this post, you will see it doesn’t matter that the LITERAL slot type is going away because it already has a better replacement: custom slot types.

Before we get into the details, it’s clear that the community needs more time to experiment with custom slot types and to make the transition. So, we’re moving the LITERAL deprecation date for US skills to Feb 6^th 2017. From the beginning, custom slot types (and not LITERAL) have been the solution in the UK or Germany.

Slots let you to build interaction models and pass phrases from the user to your skill. Amazon provides a set of built-in slot types that cover common things like numbers, names, and dates. Custom slot types go beyond these to enable support for the scenarios that you’ve chosen to build. They are a superset of the LITERAL slot type that we’re deprecating.

This post will describe how to support three common LITERAL scenarios we’ve seen.

Scenario 1: I want to collect an arbitrary word or phrase from what the user said.

Imagine a situation where you want to gather information from users that you don’t know when you build your interaction model. Examples include things like lists of wines, items in a game, names of cities, nicknames, etc. It’s clear that you could build a custom slot with all the values that you do know but how do you handle the values that you don’t or can’t know?

First, be sure to check the list of built-in slot types. You may find something that we’ve already built for you like first names, city names, last names, dates, numbers, and many more.

When you create a custom slot type, a key concept to understand is that this is training data for Alexa’s NLP (natural language processing). The values you provide are NOT a strict enum or array that limit what the user can say. This has two implications 1) words and phrases not in your slot values will be passed to you, 2) your code needs to perform any validation you require if what’s said is unknown.

Let’s look at an example of how to build support for something like nicknames. The custom slot type is named NICKNAMES. The custom slot values are shown here: 

Figure 1 : Custom slot for NICKNAMES

The intent schema uses NICKNAMES instead of AMAZON.LITERAL.

In September 2016 we announced the all-new Fire HD 8 tablet, designed form the ground up for all-day entertainment. Among the many new features mentioned was support for Alexa, as quoted here:

"Alexa is Amazon’s cloud-based voice service that allows customers to play music and get information, news, sports scores, weather, and more—instantly, just press and ask. In the coming months, Fire tablets will also be able to connect to Alexa, enabling Alexa developers to extend their reach to Fire tablet users."

Today, customers can now access Alexa on Fire, Fire HD 8, and Fire HD 10 tablets by simply pressing down on home icon in the navigation bar and start talking. For Alexa developers, this not only extends the reach of your audience, it provides another scenario where voice-interactions can be complemented with a visual skill card to enhance the experience. When using Fire Tablets or Fire TV Stick with Alexa Voice Remote, the visual cards appear immediately and can also be referenced in the Alexa app.

Skill cards contain a title, a text body, and optionally one image. These cards present information for easy consumption by customers.

Today we are happy to announce the support for scenes, a new feature in Alexa skills developed with the Smart Home Skill API. With scenes, customers can issue a single voice command to an Alexa-enabled device such as the Amazon Echo or Echo Dot to set a predefined configuration of one or more devices to a desired state. For example, a customer could say, “Alexa, turn on bedtime” resulting with specific lights turning off, a bedroom light changing color to a low-lit orange-hue, a ceiling fan turned on, and the temperature changed to an ideal setting for sleep.

At first glance scenes might appear similar to the groups feature found in the Smart Home section of the Alexa app as both allow control over multiple devices with one voice command. However, scenes differ from groups in the following ways:

• Scenes allow each device configured within it to be set to a desired state, whereas groups are stateless and simply turn devices on or off.
• Scenes are configured by customers through a device manufacturer’s app, whereas groups are configured in the Alexa app.
• Scenes only contain devices managed by the device manufacturer’s app, whereas groups can contain any device discovered in the Alexa app.

With scenes customers have another option to groups for controlling multiple devices. Customers may already have scenes configured in device manufacturer apps such as those provided by Control4, Crestron, Insteon, Lutron Caseta, SmartThings, or Wink. Prior to today, these scenes were invoked by using the device manufacturer’s app. Now customers can find these scenes listed as devices in their Alexa app after requesting device discovery and control via voice interaction. 

How Scenes Work

Figure 1: Scene control process

Once a customer has configured a scene through the device manufacturer’s app and requests a device discovery to Alexa, the scene name will appear in the device list in the Alexa app. Consider what happens from a developer perspective, when a voice command is made to turn a scene on.

Let’s examine each step above in more detail.

1. Customer says, “Alexa, turn on bedtime.”
2. Alexa service receives the request and routes this intent to the Smart Home Skill API.
3. A directive is composed including the ‘TurnOnRequest’ name in the directive header and the appliance ID (located in directive payload) corresponding to the friendly name of the scene “bedtime.”
4. The skill adapter hosted in AWS Lambda receives the directive. Included in the directive is an access token to determine the customer’s account making the request. A call is made to device cloud API to turn on the scene matching the appliance ID for the associated customer.
5. The device cloud (likely owned by the device maker) receives a request from the skill adapter, and communicates to a device hub or controller to turn on the scene preconfigured by the customer.
6. The device hub sets the desired state of each device configured by the customer. Note in this “bedtime” example, turning on a scene may result in turning off a light, since this could be the desired state of that device for the scene.

Today’s post comes from J. Michael Palermo IV, Sr. Evangelist at Amazon Alexa. You will learn how to respond to control directives in code to turn devices on or off, set temperature, and set percentages.

When you build a skill with the Smart Home Skill API, the ultimate goal is to control a device. That control can include turning a device on or off, setting a temperature, or setting a percentage, such as when you’re dimming a light bulb. This post will cover the general process of device control and teach the fundamentals by demonstrating control of the ‘on’ or ‘off’ state in code using Node.js.

This technical walkthrough is a continuation in a series of smart home skill posts focused on development. Please read and follow the instructions found below to reach parity.

• Five Steps Before Developing a Smart Home Skill
• Coding Smart Home Skill Adapter Directives Using Node.js
• Managing Device Discovery for Your Alexa Smart Home Skill

How Device Control Works

Figure 1: Device control process

Once a customer has properly installed, configured, and discovered all smart home devices, verbal control commands can be issued to an Alexa-enabled device, such as the Amazon Echo. Consider what happens from a developer perspective when a control command is made, such as turning on a light.

Let’s examine each step above in more detail.

1. Customer says, “Alexa, turn on desk light.”
2. Alexa service receives the request and routes this intent to the Smart Home Skill API.
3. A directive is composed and contains, among other things, the ‘TurnOnRequest’ name in the directive header and the appliance ID matching the friendly name “desk light” in the payload.
4. The skill adapter hosted in AWS Lambda receives the directive. Included in the directive is an access token to determine the customer’s account making the request. A call is made to device cloud API to turn on the device matching the appliance ID for the associated customer.
5. The device cloud (likely owned by the device maker) receives a request from the skill adapter, and communicates in its own fashion to the device identified by appliance ID to turn on.
6. The device, in this example, a desk light), turns on.

Today’s post comes from J. Michael Palermo IV, Sr. Evangelist at Amazon Alexa. You will learn the process of device discovery and how to support it in code for your smart home skill.

Developing a smart home skill is different than building a custom skill. One of the main differences is the dependency on devices to control. The device might be a light bulb, thermostat, hub, or other device that can be controlled via a cloud based API. Or maybe you created an innovative IoT gadget and you want to make it discoverable by an Alexa enabled device. In this post, you will learn how the process of device discovery works, and how you can support discovery in your custom skill adapter communicating with the Smart Home Skill API.

To meet prerequisites and set the context of the technical information in this post, start by reading the five steps before developing a smart home skill and set up your initial code to support skill adapter directive communications. This post will be the next in the series of these posts and provides the foundation for code samples to follow.

Understanding the Customer’s Perspective of Device Discovery

To appreciate the role of device discovery, consider how a customer is involved in the process. The following steps assume a consumer has an Alexa-enabled device, such as the Echo or Echo Dot, already set up.

1. Customer physically installed a smart home device and followed instructions likely requiring customer to create an account to log into an app or web site used to associate/control the device.
2. Customer opens Alexa app and enables the smart home skill associated with device. Customer is immediately prompted to sign in with credentials used in previous step.
3. Customer either selects the ‘discover devices’ link in the Smart Home section of the Alexa app, or verbally commands it by saying “Alexa, discover devices.”

Once the first step is completed, the customer is able to control the smart home device typically through an app provided by the device maker, which is graphical user interface that manages device and owner information controlled in it’s own device cloud. The account created in the first step is the same account used in the second step when the consumer enables the associated smart home skill. This explains why account linking is mandatory for skills created with the Smart Home Skill API.

But what happens in the third step when the consumer makes a device discovery request? Does it actually seek for devices emitting some signal within the home? Is it querying everything it can within the local WIFI area? The answer to both questions is no. Although there are a couple of exceptions to enable early support of popular products such as Philips Hue and Belkin WeMo, the process described next is what is supported today and moving forward.

How Device Discovery Works

Figure 1: Device discovery process

When a request is made by the customer for devices to be discovered, the Alexa service identifies all the smart home skills associated with the consumers account, and makes a discover request to each one as seen here.

Let’s examine each step above in more detail. Notice the first step is the same as the last step we covered when considering the customer’s perspective, so this is a deeper dive as to what happens next. Also observe in Figure 1 that no communications occur directly between the Amazon Echo and the smart home device.

Today’s post comes from J. Michael Palermo IV, Sr. Evangelist at Amazon Alexa. In this post you’ll learn what directives are and how to develop a smart home skill adapter from scratch using Node.js.

Much of the heavy lifting for creating smart home skills happens before writing a line of code. In my last post, I walked you through the five  prerequisites to building a smart home skill. You may have noticed I left the code for the AWS Lambda function blank. In this post, you will start where that post ended. Not only will see how to manage the code workflow for a smart home skill adapter using Node.js, but you will also learn the fundamentals of the directive language, the communication protocol used between your skill adapter and the Smart Home Skill API.

Skill Adapter Directive Language

Before tackling any lines of code, you should understand the role of your skill adapter in the smart home skill process workflow. When the Alexa service understands the intent of a voice command to be smart home related, it continues processing through the Smart Home Skill API. The Smart Home Skill API service then communicates with a skill adapter using directive language, a JSON protocol structured to convey requests and responses. Each unique instance of a request or a response is known as a directive. All communications between your skill adapter and the Smart Home Skill API use the directive language. Your skill adapter receives requests as directives and is responsible for providing responses as directives.
 

Figure 1 : Directive Language

The structure of a directive involves two primary components, a header and a payload. While the payload varies in structure based on context, the header is fixed with just four fields defined here.

Table 1 : Directive header fields

Consider an example of an incoming directive from the Smart Home Skill API service to a skill adapter.

{

 "header" : {

  "messageId" : "6d6d6e14-8aee-473e-8c24-0d31ff9c17a2",

  "name" : "DiscoverAppliancesRequest",

  "namespace" : "Alexa.ConnectedHome.Discovery",

  "payloadVersion" : "2"

 },

 "payload" : {

  "accessToken" : "acc355t0ken"

 }

}

In the header, the namespace reveals the category of the directive is “Alexa.ConnectedHome.Discovery”, and the name “DiscoverAppliancesRequest” indicates a device discovery request is being made to a skill adapter. Because all smart home skill adapters require account linking at time of enablement, the payload will include the access token associated with the customer’s device cloud account. The value shown above is a mocked value used for testing purposes only. For more background about account linking and access tokens, please see this blog post.

Today’s post comes from J. Michael Palermo IV, Sr. Evangelist at Amazon Alexa. Learn what steps you should take before developing with the Smart Home Skill API.

Before creating a skill, you must first determine if you want to build a custom skill or a smart home skill. Most skills are built using the Alexa Skills Kit (ASK) and are broadly known as custom skills. However, if the end goal is to enable a skill to have voice control over a device or appliance in the home, you will want to develop a smart home skill using the Smart Home Skill API.

Smart home skills differ from custom skills in these ways:

• With custom skills, you must build a voice interaction model to handle customer requests. Smart home skills use Amazon’s standardized language model so you don’t have to build the voice interaction model. As such, your customers don’t need to remember your skill name or a specific invocation phrase. Furthermore, customers who already control devices using Alexa with other smart home skills already know how to use your smart home skill, and will also enjoy a consistent, first class experience with your devices.
• The smart home skill adapter must be hosted in an AWS Lambda function, whereas custom skills can be hosted in either AWS Lambda or another cloud-based hosting service.
• You must implement account linking using OAuth 2.0 for smart home skills, while this is optional for custom skills.
• Since smart home skills target connected devices in the home, you must have access to a cloud-based API to handle device discovery and control.

With the above differences in mind, your approach to creating a smart home skill may require more work to be done upfront than with a custom skill. However, know that with a smart home API skill, you wouldn’t need to define and maintain a language model yourself, and as Alexa improves its language model overall, you get the improvements for free.

Meeting the Smart Home Skill API Prerequisites, Step by Step

Follow these steps to confirm you have what you need before developing a smart home skill. Start by following these five steps to meet the Smart Home Skill API prerequisites:
 

1. Choose OAuth 2.0 provider for account linking
2. Initialize creation of smart home skill
3. Create an AWS Lambda Function
4. Configure smart home skill
5. Finalize account linking and confirm
    

Step 1: Choose OAuth 2.0 Provider for Account Linking

Sebastien Stormacq recently authored an excellent blog post providing step-by-step guidance to implement account linking for custom skills. While much of the information in that post applies here too, there are some differences in implementation details. This post will provide complete guidance for setting up account linking for smart home skills, with some admitted overlap to Sebastien’s post. For a fine overview of OAuth 2.0 and understanding of options, it may benefit you to read the first two sections of his post and then resume here.

If you have already created or chosen a specific OAuth 2.0 provider, you can proceed to the next step. If not, the remainder of this step will show how to fulfill this requirement by using Login with Amazon (LWA).

First, you need to create an LWA security profile. Here’s how:
 

• Connect to https://developer.amazon.com and authenticate with your Amazon credentials.
• Click on “Apps & Services”, then “Login with Amazon”
• Click on “Create a New Security Profile”

Figure 1 : Access Login With Amazon.

Fill in all three required fields to create your security profile and click “Save”. For the purpose of this post, the privacy URL points to Amazon’s. Make sure to replace the link with a link to your own Data Privacy policy.

Hello, my name is Michael Palermo, and I recently joined the Alexa team as the first dedicated evangelist for smart home. When friends and acquaintances ask what I do, they often looked puzzled before I get past my title. Inevitably I get questions like: What is a “smart home”? Who or what is Alexa? Why are you called an evangelist?

In this post, I’ll answer a lot of these questions. Granted, you may already be familiar with some of the topics, but stay tuned as I will also provide additional insights as to why it might matter to you.

What is a “Smart Home”?

The term “smart home” or “Connected Home” (CoHo) refers to a residence consisting of one or more smart products which enhance the living experience with benefits such as convenience, control, and optimization of resources. A product is deemed “smart” when it is capable of communicating with other smart products and/or a user interface to manage it.

What is Alexa?

From a consumer perspective, a more familiar brand name is Echo. Alexa is the voice service that powers Echo and other similar devices like Amazon Tap and Echo Dot. With Alexa, developers can build new voice experiences with the Alexa Skills Kit (ASK) or by adding voice to connected devices with Alexa Voice Service (AVS).