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

You need to activate ISY for your second Amazon account before it appears in the Alexa app: https://pitangui.amazon.com/api/partner-authorization/redirect-to-partner-authorization-uri?partnerId=Lg6UxwcNheb9gQrMG8GbeI8V3&applicationDomain=ALEXA_COHO What's your goal in setting this up? -David

That's great to hear that Amazon was so open - it's funny you bring up Sonos in this context. The audio from my Sonos stuff blows away the echo, but in a few rooms, like my bedroom it would be overkill since I rarely listen to music there. So for me, not buying more Sonos is how I'll end up funding additional echos -David I was hopeful of the same - you can use the feature to get access to your Amazon content, but none of your third party connections carry over. Best, -David

Hey - no need for additional ISYs. For each additional "zone" for lack of a better word, all you need is an additional portal user, an Amazon account associated with the echo for that zone and a few mins to spare. So I agree it's not ideal, and I sincerely hope Amazon implements this officially. However, if you don't mind spending 5 mins per zone, you've got the described result at no additional cost. Now I just wish these things were cheaper Best, -David

Confirmed 100%. creation of a separate user and doing all the usual linkages with a second Amazon account and then using their Group feature for Generic names that are unique to the scope of that Amazon account / echo works. Looks like I'm buying another echo ! -David

Hi Michel, I finally got around to trying this out from earlier in a different thread, and I think one more step is required. It seems that on the backend, portal keeps track of the mappings of devices on the ISY to Spoken names based on solely on the ISY, vs. account/ISY. So, even under the second account, mappings all appear the same, if you log in with one account and make a change, logout and in with the second, the change is reflected. However, I'm 99.99% sure that it's actually slightly simpler. This is already complete in terms of steps, my buddy just needs to help me confirm by using is echo to control my media room lights when he says "Alexa, turn off the lights." Whereas when I say the same thing, it should turn off my living room lights - I don't have a second echo, but based on the outcome I may soon . So, basically, instead of creating a separate account, approving it on the ISY etc. just create another user under the same account. Then the rest is the same: create another Amazon account with the other echo; enable ISY coho, skill, etc. and the last piece is: In the Alexa app for each echo/Amazon account I question, created a new group with the appropriate device(s) from portal and gave it a generic name. So for me, "lights" group in the alexa app is associated with a different device depending on which account I am logged in as. As stated, this is all set up already, just need to test it shortly. Best, -David

Hopefully they let others use the same framework soon.

Hi Einstein.42: this is great! I run all of my ad-hoc HA stuff on a Raspberry Pi, so I quickly scripted a CGI wrapper for your app - it's pretty ugly since it doesn't really handle output any more than it needs to so Apache won't barf - but it works for being called as a network resource. So, Keypadlinc with a garage button is good to go. Also, if you or others are looking for a way to reflect the door status on the Keypadlinc in near real-time based on MYQ (instead of another sensor) you can use IFTTT now. I have my MYQ app configured to send an email alert if there is a door open or close event. I created a gmail label to capture those notifications. I then created an IFTTT rule which calls the maker channel to run my Get/Update status program on the ISY when new mail with that label comes in. For safety, rather than immediately setting a specific status, the program runs the status command in your script and then turns the scene with the KPL button responder on/off accordingly. It doesn't matter if it was an open or close email, it's always handled the same way. I also have a program which runs every 5 minutes to do the same just in case IFTTT or gmail is gummed up. This way you can get near real-time status reflection if a native controller is used to open/close the door without hammering their API every few seconds. Best, -David

Likewise, significantly faster - easily 2-3x! -David

Hi Michel, It seems like this is a controversial topic and has been debated before: http://forum.universal-devices.com/topic/15372-simple-3-way-dimmer-switch-question. From what I can tell, there are those who are fixated on what Insteon can and cannot do; those who don't care either because they are a user with a specific need or because they are a developer with a mindset of always solving problems in software (or both) and then there is UDI, which needs to weigh the benefit vs. complexity, priority, etc. of every feature you plan on delivering in your product. Clearly, your team has exceptional experience in Insteon and HA in general, but especially as you expand beyond Insteon with Polyglot etc., I would ask that long-term you consider some type of virtual object that isn't based on an Insteon scene - Who knows, in the future people may want to have Insteon loads and Hue bulbs managed together. I know one major concern is that something you implement would break existing installations or cause unexpected behavior - to that end, I'm sure everyone looking for something like this wouldn't mind "opting in" with a button that is off by default or something. I would be very happy if for example, I could check an option on a scene and have a "Derived Group" based off of it as a sub-node. This derived group could be limited in only including certain device types within the existing scene and it would still probably meet most users needs. Another option would be to have programs that can take an argument like a brightness level and act on it etc. Much of this can be implemented outside of ISY and maybe would be best implemented in a Poly, but as you pointed out earlier even just the issuance of multiple direct Insteon commands can introduce latency that may cause the loads to respond asynchronously. While this is definitely true, I think in many situations it will work quite well. However, adding calls to other devices on the LAN or implementing it in the cloud (like in the Alexa app) is almost certain to deliver an asynchronous experience. I know it seems simple to just create a couple of scenes at pre-determined levels, but if the goal is natural speech, it just doesn't work. Also, there are applications other than speech which would benefit from this as well. Anyway, all of the recent developments are amazing - I really appreciate all of the work that has gone into it even if I just sound greedy for features. Best, -David

Hi Michel, Does this mean that in the Portal, I can add a second user with the same preferred ISY, but link this user with a different Amazon account / Echo and maintain a separate Spoken table? Regards, -David