The Wait Action

[randy]

The "Wait" action inserts a pause in action processing. When a Wait action is placed between two Actions in an Event, the Event is suspended at the Wait action for the designated period of time. No further processing of the remaining Actions is done until the Wait period has elapsed. Wait actions are sequential. If there are two Wait actions back to back, each will pause the event in succession, making the Wait the sum of the two times. Here is an Example Event with 2 wait actions.



When the above Event is run, it will turn Device1 On, then the entire Event will pause for 10 seconds and execute the second action and turn Device2 On. After another 10 second pause the third action will be run turning Device 3 On. As you can see below, the three devices were turned on in succession with 10 seconds between each Action


.
The Event actually looks like this in terms of processing:

PAUSE 10 seconds

PAUSE 10 seconds


The Wait action also serves another purpose. When an Event is in a Wait state, it can be cancelled by the "Cancel Another Running Event" Action. This Action will ONLY work on an Event utilizing a Wait Action. An Event without Wait Actions is completed within milliseconds and therefore cannot be cancelled.

A Wait can be inserted between any Action or group of Actions. Here a Wait is at the top of the Event, with three Actions following. All three Devices will be turned on at once after a 10 second delay.





For short delays of a few seconds a Wait is generally more reliable and efficient than Delayed Events or Delayed Device actions. Those will be covered in another thread.

[BobSpen]

Randy,
I always try to avoid using "wait" because it can have some unintended results. One example is using a "wait" before starting a timer; the timer will start as soon as the "wait" STARTS, but it won't display in the timer device until after the "wait" ENDS. Then the count it displays shows it was running during the "wait".

[randy]

Randy,
I always try to avoid using "wait" because it can have some unintended results. One example is using a "wait" before starting a timer; the timer will start as soon as the "wait" STARTS, but it won't display in the timer device until after the "wait" ENDS. Then the count it displays shows it was running during the "wait".

That is a new one and one I just confirmed. Have you reported it to HomeSeer? Have you noticed any other problems with the Wait action? I use it somewhat and have never seen a problem, though I have never used it in conjunction with a Timer.

Other than the problem you just pointed out, I still contend that using a Wait is preferable to a Delayed Device Action for short delays. In that role and in delaying other actions, it has been predictable and reliable.

[BobSpen]

Discovered quite some time ago--I think I did report in Bugzilla. But as you know it's tough to get HS to focus on fixes.....

[randy]

Since Bugzilla is no longer, I will drop support an email tomorrow. Have you noticed any other anomalies with the Wait action or just the Timer weirdness?

[BobSpen]

No other anomalies that I recall, but as I said I use "wait" infrequently.

[Guest]

Question: If Homeseer reboots while the event is in the Wait state, does the following actions get lost? (I would assume so).

Perhaps another reason to use Delayed Actions instead of Wait. However, I find that using Wait instead of Delayed actions is easier to decipher what the event does, and its flow, when looking at it some time later.

[randy]

Question: If Homeseer reboots while the event is in the Wait state, does the following actions get lost? (I would assume so).

Perhaps another reason to use Delayed Actions instead of Wait. However, I find that using Wait instead of Delayed actions is easier to decipher what the event does, and its flow, when looking at it some time later.

I would expect that a suspended Event would be lost over a reboot. I will attempt to test it later. I think it is a reasonable assumption that an Event in a Wait state is not written to the database during shutdown. That is one of the reasons I suggested that a Wait is better for very short delays and that longer delays are better handled by a Delayed Device Action or Delayed Event.

[randman]

I've got a question on serialization/parallelizaton of actions within an event.
For example, I have three ACTIONS in an event:

THEN turn on outside door lights
THEN take a picture from camera and download it to HomeSeer PC
THEN send a pushover or email containing the picture

Does HomeSeer do any parallelization when running the actions in an event, or will it run them sequentially, one after the other?
I've had to add waits between the actions above. Otherwise, the picture may not be bright enough or the email attaches an older version of the picture since the new one hasn't been downloaded to the PC yet.

Just wanted to get the official word on how HomeSeer handles multiple actions - all serialized or parallelized if there are no waits?

EDIT: also, is putting waits, no matter how short, sufficient in ensuring that one action won't be started until a previous action has completed? Or should the wait length need to be at least as long as the amount of time that the previous action takes in order to run to guarantee that the next action won't start until the previous action completes? The reason I ask is I'm finding that I have to add a long wait between the time the camera takes the picture and the time I can start using the picture to attach to an email.

[Guest]

I've got a question on serialization/parallelizaton of actions within an event.
For example, I have three ACTIONS in an event:

THEN turn on outside door lights
THEN take a picture from camera and download it to HomeSeer PC
THEN send a pushover or email containing the picture

Does HomeSeer do any parallelization when running the actions in an event, or will it run them sequentially, one after the other?
I've had to add waits between the actions above. Otherwise, the picture may not be bright enough or the email attaches an older version of the picture since the new one hasn't been downloaded to the PC yet.

Just wanted to get the official word on how HomeSeer handles multiple actions - all serialized or parallelized if there are no waits?

EDIT: also, is putting waits, no matter how short, sufficient in ensuring that one action won't be started until a previous action has completed? Or should the wait length need to be at least as long as the amount of time that the previous action takes in order to run to guarantee that the next action won't start until the previous action completes? The reason I ask is I'm finding that I have to add a long wait between the time the camera takes the picture and the time I can start using the picture to attach to an email.

This is something I asked myself a couple of time.

[Guest]

What appears to me is that the actions in the event list are initiated (could even say "scheduled") when encountered. However, the action will not actually be started or completed until HS is no longer busy doing something else, including the processing of the original event action list. The presence of the Wait (even for the minimum 1 second) allows HS to be free to actually accomplish that action now.

I noticed this when updating counters, for example. The new counter value would not actually "show up" (and testing of that counter for the new value would fail) until HS paused for whatever reason (either by a wait, or by completing the event actions).