I’ve publicly released my Alexa-HA Skill on GitHub. This provides verbal I/O to control your OpenHAB server/items using voice via the Amazon Echo. Key features include:
Switch devices/appliances/lights/etc
Set light colors individually, by room or group
Control light dimmer levels individually, by room or group
Set thermostat target temperatures
Change between various scenes/modes (i.e. home/lighting/security/etc)
Get current states (i.e. temperature/humidity/luminance, power consumption, etc)
Trigger custom server side rules and return a response which is spoken by the Echo (i.e. say ‘watch a movie’ automatically sets up your Home Theater by powering on the Projector/AV Receiver/HTPC, lowering the Projector Screen, dimming the lights, etc.)
Research virtually anything via voice through Wolfram Alpha API
Display customized ‘cards’ in the Alexa App
Automatically generates the Skill ‘utterances’ based on configured devices/rooms
Crude support for Text-To-Speech ‘announcements’ by pairing the Echo with your HA server over Bluetooth
Regarding npm, it was an extra step for me on Linux, but if you have it after installing Node (i.e. can run npm from the command prompt) then you could safely skip installing it separately as mentioned in the instructions.
Thanks,
Just to be clear, what is needed to be installed on the rpi itself and what can be installed on my normal pc, i.e what is happening in the cloud and what happens on the openhab server?
@skatun,
Depends on your how you want to deploy it, but I’d recommend the ‘Proxied through a webserver’ approach (i.e. Echo -> AWS ASK -> Apache/Nginx -> NodeJS -> HA). I wouldn’t recommend installing the required Alexa-HA services on your normal PC (or your OpenHAB Server!), but rather a separate 24x7 server if available. While you can likely install everything on your Rasberry Pi along side OpenHAB, its better to have a separate public facing server handling these requests for improved security.
So in this case, the following happens in the cloud:
Echo request processing
Alexa-HA ASK Skill is hit
AWS issues request to your public facing SSL endpoint
Your server then hosts Apache/NodeJS/Alexa-HA:
Runs Apache, receives the request and proxies it to NodeJS
NodeJS processes the request using the Alexa-HA application code
Alexa-HA figures out what to do, and issues the command(s) to your OpenHAB Server’s REST API (on your RPI)
Any way to get node to run server.js on a specific IP? Right now when it starts I look in netstat and its bound to everything. I am trying to get it to bind to just the private IP of the box on port 30000.
@sipvoip - My first thought was to edit server.js, but it seems Alexa-App-Server does not provide a configuration option to control the listen address, only the port. It depends on Express, and Express does provide a way to define the listen IP. Experimenting with this now! If we can’t find a solution I’ll raise a feature request to Alexa-App-Server’s author…
@sipvoip - Unfortunately this doesn’t seem to be doable without a change to Alexa-App-Server. I did however find a hackish way to do it by combing through AlexaAppServer.start() code in index.js.
Find line 218 and change:
self.express.listen(config.port);
to self.express.listen(config.port,'10.71.129.1');
userId: A string that represents a unique identifier for the user who made the request. The length of this identifier can vary, but is never more than 255 characters. The userId is automatically generated when a user enables the skill in the Alexa app. Note that disabling and re-enabling a skill generates a new identifier. Type: string.
I must have pulled it out of my request logging during development, and assumed it was static for my Echo! Filing an issue on this now and will get it fixed soon in the code. In the mean time, as a workaround, please modify Alexa-HA index.js, line 48, and comment out this block.
if (request.sessionDetails.userId != config.userId) {
response.fail("Invalid user ID");
console.log('Invalid userId: ' + config.userId );
}
You will still be well protected by the applicationId check, which is custom to your ASK App!
While we are talking about that, is it a big deal just to support https in alexa-app-server? Right now I am messing with trying to get apache to talk SSL on public IP:30000 and then forward non SSL to private IP:30000. I don’t get having the apache server in the middle when express already supports https.
That is definitely doable. Have a look at AlexaAppServers SSL support - should even work with a self signed cert as long as you upload it to your AWS ASK.
For my setup I already had apache with a trusted cert, which is why I ended up proxying it through that public server to Node…
Progress, figured out how to get SSL working on port 30000 without screwing up my other hosts, I added Schema and both Slot Types and then Utterances and clicked next and got:
Error: There was a problem with your request: Incorrect syntax for the slot '{-|Location}'. Each token must consist only of alphabets, white-spaces and valid punctuation marks. Valid punctuation marks are periods for abbreviations, possesive apostrophes and hyphens. Occurred in sample 'Switch to turn {ON|Action} the {light|ItemName} in the {-|Location}' on line 1.
OK, you need to apply these changes to alexa-utterances module, mentioned in the documentation here:
Apply a temporary patch to alexa-utterances (which was installed as a dependency for alexa-app), required to support the CUSTOM SLOT types - should not be necessary after the next release of alexa-app!
