I have implemented support for switches, lights, TVs and scenes. Unfortunately I don’t have fans or AC smart devices.
1 Like
Haaska still works fine for me. I’m able to use hass scripts to control just about anything.
You could easily do this for the use case of tripping individual speakers as asked above.
Broadlink IR/RF controls integrate as switches to control the TV/set-top boxes/Ceiling Fans too.
For sensor status, I used the trick to name the invocation name to “me” so I can say things like “Alexa”:
“tell me about the humidor”
“tell me about the front door”
“tell me a hint”
“tell me about the temperature”
etc.
I do have an issue in that the new simplified groups in the built-in alexa app don’t work for me, so I can’t get assigning a dot to a room and just saying “turn on the lights” to work for me, but that is not a big deal IMO.
I’m going to ride out haaska until i’m forced to move and have not yet upgraded hassio from 59.2 to 60.0 … I’m waiting to see what is up with the whole cloud thing first.
If push comes to shove I will have a lot of amazon gear for sale and will migrate to a local snips setup i suppose, but I’ve been part of this community for long enough to trust the decision makers to do the right thing in the spirit of total control of the home.
I just figured out a way to add other characteristics other than on/off such as increase/decrease fan speed working with the Node-Red local node if you’re interested.
The key is to attach the debug onto the Alexa command and read the output. Then I saw there’s a few values it passes on such as a boolean whether it’s an on/off command or something else. When you say “Alexa increase the fan/tv/etc.” It will pass brightness characteristics which you can use to trigger scripts such as volume or speed up/down. I can post a screenshot if you’re interested.
can you post one? im interested in the setup
Sure. I’ll post tomorrow in a separate thread and copy you so it’s easier to find for others as well. Cheers.
@LaFed @masterkenobi Here’s the mini-tutorial for adding more than just on/off commands with Node-Red here…
Just to keep everyone up to date here - while I haven’t gotten around to learning Python myself just yet, there are two people that seem to be working on the conversion to v3.
Mike Grant: https://github.com/mike-grant/haaska/
Bkryza: https://github.com/bkryza/haaska
There’s even a third person that is taking the work from the other two, merging it together, and building further on it: https://github.com/Minimad-Diver/haaska
I’m actively watching all three of these with interest. I’ve updated my repo to reflect these others in the readme. I am moving mine to archive/read-only in a few days.
5 Likes
FWIW, I ended up trying to do this on my own from scratch, but instead of using the haaska/HA cloud approach of automatically mapping certain types of HA entities to certain types of Alexa interfaces, I decided to use AppDaemon instead and let the user decide what exactly to expose to the Alexa Smart Home Skill. The main advantage to this is that I could use some Alexa interfaces like ChannelController that don’t natively map to any HA entities but can very easily correspond to an AppDaemon app. The second big advantage is that all the message processing happens locally in AppDaemon instead of in the lambda function (which just dumbly forwards requests and patiently waits for responses to dumbly forward back to the Alexa Cloud), which makes testing a hell of a lot easier. The obvious disadvantages are that users will have to install AppDaemon, know python to configure things themselves, and familiarize themselves with the Alexa Smart Home API, but the tradeoff is that it’s way more flexible and powerful. I think down the line it would be relatively easy to automatically map HA entities to Alexa interfaces, but that can be done later.
Anyway, I’m pretty much done, but frankly a lot of the issues seem to be caused by how flaky the Alexa Smart Home Skill infrastructure actually is. I’m able to parse a message, execute the corresponding command, and send a response, but more often than not, the Alexa cloud doesn’t like the response for some reason and Alexa will say something along the lines of " isn’t responding". Worse, there’s no way to tell why the Alexa cloud doesn’t accept the responses, which is absolutely unacceptable. The documentation and samples are often just plain wrong or contradictory, and the actual dev support on their forums is pretty much non-existent. Here are some examples of things that just don’t work:
- Alexa can recognize “set thermostat to heat” but cannot recognize “set thermostat to 70”, which is exactly what the documentation says should work.
- For entertainment skills, the Alexa cloud refuses to accept responses to operations that contain the actual data with what changed. For example, when turning off an entity, the Alexa cloud expects a response that includes the new state of the entity (eg, off), but it only accepts the response if the state is not included!
- Entertainment interfaces have a different version (1.0) than all other interfaces (3, not 3.0) for discovery only. This difference isn’t explicitly noted anywhere. And yes, the “.0” of 1.0 actually matters!
That’s just a few of the problems I’ve run into.
Until I’m able to get things to work end-to-end properly, I don’t think I’ll be releasing it, but just a heads up for those who are trying to get things to work.
1 Like
Have you tried using ”set thermostat to 70 degrees”, that’s what I have to say for my Hive thermostat which uses the Alexa smart home skill and is 100% reliable.
ditto with my nest
Yes, that works for me, but I’m just pointing out that the documentation is often wrong for even dumb things like that.
Maybe because you need to say Celcius, Fahrenheit or Kelvin they left out on the example intentionally.
If you read the all page you linked you see they mention everywhere else that the temperature.scale is a required payload and is included on the example requests.
Nope. You just need to say degrees to Alexa. That does the trick. No need to specify the scale when speaking to Alexa.
Field:temperature.scale
Description:Indicates the temperature scale for the temperature value. Supported values: “CELSIUS”, “FAHRENHEIT” or “KELVIN”
Type:string
Required:Yes
This information on the documentation you have linked
PS: Yes degrees does the trick because in the Celsius scale, Degrees Celsius are the unit
Sorry, there’s something lost in communication here.
When physically speaking to Alexa, only “Alexa, set thermostat to 20 degrees works”. The documentation says physically speaking “Alexa, set thermostat to 20” should work (it’s the second paragraph in the SetTargetTemperature section, right before the "Example single mode request), but it does not. I’m well aware that messages passed between the Alexa Cloud and the device cloud require a temperature.scale value as part of the message payload, and I’m not disputing that the documentation doesn’t say that.
That’s why I first wrote:
I still think the example is correct you just need to say: “Alexa, set thermostat to 20” and add your scale unit since that 20 can mean different temperatures on each scale.
If you really think about it it makes a lot of sense. Imagine you being used all your life at Celsius and visit someone with an Alexa programmed only in Fahrenheit and the wall screen also, you had to open your phone to convert Celsius to Fahrenheit all the time you wanted to changed the temperature.
This way I can just say to Alexa “Alexa, set thermostat to 20” degrees and the owners can still say “Alexa, set thermostat to 60” Fahrenheit.
I understand where you got misleaded but the documentation is not a 1 line sentence and sometimes you have to read it a little longer 
For anyone still following this thread, Mike Grant has been doing a lot of work and has a mostly running V3 branch.
This is made easier by the fact that there was some work done to expose a payload compatible with Alexa through the HTTP endpoint in 0.62.
The instructions aren’t complete yet, but you can look at https://github.com/mike-grant/haaska/tree/v3 for some details, and on the original haaska repo as well: https://github.com/auchter/haaska/pull/109
3 Likes
yeah… i have been watching the threads myself and happy to see the progress. unfortunately I haven’t try it myself because of some issues I have with HA 0.62.
Hi all,
Checking in again. No need to use the specific V3 branch, everything is committed to the master now.
Get it while it’s hot:
5 Likes
I can confirm Haaska by mike-grant is the best alternative to HA Cloud. It works exactly like the cloud component.
1 Like