Piston Delay / Pause

#1

1) Give a description of the problem
Sorry, I am new to webCoRE but program extensively elsewhere. The forum interface is a bit different than I am used to. Time delays seem to be an issue in webCoRE. Such as things like allowing Amazon Alexa to finish what she is saying before triggering a new event. This is an issue when you have two or three triggers to send to Alexa as I am doing.

2) What is the expected behaviour?
Alexa can finish what she is saying (including random statements), before the next response event is triggered.

3) What is happening/not happening?
Alexa can be cut off mid sentence when an new event triggers. Alex routines do not have the ability to trip a switch AFTER Alexa says “bla bla”, only before. Therefore a delay needs to be implemented in webCoRE so Alexa can finish what she has to say before the next trigger. However, webCoRE does not have a good implementation of a delay timer inside of a piston.

My solution has been to use the delay timer for presence sensors in the ST stock routines. A simulated presence sensor set to “departed” can have a fractional min based delay. This routine will then flip a switch that process the next Alexa triggered response. and then resets itself. Its not elegant, it works, but becomes tedious with more than three stacked responses from Alexa. Does anyone have a better way to do this?

4) Post a Green Snapshot of the pistonimage
(UPLOAD YOUR IMAGE HERE)

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)

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

#2

The true issue is not with webCoRE… It is with Alexa.

Amazon does not want her being controlled by other devices, so any voice alerts are a hack. This means Alexa does not report that she has finished the alert (or anything else).

If you want to force in a wait between alerts, instead of jumping thru hoops, why not just send a WAIT for 8 seconds (or whatever), and then send the second command?

Pro Tip:
I would make the WAIT at least two seconds longer than the duration of the message…
(to allow for network congestion)

In my home, I typically set it to 10 seconds between messages, but I have a few WAITs set shorter or longer, depending on the expected message.

#3

Thanks for your help. I have changed over to using the WAIT function but is seems to be quite un-predictable. I have also seen that anything more than a 5 sec delay alters the way the piston executes and its not sequential (looks like it starts at the beginning again after a wake). I have it working again but not nearly as reliably. Are their any tricks you do to keep the timing more stable? I have re organized my piston to deal the execution issue but occasionally there is either a long delay or its way too short (Ive been timing it).

Using a simulated presence sensor and the delay “after all have left” function I got exactly 6sec for 0.1 min delay. Was a pain to implement as I had to ping pong switches, presence sensors, and contacts to make everything work but the timing was perfect.

#4

I find WAITS to be entirely predictable, but only after using them for awhile, and getting familiar with the way they are handled…

SmartThings limits execution to 20 seconds, so webCoRE tries to finish all processing within 10 seconds. Beyond 10 seconds, webCoRE schedules a wakeup timer to continue. At that point, the “define” section of the code is re-examined. Then the piston will continue where it left off IF the last condition is still true at the time of the wakeup.

Here is two posts of mine showing this wakeup in detail.

If the house is calm, I find my timings very consistent. If there is a lot of activity in my house (sensors, pistons or home network), then there may be a delay.

For a good example, I have 8 pistons “daisy chained” together. Each piston is at maximum capacity, and is over-loaded with complexity. The very last command executes the next sequential piston. With all 8 pistons running back to back, each with tiny WAITs programmed, the final piston runs within a 15 second window. This means (on average) that each piston behaves within about a two second variance.

This is why I suggested that:

(adding 4 seconds would be even more reliable)

Essentially, your WAIT in your piston should “cushion” a bit of extra time to allow for the inevitable delay during a hectic moment in time.

Edit:
Also, if the “total execution time” from top to bottom is 10 seconds or more, keep in mind that the wakeup may be a couple seconds off. I find that keeping “total execution time” to 9 seconds and less will keep the timings much more accurate.

#5

Thanks, very helpful information. Ill go through this in detail and optimize my pistons based on your recommendations.