Question on IF evaluation

[paulw]

In the following code, will the IF be re-evaluated even if 'Front 1 Level' is already true?

 

If
    Folder "Re Dim is True
  and Program 'Front 1 Level' is True
Then
     Run Program 'Front 1 Level'  (Then Path)
Else
     No actions

 

It seemed to create a loop for me, until I changed the condition of the folder in 'Front 1 Level'

[oberkc]

It seems to me that if you have a program "front 1 level" that has conditions in which it can be true or false, the then path will run any time it becomes true. The set of code you quote would run the same set of commands again, so long as the both conditions are true. Yes, it seems like a potential for a loop to me.

 

Before reaching any conclusions, however, I would like to see your entire front 1 program and the conditions of your dim folder. Is is possible that your front 1 program, itelf creates a loop of some type? Does the actions in the program cause the conditions to be re-evaluated?

[paulw]

Oberkc,

 

Still getting some execution sequences under my belt but, I did not expect the 'Rd Dim Final' IF to be re-evaluated as there was no change in status.

 

Paul

 

 

 

[u]Re Dim Folder[/u]
If
       Program 'ReDimSwitch' is True

Then
  Allow the programs in this folder to run.



[u]Re Dim Final (program in Re Dim folder)[/u]
If
       Folder  'Re Dim' is True
   And Program 'Front Final Shut Down' is True

Then
       Run Program 'Front Final Shut Down' (Then Path)
       { Run Program 'ReDimSwitch' (Else Path)}  <-  never executed  see below

Else
  - No Actions - (To add one, press 'Action')



[u]Front Final Shut Down (program)[/u]
If
       Time is 11:18:00PM

Then
       Send X10 'L1/Off (11)'
       Run Program 'Front 4 Level' (Else Path)
       Run Program 'ReDimSwitch' (Else Path)  <- moved here to stop loop

Else
  - No Actions - (To add one, press 'Action')



[u]Front 4 Level (program)[/u]
If
       Time is 10:48:00PM

Then
       Send X10 'L1'
       Send X10 'C1/Preset Dim (4)'
       Run Program 'Front 3 Level' (Else Path)
       Run Program 'ReDimSwitch' (Else Path)   

Else
  - No Actions - (To add one, press 'Action')

[oberkc]

Wow. You spin a complicated web. I am not sure that I am able to sort through what you have, and I still think there may be something missing. I will offer some thoughts and, with luck, this may help.

 

Regaring your "Re Dim Folder", the condition of this folder is based upon the condition of a program "redimswitch". I don't see this program anywhere. What is in it? When is it true? When is it false?

 

Regarding program "Re Dim Final", there is a condition, "if folder 'Re Dim' is True'. Since this program already resides in the folder, it won't run unless the folder is true by definition. I conclude that the stated program condition is redundant. Why is it there? Is it your intention that the change in status of this folder trigger the program to run?

 

In this same program, your second condition is that "Front Final Shut Down" is true. As I understand conditions, this program will ALWAYS be true. This program will be evaluated at 11:18pm and show true. It will remain true until it is evaluated again. It will be evaluated again in 24 hours, at which point, it will still be true, etc.. Without knowing the conditions defining the status of the folder, itself, I am not sure when to expect this program to run. It may never run.

 

In this same program you run "front final shut down" then path. This appears to have the potential to run twice, simultaneously, at 11:18pm (since the next program will trigger the then path at 11:18p). I am not sure about the consequences of trying to run the same program twice, but I am not sure why one would want to.

 

I see nothing in the remaining two programs which, by themselves, cause a problem.

 

I noticed that you moved a line in a program because it never executed. Is it possible that this whole program never executed? Why would the first line execute and not the second? Again, is it possible that your conditions are never evaluated as true?

 

It is possible that you have commands running in the ReDimSwitch" or "Front 3 Level" programs that are causing loops, but they are not listed so I cannot offer any comment.

 

Sorry I cannot offer more. If you care to post the contents in the other programs, I may be able to see something.

[paulw]

Let me start by a recap of what I am doing.

 

I have lights which dim as the night goes on (Five seperate programs each similar to 'Front Final Shut down'. Each program sets the lights to a lower setting, and runs the 'else' from the previous program leaving the current program as the only 'true' program.

 

These lights can be set to a full brightness for example, when the alarm system is armed remotely, thus there is the 'ReDim' folder which has five programs which test for the appropriate 'true' program, and runs the 'then' to reset the lights.

 

The ReDimSwitch is a program with no code to act as a switch. It is set to 'true' whenever there is a need to reset the lights.

 

 

The reason for the repeat of the folder IF condition in the programs residing in the 'ReDim' folder, was to force each program to be evaluated. Without that the programs in the folder would not run, per the documentation on folders.

 

The whole program "front final shut down" is not being run, just the "then".

 

Was expecting the "Re Dim Final" to go out and run the 'then' of "front final shut down", come back and continue with the next instruction which was turning off the 'ReDimSwitch'. I assumed this, as there is no change in any of the 'IF' conditions. However it appears that the ISY is acting like there has been a change in status and starts 'Re Dim Final' from the top.

 

I was wondering that since the 'then' from 'Front Final Shut Down' was being executed, that it was being considered as a change is state even though it was true to start with.

 

My resolution to this issue was turning off 'ReDimSwitch' in 'front final shut down' which keeps the ReDim folder from being true.

 

 

At this point I am just trying to understand why it behaved as it did.

[apostolakisl]

It would seem that at least some of the confusion here goes to what we have been discussing on another thread. And that is under what circumstances do various "if" statements get evaluated. "triggers" as we have been calling them.

[oberkc]

I agree with apostolakusl....I think we need to make sure we understand when, or if, your various programs trigger. He has in interesting thread on this. Check it out.

 

The ReDimSwitch is a program with no code to act as a switch. It is set to 'true' whenever there is a need to reset the lights.

 

How is it ever set to true? The only listed examples set it to false, by running the else path.

 

I did not expect the 'Rd Dim Final' IF to be re-evaluated as there was no change in status.

 

When DO you expect it to get evaluated, if ever? I would expect it to be evaluated every day at 11:18p (since it is partly based on "front final shut down", which is evaluated every day at 11:18p. No, the state TRUE does not change, but it is evaluated). I would expected to get evaluated any time the folder changes state, which I now understand is the result of a switch. Unfortunately, since that same switch disables/enables the folder in which the program resides, I am not sure that this evaluation will happen. This is a least part of the "confusion" mentioned by apostolakisl, I believe.

 

The only action in Re Dim Final (when evaluated true) is to run "front Final Shut Down (then path). Since "Front Final Shut Down" runs on its own at 11:18p, the call out from Re Dim Final appears redundant, at best. When is it that you believe this program (Re Dim Final) will trigger? Have you checked the event viewer to confirm?

 

You state that there are five programs in the ReDim folder. I note only one program highlighted as being in that folder. Are all the other listed progams (Front Final Shut Down, Front 4 level, others not listed) part of this program as well?

 

The reason for the repeat of the folder IF condition in the programs residing in the 'ReDim' folder, was to force each program to be evaluated. Without that the programs in the folder would not run, per the documentation on folders.

 

This may be a timing issue. Unless the folder is true, these progams are disabled. I am unsure about the timing of events, but I assume this condition first makes the folder true. Once the folder is true, the event has already passed and will never force an evaluation of the conditions of the programs residing in it. This is how I see it.

 

Was expecting the "Re Dim Final" to go out and run the 'then' of "front final shut down", come back and continue with the next instruction which was turning off the 'ReDimSwitch'.

 

The problem that I see is that running the front final shut down makes the parent folder false, which suspends any further activity of programs within. As such, it will never continue past the first then line of your "Re dim Final" program. Perhaps that is the heart of the issue.

 

I was wondering that since the 'then' from 'Front Final Shut Down' was being executed, that it was being considered as a change is state even though it was true to start with.

 

My resolution to this issue was turning off 'ReDimSwitch' in 'front final shut down' which keeps the ReDim folder from being true.

 

I think I may be repeating myself, but this may be what is happening.

 

I cannot help but suspect that there is an easier way to do this, but the relationship between your alarm system and other programs is still one that I don't understand.

[Goose66]

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.

[paulw]

kingwr:

 

Your last paragraph was where I was putting my money. See my comment below to obrekc on the ReDimSwitch. A bit complicated but it works and I only have one place where the levels are being set so changes are easy, and the re-dimming always uses the same code.

 

 

oberkc:

 

The ReDimSwitch is turned true elsewhere whenever there is the need to reset the lights due to something else, like the alarm activation, which has changed their level.

 

My reason for questioning this was to determine if it was my misunderstanding of the processing sequence, or something else. Seems to be either a documentation issue, or a bug.

 

Runs fine with setting the ReDimSwitch false as part of the normal evening sequence, even though it serves no purpose there unless ReDim is active.

[Goose66]

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).

[paulw]

When one understands the rules of a game, one can play the game

 

I'm new enough to ISY that I'm sometimes not sure I understand the rules