Unrelated global var update is causing condition cancellation?

#1

Hey I just saw this this morning twice, but I don’t yet have a log of it. It appears that updates to completely unrelated global vars are causing condition state cancellation in pistons that aren’t even using that global var.

Still trying to get my head around this. This is on hubitat, so that may have something to do with it. Also I’m only saving 50 lines of logs so I just lost logging of the event, but I’ll post a piston and the log shortly.

Is there a way I can prevent a piston from subscribing to globals it doesn’t use? My conditions are cancel on condition state change not piston state change, so I don’t get why an unrelated global var change would change the condition state.

I’ll setup a test here shortly and post it, but is this behavior expected?

#2

OK well here’s a piston that doesn’t make use of this particular global, @LevelEastHigh.

None the less it receives an event when @LevelEastHigh is updated and executes the piston as you can see from the logs. This event also seems to be either cancelling my condition, or causing my pre-existing wait timer to reset. This seems really wrong. How can I prevent my piston from executing when a completely un-related global var is updated? I still need it to be global because it’s used by two other pistons, just not THIS piston.

download
download.png1178×2236 348 KB

11/17/2018, 11:49:04 AM +858ms

+17ms

╔Received event [Holman].:a561562228c112bbaca33856e5eafe08: = @LevelEastHigh with a delay of 686ms

+637ms

║RunTime Analysis CS > 198ms > PS > 297ms > PE > 142ms > CE

+871ms

║Runtime (63422 bytes) successfully initialized in 297ms (v0.3.108.20180906) (848ms)

+872ms

║╔Execution stage started

+876ms

║║Comparison (string) :18e2186ca0d5a3446d4e55c749accf18: is_any_of (string) :80ff8adc87cc6d0d790b1bb31708f282:,:18e2186ca0d5a3446d4e55c749accf18: = true (1ms)

+877ms

║║Condition #1 evaluated true (3ms)

+878ms

║║Cancelling condition #2’s schedules…

+879ms

║║Condition group #2 evaluated true (state changed) (5ms)

+903ms

║║Condition #3 evaluated false (22ms)

+903ms

║║Cancelling condition #2’s schedules…

+904ms

║║Condition group #2 evaluated false (state changed) (24ms)

+913ms

║║Comparison (enum) inactive is (string) inactive = true (2ms)

+914ms

║║Condition #14 evaluated true (6ms)

+915ms

║║Condition group #13 evaluated true (state did not change) (7ms)

+929ms

║║Comparison (string) :18e2186ca0d5a3446d4e55c749accf18: is_not (string) :80ff8adc87cc6d0d790b1bb31708f282: = true (2ms)

+942ms

║║Condition #18 evaluated true (26ms)

+944ms

║║Comparison (integer) 0 is_equal_to (integer) 30 = false (0ms)

+945ms

║║Condition #19 evaluated false (2ms)

+946ms

║║Condition group #15 evaluated false (state did not change) (30ms)

+1019ms

║║Comparison (time) 42545806 is_before (time) 1542501480000 = true (2ms)

+1020ms

║║Time restriction check passed

+1021ms

║║Condition #25 evaluated true (74ms)

+1023ms

║║Comparison (integer) 0 is_less_than (integer) 30 = true (0ms)

+1025ms

║║Condition #26 evaluated true (2ms)

+1092ms

║║Condition group #20 evaluated true (state did not change) (145ms)

+1093ms

║║Cancelling statement #20’s schedules…

+1105ms

║║Executed virtual command [Hallway Light].wait (1ms)

+1106ms

║║Requesting a wake up for Sat, Nov 17 2018 @ 11:51:35 AM PST (in 150.0s)

+1108ms

║╚Execution stage complete. (236ms)

+1116ms

║Setting up scheduled job for Sat, Nov 17 2018 @ 11:51:35 AM PST (in 149.996s)

+1266ms

╚Event processed successfully (1266ms)

#3

I do not code like this, but I believe you can change lines 111-121 to this:

IF 
    Unknown Device 6's motion changes to active  <-- Trigger
Then
    IF 
        @LevelEastHigh is equal to 60            <-- Condition
    Then
        With Switch 10, 14 & 21
        Set level to 15%
    END IF
END IF

Notice one IF is inside the other. The outer IF is the trigger, and the inner is a condition. This block should not look at the global unless Device6 changes to active.

#4

Yep just saw that too. It’s not supposed to be using @LevelEastHigh, that’s the wrong var and explains why its subscribing when it shouldn’t be. Thx.

As for using a condition inside a trigger… that seems logically consistent, but I suppose I figure the restrictions are there for a reason so I’m going to make use of them.