Possibly if something is a pre-requisite, perhaps at least a little info to help those (like me - While I have plenty experience of most things, I’ve never worked with anything AWS related at all before) who’ve never encountered it before. There’s quite possibly a lot of potential users who just give up on hasska as they may perceive it as being too difficult to set up. Things I feel should absolutely be mentioned:
That users behind router using NAT will have to port forward - you can’t be expected to provide guidance on how to do that, there’s just too many devices out there, but a mention that they will have to do it will give them some idea of what to Google
That unless users have a static routable IP address, they will need some form of dynamic DNS in place, and list a few alternatives
That users should seriously consider SSL
A little more/better guidance around the whole AWS/Alexa/Lambda side of things
Another thing to consider: There are people out there who don’t have a clue about how to set up or use a development environment. Possibly suggest to Mike that the project provides the deployment package as well as the source - I discovered that it’s pretty easy to edit the config file in the Lambda console.
Re: Prebuild - Yes, I’ll at least mention it (which will be in the form of a GH issue), if not create a Pull Request myself. I think it might just be a legacy thing to have it be built, so it’s always using the latest version of Requests (which is the only package we use).
Regarding the setup, I have instructions written now that take you through each click and tell you what to put in what fields, even if a text box is supposed to be left blank. I wonder how long this will last though - Amazon have a habit of changing their console layouts frequently.
For the pre-requisite page, if you have any text/steps you’d like to contribute, just let me know
I think this is useful even if Amazon changes the layouts. I suspect the information that needs to be entered will remain the same. The user should be able to figure out where in the new layout that same information goes.
In short, you’ll need to jump ahead and create the AWS Lambda function. Along the way an ARN is created for your AWS Lambda function, and it is this ARN that is used as the Skill’s endpoint.
Another heads up to anyone in this thread paying attention to Haaska. As promised, I’ve got a new set of instructions currently “cooking”. I’ve re-setup everything from scratch, so I could go through the process from start to finish (with the exception of making an AWS and Amazon Developer account).
Just going through some final changes, and then proofreading before pushing it to the master branch.
In the meanwhile to help with any questions or concerns, I’ve created The Haaska Super Thread. Please feel free to hop over there, so we can keep this thread clear for everything else.
If you are using the latest Haaska (v0.5), then you have to use the new authentication scheme in HA by getting a long lived access token, and in the json file instead of “password” use “bearer_token”
AWS Lambda is of course external and is trying to reach your Home Assistant, so you would use the URL that allows you to reach your Home Assistant from the external network.
Looks like you’re missing “requests” module.
Is there a “requests” folder inside your “haaska” folder on AWS Lambda?
If not, did you do a Make on haaska-master to generate a haaska-zip and then upload it to AWS?