Announcement

Collapse
No announcement yet.

∞ Events & Delayed Events Looping ∞

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

    ∞ Events & Delayed Events Looping ∞

    I have experienced event looping with the event in the screen capture below. I have also experienced the creation of over 9,000 events and delayed events.
    Click image for larger version  Name:	 Views:	0 Size:	109.6 KB ID:	1405266
    It is the same issue as described here: https://forums.homeseer.com/forum/ho...nts-on-restart

    After changing the rule to the screen capture below, it seems to be stable without any issues...until maybe after rebooting...(Have not attempted this as of yet).
    Click image for larger version  Name:	 Views:	0 Size:	68.7 KB ID:	1405267

    I have also noticed that while there is an 'Ungrouped Events' present, it takes much longer to load user-created events (most likely because there are so many ungrouped events). This can also happen simultaneously with an ongoing/looping event (as can be seen within the screen capture below regarding the 1st screen capture above).
    Click image for larger version  Name:	 Views:	0 Size:	147.6 KB ID:	1405271
    I have restored older event backups as well as deleting all events to stop the rogue events and then rebooted a few times. This has been a workaround to stop these events from getting out of hand although it still takes a long time for HomeSeer to attempt loading these 'Ungrouped & Delayed' events if they are still / become active.

    Seems like this request may be necessary to keep delayed events stable: https://forums.homeseer.com/forum/ul...-device-action

    As for infinite looping events, I am unsure of the cause...

    #2
    As you note, I have had some problems with "Ungourped" events. I suspect, but cannot prove that they occur when the number of delayed events exceeds some limit and HS can no longer keep track of them. I've been able to keep the problem under control by being careful about how I use the feature.

    A few suggestions:
    1. Instead of three delayed device actions create an event with the three actions and run the event with a delay.
    2. Add an action (as the first action) to delete any pending instances of the delayed event to prevent repeated light actuation generating lots of pending events.
    3. You could also add a do not retrigger time for your calling event to help reduce the load further.
    If you have a large number of events labeled as "Ungrouped" you can delete them all with the 'X' at the top of the list.
    Mike____________________________________________________________ __________________
    HS3 Pro Edition 3.0.0.548, NUC i3

    HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

    Comment


      #3
      It’s looping because the first Event is triggered by the device being set, which in turn sets the device, which in turn triggers the event. With this runaway, it will create 8100 (Figuring the event reruns once a second, 3 actions per second for 45 minutes) delayed device action Events during the 45 minute delay of the first three actions. Each delayed device action creates a new Event. This will cause the Event queue to choke. It can fail to put new Events into any group because it is too busy.

      The modified Event cures the problem by requiring the device to be set to a value greater than off and the actions are turning the device off.

      Comment


        #4
        Originally posted by rprade View Post
        It’s looping because the first Event is triggered by the device being set, which in turn sets the device, which in turn triggers the event. With this runaway, it will create 8100 (Figuring the event reruns once a second, 3 actions per second for 45 minutes) delayed device action Events during the 45 minute delay of the first three actions. Each delayed device action creates a new Event. This will cause the Event queue to choke. It can fail to put new Events into any group because it is too busy.

        The modified Event cures the problem by requiring the device to be set to a value greater than off and the actions are turning the device off.
        rprade , your explanation seems extremely important to me -- something I should strive to understand.

        But I don't.
        It’s looping because the first Event is triggered by the device being set, which in turn sets the device...
        Yes, but because of the 45 minute delay, I would expect that set not to occur for 45 minutes. So, there may be looping involved, but it appears to me that there ought to be 45 minutes of quiet time between each iteration of the loop.

        My sticking point is this: If you write an action statement to "Set Devices ... after a delay of 45 minutes ...", then I would expect any consequent event trigger to be evaluated at the (delayed) time when the device is actually set, not at the (immediate) time when the delayed device action event is created. Thus, looping, but at a 45 minute iteration rate.

        What am I missing here?

        BTW, I am a great fan of all your posts. I have probably learned more about event creation and processing from you than from all other sources combined.

        Comment


          #5
          You are correct. I didn’t think it through thoroughly. It would not set the three devices until 45 minutes have lapsed, but it would trigger the event again 3 times (each of the 3 delayed device actions would trigger the Event creating 3 more Delayed Device Actions each time) after 45 minutes, creating 9 delayed device actions, then after 45 minutes it would create 27 and so on. So in 450 minutes you could have 177,000 Delayed Device Action Events.

          The second event would not have the same problem.

          Comment


            #6
            How would a user go about doing these?

            Originally posted by Uncle Michael View Post
            2. Add an action (as the first action) to delete any pending instances of the delayed event to prevent repeated light actuation generating lots of pending events.
            3. You could also add a do not retrigger time for your calling event to help reduce the load further.

            Comment


              #7
              Not sure if this is what you are asking, but this is an example from one of my events. (It involves delayed event actions rather than delayed events, but the process is the same for both.) Does that answer your question?

              Click image for larger version  Name:	removedelay.png Views:	0 Size:	41.4 KB ID:	1406673
              Mike____________________________________________________________ __________________
              HS3 Pro Edition 3.0.0.548, NUC i3

              HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

              Comment


                #8
                Originally posted by Uncle Michael View Post
                Not sure if this is what you are asking, but this is an example from one of my events. (It involves delayed event actions rather than delayed events, but the process is the same for both.) Does that answer your question?

                Click image for larger version Name:	removedelay.png Views:	0 Size:	41.4 KB ID:	1406673
                Ah yes, thank you. I will test using 'Cannot Re-Run'. 🙂

                Comment

                Working...
                X