Goose66

I'm not sure native integration into Alexa is such a great thing, anyway. Especially for things like individual light bulbs. What am I going to do - every time it's time to go to bed, do I say "Alexa, turn off the Hall Ceiling Can 1," "Alexa, turn off Hall Ceiling Can 2," "Alexa, turn off Hall Ceiling Can Thre...," well you get it. Voice control of individual devices is a cool trick to show your friends and all (and, yes, I know about Groups), but in practicality there is a limited number of things regarding home automation that I want to do with voice. The majority of these are multi-step, composite functions that may involve lights, security, AV settings, etc. Having the ISY accessible to the Alexa through the Smarthome 2.0 API and ISY Portal is ideal for me, because I can setup the scenes, programs, conditions, etc. I want to control on the ISY and make them accessible to both buttons on KPLs and specific voice commands that I determine. So I can say "Alexa, turn on the Spa" or press the "Spa Mode" keypad button and I get the same complex mixture of pool equipment control (now through my new node server), outdoor lighting, audio output to outdoor speakers, and the like. Try doing that with some of the items being native to Alexa and some not - it's too hard. And once Amazon releases multi-step programming in October, "Alexa, goodnight" and "Alexa, good morning" will allow me to link a goodnight and goodmorning ISY program to set conditions the way I want while Alexa reads me my calendar entries or the news. Again, try that with some things being controlled natively and some not - it's just too much to maintain!

Amazon Alexa devices don't send anything to the cloud service until you say the "Alexa" or wakeup keyword.

Thanks for clarifying. For me, the deciding factor for the ISY over Insteon Hub, HomeKit, SmartThings, and several others is the fact that it can operate independent of an Internet connection. Connectivity to cloud services (like the ISY Portal) is great, and I wouldn't even mind if the ISY Admin console was moved to the cloud. But having the core functionality depend on connectivity to the cloud (and/or mobile devices, in the case of HomeKit) just doesn't make sense for me.

Comparing ISY 994i with the Insteon Mobile App is comparing apples and oranges. The ISY 994i is more comparable to the Insteon Hub. The Insteon Hub plugs directly into the wall and provides an interface between the Insteon Mobile App from any location and Insteon devices in your home. The ISY 994i requires an Insteon PLM and a subscription to the ISY Portal to do the same thing, plus that doesn't include the app. You have a couple of choices for mobile applications (MobiLinc, eKeypad, Agave) and they each have associated costs. There is an administration module that comes with the ISY 994i, but it is more functional than pretty, must run on a PC or Mac with the JRE installed, and is more for configuration than control use (It would get very low WAF scores for a comtrol app). What you get from the ISY 994i is the ability to integrate many other, non-standard devices and ecosystems into you home automation system through ZWave and Zigbee modules, electricity monitoring, a basic programming capability, network resources, node servers in the beta 5.0.X firmware, and the like. But setting this up and maintaining it requires a hobbyist/technologist/programmer skill set and may not be right for everyone. The Insteon Hub is more plug-n-play, allows control and integration of Insteon dimmers, switches, outlets, thermostats, cameras, and the like, and comes with builtin mobile app and Internet portal capability. It has some integration capability with a few brands, like Amazon Alexa, FirstAlert, Sonos, etc., but is otherwise closed and doesn't allow custom integration (it may support IFTTT, though). It supports more of the latest Insteon devices, like the Motion Sensor II, for example, and it has better troubleshooting tools for your Insteon network.

So many new ceiling fans come with fancy DC control circuitry for the motors and lights that provides remotely-controlled, energy-efficient, multi-speed, quiet operation. But it also eliminates the ability to control with external controllers save the remotes that come with the fan. Anybody done any work on ways to get these types of fans integrated into an ISY994i-based home automation system? The one I have does not have a removable control unit (at least not without cracking open the motor housing). It doesn't even allow separate, external control of the light. It appears to at least allow the fan to return to its previous settings when power is removed and reapplied. I can live without speed control of the fan in the automation system, but I sure would like to be able to control that light separately. The remote is RF and not IR, as well. I am thinking I may have to buy an additional remote (at $50) and then hack it with a Insteon universal module.

Well, that certainly explains it. Back to the box o' crap from the basement... Thanks!

HELP! Just moved to a new house, plugged in my 2413S PLM, connected it to my ISY 994i through the same CAT 5e cable (I think) that it was connected through at the other house, and got no lights. At my old house, the ISY 994i had an external power supply that was connected to a UPS, but my understanding is that the PLM should provide power, right? Is there a special cable to allow it to power the ISY 994i or should any CAT 5e cable work?

I don't know that these include the same home automation features of the Echo/Dot or are compatible with the Smarthome API. It should let you use the UDI "Izzy" Skill, however. It would be useful if these would send a room identifier or specific unit identifier which could be tied to a room in the setup of the Izzy skill. EDIT: OK, I think I am wrong on this. Alexa Voice Service ("AVS" - what Nucleus and other non-Amazon products utilize) can use the Smart Home API, so cloud enabled devices like the ISY can be discovered and controlled. However, it can't do discovery and control of local devices (e.g., Wemo, Hue, Wink, Smarthings) like the Echo and Dot can.

+1

A couple of more tests between 7:30 and 7:32 EDT: Tried issuing the command "decrease the downstairs thermostat temperature" with both the thermostat off and the thermostat in Cooling mode (both those modes set by successful voice command). The response to the decrease command was always "I can only set the temperature..." regardless of the mode.

Sorry for coming to the party late - my PLM died the day before I upgraded to the V2 API. Anyway, new PLM arrived and I started testing. When I say "Alexa, increase the downstairs thermostat temperature" it says " I can only set the temperature between 32 and 104 degrees." If I say "Alexa, set the downstairs thermostat temperature to 76 degrees", it says "downstairs thermostat is an auto mode, aiming for 76 degrees" and sets the cooling set point to 76, leaving the heating settling at 68. This happens for both my Venstar thermostats and my Smarthome thermostats: 2 x Venstar w/ Insteon Adapter 1 Smarthome Insteon Thermostat Auto Mode, 78 Cool, 68 Heat Farenheit Tested between 7:00 and 7:25 EDT on Friday, July 1

Sorry - didn't read the last post. I will signup.

Would it be possible to upload the new ISY Skill with the 2.0 SmartHome API as a new, separate product? I could just delete the old Skill and add the new one? Since they are free and easy to configure, this would avoid any support calls.

If they would just switch the endpoints I would be glad to tell them what the impact is.

Any updates?

Do you lose the shared shopping list and to-do list across your Echoes/Dots? Do you have to duplicate all of your IFTTT recipes across Echoes? Do you lose Prime Music streaming on the non-Prime Amazon accounts?

Well, and the utility of their time. I love to tinker, and I was early in writing Alexa skills. But it takes more time than I have to create and maintain an actual working solution. I am doing the same thing now with chat bots, but I don't think I will have a marketable solution from it. Just want to make sure I understand the latest "thing" (which is necessary for my career so that I can relate to my clients).

I think we should be making as many suggestions in this regard to Amazon as possible. They have been responsive to other suggestions that I and others have made, especially early on. In regard to the multiple Echo/Dot issue, not only providing a device ID in the request would be useful, but having multiple devices communicate to avoid two different devices processing the same command would also be helpful. They could do a quick broadcast when the wakeup word was recognized indicating the relative strength of the received voice signal, and only the one with the best signal strength would send the remainder of the voice utterance to the Alexa service for processing, while the others would go back to sleep. If Alexa is going to be the heart of a Home-based AI controller through these devices, it will need this functionality.

At first I implemented my own Alexa Skill ("Ask Victor") that utilized the REST API of the ISY 994i. This had the advantage that I could define my own lexicon for scenes, programs, and thermostats devices and it was fairy accurate in the speech recognition, but the "Alexa, ask Victor to ..." was low WAF and Amazon made several changes to the skill API that kept breaking my service. I spent some time playing with the HUE emulator on a RPi, but that was a lot of work and I never got it working correctly. I know some folks on here have created fairly decent codebase and instructions for it since then, however. So after about a year I bought an Insteon Hub (even at 15% off it was $69). That worked directly with the Echo (no "Ask Izzy to..." or "Ask Victor to...") for lights, but not at all for my thermostats. Also, as others mentioned, the Insteon ecosystem did not like having two controllers at all. Too much status information lost. With the announcement of the Smart Home API 2.0 and support for thermostats (for which Michel has promised support in "early May"), I sold the Insteon hub on eBay for $45 and got the two years of ISY Portal service. I like the ISY Portal for a number of reasons: 1. You have both the "Ask Izzy" interface (ISY Skill) to do some more robust things, and the Echo Connected Home support for simple commands to turn on and off scenes and programs that can be setup for a core set of voice command functions. This has high WAF and goes beyond simply turning on and off individual devices by voice. For example, after asking Alexa to order us a Dominos pizza (just kidding - can't stand Dominos pizza), we can say 'Alexa, turn on arrival lights" and it activates a program that turns on front porch lights, driveway lights, path lights, and sets a variable. When motion is detected in the driveway, the front foyer lights come on to indicate that someone is at the door (preventing them from having to ring the doorbell and sending our dog into a conniption). You can't do anything like that with the Insteon Hub. 2. The Portal connection greatly simplifies the configuration of your network firewall, because the connection is outbound from your ISY (and not inbound ports opened up). 3. Using the Portal to expose specific Scenes, Programs, and Devices to Echo makes voice recognition more accurate than if the Echo is allowed to query every device the Insteon Hub is connected to. 4. I can imagine that Michel will continue to develop support for expanded Smart Home API capabilities in the future (***nudge and wink*** where's the thermostat support) Given all that, I think $50 is a small price to pay for two years of the Portal, but that's just one man's opinion. WRK

Any word on thermostat support for the latest version of the Smart Home Skill API? Does an app have to be submitted for approval or is this just a matter of responding to the thermostat commands in the skill adapter?

Don't really know yet. A database, web service, and web app will cost money to host, not to mention the processing cost for the lambda service implementing the actual Alexa Skill. So it's either charge an app fee to cover costs (after some testing) or just open source it and not worry about it. Frankly it only makes sense to make it database driven if it is going to be a multi-user service. If each individual is doing it for themselves, you can keep the database out of it and save 150ms or so per call. Better yet, you can put your individual device/scene names in the sample utterances to make the speech recognition better. As it is now, I have chosen generic sample utterances and want to eventually add smarter matching of spoken name with names in the node list, something like a confidence match with a threshold.

Back on the Alexa Skill (app) for the Echo front (if anybody still cares), I have my Alexa skill running and controlling the devices in my house. A list of device IDs and spoken names (node list) and the controller settings is in a database, so it would be configurable to be used with anyone. Next step is to create a service that supports a simple website creating a user profile, setting your controller settings, and building a node list from the ISY via REST. What I was planning on doing was have the service build the list from any nodes that had a spoken name attribute set. However, it appears that spoken name is only available on devices, but I am finding that I am much more interested in controlling scenes than individual devices. For example, if I am standing in the bay window at night and want to see what's outside, I don't want to have to say "Alexa, tell Victor to turn on the left backyard floods," "Alexa, tell Victor to turn on the right backyard floods," "Alexa, tell Victor to turn on the basement porch lights," and "Alexa, tell Victor to turn on the deck lights." I would muck rather say, "Alexa, tell Victor to turn on the backyard lights," which is a scene that I have setup. Michel, I don't mean to sound ungrateful (I know you added spoken name to devices already), but can we get this attribute added to scenes (groups) as well? Even more difficult, can we get spoken name worked into the UI for scenes? Maybe in 5.0 beta? That would be great. Otherwise, my service will be limited to devices only (or scenes for me since I can just manually alter my database).

So the setup for Wink is different from Hue or Wemo. It is setup as a "Hub Service." You install the device on the same LAN and then user the Device Links under Connected Home in the Echo App to link it with the third-party hub service. I know Michael said they looked at all of the APIs, but I wonder if this form of connection to "third-part hub service" will be opened up to other manufacturers? This is precisely what is needed for the ISY.

Huh, ... er ..., what? I can't concentrate on your post post because your avatar has me hypnotized!

The other thing that needs to be added (and I have suggested this) is that there needs to be a way to "gang" these so that multiple units in the house can work together. For example, if I shout from the bathroom to the Echo on my bedside table, the unit in the downstairs great room can also hear me, and they may both answer. What needs to happen is that they quickly decide between the two of them (or the N of them) which one received the wake-up word with the strongest confidence level and all of the others then ignore it.