apostolakisl

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.

My guess is that you had a poor connection with some arcing under the wire nut. The tinned multi-stranded wires aren't the easiest things to splice. They are nice and flexible, however.

Yes, I think you are saying the right thing. You have 8 items in the if section. All of those 8 items are trigger events, meaning that should they happen, this program will end the "wait" clause, and start over from scratch. If it so happens that the "if" event was true, the timer (wait) will start over, If the "if" event is false, the else clause will run, which in this case is empty.

OK, so you had some phantom links or partial links between the switches, somehow, which are now fixed, I think. I am wondering if both switches are set as controllers. Make sure both switches under the scene on the left hand pane are colored red. When pressing any Insteon switch, the local led's will always ramp at the applied local rate. This is set from within a scene by clicking the device under the scene, or by clicking on the device where it is in the left pane as its own thing. When a switch is a controller, the other switches in the scene will react according to the settings in the scene for each switch. The load(s) will respond according to the behavior of the switch they are attached to. NOTE: the "on level" works the same as the "ramp rate" If you want to create a virtual 3-way where all switches behave exactly the same: 1) Click on the scene in the left pane of the main page of ISY admin console 2) Check the box "apply changes to all devices" 3) Set the desired ramp rate and on level 4) Click on the first device under the scene 5) Click "copy scene attributes. . ." . . . repeat steps 4 and 5 over as many times as necessary for all additional switches. Realize that when you build bigger fancier scenes, you will likely have different devices responding different ways and not all devices will be controllers. This is the cool part of all this. The virtual 3-way you are creating here is kind of boring and may seem a little strange that you need to do these things to get a simple 3 way to work. But, once you start making fancier scenes, you will understand why it is this way.

You have a curious anecdote, but no, that isn't how it works. Insteon commands are not routed, all commands go out on the power lines and are received by any switch in range. If the hop count has not reached its limit, the switch repeats the command. The repeat is timed to coincide with other repeats from other switches by counting cycles on the 60 hz wave. If the command includes instructions addressed to that switch, the switch executes. Otherwise, it is just a repeater. Personally, I have quite a few switches in my house where 2, 3, or even 4 Insteon switches have the hots and neutrals bundled into a single wire nut.

The answer to this is how good a job did you do programming your regular thermostat! Knowing the time off, stage 1, and stage 2 can be helpful in sizing your system. After a years worth of data you will have a reasonable idea if your system is over sized and if so you can opt for a smaller unit whenever you might be in the market for a replacement. Of course you don't need a Nest to know if your system is undersized

Good idea on the parallel wired old fashioned thermostat. Now you just have to worry about the furnace breaking. My suspicion is that the furnace itself is the weakest link. My parents summer home (in northern MI) furnace fan broke last week and if not for their weekly guy doing a home check (who found the house at 34 degrees), bad things could have happened. Somehow their security system never sent the freeze alert it was supposed to. I have the infinity system and unfortunately there isn't a whole lot you can do with them. They use a proprietary comm with the thermostat (RS 485?). You can re-wire it for a typical thermostat, however you lose out on lots of features that help the system run more efficiently and also keeps track of the operating parameters and notifies you of anything out of range.

If ISY hung (which pretty much never happens), wouldn't the thermostat just continue at whatever temp it was before ISY hung?

Thank you Michel for the kind words. I am afraid this topic got a little side tracked from the OP and to some extent I am to blame. But, to the OP's point. You've made it this far. If you hire someone to do your programming, I truly think you will fail to realize the potential of the system. . . by lots. Perhaps some tutoring would be helpful, but I believe you will be best served to do your own programming. The system really works its best when you understand what it can do and then make it fit your personal habits.