randyth

Fixed! Thanks for the prompt service, Michel. -Randy

As of today, my programs that use the rest interface via the portal have stopped working. Specifically, a custom Echo app and an IFTT recipe, both of which were previously working fine. To help debug it, I tried sending a simple nodes rest command from my web browser (https://<user>:<password>@my.isy.io/isy/<security_token>/rest/nodes) and I now get the following message: Cannot GET /isy/[xxx]/rest/nodes ...where [xxx] is the security token gleaned from the portal's ISY Information window. Has anything changed recently that would require me to alter they way I access the portal? -Randy

A general thought (and something I should probably post on Amazon's Alexa developer forum)... Instead of having just one list of generic "one size fits all" utterances (Interaction Model) per app, it would be nice if Amazon allowed Echo apps to have a dynamically customize-able Interaction Model per user. This way, the Interaction Model for any one user could include the actual device names found during the device refresh, thereby greatly improving voice recognition for that particular household. -Randy

Using a custom Echo app I wrote for myself, I can say that the Echo refuses to correctly match the word "Christmas" and pass it to my app. So, this is clearly not a problem exclusive to the ISY app. Like you, I finally resorted to using the word "Holiday." I blame Amazon. -Randy

+1 as well

That's great news, and I like the skill name very much. However, I thought skill names had to be more than one syllable. I hope Amazon has changed this requirement because, as I said, I think "home" is a great skill name for this purpose. If Amazon does ask you to choose a new name with more syllables, I suggest you change it to "my home" or "my house." -Randy

It would be interesting to get a poll going of possible names.

As I'm sure you are aware, you are using "the cloud" simply by using your Echo. But, you are certainly minimizing your exposure via a HUE emulator as opposed to a portal solution. Though I have a working HUE emulator in addition to my hard-coded (read, "only works for me") Alexa Skill app, I plan to support UDI's efforts to create an official UDI-created app. I assume the cost of the UDI portal will be reasonable and have no qualms about rewarding their good work with my money. I know UDI would prefer to avoid the cloud as well, but for now, Amazon is sadly not providing UDI with the same level of custom support as they are the big players like Phillips. Maybe down the road... By the way, I also support your efforts, Barry! Even if its only moral support and not with my checkbook. Your work is truly impressive. -Randy

I totally get the aversion to using the cloud, especially for something like home automation where each device (Echo and ISY) coexist on the same LAN. That said, I think using the portal is a perfectly acceptable solution. I'm using it now for my own tests and it adds no noticeable delays. I'm also not too paranoid about the security issues. Heck, I already put a microphone in my house so Jeff Bezos can listen to all my conversations. -Randy

Yay!

Of course! The human is the most important component.

Yeah, RackFanTempLimit is a constant of sorts in the form of an ISY Integer variable so I can tweak it now and then based on how paranoid I am about how hot I can let the rack get versus how much energy I want to save by not running the fan as often (which is really silly of me, I know).

With this method, I can easily have custom triggers that turn the fan on for as much or as little time as I want. For example, I use the following program to turn on the fan for 30 minutes when I hit a button on a remote. (I'm often working around the rack and want the fan to stay on for a while to keep the human -- that's me -- cool). RackFan On If IR 'Up' is Pressed Then Set 'Rack / ZW 004 Rack Fan' On $s_RackFanCoolTimer = 30 Else - No Actions - (To add one, press 'Action')

What I originally posted is one of three programs I use to run a fan that cools an equipment rack if it gets above a certain temperature (as determined by the variable i_RackFanTempLimit). These programs run the fan for at least five minutes and then continually add an additional minute if the rack hasn't decreased in temperature enough. I went ahead and posted all three programs below. @Michel, that's great about 5.0. It will be fun to streamline many of my programs with 5.0's new features. Cool Rack If $s_RackTemp >= $i_RackFanTempLimit And Status 'Rack / ZW 004 Rack Fan' is not On And $s_RackFanCoolTimer is 0 Then Set 'Rack / ZW 004 Rack Fan' On $s_RackFanCoolTimer = 5 Else - No Actions - (To add one, press 'Action') Cool Rack Delay If $s_RackFanCoolTimer > 0 Then Wait 1 minute $s_RackFanCoolTimer -= 1 Else Run Program 'Cool Rack Off' (If) Cool Rack Off - [Not Enabled] If $s_RackTemp < $i_RackFanTempLimit Then $s_RackFanCoolTimer = 0 Set 'Loft / ZW 004 Rack Fan' Off Else $s_RackFanCoolTimer = 1

Maybe not exactly what you're looking for, but I use the following logic to "wait" for as many minutes as the state variable s_RackFanCoolTimer is set to. Because I use a state variable, this timer program is triggered by simply setting the variable to a positive value. If $s_RackFanCoolTimer > 0 Then Wait 1 minute $s_RackFanCoolTimer -= 1 Else Run Program 'Time is Up' (If)

I still care.

I don't think that guy is doing anything very different than what kgividen and I have already done with our Amazon Echo apps. They operate the same in that I issue commands such as "Alexa, tell Sarah to turn on kitchen light." The trick is making the app work for anyone. I suspect this guy's Echo app is hard coded to talk to his personal system, which he calls IntelliHome. Similarly, my app is hard coded to talk to my system via UDI's beta ISYPortal. The trick is making the app work for anyone, so unless he has a clever way for any random user to point his or her Echo device to their personal "IntelliHome" website or ISYPortal, each user has to have a custom app built for them. I could be wrong, of course, and there could be more magic behind the curtains that I can't see from just looking at his video. -Randy

@kingwr I think you hit the nail on head regarding all the user-interface issues that have to be resolved, how they could be resolved given the current Alexa API, and the fact that (until UDI is given the same device-level access Phillips was with their HUE products) any homegrown solution we unwashed developers come up with today will always appear a bit clunky due to the need for the three extra words "...tell <appname> to..." That said, I'm having fun experimenting with solutions while I wait for a more comprehensive API from Amazon. -Randy

@kgividen Happy to talk to you directly. Email sent.

+1 You'd still need to share your ISY's username:password with the Echo app, but at least we wouldn't have to expose our ISYs to the world via the cloud.

@kgividen Yes, I agree there will eventually have to be a settings option added to the web-based Echo app that allows the user to enter this information in the same way you currently enter your Pandora or iHeartRadio account info. In other words, a way for us (developers) to add simple UI screens to their current web-based Echo app as part of our app's "installation" process. This is obviously something Amazon would have to allow/support in order to for anyone to publish this type of app for public use. Otherwise, you have to customize the app for each user! There might be some creative solution to this, but none I can think of at the moment. Until then, I am trusting that Amazon will figure all this out by the time they have a process and app store in place for people to actually share/sell their Echo apps with the world. -Randy

As you might know, the AWS Lambda server supports JavaScript functions through Node.js. I am using Nodes.js' HTTP module to talk to my proxy server. While I am not using my ISY username/password in my AWS Lambda code (I only do that at the proxy->ISY level inside my LAN), the HTTP module claims to support basic 'user:password' authentication to compute an Authorization header. It also claims to support HTTPS. I've yet to have to use either, but I am willing to try. I'll send you an email at support@universal-devices.com so we might set up some tests. Cheers, -Randy

After being waylaid by other silly projects that should be limited to people with more skills than I possess, I was finally able to get my Echo to talk to my ISY without the use of the Hue "hack" or IFTTT. Using my Amazon Echo developer access, I created an app that runs on Amazon's AWS Lambda servers. I call my app SARAH in honor of the Self Actuated Residential Automated Habitat system from the old Eureka TV show. This Javascript-based app talks to my ISY device via a custom proxy that I created and run on my local NAS drive. I had to open a port and use a free cloud/DNS service so the Echo app could reliably contact my NAS drive. It's a bit of a patch job -- certainly not a final solution for the masses. In fact, it is as much or more of a "hack" than the HUE solution, I'm sure, so please don't ask me for my ugly code. I'm sure you don't want it. However, I am very happy with it! @Michel, if you can still use volunteers, I will gladly help you to test out your new ISYPortal with my SARAH app. Thanks, -Randy

@jruben4, here's more info on hbs01's comment: http://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface#Programs

I just received my "Alexa AppKit" invitation, giving me assess to the Amazon Echo Developer program. I haven't even logged into the developer site yet so know nothing as I post this. When I do learn more, I'll share what little information the NDA allows (which could very well be nothing). And, of course, see what I might do to help get UDI into the program. They certainly deserve to get an invite more than I do. As cool as the WeMo / Hue hack is, I'm hoping to avoid it and have Alexa on direct speaking terms with the ISY -- no interpreter required! -Randy