MWareman

I've also been using the milight stuff - also fairly reliable, but having the controller being separate from the WiFi bridge is just kind of annoying me. I'm eagerly awaiting zwave multi-channel and I'm switching over to a Fibaro controller. Still the same LED strios, just a zwave interface to ISY.

This. No reason not to! It's *so much better* to say 'Alexa, turn on the kitchen light' and get 'OK' back instead of 'Alexa, tell Izzy to turn on the kitchen light' and maybe it will work, but have it respond 20% of the time that it couldn't find the device due to the Izzy not being heard properly and the request getting misrouted. Much, much better now!

From memory... For the Elk, I wired the mag sensor to an alarm zone - configured as an 'Entry 2' zone (I think... in my case). I have a longer entry time associated with this (when I arrive home and open the door, a longer entry delay starts. When you open the door to the house, the entry delay sharply shortens). With the Elk module on ISY, I trigger the garage light from the door being opened, and turn it off 2 mins after the door is closed. To control, I have an output wired to a remote button (I have a Chamberlain MyQ enabled door and then smart button - I cannot wire directly to the GDO). Basically, you wire the output in the same way the IOLinc was wired to the GDO. I configured a rule on the Elk - when output 65 turns on, turn on output 3, wait 1 second, turn off output three, turn off output 65. On ISY, all I need to do is turn on Elk output 3 to open or close the door.

Glad to see I'm not the only one. I've confirmed I'm not blocking JavaScript from executing on the portal.

Of course you can have a program (ProgA) with a 'RunIf' (ProgB) clause in the 'Then' section. Assign a spoken name to 'ProgA' and when you 'turn on ProgA' the 'if' clause of ProgB will be executed. Not ideal and messy - but possible. Personally, for 'If' program triggering I would stick with the skill. This may be a use case for virtual devices. Assign a spoken name to a virtual device and use them in a 'If' statement to trigger it. I'm not sure if UDI is any closer to implementing virtual devices though. Also, does Portal recognise nodes from node servers external to ISY (and let you assign spoken names)? I don't have this going yet, but am interested in knowing.

If you want to use local HTTP, create a second profile in Mobilinc. Don't configure the HTTP settings in the same profile that the portal is configured.

Don't do that anymore. For Alexa, all spoken words are managed in the portal, and the portal spoken words do not sync with the ISY spoken words. When managing in the portal, a sync is unnecessary. I also had the error about linking when I first added the connected home module. I logged out and back in to the portal and have not had it since. Michael.

Mines a Nexus 9 running Android 6.

Same here on my Android tablet (with Chrome). Hangs as the screenshot after authentication...

It's been a while - I hope I get this right.... In this case, 'is on' will trigger 'Then' when 'on' is pressed and 'not off' will trigger the 'Else' to run if the switch is turned off. Without the second clause, the 'Else' will never run when the light is switched off - only the 'Then' when the switch is turned on - which makes the program useless for status. Michael.

That may be why my fanlinc programs are not working... I wonder why this is? Can I set the device and call a scene (so the kpl gets updated)? More experiments to do tonight...

Very impressed so far. Very fast. Alexa simply responds 'OK' - usually after the desired action has taken place. I've created some device groups in Alexa - looks like that can be used to create aliases that Alexa will understand - since a group can contain one object. Michael.

Yeah, you'll need that to utilize that built in function. Otherwise you can send emails and write an email parser, but I suspect the network module will be much better for your need, and it will open up all kinds of additional capability to you.

Just found out you can discover from the app. Who knew! My devices discovered - even a program I have a spoken name attached to. I'll give them a try tonight. For the poster that asked for an easy list, once the ISY is connected you get a list of all devices (with their spoken name attribute) right in the Alexa app after they are discovered. Nice!

Woot! Thank you Michel and Benoit. Awesome job! Got my account all linked up, and ISY is showing up in my Alexa connected home settings. I just need to get home now to do a device discovery. Only one thing, I love the ! In the description....

Thank-you!! I also like the new button layout when added spoken names. Very slick. Michael.

Correct. In order to do a cloud to device notification to be consumed by the Mobilinc application, UDI would need access to the private application keys for Mobilinc's Apple server connection. Mobilinc would have to provide UDI an API that the ISY portal could connect to to securely send a notification. I doubt that's going to happen any time soon, but I could be wrong...

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.