Infrastructure
In this document I give a simple overview about the alertR infrastructure.
# Infrastructure - BasicsalertR uses a client/server based infrastructure. The server contains all the logic and is informed by the clients of the state of the sensors. When a sensor is triggered, the server decides what to do next.
The general infrastructure is shown in the following image:
At the moment there are 3 types of clients in a general alertR infrastructure:
- sensor
- alert
- manager
The sensor client is a client that manages one or more sensors. The sensor can be anything from a Raspberry Pi GPIO pin to a command that is executed and its result is checked. It does not matter. Important for alertR is that the sensor can be abstracted to either be a 1 (triggered) or a 0 (not triggered). When the sensor can be put into these states, it can be used by alertR (for example an incoming phone call which can be triggered via an Asterisk server).
To keep the server as simple as possible the sensor client has to decide if the sensor has triggered or not. This means that the server only gets the information about a triggered/not triggered sensor and not the details about the sensor state like temperature values or what ever the sensor observes.
The image above shows some examples for what a sensor can be. For example it can be a window/door alarm switch which will trigger when the window/door is opened. The door bell can be a sensor which triggers when someone rings the bell at your door. But not only hardware events can be sensors. A simple ping can be a sensor for alertR. With it you can test if a server is up (or your Internet connection). Also a script which tests a service of yours can be a sensor. Like said above, there is no limitation of what a sensor can be as long as it can be abstracted to triggered/not triggered.
## alertThe alert client is a client that gets informed by the server if a sensor has triggered and an alarm should be raised. It can be seen as the "executer" of alertR. The client can have one or more alerts that it can activate. An alert can be anything from a Raspberry Pi GPIO which is set to high and turns on a siren to making a call via an Asterisk server.
In the image above there are some examples for alerts. A D-Bus notification can be an alert for example. When someone rings at your door you can get a notification message on your PC via D-Bus that the door bell has ringed. The same goes for a XBMC (or now Kodi) notification. Also a movie or music that is played on XBMC can be paused when someone is at your door. Also a webcam stream can be shown via picture in picture on a XBMC system when someone rings at your door bell or a motion sensor has triggered. Again, as long as it can work with the triggered/not triggered abstraction it can be used by alertR.
## managerThe manager client is a client that gets informed about the state of the alertR system. It is used to give an overview about the current state of the alerting system and all its sensors. Also the client is used to switch the activation state the alerting system.
Again the image above shows some examples for a manager client. A web access portal can be a manager client. A website shows the state of the alerting system for example for mobile devices like an Android phone and alertR can be activated/deactivated via the website. Or another example for a useful manager client for an home alarm system with alertR can be a client with a PIN keypad. This client allows the user to activate/deactivate the alarm system after the correct PIN has been entered on the keypad. Or for Linux PCs a small console manager client can give an overview about the current state of the alerting system.
# Infrastructure - DetailsA more detailed infrastructure overview is shown in this image:
In this image you can see that sensors and alerts have something configured which is called alertLevel. An alertLevel can be seen as a logical group or categorization of sensors and alerts. Each alertLevel is configured on the server side and all sensors and alerts on the client side are a member of at least one alertLevel. When a sensor triggers, the client informs the server about it. Then the server looks up which alertLevel belongs to this triggered sensor and notifies all alerts which also belong to this alertLevel.
But let us understand the details behind alertLevels with the help of the example in the image above. The server has configured two alertLevels.
alertLevel 1 has the name "alarm" and has set the option "TriggerAlways" to "False". This means that this alertLevel only triggers an alarm when alertR is activated. This is useful for example when alertR is used as an home alarm system and you monitor if windows are opened or not. Surely you only want an alarm raised if you are not at home and not each time when you open a window yourself when you are at home. Also the alertLevel is configured to send you an eMail when it is triggered. Again this is useful for an home alarm system when you get an eMail when someone tries to break in into your house. Additionally the option "Rules Activated" is set to "False". alertLevels can have complex rules which are chained via Boolean operators like AND or OR. With the help of this you can for example create a complex rule set which only triggers when multiple sensors have triggered or motion detectors have triggered in a specific order or a specific sensor has triggered on a specific day. But for this alertLevel it is not needed.
alertLevel 2 has the name "notification". This alertLevel is set to trigger always and not only when alertR is activated. This can be useful for notifications. For example when someone rings at your door bell you always want to be notified at your PC and not only when the alerting system is activated. The alertLevel is configured to not send an eMail when it is triggered and the rules are again deactivated.
Now let us take a look at the sensors and alerts. The sensor "window alarm" is set to trigger the alertLevels 1 and 2 and the sensor "door bell" the alertLevel 2. On the other side the alerts "D-Bus notification" and "XBMC notification" are set to belong to alertLevel 2. The alert "siren" is set to belong to alertLevel 1.
When alertR is deactivated and the "window alarm" sensor is triggered, only alertLevel 2 triggers an alarm which means that only "XBMC notification" and "D-Bus notification" informs the user about the window alarm. When alertR is activated, the "window alarm" sensor also activates the "siren" alert and an eMail is sent to the user to inform her about the triggered sensor. On the other hand when the "door bell" sensor is triggered, the alerts "XBMC notification" and "D-Bus notification" always raise an alarm regardless of whether alertR is activated or not.