MikeB

That's the Force Armable option I mentioned. Problem is I have other zones that are Force Armable (three season room door, window, etc.). I like knowing if those zones are violated when I arm at the keypad. If I set all my motions Force Armable as well it won't be as obvious.

I found that as well. I decided to use a "Goodbye" program to turn off lights, set the alarm, etc. anyway so I just say "Alexa, Turn on Goodbye". Only problem I have is that the ELK will not arm during motion. I think that's more of an issue (at least for me) when using something like the Echo when you're trying to arm the system while walking out the door, especially with kids. The other issue is that if you are triggering a program that's doing multiple things, especially if there's a few WAITS in there, if you run that program again (by voicing the command again to Alexa) before the first attempt finishes the program does not seem to run although Alexa tells you OK. Hope this makes sense. I posted a message in the ELK forum about arming during motion but thought I'd post here as well. For right now I just have the ELK arm 30 seconds after I voice the command via a WAIT in my program but wondering if there's a better solution.

Check for another application using a port per the previous posted steps. I'm running on Windows Server 2012 R2 64-Bit without issue. I had another application using port 8080 (JRiver Media Center).

Going to jump in and try this out. Thanks for the walkthrough madmartian! Would like to give g10f4's configuration utility a try. Sent him a PM.

I'm very tempted to give it a try. Any issues with 2 Echoes in the home and the Hue emulator?

Ditto!

That's normal, how INSTEON works.

Done. First tweet ever.

Just got an email saying the Echo now supports WeMo and Hue: Supported products: • WeMo: Switch, Insight Switch, and Light Switch • Hue: A19, Lux, BR30, Bloom, and LightStrip lights I'd love to see support for the ISY as well!

Thanks for the confirmation!

It seems that my IOLincs engage their relays if an INSTEON ALL ON command is received. Can anyone confirm that their IOLinc relay engages when an ON is sent to My Lighting? I have a pair of IOLincs controlling my garage doors. I planned on having a rule in my Elk that would send an ON to My Lighting if my alarm went off. However, I certainly wouldn't want my garage doors opening! Thanks

It seems that my IOLincs engage their relays if an INSTEON ALL ON command is received. Can anyone confirm that their IOLinc relay engages when an ON is sent to My Lighting? I have a pair of IOLincs controlling my garage doors. I planned on having a rule in my Elk that would send an ON to My Lighting if my alarm went off. However, I certainly wouldn't want my garage doors opening! Thanks

I use a TriggerLinc in my home to automatically turn on/off my master bedroom closet when my door is opened/closed. If the battery dies it's obvious. However, there are other uses for a TriggerLinc where failure might not be quite as obvious. For example, I just switched to TriggerLincs to sense if my garage doors are open and if so light up an indicator in my master bedroom. Since my GarageDoorStatusLight is way up in my master bedroom, and the primary use of this is a reminder that a garage door is open before going to bed, it might be quite a while before I notice that a garage door was left open and the status light was not on. Since we use the garage doors pretty much every day I wrote programs that run when a door is opened. Once a door is opened a countdown is started. If the ISY does not show that same garage door is opened again within 72 hours it will assume something might be wrong and send an email to me. If that door is opened again within 72 hours, the counter restarts itself. Best case is that I will know in a few days if a TriggerLinc is not working. Worst case is I'll get a bogus message if I'm on vacation for a week and no one is using the garage doors. Here are the programs: GARAGE DOOR 1 BATTERY CHECK If Control 'GarageDoor1Sensor' is switched On Then Wait 72 hours Send Notification to 'Email' content 'GarageDoor1 Battery' Else - No Actions - (To add one, press 'Action') GARAGE DOOR 2 BATTERY CHECK If Control 'GarageDoor2Sensor' is switched On Then Wait 72 hours Send Notification to 'Email' content 'GarageDoor2 Battery' Else - No Actions - (To add one, press 'Action') Obviously you can adapt this to other uses. However, to be practical, the sensor must be used fairly often. Using this on a TriggerLinc attached to a window that is opened only 3 times per year might not be helpful. Hope this helps someone looking to do something similar!

I wanted to update this post since my garage door configuration has changed. Twice now my EZIO2x4 has fried (not working, partially melted case) just after a thunder storm. 2 of my sensors have also fried. My garage doors are metal, and I can only assume that something is taking a hit and frying the EZIO and sensors. This concerned me quite a bit (especially the melted EZIO case), so I've decided to move to wireless sensors and see what happens. Basically, I've taken the same garage door sensors from Smarthome: http://www.smarthome.com/7455b.html ...and attached them to the external sensor input on TrigggerLincs instead of hardwiring them to an IO controller. I've also trashed my EZIO and moved to a pair of less expensive IOLincs to control the doors (one for each door). Doing this has dramatically cut down the wiring needed. Each TriggerLinc is located close to the garage door sensor (close enough where the sensor's attached wire is all that is needed). Since I now have an IOLinc at each garage door opener, and I have an electrical outlet located on the ceiling right next to each opener, I'm using ~1 foot of wire between each IOLinc and garage door opener. Much cleaner than my last configuration. Using the TriggerLincs, I'm now using the green and black wires on the garage door sensors so that the TriggerLinc will show ON when the door is opened and OFF when the door is closed. I had a spare AccessPoint kicking around so I plugged it into an available garage outlet to ensure the TriggerLincs would be in good, reliable range. My programs have also changed somewhat since my initial post. Here are my current programs and the reasons for any changes: GARAGE DOOR STATUS ON If Status 'GarageDoorStatusLight' is not On And ( Status 'GarageDoor1Sensor' is On Or Status 'GarageDoor2Sensor' is On ) Then Wait 14 seconds Set Scene 'GarageDoorStatus' On Else - No Actions - (To add one, press 'Action') GARAGE DOOR STATUS OFF If Status 'GarageDoorStatusLight' is not Off And ( Status 'GarageDoor1Sensor' is Off And Status 'GarageDoor2Sensor' is Off ) Then Wait 1 seconds Set Scene 'GarageDoorStatus' Off Else - No Actions - (To add one, press 'Action') I now use separate STATUS ON and STATUS OFF programs so I can check to see if the GarageDoorStatusLight is already on or off. If it's already ON because one door is open, I don't want to create unneeded traffic by sending a 2nd ON command because the 2nd door is opened. I also increased my WAIT to 14 seconds to ensure reliable operation. Since my GarageDoorStatusLight button can be pressed to close any open garage doors, if pressed (turning the light off) the 14 second WAIT gives the garage door opener enough time to close so that the light does immediately come back on. GARAGE RELAY 1 AUTO OFF If Status 'GarageDoor1Relay' is On Then Wait 2 seconds Set 'GarageDoor1Relay' Off Else - No Actions - (To add one, press 'Action') GARAGE RELAY 2 AUTO OFF If Status 'GarageDoor2Relay' is On Then Wait 2 seconds Set 'GarageDoor2Relay' Off Else - No Actions - (To add one, press 'Action') I do have my IOLincs configured for Momentary Mode A, which means they will automatically turn off once turned on, but since the ISY does not update the Admin Console to show them turning off I still use my AUTO OFF programs to keep the Admin Console clean. GARAGE DOOR 1 CONTROL If Control 'GarageDoorStatusButton' is switched Off And Status 'GarageDoor1Sensor' is On Then Set 'GarageDoor1Relay' On Else - No Actions - (To add one, press 'Action') GARAGE DOOR 2 CONTROL If Control 'GarageDoorStatusButton' is switched Off And Status 'GarageDoor2Sensor' is On Then Set 'GarageDoor2Relay' On Else - No Actions - (To add one, press 'Action') The above programs are pretty much unchanged although I cleaned it up a bit. Basically, if my GarageDoorStatusLight is ON (indicating a door is open), I can press it to turn it OFF and the above 2 programs close either door if they are open. My biggest concern moving to TriggerLincs for my sensors was battery life or other malfunction. How would I know if the battery died on one of my TriggerLincs, or it otherwise malfunctioned? Since my GarageDoorStatusLight is way up in my master bedroom, and the primary use of this is a reminder that a garage door is open before going to bed, it might be quite a while before I notice that a garage door was left open and the status light was not on. Since we use the garage doors pretty much every day I wrote programs that run when a door is opened. Once a door is opened a countdown is started. If the ISY does not show that same garage door is opened again within 72 hours it will assume something might be wrong and send an email to me. If that door is opened again within 72 hours, the counter restarts itself. Best case is that I will know in a few days if a TriggerLinc is not working. Worst case is I'll get a bogus message if I'm on vacation for a week and no one is using the garage doors. Here are the programs: GARAGE DOOR 1 BATTERY CHECK If Control 'GarageDoor1Sensor' is switched On Then Wait 72 hours Send Notification to 'Email' content 'GarageDoor1 Battery' Else - No Actions - (To add one, press 'Action') GARAGE DOOR 2 BATTERY CHECK If Control 'GarageDoor2Sensor' is switched On Then Wait 72 hours Send Notification to 'Email' content 'GarageDoor2 Battery' Else - No Actions - (To add one, press 'Action') Hope this helps someone looking to do something similar!

I liken changing the default port to locking your car door. Will it stop someone who wants to get in? No, but it might make them move on to the next car.

You need to create an additional scene ONLY containing the sub-button as a responder, and write a program to turn that scene off (not your main scene) after x seconds. It is (or at least with my KPLs). I use ISY programs all the time to turn on KPL sub-buttons that are set to non-toggle off.

I would create a new scene and add that sub-button to the scene. Create a program saying if that button is ever NOT OFF, wait 30 seconds and turn that new scene OFF.

Motion sensors cannot be linked using Auto Discover. http://www.universal-devices.com/mwiki/ ... ion_Sensor

Typically this is a communication issue between the KPL and the LampLinc. What kind of a bulb is in this lamp? Anything else close to the lamp on its circuit that could be absorbing INSTEON signals? Maybe a surge strip plugged in to the same outlet as the LampLinc? Try unplugging things on the same circuit as the lamp/LampLinc to see if reliability improves. Keep in mind that physical location between devices does not matter in most cases because most devices are not RF. You could have 2 adjacent outlets 4 feet apart that are on completely different circuits.

Here is a Program I use to randomize a bedroom light while I'm on vacation. It utilizes some of the things you are asking about: If Time is 8:00:00PM Then Wait 10 minutes (Random) Set Scene 'MatthewBedLamp' On Wait 10 minutes Wait 10 minutes (Random) Set Scene 'MatthewBedLamp' Off Else - No Actions - (To add one, press 'Action') Sometime between 8pm and 8:10pm the bedroom lights come on, then the program waits between 10 and 20 minutes and turns the light back off.

Hi Rich - When Excel opens, be sure to click the option to enable macros.

Hi Tom - Are you certain your router is still forwarding port 443 (or whatever port you've assigned to HTTPS if you've changed it) to your ISY?

This is normal. You cannot control KPL secondary buttons directly - they must be controlled as members of scenes.

One thing to note is that I don't believe the 1-day model accepts the humidity sensor module from Venstar if that matters to you.

Do you know if you are running 64-bit Windows? If so, consider downloading both the 32-bit and 64-bit version of Java and try again.