IndyMike

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

HokiePerogi, I'm almost sorry I brought this up. I don't believe it's related to your current problem. It could cause problems down the road. In general you should avoid programming an action that will change your conditions. This will create a new "event" that will be evaluated by your program (i.e. your program is re-started and the conditions re-evaluated). A status request on one of the conditions will (I believe) produce the same re-evaluation. If you are using a "status" condition, and want to modify the status of the same device, you need to use two programs. The following is a modification of your latest code. If Status 'Rec Room Stairs Top' is Off And-( | Control 'Rec Room Theater Front' is switched Off | Or Control 'Rec Room Theater Front' is switched Fast Off | Or Control 'Rec Room Theater Front' is switched Fade Down -) And From Sunset - 1 hour For 10 hours Then Set Scene 'Rec Room Stairs 3-way' On delay 30 seconds Set Scene 'Rec Room Stairs 3-way' Off Else - No Actions - (To add one, press 'Action') 1)If the "Set Scene 'Rec Room Stairs 3-way' On" changes the state of your status condition "Status 'Rec Room Stairs Top' is Off" a new event will be triggered and the condition will be re-evaluated. 2)If the status condition has changed from "off" the program will evaluate to false, and terminate execution (most likely in the middle of the 30 sec delay). 3) Worst case - an event is generated and the status is still true (rec room stairs is off) - you wind up with a looping program (constantly re-triggering). This is my supposition - Chris is the expert. To handle this properly, divide the program up as follows: If Status 'Rec Room Stairs Top' is Off And-( | Control 'Rec Room Theater Front' is switched Off | Or Control 'Rec Room Theater Front' is switched Fast Off | Or Control 'Rec Room Theater Front' is switched Fade Down -) And From Sunset - 1 hour For 10 hours Then Run program "Theater Room Stairs" Else - No Actions - (To add one, press 'Action') Program "Theater Room Stairs" If - no conditions Then Set Scene 'Rec Room Stairs 3-way' On delay 30 seconds Set Scene 'Rec Room Stairs 3-way' Off Else - No Actions - (To add one, press 'Action') Again, I don't believe this has anything to do with your current problem. I think your program will work "as is". I'm just trying to prevent any hardship "down the road". I'm speaking as one who has been through the "school of hard knocks". To my mind, the best way of learning is through doing - welcome to the club. IM

Well, I said 1 additional comment - I guess I lied. In your code below I'm assuming the the statement Set Scene 'Rec Room Stairs 3-way' On also activates the condition And Status 'Rec Room Stairs Top' is Off changing it's status to "not off". If this is true, it's a no-no. When you activate the "scene" it will generate a status event on the "Rec room stairs top" and your condition will evaluate to "false". As written, you do not have any statements past the "set scene". This will most likely work. If you had additional statements, they might not be executed. Try to avoid this in the future.

Frank, I've been a bit remiss in not posting this earlier - nice to have you back guy! Your AWOL period must have invigorated you - you've been active (to the forums benefit). In regard to your post regarding folder/program schedules, if you have some examples that you could provide, I'd be happy to spend some time running tests. My curiosity has been "peaked". IM

Michael, To be honest, if the "1 minute" suggestion works I won't be able to explain why. All I can say is that this is the way that I structure my schedules (definite time period). I still don't see anything "wrong" with your original (single ended) schedule. I have three different versions of your schedule running now. They all functioned as I expected at 2:30PM today. We'll see what happens tomorrow. IM

One additional comment, With the V2.6.1 firmware, a fade Up/Down is only registered by the ISY when it is followed by a Fade Stop. Can't comment on the latest beta 2.6.2. In your example, using the Fade up will not register a change in the status of the Scene devices. I'm not sure if that is what you had in mind. IM

mcrean, First, I apologize for my last post - I had missed the fact that you had aleady taken steps to correlate the ISY status with your KPL. From your post below, I'm not sure where You believe the problem is - Actually, I would have expected the Deck Spots Status program to show "True". If Time is 10:01:00PM And Status 'Deck Spots' is not On Then Run Program 'Deck Spots Turns Off Night' Else - No Actions - (To add one, press 'Action') The "event" in the above is the Time 10:01:00PM. At that time the entire conditional is evaluated. It will retain that evaluation until it is retriggered (10:01 the next day, or the deck spots are activated). I would expect this to show "true" if your spots were off at 10:01PM. A false indication indicates the "then" was not executed. Please try the following : If From 10:01:00PM For 1 minute And Status 'Deck Spots' is not On Then Run Program 'Deck Spots Turns Off Night' Else - No Actions - (To add one, press 'Action') Assuming that you did not turn your Deck Spots on while the folder was active, I believe the "True" is correct for this program. If Control 'KeypadLinc A (Deck Spots)' is switched Off Then Wait 1 hour Set 'Malibu Lights' On Wait 4 minutes Set 'Malibu Lights' Off Wait 1 minute Set Scene 'Deck Spots Button' On Else - No Actions - (To add one, press 'Action') Like the program above, this is showing the status of the last call (event) on 3/12/2008. Since you are calling the "Then" statement directly, is has no choice but to reflect a "true" status. As I indicated above, the then loop was not called on 3/13. You may be referring to a discussion between myself and Linuxguy. If that's the case, we were not discussing a "bug" in the nextday condition. We were discussing the fact that it's not possible to troubleshoot a nextday condition (other than letting the clock run). I use this condition in many folders and programs and don't have an issue. From your description, your folder appears to be enabling correctly. Please try adding the "1 minute window" to your program. I will try checking some things tonight. IM

mcrean, If I had to guess, I'd say that the original failure was due to your Insten Device not properly communicating a off status to the ISY. Last night, when you monitored the conditions and status, everything worked properly (as it should). This could be due to general noise/signal absorption in the vicinity of the Insteon device (reducing margin) or it could be something that is turning on at night (cfl's and outdoor photocells that activate at night are prime candidates). Keep us posted, IM

mcrean, As Chris indicated, I don't see anything incorrect with your programs. I tested the Deck Spot Status and folder conditions and everything appeared to work properly. You mentioned that "you turned the deck spots off at 7:00 and at 10:01, the Deck Spots Turns off Night was not running" - 1) Was the folder running (true) at that point. Is it possible you switched the night and day conditions between folders? I don't mean to insult your intelligence. I bring it up because I've made this mistake (multiple occasions). 2) How did you "turn off" the deck spots (ISY or at the switch). Is it possible that there is a noise source that prevented the ISY from registering the "off event"? Short of that, I don't see any problem. I do have a couple of observations (unrelated): 1) Beware of the condition "And Status 'Deck Spots' is not On". A level between 1% and 99% is considered "not on". You may want to change this to a status of "off". 2) The time conditions between your two folders have a possibility of overlapping (not sure how the ISY handles this). Chris would be far more knowledgeable here, but I typically use a underlap of 1min between daytime and nighttime conditions. IM

Chuck, Intermittent problems are often the worst kind. Unfortunately, I don't believe the ISY can ascertain that a command sent to a KPL secondary button has been properly received. It assumes that the Insteon communications are intact and uses a predictive status (I sent the command, therefore the device is on/off). If your communications are less than "stellar" you get the results that you are seeing now. As an example, I have a very similar "status monitor" setup on a KPL. I can air gap my KPL and execute the program and the KPL secondary status registers "ON". That's obviously not possible since I've removed power from the device. I understand that you're trying to work around this problem with software in the ISY. Just my opinion, but I believe your time would be better served if you improve the communication to the device itself. Unfortunately, the nature of Insteon communication makes it very difficult to troubleshoot. I've used a ELK-ESM1 and a PLC to listen to communications with limited success. In the end, the old X10 methods of mapping, isolating, and filtering problem devices do appear to work with Insteon. FWIW, the following has worked well for me (both X10 and Insteon). 1) PLM on dedicated circuit next to the breaker panel (basement). 2) Passive coupler at the breaker panel. 3) Signalincs located on second floor. Other possibilities - 1) Check your signalincs/accesspoints to make sure they haven't locked up (they're still communicating). 2) Consider moving a signalinc/accesspoint to the same circuit as your problem KPL. 3) If you have a BoosterLinc installed (or devices with Boosterlinc capability) - pull it. Once my Insteon installed devices grew beyond 25, Boosterlincs became a problem. Let us know where you stand, IM

Hello again Chuck, Your code below is changing the status of your condition 'Living Room - ALL OFF' is not Off. When this is executed the program status be changed to "false" and the statements that follow will not be executed. The fact that you require the status check may indicate that you're having communication problems with your device. Executing the scene "All off LED" off should work by itself. You may want to focus your efforts on improving the device communication rather than "re-querying" the device. If you feel you need to check the status of the lamp, you should divide things up into two programs to prevent changing the state of your conditions within the program: If ( Status 'Basement Playroom Lights (loa' is not Off Or Status 'Dining Room - LIGHT (load)' is not Off Or Status 'Dining Room Ceiling Fan (load' is not Off Or Status 'Kitchen Ceiling Lights (load)' is not Off Or Status 'Kitchen Sink Light (load)' is not Off Or Status 'Living Room Ceiling (load)' is not Off Or Status 'Living Room Lamp (load)' is not Off Or Status 'Office Ceiling Light (load)' is not Off ) And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Run Program 'ALL OFF LED - Off (Daytime)' Else - No Actions - (To add one, press 'Action') Program 2 sets the scene OFF and tests the status. If the status comes back "ON" I would assume that the ISY would treat this as an "event" and Program 1 would again become true (triggered by the event "Status 'Living Room - ALL OFF' is not Off"). I haven't tried triggering programs with status calls. Hopefully someone else can confirm if they function in this manner. If No conditions Then Set Scene 'ALL OFF LED' Off Wait 10 seconds Set Scene 'ALL OFF LED' Query (if the light is on, the ISY will hopefully see this as an event and call the original program) Else No actions Be careful with this code - If you cannot turn the indicator lamp off for some reason, you may wind up stuck in a loop (querying and re-triggering the original program). IM

Chuck and Darrel, Sorry for the misinformation. Obviously (hindsight) the below is incorrect - you can turn an Insteon device off if it is already in the off state. I honestly never considered this before. I guess my "old school" brain isn't wired that way. Also seems that I may have some holes to plug in my programming... IM

Hello Chuck, From what I can see, your Status and Control statements below can't be satisfied with the same event. The light can't be off and switched off at the same time. I tried the below code with varying ramp rates to try to ensure that there wasn't some trick involved - could not get it to execute. The below will function with an "or" between the status and control. You mentioned that this worked at one time - I honestly can't see how. Is it possible that you modified the program and didn't save it? Be advised that beta 2.6.1 did not save programs with it's "backup feature. Programs could only be saved with an explicit export. IM

Michael, I re-read your original post again. I sounds as if the PLM can't "hear" the switch unless it's at a level somewhere above 40%. Does the switch respond to the ISY/PLM when it's off (turn on from a off condition)? I'm beginning to wonder if you have a problem with your neutral connection to the switch. If this switch works in another location, you may want to start checking connections along the circuit (other boxes in the chain).