Interval Condition

The Interval condition is like a free-running timer — it becomes true for a (very) brief period at specified intervals, allowing you to trigger periodic activities that may not necessarily be tied to a specified date and time. Reactor will try to preserve the timing as closely as possible across reloads or other events (like power failure) where the interval comes due while Vera is unavailable — it will run the missed task immediately, and then get back on schedule.

To specify an interval, just enter the number of days, hours, and minutes in the interval (one of them must be non-zero). The condition will become true on that interval and then automatically reset. This reset pulse is very quick — shorter than the UI can display. You can stretch the length of the interval pulse period using either a delayed reset (in output follow mode, the default) or changing the output mode to pulsed.

By default, all intervals are relative to midnight. That is, if you set an interval for every 90 minutes, it will occur at 00:00, 01:30, 03:00, 04:30, 06:00, ..., 22:30, and 00:00 (i.e. starting at midnight and every 90 minutes thereafter). If you wish to have the interval offset from a different time, you may specify that time with the "relative to" fields. For example, if we set the relative time for our 90-minute interval to 02:15, then the interval will trigger at 02:15, 03:45, 05:15, 06:45, 08:15, etc. The interval always passes through (occurs on) the "relative to" time.

It is also possible to have the interval sync to the last true transition of another condition, as shown in the second Interval condition in the screenshot above (note the "relative to" selection of "condition TRUE"). In this configuration, the Interval condition first fires when the "gating condition" goes true, and then at each time interval thereafter while the gating condition remains true. When the gating condition is false, timing is stopped and the Interval condition does not go true. As it applies to the example, the Interval would first trigger when the "Virtual Switch 10 Status is TRUE" condition goes true (i.e. the switch is turned on), and then every 15 minutes thereafter while the switch condition remains true. When the switch is turned off, the Interval stops triggering.

Deprecated Feature!

The use of the "relative to Condition TRUE" feature of the Interval condition is now deprecated. The preferred mechanism to use the "Pulse" output mode on what would be the gating condition of the Interval condition (see Condition Options). This feature will be removed from a future release, so you are encouraged to update your logic accordingly.

"Proper" Use of Interval Conditions

Generally speaking, it is not necessary to use an Interval condition to force the re-evaluation of other conditions. Reactor is sensitive to change for all condition types, so re-evaluations at times other than a detected change just wastes CPU cycles. The exception is a variable value, other than that resulting from the use of getEntity(), matchEntities() or groupMembers(), that needs periodic recomputation for some purpose, such as an accumulator, time series generator, or random number generator. It is not necessary to use Interval conditions to force re-evaluations of getEntity() (and others previously mentioned) dependencies because the subject entity is watched, so a change to the watched attribute is detected immediately and causes a re-evaluation, just as it would if the attribute were used in a Entity Attribute condition.

Interval and Daylight Saving

The Interval condition is intended to trigger (go true) on a specific interval from a given base point in time, not trigger exactly at a repeating moment in time. DST makes these two things a non-equivalence. For example, an interval of 7 days beginning at 20:00 on Friday, January 1, 2021 will quite literally fire every 604,800 seconds from that time, without respect to DST. When DST goes into effect, it will look to the user that the event is firing one hour (assuming that's the DST offset) late (i.e. at 21:00). However, this time is correctly 604,800 seconds on the interval from the non-DST time given as a base time. DST does not affect the function of time within the system: time is always advancing, counted monotonically from a reference point called the epoch (which is midnight January 1, 1970 UTC on Linux systems). DST only changes the human-readable representation of time.

Therefore, it is inapproprirate to use an Interval condition to fire a repeating event at a particular time at an interval of days. To get, for example, a weekly event at a particular time of day, use a Weekday condition AND'ed with a Date/Time condition using the after operator specifying the trigger time as its operand. Read why the after operator is recommended. For intervals not represented well as weekdays, the Interval condition can still be used, coupled with a Date/Time condition (in an AND group) to get the time component (on the Interval condition, use midnight as the time base, and specify a delay reset condition option of up to 86400 seconds to stay true the entire day).

Updated: 2021-Mar-28