Indigo and the Amazon Echo

The Amazon Echo is definitely a game changer in many ways, including how you can interact with your smarthome. After testing an Echo and digging through the beta Alexa API docs, we see great promise. We were hoping for a quick, short-term win, but unfortunately the shortcomings in the current beta API aren't going to make that possible beyond what’s already been done. The work that Matt Reynolds and others on that thread has made Echo integration possible, albiet with some pretty non-trivial technical setup requirements. We've looked at this work and it's great. But again, unfortunately, it only helps us get partially to an official and easily configured solution, again because of limitations in the beta Alexa SDK.

We would like to outline the problems here - not to dismiss an official integration, but rather to help you understand why one is not going to happen quickly.

Problem One: Alexa Skills API Configuration (or lack thereof)

The first problem is that third party Alexa skills (sorta like an app or plugin for the Echo) have no ability to provide users with a user interface to configure them. This means that there is no way (at skill activation time) to collect the information necessary to connect to a user’s Indigo Reflector (reflector url, username, password). Without that information, Alexa has no idea how to communicate with your Indigo Server. The current integration works because it requires that you hard code that information into the actual JavaScript code before you upload it to Amazon (well before it’s added to your Echo). For a generic Indigo skill to work, we need some way for the user to configure those values at the time the skill is added to your Echo.

Now, as it turns out, there is one way to collect some information from a user at the time the skill is activated on your Echo, and that’s through an authentication mechanism called OAuth. OAuth allows one website to have users authenticate against a different server to access a service. For instance, if you’ve ever used a website that’s using Facebook or Yahoo for authentication (perhaps for comments or something), then you’ve used OAuth. The originating website temporarily redirects you to Facebook or Yahoo to authenticate, then you get redirected back to the originating site.

When OAuth returns to the originating website, a token is returned that can be used in future actions to authenticate against the remote user database. Ah ha! If we could get your Indigo Server’s username and password into an OAuth system somehow, that might help us, right? Unfortunately, there’s a problem with that.

Our Privacy and Security Philosophy

When we developed the Indigo (aka Prism) Reflector, our goal was to make it as secure and private as possible. We’ve done this by making the reflector just a secure tunnel between the user’s client device (Indigo Touch on iOS or web, DomoPad on Android, Roomie Remote, etc.) and the user’s Indigo server. The reflector knows nothing about the authentication credentials you set up in the Start Local Server dialog in Indigo. We did this for obvious reasons: if our servers were ever compromised, it would not enable anyone on the Internet to connect to your Indigo server and mess with your house. We’re quite proud of this technology, which none of our competitors offer.

Unfortunately, it turns out that this lack of a centralized user access credentials is one thing that’s holding us back from doing a generic Indigo Skill. A skill can define a single OAuth server to authenticate against. That won’t work for Indigo currently because authentication takes place against each individual Indigo Server/Reflector. And, remember, there is no way to tell the Skill what that server is. So, what we need is a single OAuth server where all Indigo users can authenticate.

We have the Indigo Account system in place already, where you subscribe to the Up-to-Date/Reflector subscriptions, etc., but also recall that it doesn’t know how to authenticate against your Indigo Server (which makes it very secure). Since our servers, which would be required to host the OAuth server, have no direct access to a your Indigo Server, we would have to change our policy and/or communication methods between our hosted servers and your Indigo Server. Further complicating things is that a user’s Indigo Account isn’t necessarily a 1:1 with an Indigo Server (some of you have multiple servers for various homes).

While we believe all of this is doable, it’s not something that we can do quickly, nor do we want to. We want to take the time to make sure we understand all the security implications so that we can make the experience as safe and secure for users as possible.

Problem Two: Skills API is Static

The beta Alexa API is very static in a variety of ways, which makes it difficult to develop a generic solution for all Indigo users. In newer API versions, it has become more clear that it’s relying more and more on what’s called sample utterances to more correctly understand what a user is saying to the Echo.

Unfortunately, those sample utterances can’t be dynamically modified (outside of the Lighting API which we’ll talk about next), a reliable generic solution seems pretty much impossible at the moment. In the current integration, you create your own sample utterances file which you upload at the time you’re uploading the skill to Amazon’s servers (again, well before you activate it on your Echo). This makes it work well for an individual’s system, but doesn’t allow a generic solution work nearly as well.

We suspect that this will be improved by Amazon (maybe when it comes out of beta), given the amount of comments on their forums about this, but for the moment it is what it is.

Problem Three: Lighting API is more Dynamic, but Limited

The Lighting API, which is something of a subset of the broader API (both still beta), will allow for more dynamic speech recognition for device names, which is great. The downside to the Lighting API, though, is its limitation in terms of what it can do. Realistically, it can just do on/off and an arbitrary level (numeric). The current integration allows you to execute action groups and get the value of variables - none of this is available in the current beta Lighting API.

We suspect that Amazon is working on expanding the Lighting API (or adding more subsets like it). That will help, but again for the moment it is what it is.

Summary

So, to summarize, we believe that a generic supported Amazon Echo integration would be a great addition to the Indigo platform. Getting to a general purpose Alexa Skill, given the current beta APIs, will require a non-trivial amount of work, including a rethink/redesign of our Reflector service which has significant security implications. The ASK (Alexa Skills Kit) is still in beta and somewhat on the bleeding edge. We hope that by the time their API comes out of beta, some of the issues will be resolved. However, we will also be closely investigating the various workarounds described above (and others as we discover them) for the Indigo 7 release.

In the meantime, we've released an open source plugin that allows you to control up to 27 Indigo devices via the Echo (and other Alexa devices). We do it by masquerading as a Philips Hue hub (which is why there's a 27 device limit). It works nicely as an interim solution!