Glad you brought this point up, @Farhanito!
Hey guys I was playing around with a native OH2 solution, itās not as feature complete as the one in this thread, but I wanted to get others thoughts on if it would be useful or not. I am trying to reduce how many other services are running on my box next to OH. I realize everyone has put in a ton of work, so my version may live forever as a side project which is ok, but your feedback would be greatly appreciated. This started with me wanting to learn how the skills api worked and morphed into a binding, I was torn even publishing it knowing there was another effort underway.
Hey @digitaldan!
I tested your older version and it worked great, prior to starting work with Alexa-HA. Iām currently running OH 1.8.x, but do intend to add support for OH 2.x before publishing Alexa-HA as an official skill. Iām sure many will continue to find your Alexa binding useful as its very easy to setup, offers auto-discovery and does most of the communication locally - something I wish was possible with a ācloud hostedā Skill, but that is not possible today. Providing both options to the OpenHAB community is certainly a good thing 
Iād also appreciate any thoughts/feedback on how we can improve Alexa-HA, and if your interested merging our collective efforts into the much more flexible Skill based approach!
Thanks @d0t ! Iām not sure what the plan will be for this binding, which is different then the hue emulation binding that I think you are referring to (which is the primary voice interface on my system). This one is a java based skill integrated into OH2 as a native binding. Again, Iām super impressed with your work, I think doing it it JS is awesome since it can be run as a lambda service. This is just another option, not sure what will happen with it, or if people will find it useful. Ultimately it would be great to combine our efforts since I wrote most of this in a silo ( actually i was on a long plane ride)
Thank you, Dan!
Oh I see! Yes I thought you were referring to the Hue Emulator approachā¦ For reference, here is a deep link to Danās new Skills README.
You were able to write most of this on a flight? Wow!
Couple of thoughts:
- If the intention is to create a published Skill that everyone can use without having to deal with SSL/webservers/ports/proxies/etc, then NodeJS may be a better fit since this can more easily integrate with my.openhab.org or more easily become hosted as a separate SaaS capable of managing many configurations/credentials/etcā¦ Then our OH/Echo users can simply install the Alexa-App, link their SaaS account, and get started.
- I really like how you used the homekit to make configuration possible via items! Is it possible to define multiple device names/labels?
- For OH 1.x, I donāt think its possible to access the binding config for an item over REST (so I couldnāt do something similar to your homekit item config), which is why I took the heavier Alexa-HA config.js approachā¦ But since youāve developed a native binding I guess anything is possible
- Does your code generate many utterances for the same ācommandā? This sort of training has made Alexa-HA pretty darn accurate and figuring out what you meantā¦ Wonder if there is something like alexa-utterances in pure Java you could use for thatā¦
While I am decent at coding in JavaScript, I am not very good in Javaā¦
I would agree with you on this point for sure, being able to throw this up as a lambda service would be much easier, itās a pain to do this locally.
My goal was to have as little or no configuration needed by the user other then tagging items. After talking with Kai abou the hue emulator binding , there was a certain appeal to being able to tag once and have items exposed automagically to many voice services. We decided to use āhomekitā as that tag for now, even though these are not apple homekit bindings. i think the future intent is to use some more widely adopted tag when that becomes available. The OH2 api allows you to pull things like tags on the items, so we could automatically pull down a users items and generate slots/utterances. This might be a good area for me to contribute to your project 
When I first started writing the java binding, I went down using the LITERAL slot type and having tons of sample utterances. But then i got confused with the differences between custom slots vs the LITERAL slot until I realized custom slots was a more recent addition to the API to solve the problem of having hundreds or thousands of utterances to try and match LITERAL values, or at least thatās my interpretation. I also think itās likely Amazon would release a āDynamicā slot type which would be awesome for supporting something like a my.openhab service. Iām guessing this is how other cloud home automation integrations are working. Again, this might be a good place for me to contribute
Actually once the offical Skill is released, I would rather have dedicated Alexa-HA server(s) do the processing. From my research, AWS Lambda execution times can vary quite a lot, and they have had weekend-long outages in the past. Furthermore Iād prefer to keep the most of the processing/handling on private servers to keep each ASK users OH server access ālocked downā and isolated from the public cloud. The cloud portion of the ASK should only handle the voice I/O, and not know how to reach the OH Servers directly (all get/set state commands would be issued from our private servers NodeJS app). To me this seems like a more secure architecture, but I am always open to explore other optionsā¦
Totally agreed 
Lets brainstorm on how we can do this consistently for OH 1.x & 2.x, if possible. Iād love to get away from the heavy config Alexa-HA requires today, but still want to handle āwhat & whereā for each item without requiring major changes to the item definitions, be able to tag each item with multiple names, handle edge cases in a customizable way, etc. Also, for OH 1.x this may require āfeedingā Alexa-HA the items configuration file(s) as binding configs and full item definitions canāt be read remotely (to my knowledge, someone please correct me if Iām wrong there!).
Many of them are seemingly black box (not FOSS), my guess is that they define the ASK slots/utterances as widely as possible, and then use server side validations based on individual user configuration. This way its one Skill that can control all. The slots/utterances arenāt āblockingā so to say, rather they are used only to generate the voice models on the ASK servers. I do hope to see additional slot types though, as this could help to boost accuracy and give us better flexibility in a hosted solutionā¦
Both of your suggestions for areas to contribute sound excellent; I am very glad to have your support with Alexa-HA!
Cheers 
Absolutely, i actually prefer to run docker containers that can run on AWS and locally.
Iāll probably focus mostly on OH2 if others want to focus on supporting OH1. Iām not sure how much time I would spend on new features for a platform that is in maintenance mode.
My guess is that they are building custom slots (or utterances) for a userās device. With the Hue binding it scans all of your items and puts them in your āconnected homeā list, the voice recognition is spot on, even with some non standard names. After playing around with the literal slot and lots of generic utterances (my first approach) , I came to the conclusion Alexa builds custom slots based on the device labels (which is what I did in my binding). It would be awesome if they would open this up to more than just their home automation partners. As you pointed out itās all rather black box stuff, so of course this is just my guess/opinion
Understood; I will see what can be done for OH1, if no one else wants to tackle it
My reply above was referring to the other available HA Skills (like MobiLinc, ISY, HomeSeer, mydlink, etc), and not the integral āconnected homeā features. Even if we did somehow partner with Amazon and get access to the āconnected homeā APIs/SDKs, as far as I know we would not be able to do anything beyond on/off/dim (and maybe open/close), and cannot return custom responses today. This is the main reason I decided to build this out as an ASK - to make it totally interactive via custom intents/responses, and not just issue commands.
Hey Mike - my Echo finally arrived today and I have just got your Alexa-HA skill setup and working - really really cool! I am not running OH v2 so canāt try DigitalDans stuff, but so far I am very impressed with what you have got working here. I need to play around with my utterences etc and work out how to do some simple things like alexa, ask openhab to turn on the coffee machine - i.e. without having to pass a location.
I will let you know if I come across any bugs - keep up the fantastic work!
1 Like
Thanks a lot, Ben; I certainly will!
Handling missing location/slots has been a pain to get right. My intention was to use the ādefaultā values (in config.js) when no location is available, but this is not currently wired in. Not ideal, but you could add a config item for this like so:
'coffee machine': {
'kitchen': 'Switch_Coffee',
'house': 'Switch_Coffee',
default: 'Switch_Coffee'
},
Then you could say (as well as the many other variations through the automatic utterance expansion):
- alexa, ask openhab to turn on the kitchen coffee machine
- alexa, ask openhab to turn on the house coffee machine
You could also totally hack this via config.js by making ācoffeeā the item and āmachineā the location, but that is not advised
Please keep your thoughts for improvement flowing! Github tickets preferred
Sweet, yeah had tried the default thing but makes sense now why it didnt work. Will keep playing and report any issues in Github.
Iām wondering if this could be used with the recently released Alexa for Raspberry Pi?
@proffalken - good question; I am uncertain without testing it out hands on, but believe it will. Both projects are already using NodeJS, so from a technology stack perspective its a good fit. I do not know how AVS->ASK calls work yet, but have found references of people with AVS/RPI using existing Skills just fineā¦
Amazon announced a new Smart Home Skill API today which supersedes the older Alexa Lighting API. I excitedly explored its potential, and it does allow anyone to build HA Skills which can be used without having to say the Skills trigger word (a.k.a. Invocation Name). Great! But the bad news includes:
- Similar to the current ābridgeā approaches available today, you cannot do anything beyond ON/OFF/DIM.
- Unlike Custom Skills build with ASK, you cannot define custom intents
- You cannot return customized verbal feedback for a command
- Only lights/thermostats/switches are officially supported (though its possible to work around this with unnatural commands like āalexa turn on home theater sceneā)
- Highly cloud-service/OAUTH dependent; seemingly requires AWS Lambda so you may not be able host the Skill yourself
Efforts will continue on AlexaHAās Custom Skill which offers a lot more flexibility and capability, IMHO!
1 Like
Hey Mike, if Amazon has an official home automation api I think it would be in our best interest to be compatible with it. While it may not support as much as the current integration, Amazon does state in their FAQ that they will be expanding the API to support additional types of devices in the future.
Point taken. I have been brainstorming on a hybrid approach which can support both in the interim. Without custom intents and the ability to return customized verbal feedback this is limited today, but I do agree that the official API will eventually become the best way forward.
Hey all,
just saw that Amazon has put everything on Github to turn a Pi into Alexa station using Java. Hereās the link in case you havent seen jet:
FYI - @digitaldan and I have been working behind the scenes to roll out an official OpenHAB skill based on the new Amazon Smart Home API, which is backed by the āmy.openhab.orgā cloud service. This Smart Home API based Skill features automatic discovery (using āhomekitā tags for OH2, and āloadedā virtual items for OH1) which will make it much easier for new users to configure and get voice controls working. Expect to see a published OpenHAB Alexa Skill in the near future which will be available via the Alexa App.
Alexa HA development will also continue forward, to handle more advanced interactions such as providing feedback for each command, handling variances with āutterancesā and controlling other types of unsupported devices/items. I intend to publish this Skilll too, ASAP
1 Like
Will this work without my.openhab for those of us who Han openhab on the public internet? Trying to stay away from as many cloud services as I can.