Algorithm

Actually that would be quite handy right now as the forum appears to be having some technical difficulty. I have done a couple of postings that gave an error but still posted, and the email notification has not been working propoerly. MikeB tried to send me a PM that did not go through, also. It looks like it may just be in the email function. This is the error I got when I posted this original message: Failed sending email :: PHP :: DEBUG MODE Line : 234 File : emailer.php Yes, the error was one topic I had in mind . I got that same error a couple of times--thanks for capturing it. And there's still lots more I can think of for these additional forums as well.

Given that the existing list of forums on this board is sufficiently long that I need to press PageDown more than once to see them all, I am reluctant to suggest any increase in that number. Yet I do think that it would benefit from a 'Forum Feedback' or 'Site Improvements' forum, and from a 'User Interface' forum. I have several topics in mind for each.

Jim, go for it! If you wish to use it just for your home theatre room, 16 codes (one housecode) may be more than enough. If you find later you want more, well $12 wasn't too steep an investment.

Jim, the IR543 does only a single housecode. The IR543AH will do all 16 housecodes, but is much more expensive. Smarthome has the former for $30, but doesn't have the latter (that I could find). AutomatedOutlet has the former for $20, and the latter for $90.

upstate, I like your unified field^B^B^B^B^Bscene theory. One advantage of such a scheme is that there would be no need for the ISY to track two separate status (group and scene); a single scene status would be sufficient. But as I was reading through your description, I found myself wondering about the former group indicator. Reaching the end of your post, I see that you have addressed that as well. Option 1 - Who cares? should not be preferred because, I think, almost every user is likely to use at least one 'all off' indicator, such as 'First Floor All Off' or 'Inside Lights All Off' or something similar. Option 2 is much better in that regard. One could define an 'all off' scene which included all the desired members, each set to Off. ISY could track this scene like any other, so the scene would be False if any member was Not Off, and True only if all members were off. The user could program ISY to set a button's light On when the scene was True and Off when the scene was False, thus having the button lit when all members were Off (an All Off indicator). Alternatively, the user could program ISY to set the button's light Off when the scene was True and On when the scene was False, thus having the button lit when any member was Not Off (an NOT All Off indicator). Either of these would be independent of the state of other scenes/buttons. Finally, the use could program ISY such that the above button indication would be mutually exclusive of other button indicators, yielding the condition you described in Option 2 that said indicator would only be on when the other scene indicators were off. The user could choose whichever type of indication he preferred.

That's encouraging! Glad to hear it. Hope Bright/Dim triggers are also coming.

upstate, great job. That's an excellent example, and should help in understanding the subject. I noticed you introduced a new term, "default scene". I like it! There's another term for the Wiki, Mark.

Thanks, Chris! The workaround makes sense. I'm really glad you guys are so right on top of the bugs, squashing them as fast as they turn up!

Its definitely a topic to think about for Triggers 2.0. When program conditions change for a running program it immediately stops, and then runs either the Then or Else. In this case, there isn't much choice but to to stop immediately otherwise you could have both the Then and Else running simultaneously. Yes, I agree. I shan't propose any changes just now, as I can't think of anything better at the moment. Perhaps others will have some thoughts on this. But I've learned something new from your answer. If a program is running the Then (meaning either that its conditions are True, or that the Then path was invoked by another program), and while doing so the program's conditions become False, it doesn't just stop running the Then, but it also runs the Else. And further, if a program is running the Else (meaning either that it's conditions must be False, or that the Else path was invoked by another program), and while doing so the program's conditions become True, then it will immediately stop running the Else and start running the Then! One more question regarding folder conditions: when a folder's conditions are False, can the programs within it still be run by other programs?

Thanks for the log, Indy; good information. It would help greatly if the guys could remove the 'I 1' which precedes each 'I Dim' command. I don't know any of the exact details, but the next firmware version is supposed to have a lot of X-10 improvements.

Will they be available in a future firmware version?

Thank you! So the conditions on a folder determine when programs within it may begin running, but once started the programs will continue even when the folder conditions become False? And of course the running programs may be explicitly stopped. That's just the way it should be, in my opinion. I wouldn't want all the running programs to terminate in the middle when the folder conditions became False. However, does that not put folder conditions at variance with program conditions; i.e. doesn't a running program terminate immediately (even in the middle of its actions) when its conditions become False?

Did the Bright/Dim triggers get added to the beta, and then removed later on? I only have On/Off/FastOn/FastOff in the event box.

Yes, that will do it! Thank you Chris. Now, could you give us the rundown on what happens to running programs within a folder, when the folder conditions become False, asked in this thread?

Yes, that is exactly so. But I'm not sure how long it may be until the Run Program (with IF) may be approved and implemented. I was hoping there may presently be a way to nest conditionals, even if not as nice as the above.

Happy birthday to your son! Have a good time, all of you. Will look for some examples after you've recovered.

How can one nest conditions, something like (pseudo-code): IF Condition 1 THEN IF Condition 2 THEN Action 1 ELSE Action 2 ENDIF ELSE IF Condition 3 THEN Action 3 ELSE Action 4 ENDIF ENDIF Most likely it would need to be done with separate programs, but how?

Given a folder that has conditions which are presently True, and that some (or all) of the programs within that folder are running, what happens when the folder conditions become False? Do the running programs immediately stop? Or do they run to conclusion?

I second that! It would be great to be able to run a program including the 'If', but not to take away the selective run either. So we could have three possible actions: Run Program 'ThisProgram' Run Program 'ThisProgram' (Then Path) Run Program 'ThisProgram' (Else Path) The first would run the 'If'. This seems semantically more clear to me, in that when you 'run the program' (first line), you're running the whole program, including the condition; when you run a specific part, it is clearly labeled in the other lines.

Chris, thanks so much! I was just getting ready to ask whether a program could call itself, and you've answered that. I am assuming that one with no condition would also work: Program: ThisProgram If - No Conditions - Then Wait 5 seconds Run program 'ThisProgram' (Else Path) Else - No Actions - (To add one, press 'Action') Just out of curiosity, would the following loop work: Program: ThisProgram If - No Conditions - Then Wait 5 seconds Run program 'ThisProgram' (Else Path) Else Wait 5 seconds Run program 'ThisProgram' I would probably never do that without a terminating condition, but wonder whether it would work?

Michel, that's great to hear! It would be great if ISY could maintain the state of both the scene and the group, but reading between the lines, it sounds as though perhaps ISY will only maintain a single state for each scene/group. If that is the case, then it must be decided whether to maintain the state of the scene (becomes false when any member varies from the preset level) or the state of the group (becomes false only when all members are off). Whichever state is chosen (if only one can be maintained), the other state can be found by user programming as is done now. So what say you, fellow forum members--which state should be maintained?

upstatemike, thanks for the input; good thoughts all the way around. Yes, I agree with your analysis, and would just like to add a couple of qualifiers. When one presses scene 2 button, devices go to scene 2 levels, scene 2 button goes on, but scene 1 button goes off if, and only if, scene 1 is no longer true. That is to say, scene 1 and scene 2 could have the identical levels. I'm sure that no one would actually do that, but the point is that the buttons are not mutually exclusive, and a scene button should go off only when its presets no longer exist. Manually change a dim level of a group X device--buttons representing any scenes which are no longer true, should go off; by the same token, buttons representing any scene which has become true by this action, should turn on. This same logic should apply whenever any state change occurs within ISY--all scenes and groups should be evaluated and their status set appropriately. I don't mean to imply that ISY should do a whole network query, but rather that it should use its predictive algorithms exactly as it is doing now. upstate, I know you know these things; indeed your posts influenced my thinking on this. I'm just clarifying (I hope) for other readers.

I'm also very interested in this, and hoping someone will provide the answer.

I can confirm that this is possible with the beta ISY-99i/IR PRO. The control commands are FADE UP and FADE DOWN. Wow, that's super good news. I hope these will also be available in the next release for ISY-26.

Hey! I resemble that remark! Actually, I was hoping that upstatemike would join in, as he's obviously done much thinking on this subject! And everyone else, too, of course.