Boolean comparison in changes_to false = false produces false

#1

I wonder how a false to false comparison might give a false result, am I missing something or it is a bug:

+228ms ║║Comparison (boolean) false changes_to (boolean) false = false (0ms)
+229ms ║║Cancelling condition #8’s schedules…
+231ms ║║Condition #8 evaluated false (12ms)

Here is my piston:

image
image.png1178×918 48.7 KB

Here is the entire log:

+155ms ║RunTime initialize > 154 LockT > 1ms > rtDT > 97ms > pistonT > 97ms (first state access 56 57 97)
+173ms ║Runtime (8364 bytes) successfully initialized in 97ms (v0.3.110.20201015_HE)
+175ms ║╔Execution stage started
+179ms ║║Comparison (boolean) false changes_to (boolean) true = false (1ms)
+181ms ║║Cancelling condition #18’s schedules…
+195ms ║║Condition #18 evaluated false (6ms)
+196ms ║║Cancelling condition #6’s schedules…
+197ms ║║Condition group #6 evaluated false (state changed) (20ms)
+201ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+203ms ║║Cancelling condition #9’s schedules…
+218ms ║║Condition #9 evaluated true (6ms)
+228ms ║║Comparison (boolean) false changes_to (boolean) false = false (0ms)
+229ms ║║Cancelling condition #8’s schedules…
+231ms ║║Condition #8 evaluated false (12ms)
+232ms ║║Condition group #19 evaluated false (state did not change) (33ms)
+237ms ║║Comparison (boolean) true is (boolean) false = false (1ms)
+239ms ║║Cancelling condition #12’s schedules…
+240ms ║║Condition #12 evaluated false (6ms)
+241ms ║║Condition group #20 evaluated false (state did not change) (8ms)
+244ms ║║Condition group #17 evaluated false (state did not change) (45ms)
+250ms ║╚Execution stage complete. (75ms)
+253ms ╚Event processed successfully (198ms)
#2

You left out the the crucial trigger in your log…
(and with “changes to”, it helps to see more than one event)

… What I suspect is happening is, you have a trigger (#8) inside of another trigger (#18). I would re-write this, and keep your triggers top level, and drop the ELSE IF.
(IE: you want the trigger evaluation to happen first thing)

For example:

IF @home changes to true
    Then do stuff
END IF

IF @home changes to false
    Then do different stuff
END IF
#3

Here is the missing trigger from my log:
+56ms ╔Received event [Bul. Bulgaria].:3d58d668f32e2a4b25d6e7445354ab32:.@home = @home with a delay of 242ms, canQueue: true, calledMyself: false
It triggered when @home changed to false.

Here is a log when @home changed to true:

+59ms ╔Received event [Bul. Bulgaria].:3d58d668f32e2a4b25d6e7445354ab32:.@home = @home with a delay of 240ms, canQueue: true, calledMyself: false
+160ms ║RunTime initialize > 159 LockT > 0ms > rtDT > 99ms > pistonT > 99ms (first state access 60 59 100)
+165ms ║Runtime (8370 bytes) successfully initialized in 99ms (v0.3.110.20201015_HE)
+166ms ║╔Execution stage started
+234ms ║║Comparison (boolean) true changes_to (boolean) true = true (24ms)
+236ms ║║Cancelling condition #18’s schedules…
+237ms ║║Condition #18 evaluated true (32ms)
+238ms ║║Cancelling condition #6’s schedules…
+240ms ║║Condition group #6 evaluated true (state changed) (36ms)
+243ms ║║Cancelling statement #24’s schedules…
+256ms ║║Executed virtual command setVariable (1ms)
+260ms ║╚Execution stage complete. (94ms)
+270ms ╚Event processed successfully (206ms)

It works as expected.

What really bothers me from the log which I intilly posted is that:

+179ms ║║Comparison (boolean) false changes_to (boolean) true = false (1ms)
+181ms ║║Cancelling condition #18’s schedules…
+195ms ║║Condition #18 evaluated false (6ms)

and in the same time:

+228ms ║║Comparison (boolean) false changes_to (boolean) false = false (0ms)
+229ms ║║Cancelling condition #8’s schedules…
+231ms ║║Condition #8 evaluated false (12ms)

this does not seem right to me…

Ok i will refactor this construct to have triggers in the top level, but how can I stop the execution of the piston when it enters the first condition from your suggestion. You see the second condition has this or statement, which i don’t want to execute when @home changes to true.

#4

You can split it up into two IF blocks, with the inverted triggers at the top level. IE:

IF @home changes to true   <-- Trigger
Then
    Set variable
END IF

IF @home changes to false  <-- Trigger
Then
    IF W is true           <-- Condition
       and
       X is false          <-- Condition
    or
    IF Y is false          <-- Condition
       and
       Z is true           <-- Condition
    Then
       Do fancy stuff
   END IF
END IF

(Notice the first IF completely ends before the second IF starts)

#5

I think I didn’t explain clearly what I am trying to achieve. So there are two ways to run the piston. One is a change in the @home variable and the second is by running the piston from another piston. So the “changes to” statements listen for changes in @home and the “or” statement covers the condition when the execution is from another piston.

I have added the “@home changes to true” statement due to the fact that “@home changes to false” fires even when @home changes its value to true and in that case the “or” statement might evaluate to true also and the actions inside the condition will be executed.

Ideally I would like to capture the change to true for @home and just do a “return” or “break” and terminate the piston execution as a whole.

#6

You can achieve this with a slight modification:

IF @home changes to true  <-- Trigger
Then
    Set variable
    Break
END IF

IF 
   @home IS false         <-- Condition
   and
   @vacuum is true        <-- Condition
or
   @vacuum is false       <-- Condition
   and
   @bedTime is false      <-- Condition
   and
   @wentToBed is false    <-- Condition
   and
   @home is true          <-- Condition
Then
   Do fancy stuff
END IF

This still uses two top level IFs, but only the first one is a trigger.

#7

Tanks, I will try that.

#8

Just seen this thread.

The problem is that in order for ‘@home changes to false’ to evaluate as true, the piston must have previously evaluated it when @home was true so the change to false is recognised as such. As your piston can only reach line 25 when line 18 evaluates as false and line 23 is true, it doesn’t get to see @home being true.

As @WCmore suggests, you need to get the trigger into the top level of nesting.

#9

It seems like simply changing “@home changes to false” to “@home is false” will fix it. Thanks.

#10

If you change both @home triggers to conditions, then your piston wil also fire at every change to @vacuum… and every change to @bedTime… and every change to @wentToBed…

Ack!!

I’d probably avoid that if at all possible.
(IE: Keep at least one @home as a trigger (lightning bolt) if possible)