Async doesn't seem to work properly

#1

1) Give a description of the problem
I’m having issues with a piston with async sentences and I have created a small test piston to show the issue. Basically I included 2 async sentences, and for some reason the second one is not executed.

2) What is the expected behaviour?
Both async sentences should be executed and the value of variable valor should be 3 instead of 7

3) What is happening/not happening?
Just the first async sentence is executed so the value of the variable valor is 7 after the execution

**4) Post a Green Snapshot of the piston!
(UPLOAD YOUR IMAGE HERE)

download
download.png1178×495 74 KB

5) Attach logs after turning logging level to Full

26/12/2019, 15:42:18 +88ms
+1ms ╔Received event [Inicio].time = 1577371338221 with a delay of -133ms
+116ms ║RunTime Analysis CS > 37ms > PS > 39ms > PE > 40ms > CE
+119ms ║Runtime (37641 bytes) successfully initialized in 39ms (v0.3.110.20191009) (118ms)
+120ms ║╔Execution stage started
+135ms ║║Executed virtual command setVariable (2ms)
+138ms ║╚Execution stage complete. (18ms)
+139ms ╚Event processed successfully (139ms)
26/12/2019, 15:42:14 +61ms
+1ms ╔Received event [Inicio].time = 1577371335273 with a delay of -1212ms
+130ms ║RunTime Analysis CS > 35ms > PS > 65ms > PE > 30ms > CE
+132ms ║Runtime (37642 bytes) successfully initialized in 65ms (v0.3.110.20191009) (130ms)
+133ms ║╔Execution stage started
+142ms ║║Executed virtual command setVariable (2ms)
+144ms ║║Cancelling statement #4’s schedules…
+148ms ║║Executed virtual command waitRandom (1ms)
+149ms ║║Requesting a wake up for Thu, Dec 26 2019 @ 2:42:18 PM GMT (in 4.01s)
+152ms ║╚Execution stage complete. (19ms)
+154ms ║Setting up scheduled job for Thu, Dec 26 2019 @ 2:42:18 PM GMT (in 4.007s)
+162ms ╚Event processed successfully (162ms)
26/12/2019, 15:42:10 +177ms
+0ms ╔Received event [Inicio].test = 1577371330176 with a delay of 1ms
+80ms ║RunTime Analysis CS > 12ms > PS > 37ms > PE > 31ms > CE
+83ms ║Runtime (37637 bytes) successfully initialized in 37ms (v0.3.110.20191009) (81ms)
+84ms ║╔Execution stage started
+88ms ║║Cancelling statement #1’s schedules…
+94ms ║║Executed virtual command wait (0ms)
+95ms ║║Requesting a wake up for Thu, Dec 26 2019 @ 2:42:15 PM GMT (in 5.0s)
+109ms ║╚Execution stage complete. (25ms)
+115ms ║Setting up scheduled job for Thu, Dec 26 2019 @ 2:42:15 PM GMT (in 4.982s)
+123ms ╚Event processed successfully (123ms)

#2

Your first WITH does not have ASYNC turned on…

Doing that will fix your issue.

pic

#3

Thanks but I want the first blocked to be executed first (so everything else waits), and then the other two blocks to be executed async (so the third block doesn’t wait for the second one), and I don’t understand why it doesn’t work.

#4

Then remove the WAIT from the first block.

That also solves it.

Normally, if I have to use ASYNC, I place it on the WITH that contains the first WAIT, as well as the blocks below.

#5

I included the first block because I need all the other blocks to wait a random time (for this test I included a fix value of 5 seconds) and then all the other blocks should start. I’m just trying to understand why webcore doesn’t execute the third block as it should, but if I can’t figure it out I will have to do it in a different way

#6

Why not make the first WAIT ASYNC, and then add 5 (or X) seconds to the other two WAITS below…

It will effectively solve your original question.

#7

As you probably realise, the problem is triggered by the initial wait being long enough to be implemented as a wake-up. On waking up the new instance only executes the first of the async blocks and nothing after that. It is like it thinks the block is synchronous when it calls it, but then it executes it asynchronously and confuses itself.

It is not how I’d expect it to work.

Maybe there are ways to change the behaviour by restructuring the code, for example placing the async blocks in a contrived conditional block. I’ve no idea if that sort of thing would help.

#8

If your first WAIT is not ASYNC, you can also lower the WAIT to 4 seconds or less, and your original piston works. If that WAIT is 5 seconds or more, it schedules a wakeup, and that is when the last block fails to run. (unless ASYNC is turned on block one)

#9

Thanks for the info, I am pretty new to webcore and I don’t know what a “wake up” is, but I will find out. In this case it looks like webcore is not working as we all would expect, but thanks to all your comments I have been able to fix my issue using a workaround

#10

When it comes to SmartHome programming… workarounds are our friends, LOL

I am curious, which one did you use to resolve this?

#11

As it was suggested I removed the first block with the wait that was causing the issue, and I included the wait sentence at the beginning of each of the other blocks

#12

Perfect. :+1:

Once we understand how the code is processed, there is almost always a way to achieve our goals.

#13

WebCoRE pistons, being SmartThings SmartApps, are limited to 20 seconds of actual execution time. A ‘wait’ can be implemented by a timed loop in the code that doesn’t do anything other than effectively pause things, but that eats up that execution time. So if the wait is five seconds or more, or there would be less than ten seconds left after the wait, the piston schedules a new run for the end of the wait period, and simply exits. So we can say the piston goes to sleep during the wait and wakes up at the end.

It is useful to be aware that this is how longer waits work.

#14

Thanks for the clarification, it is really useful. The only question that is still a mystery is why the last sentence is not executed after the piston wakes up, but I guess the mystery will remain as it is pretty simple to solve the issue with a workaround