Leveraging Two Types of Alexa Skills

I’ve been progressively expanding my RV’s automation system. At this point I have 14 automated lights, and I expect that number to at least double over the next year.

Voice control using Alexa is working fairly well. Currently, I use the Patriot Alexa smart home skill to control both activities (aka scenes) and individual devices. And I think this is becoming a problem.

As the number of devices grows, it gets harder to remember the exact name of each specific light, and harder for Alexa to accurately hear the correct device or activity name. For example, I have lights on the front, rear, and ramp awnings. I’d like to be able to control them individually, as well as being able to turn them all on or off with a single activity name. It’s easy for me to say “Alexa, turn on the awning light” as I’m heading out the rear door, when what I really mean is the “rear awning”. Sometimes Alexa responds with something like “I have several devices with that name. Which do you mean?”.

So I’ve been thinking about how to simplify the vocabulary that I use with Alexa. I really like that Alexa smart home skills provide a very simple and terse vocabulary (eg. “Alexa, turn on xyz”). So I’m currently allowing it to control both activities as well as individual devices. One of the things I’ve realized is that as the number of devices grows, I rarely want to control individual lights. So I use activity names most of the time. The large number of individual device names just provide opportunities for conflicts with activity names, and misinterpretations. It would be nice if I could clearly separate device names from activity names.

Also, I’d like to be able to dynamically create and edit activities. A smart home skill certainly won’t allow this. So I’ve come to the conclusion that I also need a custom skill to provide that additional functionality.

At this point a light comes on in my head, and I think “why not use a smart home skill for the commonly used things, and a custom skill for the rest?” This equates to using the smart home skill to only turn activities on and off, and use a custom skill to control individual devices, and add or remove them from activities.

So this is the direction I’m going now. I’m going to remove individual device control from the published Patriot hobbyist smart home skill. This doesn’t mean it can’t control an individual device. It just means that an activity will be needed to do that.

I’ve already started on the custom skill, and have published the beginnings of it on Github. I’ll be expanding both it and Patriot to allow defining new activities, as well as allowing activities to be edited or updated using voice also.

Extending an Alexa Skill to Control Patriot Devices

In the last post I showed how to create an Alexa skill using the Alexa Skill Kit Command Line (ask-cli). In this post I’m going to show how to extend that skill to control the blue LED on a Particle.io Photon.


This post assumes:

  1. You are already familiar with Photon development using the Particle.io IDE of your choice
  2. You have a particle.io account already setup.
  3. You have completed the previous post to create a starter Alexa skill using the ASK CLI.

Continuing Where We Left Off

By the end of the last post we had a working Alexa skill, although it didn’t really do anything interesting. Let’s change that and add some code to make it talk with a Photon controller using the particle.io API.

Let’s start by adding a couple intents to turn on and off a light:

Alexa, turn on the blue light

Alexa, turn off the blue light

Easy, right? We’ll add the intent first without it doing anything except responding “Ok”, then add the calls the the particle.io after that is working.

Basic Changes

Let’s start by changing the invocationName on line 4 of en-US.json to “my photon”. Now we can say “Alexa, tell my photon to …”.

Adding a New Intent

Copied intent

Adding an intent will require defining it in the en-US.json file, and then creating an intent handler in index.js.

So open en-US.json in your favorite editor, and copy the entire HelloWorldIntent. After the copy, it should look as shown here.

Next edit the two copies to make them be our turn-on and turn-off intents.

Note: we could have used a single intent with a slot for the on/off state, but I’m trying to keep things very simple. Plus this allows you to use slang or fun expressions such as “light me up” or “gee, I feel blue”, etc.

So now we should have a TurnOnIntent and a TurnOffIntent defined. Let’s delete the previous MyNameIsIntent. So the final file should look like this:

Edited en-US.json file

So now we need to handle the two new intents, and remove the deleted intent from the Lambda source. So open the lambda/custom/index.js file and make the following changes (or you can cut/paste the entire thing from the example below):

  1. Delete the ‘SayHelloName’ handler on line 29 through 34.
  2. Edit the ‘SayHello’ function to say something appropriate such as “You can tell me to turn on or turn off the light”. Update the cardRenderer() text similarly.
  3. Copy the same or similar text to the help intent.
  4. Delete the HelloWorldIntent and MyNameIsIntent
  5. Copy the SayHello intent twice
  6. Change the first SayHello copy to ‘TurnOnIntent’, and change the text to something like ‘Ok, the light is now on”, and provide more descriptive text in cardRenderer. The later is the text to be displayed on Show and in the Alexa app.
  7. Similarly, change the second SayHello copy to ‘TurnOffIntent’, and change the response and card text.

The index.js handler’s section should look similar to this after these edits:

Updated index.js

Now deploy the changes by entering “ask deploy” again. Test the updated skill by saying “Alexa, tell my photon to turn light on”. Make sure that you previously enabled testing in the Alexa skill test tab.

Verify that all of the intents work as expected, including:

  • Just launching the skill: “Alexa, open my photon”
  • Asking for help: “Alexa, ask my photon for help”
  • Turning on light: “Alexa, tell my photon turn light on”
  • Turning light off: “Alexa, tell my photon turn off”

If all that is working as desired, let’s move on to sending on/off commands to the Photon via the particle.io and Patriot open source library.

Adding the Particle Javascript SDK to our Project

So now on to the fun part. Alexa can now handle commands to turn something on and off, so we need to forward those requests to the particle.io API.

We’re going to use the particle Javascript SDK. I had posted code to Github a couple years ago called alexaParticleBridge using raw HTML calls, but since then Particle published their SDK that makes this a lot simpler.

So first we need to fetch and add the particle-api-js package to our project.

  • Edit lambda/custom/package.json to add the following line to the dependencies section:particle api dependency
  • Within the lambda/custom directory, run “npm update” to fetch the particle sdk modules.

Now we need to add the Particle object to our code. Include the Particle object in index.js by adding the following line near the top below the line that includes the alexa-sdk:

Code to include particle sdk

Setting Up Alexa Account Linking

Before we can call the methods of the particle object to communicate with our device, we need to give Alexa the credentials needed when calling the Particle API. We could hardcode our Particle account username and password into the skill, but that would be unwise and is totally unnecessary. Both Alexa and Particle.io provide support for using OAuth2.

Without getting into the messy details, what OAuth2 does in this case is to allow the Alexa skill to call a webpage provided by Particle.io. That webpage prompts the user to enter their username and password, and if valid will forward an access token to the Alexa skill that it can use to access the API. The Alexa code never has to know or even see the user’s credentials. How cool is that?

To get Alexa Account Linking working, we don’t really need to understand how OAuth2 works. We just need to know where to get the information needed. I’m going to step us through doing that.

Note: currently it doesn’t appear that the ask-cli supports uploading Account Linking information, so we’re going to need to enter the information directly into the Alexa developer website for the skill.

So open up a browser window to you Alexa developer account, and browse to the skill’s Configuration tab. The Endpoint information should already be filled in. Below that is the scary looking Account Linking radio button. Select Yes and a bunch of cryptic entry fields will appear. Let’s fill then in one-by-one:

  • Authorization URL: https://api.particle.io/oauth/authorize
    This tells Alexa the URL to display to prompt the user for their account login. This is a Particle.io provided website.
  • Client ID: particle
    This is provided to the Particle.io authorization URL. We will generate this in the next step, but for now enter “particle”.
  • Domain List (optional):
    Leave blank. It isn’t needed.
  • Scope: none
    Click on the Add domain button and add the scope ‘none’. It isn’t currently used, but may cause problems if something isn’t entered here.
  • Redirect URLs
    These are filled in for you. We don’t use them, so you can ignore them.
  • Authorization Grant Type: Auth Code Grant
    Select Auth Code Grant
  • Access Token URI: https://api.particle.io/oauth/token
    This provides Alexa with the URI to use when requesting or refreshing an access token. It is provided by Particle.io.
  • Client Secret: particle
    We will generate this in the next step. For now enter “particle”.
  • Client Authentication Scheme: HTTP Basic
    Leave this the recommended default.
  • Permissions:
    Leave these all unchecked.

Save this page. We’ll come back and enter the actual Client ID and Client Secret later.

Make a copy of one of the Redirect URLs. We’ll need it to create the client ID and secret in the next step.

Generate an Oauth Client

We need 2 things to create an oauth client:

  • Your particle.io access token
  • The redirect URL from the previous step

To get your particle.io access token, log into your particle.io account and go to the IDE. Select Settings (the gear icon in the bottom left) and assuming that you are logged in, the Access Token will be displayed near the top left. Make a copy of it for use in a moment.

Now we need to use your access token along with the Redirect URL saved in the previous step to create a valid Oauth client. These instructions assume you are running on a Mac and using the Terminal, but you could use any program capable of issuing Curl commands.

  • Open a Terminal or Command Line window
  • Issue the following command, substituting your redirect url and access token:
    • curl https://api.particle.io/v1/clients -d name=<your-skill-name> -d type=web -d access_token=<your-access-token> -d redirect_uri=<your-redirect-url>.

The response should include an id and secret. Make a not of these.

Warning: This is the only place that the secret will be displayed. Save it carefully. If you lose it and need it again later you will have to repeat the above steps to recreate a new id and secret.

Now go back to the Alexa Configuration page and enter and save the new Client ID and Client Secret you just created.

Whew! That should do it. Save this information, and restart your skill. When your skill is enabled in the Alexa app, it will display the Particle.io login screen where you can enter your user id and password. From then on, Alexa will automatically fetch a Particle.io access token that your code can use to access the Particle.io API.

Using the Access Token

Now that we’ve setup account linking, Alexa will pass an access token to our code with each request. It will be passed in the event session information event.session.user.accesstoken. Let’s update our code to get and save it.

var token = this.event.session.user.accessToken;

Sending Requests to Particle.io

Now all that’s left is to use the Particle object created to to send requests to our Particle devices using the token obtained above.  So lets create a function to call the Particle API Publish function:

publish function

Now we can add calls to this method in our intent handlers, and Publish events to our Particle devices. Here’s the TurnOnIntent and TurnOffIntent will the calls to publish():

TurnOnIntent and TurnOffIntent code

Note that a promise is used, and that emit is only called after the promise resolves. Also, the arrow function is used to allow “this” to continue to point to the response object.

So at this point we have a working Alexa skill that Publishes events to our Particle devices. In this example we used the device name “blue”. This needs to match the name you gave a device or activity in your Patriot code. I’m not going to duplicate the information about using Patriot, since I’ve posted several articles about that already. And of course you can call other particle API methods in addition to publish.

So this example should give you enough information to make function calls, set or read variables, and so forth. The complete project code is on Github. I hope you have as much fun with it as I have.

Caveat: I’m very much an intermediate Javascript programmer at best. I’m working with and learning from some really good Javascript programmers, but I’ve got a long way to go. Please don’t use my code as an example of the correct or best way to do things in Javascript.

Using ASK CLI to Create a Custom Skill

When Amazon announced the ASK CLI a couple months ago, it created a simpler and more powerful way of creating and updating Alexa skills. We’re going to use the ask-cli to create an Alexa custom skill. In the next blog post we’ll extend that skill to interact with a Particle.io Photon using open source Patriot code.

Before the ASK CLI was available, I had to open multiple browser windows and edit data directly in the Amazon Alexa developer portal and AWS Lambda console. As a professional software developer, I’m accustomed to using powerful editors and source code management tools such as Git to track my changes. Being forced to enter data into a web browser page leaves a lot of room for mistakes. And tracking those changes with Git means having to cut/paste from a tracked local file to the browser, again leaving room for more mistakes.

The ask-cli goes beyond just allowing local files to be uploaded to an Alexa skill. It provides a start-to-finish set of commands to create, update, and publish skills.

So let’s see how the ask-cli can be used to create a new Alexa skill from the ground up.

Install and Initialize the ASK CLI

Refer to the Amazon documentation for instructions on installing and setting up the alexa skills kit command line interface (ask-cli). You’ll need to configure it with your Alexa developer account and an AWS account using the “ask init” command.

Create a New Skill

Now create a directory to contain your new skill, and run the “ask new -n <skillname> ” command. For example, I’m naming mine “Patriot”, so the command is “ask new -n Patriot”. This results in the following directory structure:

folder structure created by ask new

In one fell swoop we have created a basic “Hello World” Alexa custom skill. This includes the Alexa intent schema, utterances, and Lambda source and meta data. Pretty cool, eh?

Add Source to Git

If you use Git to track your source changes, now would be a good time to create a repo and add the files to it. This step is completely optional, but recommended.

Run the Skill

At this point, even without having changed anything, the new skill should work. Let’s upload it just to see:

ask deploy

If you’re accounts and ask-cli are setup correctly, then you should receive a series of messages indicating that the skill and lambda have been deployed correctly as shown here:

ask deploy
-------------------- Create Skill Project --------------------
Profile for the deployment: [default]
Skill Id: amzn1.ask.skill.your-new-unique-id...
Skill deployment finished.
Model deployment finished.
Lambda deployment finished.

Now if you check your Amazon Dev Alexa and AWS accounts, you should see that a new Alexa skill with the name you specified on the “ask new” command, and a Lambda  named “ask-custom-<name>-default” have been created. The default invocation word for the skill created by “ask new” is “hello world”.

By default, the new skill is not enabled for testing. Go to the test tab in the developer.amazon.com Alexa console console and enable it, and then you can test “hello world” on your Alexa device (Echo, Dot, EchoSim.io, etc).

Edit the Source Code

Ok, so now that you’ve seen the awesome power of a fully functioning death star, er I mean Alexa skill, we can commence to editing it to do something that we want beside telling us hello.

Now begins the iterative development process:

  1. Updating the source
  2. Deploying the skill
  3. Testing the skill
  4. Repeat

I strongly recommend that you make tiny changes each iteration, and use Git to check in each step of the way. That way you can back up a step if something breaks and you cannot figure out what.

There are 2 main source code files you need to work with. For simple skills, that’s all you need to modify:

  1. models/en-US.json (if you’re in the US, otherwise named for your language)
    contains the intents, slots, and utterances (now called samples)  that Alexa will respond to.
  2. lambda/custom/index.js
    contains the response to each intent.

By default your new skill will say “Hello” in response to launching the skill eg. “Alexa, open hello world”, or “Hello <name>” in response to “Alexa, tell hello world my name is <name>”. I recommend playing with the existing code, making small changes to the skill, redeploying it, and verifying that your changes act as expected.

Here are some things to try:

  1. Change the response to the SayHello intent from “Hello World!” to “Hello whatever your name is”. This should require just a change to line 25 of index.js.
  2. Change the help response. This is on line 43 of index.js.
  3. Add some additional samples to en-US.json for the user to say to invoke the two intents. For example, add “whats up,” between “hello”, and “say hello”,.
  4. Change the invocationName in en-US.json. For example, change “invocationName”:”hello world” to “invocationName”:”ahoy matey”. In addition, change the response in index.js to “Welcome aboard!”

If you don’t include quotes or commas where needed, ask will happily upload the broken code, and you won’t know until you test the skill. This is where a good Javascript editor comes in handy.

I’m not going to try to cover all the details of coding an Alexa skill here. There are lots of tutorials and blog posts in addition to Amazon’s documentation. I leave that as a homework assignment for you.

In the next article I’m going to show how to update this skill to send on and off commands to the LED on a particle.io Photon.

Automation Using the Control Everything Relay Board

ControlEverything.com boards

As I mentioned in the previous post, I’m going to give the ControlEverything.com boards a try. I’ve received the 8 relay Photon board, an 8 relay I2C expansion board, and the cable to interconnect them.

So to start off, I plugged a Photon into the 8 Relay Photon board, connected 12v to the board, and worked through their getting started tutorial.

I flashed the Photon with the example I2C scan code, and it immediately detected the I2C port at address 32.

Next I tried out the example from their NCD8Relay library on GitHub. This worked great. It toggles the relays in various ways. You can hear the relays toggling, in addition to seeing the status LED of each turn on and off.

So next I needed to figure out how to integrate this board with Patriot. Currently Patriot assumes a dedicated pin to control each device. Since the ControlEverything.com boards use I2C, I’d need to make some changes.

So next I created a new Patriot plugin library named NCD8Relay. This plugin should work with any of the NCD relay boards. There are two different I2C chips used on the boards, so addressing needs to take that into account. Since I don’t have any of the other sized relay boards, only the 8 relay photon and I2C expansion boards are tested at this point.

So having extended Patriot with the NCD8Relay plugin, I verified operation of the boards using both the iOS app and Alexa smart home skill. This all looks pretty good, so the next step will be to mount the boards behind the lighting control panel and wiring them up. That’s coming up in the next post.

Patriot iOS App

Patriot iOS appThis weekend I posted to GitHub the source code for a Patriot iOS app. This is a cleaned-up version of an app that I wrote awhile back to control Photon devices in my RV. The intent is to allow mounting old iPhone devices to the wall to use as control panels for my Photon controllers. Refer to my previous article about Patriot for information about the Particle.io code and Alexa skill.

In the image here you can see 3 different ways of controlling a Photon controller. There is an Alexa sitting next to an iPhone 4s mounted to the wall next to several wall switches.

The Problem with Switches

The switches are connected to a Photon mounted in the wall behind them and actually broadcast particle.io events instead of directly controlling power to lights. They can control multiple lights, or even things that aren’t lights. I had intended to put a bunch of switches like these around my home, but there’s a problem with mechanical switches like these. They suggest a ‘state’ of on or off. So for example, typically a switch would be “on” if one way, and “off” if the other. However, if I turn a a light on by flipping a switch up, then I turn the light off by telling Alexa to turn it off, then the switch continues to indicate “on” but the light is actually off.

Alexa Smart Home Skill

The Alexa is running the Patriot Alexa smart home skill to dynamically determine the events that my IoT Photons are listening for, so I can tell Alexa to turn activities on or off. But as described above, this leaves normal switches indicating the wrong state. So I decided that I need some sort of switch that can change to reflect the state even when changed by other devices or switches.

Old iPhone Devices to the Rescue

So an obvious choice is to use motorized switches. Unfortunately I couldn’t find any in my parts locker. But I did come across several old iPhones and began to think about how extremely powerful these could be to control my IoT devices. So I wrote a simple control panel app that displays the state of a list of hard coded activities, and allows tapping on them to toggle their on/off state. I then purchased some cheap plastic iPhone covers for them that I mounted to the walls, and can just snap the iPhones into place to hold them on the wall. I ran a power wire over, and voila!

Nice, works ok, but my head nearly exploded when I started thinking about  all the ways these could be extended. Before I start going on about possible future enhancements, let me announce that I have cleaned this original code up, extended it to use the latest Patriot dynamic device discovery, and posted the Swift source to Github.


The Possibilities of Patriot iOS Control Panels

So now that we have a system that allows old iPhones to communicate with our IoT system, what are some of the things that we can do to leverage the incredible power of these cheap devices? Here’s just a short list of some things that I’ve come up with so far:

  • Utilize BLE to detect the presence of certain other iPhones to monitor my comings and goings. Turn on lights when I get home after dark, etc.
  • Put a BLE tag on my car and motorcycle to track when they are at home or away or being stolen. Combined with the above…
  • Coordinate with Alexa commands to dim or display the panels.
  • Provide other views such as video chat, monitoring outside, etc.
  • Mount one of these outside to use as a doorbell with camera and audio intercom.
  • Use the back facing camera to perform motion detection, face recognition, etc. This one really has my head spinning. I intend to start looking into OpenCV to see about replacing simple motion and proximity detectors with just the camera mounted on the iPhones.
  • Motion detection and GPS: since my home is an RV, these may prove handy for a lot of things.

And the list just goes on and on. So this iOS code is intended as just a starting point. I hope others will get involved and contribute also.

Self Discovering IoT System

I’ve been working for a couple years now to automate my RV using a combination of Particle.io Photon micro-controllers, an iOS app, and an Alexa skill. This has been fairly easy to do, due mostly to the ease of using the Particle.io API. Over the next year, in addition to adding additional functionality and more Photons, I hope to add Apple TV and Watch apps. This got me to thinking about how to make the system easier to configure and extend.

Since I’ve written all the software pieces myself (iOS app, Alexa skill, Particle sketches), up until now I’ve taken the expedient route of just hard coding the names of each controller into both of the apps. With only a single iOS app and Alexa smart home skill, this meant updating those two programs every time I added a new Photon, or extended one of the existing Photons. Not a big deal, albeit somewhat inconvenient.

However, recently I created an additional iOS app to allow using older iPhones to be mounted to the wall and used as control panels. Hard coding the names of the controllers into the apps means that I have to manually update each device whenever there is a micro-controller change. Now this is becoming a much bigger inconvenience.

So I’ve converted each micro-controller to be self registering with the system:

  1. Each Photon publishes several variables that list the device names it implements, in addition to what ‘events’ it listens for. These variables are exposed by the particle.io API and used by both the Alexa and iOS app to dynamically configure themselves.
  2. All applications use this information, instead of having to hardcode a list of commands.
  3. This functionality is built into a published IoT particle library, so copy/paste is minimized.

So now instead of needing to reprogram the Alexa skill and iOS control panel apps whenever I add a new controller, I just need to expose the data about that controller as described above, and all the applications pick it up.

I’ve posting the Photon and iOS code to Github, so please take a look and let me know what you think.

Alexa Smart Home Skill

I’ve now replaced my previously created Alexa Custom Skill with an Alexa Smart Home Skill. I’ve been holding off doing this because of the difficulty of setting up an OAuth2 server. Recently I came across an article describing how to use Login With Amazon to do this though, and I have gotten that working now.

So now I don’t have to say the name of the custom skill when invoking Alexa. Using the custom skill, I would have to say something like “Alexa, tell My RV to turn on the computer”. Sheesh. Quite a mouthful. And easy to get wrong. But using an Alexa Smart Home skill, I now only need to say something like “Alexa, computer on”. This seems like a small change, but it has made a big difference.

I’m working on providing some instructions, and then I’ll post all this code to Github.

Update: I’ve now converted the skill from using the Login with Amazon to using the particle.io oauth directly, and I’ve published the skill. What this means is that it can now be used by anyone, and it will prompt you during installation of the skill to provide your Particle.io login to access your devices. Refer to my other posts and Hackster.io project for more details. I had initially call this ParticleIoT, but that was hard to say and spell so I renamed it Patriot which uses many of the same letters.

New Photon Based IoT PCBs

New IoTv2 PCBs

I’ve updated the printed circuit boards for my IoT projects. These boards are 5×5 cm and intended to be used in a variety of IoT applications. They include the following features:

  • Switch from linear voltage regulator to buck regulator.
    • The linear regulators used on my previous boards were getting quite warm as a result of converting the RVs +12 volts to +5 or +3.3v. I found some inexpensive variable voltage bucking regulators for about $1 each. These are marked “D-Sun”, readily available on Amazon.com, and they work well.
  • Provide direct pin-outs to LED driver boards.IoTv2 PCB with LED drivers
    • I’ve provided 4 sets of PWM pins that can interface directly with the Sparkfun 12959 MOSFET LED driver boards. I’ve positioned the pins such that standard header pins can be used to attach the boards instead of wires. I’ve gone back and forth about integrating the functionality directly, and finally concluded that the space used by the MOSFET and screw terminals was better pushed off onto small extension boards. Up to four of these can then be optionally added as needed. Sparkfun sells these for $4 each, so it’s sort of a no brainer. Putting them onboard would force me to moving to a larger 10×5 cm board, and only save a couple bucks.
  • Both 3.3v and 5v supplied
    • I’m using a 5v regulator to provide power to the Photon. It then has a 3.3v regulator for itself, and can provide 3.3v @ 100 mA to other sensors, etc. Since most of the Photons pins are 5v tolerant, this enables using both 3.3v and 5v sensors.
  • Provide groups of pins for ease of connecting other devices
    • To simplify adding additional sensors such as DHT11 temperature sensors, I’ve provided groups of pads that provide a GPIO, power, and ground. Some are 5v, and some are 3.3v. I was careful to ensure that the GPIOs provided with the 5v power groups are in fact 5v tolerant. These are great for things like PIR motion sensors, various switches, and so forth.

So after checking that the first batch of 10 boards work as intended, I’ve ordered another 10 and am in the process of replacing most of my existing controllers with these. While the Photon costs substantially more than the previous Arduino Pro Mini and RF24 radios, the ease of programming over the air combined with their robust design (5v tolerant pins, super stable operation) and included Particle.io support make these worth it!

I’m currently using my Echo and Dot to control these, but recently got AVS running on my Raspberry Pi and may throw that into the mix also.

If anyone is interested in using these boards in your own projects, post your request in the comments and I’ll provide links to the Eagle files so you can have boards made yourself. If you don’t mind waiting about 6 weeks, you can order these from itead.cc for $13 total for 10 boards. If you’re in a hurry, DHL shipping increases the total cost to about $26 total for 10 boards that arrive in less than 2 weeks. I ship with DHL for the first batch, then use the cheaper shipping to get more while I work with the first batch.

Note: I’ve now posted the Eagle files on Github.

Alexa does comedy

I’ve been playing recently with programming Amazon Echo’s Alexa to perform comedy. As a first proof-of-concept, I programmed it to do the Abbott and Costello “Who’s on first?” routine. This routine is very long: about 8 minutes with each performer saying about 87 lines. I was wondering whether Alexa’s speech engine could handle that many lines, and whether or not the programming could handle all the repeated lines; the sentence “Who” is said about a dozen times.

Well, the results were pretty good, and I’ve published the skill. It’s called “Who’s On First? Baseball Skit”. And if you have two Alexa devices, for example an Echo and a Dot, then you can have them perform both parts together.

Here’s an early video I made.

How to connect Echo’s Alexa to an Arduino


As mentioned in my last post, I have connected my Echo to interface with my Arduino controlled RV lights. And thanks to the Particle.io Photon, this was quite easy. Perhaps the toughest part about this process has been getting past all the unfamiliar language used by Amazon, such as “Lambda functions”, “Skills”, and so forth. The actual implementation was fairly quick and easy, as I’ll explain in this post and the accompanying GitHub project.

Who is Alexa, and what is an Echo?

In a nutshell, the Amazon Echo is a small electronic device that you can interact with using spoken natural language. It has directional listening capability that allows it to hear you talk even in a noisy environment; for example when you’re playing the TV or stereo. It responds to you after you speak the work “Alexa”.

Requirements for connecting Alexa to your Arduino

You don’t have to own an Amazon Echo to get started. You can design and build a voice controlled interface, and test it using the Alexa Skills Kit (ASK) Service Simulator. The simulator allows you to type in what you would speak, and responds exactly as the Echo device would.

You’ll need to join the Amazon developer program, and setup an Amazon account to handle the backend. Both of these things can be done for free.

I’ve posted all the details on Github. I’ll warn you though; the instructions appear quite long. But don’t be deterred. None of the steps are particularly difficult, and the results are amazing!

I’ve been sharing tips and ideas with my buddy Don. He’s setup his Echo to control his pipe organ clocks. You can check out his work on facebook or at donholmberg.com. There’s also a blog article on Mutual Mobile’s website talking about some of our Arduino projects before connecting them to the Amazon Echo.

I’m having a blast working with all this new technology, and its fun to be able to use it to enhance my RV lifestyle!