The Haaska Super Thread

I wonder if @gregma could go through the skill set up and creation steps on both accounts, in theory I think that would work without issue?

It might I haven’t tried it. If both accounts shared the same access keys in HA then it should work fine. However, that’s two places you have to maintain code. It would give you a bit of customization though.

@sloth @crzg Not entirely sure what’s happening… When you run the test in the Lambda console, the result shows all your devices?

Hi @anthonylavado - yes that’s right! All show up.

There are 183 entities in total that show up in the Lambda test. Possible I have exceeded the limit?

I note that in the older Haaska there was an option to change expose_by_default, is this possible here? Tried myself using snippets of the auchter code but didn’t seem to work.

Thank you!

This doesn’t seem related to some kind of entity limit, as I have introduced a filter to include only one entity in my configuration.yaml file. The device shows up in the log file, but is not discovered by the Echo Dot v3.

Relevant part of my configuration: https://pastebin.com/w2FnqHdw

Log output (results returned from “Alexa Discovery” test event from documentation)
https://pastebin.com/t7316fm8

Logbook entry from the test event: https://i.imgur.com/pZL0JwO.png
Access.log entry from nginx: https://i.imgur.com/0K6V2ZS.png

@sloth - I am guessing you are based in Europe - I am in Ireland, perhaps some issue with Europeans that isn’t cropping up elsewhere?

Realise that there is guidance around European users (I previously had it working, have all accounts listed in Ireland, as is the Lambda function, skill language is set to English (UK)) but perhaps something finicky there?

How would I test whether the skill is successfully invoking the Lambda function? I used the debugger in the skills console after asking for device discovery - not sure if this is the right way to check but it shows up as skills: null under payload

To circle back on this - it sounds rather obvious but equally an odd quirk in Alexa/Lamdba

Although I am in Ireland and had the skill set up in English (UK), if I link the Alexa skill with a Lambda function that is created in Europe (Ireland) as suggested… it does not work… once I swapped over to US East (N. Virginia) everything now works.

I find this very odd - particularly because Amazon itself says here that you need to match the AWS region to the skill language… however it seems to have nothing to do with the language on the skill (I have tried English (UK), English (AUS), etc. on the skill and they all work), but rather the address on my Amazon account. So if I am right… Irish users cannot use the Irish AWS region… seems odd!

Not sure if this helps anyone else, and maybe for some odd reason this only affects Irish based Amazon account holders… but hopefully it saves someone hassle

@sloth - not sure if this is any help to you, realise it sounds like you’ve done some similar troubleshooting, just in case you didn’t adjust the endpoint region within the skill when you were going back and forth on the Lambda function. Changes I made:

  • Made sure that my personal Amazon account and developer accounts were all in the same country (Ireland)
  • Lambda function: Created duplicate function in N Virginia
  • Alexa Skill: Changed the default endpoint to the N Virginia function and changed from Europe, India to under the “Pick a geographical region that is closest to your target customers and setup geographic specific endpoints:” section

1 Like

Was’nt too painful to set up.
But now I have 270 new devices :see_no_evil:
should have first set up the config lol

I hope that the wiki ll be a little easyer to follow
I had often to scroll back and look waht i did in step 5.6.27

Does this works with the Alexa app for ios?
I’ve all setup as per instruction by the Wanderer blog and in the aws console the test pass without error and gives me all the devices from home assistant.
But in the ios app I activate the skill, connect the account, but when it search for new devices it doesn’t find anything.
Am I missing something?
thanks

Hello,

I have a question :slight_smile:
i have successfully follow the guide here to setup Haaska with Home Assistant (http://collingwood.me.uk/blog/index.php/hass-io-and-alexa/)
I have tested it (https://github.com/mike-grant/haaska/wiki/Testing-Haaska) and it works.

I have in my house a Roborock, configured with some scripts in HA to clean specifics rooms.

How can I link Hasska with HA and Roborock + Alexa ?
Can I launch Roborock to say : Alexa , launch Roborock to clean the kitchen ? (if kitchen is identify (I don’t know how yet))

Thanks for your help!

Nevermind, I had to select Ireland as region for the lambda function.
Now it’s working.

I’m been using Haaska for a couple of months now, and thought I would add my binary sensors but they are not being discovered. To make sure the discovery was still working, I added a light and the light does get discovered. This may not be a Haaska issue, but thought I’d ask if binary sensors are supported?

@wmaker It’s all dependent on Home Assistant sending out as a device for Alexa to read from. I thought they had enabled “switch” as the basic fallback type, but I could be wrong. Let me look.

So motion sensor support was added as of 0.82:

They should work and should show up.

I figured it out (had to take a look at the smart_home.py code in HA).
It has to figure out how to categorize a sensor (for Alexa) as CONTACT or MOTION sensor.
It Looks at a sensor’s device class, and only looks at a limited number of device classes:

if attrs.get(ATTR_DEVICE_CLASS) in (
        'door',
        'garage_door',
        'opening',
        'window',
):
    return self.TYPE_CONTACT
if attrs.get(ATTR_DEVICE_CLASS) == 'motion':
    return self.TYPE_MOTION

My binary sensor was not any of these device classes so it wasn’t discovered.
Once I changed its device class to “opening” then got discovered.

1 Like

I retry here :slight_smile:

You set it up the same way you set up any device but you’ll need to set up a routine in Alexa to trigger it with a statement like that.

I was bussy the whole day trying to get haaska up and running. I was following these instructions of The Wanderer, since the instructions of Anthony Lavado unfortunately seems to be still incomplete.

But I got stuck at the point of using the “make” command to make the haaska.zip file, resulting in figuring out how to get this “make command” work in Windows for half a day. I gave up on it after a lot of diffrent approaches and the same amount of failures.

But then I came across this section of Anthony Lavado, which give new hope, where the compiled *.zip file was to be downloaded. So I downloaded this file to use in the further installation process.
But when finally finished, I realized that this file could never hold the following information of my setup:

{
“url”: “https://<your subdomain from step 2.2>.duckdns.org/api”,
“bearer_token”: “<the token you created in step 3.1>”,
“debug”: true,
“ssl_verify”: true,
“ssl_client”: []
}

So I edited the json file in the zip file and saved everything as the same zip, but now with the edited json-file. And followed the instructions part considering uploading the zip-file again.

The haaska skill is visible in my Alexa account. But I get the following error when trying to enable it:

Error Summary
400 Bad Request

The redirect URI you provided has not been whitelisted for your application. Please add your redirect URI in the ‘Allowed Return URLs’ section under ‘Web Settings’ for your Security Profile on Amazon Developer Portal.

So I got a bit stuck here…

Hello @Bobby_Nobble !
I thought it was possible to use it directly like that :
Alexa, turn up <Device Name> to <Position>
And say it like that : Alexa, turn up Roborock to Kitchen

The routines works well, but you cannot say all that you want (for eg , the word Roborock is not very well handle in routines)

I’m not sure, but the Error Summary suggests the Allowed Return URL is the problem
and this maybe because the Redirect URLs were not generated and populated correctly.
I think this is Wanderer’s step 6.22.

So somewhere in the Account Linking Step (I think this is Wanderer’s step 6.21), there should be
“Redirect URLs” that should be copied and then pasted into the OAuth Providers “Allowed Return URLs”.