yardman 49 Posted January 20, 2008 Posted January 20, 2008 Hello all: Something weird is happening with one of my programs. I'm hoping that someone could tell me if its something I'm doing. During the last two nights, timed programs that I have in a folder have been running themselves, even though the KPL secondary that is controlling their folder has not been turned on. So here are the programs. Folder Conditions for 'Away Scene ON' Add conditions to limit when programs in this folder are allowed to run. If Control 'Hall KPL G - Away Scene' is switched On Then Allow the programs in this folder to run. Away Scene ON Sub 1 If Control 'Hall KPL G - Away Scene' is switched On Then Repeat 3 times Send X10 'G7/Off (11)' Wait 2 seconds Else - No Actions - (To add one, press 'Action') Away Scene ON Sub 2 If From 7:00:00PM For 3 hours Then Wait 10 minutes (Random) Set Scene 'Kitchen Main Group' On Wait 15 minutes Set Scene 'Living Room Ceiling Group' On Wait 10 minutes Set Scene 'Master Bed Light Group' On Wait 7 minutes Set Scene 'Master Bed Light Group' Off Wait 2 minutes Set Scene 'Master Bed Light Group' On Wait 3 minutes Set Scene 'Master Bed Light Group' Off Wait 5 minutes Set Scene 'Basement Game Group' On Wait 5 minutes Set Scene 'Living Room Ceiling Group' Off Wait 3 minutes Repeat 3 times Send X10 'G7/On (3)' Wait 2 seconds Else - No Actions - (To add one, press 'Action') Away Scene ON Sub 3 If From 11:00:00PM For 3 hours Then Wait 10 minutes (Random) Set Scene 'Basement Game Group' Off Wait 1 minute Set Scene 'Living Room Ceiling Group' Off Wait 5 seconds Set Scene 'Kitchen Main Group' Off Wait 2 minutes Set 'Master Bed Dimmer' On Wait 1 hour and 2 minutes Repeat 3 times Send X10 'G7/Off (11)' Wait 2 seconds Repeat 1 times Wait 10 minutes Set 'Master Bed Dimmer' Off Else - No Actions - (To add one, press 'Action') So, from what I can see, Sub programs 1,2 & 3 should only run if the "Hall KPL G- Away Scene" button has been turned on. But the last two nights, the button was off, but the programs ran anyway. Previously this wasn't happening. The recent changes that I made to the program was to move the "Sub 1 program into the Folder with the other Subs. Also, I changed from looking at the "Status" of that KPL button to looking for the actual "Control" signal. I don't know if these could be part of the problem. I also have a program that turns the devices off, and stops the Sub Programs. It looks like this: Away Scene OFF If Control 'Hall KPL G - Away Scene' is switched Off Then Stop program 'Away Scene ON Sub 2' Stop program 'Away Scene ON Sub 3' Set Scene 'Kitchen Main Group' Off Set Scene 'Living Room Ceiling Group' Off Set Scene 'Master Bed Light Group' Off Set Scene 'Basement Game Group' Off Wait 3 seconds Repeat 3 times Send X10 'G7/Off (11)' Wait 2 seconds Else - No Actions - (To add one, press 'Action') FYI, the "G7" commands are for an X10 lamp module that controls a light in my office. If this happens again, I'll look to see if "My Lighting" shows an "ON" status for the KPL G button. I've forgotten to look for this, as the button itself has shown to be "OFF" both times that this has occured. Thanks
Michel Kohanim Posted January 20, 2008 Posted January 20, 2008 Hi Frank, My only comment is that your folder condition is using Control. This means that: 1) When your KPL is switched on the first time around, this folder remains TRUE till such time that your KPL is switched off (or anything except on). So, if you never ever physically switch off your KPL, this folder condition remains true 2) If this KPL button is somehow in a scene with another device which could turn this KPL button off, then your condition does not change since it's only the status of the button that has changed and not its control 3) If there are any type of communications problems and if ISY does not hear the change of state on your KPL, then the condition remains true In short, you have to make sure: a) Your KPL button is not controlled by any other device Your KPL communicates reliably with ISY With kind regards, Michel
yardman 49 Posted January 20, 2008 Author Posted January 20, 2008 Hello Michel: Thanks so much for the reply. I've changed the folder "IF" condition back to "Status" instead of Control. I've also removed the Sub 1 program from under the folder and made it a top-level program. I left that one as a "Control". I'll monitor this tonight and see what happens. The "OFF" program is activated by the same KPL button. So it should be changing the control/status back to off. It also stops the Sub 2 and Sub 3 programs. Here are some more questions: 1) Is it possible that the ISY thinks that the time Condition programs in a Folder are always in a "Run" state, even if the Folder conditions have not been met? The reason I ask this is that I had previously tested the programs from the Program Summary page by using "Run". I didn't know if there was a possible "bug" that if you run a program manually through Program Summary, that it never really "Stops". 2) Could you tell me how often "Status" changes are evaluated? Every 1 second? Immediately? 3) If the ISY reboots, what state does it assume for KPL secondaries? Since KPL secondaries don't respond to "status queries", the only way that the ISY knows what the curent status is, is to make the assumption that the status is the same as it was as of the last recorded button push. As such, I see that after the ISY reboots, the status of KPL secondares are "blanK" until I push each of them at least once. Can I assume that if the status is "blank" that the ISY treats this as "OFF"? Or is the status considered to be in an indeterminate state? Thank you.
IndyMike Posted January 20, 2008 Posted January 20, 2008 Frank, I may be able to help with one of your questions - Your time condition - If From 7:00:00PM For 3 hours Has a definite start and stop time. It will show a "true" status over this period. If you "force" a run outside this time period, the program will show a "true" status until 10:00PM rolls around again. Your condition If Control 'Hall KPL G - Away Scene' is switched On Will always show a "true" status since there is no way to "trigger" this to an off or "false". Unlike "status" triggers which are executed whenever a status changes, the control is a single pass trigger. It can only evaluate to a "true" status. The same is true of "indefinite" schedules and X10 triggers: If Time is 11:00 PM or If X10 A12/On is received These will always show a status of true. Chris Jahn posted an interesting method to correct this. It involves "forcing" the else loop to be run. The following is an example of your control function with the "else path" force: Away Scene ON Sub 1 If Control 'Hall KPL G - Away Scene' is switched On Then Repeat 3 times Send X10 'G7/Off (11)' Wait 2 seconds Repeat 1 Time Run Program "Away Scene on sub 1" (Else path) Else - No Actions - (To add one, press 'Action') Beware that actions in the "Else" will not be executed. This is simply a means to force the program to evaluate to a "false" status. Hope this helps, IM 1) Is it possible that the ISY thinks that the time Condition programs in a Folder are always in a "Run" state, even if the Folder conditions have not been met? The reason I ask this is that I had previously tested the programs from the Program Summary page by using "Run". I didn't know if there was a possible "bug" that if you run a program manually through Program Summary, that it never really "Stops".
yardman 49 Posted January 20, 2008 Author Posted January 20, 2008 Hello Mike: Thanks for your explanation....that really helped me to better understand why programs appear as "True" when they are out of the time range specified in the IF statement. In case anyone is wondering, the reason that I use "From 7:00 pm for 3 hours" rather than a fixed time, is so that the program can be run anytime in this time period. For instance, if I leave at 8:00 pm, the program will still run as long as its folder conditions are met (KPL Button has been turned ON). Thanks again.
Chris Jahn Posted January 20, 2008 Posted January 20, 2008 Beware that actions in the "Else" will not be executed. This is simply a means to force the program to evaluate to a "false" status. This is a bug, the Else path is supposed to run but does not. In the next release; the Else path will be run.
Chris Jahn Posted January 20, 2008 Posted January 20, 2008 Here are some more questions: 1) Is it possible that the ISY thinks that the time Condition programs in a Folder are always in a "Run" state, even if the Folder conditions have not been met? The reason I ask this is that I had previously tested the programs from the Program Summary page by using "Run". I didn't know if there was a possible "bug" that if you run a program manually through Program Summary, that it never really "Stops". I'm not sure if you are confusing True/False with programs running. A program (or Folder) will always have a True or False value, regardless of whether the program is running or not. It will be set 'True' when the If condition becomes True (additionally for programs the 'Then' runs), and will we set 'False' when the If condition becomes false (additionally for programs the 'Else' runs). If you run a program manually it will stop as normal, unless you have created an infinite repeat or loop of some kind. The only other possiblity is that the Program Summary wasn't updated correctly; if think this may be the case, press the 'Refresh' button. 2) Could you tell me how often "Status" changes are evaluated? Every 1 second? Immediately? There is absolutely no polling going on. A Status change, a button press, etc. are processed when they occur. It is entirely event driven. 3) If the ISY reboots, what state does it assume for KPL secondaries? Since KPL secondaries don't respond to "status queries", the only way that the ISY knows what the curent status is, is to make the assumption that the status is the same as it was as of the last recorded button push. As such, I see that after the ISY reboots, the status of KPL secondares are "blanK" until I push each of them at least once. I believe they are defaulted to 'Off' when the ISY reboots.
IndyMike Posted January 20, 2008 Posted January 20, 2008 Chris, Thanks for the update. I already like having the ability to force the else loop and a false status. Being able to execute actions in the "else" will be icing on the cake. IM
Algorithm Posted January 21, 2008 Posted January 21, 2008 Beware that actions in the "Else" will not be executed. This is simply a means to force the program to evaluate to a "false" status. This is a bug, the Else path is supposed to run but does not. In the next release; the Else path will be run. Chris, thanks for the information. Can you clarify whether this bug prevents the Else path from running only when it is called from the Then path of the same program, or also when it is called from another program or run from the Program Summary?
IndyMike Posted January 21, 2008 Posted January 21, 2008 Chris, thanks for the information. Can you clarify whether this bug prevents the Else path from running only when it is called from the Then path of the same program, or also when it is called from another program or run from the Program Summary? JAJ, I have tried running the "else" from the Program Summary - this does correctly execute the else path. I have not tried calling the "else path" from another program. Actually, I didn't realize that was an option. IM
Chris Jahn Posted January 22, 2008 Posted January 22, 2008 Beware that actions in the "Else" will not be executed. This is simply a means to force the program to evaluate to a "false" status. This is a bug, the Else path is supposed to run but does not. In the next release; the Else path will be run. Chris, thanks for the information. Can you clarify whether this bug prevents the Else path from running only when it is called from the Then path of the same program, or also when it is called from another program or run from the Program Summary? Mostly correct; this problem only occurs when a program attempts to run itself in any combination (i.e. Then runs 'Then', Then runs 'Else', Else runs 'Then', Else runs 'Else').
Algorithm Posted January 22, 2008 Posted January 22, 2008 Indy and Chris, thanks for the clarification. It seems as though, being limited to the same program, the problem should be easy enough to work around until it is corrected!
Recommended Posts
Archived
This topic is now archived and is closed to further replies.