Skip to content

Thermostat Controlling System with Raspberry Pis

TL;DR

I built a thermostat controlling system because we regularly forgot to turn off the heating when opening the window in the same room. The system turns off the heating in the room when the window is opened and turns it on again after the window is closed again. And since I was at it, I also added the feature to control each thermostat in the apartment with the mobile phone.


Introduction

The problem my family had was this: when ventilating the room in the morning (or when needed) more often we forgot to turn off the heating. And if it is cold outside, this is a really bad habit. Not only for the costs of the energy that is wasted, but in regards to our global heating crisis this definitely has to stop. We tried different stuff to get rid of this bad habit, however, this did not work for long. After a while, when your head is back in the "So, what is my TODO-list for today?"-mode in the morning, we forgot the heating again. So, a more clever solution is needed.


Planing

When planing this, I had to consider the network and things I already had installed at home. In every room in my apartment I have a Raspberry Pi running connected to the network. Additionally, I already have magnetic switches on each window as part of the alarm system. The switches are connected to the Raspberry Pis. Hence, I only need thermostats that can communicate with the Raspberry Pis. Since version 3 of the Pi has Bluetooth built-in, I searched for Bluetooth LE compatible thermostats which I can talk to. The only thermostats fitting this requirement were the Eqiva Bluetooth Smart Thermostats (model 141771E0). Furthermore, there is a Python library which can communicate with these thermostats. This makes life way easier. For all Raspberry Pis below version 3, I just bought a USB Bluetooth adapter.



So, the overall hardware requirements for this project were:


  • Raspberry Pi (lower than version 3 additional Bluetooth USB adapter)

  • Eqiva Bluetooth Smart Thermostats (model 141771E0)

  • Magnetic switches for each window



However, hardware alone does not help us much. We need software which glues together everything. Since I run an AlertR setup at home, it was an obvious choice to hijack this environment to control the thermostats. The AlertR infrastructure already monitors and communicates every sensor state in the apartment so I can use it to transfer the temperature of the thermostats. AlertR was not directly built for this purpose, however, its design allows us to easily integrate the thermostats into it. On a high-level, the infrastructure we want to build looks like the following:




Local Thermostat Controlling

Before we can start integrating the thermostats in the AlertR infrastructure, we have to build something that is able to talk to the thermostats. I implemented a small service that communicates with the thermostats (if we want to be fancy we can call it "micro service" ;-) ). This service takes commands via a local FIFO file such as changing the temperature or reacting to an open window. We can easily instrument this with AlertR by executing local scripts that write into this FIFO file on triggered events. However, somehow this service has to tell AlertR about the current state of the thermostat (such as temperature or battery state). For this, AlertR offers the possibility to take sensor readings via a local FIFO file. In short, the AlertR infrastructure and the thermostat service communicate with each other via FIFO files on the local host.


Infrastructure Design

AlertR groups events into AlertLevels. The setup we want to create has actually two types of events we have to react on: window open/close and set temperature. The AlertR infrastructure design looks like the following:



On first glance, this seems really complicated. But it is not. Let us go through it step by step.

First, we start with the window open/close event. The window sensor (top left in the image) gives the AlertR sensor client running on the Raspberry Pi the signal that the window was opened/closed. This sensor transmits the information to the AlertR server. The window open/close event is part of AlertLevel1 which then triggers the event. It is transmitted to the AlertR executer client which then writes into the FIFO file of the thermostat service that the window was opened/closed. The thermostat service then turns off/on the heating by setting the temperature accordingly. This is everything we need to react to an window open/close event.



Before we start to look into how the temperature is controlled, let us take a look at how the temperature of the thermostat is processed by AlertR. The thermostat service reads periodically the temperature from the thermostat and writes this information into a FIFO file of an AlertR sensor (bottom left in the image). This information is transfered to the AlertR server which stores it. AlertR uses manager clients to control it. One of these manager clients keeps a copy of the system data in a database to share it with external components. For example, a website can read this data and display it. In this case, a small website shows the temperatures of the thermostats.

Now let us take a look how the temperature is controlled. Since this website shows the current temperature of the thermostats, it is the best place to give the user the possibility to control the temperature. When the user changes the temperature, the website writes this new value into a FIFO file of an AlertR sensor (bottom right in the image). This sensor is part of AlertLevel2 which triggers an event. This set temperature event is transmitted to the AlertR executer client which then writes the new temperature into the FIFO file of the thermostat service. The thermostat service then sets the new temperature on the thermostat.


Website

It would be cooler if the website for the thermostat is easily controllable by a mobile phone. So I wrote the website with this goal in mind. Next to the thermostat data it also shows the data of separated temperature sensors which I have placed in the rooms as well as local weather data.


Source Code

If you are interested in building something similar, the source code for AlertR is available as Github repository. Since the code for the website and the thermostat service is rather specific for my needs, I did not publish it (though everything is configurable). However, if anyone is interested in it, just contact me. I am happy to share the code.


Security Concerns

One big problem remaining is the security of the thermostats. When you are using the official App for the thermostats, you have to pair your mobile phone with the thermostats by entering a PIN code that is displayed on the thermostats. However, it seems that this is just for show. Because when you are using the Python library, you can just access it without any pairing. And this is not just a read-only access, you can set any configuration available. Meaning everyone in Bluetooth LE distance can change settings on your thermostats. This is really bad and the reason I hesitated to build this. However, the attacker capability is as follows:


  • An attacker has to be in near distance (50-100m away) to access your thermostats,

  • and the attacker can only change the temperature in your rooms.



If an attacker changes the temperature in your rooms you will notice it after a while (since you either start sweating or it is getting too cold). Meaning no big harm is done here. However, this is still an annoying issue. One way I thought about to tackle this issue is to use the thermostat service as an intrusion detection system (IDS). The thermostat service can monitor the values of the thermostat and notify the user if they are changing unreasonable. Then the user can react accordingly. It can also act as an intrusion prevention system (IPS) by restoring the thermostat state to the intended state. Overall, this is an interesting topic since most IoT devices have security issues which will not be patched and you have to cope with it (the same problem exists for medical devices and is part of current security research).

Dude, where is my car? (Android Edition) - Part 2

A year ago I started a project to be able to track my car in real time. Additionally, my idea was to use it as a car alarm system. I went through different iterations until I had a working system with which I was satisfied. This is the second part of a blog post series that describes how to track your car in real time and how to use it as a car alarm system.



The Problem: SD Card

The Raspberry Pi built into my car worked great. I got real-time location information about my car and was happy. However, after around half a year it stopped working sporadically. And then more often until it completely stopped. I hooked up the Raspberry Pi to a display and saw the problem: the SD card. Since the Raspberry Pi was directly connected to the power my car engine provided, it got power as soon as I started the car and lost it as soon as I turned off the engine. Because of all these abrupt power losses, the SD card was more heavily used than normally. Since it is a flash memory with only a certain number of read/write accesses, it died pretty early.

Now the easiest would be to just replace the SD card wit a new one. However, then I would run into this problem again. And since I am no hardware tinkerer, my skills in building a battery in front of the Raspberry Pi to provide it with enough power for a normal shutdown are limited. Furthermore, the Raspberry Pi needs some kind of signal that it should shutdown which means designing some kind of circuit for this. Also the Raspberry Pi has to start up again as soon as the engine starts. So, I was at a loss here first.


The Solution: Old Mobile Phone

I was thinking about the hardware problem I had and came to the realization: a mobile phone has exactly the hardware I need. Come to think of it, I do not know why I did not think about this in the first place. I need a GPS receiver for the GPS tracking. A mobile phone has one build in. I need a GSM/UMTS modem to transfer the data. A mobile phone has one build in. Now I need a battery to compensate abrupt power loss. A mobile phone has one build in. So, it has actually all the hardware I need and additionally needs less space. So I would call it a win-win situation. And since almost anyone has some old mobile phone lying around, there is no shortage on supply.

However, for this to work the mobile phone has to do two things it normally does not:


  1. Turn on as soon as it gets power from a power supply, and

  2. shutdown as soon as the power supply is turned off.



Since these are things I have to change in the operating system, I decided to give LineageOS a try. This Android based operating system gives me total access to the operating system and supports a wide range of mobile phones. I had an old mobile phone at home (a Motorola Moto G 2014) and started to tinker with it. After some searching in the Internet and some tinkering the mobile phone did what I wanted. I wrote two separated articles on how to modify your mobile phone for this:


  1. Android (LineageOS 15.1 and 16) Auto Boot on Charging

  2. Android (LineageOS 16) Shutdown when Power Supply Turned off

  3. Android (LineageOS 15.1) Shutdown when Power Supply Turned off



After that, the only missing piece was an Android App that gathers the GPS locations and transfers these to the server (basically the logger App for ChasR was missing). The source code for the Android logger is available on Github and it can be directly installed via Google Play. The App has to be configured to start automatically (just a checkbox in the App itself) and the power management of Android has to allow running the ChasR Logger in the background. This is just a setting in the power management options of Android one has to set. After that, everything works like a charm. The final setup in the car looked like this:



Again, I was able to track my car in real time either on my browser at home or via an Android App on my mobile phone:




Postscript

This setup runs now for over 3 months without any problems. The only shortcoming I could find so far is the long boot up time the mobile phone needs (around 40 seconds). I am thinking about trying to build a ChasR logger for a microcontroller. There are some controller boards that have exactly the hardware build in that I need for this. Then it should almost instantly track the GPS location. However, I never build something with a microcontroller. So it will be a steep learning curve for me :-)

The additional cool part about having written the logger Android App is that if car manufacturers should start shipping Android to their cars in the future, one can use this App directly in the car. Since a car will by then also have a GPS receiver and GSM/UMTS modem build in, it should work without any problems.

Dude, where is my car? (Raspberry Pi Edition) - Part 1

A year ago I started a project to be able to track my car in real time. Additionally, my idea was to use it as a car alarm system. I went through different iterations until I had a working system with which I was satisfied. This is the first part of a blog post series that describes how to track your car in real time and how to use it as a car alarm system.



The Beginning: GPS Tracking System

The first idea I had was to put a Raspberry Pi into my car that gathers the GPS data and submits it to a server. So I started to look into GPS tracking systems usable with Linux. Unfortunately, all GPS tracking systems I found where either in a way that I had to host them myself by using MQTT or they were only available as a service. The self-hosting suited me fine, but the MQTT part not. Why not? Because I have to open a port to the Internet for a MQTT server which I do not know the code quality of. Being a security enthusiast, I would rather have the GPS tracking system using HTTPS via a standard web server which I know is tested a millionfold. The GPS tracking as a service would also be fine for me as long as it gives me access to the data via an API. Unfortunately, the data is stored unencrypted (no end-to-end encryption) by the services and therefore do not protect my privacy (I do not want some provider to know where my car is all the time). Also, some other GPS tracking services did not have an API to fetch the stored data.

So, I started to develop an end-to-end encrypted GPS tracking system myself, called ChasR. The complete source code is available on Github if you want to host it yourself or you can just use it as a service (since the data is stored encrypted, your privacy is protected).


The Raspberry Pi

In order to install the GPS tracking into my car, I bought a Raspberry Pi (version 1), a USB GPS receiver and an UMTS modem. Obviously, the GPS receiver is used to gather the current location. The UMTS modem is necessary so the Raspberry Pi can transfer the GPS location data to the server. With the help of the Linux client for ChasR, the Raspberry Pi is able to do that. An early test setup looked like this:



To not drain the battery of my car, I connected the Raspberry Pi to the ignition of my car. Meaning, every time I started the engine of my car, the Raspberry Pi got powered up. However, I had a problem. Every time I turned off the engine of my car, the Raspberry Pi lost also power. First I thought I do not care. However, the temporary files stored locally by the ChasR logger were corrupted by this. Therefore, I added code to the client that syncs the filesystem each time a file is touched by the logger. As a result, the loss of power did not corrupt the temporary files anymore.

Finally, I was able to track my car in real time either on my browser at home or via an Android App on my mobile phone:

Behind the Scenes: hack.lu CTF Watchdog Infrastructure

After the hack.lu 2017 CTF was successful, there is some time to recap the feedback. One thing that we heard the last years was that the availability of our challenges is really great. To quote one of the feedbacks we got this year: "The CTF runs so flawlessly that I didn't realized I needed to ask for support.". I think there are two reasons for this (and everyone who ever hosted a CTF knows it is not the well written code of the challenges ;-) ). The first and main reason is the awesome team we have. Everyone is really dedicated to the hack.lu CTF and wants to make it a great experience for each participating team. The other reason, I like to think, is that we constantly monitor our challenges. And this is what this article is about.

Every challenge author always writes a proof-of-concept exploit for his challenge during the creation process in order to check if the challenge works. And our idea was that since the author writes the proof-of-concept exploit anyway, why not use it for the monitoring? So we created the guideline that each proof-of-concept exploit should be using the first argument for the address of the service, the second argument for the port, and an exit code unequal to 0 if an error occurred (there might be exceptions for this but this guideline is usually sufficient). That is all a challenge author has to take care of in order to provide a monitoring for his service.

But a bunch of scripts that can exploit the services of the CTF are not sufficient alone. We need a central entity that will notify us if anything goes wrong. And for this we use the alertR monitoring system. Mainly we use the following components of the monitoring system:

* alertR Server
* alertR Sensor Client Executer
* alertR Alert Client Push Notification
* alertR Manager Client Database

In the following sections I will describe what these components do and how they help us keeping the services up and running.


alertR Server

This is the main component of the monitoring system. Each client will connect to this server and send all information about the monitored services to it. In our case, the server has exactly one group (called alertLevel) to which each sensor (exploit that tests the services) and each actuator (called alert) belongs to. This alertLevel is set to trigger always an alarm even if the monitoring system is deactivated. How the alertR infrastructure looks in detail, can be read on the corresponding Github Wiki Page.


alertR Sensor Client Executer

This is the part that executes the exploits. It will check the exit code of each executed exploit and will raise an alarm if it is unequal to 0 (or the exploit times out). The interval in which the exploit is executed and a timeout value for the exploit is given by the author of the challenge.


alertR Alert Client Push Notification

alertR is able to send you push notifications to your Android devices. For this, you have to install the official alertR App on your Android and set up an alertR account (one account per monitoring system, not per Android device). Now every time a challenge has a problem, you get a push notification on your mobile device.


alertR Manager Client Database

This component allows you to provide the monitoring system data in a MySQL database for any component to process it. With the help of this, we provide two services:

IRC Bot

We wrote an IRC bot which can process the alertR system data. Most of our team is online in our internal IRC channel. Therefore, it was only a logical step to implement an IRC bot which will keep us updated on the current state of the CTF challenges. If a challenge encounters any problems, the IRC bot will post it into the channel.

Status Website

The website that shows the state of our challenges is used by us internally as well as by the CTF users. This website just shows the state of each challenge plain and simple. With this, CTF users can see if a challenge is actually working before they are asking for any support if they encounter problems.


Monitoring Infrastructure

Well, the hack.lu CTF is a hacking competition. Therefore, we try to make the infrastructure as secure as possible. This also applies to the monitoring system infrastructure. The alertR monitoring system is network based. This means that each component can be run on a different host. Since most watchdog scripts have the flag hardcoded, we have to make sure they can not be read by anyone. Because of this, we set up the executing mechanism on a separate host that only runs this part. As a result, we make sure that the attack vector for this crucial part is as narrow as possible. The status website as well as the IRC bot are also running on a different host than the alertR server. This is just circumstantial, but it certainly does not weaken the security of the system.


Final Words

I hope you enjoyed this little article about one internal aspect of the hack.lu CTF. Perhaps it is helpful to some people out there that are also hosting CTFs.

Building a MagicMirror using VESA mount

There are a lot of MagicMirror building tutorials out there. So why another one? The tutorials I saw always dismantled the display in order to build the case around it. I did not want to do it this way. Actually, I wanted to be able to easily exchange the display if it breaks down. So I decided to use the VESA wall mount capability of the display in order to fixate it into the mirror.

Another thing I saw a lot in other MagicMirror tutorials was that the front part of the frame had screws in it or was not sawed in a straight line. This I found rather ugly because it is the part you see the most when you use your MagicMirror in your living space. Therefore, I decided to use a frame for pictures that I can buy. At this shop (German link) I bought the frame "Monaco" in black with a size of 60cm x 40cm. Now the only missing part was the mirror glass. This I bought at this shop (German link), again with a size of 60cm x 40cm. When I got both, the mirror glass fitted perfectly into the frame. Now it was time to build the rest of it.

The first thing I did, I crafted a casing that I can put under the bought frame. I used a height of 13cm, but afterwards I realized it could be smaller (perhaps 8cm).















Next thing was that I painted the casing black in order to make it fitting for the bought frame.









Next I used wood glue to glue both parts together.








Because the mirror glass is really heavy, I did not think the glue alone would hold. Therefore I also screwed everything together from the inside.







This was the first intermediate result.









Next I used the VESA 100x100 mounting feature of my display to connect it to the mirror casing. I used an old 24" LCD display I had at home. If you use a new LED display, it would be thinner and much lighter. Personally, I would recommend to use a new LED display.









The first test of the display.







I used normal angle brackets to build a mount for the wall. These I use to hook the mirror up to screws I put into the wall.









Next I build a small mount for my Raspberry Pi 3 casing.







A small test if the new Raspberry Pi works with the vertical video output option.





Next I just added all the cables for the power supply and hooked it up to the wall.







And here is a final picture of it running the MagicMirror framework.



The mirror shows the sate of the alertR monitoring and alarm system. I wrote two MagicMirror modules, one that displays the states of the sensors and one that displays all sensor alerts. Also in order to reduce the power consumption, the MagicMirror tests if the alarm system is activated (and therefore everyone is sleeping or not at home) and turns off the display if it is. So if you are not only interested in the MagicMirror itself but also in alertR, feel free to give it a try :-)