The control software managing the home automation installation deals with only a few basic concepts, which are explained here in detail:
Basically the view of the control software consists of events and actions. Actions can be triggered by events through a set of rules.
State information may be kept for quick reference without having to request it each time again. All components that can emit events or process actions are represented by objects in software.
Every activity in the system is triggered by an event, for example a switch being toggled. Events are sent into the system mainly by CAN input devices, which send their respective messages onto the bus and into the system.
The control computer's system clock can also generate events, for time-controlled activity.
Actions are the response to events and triggered by the control computer. For example, the activation of a lighting circuit requires an action, in this case sending the correct control current pulse to the correct switching device to which the lamp is attached.
Not every action needs to be visible externally, for example, a valid action may also be "store the value received from this sensor for later reference".
For easier configuration, one or more single actions may be grouped under a new name, and are then considered a macro. For example, "set light intensity to 30% in living room, turn off light in dining room, turn on television set" might be grouped to a macro "turn on television".
All input and output devices, are represented as objects in the software handling events and actions. For example, a wall outlet is represented by an object that keeps a certain state (such as current amperage, energized or not, through which bus device it can be controlled).
The actual implementation of the different objects is documented in the
HA-P03 software stack description.
Rules connect Events to Actions. For example, a rule might be "if switch 1.101 is pressed, toggle relay 1.204". More complex rules may involve more than one event, and involve state information saved before as well, for example a rule like "if switch 1.103 is pressed, and it is after 8 pm, and it is dark outside, close the window shades".
State is stored information that is delivered (as an event) periodically to the control system, but may be used independently of the actual event delivering it. An example is a temperature sensing device that reports every five minutes through the bus system, but queried by several rules being triggered by timer actions.
Note that, while the system clock can generate events through the respective program, the actual current system time is considered state information (it's stored in some place accessible for evaluation at any time).
There is a description to show how it all works together.