Program logic problem in 5.0.16c?

[larryllix]

27 minutes ago, MrBill said:

I think that it's pretty simply a bug.   I hadn't actually created the example and tested until now.  We don't need to over complicate by talking about oscillating values etc.

Plain and distinct:  RUN THEN should run the THEN block.  RUN ELSE should run the ELSE block.  There is nothing about that says an evaluation should be occurring...The IF block should not matter, it should be ignored. The current true/false state of the program should not matter.  If we RUN THEN then THEN should run, If we RUN ELSE then ELSE should run, they should NEVER be interchanged the way they are. 

@Michel Kohanim and @Chris Jahn will need to review, but it's a bug.

That  is not even a bug, but rather a natural result of the major bugs in the evaluation process inside the ISY logic engine around this. This isn't about one OP having some problems with a single program. This is about a violation of ISY's basic concepts. I really doubt this was intentional by UDI.

The program should oscillate, if the event triggers followed ISY's simple philosophy, because the program contains a basic event triggered software no-no, most of us have caused with other programs. 
This logic defies many rules that UDI has setup for ISY.
- It allows re-evaluation in the wrong place. and
- it doesn't always evaluate to the same resultant. The same conditions evaluates to True or False the first time, and the next time doesn't evaluate or trigger the program at all.

 

[MrBill]

1 hour ago, larryllix said:

That  is not even a bug, but rather a natural result of the major bugs in the evaluation process inside the ISY logic engine around this.

A bug by another name is still just a bug.

 

1 hour ago, larryllix said:

I really doubt this was intentional by UDI.

Me either, it's just a bug.

[kclenden]

On 8/22/2020 at 2:45 AM, andrewm said:

Imo statement tracing should be completely non-intrusive and not require any program changes.

I agree, but you have to work with what you're given.  ?

[kclenden]

On 8/22/2020 at 1:28 PM, larryllix said:

These program states are not evaluating according to any rules that I can tell.

You should try using state variables.  Things get even more interesting...

Test Program State - [ID 00C3][Parent 0001]

If
        Program 'Test Program State3' is False
 
Then
        $sTest  = 1
        $sTest  = 0
 
Else
        $sTest  = 2
        $sTest  = 0

Test Program State2 - [ID 00C4][Parent 0001]

If
        Program 'Test Program State' is False
 
Then
        $sTest  = 3
        $sTest  = 0
 
Else
        $sTest  = 4
        $sTest  = 0

Test Program State3 - [ID 00C5][Parent 0001]

If
        Program 'Test Program State2' is False
 
Then
        $sTest  = 5
        $sTest  = 0
 
Else
        $sTest  = 6
        $sTest  = 0

Here are the results that I get:

I've tried running the ELSE of "Test Program State" more than 20 times and always get the same order 6, 3, 2.  This means that the ELSE of the third program runs, then the THEN of the second program, and finally the ELSE of the first program.  So, ignoring the question of whether the state of any of the programs are technically changing, the following happens:

1. The state of "Test Program State" is set to FALSE
2. This causes the IF of "Test Program State2" to run the THEN
3. This causes the state of "Test Program State2" to be set to TRUE
4. This cause the IF of "Test Program State3" to run the ELSE
5. This causes the state of "Test Program State3" to be set to FALSE
6. This DOES NOT cause the IF of "Test Program State" to run because "Test Program State" is already running its ELSE clause
7. With nothing interrupting it from starting to execute, the ELSE of "Test Program State3" runs setting sTest to 6
8. Then the THEN of "Test Program State2" runs setting sTest to 3
9. Finally the ELSE of "Test Program State" runs setting sTest to 2

This behavior is consistent with how the OP program ran.  The state of the program is set before any code is executed, then any IF's that are watching that state are executed.  The only question is whether the state of a program should trigger other actions if it doesn't change, but its code is executed.  Again, I think this is in the eye of the beholder.  Without the benefit of a detailed discussion of the implications, I think it should because the code has actually been run again.

[larryllix]

13 minutes ago, kclenden said:

You should try using state variables.  Things get even more interesting...

Test Program State - [ID 00C3][Parent 0001]

If
        Program 'Test Program State3' is False
 
Then
        $sTest  = 1
        $sTest  = 0
 
Else
        $sTest  = 2
        $sTest  = 0

Test Program State2 - [ID 00C4][Parent 0001]

If
        Program 'Test Program State' is False
 
Then
        $sTest  = 3
        $sTest  = 0
 
Else
        $sTest  = 4
        $sTest  = 0

Test Program State3 - [ID 00C5][Parent 0001]

If
        Program 'Test Program State2' is False
 
Then
        $sTest  = 5
        $sTest  = 0
 
Else
        $sTest  = 6
        $sTest  = 0

Here are the results that I get:

I've tried running the ELSE of "Test Program State" more than 20 times and always get the same order 6, 3, 2.  This means that the ELSE of the third program runs, then the THEN of the second program, and finally the ELSE of the first program.  So, ignoring the question of whether the state of any of the programs are technically changing, the following happens:

1. The state of "Test Program State" is set to FALSE
2. This causes the IF of "Test Program State2" to run the THEN
3. This causes the state of "Test Program State2" to be set to TRUE
4. This cause the IF of "Test Program State3" to run the ELSE
5. This causes the state of "Test Program State3" to be set to FALSE
6. This DOES NOT cause the IF of "Test Program State" to run because "Test Program State" is already running its ELSE clause
7. With nothing interrupting it from starting to execute, the ELSE of "Test Program State3" runs setting sTest to 6
8. Then the THEN of "Test Program State2" runs setting sTest to 3
9. Finally the ELSE of "Test Program State" runs setting sTest to 2

This behavior is consistent with how the OP program ran.  The state of the program is set before any code is executed, then any IF's that are watching that state are executed.  The only question is whether the state of a program should trigger other actions if it doesn't change, but it's code is executed.  Again, I think this is in the eye of the beholder.  With a detailed discussion of the implications, I think it should because the code has actually be run again.

Very good, Spock!

The one that bothers me is that they can all trigger the next program, but the first program is dependent on the third program and yet never triggers at all. With a three program loop I think we can conclude there can be no prediction of oscillation by ISY. How would the first program know something that the other two didn't and not trigger from the same stimuli style event?

Variable order? FILO stack?

[kclenden]

56 minutes ago, larryllix said:

How does the first program know something that the other two didn't?

Well, we know that only one instance of a program ever runs, so you may be onto something with a FILO stack.  In the OP's case, there is only one program so its THEN is the top of the stack and can be popped off and replaced by its ELSE.  With your programs, the original ELSE from Program 1 can't be popped off and replaced because it's buried under two other programs.

Or maybe we're missing something about when a program's state can be changed.  With your programs, none of the actual statements in the ELSE of Program 1 have been executed so when the change of state for Program 3 happens causing the IF of Program 1 to evaluate and run its ELSE (and set it state to FALSE), perhaps that is not considered a change of state since it was already FALSE and no statements had been executed by Program 1 in between.

[larryllix]

1 hour ago, kclenden said:

Well, we know that only one instance of a program ever runs, so you may be onto something with a FILO stack.  In the OP's case, there is only one program so its THEN is the top of the stack and can be popped off and replaced by its ELSE.  With your programs, the original ELSE from Program 1 can't be popped off and replaced because it's buried under two other programs.

Or maybe we're missing something about when a program's state can be changed.  With your programs, none of the actual statements in the ELSE of Program 1 have been executed so when the change of state for Program 3 happens causing the IF of Program 1 to evaluate and run its ELSE (and set it state to FALSE), perhaps that is not considered a change of state since it was already FALSE and no statements had been executed by Program 1 in between.

I think I followed all that but Program 1 should change state to True because Program 3 became False. If that did happen then the chain should oscillate. The OP's program should oscillate also and doesn't. That is what is weird and the biggest bug, inconsistency of the logic. The same logic that works once doesn't work the next iteration.

I think I proved the original program does attempt to run True/False as manually commanded but re-evaluates before actually running any code lines. That also disobeys the ISY logic rules from other elements. Something stops the code from oscillating more than once and that is why it appears to end up in the opposite state to expected.

Interesting puzzle.

[kclenden]

1 hour ago, larryllix said:

but Program 1 should change state to True because Program 3 became False

Yeah, I messed that up.  For the convenience of conversation, I drew a diagram

So the question is, if the program state change at step #2 causes the IF to be reevaluated and run the ELSE, why doesn't the program state change at step #5 cause a return to the IF, instead of continuing to step #4 (running the ELSE)?

Likewise on the right, why doesn't the program state change at step I cause the IF of the first program to be reevaluated, instead of continuing to step F, G, and H?

Based on the actual execution (green lines) of both tests, we know:

• Program state is changed as the very first step of an IF or ELSE before any code is executed
• When an IF is triggered by a program state change, it begins running and the program that triggered it is suspended
• Only one instance of a program can ever exist, so if a program's state change triggers its own IF, it ceases to run the code that would have been run and instead runs the code activated by its IF

Now we just need a simple rule that accounts for what doesn't happen at step 5 and I.