brad77

I have used both. Either way works the same in my configuration. They just toggle the sensor status when the door is open versus closed. I am set up so that the light is ON when the door is open. I felt it was more consistent with the way the ISY displays the status, showing ON in red. I'm not sure, as Smarthome's manual doesn't jive exactly with the ISY's description of the options, so here's a screen shot of my setup on firmware 2.7.9a: Hope that helps!

For what it's worth, my IOLinc is in Momentary B mode, and I do not set the relay to off at any time. I do however have a program that queries the relay 30 seconds after it is turned on so that the ISY knows the correct relay status. I wait 30 seconds to prevent colliding with any signals sent by the IO Linc's sensor as my door takes about 10 seconds to close. 30 is probably overly long, but it works.

I agree with Gary. A LampLinc is a dimmer, and may do funky things with inductive loads like a fan.

From the TED troubleshooting guide: TED communicates over the existing power lines in your home using Power Line Carrier Technology. TED digital communication signals are imposed over a carrier frequency of 132 kHz which is transmitted during the zero crossing of the power line 60 Hz signal. INSTEON operates at 131.65 kHz. FilterLincs are designed for X10, and so operate at 120 kHz. This is apparently sufficiently close the INSTEON's frequency, so they should work for both. I would assume that they would help with your TED as well as it is very close the the INSTEON frequency. You may want to use the AF120 (link), which has an advertised range of 30 to 200 kHz. Keep in mind that this device is somewhat large, and can be unsightly. It does, however, have an easily replaceable fuse. If you opt for the FilterLinc, make sure to refer to your air filter's specifications or test your motor's power draw if possible (including a possible spike upon startup). Do this to determine the appropriate size FilterLinc to get. I've blown a fuse on one before, and replacing it is not an easy task. You might want to pick up a Kill-A-Watt for that.

As oberkc said, your program's IF condition is getting re-evaluated when you turn the lights off manually, switching the lights back on. It's also worth mentioning that if you set the motion sensor into "on only" mode, your lights will turn on indefinitely as the motion sensor will never notify the ISY when it is no longer detecting motion. I would use Control here as well. This will then respond only when the motion sensor first detects motion (and again when motion is detected in the future after the countdown is reached).

The ISY will use the non-secure port (port 2101 by default). Your ElkRP software will likely use port 2601, which is the secure port. You just want to make sure to have both enabled if you want to use your Elk with your ISY. For what it's worth, I have been using 2.7.9a with my Elk and haven't had any problems as of yet.

++ Kudos Michel!

Pretty much. Here's an example of a program that I use with a RemoteLinc: If Control 'RemoteLinc: Button 1' is switched On Then Set 'Some Light' On Else - No Actions - (To add one, press 'Action') There's a bit of a delay, but it works great.

Here you go: If Time is 3:00:00AM Then Set Scene 'My Devices' Query Else - No Actions - (To add one, press 'Action')

Jason- It sounds like your approach is working great for you. Please don't take my comments as suggesting that you should do something different. There was a bit of discussion earlier about setting the unit to ON-only mode to save battery as it seems to eat batteries and the low-battery indicator doesn't seem to work reliably. I personally tried this and after a bit of testing discovered what I mentioned in my previous post, which basically made it cumbersome for me to use the ISY to turn the lights off. Additionally, by switching the sensor to ON-only mode, the ISY never changes the sensor status as it no longer broadcasts a message when the motion timeout has expired. I guess one person's feature is another person's bug in this case. Oh, and I realize that it isn't a bug...I'm just being facetious. On a side note, I prefer to have my MS linked to lights as I find the delay to be too long when the ISY handles the task, but that's just my personal preference.

This might be a dumb question, but can you confirm that the ISY is still at the same IP address by pinging it? Have you also tried rebooting your ISY? If its telnet service is not responding, it's not a client problem.

I wish that there was a jumper for this. The problem I've found with it is that while it doesn't trigger another on command during the countdown, it extends the timeout period each time it detects motion. Consider the following: 1. MS is in on-only mode with 1 minute timeout. 2. ISY program responds to MS sensor detection and turn off lights after 5 minutes. 3. Motion triggered, light turns on, both MS and ISY countdown begins. 4. Motion continues in monitored area for over 5 minutes. MS keeps resetting its timer each time it sees motion. As a result, the MS never sends another on command that ISY can hear. 5. ISY timeout expires, leaving person in the dark. Because of this, I do not use the ISY to manage my MS timeout periods.

Just wanted to chime in that threads like these are why I check this forum so often. Great info. I've bookmarked this for future reference.

Thanks, Michel. Will do. I thought that closing the browser and clearing the cache was overkill. Glad you found the issue.

Correction: After adding, removing and updating a number of entries in IE, the notifications recipient field stopped updating. Then after closing the browser, clearing its cache, then clearing my Java cache things worked again for a short time. Rinse and repeat. I cannot tell exactly what is causing it, but I can get it to happen reliably.

Update: I tried updating notification entries in IE instead of Firefox and was able to add addresses successfully. I will continue to experiment to see if I can identify why it's happening for me. Thanks!

Michel- The migrated entry was indeed there after upgrading. In my experimentation, however, I deleted it. I am now unable to add any addresses. Following the steps I described, I am able to create notification entries, but I cannot add email/text addresses to them. Thanks for working on New Year's Day!

I can confirm problems with adding emails/notifications. When I add new notifications (or edit an existing one), my changes are not saved. To reproduce: 1. Click Add 2. Enter a name in the Name field and hit the Enter key. 3. Click on "n/a" in the Recipients field. 4. Select "Regular Email" from the list and click Add. 5. Enter an email address and hit the Enter key. 6. Click OK. Upon clicking OK, the Recipients field remains "n/a". Subsequently clicking on the "n/a" opens a window without any addresses in it.

You can use programs as flags, however. Check the wiki for more details.

Ah, yes. iLinc. I forgot about that one. I'm not an iPhone user myself.

I was describing how to make a scene. If you already know how to do that, there's nothing new to see there. When it comes down it, scenes don't require the ISY and programs do. Scenes provide INSTEON devices with a way to talk/coordinate with each other. Although scenes can be setup and manipulated with the ISY, the devices in the scene communicate directly with each other. Programs are a construct of the ISY and do not exist in the world of INSTEON. That is to say, program logic cannot be stored in an INSTEON device. Programs will allow you to add any conditional logic you might need along with more complicated command sequences. They can be run on demand or in response to an event, schedule, etc. On the downside, programs will not respond as quickly as a scene if they are triggered by an INSTEON event (turning a switch on, for example). Lastly, you cannot link programs and scenes. Does your wife need to toggle the garage door opener or conditionally open/close the door? If it's the former, all she needs to do is activate the Garage Door Opener's relay (turn it on) or activate a scene that does the same. Or are you thinking that she would want to close the door if she were away from the house but couldn't be sure if it were indeed open? For the door programs we're talking about, you should always use Run If. You should probably familiarize yourself with how programs work, which you can find in the Wiki. It has a great rundown of what all of this means. In a nutshell, Run If makes sure that your condition is evaluated. Then, the THEN or ELSE portion of your program runs based on the result of evaluating the condition. In the garage door example, the door close program only toggles the relay if the door is already open. Running the THEN or ELSE of the program bypasses the condition and simply does whatever is listed in the THEN or ELSE part of the program. Make sense? I agree with you on the ISY web interface. It's definitely geared towards the more advanced user/admin. I wouldn't even consider having my wife use it. I'm sure that she'd be able to figure it out, but it's just too complicated for her use. She'd have to sift through dozens of programs, scenes and devices. You might want to consider a different interface for her, like Touchswitch. It installed directly on the ISY and provides an alternate web interface. It doesn't support programs, but it can provide a more intuitive interface for checking the status of your garage door sensor. It also looks better on an iPhone. Note that Touchswitch requires the Networking module, which I believe comes at a discount when you purchase them together.

I don't have one, but yes, you can make it a scene. Make the IOLinc relay a responder and your keypad button or other switch a controller. Yes. Here is the program: If Status 'Garage Door Opener' is On Then Wait 30 seconds Set 'Garage Door Opener' Query Else - No Actions - (To add one, press 'Action') My garage door takes about 15 seconds to open/close, so I wait for it to finish before querying so as not to collide with any signals from the sensor's status change. 30 seconds is probably overly long, but I can live with it. While I'm at it, here are the conditional programs: Conditional Open: If Status 'Garage Door-Sensor' is Off Then Set 'Garage Door Opener' On Else - No Actions - (To add one, press 'Action') Conditional Close: If Status 'Garage Door-Sensor' is On Then Set 'Garage Door Opener' On Else - No Actions - (To add one, press 'Action') Make sure to uncheck the "Enabled" checkbox on these programs to prevent them from firing under "normal" conditions. You only want to fire these from other programs. In that case you would always use Run (If). No problem!

With the way I have it configured, the "on" command on the relay will always activate the door opener. There's no need to get complicated if all you are going to do is raise or lower the door with the press of a single button. Just assign the state of the sensor to the light on the button and have the button activate the relay. After two seconds, the relay will turn itself off again. Press again to toggle. On my ISY, I have a query that runs within 30 seconds to query the relay just so the ISY has the correct status as my IOLinc does not send a broadcast when the relay is turned off. That said, I do have two programs that I use to raise or lower the door conditionally (the "close door" program always closes and the "open door" program always opens). It comes in handy from time to time.

I'm not sure. I use Momentary A and Momentary: Both (which I'm assuming is Momentary , but I'm not linking my IOLinc to a switch or keypad.

Use the black and red wires instead of the black and green to switch from normally open to normally closed. For future reference: Green: Normally open (NO) Red: Normally closed (NC) Black: Common Refer to the owner's manual on the contact sensor.