Now that is a great idea…
If it was self-hostable, but also they could just run it for you for a fee.
There is a sizeable part of this community that does not want external cloud-hosted solutions, so yeah…
I’m sure the mods are watching for (ahem) reasons, so maybe someone will see such a suggestion.
I will take the liberty to clean-up this thread. As @masterkenobi said: Stay on topic.
We know that the topic is an emotional one but there is no need for certain behavior or violating the code of conduct. Thank you.
Yes, the topic went off course.
Are you aware of any plan of making the cloud server open source?
That will solve any problem of premium that would be only available to the one who pay, while offering a simple setup for user that does not want to manage duckdns/letsencrypt/…
That is one (of many) unanswered questions about the new cloud service.
Once I start paying for a service I would like to know what to expect for example from a security point of view, privacy, up time, support etc.
@sjee I agree that this is the problem with paid solutions. There is definitely an expectation for security, uptime, technical support, etc. And this is one of the issues I have with the new Cloud feature. I wish there was a way to contribute but not feel obliged to auto hit my credit card every month. Hopefully the silver lining will be a new open source custom skill will be available as an alternative that is fairly simple to set up. I guess we have 2 months before our free cloud accounts are deleted. 
You geolocationist!
I haven’t checked all the Haaska forks yet to see if anyone else has started moving it to v3, but I’ve set one up with the intention of doing so.
As I’m a Python novice, I’ll be slow to start contributing myself, but I will maintain the repo (issues/PRs) to the best of my abilities.
You can go to it here: https://github.com/anthonylavado/haaska
Now if we could only get @auchter to set a license for his repo, so we know how this should be licensed as well…
is there a way to create a virtual component that can be controlled by Alexa (a virtual light maybe), over the emulated hue add on, that could be used to automate a task.
So you ask Alexa to " turn on cinema mode" where “cinema mode” is a virtual light. Then you could create an automation: When cinema mode=on, turn on the tv and turn off the lights.
Is this a thing you can do?
Emulated hue can always do that. Just create a scene in HA and expose it in emulated hue.
The only reason why I don’t want to use emulated hue is because it exposes every devices as light type. This is not ideal for users with echo in multiple rooms. With emulated hue, I have to say the full device name such living room TV, bedroom TV, living fan, bedroom fan, etc… If it can differentiate each devices by different types, then I can add them into respective alexa-enabled smart home group and simply say light, fan, TV, etc… and it will know which device to turn on/off.
Unfortunately Haaska and node-red also expose every devices as light type as well. HA Cloud seems to be the only one getting it right. But it only works for light and TV at the moment. Others like fan, speaker, air conditioner are not yet supported.
I have been wondering, why can’t we have smart home skill hosted on our server without using AWS Lambda?
I got my receiver to show up as a speaker in the Alexa app using the available settings in cloud. alexa_display_categories: SPEAKERS
But can you turn it on by saying “Alexa, turn on speaker” if you have multiple devices with the same speaker category?
Haven’t tried with multiple speakers.
Could you not do it by only exposing specific devices to specific Echos or even split them by using a different account on each Echo and forgetting the unwanted devices via the Alexa web app?
@masterkenobi you should read the smart home skill docs. Smart home skills are special and additionally require using AWS lambda. This is different compared to normal skills, for which the corresponding back end service can be hosted wherever you want.
There’s really three types of options here at the moment, and here’s a brief high-level overview of each of them.
Create your own normal skill. This is nice because all of your device and HA information can stay local to your installation, as Alexa will pass on the intents to your service/installation. The big drawback is that all voice commands must be a variation of "ask for ".
Emulated hue variants. HA exposes devices to the internet (eg, /api/pi/lights) so that Alexa can discover them. I’m not 100% sure, but I think the exposed device information is stored in AWS implicitly so it can process the voice commands. node-red-contrib-alexa-local linked above is one example of an emulated hue variant. Its big advantage is that it doesn’t need to use the clunky "ask " syntax (eg, instead of “ask to turn on the kitchen light”, it’s simply “turn on the kitchen light”), but the big downside is that everything is treated as a light, causing effective functionality to be limited to turning things on/off and raising/lowering a number, ie the brightness of the “bulb”.
Smart home skill variants. Haaska uses v2, and HA cloud uses v3. The Node-RED Alexa Home Skill Bridge linked in the OP seems to be a smart home skill too, and I’m pretty sure it’s v2 like Haaska. The v3 api includes support for entertainment devices and has quite a bit more features than v2, which explains the gap in device support between something like Haaska and HA cloud. Like the emulated hue strategy, this doesn’t use the "ask " syntax, but the big difference is that it gives much more appropriate and specific controls for many different types of devices, including temperature controls, door locks, fans, entertainment devices, and cameras. The downsides include:
a) Setting up a smart home skill is not as straightforward as a normal skill: a device “cloud” that exposes the relevant is needed, oauth 2 is needed, and the general process is more complicated. Here are the docs, and here is an image of the flow.
b) Some code must be uploaded to AWS Lambda which is basically responsible for mapping Smart Home Skill device types to HA component types. If you want to see an example of this, check out Haaska’s implementation conforming to the v2 API.
c) Some device info is stored in the Alexa cloud, so Alexa can figure out effectively which entity is being referred to during a command. This isn’t a big deal to me personally, as AWS is extremely secure, but some people might feel differently.
If you need/want a smart home skill implementation and either a) don’t have the time to deal with bullets a and b and/or b) don’t mind paying $5/month, then HA cloud may be the right choice for you. Until someone updates Haaska or provides a good v3 guide, these are really the only options.
Totally agree with you. Guess I will have to use HA Cloud until Haaska is updated to V3.
I was using separate Amazon accounts for each Echos until Amazon introduces multi-room audio. In order for multi-room audio to work, each Echos much use the same account.
From your description the Node-RED Alexa Home Skill is actually v3.
If you check the docs you’ll see it includes commands for temperature controls and door locks but more tellingly it works directly with new Echos like the Show and V2 which only work with v3.
But it exposes everything as lights. Makes no difference than using emulated hue.
Oh well, never mind. Thinking about it, could you get multi room audio to work by linking the same second account to every Echo? I don’t know much about the audio side as it doesn’t interest me so apologies if that’s a dumb suggestion 
There’s a huge difference to emulated_hue in that it’s v3 and allows all the people stuck with non working emulated_hues to get back on course again. It doesn’t actually expose everything as lights, only those which use the on/off function, just unfortunate all yours would be!
Why not give the dev a shout and see what he says about adding other devices, he welcomes communication…
If you just have a general question then probably best to try and find me (hardilllb) on the Node-RED Slack team in the #alexa channel.
