Goose66

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.

I probably could experiment with this, but I will just ask instead: If a program is in a folder with a condition, and the program is triggered while the folder condition is true, then the folder condition subsequently becomes false, does the program status of True or False get preserved from the last time it was executed? Or will the program status be changed to false when the folder condition becomes false?

If don't think you can specify "Time Before Sunrise + 30 minutes (same day)." You could say: On Mon, Tue, Wed, Thu, Fri Time is 6:50:00AM AND Time is Sunrise - 30 minutes but that condition would never be true unless Sunrise - 30 minutes occured exactly at 6:50 AM. The folder option could be done, but that is a layer of complexity not desired. What I wound up with was: If On Mon, Tue, Wed, Thu, Fri Time is 6:50:00AM And From 12:00:00AM To Sunrise + 30 minutes (same day) Then Set Scene 'Master Suite / Wakeup' On Else - No Actions - (To add one, press 'Action') The drawback to this solution is that the program runs at 6:50 AM (as intended) but also runs at 12:00 AM and Sunrise + 30, setting the last program result to false. If I wanted to determine if the scene was actually turned on at 6:50 at some later time in the day, I would be out of luck. Again, just trying to document for everyone the virtues of being able to seperate trigger conditions from IF statements.

Here is another example of where I need to be able to specify trigger conditions seperately from IF conditions: I want to setup a program that triggers at 6:50 AM every morning and turns on a scene with a 8 minute ramp up of lights in my bedroom (an alarm clock). I don't want to do it if its at least 30 minutes after sunrise, however, because I will presumeably already be awaken by the light from outside. So what I want is: Trigger: Time is 6:50 AM IF: > 30 Minutes after sunrise Then: Turn on Wakeup Scene Here is what I got: If On Mon, Tue, Wed, Thu, Fri From 6:50:00AM To Sunrise + 30 minutes (same day) Then Set Scene 'Master Suite / Wakeup' On Else - No Actions - (To add one, press 'Action') I have no idea what the outcome of this will be? If Sunrise +30 occurs before 6:50:00AM, will the IF statement become True and turn-on the scene? This may be a good one for a folder with a Sunrise + 30 condition. But, then I would have to have a folder for every different status time I might want to check. If I could split this into a trigger (time is 6:50) and a status check in the IF statement (Time is < Sunrise + 30 min, that would be ideal.

From you observations, it seems like having only the Run "Front Final Shut Down" in the Then branch of "Re Dim Final" does not cause the loop. My further question is, why not? Was it having a second, subsequent Run program statement that caused it to loop? Would it have looped if there was a WAIT statement next? What if there was a command next? We could answer all these questions if there were some visibility into how the program engine worked (I think Rand is working on something).

In furtherance of the OP's original question: Since, as discussed above, the motion program gets evaluated at both an ON from the sensor AND at Sunset and Sunrise, why not put an OFF command in the Else brach of the program to handle the boundary condition. If From Sunset To Sunrise (next day) And Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else Set Scene 'Outdoor / Driveway Floods on Motion' Off This way, unless there is a motion sensor ON sent precisely at Sunrise, the flood light will be turned off at Sunrise and subsequent ONs from the motion sensor will be ignored. This seems to handle the boundary condition without the need for another program. Thus you have 1 program to respond to your motion sensor instead of 3, and no need for folder conditions.

I understand what you are trying to do (although I agree it is pretty damn complicated way to go about it). You have are 5 programs in the Re Dim folder that are all intended to be kicked-off at precisely the same time: whenever ReDimSwitch is set to True. Each program in the Re Dim folder has a corresponding normal mode program that establishes a dim level at a certain time. When the ReDimSwitch is set to True, one of the 5 programs conditions should be true, and that program restores the dim level by executing the Then branch of the correspoding normal mode program. A couple of questions: 1) How is ReDimSwitch activated? Is it linked to an Insteon switch, such as a KPL? 2) Is ReDimSwitch program in the "Re Dim" folder? I think your original supposition is correct, and this is indeed the lengthy and laborious topic of two other threads: http://forum.universal-devices.com/viewtopic.php?t=4236 http://forum.universal-devices.com/viewtopic.php?t=4332 What seems to be happening is that when the Re Dim Final runs the Then branch of the corresponding normal model program ("Front Final Shut Down"), it changes the status of the program to True (even if it was so already) causing the Re Dim Final to be run again, pre-empting execution of the previous instance of the program in favor of the new executing instance of the program. This creates your endless loop. What surprises me is, according to the Wiki and Rand, this shouldn't happen unless there is a Wait or Repeat in your program. Otherwise, the program should have behaved just as you expected. I think we need further clarification on how the program engine works as to evaluating conditions and triggering programs.

Also, my understanding is that much of this is only applicable if the THEN or ELSE branch contains a WAIT or a REPEAT. This was mentioned before, but was lost in the last few posts. So, just to make sure we are all clear, the only time a subsequent triggering of a program may occur that would pre-empty the currently running program is when there is a WAIT or a REPEAT, I think.

I wish they had offered an upgrade for those, similar to the V2 thermostat adapter.

To add to the original thread topic, most of my motion detectors are simply set to turn on the lights directly and turn them off after set period of time. Having the motion sensor and light in a scene seems to me to provide more instantaneous light on motion than the use of a program. The motion detector has a dusk/dawn detector that can be set as well. However, as you know, this may not work if the light is in the room with the motion detector, because the dusk dawn sensor may reset after the light is on for about 4 minutes (in my case). This was the problem I had on my driveway sensor. To alleviate that, I have implemented the following program: If From Sunset To Sunrise (next day) And Control 'Outdoor / Driveway Motion-Sensor' is switched On Then Set Scene 'Outdoor / Driveway Floods on Motion' On Wait 8 minutes Set Scene 'Outdoor / Driveway Floods on Motion' Off Else - No Actions - (To add one, press 'Action') However, as you know this creates the "boundary conditon" described above where the light may be left on at motion within 8 minutes from sunrise. To couteract that, I have another program that cleans-up my outdoor lighting: If From Sunset To Sunrise (next day) Then Set 'Outdoor / Front Lanterns' 80% Set 'Outdoor / Front Porch Lights' Off Set 'Outdoor / Garage Keypad-Driveway Flood' Off Else Set Scene 'Outdoor / Outdoor All Lights' Off This way nothing is left on at Sunrise. If something accidently gets turned on during the day, it is also cleaned up at Sunset. So, 2 programs instead of 3, with one program being a generic cleanup. This seems to be working, although only for a couple of days. But from the discussion above, it theoretically should work.