IndyMike

Chuck, Glad to here that the "alloff" worked. Keep in mind that this was just a troubleshooting step, nothing has been fixed as of yet (unless removing your lamplinc fixes the problem). As I stated previously, all of the devices in your original program are observable from the device tree. If their status indicated "off" your program should have returned a "true". The fact that it showed a "false" indicates that something was "stuck". I'm trying to come up with a scenario where the ISY might declare a device as "faulted" due to a communication error. This might prevent programs from triggering properly. I'll keep you posted as well. This is a LampLinc. I have removed this in the past remembering something about them not always returning status properly. Do you know what the actual limitations are with LampLincs in this regards? Lamplincs are really just responders. They can't command scenes or announce their On/Off status to the PLM. Even so, if your ISY showed this device as off, your program should have responded correctly. All Off from the main console does work. I substituted the SwitchLinc linked to the LampLinc and it is working (for now). I will keep you posted. Unlike the Lamplinc, your Switchlinc will communicate it's status to the PLM. The ISY will "infer" that the Lamplinc has turned on since the scene has been activated (no direct confirmation here). I'd be very curious if this solves your problem. IM

Chuck, Sorry to here that you're still experiencing problems. In the above, you refer to "removing the filterlincs" - and things improved. Did you intend to say "signalincs"? You also mentioned restoring the KPL. What caused you to restore the KPL and what were the changes as a result? If Status 'Basement Playroom Lights (loa' is Off And Status 'Dining Room - LIGHT (load)' is Off And Status 'Dining Room Ceiling Fan (load' is Off And Status 'Kitchen Ceiling Lights (load)' is Off And Status 'Kitchen Sink Light (load)' is Off And Status 'Living Room Ceiling (load)' is Off And Status 'Office Ceiling Light (load)' is Off And Status 'Living Room Lamp (load)' is Off Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') I can't see anything wrong with the above code. All of the devices are load bearing (no kpl secondaries) and therefor should be completely observable by the ISY (with the possible exception of your lamp). If the ISY indicates that all of the devices are "off" the program should indicate true. Is there a folder condition that might prevent the program from running (and recognizing a status change)? This really sounds like the ISY believes that one of the devices in your conditional is still on. Under those conditions the program would re-trigger and indicate false. The only device in your list that isn't "completely observable" is your Lamp (I assume this is a lamplinc). Could you try a "all off" from the main program tree to see if this rectifies the problem (not a solution mind you). If this works, could you try removing the lamplinc from the condition?

Illusion, The UDI guys have been foretelling of a new firmware version that they refer to as "triggers 2". This may also include variables. Using a variable you could conceivably count switch presses within a predefined period. That would be the ultimate solution to your problem. I did manage to come up with a brute force method (such is my way - if it ain't broke take it apart and see what makes it tick). I initially tried using a trigger "xx seconds after program yy last run". This didn't function at all the way that I expected. The following will count three consecutive presses (three timer values) and will flash the light to confirm which timer is active. You will need to be careful not to "double press" (fast on) as the routines aren't setup to register this. Program Press1 If Control 'Test Switch' is switched On And Program 'Timer1' is False And Program 'Timer2' is False And Program 'Timer3' is False Then Run Program 'Timer1' Else - No Actions - (To add one, press 'Action') Program Press2 - Will interrupt program Press1 and shut down timer1 If Control 'Test Switch' is switched On And Program 'Timer1' is True And Program 'Timer2' is False And Program 'Timer3' is False Then Run Program 'Timer2' Run Program 'Timer1' (Else Path) Else - No Actions - (To add one, press 'Action') Program Press3 - Will interrupt program Press2 and shut down timer2 If Control 'Test Switch' is switched On And Program 'Timer1' is False And Program 'Timer2' is True And Program 'Timer3' is False Then Run Program 'Timer3' Run Program 'Timer2' (Else Path) Else - No Actions - (To add one, press 'Action') Program Timer1 - Single press timer - Control trigger used to shut down program prior to normal timeout. 2 second delay included to allow timer3 program to interrupt execution and take control. If Control 'Test Switch' is not switched Off Then Wait 2 seconds Set 'Test Switch' Off Set 'Test Switch' On Wait 20 seconds Set 'Test Switch' Off Run Program 'Timer1' (Else Path) Else - No Actions - (To add one, press 'Action') Program Timer2 - Double press timer - Control trigger used to shut down program prior to normal timeout. 2 second delay included to allow timer3 program to interrupt execution and take control. If Control 'Test Switch' is not switched Off Then Wait 2 seconds Set 'Test Switch' Off Set 'Test Switch' On Set 'Test Switch' Off Set 'Test Switch' On Wait 40 seconds Set 'Test Switch' Off Run Program 'Timer2' (Else Path) Else - No Actions - (To add one, press 'Action') Program Timer3 - Triple press timer - Control trigger used to shut down program prior to normal timeout. Flashes the load 3 times to confirm activation If Control 'Test Switch' is not switched Off Then Set 'Test Switch' Off Set 'Test Switch' On Set 'Test Switch' Off Set 'Test Switch' On Set 'Test Switch' Off Set 'Test Switch' On Wait 1 minute and 20 seconds Set 'Test Switch' Off Run Program 'Timer3' (Else Path) Else - No Actions - (To add one, press 'Action') Not pretty, but it seems to work reasonably. I was using direct ON/Off commands to a relay module. Using scenes or ramp-rates (not fast on/fast off) may cause problems with the confirmation (flash) timing. IM

Digger, It's got to feel great to make some progress after all this time - congratulations. When you get a chance, could you update us on the version/date code of the switches that were giving you a problem? Thanks, IM

Michel, Message received on the replace option. I'll put some workarounds in place and wait for 2.6.4. I checked my NODESCNF.XML file. I do have some groups with elements less than 20 (not in my problem scene). I remember seeing something about this some time back, but have forgotten the implications. The PLM is ~ 2 months old (upgraded to a 2.75), but everything was imported from a PLM purchased in Aug. Thanks again, IM

Michel, I had thought about using the "Replace" but was surprised to find that it was no longer available with V2.6.3. I'm trying to figure out the thought process here. If I use a replace and the problem is duplicated on the new device, that would indicate a corrupted ISY configuration file - correct? If the problem isn't duplicated, I have a problematic Switchlinc? I'm thinking about rolling back to V2.6.1 to give this a try. Is that advisable, or is there a problem with the "replace" under 2.6.1? I'm a bit curious as to why it was pulled under 2.6.3. CORRECTION (4-7-08) - Replace is still available under V2.6.3. I may have "clicked" on a KPL secondary when looking for the option. Sorry for the confusion. Thank you, IM

RLIKWARTZ, Another possible solution would be to use X10 to trigger your program. When the outletlinc is triggered locally it will send an X10 On/Off at it's assigned housecode/Unit code. It's probably doing this now without your knowledge. I call this a "possible solution" because, if you're not set-up for x10, your PLM/ISY may not be able to hear the X10 transmission. Insteon devices can communicate in X10 but they do not repeat it (no amplification) and accesspoints/signalincs will not couple it to the opposite phase. If your PLM/ISY is one the same electrical phase as your outletlinc it might be worth a shot. Let us know, IM

Illusion, Thank you for pointing out a rather glaring omission in my post. I never stated what the actual problem was. I've edited the original post to include this information. I'd be interested in your opinion. The bottom line problem with my original program was the following - 1) I was using a status trigger on my "Master KPL 1st FL" to start the program. 2) The program modified the Scene '1st Floor Off'. The "Master KPL 1st FL" was a member of this scene, so it's status was changed. 3) The status change in the "Master KPL 1st FL" caused the program to re-trigger with some interesting results. This is what I was attempting to document. All of the above is prevented by using a "Control" trigger. A control trigger is not affected by scene induced changes. Sorry for the confusion, IM What does this mean? I do not understand why the second bit of code does not work but the first one did.

Hello Learned Members, After performing some rather nasty stress testing last night, I found that one of my Switchlincs had lost it's link table. I could control the device directly from the GUI, but it no longer responded to scenes and the PLM did not recognize a status change initiated at the switch. Oh well, Device Restore to the rescue - problem is, it didn't rescue me. I have successfully used the Device restore with KPL's on several occasions. It's a huge time saver that has really saved my derrière with the KPL's. For some reason, it isn't working with this particular Switchlinc and I'm curious why. Call it my need to know. To date I've performed every combination of "factory reset" and restore that I can think of (PLM and SL). I've also restored the ISY from a backup. I simply can't get the links back into this device using a restore. Here's the configuration (Entry Patio is my problem device): SC Ouside Night Master KPL Entry: Responder Mud KPL Entry Garage: Responder Entry Porch: Responder Fam KPL Entry: Responder Entry Patio: Responder Entry Deck: Responder SC Outside Status: Master KPL Entry: Responder Fam KPL Entry: Responder SC Outside Sunset: Master KPL Entry: Responder Mud KPL Entry Garage: Responder Entry Porch: Responder Fam KPL Entry: Responder Entry Patio: Responder Entry Deck: Responder Symptoms - 1) ISY cannot "hear" changes initiated at the Switchlinc. I interpret this as meaning that the SL has lost the link to the PLM. 2) I cannot control the Switchlinc through either of my two scenes. I interpret this as meaning the the SL has lost the scene (or group) link as well. 3) I can control the SL through the My Lighting tree. I believe this is a "direct" address command to the device. 4) I can query the device from the My Lighting tree (similar to 3 above). I realize that I can correct this situation by performing a manual remove/add device. This rather painful procedure was common before UDI perfected the "Device Restore". To prove this, I removed/added the SL to my "outside sunset" scene. It now functions normally within that scene. At present, I have not restored the link for my "night scene" or the link to the PLM itself. I'm looking for guidance on how to determine why the "restore" is not working for this particular device. I'm a bit concerned that others, when encountering the same problem, might interpret this as being signal related. I've seen numerous posts regarding scene problems with devices that were physically next to one another (one works the other doesn't). In troubleshooting issues like this, I had assumed that a device restore would rule out the possibility of link table corruption. Obviously I was wrong. Thanks in advance, IM ISY-26 V2.6.3 Rev 2.75 PLM

Thanks Mark. I'm due to loose those braincells around 6:00 PM tomorrow (final four tipoff). IM

Gents, The short Answer: Standard Bright/Dim commands require a series of concatenated commands to achieve a particular level. They don't obey normal X10 protocol, they're extremely hard on repeaters and receivers (easy to mis-interpret), and they take forever to transmit (over 5 seconds for a 100% bright command). Preset dim commands allow you to command a device directly to a particular level. The old X10 protocol allowed 32 different levels to be commanded through "Preset Dim1" and "Preset Dim2" commands (16 levels each). 1) Preset Dim(4) - The "4" specifies a "Preset Dim1" command (0 to 48% bright). This must be used with a "letter code" to specify the "dim level" (see table below). 2) Preset Dim(12) - The "12" specifies a "Preset Dim2" command (52 to 100% bright). Using this command with the ISY is a bit different from "standard" X10 commands. 1) You must first address your device with a House/Address code and NO Command. Use the ISY "NO Command" from the drop down command list. 2) You then send the preset command with a house code that corresponds to the Bright/Dim level that you desire. A) Specify the Housecode (M,N,O...) Specify no unit code ( use the "-" on the unit code drop down). C) Select Preset(4) (0 to48% bright) or Preset(12) (51 to 100% bright) If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Send X10 'B3' (Address device) Send X10 'M/Preset Dim (4)' (Send Preset Dim1 Level=0%) Wait 10 seconds Send X10 'B3' (Address device) Send X10 'J/Preset Dim (4)' (Send Preset Dim1 Level= 48%) Wait 10 seconds Send X10 'B3' Send X10 'M/Preset Dim (12)' (Send Preset Dim2 Level = 52%) Wait 10 seconds Send X10 'B3' Send X10 'J/Preset Dim (12)' (Send Preset Dim2 Level = 100%) Else Send X10 'B3/Preset Dim (12)' The above is an adaptation (for the ISY) from an article from fellow Hoosier, and X10 Guru, Uncle Phil Kingery. If anyone is interested in the "nuts and bolts" of the above, the long answer is located here: http://www.act-solutions.com/PCC/kingery18.htm Actual X10 protocol (command structure) is located here: http://www.act-solutions.com/PCC/kingery13.htm Hope this helps, IM Edit: Replaced links from the old Geocities site (offline - sorry)

Illusion, You'd be thinking correctly. Darn higher math tripped me up again. Thanks for the correction, IM

Hey Sloop, It occurs to me that you are making things overly hard for yourself by including too many controllers in your scenes. Let's start with your Guest Bath scene: Guest Bath: LP Guest Bath: Controller GBathS Guest Bath Lamp: Responder GBathS Guest Bath: Controller GBedP Guest Bath: Controller Guest Bath Sink: Responder GBedO Guest Bath: Controller OO Guest Bath: Controller SO Guest Bath: Controller LO Guest Bath: Controller 7 controllers in a guest bath??? No I know things are "bigger" in Texas, but this thing must be huge. Even so, I'd wager you couldn't swing a dead #$% (small 4 legged furry creature) without hitting many of them. Can you make do with fewer? The reason I ask is due to the time that it takes to program the links in multiple controllers. The following is a comparison of "scene programming times" for a 9 device responder scene vs a scene similar to yours above. The times shown were measured on my system with no communication errors. The above shows a "scene programming time" of 100 seconds for 9 responders. By comparison, your guest bathroom scene took me 10X as long to program (1035 seconds) with no communication errors. I take a bit different approach to scenes: 1) None of my scenes has more than one controller. My 3-way installations (2-controllers) are divided into two separate scenes with one controller each 2) Large scenes (I have one with 58 devices) have no controllers. I use programs to trigger the scene instead. The above results in much quicker programming and changes (ramp rates/levles) for my scenes. It also allows me to specify any device as a trigger without messing with link tables. In my experience, I've had more trouble with dumping link tables in KPL's than I've ever had with the PLM/ISY. Now for your "Mack Daddy Scene" - 120 Devices, with 107 responders and 13 controllers. 1) Using time of 15 seconds per link, I estimated that it would take roughly 7 hours to program this scene. If you have any communication problems that will stretch. 2) If all 120 devices were responders, the same "scene" would take roughly 30 minutes to program (again assuming no errors). Activating this scene would then require PLM/ISY trigger control. I understand your desire to get all of your Insteon devices linked so that your scenes can operate without PLM/ISY Intervention. In a perfect world everything should work as you've set it up. It isn't, and it just seems like you're really beating yourself up trying to get there. Open to a change? IM Footnote - Dude, you have more patience than anyone I've ever known.

Michael, Once again, I'm a bit confused (don't worry, it happens a lot). I'm assuming you were running the above code - please confirm. Allow me to re-state what may be obvious to you: 1) Your program status can only become true if at 10:01 PM your ICON 2 status = 0n. Last run time would be 10:01 PM 2) If can become false at any other time (within the folder time constraint) that the Icon 2 status changes. This would cause the program to re-execute, due to a status change in the Icon 2 unit, and evaluate to false (since the 10:01 time constraint is false). This would also update the "last run time" for the program. The constant in the above is that any time a program is triggered, it updates it's run time. Are you indicating that your "status trigger test" program indicated a False with a run time of 10:01? Please Confirm This would indeed be odd since you indicated that you received the "notification". The notification would have required a "true" status at 10:01 PM. Obviously, you can't have both a true and a false evaluation at 10:01. IM

Michael, When Chris speaks (or any of the UDI people) we should definitely listen. Having said that, I view Chris's post as more of a suggestion. Your program trigger "At 10:01PM and Status XXX" is already completely constrained. As such it doesn't have to be in a time constrained folder. That's very different from saying that it can't be in a timed folder. To check this, I set a timed folder containing a program with a 1 second differential: Folder: From 10:00 AM to Sunrise (next day) Sub Program: If time is 10:00:01 AM and status XXX is off. The above properly evaluated the status condition 1 second after the folder was enabled. There should be not problem with a one minute differential. It may be more efficient (execution timing) for the program to be outside the timed folder, but I believe your program should function either way (Chris - please let me know if I'm mis-speaking here). Test Status I've run my folders for the past two nights with a "10:00 PM to Sunrise" folder time constraint. The programs executed properly each night. To date I have not found a way to "trip up" the status routines. While I'm happy that your programs are now functioning properly, I'm a bit bothered by the fact that we haven't resolved the original problem. Others have reported similar problems with time constrained folders as well (Frank in this thread). I have a feeling we may be coming back to this at a lated date. To that end, the following is my attempt to summarize your saga: Summary 1) Your problems appear to revolve around an incorrect interpretation of the status condition "If time is 10:01 and Status XXX off" when this program is included in a time constrained folder (10:00 PM to Sunrise). Program appears to execute properly on the 1st day, only to fail (intermittently?) on successive days. 2) If the status program is moved to a folder without time constrains, it runs normally. 3) On 3/24 you reported the following: This function of this program is to stop your 'Deck Spots Turns Off Night' program. No way should this have 'stuck' in the running then state. I did notice (in another thread) that you were using a windows mobile device to access your ISY and having some problems with lockups. It's possible that this is what caused your stuck then. I can't simulate this. 4) We've gone through a couple of ISY updates during the course of this thread (started at 2.6.1 - now 2.6.3). Although unlikely, I suppose it's possible that something was corrected along the way. IM

For starters, I stand corrected. I went back to your original post and saw where you correctly had a status trigger in the "10:01 deck spots status" program. I'll try the 10:00 PM to sunrise routines again. In the meantime, do you have a backup where you could check where the status program was located? IM

Micheal, I checked your latest code post again and noticed something different from what I was testing. You are using a "Control" trigger whereas I'm using a "status". Sorry, this was a big miss on my part. Here's what I ran - Folder Conditions Folder Conditions for 'Test Program mcrean' Add conditions to limit when programs in this folder are allowed to run. If From 4:45:00PM For 15 minutes Then Allow the programs in this folder to run. Trigger Program 1 (control trigger) - Program shows being run at 4:46 but does not call "mcrean2" If Control 'Entry Patio' is Switched Off And Time is 4:46:00PM Then Run Program 'mcrean2' Else - No Actions - (To add one, press 'Action') Trigger Program 2 Program runs properly (status trigger) If Status 'Entry Patio' is Off And From 4:50:00PM For 1 minute Then Run Program 'mcrean4' Else - No Actions - (To add one, press 'Action') Trigger Program 3 (Control trigger) - Program status shows being run at proper time, but does not call mcrean6. If Control 'Entry Patio' is Switched off And Time is 4:48:00PM Then Run Program 'mcrean6' Run Program 'mcrean5' (Else Path) Else - No Actions - (To add one, press 'Action') Called program (3 programs - same code) If Control 'Master Fan' is switched Off Then Send X10 'E1/On (3)' Wait 10 seconds Send X10 'E1/Off (11)' Else - No Actions - (To add one, press 'Action') This really has nothing to do with the folder conditions. It's the usage of the control trigger. Consider the following code (no folder constraints): If Control 'Entry Patio' is switched Off And From 5:40:00PM For 5 minutes Then Run Program 'mcrean2 Copy' Else - No Actions - (To add one, press 'Action') 1) If I turn off the 'entry patio' at 4:00, the program status will reflect a run but it will not execute the "then". It received a "control trigger" but the time was false. 2) When 5:40 occurs, the program again shows a "run" status but not execute the "then". It receive the time trigger, but the control status has not been executed. 3) If I turn off the 'entry patio' between 5:40 and 5:45 the program will return 'true' and call the 'then'. Of the above, the only thing that I might call "odd" is the fact that the program shows a run time with only one trigger present (then not executed). This can be confusing until you consider the fact that the program is indeed running, it's just running the else path. For your purposes, I really think you want to use a 'status' trigger. IM

Michael, I've changed the folder time conditional to match your 10:00 PM to Sunrise. I'll be on a "winter camp out" tomorrow night. It'll be late Saturday before I can get back with you. IM

Frank, Thank you for the additional background. I don't doubt for a second that both you and Michael have (are) experienced problems with folder conditions. To date, I haven't been able to throw the right set of inputs at the routines to initiate a problem. I have tried some cursory tests using the routines that you provided. To date I've come up with a few methods to stop them from executing. I haven't come up with a way to cause them to execute with the folder condition false. Still looking... IM

That's a bit wild. Could you please confirm that you're still running the following code? If your code is the same as above, my best guess would be that your PLM locked up or your program is looping (I don't understand why). I just tried a similar "program stop command" and had no problems with beta 2.6.3. I'm at a loss at the moment. It's beginning to look like you're in need of the services of an expert (Mr. Jahn). IM

Michael, I haven't made a change to the ISY in over a week (I've been away as well). Each time I've checked the programs indicate that they have been executing properly. I'm actually activating a X10 device with the equivalent "deck spots turns off night" program. My X10 CM15a interface confirms that the X10 commands are being sent at the proper times. Folder Conditions Folder Conditions for 'Test Program mcrean' Add conditions to limit when programs in this folder are allowed to run. If From 2:30:00PM For 15 minutes Then Allow the programs in this folder to run. Trigger Program 1 If Status 'Entry Patio' is Off And Time is 2:31:00PM Then Run Program 'mcrean2' Else - No Actions - (To add one, press 'Action') Trigger Program 2 If Status 'Entry Patio' is Off And From 2:36:00PM For 1 minute Then Run Program 'mcrean4' Else - No Actions - (To add one, press 'Action') Trigger Program 3 If Status 'Entry Patio' is Off And Time is 2:33:00PM Then Run Program 'mcrean6' Run Program 'mcrean5' (Else Path) Else - No Actions - (To add one, press 'Action') Called program (3 programs - same code) If Control 'Master Fan' is switched Off Then Send X10 'E1/On (3)' Wait 10 seconds Send X10 'E1/Off (11)' Else - No Actions - (To add one, press 'Action') As I indicated, I've tried a number of things to trip these programs up. 1) Direct program call from another folder - outside time window. 2) Program stop from another folder - outside time window. 3) Direct program call from another folder - within time window. 4) Program stop from another folder - within time window. None of these attempts had any effect on the execution. I'd like to say that moving your time conditionals into the actual programs would work for you. Problem is, I don't understand why it's not working currently. IM

Michael, I've had three different versions of your program running for ~ 5 days now. All have performed properly. I've tried numerous things and haven't been able to "trip them up". Let us know how things are going when you return, IM

Sorry! I didn't realize I was assigning homework (I always hated that). In regard to the rest of your post - 1) It's amazing the number of Pilots I've met doing HA. Is it because you guys are always "on the road"? 2) If you're asking me to strap into the cockpit of a wide-body, yep that scares the heck out of me. However, if you're flying a Boeing, Airbus, or MD airframe, you've got many of my components on board. 3) I write code, but I am certainly not a programmer. Actually I'm just a design engineer that had to pick up some programming experience to "get by" (makes me the worst kind of hack). I'm still curious about the schedule: AND FROM 12:00:00 0n 1/1/08 to 11:59:59 oN 12/31/08 Do you want your program to stop on 1/1/09? IM

Alf, I think I understand what you are trying to accomplish with the above. However, if your above code works for you then I don't understand the ISY "order of operations" (we'll need to consult Chris and Michel). I normally evaluate these by writing a boolean equation. Definitions: True=1 False=0 X (multiplication) = and statement + (addition) = or statement A + B = 0 + 0 = 0 (false) A + B = 1 + 0 = 1 (true) A + B = 0 + 1 = 1 (true) A + B = 1 + 1 = 1 (true) A X B = 0 X 0 = 0 (false) A X B = 1 X 0 = 0 (False) A X B = 0 X 1 = 0 (False) A X B = 1 X 1 = 1 (true) Now for your code - Changing the "Or statments" to "+" and the "and statements" to "X": ('KPL ABC E' is ON) + ('KPL XYZ E' is ON) + ('APL AWAY' is ON) X (FROM 12:00:00 0n 1/1/08 to 11:59:59 oN 12/31/08) X (FROM SUNRISE -30 MINUTES TO SUNSET +30 MINUTES) X (STATUS 'LAKE OUTLETLINC' IS OFF) Substituting variables: A + B + C X T1 X T2 X D = result Looking at the above, if either A or B are true, condition will evaluate to a true 1 + B + C X T1 X T2 X D = 1 (true) A + 1 + C X T1 X T2 X D = 1 (true) If A and B are false, and any of the multiplied terms are false, you will get a false out of that section of the code. Said differently terms C, T1, T2 and D all need to be true to get a true. A + B + 0 X T1 X T2 X D = 0 (false) I'm not entirely sure why you have the T1 constraint below. As written, your schedule will stop functioning on 1/1/09. AND FROM 12:00:00 0n 1/1/08 to 11:59:59 oN 12/31/08 AND FROM SUNRISE -30 MINUTES TO SUNSET +30 MINUTES So, if I haven't bored you to tears yet, here's what I believe you were trying to accomplish - (A + B + C) X T1 X T2 X D = result For your actual code: IF ( 'KPL ABC E' is ON OR 'KPL XYZ E' is ON OR 'APL AWAY' is ON ) AND FROM 12:00:00 0n 1/1/08 to 11:59:59 oN 12/31/08 And FROM SUNRISE -30 MINUTES TO SUNSET +30 MINUTES AND STATUS 'LAKE OUTLETLINC' IS OFF THEN 'LAKE OUTLETLINC' ON If ( Status 'Bar Cans' is On And Status 'Bar Lamp' is On And Status 'Dinette' is On ) And From 12:00:00AM on 2008/01/01 To 11:59:00PM on 2008/12/31 And From Sunrise - 30 minutes To Sunset + 30 minutes (same day) And Status 'Kitchen Cans' is On Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Also - copy a program by "right clicking" on the program tree. Select copy to clipboard and past into the forum post. Happy programming, IM

Alf, What were talking about here is really the "distributive property" of multiplication. i.e. A x (b + c) = (A x + (A x C) In the above the "X" is an "and" statement and the "+" is an "or" statement. The equivalent logic in terms of the ISY conditions : A X (B + C) If Condition1 and ( Condition 2 or Condition 3) would be the same as: (A X + (A X C) If (Condition 1 and condition 2) or (Condition 1 and condition 3) Does that make sense, or have I just made things more confusing? IM