Announcement

Collapse
No announcement yet.

HS automatically creating "delayed action" events

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

  • HS automatically creating "delayed action" events

    I was messing with some new events yesterday and now I'm seeing a new group called "Delayed Action" and in it is a bunch of delayed action that was triggerd. Any idea?

    Click image for larger version

Name:	delayed_action.jpg
Views:	31
Size:	43.9 KB
ID:	1241270

  • #2
    You have an event that is repeatedly triggering and creating them. Do a search in the log for the delayed action and you should be able to find the event. Or you can open up one of the delayed action events, find the device that is being controlled, then filter events on that device.
    Randy Prade
    Aurora, CO
    Prades.net

    PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

    Comment


    • #3
      Originally posted by rprade View Post
      You have an event that is repeatedly triggering and creating them. Do a search in the log for the delayed action and you should be able to find the event. Or you can open up one of the delayed action events, find the device that is being controlled, then filter events on that device.
      thanks got it figured out based on your suggestion.

      Comment


      • #4
        Good. Just wait until you screw up an event that triggers once a second for minutes, creating a delayed action an hour away. Don't ask me how I know Each minute creates 60 Events, each hour 3600. You will build a whole ton of delayed actions. I have read of a couple of people who had so many delayed device actions it brought the systems down.

        The most dangerous Events are triggered by "When a device has been for at least..." and "A timer's value is more than than...". Either of those triggers can swamp the system if they run away, especially if they create Delayed Device Actions or Delayed Events. It is a good practice to put a "Cannot Re Run:" value on any Event that uses either of those triggers - just in case. Clearly those triggers are safe if you use a device that is controlled by the Event as a Condition. That way the Event will not repeatedly trigger.
        Randy Prade
        Aurora, CO
        Prades.net

        PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

        Comment


        • #5
          Wonder if we added "Then wait...." as an action instead of within the action.

          There's gotta be a reason for the similar action to be located in two separate places.

          Comment


          • #6
            It might be important to understand the differences between a "Wait" and a "Delayed Device Action".

            A "Wait" Action suspends Event processing for the period of time defined in the Action. The remaining Actions in the Event will be processed after the Wait has lapsed. If there is more than one Wait in an Event, they are processed sequentially. If an Event is again triggered while in a Wait state, another copy of the Event will be spun off into an additional thread. This process is repeated each time the Event is run. The primary purpose of a Wait is to hold an Event in suspension so that it may be cancelled during the Wait period, using the "Cancel Another Running Event" Action. An Event cannot be cancelled unless it has a Wait. A Wit is sometimes the best option for very short delays. For example if you want to delay an action for a second or two for timing purposes, a Wait is probably more efficient than a Delayed Device Action.

            A Delayed Device Action spins off a fresh Event with a time trigger so that the device is controlled at a later time. If you run an Event at 10:00PM with an Action to turn a light Off after 10 minutes, a Delayed Device Action will be created with a 10:10PM Trigger. This Event will be placed in the Delayed Actions Group. Every time the primary Event is run, it will create a new Delayed Action Event. These Events self-delete after running. When you issue a Cancel a Delayed Device Action, all of the queued events for that device in the Delayed Actions group will be deleted. When all Delayed Device Actions are deleted, the Group is deleted.

            Delayed Event actions are handled in the same way as Delayed Device Actions, but are stored in the Delayed Events Group.

            Event Delays and Device Action delays are set in the individual Action and only affect the Action. The rest of the Actions in the Event are processed immediately. A wait is set in the Action as well, but further processing of the Event is suspended during the Wait.

            It is certainly a users choice as to the best times to use one over the other, but I tend to believe it is better to avoid using Wait for long periods of time. If I need a delay of greater than a few seconds I prefer a Delayed Device or Delayed Event Action. Whether you use a Wait or a Delayed Device Action, a repeatedly retriggered Event will run, either with many identical Events suspended in threads or as many Delayed Device Actions queued for later execution. Either way it presents a problem, you can see Delayed Device Actions and cannot see suspended Events, they are both created. For this reason it is up to you to design your events such that they cannot run away, either by using a device controlled by the Event as a Condition or by setting a Cannot Re-Run in the Event options.
            Randy Prade
            Aurora, CO
            Prades.net

            PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

            Comment

            Working...
            X