Goose66

Curt, You are confused regarding the difference between what causes a program to be executed (trigger conditions) and what is evaluated in order to go down the THEN or ELSE branches (IF conditions). Believe me, you are not by far the only one. The way it works is that if you have a status condition in your IF, the program will run everytime the status of that device CHANGES. If you have a control condition in your IF (Control Device Is Switched On), then the program will run everytime that command is received from the device (or any command is received from the device if the condition is (Control Device Is Not Switched On). See this thread: http://forum.universal-devices.com/viewtopic.php?t=4639

Not to be flip, but this is like writing code that properly calculates a leap year. Divisible by 4, but not by 100, except by 400. You could put that calculation all over your code only to later realize that the first time divisble by 4 doesn't work is 2100. Will your program be running then? Just make an If range for July through October of 2010 OR July through October of 2011 or July through October of 2012 OR July through October of 2013, and that should hold you for a while.

Let me first say that I have several times expressed the need to seperate the trigger conditions for a program from the IF statement conditions, i.e. what starts the program running versus what conditions are evaluated to resolve the IF statement. Much of the confusion could be eliminated by making this change in the programming structure. Second, with all due respect, Mark James's example is not quite correct. This example confuses the difference between "Control" conditions and "Status" conditions. If your condition is "IF switch is turned ON" (a "Control" condition), then the program will only be executed if the switch is turned ON. The program will not run if the switch is turned OFF. For example: If Control 'Master Suite / Keypad - G' is switched On Then Set 'Master Suite / Left Sconce' On Else Set 'Master Suite / Left Sconce' Off This program will turn the "Left Sconce" ON when the G button is turned ON. However, it will never turn the "Left Sconce" OFF (the ELSE branch), nor will the program status ever be FALSE. The IF condition in this program will always be true, because the program is only run if the G button is turned ON. Compare that with: If Control 'Master Suite / Keypad - G' is switched On And Control 'Master Suite / Keypad - G' is not switched Off Then Set 'Master Suite / Left Sconce' On Else Set 'Master Suite / Left Sconce' Off In this case, the program works more along the lines of what would be expected. This program is run anytime a G button command is sent, be it ON, OFF, DIM, whatever. This is because all commands are needed to evaluate the "IF switch is not switched OFF" condition. Therefore, turning G ON will turn the "Left Sconce" ON and turning G OFF will turn the "Left Sconce" OFF. Contrast all of this with "Status" conditions: If Status 'Master Suite / Keypad - G' is On Then Set 'Master Suite / Left Sconce' On Else Set 'Master Suite / Left Sconce' Off This program will run anytime the status of G changes. So, if G is OFF and G is switched ON, then the program will run and the "Left Sconce" will turn ON. If G is subsequently turned OFF, the program will run again and the 'Left Sconce" will turn OFF. Note, however, that if G is ON and is switched ON again (such as a keypad button in non-toggle ON mode), the program will not run since the status hasn't changed, where the two programs provided above will run anytime G is switched ON, regardless of the previous status. Hopefully this helps you understand WHEN programs run, and thus what the likely outcome of the IF statement will be (THEN branch or ELSE branch). Mark James's comment regarding a WAIT in a program is correct. If the program is in a WAIT and is executed again, then the WAIT is termintated, and any subsequent statements are not executed, in favor of the newly executing instance of that program. The same holds true for a REPEAT.

I did test this and it works. The lights in the scene that are off remain off.

It sounds like you want it to be more sensitive to motion, not darkness. There is a jumper to adjust the sensitivity range, but this defaults to the most sensitive. If you want to adjust the sensitivity to darkness for the Dusk/Dawn feature, the v2 Motion Sensors have a potentiometer to adjust the sensitivity. The v1 sensors do not. You could always disable dusk/dawn and write a program to turn on the lights within a time range when motion is detected. However, this will insert a brief delay between motion and the light coming on.

Try something like this: Put all your interior lights in a scene call "Interior All Lights" and then add a program such as: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 5 times Set Scene 'Interior All Lights' Dim Else - No Actions - (To add one, press 'Action') Running the THEN branch of the above program will reduce the level of all lights in the scene by about 15%. If the lights are off, they stay off.

Assumptions: you have a program activated by an ON command from the motion sensor (MS) that starts a 5-minute WAIT and then turns off all the lights in your bathroom. Also, your lights are always set to one of a number of scenes activated by Insteon controllers. 1. Create a first set of programs, one program for each scene, with a condition set to OR each of the controllers for the scene (there is no way to build a condition that is the status of a scene, unfortunately). The THEN branch for each of these programs would run the ELSE branch of all the others, thus only one of this set of programs would be true at any given time. The true program would represent your last scene set. 2. Create another set of programs, one program for each of the programs in the first set, with a condition for the motion detector command ON (not status) and the status of a corresponding program in the first set of True. The THEN branch for these programs would turn on the corresponding scene, nothing more. 3. In your original motion sensor program, after the 5 minute WAIT and the lights off, put another 15 second WAIT, and then set run the ELSE branch of all of the first set of programs to ensure they are all false. Now, when a scene is turned on, the corresponding program from the first set of programs will be set to true. Then, during the 15-second wait after the original program turns off the lights, if an ON is received, the scene that was on will be reactivated, and the original program will be re-run with a new 5-minute wait timer. If you have an all lights off button or some other such controller, you will also want to change that program (or add a new program conditioned on that button(s)) that also runs the ELSE branch of the all of the first set of programs to clean everything up. One drawback of this approach is that while there is movement in the bathroom, there will be repeated ON traffic for the currently activate scene. This could be cleaned up with additional conditions for the second set of programs, but would make keeping them in sync with the scenes complicated. If your lights are set to random levels (i.e. not predefined scenes), then this is not currently possible. Depending on the implementation, this may be possible once the variables feature is added, however.

The status of the button is only important if you use Status type conditions to trigger your programs. As stated above, use Command type conditions instead and the status won't matter. Same deal for motion sensors that are programmed to only send ON commands.

Dwayne, One scene would be All Lights. This scene could be linked to one RL button ON would turn all lights on, OFF would turn them off. For chart light only or reading lamp only, you could do with programs or scenes. For a chart light only scene, for example, set the chart light to 100% and the other lights to 0% in the scene. Link the scene to an RL button. Turning the button ON turns the chart light on and the other lights off (0%). Turning the button OFF turns all lights off. To do this with a program, use the condition "Control 'RL button 5' is switched on" instead of "Status 'RL button 5' is on." This way, the program will run everytime you press ON on button 5, regardless of the status of the button.

I looked at that link when I was setting my Motion Sensors up with the ISY. That is crazy complex, and, IMO, unecessarily so. A "quirk" in ISY programming is that if the trigger conditions occur again while a program is running and in a WAIT command, the program starts afresh and reevaluates the conditions. This fact makes much of the programming in that post unecessary. Plus, programming your Motion Sensors just to send ON commands also simplifies the programming for the ISY. It sounds like your main concern is not wanting to wait on the delay for the ISY to turn on the light in response to motion. One thing you could do is set the Motion Sensor to just send ON commands, set the motion sense POT to the lowest level (~30 seconds), and have the ISY manage the OFF after a WAIT in a program, such as: If Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Wait 8 minutes Set Scene 'Outdoor / Driveway Floods' Off Else - No Actions - (To add one, press 'Action' Put the Motion Sensor and the light in the scene. Each ON command will turn the light on (indepednent of the ISY) and the program will keep the light on until 8 minutes after the last ON command received. Then, create another program thusly; If From Sunset To Sunrise (next day) Then In Scene 'Outdoor / Driveway Floods' Set 'Outdoor / Garage Keypad-Driveway Flood' 100% (On Level) Else In Scene 'Outdoor / Driveway Floods' Set 'Outdoor / Garage Keypad-Driveway Flood' 0% (On Level) This should accomplish what you want, albeit producing some unecessary Insteon traffic during the day when motion occurs and the light is turned "ON" to 0%.

Make sure your program is responding to "Control 'Motion-Sensor' is switched on" and not "Status 'Motion-Sensor' is on." This way your program will get every "On" sent from the motion sensor. If the program is running and receives a subsequent ON, then the wait counter will reset, and the light will stay on until 30 seconds after the last received motion. Below is a sample program that uses these concepts: If From Sunset To Sunrise (next day) And Status 'Outdoor / Garage Keypad-Pizza Delivery' is not On And Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Set Scene 'Outdoor / Driveway Floods' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods' Off Else - No Actions - (To add one, press 'Action') You can put your time range in place of "From Sunet to Sunrise" and 30 seconds in place of the 8 minutes. Two things. If your motion sensor is set to only send "On" commands, it will always have a status of On. Also, if the time range boundary condition (in my case at Sunrise) occurs while the program is running, then your light may be left on. If have another program that runs at Sunrise to cleanup all my outdoor lighting, including the driveway floods.

That brings up another question: What is stored in the 32KB memory on the PLM? I would assume that there has to be a device database in order for the PLM to report events to the ISY (the Insteon security). Is this just a link database similar to a SwitchLinc, etc. or is it something different? Are all the scenes defined in the ISY stored in the PLM's memory, and is the PLM a controller in every scene on your Insteon network?

I do have a humidistat installed in my T1800. On the thermostat itself it seems to work OK, although we just finished our first winter with it installed and the humidity constantly read in the 32-35% range, which seems unlikely when the humidifer is not running. Maybe the humidistat is bad or not seated on the circuit board correctly. The ISY, on the other hand, shows the humidity at 0%, in the 32-35% range, or 150%. I have never analyzed the log entries to determine if the V2 Insteon adapter is reporting those outlier values (0 and 150) or if the ISY is just losing track somehow.

In addition, everytime I view the log, it is full of humidity reports from the thermostat. Every one minute or so, all day long. I wish there were someway to control the reporting in the v2 thermostat adaptor. If humidity is not going to work in the ISY, then I would just assume not have humidity reported at all. As long as the thermostat can control my humidifier, then I am fine. Overall, the Venstar thermostat seems like a good device. And while the ISY support for the Insteon thermostat adapter is lacking somewhat, it is clear that the v2 Insteon adapter itself is a much a piece of junk as the v1 adapter. I wish I could hardwire my ISY to the thermostats with RS-422, and take Insteon out of the equation altogether for these devices.

My fan control always shows "On" as well in that view. The Cool Control / Heat Control will show "On" when running and "Off" when not. But it will have no state if it hasn't cycled since the last reset of the ISY. My humidity does not report correctly, sometimes reading 0%, other times 150%, and other times 32%. Each of these values never match what is shown on the thermostat.

Got it. Perhaps when the SHN issues are ironed out, we can pursue this further, because I have the same issue but have shyed away from overly expensive mutli-zone controllers and systems. However, does the ISY support automatic, periodic polloing of any devices? For example, could the firmware code supporting the EZIO2X4 be written to periodically poll for the value of the analog input and change the state internally (thus potentially triggering a program) if the value changes? It looks like the "alarm value" that can be programmed in the EZIO2X4 only works in one direction.

The problem, though, will be in the ISY programming for such a setup. Ideally you would want the temperature setpoint for each room to be compared to the current reading of the Venstar, which is going to require variables and probably the ability to do some math. In addition, even if the ISY allows access to the current values of the EZIO analog inputs, you are going to have to figure out how to poll for these on a periodic basis.

How about two EZIO2X4s connected to temperature-sensing IC-chips (e.g. http://www.smarthome.com/1523/Temperature-Sensing-IC-Chip/p.aspx) mounted in small plastic boxes in each room. If you design a circuit board for these with screw terminals and a .1mf capacitor across the output and ground, order 4 for me as well. Better yet, how much you want to bet that the Venstar remote temperature sensor (http://www.smarthome.com/30421/Venstar-Indoor-Outdoor-Remote-Temperature-Sensor/p.aspx) is not exactly that: a temperature sensing IC-chip mounted to a circuit board in a plastic case that receives a 5V Vs and returns 0-5V signal based on the temperature.

Simplehomenet has a number of devices (e.g. EZIO8SA) that offer analog inputs with 1024 point resolution. Most of these have relay outputs as well. It seems like one or more of these devices could be used to both read the room temperatures and to control the damplers. I do not know what support for these devices exist in the ISY. However, the solution may be more complicated that you think. First, you probably want dampers on both the vents and the returns. This will substantially increase your cost. But, if you are sending air to only one room but all returns are active, then you create negative pressure situations in the other rooms that will suck air under the doors. This may cause doors to "pop" open, whistling or other air noise, the nasty black stuff on your carpet under the doors, shortened lifetime of your HVAC unit, etc. Further, if you are going to let the ISY control your multizone HVAC over Insteon, I suggest installing a negative pressure damper on a return from the common space (over the catwalk) and as well as a vent over the catwalk. This may mitigate circumstances that could damage your unit, such as the Venstar commanding HVAC to a room but the Insteon signals to the dampers not reaching their destinations. You don't want to have the unit running and all dampers closed! Lots of online dicussions around this. I suggest you read up and let us know what your final design looks like.

You like that one? A KPL button that, if on, turns on the driveway floods, the front walk, the front porch, and brings the front accent lighting to 100%. Motion in the driveway, instead of activating the driveway floods, activates the foyer light, to signal arrival of the pizza. When deactivated (or after two hours), it returns the outdoor lighting to the nightime lighting state. Now if I could just get the ISY to send our standard order over the Internet, that would be sweet. Of course, my 4 year old would be ordering 5 or 6 pizzas a day (at the press of a button, literally).

The differences affect both when a program runs, and what the outcome of the IF statement will be. While my understanding/experience with how it works doesn't always jibe with the sample programs you see on this site, here it is: If you use a Control-type condition, e.g. "Control 'Outdoor / Driveway Motion-Sensor' is switched On," then your program will only run with ON commands from the motion sensor. OFF commands from the motion sensor will not trigger the program. Thus this condition in an IF statement will always resolve to True since the program only runs when it is true, and a program with only one such condition will always run the THEN branch, never the ELSE branch. If you use a Status-type condition, e.g. "Status 'Outdoor / Garage Keypad-Pizza Delivery' is On," the program will run on any change of status of the KPL button registered in the ISY, whether by a physical button push, a scene command, a direct command, etc. This condition may evaluate to either TRUE or FALSE, depending on the actual status of the device in the condition. Thus programs with Status-type conditions may run either the THEN branch or the ELSE branch, depending on the outcome of the IF statement.

The Insteon Thermostat Adapter will not work with the SignalLinc RF. You must have Access Points. I suggest replacing your SignalLinc RFs with a pair of refurbed Access Points. You will need the Access Points for any Motion Detectors as well.

As to my suggestion to seperate program trigger conditions from IF statement conditions made on page 2 of this thread, I had a further idea of how it may be implemented while minimally impacting existing libraries of programs: What if, down in the "Add to Program" section of the program detail screen there were a checkbox that read "Triggers Program." The state of this checkbox would be stored in the XML with each condition. Those conditions that had "Triggers Program" checked would be both trigger conditions for the program and be evaluated in the IF statement. Those conditions that did not have "Triggers Program" checked would only be evaluated in the IF statement but would not trigger the program to run. The default for Triggers Program would be true, and all existing programs would work in the new model just as they do now. Just another thought.

Well, operating under my standard "believe but verify" approach (as my wife puts it), I went through my programs in the ISY and it turns out that I don't ever use 'status is On'; only 'status is Off' and 'status is not Off'. So my understanding that status of On was anything other than status is Off was not only incorrect, it was unfounded. I was wrong, you were right, and I am sorry (my wife would be so proud)

I see why this is confusing, because my experience is that status is ON is true for anything but OFF. I could be wrong, thourgh. For what you are trying to accomplish might I suggest: 1) For your program that turns the light on before sunset (call it "TrackOn"): If Time is Sunset - 5 minutes And ( Status 'Rec Room Track' is On Or Status 'Rec Room Track' is Off ) Then Set 'Basement / Playroom Track Lights' 90% Else - No Actions - (To add one, press 'Action') 2) Then for the program that turns the light off If Time is 12:22:00AM And Program'TrackOn' is True Then Wait 40 minutes (Random) Set 'Rec Room Track' Off Else - No Actions - (To add one, press 'Action') In this scenario the lights will always be set to 90% at 5 minutes before Sunset and teh program TrackOn will be set to true. However, any subsequent status change, whether turning them to 100% from the switch or turning them off, will trigger the "TrackOn" program and set it to false (because the time is not 5 minutes before sunset). At 12:22, the second program will only turn the lights off if the "TrackOn" program is True, i.e. the lights were set to 90% at 5 minutes before sunrise and have not been changed since.