Inconsistent variable/condition evaluation


#1

1) Give a description of the problem
Short description: One part of the piston is evaluating a condition as false when it’s true, while another part evaluates it correctly.

Long description: I have a piston that color cycles a light every 2 minutes to a random hue. The intent is to keep my daughter focused on a single point while I or my wife are rocking her to sleep, speeding up the sleep process a bit. (This is actually an old hypnotic method called fixed-point induction.) All that works fine.

I have a boolean variable called “Lydia_Asleep” that I use in some other lighting routines. Because we won’t be using some of the other lighting pistons regularly, it’s very possible this variable can be set to “true” when she’s actually awake. To avoid that, one of the first things I do in this piston is set the variable to false. In the 2nd “block” (where I’m basically running a 2-minute loop), you can see that if this variable changes from false to true, it will cancel the loop. That part works.

In the third block, you can see that it’s specifically waiting for this variable to become “true.” When I run the ST routine that sets it to true, the loop stops, as it should, but the next part doesn’t run. According to the log, it was evaluated as false. I’m confused as to how two parts of the same piston can evaluate the same variable two different ways at the same moment.

To add to that, since the 3rd block evaluates incorrectly, if I set “Lydia_Asleep” to false (part of another lighting piston), it starts the 2nd block back up and resumes the color cycling. Incidentally, that also showed me I can preset a LIFX light to exactly what I want without turning it on. Good to know. :slight_smile:

2) What is the expected behavior?
The condition should be evaluated as true when I change the variable to true.

3) What is happening/not happening?
Condition not evaluating correctly.

**4) Post a Green Snapshot of the piston!
This was after I set the “Lydia_Asleep” variable to “True.” (Condition #19)

5) Attach any logs
This was also after I set the “Lydia_Asleep” variable to “True.” (Condition #19)

‘|+0ms |╔Received event [The Bull Homestead].:6af3b6cfbce7661df2d53986340160eb: = @Lydia_Asleep with a delay of 90ms|
|—|---|
|+304ms |║RunTime Analysis CS > 24ms > PS > 179ms > PE > 101ms > CE|
|+317ms |║Runtime (50463 bytes) successfully initialized in 179ms (v0.2.0ff.20171129) (316ms)|
|+317ms |║╔Execution stage started|
|+324ms |║║Comparison (string) null executes (string) :835b57e99e5e99197d92f8651702614b: = false (2ms)|
|+325ms |║║Condition #13 evaluated false (4ms)|
|+326ms |║║Condition group #1 evaluated false (state did not change) (4ms)|
|+331ms |║║Comparison (datetime) 1513018624535 is_less_than (datetime) 1513021901349 = true (1ms)|
|+333ms |║║Condition #12 evaluated true (4ms)|
|+336ms |║║Comparison (boolean) true is (boolean) false = false (1ms)|
|+337ms |║║Cancelling condition #14’s schedules…|
|+338ms |║║Condition #14 evaluated false (4ms)|
|+338ms |║║Cancelling condition #8’s schedules…|
|+339ms |║║Condition group #8 evaluated false (state changed) (11ms)|
|+344ms |║║Comparison (boolean) true is (boolean) true = true (1ms)|
|+345ms |║║Condition #35 evaluated true (4ms)|
|+348ms |║║Comparison (boolean) true changes_to (boolean) true = false (0ms)|
|+349ms |║║Condition #19 evaluated false (3ms)|
|+352ms |║║Comparison (datetime) 1513018624556 is_after (datetime) 1513021901349 = false (1ms)|
|+353ms |║║Condition #31 evaluated false (4ms)|
|+354ms |║║Condition group #36 evaluated false (state did not change) (9ms)|
|+355ms |║║Condition group #15 evaluated false (state did not change) (14ms)|
|+357ms |║╚Execution stage complete. (40ms)|
|+421ms |╚Event processed successfully (422ms)|’


#2

I think you might be running into an issue with the following - meaning once your piston starts running, the value of your global variable is locked in until the next piston run:

Global Variables
Global variables are variables that are common to all pistons. They always start with the @ symbol and are available to all pistons in the same webCoRE instance.

Any change made to a global variable by any piston is available for the next run of all other pistons within the same webCoRE instance. When a piston runs, a snapshot is taken of the global variables to ensure that they do not change unexpectedly while the piston is executing. For this reason, global variables cannot be used to “pass back a result” from the Execute piston action to its caller._

Maybe getting rid of the trigger (changes to true) would help your piston execute the way you want it to?


#3

I was beginning to wonder that. I just noticed in the log it was always comparing the initial value, which made it come up false since it didn’t change (3rd block), yet recognized the change it made itself (causing the 2nd block to run. The confusing part is still that the loop seems to respond to the change made from another piston. I have another idea in mind.

Thanks for pointing that out.


#4

Got it to work by just swapping out the variable change trigger for the routine execution trigger (the one that sets the variable). Then I just used the global “Lydia_Falling_Asleep” variable (only controlled in this piston) to make an exit point for the loop, similar to what I was already doing. I guess it was kind of redundant in the first place.