apostolakisl

Yes, it does seem like a relay should be replaceable with a dimmer (but not vice-versa). Is this truly a link table issue or is it a function of the ISY just not letting you do it?

My understanding is that "replace with" simply copies the links table over. So if the new device accepts the same links, then it should work. Feel free to correct me if I am wrong on this point, but this is what my experience would indicate. I have also used this to replace icon dimmers with switchlinc dimmers.

UD I think was trying to make the world simpler by providing their own mail server to all ISY owners (thus no settings for the user) (and except when their server is down ) Your reliability is now subject to your mail server instead of UD's. There are of course other reliability issues like a stable internet connection , but those issues would be the same regardless of what mail server you use.

Yes, the replace function works for that. If there are problems, I certainly had none. I replaced several of mine that way.

Are you using your own email server or are you using ISY's default? Last I checked, ISY's server was offline. That started a week or two ago. Try putting in your own smtp server settings. Also, make sure to follow the format listed for the "from" section.

Why don't you wire it up to a lamp or something simple and obvious like that. Then you can turn the relay on/off from ISY and the lamp on/off at it's own switch (which would be simulating the thermostat flipping on/off) and I think you'll soon figure it all out.

Yes, that is about what I have heard. I am not aware of ANY insteon switch rated by UL or anyone else to use ground as a neutral. While power draw (when not loaded) may be minimal, I still think it a bad idea to hook up insteon other than how shown in the instructions, as designed. I am not recommending it.

I understand that some devices are, in fact, as you describe...using ground as a neutral for very low-power uses. Speculation on some of the other sites I read suggest that it is because these types of devices were becoming more common that the code was revised to require neutral in each switch location. Insteon switches draw about .7watts (5.8ma). Not sure what UL has to say about that. Of course a load bearing Insteon runs the full load to neutral when on, so that would definitely be off limits. I suppose I could put my amp meter on the ground and see what that maestro switch does.

I would like to point out that it is possible (and fairly common) for the load and hot to be in one (switch or junction) box with just a run of 14/3 to the remote switch box(s). I had two 3 way circuits in my place wired this way before Insteon upgrades. -Xathros I just installed a Maestro Lutron MS-OPS2 switch in my office. It is an occupancy sensing switch. It appears that it uses ground to keep it working. The unit specifically says in the instructions that it won't work without ground connected and it has no neutral. So, it appears that a UL listing is possible leaking power to ground. Perhaps it is only a few micro-amps and that is why it is allowed.

As has been mentioned, I think your likely to be satisfied by adding KPL1 button D as a responder to scene 2. The question then is how you have sw1, 2, and 3 setup. Basically, to what scenes are they responders and controllers. For example, if all 3 are responders only, when you shut them off at the switches, none of the kpls will go off. If sw1 is set as a controller to scene 1, then kpl1,d will turn off, but the other kpl will stay on. If all 3 control scene 2, then shutting any of the 3 off will shut down everything. If SW1 controls scene 1, then shutting it off will turn of kpl1d, but everything else will stay on. There is no perfect way to do overlapping scenes because the logic will always find a way to contradict itself somehow in some scenario (depending on your personal brand of logic).

This post of mine regarding a different but similar question should help. Two concepts: 1) Triggers 2) True vs False after the trigger 1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers. - - Control: Triggers whenever the action listed is taken. ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger) - - Status: Triggers with a change in status. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger. - - State variables: Trigger on any change in the variable's value. - - From:To times: Both the from and the to time itself is a trigger. - - An outside program or manual "run if" is a trigger 2) Once a trigger event occurs, then EVERY line is evaluated. - - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not". - - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true. - - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered. - - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise. Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on. Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true Multiple lines connected by "AND" statements will be false unless all lines are true. Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

According to the diagram above, the switches are using both of the traveler wires. It's just not alternating the power from one to the other as in a "dumb" 3-way. I assume the one traveler is functioning as a communication wire and the other traveler is carrying the load. It must be as oberck said, since neither the master nor remote are connected to neutral. It would work to run to ground, but that would certainly not be UL allowed.

This is the jist of it. 1) There are 2 wires that are called travelers, they connect the two boxes together. The wires may be one continuous run or they may be spliced at the light fixture (in which case the colors won't necessarily be the same) 2) The one box has a 3rd wire which goes to the load (the light fixture) 3) The other box has a hot (120vac all the time) 4) Lastly you have a neutral which isn't connected to a normal 3 way switch and in older homes may not be present (which makes using Insteon much harder). Your goals 1) Have neutrals at both boxes. Hopefully already there tucked in the back of both boxes. If one box has a neutral and the other does not, you can use one of the 2 travelers to carry neutral over to the other box. 2) Have hot at both boxes. This is not going to be the case naturally. You will use one of your traveler wires to bring hot from the one box to the other. 3) One box has the load, this is fine as is. According to your picture of your old swithces. The master: 1) Has a blue and red wire coming out of it. These connect to your travelers. Label them as such. 2) Has a black wire. This is connected to your hot, label it as such The Remote: 1) Has 2 blue wires, one is connected to only one wire. This is one of your 2 travelers. Label it. 2) The other blue wire has 2 wires connected. One is a traveler and the other goes to the load. You need to figure out which is which. To figure out which is which, the wire color might do the trick by matching up with the color at the other box, but not necessarily. Figure it out: 1) Turn off power. 2) Unhook all of your wires (you already have labeled the ones you know) 3) Splice together the 2 travelers at the Master box. 4) Put your ohm meter onto the known traveler at the Remote box, and then touch the other lead to each of the 2 unknowns. The wire with 0 ohms is the traveler and the one with infinite is the wire to the load. Label them. Install Insteon 1) With power still off. 2) At the master box, - splice Insteon black, hot, and one traveler together - Splice Insteon white to the neutral - Splice ground to ground - Cap the Insteon load (red) wire - Cap the unused traveler 3) At the Remote box - Splice the traveler wire that is now hot, to Insteon hot (if you don't know which is which, just pick one. - Cap the other traveler - Splice the Insteon load (red) to the house load - Splice ground to ground - Splice Insteon white to house neutral. 4) Turn power on. If the switch at the remote location does not turn on its led's you guessed wrong on which traveler. If it lights up, you got it right. - If you guessed wrong. Turn off the power, and at the remote box, splice the other traveler wire to the Insteon hot and cap the unused wire. 5) Turn power on. Now it should work. If it doesn't, you messed something up and you need to start over.

Your Elk logic is flawed. You are turning user specific outputs off when someone arms and on when someone disarms. This will work fine as long as each arm/disarm cycle is done by the same person. But anytime a second person gets involved, you will have your on/off status' all mixed up. You should just have the Elk do a 1 second "on" for each persons output regardless of whether it was an arm or disarm event. For example if becky turned the system on, then someone else turned it off, then becky turned it back on, then the folloiwing program will not trigger, the second time becky arms the system. If Elk Output 'Output 065' is Off Then Send Notification to 'My text' content 'Becky Out' Set Scene 'Becky Lights' Fast Off Else Send Notification to 'My text' content 'Becky In' Set Scene 'Becky Lights' Fast On The output will have been off from the first time she armed it, but since she didn't disarm it, it will stay off. When she arms it again, it will already be off, thus nothing changes and no text is sent. If instead you did a momentary on. Whenever Elk is armed and last user was becky then turn output 65 on for 1 second Whenever Elk is disarmed and last user was bekcy then turn output 65 on for 1 second If Elk output 65 is turned on And Elk is disarmed Then send text disarmed becky Else - - If Elk output 65 is turned on And Elk is armed Then send text armed becky Else - - This will also fix your issue with output status at startup since they will all be off

OK, I think I am not reading what jeff wrote correctly. I had asked the question: "Click back and forth on/ off giving a few seconds between clicks. Both switchlink LED's should ramp up/down at the desired ramp rate and to the desired on level. Also, the light fixture itself should match." And am not sure that is what is answered refers to "both".

I can't say that I have ever seen a load switch have its led's ramp up slowly but yet have the actual load come on instantly. Other than a defective switch, I don't know why that would happen.

No, I have not experienced this. I use a KPL next to my bed to arm the system and it happens faster than I can turn my head to look at the alarm keypad on the other side of the room. Currently running 3.3.6 I had issues when I went to SSL, but that was fixed by removing the xep username password. I am still a bit uncertain what impact removing that has on overall security. The only authentication method now is the user code.

Since you have changed the program to "control motion sensor on" instead of "status motion sensor on" it really doesn't matter if you have the motion sensor set to time-out with an "off" command. The program as you have it will ignore an "off" statement from the motion sensor both as a trigger and as an evaluated item. In fact, since you only have "control" statements and since none of them are "is not", this program will run "true" every single time (at least every time it self triggers, an external trigger will always run false). And if I understand the intent of this program correctly, that should be just fine. However, if you choose to use the motion sensor in another program or if you choose to link the sensor directly to some other device, it may make a difference. It just all depends on what else you may want to do with it.

Do the following: From ISY main screen: 1) Click on the scene name in the left hand pane 2) You should see the scene pop up in the right hand pane. At the bottom you should see several buttons (on, fast on, off, fast off, etc) 3) Click back and forth on/ off giving a few seconds between clicks. Both switchlink LED's should ramp up/down at the desired ramp rate and to the desired on level. Also, the light fixture itself should match. Let us know what happens.

Your last statements were correct. 2 concepts 1) Triggers 2) True vs False after the trigger 1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers. - - Control: Triggers whenever the action listed is taken. ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger) - - Status: Triggers with a change in status. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger. - - State variables: Trigger on any change in the variable's value. - - From:To times: Both the from and the to time itself is a trigger. - - An outside program or manual "run if" is a trigger 2) Once a trigger event occurs, then EVERY line is evaluated. - - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not". - - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true. - - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered. - - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise. Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on. Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true Multiple lines connected by "AND" statements will be false unless all lines are true. Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

No. None of the "control" statements will run false if it is the trigger as you have written it. When a control statement is the trigger, it will only run false if you use "control is not" Every single line in that program needs to be false for the program as a whole to be false (because all are connected by "or" statements). So, every "control" condition that wasn't the trigger (the button wasn't pushed) will be false. .. no problem there. The one button that you do push, must also be false and that can only happen with the action you took followed by "is not".

The program triggers when the temperature crosses the threshold. My guess is, that it was already below 32 when your first created the program, so it never crossed 32 and thus never triggered. By adding the from/to times, you created 2 more triggers which forced the temp evaluation.

Because everything is connected by an "or". This means every statement must be false. When you force a run by executing the "if" clause from outside of the program, you actually can have all the statements be false. 1) All of the "control" statements will be false. I explained how that works in the previous post 2) The "status" statements could be true, but if there is no motion, then indeed they would be false. Thus, all statements are false, the else runs. When you triggered the program by pushing the "media middle" button, that line of the program was true. Thus the whole program is true since you used "or" everywhere. If you changed the last line to "is not", and on your way out of the room pushed "media middle" off, then it would run false (assuming the motion detectors weren't picking you up.)

"control is switched" can never be false, either it does nothing, or it is true (if it is the only trigger in a program) "control is not switched" can never be true, either it does nothing, or is false. (if it is the only trigger in a program) "control" statements are a trigger whenever the exact thing listed after that happens: ie , control is switched on requires an "on" press. Any other press is ignored. So if you push "on" it triggers, and it evaluates true control is not switched on . . . when "on" is pressed, it triggers, but "is not" causing a false condition and the else runs. If the program runs for some other reason than the "control" item happening, it will always be false, because the switch wasn't acted on at all, let alone how it was listed. Your "status" statements can evaluate to false. Anytime the status CHANGES it triggers, and if the change ends up as true, the "then" runs, and vice-versa. So if the light is off and you push on "status is off" runs false (it changed from off to on, this triggered the line, but it is not off, so it is false Unlike control, however, "status" can evaluate to true just sitting there. If the program triggers for any reason, a "status" line can be true. A control line, in contrast, can only be true by directly doing what it says. In other words, a control line must be the trigger and you must have done, and by definition thus it will run true for "is" and false for "is not" Since your program is filled with lots of "or's", only a single item need be true for the whole thing to be true. When you left the room, you said you turned "media middle" off. This triggered the program as per the last line of your program, and indeed you pushed the "off" button, which is just what it asks for, thus it is true, and the "then" ran.

Your load switch ramp rate in the scene is set to the minimum (.1s). Click on the scene and you should see both switches in the bottom of the right pane. Slide the ramp rate bar for the load switch up to whatever it is you want. Your ramp rate 'applied locally' for both switches is fine.