Piston lag when executing actions

#1

1) Give a description of the problem
I created a simple piston that mirrors one lights behavior at certain times (time argument isn’t currently in the piston).

2) What is the expected behaviour?
When one light turn on, the other turns on and vice versa

3) What is happening/not happening?
When the initial light is turned on/off, there is a lag anywhere from 8-10 seconds before the second light turns on/off. I’m guessing this is the semaphore log event, but not sure how to fix.

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

hallway%20piston
hallway piston.png1178×692 96.3 KB

5) Attach logs after turning logging level to Full

+1ms ╔Received event [Entry Way Light].switch = on with a delay of 54ms
+10064ms ║RunTime Analysis CS > 15ms > PS > 10026ms > PE > 23ms > CE
+10065ms ║Piston waited at a semaphore for 10020ms
+10068ms ║Runtime (37327 bytes) successfully initialized in 10026ms (v0.3.114.20220203) (10066ms)
+10070ms ║╔Execution stage started
+10081ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+10084ms ║║Cancelling condition #2’s schedules…
+10087ms ║║Cancelling statement #3’s schedules…
+10105ms ║║Executed physical command [Porch Light].on() (12ms)
+10107ms ║║Executed [Porch Light].on (16ms)
+10109ms ║║Condition #2 evaluated true (32ms)
+10110ms ║║Cancelling condition #1’s schedules…
+10112ms ║║Condition group #1 evaluated true (state changed) (35ms)
+10120ms ║║Comparison (enum) on changes_to (string) off = false (1ms)
+10123ms ║║Condition #7 evaluated false (6ms)
+10124ms ║║Condition group #6 evaluated false (state did not change) (9ms)
+10127ms ║╚Execution stage complete. (57ms)
+10128ms ╚Event processed successfully (10128ms)
5/4/2022, 1:37:39 PM +430ms
+1ms ╔Received event [Entry Way Light].switch = off with a delay of 88ms
+10050ms ║RunTime Analysis CS > 14ms > PS > 10019ms > PE > 17ms > CE
+10051ms ║Piston waited at a semaphore for 10015ms
+10053ms ║Runtime (37326 bytes) successfully initialized in 10019ms (v0.3.114.20220203) (10051ms)
+10054ms ║╔Execution stage started
+10060ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+10061ms ║║Condition #2 evaluated false (4ms)
+10062ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+10067ms ║║Comparison (enum) off changes_to (string) off = false (1ms)
+10068ms ║║Cancelling condition #7’s schedules…
+10069ms ║║Condition #7 evaluated false (5ms)
+10070ms ║║Cancelling condition #6’s schedules…
+10071ms ║║Condition group #6 evaluated false (state changed) (7ms)
+10072ms ║╚Execution stage complete. (19ms)
+10073ms ╚Event processed successfully (10073ms)
#2

I’m not sure if this will make any difference at all, but why not try IF…THEN for both IF statements instead of IF…WHEN TRUE

#3

Why not reduce to one trigger so it doesn’t end up with semaphore? Unless you’re doing something more complex?

image
image.png1178×571 24.9 KB

#4

Thanks for doing that. I loaded it up from the backup code but still having the same semaphore issue:

+1ms ╔Received event [Entry Way Light].switch = on with a delay of 56ms
+10084ms ║Piston waited at a semaphore for 10049ms
+10086ms ║Runtime (36429 bytes) successfully initialized in 10053ms (v0.3.114.20220203) (10084ms)
+10087ms ║╔Execution stage started
+10102ms ║║Executed [Porch Light].on (4ms)
+10104ms ║╚Execution stage complete. (16ms)
+10105ms ╚Event processed successfully (10104ms)
#5

I’m not seeing where the semaphore wait is coming from. You get that if the piston is already running when an event fires the piston but your piston only takes about a tenth of a second or so to run and there is only the one subscription.

Does the entry light get turned on and off rapidly or is there a switch bounce?

#6

Welp, I thought I had it working, then it stopped working, then just stopped. Then saw this:

Smartthings Performance Degraded

I was about to cut bait and go back to Vera! :rofl:

Thanks again for helping me with this. I’ll give it a try again tomorrow. Stay tuned.

#7

That specifically related to issues with updates in the mobile app so it doesn’t seem likely to be a factor, though you never know.

Are those the complete logs you were sending? Having a semaphore wait appear out of nowhere is a bit odd

#8

No, I think I missed the first couple of lines in the copy and paste. There was def a semaphore in there.

As for the outage, does webcore use a direct association or thought the app? If it’s the former, wouldn’t an outage mess with that? Just curious.

I’ll try it again when I get home this evening. Thanks again.

#9

The ST problem was with delivering updates to the device controllers to the mobile apps. That’s the code that handles the UI for the devices. It gets updated outside the monthly mobile app update cycle. The mobile apps, particularly the iOS one, were a bit screwed, but it should not have impacted webcoRE.

WebCoRE pistons run as legacy Groovy SmartApps in the SmartThings cloud. The mobile apps only come into play for installing and configuring the parent webCoRE SmartApp(s). Similar to Smart Lighting really, except webCoRE also has the webcore.co site hosting a graphical frontend and other bits and bobs.

#10

Gotcha. Thanks for the explanation.

Tried again tonight, nothing. The weird thing is that I couldn’t get the piston to generate logs. Tomorrow I think i’m going to exclude both switches and start over.