@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 
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”.
Thanks for your help!
I just tried to get it working yesterday, so I began to start over from the beginning.
And Indeed! I missed the “Redirect URLs” the first time, and it seems I inserted the wrong URL’s then. It already wasn’t making sence.
So I’m able to get it enabled and linked into Alexa without error’s now! 
I also solved the part of the “make” command. I was missing a “zip config” in my GNU environment. So I was able to follow the whole tutorial of the Wanderer now.
I only having problems with the detection part now. So still something’s off here.
But again, manny thanks for your help! 
Just to be sure…
I had a working hassio environment with a few working Tasmota plugs. They where communicating together on the local IP where hassio was running.
Now that I’m trying to setup haaska (which is working via an DDNS (duckdns). Everything is still working while the plugs are still directed to the former local IP adress where hassii was running. It is still accepted and working.
But I was wondering if this could be possible the reason that my devices are not recognised via my haaska setup in Alexa?
Should I let them on the old local IP? Or should I change the URL’s in the Tasmota setups to the same duckDNS url?
Edit:
Ok, just was able to try it out. But setting Tasmota MQTT setup to the duckdns port doesn’t seem to work at all, even isn’t responding to the switch in hassio. So guess I just have to leave it on the local IP
Maybe I’m misunderstanding the problem you’re running into,
but Haaska is only trying to talk to your Home Assistant, not to your Tasmota devices
so you don’t need to change any IPs for Tasmota.
If I understand, your Haaska is not discoverying any devices from HA.
Did you ever run the test on Haaska at your Lambda that Wanderer mention?
(See Testing Haaska · mike-grant/haaska Wiki · GitHub)
I presume you also put in your configuration.yaml
alexa: smart_home:
and lots of other goodies like filter: include_entities:
Thanks again! 
Well I tried to run this test, but I was not sure if I had to edit annything. I only got a lot of errors with everything I tried. So I gave up a little bit on that. Because I wasn’t sure if I was running this test correctly.
I followed everything verry carefully the seccond time, and I was pretty sure I didn’t missed annything this time. So I was thinking it could only be something small (at least I hoped).
Because hassio was now directed via DuckDNS, it sounded logical to me that this could be the reason at that point. Because now I had to acces hassio on my py via “https://duckdns.org:8123” instead of “local-IP:8123”. So I thought maybe it could be possible that alo had to direct Tasmota via DuckDNS. My Tasmota devices where still responding on my hassio which was running via DuckDNS though. But just gave it a try to be sure. But after this, the Tasmota plugs didn’t respond annymore when I changed the host. Which was to be expected somehow haha.
It turned out I made a mistake with the layout of the JSON-file which prevented Alexa to dicover my devices. I’ve tried to explain it here
HI Everyone
I’m in the process of updating my HA, I’ve been running 0.49.1 with haaska and all works great. I’ve slowly been getting things working with the latest HA 0.86 at this point. I have got everything working OK now I’ve been working on haaska.
I dowloaded the latest haaska, Create long-lived access tokens, changed jason.config, zipped, uploaded to lambda tested and got this result
"errorMessage": "404 Client Error: Not Found for url: https://xxxxxxx.duckdns.org/api/alexa/smart_home",
"errorType": "HTTPError",
"stackTrace": [
[
"/var/task/haaska.py",
109,
"event_handler",
"return ha.post('alexa/smart_home', event, wait=True).json()"
],
[
"/var/task/haaska.py",
63,
"post",
"r.raise_for_status()"
],
[
I created new lambda functions and alexa skill for this so I can still use my old one until I get this up and running
Thank you
Is it possible, that haaska does not work with IPv6?
I have two hassio instances, one IPv4 and one IPv6 and haaska does only work on the IPv4 one.
Can somebody confirm or refute this?
Error:
"errorMessage": "HTTPSConnectionPool(host='mydomain.com', port=443): Max retries exceeded with url: /api/alexa/smart_home (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f4aed26ec18>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))",
Was excited to set this up only to encounter this blank page, and a bunch of outdated confusing documentation in older instruction sets:
All - I’m very sorry for the incomplete documentation. As always, life has gotten in the way, and to top that off, I got involved with another project that has some 2M+ Docker Pulls in the past two months alone.
I still answer issues on GitHub when possible.
It’s a long weekend here in Canada, so I will finally have time off work to help with this.
Any questions, just send them along. I’ll help set things up.
Hi folks,
It’s 3:18 am here in the UTC -5 timezone. I’ve just uploaded a much bigger, revamped set of pages and instructions to the Wiki. There’s just two pieces left to complete - Using Haaska, and troubleshooting.
I hope this works for all: https://github.com/mike-grant/haaska/wiki
@Outsideheaven - I apologize for the incomplete documentation. I’ve just finished writing a great deal of it. Would you consider trying again?
@Zoker - I know we spoke briefly on a GitHub issue, but to confirm - it appears AWS Lambda does not support IPv6. Here are some links: 1, 2, 3, 4.
@Dee - The URL in your config needs to be shorter. If you’re using the latest haaska, then you only need: “https://xxxxxxx.duckdns.org”. If you’re running Home Assistant on the default port, then it would look like “https://xxxxxxx.duckdns.org:8123”.
1 Like
can you help me with this?
I got done Upgrading from HA 0.49.1 to 0.86.3 I finally got everything working.
Haaska done and working except my Intents in Home Assistant.
I had a alexa.yaml file in my HA 0.49.1
I’m not sure how to format it under the smarthome structure, I have been using my alexa.yaml file looked like this
alexa: !include alexa.yaml
In there it looked like this
intents:
ActivateSceneIntent:
action:
service: scene.turn_on
data_template:
entity_id: scene.{{ Scene | replace(" ", "_") }}
speech:
type: plaintext
text: OK
WhereIsCarIntent:
speech:
type: plaintext
text: >
{%- if is_state('device_tracker.dee', 'home') -%}
Dee is at home
{%- else -%}
The car is at {{ states("device_tracker.dee") }}
{% endif %}
RoomTemperature:
speech:
type: plaintext
text: >
{%- set temp = states('sensor.dark_sky_temperature') | round -%}
{%- set bed = states('sensor.bedroom_temperature') | round -%}
{%- set bed_h = states('sensor.bedroom_humidity') | round -%}
{%- set t_hi = states('sensor.dark_sky_daily_high_temperature') | round -%}
{%- set t_low = states('sensor.dark_sky_daily_low_temperature') | round -%}
{%- set feel = states('sensor.dark_sky_apparent_temperature') | round -%}
{%- set humid = states('sensor.dark_sky_humidity') | round -%}
{%- set now = states('sensor.dark_sky_summary') -%}
{%- set hourly = states('sensor.dark_sky_hourly_summary') -%}
{%- set daily = states('sensor.dark_sky_daily_summary') -%}
{%- set wind = states('sensor.dark_sky_wind_speed') -%}
Right now, it is {{ temp }} degrees Out side
{%- if temp != feel -%}
but it feels like {{ feel }} degrees
{%- endif -%}.
The current humidity is {{ humid }}%.
Right now, conditions are {{ now }}.
For today, {{ hourly }}.
Today's high is {{ t_hi }} and the low is {{ t_low }}.
The wind speed is {{ wind }} miles per hour.
The forecast calls for {{ daily }}.
LivingTemp:
speech:
type: plaintext
text: >
{%- set lvrm = states('sensor.livingroom_temp') | round -%}
{%- set lvrm_h = states('sensor.livingroom_humidity') | round -%}
Right now, it is {{ lvrm }} degrees in the living room.
And the humidity is {{ lvrm_h }}%
Everything works I can turn on and off lights, open/close my blinds,
I’m not sure how to format it under the smarthome structure,
alexa:
smarthome:
and would like to keep using the, !include.yaml if I can
Thank you
@Dee - Hello 
I’ll take a look at it, but as a warning - I’ve never used Intents. Worth trying though!
I do use a few Includes in my YAML, but I haven’t tried it around the Alexa stuff. Will test that too.
1 Like