Understanding Random Event Triggers

[ericg]

I'm a little embarrassed to admit that I have been struggling for hours to use the EasyTrigger random event generation options to satisfy a single requirement, and so far, the solution completely escapes me.

As an illustration, here's what I want to do. Suppose I specify a one hour period, say, from 10:00 PM to 11:00 PM. During that time, the event engine will run 3600 iterations. I want to define a random time event occurrence that satisfies the following criteria:

• There is exactly one occurrence of the random timed event.
• The single event will occur at a time between 10:00 PM and 11:00 PM.
• Of the 3600 possible times for the single event to be triggered, all of them have equal probability of being selected by the algorithm.

I keep telling myself that this ought to be easy, but time goes by, and I still don't have a solution.

Anybody?

[randy]

I haven’t tested, but this should work:

Easy Trigger daily schedule



Event



It will trigger randomly once an hour, but be limited to 10:00PM-11:00PM by the schedule.

[spud]

I don't think Randy's suggestion would work.
Internally, what the easy trigger does is: pick a random number of seconds between the "No More" option and the "At least" option, then start a timer with this value, and trigger the event when the timer elapsed.
So if "No more" = "At least" = 3600seconds, it will always pick the same number = 3600

I have to think about this, but I feel like the "No more" condition does not work as one would expect.

[ericg]

I haven’t tested, but this should work:

...

It will trigger randomly once an hour, but be limited to 10:00PM-11:00PM by the schedule.

Your suggestion matches the first thing I tried. I did get only one trigger during the specified period, but over the first three days, I noticed that the trigger always occurred at/near the beginning of the specified period. Not random.

I have tried several other possibilities, all without success. I have presently scaled the times to be much shorter to facilitate collection of test data. Here is the test event I am currently using:


Using the Device History plug-in to track virtual device WakeUpEric, I am getting charts that look like this:



The chart is confirmed by Device History data that looks like this:



To my eye, there is no randomness here. Note that I am definitely not asserting that there is anything wrong with the algorithm or its implementation. I just can't find a way to make it do what I want.

[randy]

Your suggestion matches the first thing I tried. I did get only one trigger during the specified period, but over the first three days, I noticed that the trigger always occurred at/near the beginning of the specified period. Not random.

To my eye, there is no randomness here. Note that I am definitely not asserting that there is anything wrong with the algorithm or its implementation. I just can't find a way to make it do what I want.

Like I wrote, I hadn't tested it. The problem may be in the Condition preventing a successful trigger except once a day. Also based on what Spud wrote I moved the once an hour to the "Cannot Re-Run" option in the Event. I have put together another pair of events that may help me understand the randomness of an unrestricted trigger. I'll let them run for a day and see what happens.

[logman]

Would this work, or am I confused???



--Barry

[randy]

Would this work, or am I confused???



--Barry

Probably, but it could trigger more than once in an hour, depending on how the randomization works.

• There is exactly one occurrence of the random timed event.

[ericg]

Would this work, or am I confused???
...
--Barry

It didn't work for me when I tried it. I'm not sure I remember correctly, but I think I got nothing at all.

[randy]

I've been doing some heavy maintenance on both of my HS servers and it appears they were down in the 4:00 hour, but these log entries seem to indicate true randomness of the triggering Event I posted above. Since the condition in the called Event is not met, it is skipped.


Sep-01 6:21:59 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 6:21:59 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 5:07:19 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 5:07:19 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 3:54:51 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 3:54:51 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 2:49:42 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 2:49:42 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 1:01:45 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 1:01:45 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event.


I will let it run overnight to see how it goes, both when the Condition is met and to see if the trigger remains random. From what I see now, the pair of Events I posted in #5 above may meet the OP's requirements.

[ericg]

I've been doing some heavy maintenance on both of my HS servers and it appears they were down in the 4:00 hour, but these log entries seem to indicate true randomness of the triggering Event I posted above. Since the condition in the called Event is not met, it is skipped.


Sep-01 6:21:59 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 6:21:59 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 5:07:19 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 5:07:19 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 3:54:51 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 3:54:51 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 2:49:42 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 2:49:42 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event
Sep-01 1:01:45 PM Event Event Trigger "HomeSeer Demo Random trigger"
Sep-01 1:01:45 PM Event 'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event.


I will let it run overnight to see how it goes, both when the Condition is met and to see if the trigger remains random. From what I see now, the pair of Events I posted in #5 above may meet the OP's requirements.

I have collected some more data that I report here, but unfortunately, I am no closer to a solution now than at my initial post.
offered a second possible solution in his post #5. I had already tried this. It didn’t satisfy, but I didn’t collect data at the time. I offer here some additional data that might help somebody.

In order to collect data more rapidly, I scaled the problem times. Instead of a “random trigger at least once every 01:00:00” combined with the option “Cannot Re-Run For: [1 hour]”, I shortened both of those times to one minute. Also, instead of triggering an event whose time is extracted from a log, I made the event set a virtual device On, then reset it 4 seconds later. By using the “random” event to toggle a device, I was able to use Device History to collect trigger times.
I collected 41 samples from start until I started processing data. I used Device History to collect just the Off times. I copied these to a table in an MS Word document using cut and paste, and from there to MS Excel, also using cut and paste. I added the 4 second On duration to each of the Off times to convert them to event trigger separation intervals.
I sorted the Excel data by interval value, then plotted it to show the distribution of trigger times for my 41 samples. Here is the chart:

The shortest trigger interval was exactly one minute, and the longest was 1:44. One can see clearly from the chart that, as expected, the sample event intervals have a fairly linear distribution. The bad news: I can’t match the data to the goal. In the scaled representation, I was trying to get a trigger interval probability distribution that was flat over the interval of zero to one minute. What I got from 41 samples was a minimum of one minute, and a maximum of 1:44.
I resorted the trigger interval data to the time sequence of occurrence, obtaining the following chart:

As you can see, the intervals do appear to be random, but I still don’t know what to do with the min/max values for 41 samples. In the scaled test I ran, I was looking for successive event iterations to be spread evenly from 0 to 60 seconds. Instead, I got 60 to 104 seconds. So, I’m still stuck.

[ericg]

This is the event definition I used to collect the data I reported in Post #10:

[spud]

The cannot re-run option does not work because it just prevents the trigger from firing half the time.
I will fix the "No more" option

[randy]

The cannot re-run option does not work because it just prevents the trigger from firing half the time.
I will fix the "No more" option

I’m not sure about half the time, but it can prevent it from running occasionally. Your fix could work for a one shot, but I can see problems when done repetitively. It could work if it triggered once in every xx:xx where the time period remained chronological and the randomization was once within that period, such as this will trigger at a random time once every xx minutes from the top of the hour. The only other fix for a one shot as the OP wants would be a random time within a specific time period. Such as this will trigger at a random time within a schedule. Somehow the randomization must be in a period referenced to the time of day, not since the last trigger.

With the cannot Re-run, it missed at least one since I started yesterday and my condition was mistakenly 10:00-11:00AM instead of PM. It missed the 11:00PM hour and the 4:00PM hour(though my system may have been down then).

Sep-02 5:43:47 AM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-02 5:43:47 AM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-02 4:43:43 AM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-02 4:43:43 AM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-02 3:32:11 AM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-02 3:32:11 AM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-02 1:44:14 AM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-02 1:44:14 AM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-02 12:18:29 AM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-02 12:18:29 AM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 10:29:19 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 10:29:19 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 8:43:50 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 8:43:50 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 7:23:58 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 7:23:58 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 6:21:59 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 6:21:59 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 5:07:19 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 5:07:19 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 3:54:51 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 3:54:51 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 2:49:42 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 2:49:42 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

Sep-01 1:01:45 PM

Event

Event Trigger "HomeSeer Demo Random trigger"

Sep-01 1:01:45 PM

Event

'Run Event' action execution skipped, the conditions applied were not met: HomeSeer Demo Random triggered Event

[ericg]

Random Time Event Scheduling

...
I have to think about this, but I feel like the "No more" condition does not work as one would expect.

spud , thanks for your comment.

My grandmother used to say, "There's more than one way to skin a cat." (She was a dog person.) At the risk of giving unwanted advice, I'll offer a concept that you might find thought provoking. If I were assigned the basic problem of providing random time event triggering, my approach might be as follows:

Design Guidance:

As a guiding principle, any implementation of randomized time execution of an event should offer maximum flexibility and convenience, with a minimum of implementation complexity.

I’m a little uncomfortable with the concept of controlling randomly timed events in an IF statement. In my head, setting up an event with a random run delay is an action, and therefore more appropriate to a THEN statement.

Implementation Concept:

Full disclosure: I am not an HS3 developer, and I certainly don’t know any details of constraints on developers. As a user, I’m looking at the black box, and from its shape and size I infer what might be going on inside the box. So, I offer my suggestions in a spirit of humility. That said, imagine the following implementation (which may or may not be feasible):

Define two events A and B. Event B is the event that you want to delay by a time tweak that is based on a random number. Event A is the event that sets up event B to trigger at a fuzzy time.

Assume for now that event B is to run once only, at a time determined when it is invoked by an action statement in event A. In the drop down action list (THEN) there would be a new option: “EasyTrigger: Run Random Delayed Event.”

The EasyTrigger event specification would include and extend everything that is currently offered by the “Run Another Event” selection in the drop down list. The “EasyTrigger: Run Random Delayed Event” option would contain the following addition:

A time interval T would be accepted by the event action dialog. It would define the limits of a random delay to be added to the start time for the event being scheduled. A random number, scaled from zero to T would be added to whatever might otherwise be the computed start time for event B. (T = 0 is the special case that reduces the event invocation action to the original “Run Another Event” option.)

After using a random number to suitably adjust the start time of event B, EasyTrigger would then enter the event into the HS3 event engine’s Delayed Event queue. At that point, its processing of “EasyTrigger: Run Random Delayed Event” is complete.

If the implementation were performed as described, what would be the functional implications – i.e., how useful might it be? Following are some of the possibilities that come to mind.

The Original Problem:

I want event B to run once between 10:00 PM and 11:00 PM today, at a random time determined by a flat probability distribution. I create event A and schedule it to run at 9:59:59. Event A contains an action statement: “THEN EasyTrigger: Run Random Delayed Event”, for which I have specified, in addition to all the usual Run Another Event stuff, the parameter T = one hour.

EasyTrigger scales a random number to T, then enters event B into the Delayed Events queue with the computed execution delay. Mission accomplished.

If I had wished, I could have run event A at 8:00 PM and specified a 2 hour delay in the existing Delay Event Period parameter. The Delay Event Period would be added to the random time computed from the T parameter to determine the event B execution time.

If I wanted the same randomly occurring event to happen every day, I could schedule event A to occur every day – or on weekdays, Christmas, whatever. The random event B would automatically track to the schedule for event A.

Multiple Random Event Triggers Within an Interval:

I am uncomfortable with the “at least” concept multiple random event triggers within an interval, because to me it implies loss of control and unknown consequences for the process.

Under my proposal, if I wanted event B to run twice between 10:00 PM and 11:00 PM, I could simply add a second “THEN EasyTrigger: Run Random Delayed Event” statement to event A. This results in two event B entries in the Delayed Events queue. The times for both of them are selected by the same flat probability algorithm.

Because the two event B random run times are calculated independently, they can occur arbitrarily close to one another. The existing implementation offers a “No more than once every …” option to keep event B iterations from running too close together. Under my proposal, one could apply the existing “Cannot Re-Run For:” option in Event B.

Note that this option changes the original “at least” into a “no more than”. There are a couple of ways to evaluate this situation. On the one hand, if you really want to shoehorn N random iterations of Event B into an interval T with a minimum separation, you are creating a conditional probability problem that likely entails too much complexity for both the implementer and the user. Furthermore, forcing N iterations into period T tends to destroy the randomness. For example: Suppose you have a one hour window, and you want to force three random iterations into that window. If you specify a “Cannot Re-Run For:” time of 31 minutes, a solution is impossible. If the blackout time is 30 minutes, then you can squeeze in the three event B iterations – at exactly the beginning, middle, and end of the one hour window. Conclusion: Forcing N iterations with nonzero blackout times reduces the randomness theoretically, regardless of implementation.

As a practical matter, I suspect that allowing the specified event B blackout time to cancel an iteration would not create serious problems for most users. Consider the classic example of making your home look occupied at night. Over a period of, say, 6 PM to 11 PM, one might want to cycle the kitchen lights a half dozen times, and perhaps you want them on for 3 to 30 minutes each time they are turned on. Maybe you don’t want the kitchen lights to be turned on again for at least 12 minutes after they are turned off. If the random times are computed and scheduled entirely without regard for one another, then sometimes the computed run time for one iteration will fall within the blackout time of another iteration that occurred just a little earlier. And thus, instead of 6 cycles during the evening, you only get 5. Is that bad? I would argue no, that is just another aspect of the programmed randomness.

In case it isn’t obvious, event A would be run at 6:00 PM every day. It would contain 6 identical “THEN EasyTrigger: Run Random Delayed Event” statements to schedule 6 random event B invocations during the next T = 5 hours. To further mix things up, one could use different T values to simulate more kitchen activity earlier in the evening. When a kitchen light gets turned on, it needs to be eventually turned off. The easy way to do this is to include in event B (which turns on the lights) a “THEN EasyTrigger: Run Random Delayed Event” statement that invokes event C to turn off the lights. That statement could include a “Delay Event Period” to enforce a minimum On time before event C can turn the lights off. And the T parameter would add to that a random time for scheduling event C to turn the lights off.

Conclusion:

Lack of experience may have caused me to err both in usability and in feasibility, but I’m hoping I have offered a random event time implementation concept that is powerful, easily understood, and relatively simple to implement.

[ericg]

...
Somehow the randomization must be in a period referenced to [the] time of day, not since the last trigger.
...

I fully agree. You will note that, in my proposal, the randomization interval is anchored to a known, implicitly specified time of day.