dywicked

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

What's funny is I actually had this working exactly as you describe using your ISYHelper shortly before connected home was announced, but I forgot. It seems that you do exactly what I described earlier in the thread (just set all responders in the scene to x). My wife definitely rolled her eyes, but not before I did myself. I'm technical and love tinkering but am easily frustrated when things don't work the way I expect them to. Like you said, it just makes sense for simple scenes. Best, -David

Ugh, sorry for the relentless chatter, but I'll just try and make this as simple as possible: I can achieve what I want right now by creating groups in the Alexa app. So, clearly software can make possible the objective I wish to achieve. However I'm lazy, particularly about things I've already done and feel like I shouldn't have to again. So, as a convenience it would be great if somewhere (either in ISY or portal) I could check a box to toggle "Treat this scene as a group", which would automatically send the appropriate individual commands to each device in the scene instead of a scene broadcast. This would save me a lot of time, both initially / ongoing as I make changes and it's also going to work better; as the "grouping" can be initiated from the ISY instead of at Amazon's service. I understand that to have the grouping initiate from the ISY would require changes to the ISY, and I think that's just the cleanest way of doing it, but if implementing in the Portal for the time being meant functionality could be delivered earlier, I would be very happy. It still saves me a lot of time and is one hop closer to my home. Anyway, this is all just wishful thinking and fun discussion! Regards, -David