apostolakisl

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.

The wiring was my first thought, but seems to be OK by virtue of report that both switches never lose their LED's. I believe the OP is an electrician from another post he put up, so I suspect that he understood the wiring diagram and knew what is what. So, I would re-iterate that the quickest and simplest thing to do at this point is delete the switches from ISY, factory reset them, re-add them to ISY, then rebuild the scene with both as controllers. This will rule out any half links with less work than doing a links table analysis.

Below is turning switch 1 on (19.DB.4A). There is no indication that your switch 2 turned on. You should see a ‘ST 255’ for the other switch indicating it turned on 100% (255 is full on). You see a DON for switch 1 indicating a ‘device on’ command was sent (you pushed the button) received by ISY, and a ST 255 message sent by switch 1 indicating that it had gone to full brightness status (255). But no ST 255 from switch 2 which would indicate that it didn’t turn on. The load is switch 1, so no surprise the light turned on. Did the led’s on switch 2 go up? I presume not since there is no indication of that here. Thu 01/03/2013 10:43:30 PM : [iNST-SRX ] 02 50 19.DB.4A 00.00.01 CB 11 00 LTONRR (00) Thu 01/03/2013 10:43:30 PM : [standard-Group][19.DB.4A-->Group=1] Max Hops=3, Hops Left=2 Thu 01/03/2013 10:43:30 PM : [ 19 DB 4A 1] DON 0 Thu 01/03/2013 10:43:30 PM : [ 19 DB 4A 1] ST 255 Thu 01/03/2013 10:43:30 PM : [iNST-SRX ] 02 50 19.DB.4A 11.00.01 CB 06 00 (00) Thu 01/03/2013 10:43:30 PM : [standard-Group][19.DB.4A-->11.00.01] Max Hops=3, Hops Left=2 Below is you turning off the switch 2 (19.D4.80). Similarly, there is no indication switch 1 did anything. But you seem to indicate that the actual light did shut off, so switch 1 did actually shut off? Thu 01/03/2013 10:43:35 PM : [iNST-SRX ] 02 50 19.D4.80 00.00.01 CB 13 00 LTOFFRR(00) Thu 01/03/2013 10:43:35 PM : [standard-Group][19.D4.80-->Group=1] Max Hops=3, Hops Left=2 Thu 01/03/2013 10:43:35 PM : [ 19 D4 80 1] DOF 0 Thu 01/03/2013 10:43:35 PM : [ 19 D4 80 1] ST 0 Thu 01/03/2013 10:43:36 PM : [iNST-SRX ] 02 50 19.D4.80 13.01.01 CB 06 00 (00) Thu 01/03/2013 10:43:36 PM : [standard-Group][19.D4.80-->13.01.01] Max Hops=3, Hops Left=2 And finally here is you turning switch 2 back on. Again, no indication that switch 1 did anything, but you say the led's on the switch did go up? or do you mean the leds on switch 2 went up? Thu 01/03/2013 10:43:43 PM : [iNST-SRX ] 02 50 19.D4.80 00.00.01 CB 11 00 LTONRR (00) Thu 01/03/2013 10:43:43 PM : [standard-Group][19.D4.80-->Group=1] Max Hops=3, Hops Left=2 Thu 01/03/2013 10:43:43 PM : [ 19 D4 80 1] DON 0 Thu 01/03/2013 10:43:43 PM : [ 19 D4 80 1] ST 255 Thu 01/03/2013 10:43:43 PM : [iNST-SRX ] 02 50 19.D4.80 11.01.01 CB 06 00 (00) Thu 01/03/2013 10:43:43 PM : [standard-Group][19.D4.80-->11.01.01] Max Hops=3, Hops Left=2 It would appear both switches are communicating fine with ISY and only using 1 hop each on their own. Perhaps LeeG could enlighten more? Myself, I would start with the simple task of removing both switches from ISY, factory resetting them, adding them back to ISY, then recreate the scene. EDIT: It looked like Lee did respond as I typed. Same conclusion. But I can't explain the fact that jef000 seems to be indicating the light did switch off when he pushed switch 2 even though the load is on switch 1 and there is no indication switch 1 did anything.

Nearly all of these things can be done using a "wait" command. You might need multiple programs depending on the details. I have illustrated this below separating all the different situations into individual programs, but many times they can be merged into a single program. The root timer program would be this: I have named it program 'x' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 300 minutes Set 'whatever you want' Off Run Program 'x' Else path Else - No Actions - (To add one, press 'Action') To expire the timer If - Put the condition here for expiring timer Then Run Program 'x' (Else Path) Else - No Actions - (To add one, press 'Action') To start (or restart) timer If - Put the condition here for starting (or restarting) timer Then Run Program 'x' (Then Path) Else - No Actions - (To add one, press 'Action') To do something if the timer is active If Whatever you want to cause ISY to check if timer is running And Program 'x' is True Then - Whatever you want to happen if timer active Else - No Actions - (To add one, press 'Action') To do something if the timer is inactive If Whatever you want to cause ISY to check if timer is running And Program 'x' is False Then - Whatever you want to happen if timer inactive Else - No Actions - (To add one, press 'Action') As far as I know, you can't compare the current location of a wait to anything else. Like if the wait had more than 60 minutes left versus less than 60 minutes. Many of the situations I listed above would not require multiple programs, but the multiple program best illustrates how you could make it do anything you want.

To copy/paste, simply right click on the name of the program in the left hand pane on the "program/details" page and scroll down to the last item which is "copy to clipboard". Then paste into forum.

No, I'm not familiar with Honeywell so it wouldn't be of much use.

Since it is all on the nest website, what about software that logs into the website, parses it out (I assume once logged in it puts up a summary page with all the relevant data like actual temp and set temp), then posts to isy variables using REST?