Location Mode changes away from produced incorrect result

[pnbruckner]

1) Give a description of the problem
A Piston with an if statement that tests if Location Mode changes to any of one set and changes away from another set didn’t work.

2) What is the expected behavior?
Both conditions of the if should have evaluated to true.

3) What is happening/not happening?
The changes away from any of part evaluated to false, even though the Location Mode did just change away from one of the entries.

In the picture I’m referring to the first condition group of the second if statement. The logs show two consecutive events: Location Mode changes to Returning (:f0e9f598527e206e3175b1f965119279:), and Location Mode changes to Home (:b1070d1f86ac0eb5509e790e6c1d617d:).

I highlighted the condition in the log that evaluated incorrectly. This tests if Location Mode changes away from any of Returning, Vacation, or Away. Clearly, the previous event was Location Mode = Returning, and in this event Location Mode = Home. So, this condition should have evaluated to true. But as you can see in the log it evaluated to false.

FWIW, I’ve used this construct many times and it has worked just fine. And, yes, as I understand it, two triggers can be in the same condition group if they’re for the same device/attribute, which is the case here.

Is this a bug? It sure seems like it to me.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
2/18/2018, 3:56:35 PM +705ms
+0ms ╔Received event [Doral Ct].mode = Home with a delay of 92ms
+155ms ║RunTime Analysis CS > 23ms > PS > 47ms > PE > 86ms > CE
+158ms ║Runtime (45073 bytes) successfully initialized in 47ms (v0.2.102.20180116) (157ms)
+159ms ║╔Execution stage started
+172ms ║║Comparison (string) :b1070d1f86ac0eb5509e790e6c1d617d: changes_to_any_of (string) :f0e9f598527e206e3175b1f965119279:,:0330ac3fcc593bae7e16b64cb3917e59:,:58a71c424e58cffffc004203fcb08e32: = false (4ms)
+174ms ║║Cancelling condition #6’s schedules…
+174ms ║║Condition #6 evaluated false (8ms)
+175ms ║║Condition group #27 evaluated false (state did not change) (10ms)
+179ms ║║Comparison (time) 57395882 happens_daily_at (time) 84600000 = false (0ms)
+180ms ║║Condition #5 evaluated false (4ms)
+185ms ║║Cancelling statement #5’s schedules…
+188ms ║║Requesting time schedule wake up at Sun, Feb 18 2018 @ 11:30:00 PM CST
+200ms ║║Condition #24 evaluated false (6ms)
+201ms ║║Condition group #1 evaluated false (state did not change) (36ms)
+210ms ║║Comparison (string) :b1070d1f86ac0eb5509e790e6c1d617d: changes_to_any_of (string) :b1070d1f86ac0eb5509e790e6c1d617d:,:aa96cbc2a1c70bc707d94201749098ff:,:3678843679dc3d0590aa7b01f0ebb09a: = true (3ms)
+212ms ║║Cancelling condition #22’s schedules…
+213ms ║║Condition #22 evaluated true (7ms)
+222ms ║║Comparison (string) :b1070d1f86ac0eb5509e790e6c1d617d: changes_away_from_any_of (string) :f0e9f598527e206e3175b1f965119279:,:0330ac3fcc593bae7e16b64cb3917e59:,:58a71c424e58cffffc004203fcb08e32: = false (5ms)
+223ms ║║Condition #29 evaluated false (10ms)
+224ms ║║Condition group #25 evaluated false (state did not change) (19ms)
+228ms ║║Comparison (time) 57395931 happens_daily_at (time) 21600000 = false (0ms)
+230ms ║║Condition #31 evaluated false (4ms)
+231ms ║║Cancelling statement #31’s schedules…
+235ms ║║Requesting time schedule wake up at Mon, Feb 19 2018 @ 6:00:00 AM CST
+238ms ║║Condition group #30 evaluated false (state did not change) (12ms)
+245ms ║║Condition #26 evaluated false (7ms)
+246ms ║║Condition group #23 evaluated false (state did not change) (42ms)
+260ms ║╚Execution stage complete. (101ms)
+265ms ║Setting up scheduled job for Sun, Feb 18 2018 @ 11:30:00 PM CST (in 27204.031s), with 1 more job pending
+278ms ╚Event processed successfully (277ms)
2/18/2018, 3:03:18 PM +313ms
+1ms ╔Received event [Doral Ct].mode = Returning with a delay of 93ms
+159ms ║RunTime Analysis CS > 13ms > PS > 57ms > PE > 89ms > CE
+162ms ║Runtime (45060 bytes) successfully initialized in 57ms (v0.2.102.20180116) (160ms)
+164ms ║╔Execution stage started
+175ms ║║Comparison (string) :f0e9f598527e206e3175b1f965119279: changes_to_any_of (string) :f0e9f598527e206e3175b1f965119279:,:0330ac3fcc593bae7e16b64cb3917e59:,:58a71c424e58cffffc004203fcb08e32: = true (2ms)
+177ms ║║Condition #6 evaluated true (6ms)
+197ms ║║Comparison (string) :f0e9f598527e206e3175b1f965119279: changes_away_from_any_of (string) :b1070d1f86ac0eb5509e790e6c1d617d:,:aa96cbc2a1c70bc707d94201749098ff:,:3678843679dc3d0590aa7b01f0ebb09a: = false (17ms)
+198ms ║║Cancelling condition #28’s schedules…
+199ms ║║Condition #28 evaluated false (21ms)
+200ms ║║Cancelling condition #27’s schedules…
+201ms ║║Condition group #27 evaluated false (state changed) (31ms)
+204ms ║║Comparison (time) 54198515 happens_daily_at (time) 84600000 = false (0ms)
+206ms ║║Condition #5 evaluated false (4ms)
+207ms ║║Cancelling statement #5’s schedules…
+210ms ║║Requesting time schedule wake up at Sun, Feb 18 2018 @ 11:30:00 PM CST
+220ms ║║Condition #24 evaluated false (8ms)
+221ms ║║Cancelling condition #1’s schedules…
+222ms ║║Condition group #1 evaluated false (state changed) (52ms)
+231ms ║║Comparison (string) :f0e9f598527e206e3175b1f965119279: changes_to_any_of (string) :b1070d1f86ac0eb5509e790e6c1d617d:,:aa96cbc2a1c70bc707d94201749098ff:,:3678843679dc3d0590aa7b01f0ebb09a: = false (3ms)
+233ms ║║Condition #22 evaluated false (7ms)
+234ms ║║Condition group #25 evaluated false (state did not change) (9ms)
+238ms ║║Comparison (time) 54198549 happens_daily_at (time) 21600000 = false (1ms)
+239ms ║║Condition #31 evaluated false (4ms)
+241ms ║║Cancelling statement #31’s schedules…
+244ms ║║Requesting time schedule wake up at Mon, Feb 19 2018 @ 6:00:00 AM CST
+246ms ║║Condition group #30 evaluated false (state did not change) (11ms)
+254ms ║║Condition #26 evaluated false (7ms)
+255ms ║║Condition group #23 evaluated false (state did not change) (31ms)
+259ms ║╚Execution stage complete. (96ms)
+262ms ║Setting up scheduled job for Sun, Feb 18 2018 @ 11:30:00 PM CST (in 30401.426s), with 1 more job pending
+271ms ╚Event processed successfully (270ms)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

[Robin]

You can’t do:

trigger
AND
trigger

Both triggers cannot occur at the exact same moment (ST is synchronous) so the piston can never be true.

try:

Mode changes away from home, guest or night (trigger)
AND
Mode IS returning, vacation or away (condition)

[pnbruckner]

That was definitely NOT the case in CoRE. The CoRE documentation specifically mentioned a condition group could AND two triggers together if they were for the same device/attribute, since (as you say) each event is processed separately. I.e., a Location Mode event can both change to something and away from something else at the same time. This worked for a long time for me in CoRE. I’d be extremely surprised if this capability didn’t make it into webCoRE. Are you absolutely sure?

[pnbruckner]

Here’s the documentation from CoRE that I was referring to (where triggers are described):

Evaluate an event that has just occurred, so it has one big limitation: within one conditional set, only one device/attribute pair trigger can be true at any given time, because events are processed one by one, :in the order they were received. This means you should never use (trigger) AND (trigger) as this construction will always evaluate as false, unless the two triggers involve the same device and attribute (i.e. (Light.level :changes to greater than 50) AND (Light.level changes to odd) would work and return true only if level is an odd number above 50)

[Robin]

Yes… two triggers cannot be put together, and I don’t remember such a setup ever working in CoRE either.

Personally I almost exclusively use conditions (which without triggers behave like triggers), and I try to avoid triggers where I can.

[Robin]

Supppse with the same device it might be possible… but location mode isn’t a device.

And changed away from is a webCoRE construct, not a ST attribute.

[pnbruckner]

Well, like I said, I used this in CoRE for a long time and it worked just fine. And I need this, because I need to test if Location Mode is changing from one set to another. I can’t just have “changes to one of A, B, or C”, because this evaluates to true if it changes from A to B (or from one of the set to any other of the set.)

And, FWIW, this was working for me in webCoRE, too. For some reason, though, it didn’t work this one time. Which makes me wonder if there’s a bug lying around.

[Robin]

The example I gave you above will provide the same end result…

[pnbruckner]

Ok, I’ll give that a try. Thanks!

[pnbruckner]

This works for me. Thanks.

I still don’t understand why two triggers concerning the same thing AND’d together doesn’t work in webCoRE when it worked in CoRE.

But, yes, in general, I agree - I tend to use conditions only unless I absolutely need to use triggers.

BTW, this Piston was originally written as conditions only, but I couldn’t get it to work because of another issue I ran into:

Does Task Execution Policy (TEP) apply to entire Piston, or just statement it is set in?

1) Give a description of the problem I have a Piston with two IF statements, and in each THEN clause I have a statement with TEP set to “Execute tasks on condition state change only”. 2) What is the expected behavior? If the condition in the first IF doesn’t change, but the condition in the second IF does, then the tasks in the statement in the second IF’s THEN clause should execute. 3) What is happening/not happening? They don’t execute. From the picture you can see the second condition is…

[pnbruckner]

To completely “close the loop”, here is what I ended up with:

Switch 1 is a Simulated Switch (aka Virtual Switch) that serves two purposes: In the ST app it 1) shows the state of the cameras, and 2) can be used to manually turn the cameras on or off.

So, if the (virtual) switch is changed manually, this Piston simply invokes the correct Piston to turn the cameras on or off.

But, if the Location Mode and time determine the cameras should be turned on or off, instead of directly invoking the appropriate Piston to do that, it just turns the virtual switch on or off. If that results in a change in the virtual switch, then this Piston will be invoked a second time (for the switch change) and the Piston will then turn the cameras on or off.

(Note that the Cameras On and Cameras Off Pistons will also turn the virtual switch on or off in case I invoke them via the Dashboard’s test button. Of course, in the automated scenario, that action will be skipped since the switch will already be in the appropriate state.)

Last (well, hopefully last) comment: As you can see in my first picture of the Piston implementation, I had the camera switch triggers in the same if statements as the ones that test Location Mode and time. And, although it wasn’t mentioned before, as I just said, the Cameras On and Cameras Off Pistons were changing the virtual switch. This scenario also caused this Piston to run twice for location/time events (once for the location/time event itself, an a second time for the switch change), but I was having trouble figuring out how to keep from invoking the Cameras On or Cameras Off Pistons each time. With this latest implementation, that is no longer a problem.

[kreene1987]

Tagging onto this topic, I am having the same issue as above, but slightly different. My code is as follows:

The Logs are as follows:
5/6/2020, 12:17:04 PM +351ms
+0ms ╔Received event [Home].mode = Home with a delay of 76ms
+96ms ║RunTime Analysis CS > 17ms > PS > 25ms > PE > 53ms > CE
+98ms ║Runtime (43980 bytes) successfully initialized in 25ms (v0.3.110.20191009) (97ms)
+99ms ║╔Execution stage started
+108ms ║║Comparison (string) :12e94606b2c8160bd9f47ef8871b014c: changes_to_any_of (string) :86eac641816d983a2d415f0d5fd1047e:,:95a652554f79f53ffd4f57af21893309: = false (2ms)
+109ms ║║Cancelling condition #28’s schedules…
+110ms ║║Condition #28 evaluated false (6ms)
+111ms ║║Cancelling condition #25’s schedules…
+112ms ║║Condition group #25 evaluated false (state changed) (7ms)
+116ms ║║Comparison (decimal) 0.0 changes_away_from (integer) 0 = false (0ms)
+117ms ║║Condition #29 evaluated false (5ms)
+118ms ║║Condition group #26 evaluated false (state did not change) (5ms)
+121ms ║║Comparison (string) :12e94606b2c8160bd9f47ef8871b014c: changes_away_from_any_of (string) :86eac641816d983a2d415f0d5fd1047e:,:95a652554f79f53ffd4f57af21893309: = false (0ms)
+122ms ║║Condition #30 evaluated false (3ms)
+123ms ║║Condition group #27 evaluated false (state did not change) (4ms)
+125ms ║╚Execution stage complete. (26ms)
+126ms ║Setting up scheduled job for Wed, May 6 2020 @ 12:31:35 PM CDT (in 871.015s)
+138ms ╚Event processed successfully (137ms)
5/6/2020, 12:16:41 PM +886ms
+0ms ╔Received event [Home].mode = Away with a delay of 143ms
+72ms ║RunTime Analysis CS > 19ms > PS > 21ms > PE > 33ms > CE
+75ms ║Runtime (43352 bytes) successfully initialized in 21ms (v0.3.110.20191009) (74ms)
+76ms ║╔Execution stage started
+85ms ║║Comparison (string) :95a652554f79f53ffd4f57af21893309: changes_to_any_of (string) :86eac641816d983a2d415f0d5fd1047e:,:95a652554f79f53ffd4f57af21893309: = true (2ms)
+86ms ║║Cancelling condition #28’s schedules…
+87ms ║║Condition #28 evaluated true (6ms)
+88ms ║║Cancelling condition #25’s schedules…
+89ms ║║Condition group #25 evaluated true (state changed) (8ms)
+91ms ║║Cancelling statement #34’s schedules…
+1400ms ║║Executed physical command [Switch - Dining Room].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (935ms)
+1401ms ║║Executed [Switch - Dining Room].setColor (937ms)
+1429ms ║║Executed physical command [Switch - Dining Room Track].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (25ms)
+1430ms ║║Executed [Switch - Dining Room Track].setColor (27ms)
+1455ms ║║Executed physical command [Switch - Downstairs Hallway].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (22ms)
+1456ms ║║Executed [Switch - Downstairs Hallway].setColor (24ms)
+1482ms ║║Executed physical command [Switch - Entry].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (23ms)
+1483ms ║║Executed [Switch - Entry].setColor (25ms)
+1508ms ║║Executed physical command [Switch - Garage].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (21ms)
+1509ms ║║Executed [Switch - Garage].setColor (23ms)
+1535ms ║║Executed physical command [Switch - Guest Bathroom].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (23ms)
+1535ms ║║Executed [Switch - Guest Bathroom].setColor (24ms)
+1561ms ║║Executed physical command [Switch - Guest Bedroom].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (23ms)
+1562ms ║║Executed [Switch - Guest Bedroom].setColor (25ms)
+1590ms ║║Executed physical command [Switch - Library].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (24ms)
+1591ms ║║Executed [Switch - Library].setColor (26ms)
+1618ms ║║Executed physical command [Switch - Living Room].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (25ms)
+1619ms ║║Executed [Switch - Living Room].setColor (26ms)
+1645ms ║║Executed physical command [Switch - Master Bathroom].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (23ms)
+1646ms ║║Executed [Switch - Master Bathroom].setColor (25ms)
+1671ms ║║Executed physical command [Switch - Master Bedroom].setColor([[hex: #FF0000, hue:0, saturation:100, level:50]]) (21ms)
+1671ms ║║Executed [Switch - Master Bedroom].setColor (23ms)
+1674ms ║╚Execution stage complete. (1599ms)
+1675ms ║Setting up scheduled job for Wed, May 6 2020 @ 12:31:35 PM CDT (in 891.93s)
+1741ms ╚Event processed successfully (1741ms)

Expected behavior is that the “changes away from” and “Away” would trigger True and set the color of my switches back to standard blue (just like it does for Away --> Red), but this is equating to False and I’m not sure why.

Note that I also modified the code to “Changes to” and “Home” and it still evaluated false.

Help?

Edit: I was able to move the “blue” section down to the Else section so it runs if all other items evaluate false then it runs, but the above still doesn’t make sense to me.