Most "home control systems" seem to be mostly quiescent in nature. This is quite expected as we do deal with a human environment and nobody in their right minds would want lights flashing on/off and doing weird things every second of the day. However, when "something" is supposed to happen, it must be instantaneous, at least in terms of human perception, such as with an audio-visual remote control. After all, if it takes just as long (or longer) for a switch-press to turn on a light as it would if we got up and walked a few steps, that would severly diminish the usefulness (or attractiveness) of a home-automation system.
Also, home-automation implies that "things should happen" in response to stimuli to the system. These stimuli can be categorized thusly:
An event-driven design approach is pretty ideal for stimulus/response programming.
However, the events cannot exist in a vacuum, so the last assumption is that the system should have an "awareness" (for lack of a better term) of what the system is comprised of. That is pretty much the definition of a persistence scheme.
Quick and dirty, the system must:
That sounds very straightforward, but it can be much more complex:
For example, a remote event can serve as a trigger, causing another remote event. And a timed event can cause a remote event, which is a trigger, etc. Instead of dealing with the potential causal (and endless) chains, if each of the events is treated as a singularity and let interested portions of code act on the events in their own ways, then the complexity will fairly well handle itself.
One of the most common features of most home-control software is the facility for showing the current state of the devices in the system. This can be done by maintaining state and updating that state based on the above events. An even-driven UI can also be used for receiving "interesting" events (such as device status changes), thereby providing the excellent "blinking lights" interface some technophiles prefer (such as myself). If, on the other hand, a different interface (e.g. web) is used to present status (and handle user actions), the current state should be maintained in-memory. This can be further extended to provide status logging (event @ time). (This last item is not a particular desire of mine, as I consider that just a bit too anal.)
Additionally, if the events are treated appropriately by the system (keep it simple, and fast), then the instantaneous requirement can be approached. Usually most systems will be able to respond appropriately within a second or two, which is "fast enough" by human standards.
Side Note: based on earlier home-automation systems employed, an empirical determination of the WTF (Wife Threshold Factor) places the outside boundary for event/response timing at approximately 5 seconds. Any activity outside this boundary becomes Non-Acceptable - and all of the other issues that entails.
|