Idea for a different kind of event processing mechanism

[Dean Roddey]

So, though we have triggered events, and they serve their purpose well enough, there are other things that are kind of triggered events but they don't fit well into the triggered event scheme, so you end up doing something sort of awkward to deal with those situations.

I was thinking of a way to do something that isn't infinitely tweaking and dealing with fifty different specific situations, but instead would be generic and very flexible, but not hard to set up. Here is what I was thinking:

Configuration

The configuration for each of these things (let's call them Reacts for lack of a better term) would be three columns, something like this:

• StartIf. This column controls when the React would start. It would allow for the following criteria, all of which are joined by AND/OR type logic indicators, and negation options.
  • The standard trigger filters used by triggered events, where if a trigger gets through the filter, it makes this one true.
    
  • A list of x * y type criteria, where X and Y are fields, variables┬áand constant values and * is┬áthe usual <, > , != , etc... operators. These will be joined by AND/OR as well.
    
  • A range of hours of the day and┬ádays of the week
    
  So if the correct combination of these things occurs, based on the settings you provide and the AND/OR combination, the React would start.
  
• Cancel If. There are situations where you want to cancel the thing because something occurred that makes it no longer useful. This one one be like StartIf, except the range of hours/days would be replaced by a maximum time at which to cancel it if the final criteria haven't been met. So you could cancel based on triggers AND/OR list of field comparisons. OR, it times out without ever hitting the reaction criteria.┬á
  
• React If. This one would let you set the conditions for final reaction. This one would have the list of field comparisons and either this much time has passed, or less than this much time has passed. So you could either just wait for a length of time and do it, or check for specific field states to occur within a specific amount of time and do it, or check the fields after a specific amount of time has passed and do something then.
  

At each of these steps you could configure an action to run. The last one would be mandatory since that's the whole point of it. But the others could allow you to set up something on start, or to undo something on cancel.

Each React could have its own global variables space, so it could save info in the StartIf action, which it could use later during the ReactIf action, and use those stored values in any of the lists of X = Y type comparisons. That includes the StartIf, because you might, for instance, want to suppress a start if this React has run in the last X minutes or some such.

So, that would be a fairly small amount of general purpose setup, but it could be used to handle a very large number of scenarios. It wouldn't replace triggered events. If you just want to turn on the hallways lights at night when the front door is opened, or turn on the lights upon motion with manual turn off required, or speak something if the front gate is opened, or log a message if a security zone goes non-secure at night, it would be serious overkill to use one of these for that. A triggered event handles all those types of things just fine. 

These guys are primarily for when where timing of events is involved (which is the weakness of triggered events since you need multiple things to handle the start/timing/end parts) or where there are more complex start and completion criteria.


Anyhoo, how does this sound. Can you think of anything that wouldn't be doable with that set of options? I really don't want to set up a huge page of very detailed, specific things, because people will always come up with more and it will get out of hand. The above is fairly simple to set up and understand and should cover almost anything, it would seem to me. Though if you can come up with something very useful it couldn't do, and a simple expansion of the above couldn't deal with it, then I can go back to the drawing board.