Why is this piston waiting at a semaphore? (IF A turns ON, turn B OFF, Wait 3 seconds, turn B ON)

#1

1) Give a description of the problem
I created a piston to turn something off, wait 3 seconds, and then turn it back on.
However, when it runs, it turns the thing off, but then waits ten seconds first, before moving on to the three second wait, and then turns the thing back on.

2) What is the expected behaviour?
see above

3) What is happening/not happening?
This is really simple. See above.

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

5) Attach logs after turning logging level to Full
2/22/2020, 11:12:22 PM +849ms
+1ms ╔Received event [SWITCH1].switch = off with a delay of 185ms
+8459ms ║RunTime Analysis CS > 20ms > PS > 8425ms > PE > 14ms > CE
+8460ms ║Piston waited at a semaphore for 8352ms
+8462ms ║Runtime (43831 bytes) successfully initialized in 8425ms (v0.3.110.20191009) (8459ms)
+8462ms ║╔Execution stage started
+8469ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+8471ms ║║Cancelling condition #2’s schedules…
+8471ms ║║Condition #2 evaluated false (5ms)
+8472ms ║║Cancelling condition #1’s schedules…
+8473ms ║║Condition group #1 evaluated false (state changed) (7ms)
+8475ms ║╚Execution stage complete. (13ms)
+8476ms ╚Event processed successfully (8476ms)

REMOVE BELOW AFTER READING

NOTE: As a temporary work-around, I went and built basically the same thing in Alexa, and it works just fine, because Alexa’s ‘wait’ command seems to work fairly well fairly consistently. I don’t normally like doing that, because I’d rather keep my automations in webCoRE, but this is just confounding.

So, any idea why it’s doing that whole waiting at a semaphore deal?

#2

Piston “ooxe” looks good to me… as long as Switch 22 does not change during the WAIT.

Edit:
If this is part of a larger code structure, it’d be more accurate to say:
“… as long as nothing triggers this piston during the WAIT.”
(unless you bring TCP into the mix)

Also, the log you posted shows: [SWITCH1].switch = off
(IE: I would expect nothing to happen when changing to off)

#3

Using the device names in your piston, the log just shows the piston responding to Switch 22 having been turned off. If you turn it off within three seconds or so of turning it on you’ll get that wait so the previous instance of the piston can finish.

#4

In the log, I just replaced the real name of the switch with SWITCH1 before posting.

Also…im sick right now. So, though i have time to mess with stuff, im slow and foggy. lol

#5

That’s the nudge I needed.

I think I figured it out.
Well, at least the general area it’s coming from.

I took a look at which other pistons might have ‘Switch 23’ involved (I love the fact that we can track things down like that since each piston is basically a separate SmartApp), identified one that seemed like it may be the culprit, temporarily disabled it, and then this automation works just fine.

I’m still not exactly sure why, but at least I know where the problem is, and can focus on that.

So, thanks again, guys. :slight_smile:

#6

Glad to be able to help!