Turn off virtual switch when contact opens

#1

1) Give a description of the problem
Have a virtual switch representing me “out on a walk”, which triggers Google fit walk tracking on my phone

2) What is the expected behaviour?
Virtual switch turns off when it is 1) on and 2) front door contact sensor opens

3) What is happening/not happening?
Piston is not executing the OFF command. Fails at “contact changes to open” condition.

**4) Post a Green Snapshot of the piston![image|45x37]

webcore_walk_stop
webcore_walk_stop.png1178×522 48.3 KB

5) Attach logs after turning logging level to Full
10/22/2020, 8:09:28 AM +221ms
+0ms ╔Received event [Front Door].contact = open with a delay of 54ms
+94ms ║RunTime Analysis CS > 20ms > PS > 41ms > PE > 33ms > CE
+96ms ║Runtime (38593 bytes) successfully initialized in 41ms (v0.3.110.20191009) (95ms)
+97ms ║╔Execution stage started
+108ms ║║Comparison (enum) on is (string) on = true (1ms)
+110ms ║║Cancelling condition #2’s schedules…
+111ms ║║Condition #2 evaluated true (9ms)
+114ms ║║Comparison (enum) open changes_to (string) open = false (0ms)
+116ms ║║Cancelling condition #3’s schedules…
+117ms ║║Condition #3 evaluated false (6ms)
+118ms ║║Condition group #1 evaluated false (state did not change) (17ms)
+120ms ║╚Execution stage complete. (23ms)
+121ms ╚Event processed successfully (122ms)

I’ve also tried the unspecified “contact changes” trigger followed by an inner IF (contact == open), and this wasn’t working either. This one is confusing the hell out of me because it seems like the most dead simple piston and it just will not work. I also have the IF statement set to “never cancel tasks”, as I thought maybe turning the switch off would somehow cancel the first condition, even though that is contradictory and doesn’t really make sense. That didn’t help either.

#2

For kicks, drag the contact changes to open trigger above the condition Switch 20 is on, then try it again.

#3

I was actually going to try just dropping the “switch is on” part entirely, since worst case it just redundantly turns off a switch that’s already off, but it would run a lot of times when it didn’t need to.

Anyway, tried your idea first - after testing it for 3 rounds of turning the virtual switch on manually, and opening the front door, it appeared to shut the switch off all 3 times. I’m still a little skeptical because I feel like the old way did work occasionally, just not reliably, but I’ll see over the next few “authentic” uses if it is solved.

Is it common practice to put triggers before conditions to avoid unusual behavior like this? Or was that just a shot in the dark? Would just like to avoid situations like this in the future.

#4

Increasingly so as we see problems brought up in the forum and a pattern emerges.

The way webCoRE handles triggers like ‘changes’ is that it compares a ‘new’ value, carried in the event that caused the piston to fire, with a cache of the value the last time the event was seen. As I find the webCoRE code hard to decipher I don’t know when that cache occurs but my theory is it requires the ‘changes’ comparison to be evaluated.

In this case the piston fires because the contact changes but if the switch is off at the time the trigger condition isn’t evaluated and so the piston never gets to cache the value. So if it doesn’t see a ‘close’ it won’t see an ‘open’ as a change.

It could be nonsense but it seems to have some validity. The same thing is seen with nested ifs and restrictions (‘only when’).

#5

Very interesting, appreciate the (possible) insight into the inner workings. Based on what I experienced when fiddling with this over a week or so, it feels like that could describe what was happening to me with the… unreliability.

I’ll try to remember to come back here after a few days if it remains working consistently so there’s more damning evidence for your theory. But it sounds like you’ve seen this phenomenon a bunch already. Perhaps they should consider a warning in the UI that putting conditions before triggers can cause this - or just forcing the triggers to come first.

#6

Just dropping in to say this has worked perfectly over the past few days. Still having some issues with the part that “starts” the walk, but I think the culprit is most likely outside the scope of webcore, dealing with tasker and the sharptools requests probably getting dropped when I transfer from WIFI to mobile.

Thanks again!