alertR is an open-source alarm system with a client/server architecture. Because of its abstraction to sensors with only two states ("triggered"/"normal") it cannot only be used as a home alarm system, but also as a simple monitoring system for server administration (or any other scenario with "triggered"/"normal" state sensors you can imagine). For developers, it offers interfaces that allows them to integrate their already written scripts and programs into the alertR infrastructure (i.e., FIFO files).

The code can be found on GitHub as well as the documentation about the project on the GitHub Wiki page.

What is alertR?

alertR is an alarm system which targets developers, tinkers, 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). Here is a short introduction video of alertR as a home alarm system. This video was published in August 2014 and shows version 0.1 of alertR. Since then, a lot has changed and a lot new features were added. The subtitles have to be activated in order to understand what is happening.

Photo of the mobile manager (version 0.4).

The home alarm system was set up with the help of RaspberryPis to connect the physical sensors and alarms with the alertR system. But alertR is not limited to be only used via RaspberryPis. Any other platform that runs Python can be used as well.

What is special about alertR?

No Internet Connection needed.

Somehow it is sad that this has to be listed as "special". A lot of projects out there (this includes commercial products as well) need the Internet to be usable or to work at all. alertR does not need the Internet to work. It is no problem to use it without an Internet connection. Of course, functionalities like "eMail notification" will not work without an Internet connection, but the main functionality of alertR is not affected. One principle of alertR's design is to use the Internet only as a feature (like checking for a new version), but not as a main requirement.


You have complete access to the source code of the project. This means you can check the code and even modify it if you want to. Unfortunately, a lot of projects advertise open-source with "enhanced security" because anyone can check the code. But this does not mean that anyone does (or at least anyone with security knowledge). The code of most projects are not checked once. And when someone does, it often does not look so good afterwards. alertR is designed with security in mind and welcomes anyone who wants to take a look at the code or design. But to be honest, flaws in code will always happen and will so in alertR. The difference is that I am aware of it and would never claim otherwise ;) .

Client/Server Architecture.

alertR is designed in a client/server architecture. The clients are responsible to gather the data and to decide if an alarm by one of the sensors is triggered (sensor clients). Also, they are responsible to perform an action when a sensor triggers an alarm (alert clients) and to manage the state of the alarm system (manager clients). The server is responsible to organize the communication between all clients and to keep all clients in a consistent state.

Schematic of alertR's network architecture.

This architecture enables alertR to be easily deployed on multiple hosts and work together as one unified alarm system. For example, a home alarm system does not need to connect each sensor to the same host (i.e., a RaspberryPi). With this architecture, one can set up a host for each floor of the house to gather all the sensor data. As long as all hosts are connected to the same network, alertR can be deployed. Well, even a host in the garden that is connected via WiFi is possible.

Additionally, this architecture ensures a smaller code base. Since each client is specialized in performing its task, it has no need to have code that is not needed (i.e., the sensor client for FIFO files has no need for code that is needed to talk to RaspberryPi GPIOs).


alertR sensors work with two states: "triggered" and "normal". Everything that can be abstracted to these two states can be somehow integrated and monitored by alertR.

In order to make it easy to integrate things like already written scripts into the alarm system, alertR offers interfaces for them. This is especially interesting for all developers, server administrators and tinkers that already have written some programs or scripts that are doing a job for them like monitoring something. For example, one alertR client offers sensors in the form of FIFO files. With their help, the existing tools can write into these FIFO files and trigger an alarm in the alertR system.


I do not know if it is "special", but it is definitely cool (at least for developers ;) ). Most parts of alertR are written in Python. This allows (most) people to understand the code easily and to improve it. Furthermore, in comparison to low-level languages, it can improve the security of the code. Why? Well, many alarm system projects are written in C or C++ (open-source and commercial ones). The problem with these low-level languages is that the developer has to know what he is doing (and most developers do not). Low-level languages bring almost always security flaws in form of memory corruptions. And perhaps the only case in which using low-level programming languages is beneficial is when performance is needed. Well, alertR is not performance critical and can therefore be written in a scripting language like Python (the Python interpreter can have memory corruption issues of course, but this is out of scope for this article).

alertR's console manager (version 0.4) written in Python using urwid.

Where can I get it?

Perhaps some of you now think: "Ok you got me, I am interested!" (at least I hope that some of you will think this). If so, here are the links to get started with alertR:

If you want to reach me, have any questions, feedback or bugs, please use the GitHub Issues or Twitter.