MWareman

Also, there 5.x is early beta. I wouldn't recommend it yet for production use unless your willing to tolerate caveats for a while.

It could indicate a going-bad PLM missing link records. Try right-clicking the PLM (in the Admin Console) and clicking 'Restore'. That will put back any missing records. You can then test (the web interface is fairly authoritative). If that was the problem, plan to replace (or repair) your PLM shortly. How old is it?

This is exactly home the ISY connected home interface will work, when Amazon approve it. If you want IZZY-less interaction then this is the only way to do it until the native method is approved.

No. That's an Amazon limitation, not an ISY or UDI one. It's the only way Alexa can tell where to send your command since you may have many skills attached to your Amazon account. The connected home interface, when approved, will allow a simpler interaction as you indicate for lights and scenes, but has a limited vocabulary. So, no programs or non-lighting commands.

If often thought that a better construct for ISY would be something like: When DoorLock changes to Unlocked If Hall Light is not 80% Then Set Hall Light to 80% Send Notification 'Door Unlocked' Wait 10 minutes Set Hall Light to Off ELSE Send Notification 'Door Unlocked' Basically, only events that trigger events can show up when building the 'When' construct, and its a block that discretely defines what should trigger this program - separately from the 'If' construct that is a conditional or suppressive construct. Basically, trigger on these events, only if these conditions match'. So, in the example - the light changing state (for instance the user dimming the light) would not reevaluate the program - but a change in any condition in the 'When' (door being unlocked again) would. I've many times wanted to use a light state as a conditional without having a change in state trigger the program. Right now, its convoluted. I create a second (disabled) program with the status check in the 'If' clause, and 'RunIf' from the main program. It's a pain to keep track of. This way would be easy to automatically upgrade to as well - basically a new 'When' clause would be added to all programs populated with the current 'If' clause without non-triggering events. Overall - it would allow new users to more visually interpret the event driven nature of ISY.

You can accomplish this approximately by having your program trigger a second (disabled) programs ''RunThen" which has the wait as the first element. This would not restricted since the second program would be disabled, and wouldn't have anything in the 'If' section.

I was thinking this myself.... having 'Add' being within the 'Device' button logically separates it from the 'Scene' button. A frame around the button set with an 'Add' label would solve this - along with removing the 'Add' from within the Device button.

Thanks Benoit, I just found the (tiny) red 'x' to remove a device from the Alexa mapping table... - and noticed the 'Delete All'. So, I deleted all then added the scenes I want controllable via Alexa. I'll test when I get home this evening. It does make more sense managing this directly on the portal vs on the ISY. A question remains though - what is the purpose of the 'spoken' field on the ISY now? Is this for the connected home Alexa integration whenever Amazon approve it - or some other purpose? One (minor) comment... There is an 'Add Device' button. Why is 'Add Scene' labeled simply 'Scene'? Shouldn't it be 'Add Scene'? Michael.

When I tried to clear a spoken name, it gave me a 400 error. It also filled all spoken name fields in with the device name, most of which are structured for ease of use in the Admin Console, and are not suited for voice recognition. As an aside... I think an ISY level option to have Alexa ignore the natural device names would be useful. I also think that spoken name fields should default blank. That aside, are you saying I should delete the device on Portal?? Or just clear the spoken name field? When I adjust the spoken name field on Portal - does this sync back to ISY? They don't appear to - which makes me wonder why the recent changes to allow them, and have them show up in the topology report.... Michael.

Benoit, Will we be able to tell the portal to exclude a device/scene/program from the skill? I have over 200, and I only need less than 10 for my Echo (given its location in my house). I'm sure that by filtering devices/scenes/programs, a better, faster match to verbal requests can be made. Thanks! Michael.

I don't think so... But I'm an Android user.

You can pass credentials in the url, but its a function of the browser to do it correctly. It works fine from the Maker IFTTT, but you have to url-encode the username (die to the @), and also possibly the password (if URL illegal characters are used). Michael.

Clever!

In the skill instructions - it tells us to 'Alexa, tell izzy to refresh devices' after the spoken name is changed. I just spent some time adjusting my spoken names on my ISY - then issued this command only to be told that this was no obsolete - and to update spoken names via the portal. So - I logged onto the portal and sure enough there is now an 'Amazon Echo' option on the menu... So far so good. Now the issues... It's worth noting that all my device names are encoded - so I need to use spoken names throughout... 1) Changes on the ISY don't appear to be propagated to the portal. How is this supposed to work... I would have thought that 'Refresh' should have retrieved the latest spoken name fields from the ISY but it does not appear to do that. 2) Portal does not list programs. How do we trigger programs now? 3) It seems inaccuracies (at least in my case) come from having nearly 200 devices with encoded names... all of which appear to have their node names 'copied' to the spoken field on the portal. If I try blanking out the spoken names of devices I don't want to control - I get an error 400.... I don't want all devices to have spoken names!! Can we, by default, not assign one??? 4) In the list - I like the 'Search'... Can we add the ability to filter by type? In my case - I only want to assign spoken names to scenes (and programs). It makes no sense for me to see devices. That's it - so far. However, after manipulating names in the portal, my skill has gotten *way* more accurate and responsive. Michael.

Yes, but I'm not sure how it can be implemented without help from Mobilinc itself. I don't think it's possible otherwise. It would be easier if you were able to figure out how people can keep both Portal modules active if they wanted to - Mobilinc Connect (for IOS users who want these additional features) and ISY Portal (for Alexa and other futures). Us Android users don't really mind (since we don't lose anything), but IOS users do lose functionality by switching, any some don't seem aware of it.

Mobilinc (IOS) when using Mobilinc Connect has support for selecting events to trigger pop-up notifications in app (delivered from the Connect Portal servers via the Apple push messaging service). It just used the incoming stream of events from the ISY connection and does not need any changes on ISY itself to work. Us Android users never had this, so we are (mostly) using services like Pushover (which works on IOS as well as Android) and the networking module on ISY so deliver push notifications. The only downside is you have to configure your notifications on the ISY, you cannot do it from your mobile device.

Geofencing and notifications are a feature of Mobilinc Connect. They won't work at all on ISY Portal. I cannot speak to the status issue. I'm on Android, and I initially had the same issue. After a few hours it resolved itself for me.

Don't know about ekeypad, but Mobilinc works via the ISY Portal. Just configure it as any direct connection to an ISY, but use HTTPS only, the host name my.ISY.io and your ISY Portal credentials.

What is the firmware and UI version of your ISY? Some newer devices don't work correctly with older versions on ISY firmware. Michael.

They have. See http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events Michael.

I always advise to never hook a garage door opener to an iolinc. Insteon does not contain the needed security protections.

In my case, the portal offers Alexa integration (although still early in development) as well as multiple usernames and passwords. This is useful for my families mobile devices. If my Daughter loses her phone (again), I only have to change her password instead of messing with hundreds of resources credentials after changing the single password that a native ISY connection supports. Worth every $ to me - even in its current form.

Something is wrong. ISY Portal didn't exist in 12/2014. It only came into existence a few months ago, but definitely not until well into 2015. I'd advise a ticket, assuming that UI and Firmware are up to date and the latest.

After you've got the UI in sync with the ISY version, try right-clicking the PLM and restoring it. It sounds like the PLM may be showing early signs of problems. How old is it?

Don't know about the others, but the Hub uses an online proxy that Amazon connects to. Everyone Hub connects, and Amazon only has to connect to Smarthome proxy. This is how the ISY works with the Portal.