I currently use the emulated hue component because it was easy as pie to set up. Now that I have that set up I’ve been working on making my own intents and custom skill so that way i can say things like unlock the front door instead of turn off the front door, plus I can also get my alexa to read out my sensor values. The only real downside that I can think of for this method is that you have to use the extra invocation name. As far as the emulated hue component getting depreciated goes it’s been saying that for quite some time now. I would suggest using it while you set up your hasska or custom intents
Wait, what? Emulated Hue might be disappearing? I’ve loved using it!! Guess it might be time to look into the Cloud component then 
Ok so I went back over the emulated hue component docs and it appears to just be one of the configuration options that was removed. They added the new google assistant component so it pretty much just makes it pointless for google home users to use the emulated hue component now.
Phew!! Was getting worried there for a sec 
2 Likes
It has been useless for Google users for ages due to changes Google made, nothing to do with HA.
1 Like
try changing the invocation name for each skill you want.
one of my invocation names is “me the status” so I can say , Alexa, tell me the status of the front door
1 Like
In home assistant my lights (dimmable) are listed as lights and not switches. What would I have to change in the template nodes code to make it work? My programming skills are very limited. Your assistance will be highly appreciated.
just wanted to add that you can now accomplish some of this with emulated hue + routines in the alexa app. let’s say you have script called “unlock the front door.” in the alexa app you can create a routine that maps “unlock the front door” to “turn on unlock the front door to 50% brightness” (they’re all dimmable lights in emulated hue, but the brightness is irrelevant). so you don’t need custom intents to be able to say “alexa, unlock the front door,” and you don’t need an invocation name.
How do I go about resolving the “undefined” response in the _SessionSpeechlet - Requesting Home Assistant to turn undefined on ? The light does switch on and off.
Is the HA Cloud available to run on your own, i.e. personal cloud instance?
Also, I believe with openHAB Alexa skill, they got around the invocation word. I haven’t yet take a close look at how they did it differently than this other that they use HomeKit bindings:
Items are exposed to Alexa through the use of tags which follow the HomeKit binding tagging syntax
Yes you can do it DIY, use the latest v3 api compatible version of Haaska which in essence is just creating your own ‘test’ Smart Home Skill with all the hard work already done by the devs. You then link your ‘test’ skill in the Alexa app and away you go. As it’s a Smart Home Skill there are no invocation words.
Set up in HA is identical to the HA Cloud version other than you don’t put cloud: before alexa: in your config yaml. You shouldn’t need to do anything to the skill side once set up and it will have exactly the same features as the HA Cloud version.
I did it the other night in an hour whilst watching telly and it works perfectly.
3 Likes
How did you set up the config.json? I am trying to set it up using let’s encrypt and duckdns, but every time I run the test in AWS I get a 404 error?
Exactly as per the instructions, url set to https://my_domain.duckdns.org:8123/api
Was a while ago now but I have a feeling I had the same issue until I specifically added something for it to find so you have to set up Home Assistant config something like…
alexa:
smart_home:
filter:
include_domains:
- lightGreat, I think that may be the issue (the specified entities). Do you remember if you did anything with the ssl_verify and ssl_client in the config.json? Thanks!
More I think about it the more I’m sure it was that.
This is all that’s in config.json…
{
"url": "https://my_domain.duckdns.org:8123/api",
"password": "my_ha_password"
}Ok great, I will give this a try tonight. And just to be certain, you removed the ssl_client and ssl_verify and it didn’t cause any problems with let’s encrypt?
Where are you talking about removing them? They’re in my config.yaml as that’s how you expose HA to the outside world using a letsencrypt certificate via the duckdns add-on but not anywhere else.
Sorry, I am referring to the instructions for installing haaska v3. In the config.json, there are two ssl values in the file, ssl_verify and ssl_client. Ssl_verify is set to True in the sample file, but the docs refer to a certificate going there. I guess that is where I was getting confused
Ah…with you, just checked the instructions and guessing this may have been in the revisions done to that page since I did mine, I do recall it was related to the old version of AWS so had to adlib a few bits, don’t know if it still is. Either way, what I posted above was all I had in my config.json and it’s still working perfectly.
If you have letsencrypt set up correctly, I would’ve thought the certificates should work just like the HA front end and not need any other reference, perhaps the option is just meant for specific use cases not using external certificates.
Thanks! I was able to get it to work. For anyone that finds this in the future, I needed to set up the alexa component with the domain filter and then in the config.json, I used https://myduckdns.org/api as my url and left the ssl_verify and ssl_client alone. Thanks for the help!