Announcement

Collapse
No announcement yet.

The Wait Action

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    The Wait Action

    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.

    Click image for larger version

Name:	Wait1.PNG
Views:	344
Size:	40.8 KB
ID:	1269842

    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

    Click image for larger version

Name:	Wait2.PNG
Views:	296
Size:	22.4 KB
ID:	1269843
    .
    The Event actually looks like this in terms of processing:
    Click image for larger version

Name:	Wait3.PNG
Views:	287
Size:	13.4 KB
ID:	1269844
    PAUSE 10 seconds
    Click image for larger version

Name:	Wait4.PNG
Views:	285
Size:	9.1 KB
ID:	1269845
    PAUSE 10 seconds
    Click image for larger version

Name:	Wait6.PNG
Views:	283
Size:	5.8 KB
ID:	1269846

    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.

    Click image for larger version

Name:	Wait5.PNG
Views:	310
Size:	37.0 KB
ID:	1269847

    Click image for larger version

Name:	Wait7.PNG
Views:	289
Size:	22.8 KB
ID:	1269848

    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.



    #2
    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".

    Comment


      #3
      Originally posted by BobSpen View Post
      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.

      Comment


        #4
        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.....

        Comment


          #5
          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?

          Comment


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

            Comment


              #7
              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.

              Comment


                #8
                Originally posted by aa6vh View Post
                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.

                Comment


                  #9
                  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.

                  Comment


                    #10
                    Originally posted by randman View Post
                    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.

                    Comment


                      #11
                      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).

                      Comment

                      Working...
                      X