dywicked

Yeah, I found the language confusing as well - I interpreted “Call” as “Commanded”, but not with high confidence. Like you, I’ve used the button this way many times before. In this case, it’s All On/Off/dim, etc. These are brand new Keypads delivered straight from Smarthome in the last week. They report as version 4.5 in the ISY console.

I’ve been using Insteon and Keypadlincs for ages and I’ve never run into this, but I’ve run into something odd while working on a new setup for a friend. Basically, there’s a scene which in addition to a couple of other keypadlincs, has the top left button of a Keypadlinc dimmer(8 button) as a responder - this is connected to the load. There is another button (bottom right) on the same Keypadlinc which is set as a controller for this scene. The strange thing is when I use this button to control scene, all other devices respond except for the local load. When controlling this scene from any other Keypadlinc, all is well. The local load won’t turn on or off under these conditions and behaves the same with or without a connected load. I can reproduce this behavior on two different scenes with completely different devices involved. The final strange thing, is if I choose a button other than the H (bottom right) as the controller, everything works as expected. The two 8 button Keypadlincs I’m using to verify against each other both report back 4.5, but one is a 6 button that has been switched to an 8 button configuration, while the other is “natively” 8 button”. Perhaps I’ve just forgotten something really obvious after all this time? I also saw the following on the UDI http:// https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_a_KeypadLinc and I wonder if it’s related: “A KPL cannot turn it's load completely off when a secondary button includes it in a scene and the scene is called On. It will be better to use it without a load if you plan scenes that turn the connected lights off. But convenience should be a concern as well. As a work-around the ISY can be used to set the level to 1%” Any help is appreciated. Best, -David

So, on a couple of occasions now I’ve had programs exposed as devices, lights etc. to Alexa where knowing the “status” of the device would be useful - mostly in routines. I was thinking it would be really useful to be able to choose a variable to associate with any program based entity which reflects the virtual status of the program. So, as long as you update the value of the variable in your program you can track on/off state for Alexa’s purposes. Thoughts? Regards, -David

Yeah, the "Insteon doesn't work that way" thing bugs me too - I get it, but also who cares. Implementing a virtual device that behaves like an uncrippled scene wouldn't be crazy difficult. Sure, there should be a warning about the excessive traffic, perhaps even limitations on the maximum number of devices in the virtual, but it would be super useful. My use case is identical to yours Jimbo, and I've worked around it a couple of ways - using your ISYHelper, as well as by using a combination of Alexa Groups and a program on ISY. It would be nice if the abstraction could be done at the ISY, as this would really keep latency to a minimum. -David

Okay, first off there are two different requirements being discussed. 1) Controlling ISY *from* harmony. 2) Controlling Harmony from ISY. Jimbo's ISYHelper is an elegant solution to both. However, if you don't want to get involved with an RPi, here are some options: To address #1, get either an ISY or an Insteon IR receiver module. The Insteon option has the advantage in that you can plug it in where all of your media equipment (and your harmony) is located, whereas your ISY might be somewhere else. To address #2, the easiest think to do if ISYHelper is out of the question is to use the network module (or portal subscription) on ISY to call IFTTT to control Harmony, although there is often some lag with this method. I'm not 100% certain, but I do not believe the Insteon Hub solution allows you to control Harmony from an Insteon device, just the reverse. Mixing ISY and Hub is never worth the trouble IMHO. -David

This is just Amazon's next version of the Connected Home APIs and opening it to more developers. Using the word skill is just unifying terminology as marketing for developers.

Looks like ISY should be able to extend itself further now: https://developer.amazon.com/public/community/post/Tx1KIRDSNFDHEA4/Amazon-Enables-Developers-to-Extend-Alexa-s-Smart-Home-Capabilities-a-New-Additi

It's funny because on their March 3 blog post https://nest.com/blog/2016/03/03/nest-and-alexa-working-together/ they specifically refer to skills in addition to Connected Home and say you will be able to: "ask about the temperature and humidity." My assumption is that there is a skill still under development. Since skills can do so much more than CoHo and syntax isn't as limited, they are probably more difficult to get right (also considering UDIs experience with the skill). It also seems like there has been a race for thermostats in CoHo and Nest probably didn't want to be left too far in the dust and so prioritized this over the skill. Either way, progress so I'm happy. -David

Not much else to say.

So, I have no idea if this is widely known or not but I wasn't aware of this so I figured share. When the Echo Tap and Dot were announced, there was also mention that Nest would have native connected home integration in Alexa in a couple of weeks. However for the time being, you can get the same experience by creating a Wink account, linking your Nest account to it, Linking you Wink account in the Alexa app, and then discovering devices. Now your Nest is Coho for Alexa! No Wink hardware is necessary: http://blog.wink.com/wink-blog/2016/3/3/wink-enabled-nest-thermostats-now-work-with-amazon-echo While it seems to work, there are some quirks. 1) Its slow, probably because there 3 service hops in the mix and its brand new / not optimized. 2) The name may conflict with an existing CoHo device, for me this was "living room" which are lights on my ISY. This seems to be a limitation in Alexa's lexical analyzer. Ideally it would understand the difference when I say degrees vs. percentage - but it's definitely not something easy to solve in my opinion, so I'll cut some Amazon some slack. 3) Related to #2, there's no way to set a specific spoken name, this seems to be something UDI has uniquely gotten right amongst all of the CoHo implementations. You can work around this by changing the name of your thermostat in the Nest app to custom and call it the same thing with the word Thermostat at the end then rediscover. There are other ways too such as the inverse in ISY for the lights, or using groups, but this worked best for me. Anyway, have fun! -David

Hi Michel - another way to work around this to just create additional users on the main account in Portal and associate this with additional Amazon accounts. Then in the Alexa app for each unique Amazon account / echo, you just define a different group called "Light" with the appropriate devices. I tested this a couple weeks back and it works. Although there's something kludgy about it, there are fewer steps to get everything working and perhaps the 5 account approval limitation in ISY can be avoided. Best, -David

Likewise, I already have this working using some of the existing Python stuff on a Pi and the network module. When 5.x becomes stable I would look for a cleaner implementation as a poly node.

Ordered!

This is awesome, thank you! It worked using groups in each of the Alexa apps, but this is cleaner. Hopefully Amazon implements this natively in a single account sometime in the future! You guys are great! -David

Try logging out of Amazon, (go to Amazon.com and make sure it doesn't have your user at the top navigation). Completely close (exit) your browser (all windows) and try the URL referenced above again. Best, -David