AlertR is a client/server based alarm system and monitoring system which targets developers, tinkers, privacy advocates, and all people that are interested in DIY solutions. Despite the obvious use as a home alarm system, it can also be used to help server administrators to monitor their services (or used in any other cases in which sensors are required). Because of the way it is designed, AlertR can be used in any scenario a sensor with the state triggered and normal has to be monitored. This can be a sensor for home security or home automation system, but also computer services like a failing HDD drive in a RAID or the availability of a web server.
The vision for AlertR is to have a single service running that gathers all the information someone wants (like temperature data, service states, or bank account transfers) and provides the ability to react on them automatically. In addition, it should serve as a single point to let the user lookup aggregated information of his/her services. All this should be done in such a way that the user is always in control of his/her data and no one beside him/her is able to access them.
alertR System Infrastructure
alertR 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 alarm 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 (so-called nodes) in a general alertR infrastructure:
Also, all sensors and alerts provided by the sensor and alert clients are grouped in a so-called alertLevels.
This section explains each type of client alertR has.
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 “triggered” or “normal”. 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). Additionally, a sensor can also hold data such as temperature. But this is optional and is not needed in many cases.
In order to keep the server as simple as possible, the sensor client has to decide if a sensor has triggered an alarm or not. This means that the server only gets the information about “triggered”/”normal” states and not the details about what happened.
The image above shows some cases for sensors. For example, it can be a window/door alarm switch which will trigger when the window/door is opened. The doorbell can be a sensor which triggers when someone rings the bell at your door. But not only hardware events can be sensors for alertR. A simple ping can be used to test if a host is up (or your Internet connection). Also, a script which tests a service of yours can be a sensor. Like mentioned before, there is no limitation of what a sensor can be as long as it can be abstracted to “triggered”/”normal” states.
The 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 make a call via an Asterisk server.
In the image above there are some cases 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 doorbell has ringed. The same goes for an XBMC (or now Kodi) notification. Also, a movie or music that is played on XBMC can be paused when someone is at your door. Additionally, a webcam stream can be shown via picture in picture on an XBMC system when someone rings at your doorbell or a motion sensor has triggered. Again, as long as it can work with the “triggered”/”normal” state abstraction, it can be used by alertR.
The manager client is a client that gets informed about the state of the alertR system. It is used to give an overview of the current state of the monitoring and alarm system and all its sensors. Also, the client is used to switch the activation state the alertR system.
Again the image above shows some cases for a manager client. A web access portal can be a manager client. A website shows the state of the alertR 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 a home alarm system with alertR can be a client with a PIN keypad. This client allows the user to activate/deactivate the alertR system after the correct PIN has been entered on the keypad. Or for Linux PCs, a small console manager client can give an overview of the current state of the system.
Copyright (C) 2017 sqall01