It was a slow week at work and I’ve been playing with my new Amazon Echo Dot, so I figured I’d hook it up to my Kegbot. I can now say “Alexa, ask Kegbot how much beer is left?” and she’ll tell me.
This implementation is written as an AWS Lambda and requires your VPC to have a VPN or direct connection to your kegbot server, so I’m guessing most people will not find this useful. But it was a fun project for me to learn Lambda and Alexa Skills.
HOME SETUP:
If you don’t have a network set up to allow a Lambda to connect to your kegbot server, here is the code that can be used in a home setup:
The home setup will be easier, but not much. Instead of step 8 where you create the Lambda, you’ll have to make alexa-app-server externally accessible on your home internet connection.
Just got an Echo Dot. Definitely excited about this!
A couple of clarifications:
The DNS1 entry in 4.iii.d, is this supposed to be my FQDN? For instance: coloradoicculus.noip.me?
The port you’re suggesting on poking in the router, is this supposed to be the same external and internal? For instance, my kegberry is 192.168.2.12 and the port is 8443. Should the external port also be 8443?
When I run the node command, is there any output I can expect? Currently it seems to try to run and stop right away. Sorry, I’m new to Node. It doesn’t seem to be accepting connections, either if I am getting to it via 127.0.0.1 in Lynx, or 192.168.2.12 from inside my router.
For consistency and ease, it’s probably best to keep it the same.
It should output something. For example here is my output.
alexa@bent:~/node_modules/alexa-app-server/api$ node server.js
Serving static content from: public_html
Loading server-side modules from: server
Loaded /home/alexa/node_modules/alexa-app-server/api/server/login.js
Loading apps from: apps
Loaded app [alexa-app-kegbot] at endpoint: /alexa/Kegbot
Listening on HTTP port 8081
I’m running mine on port 8081. I’m not a node expert either. What version of node are you using?
FWIW, yesterday I successfully deployed the Lambda version of the Alexa skill.
Everything went pretty smooth, but there were a few updates to the instructions found on the Github README:
Step 7 should be: "Clone Repo: git clone https://github.com/patfreeman/alexa-lambda-kegbot.git. Currently the URL is incorrectly listed as github.org.
I’m not sure if it’s something new with the “config” npm package. But it’s now looking for the config file under a separate config directory with the name of “default.js”. Here’s the tree of the project I zipped and uploaded to AWS
.
├── config
│ └── default.js
├── node_modules
│ └── [Dependencies installed by NPM]
├── index.js
├── package.json
└── package-lock.json
For the current methods, the API key is NOT required by default. Doesn’t hurt to have it, but not required to access the api/taps endpoint
It appears that it’s required to perform the ZIP operation on a linux box zip -r lambdaFunc.zip . from within the directory with the files. I tried to use the Windows “Send to Compressed (zipped) file” but that did not work. Perhaps a separate app like 7-zip or WinZip would zip it correctly.
When I configured my AWS Lambda application, I had a lot of trouble with the VPC configuration. It turns out you do NOT need to configure a VPC for the Lambda function to work. Just leave the Network configuration set to “No VPC”
It’s been said before, but in order for this to work you will need to have some type of public internet access to your Kegbot Server.
There were a few other items that I tweaked since Amazon has updated the interface for both Lambda and Alexa Skills development but they were pretty self explanatory. I can certainly help if anyone else tries to get this working.
Definitely happy to help, send anything you have and I’m sure we can get this up and running.
As far as the API key, it looks like it is based on the Privacy Setting configured for you Kegbot Server. I currently have mine set to Public so the API Key is not required to hit the /api/taps endpoint. If you have any other privacy setting configured, the API key is required.
I will edit my current Pull Request on Github to include that information.
edit: Using nodejs 8.1 on my server, changed to 8.1 on the lambda application but no difference.
I don’t really understand the architecture here…
skill talks to lambda which sends the request direct to kegbot? if so, why does it matter what version of node is installed?!
edit again - after installing sdk and other packages I see the zip file is now much bigger so am assuming it bundles up files from the install locally. Will see what I am missing
All of this looks good, and it’s pretty much “working” if you’re getting that “Unable to connect message”, but I believe you’re facing the issue with the config package since as I mentioned in my comment it’s looking for a file within a separate config directory with a file called default.js. My gut feeling is that it doesn’t see the config file so it’s actually not picking up the URL from the config file. Hopefully my pull request with updated instructions will get merged into the main github repo soon, but in the meantime try this.
In your root project directory, create a new folder called config
Move your current config.js file into that folder and rename to default.js
Back in the root project directory, just run node index.js. You shouldn’t get any output, but you also should not get any errors. In my case npm install did not get the “config” package that’s required.
Create the zip file again. In my case, the full zip file size was about 6.38MB.
Re-upload the zip to AWS Lambda and run the test.
If you go to the github repo for the lambda function and look under Pull Requests, you’ll see my updated instructions as well as a script for testing from within the lambda function itself.
As far as architecture, you’re absolutely correct. The Alexa skill fires the Lambda function which makes a web request directly to your kegbot to get a response. The function formats that response into a phrase and sends back to the Alexa Skill which converts to speech and reads back to you. As such, I don’t think the Node version really matters. I’m actually running Node 10.1 on the box I use to configure and zip the files, but leaving set to 4.3 on the AWS side works fine.
