Controlling central heating with Arduino and Raspberry Pi


When Arduino and Raspberry Pi released first versions, I did buy one of each. Being a gadget man and … well, a man, I played for a bit with my new toys and left them in a drawer.

Time has passed and not much happened with any of them. As I became increasingly unhappy with the central heating controller in my current house, I decided to take the Ino and Pi out of the drawer and actually build central heating controller that I would be happy with.

The design phase

First requirement of the new heating control system was the least intrusive installation as possible.

The dial thermostat that I have at home, works as a simple switch: switching the heating on when temperature falls bellow pre-set; and switching heating off when temperature rise above another pre-set. I decided to use this simplicity in my design. All I needed to do is hook with one 230V cable into that thermostat (230V, hell yeah).

With entry point sorted, I went into the controller bit. Arduino board will control the Relay, which will simply switch heating on/off. For the temperature reading I chose the Digital Thermometer which offered more stable reading than the Analog one (included in Arduino Uno starter kit). I’ve also added LED to indicate when the heating was on.

Leveraging serial port used to program Arduino, I decided that the board will send temperature updates and receive setup command from Pi via USB connection. It will also be powered via the same. This also solved a problem of 2 separate power adapters for both Arduino and Raspberry Pi.

The build phase

I’ve been trying few things before arriving with the below solution.

Electronics

The Arduino circuit is very simple.

circuit-smaller

Three elements connected to Arduino with a couple of resistors, not much.

The LED is not necessary, it’s there to indicate when the heating is switched on.

The final prototype doesn’t look very attractive, but the lot is hidden under the furniture and the only elements sticking out are the temperature sensors and a bit of LED.

Final prototype of my controller

 

 

Software

I had to write three separate pieces of software:

Arduino

For the temperature sensor I included two extra libraries, the OneWire protocol library and a DallasTemperature sensor library. I use 0.5 centi-degree approximation of a temperature reading.

Temperature reads are sent via Serial Port on every loop. Arduino also expects the Float number on a Serial Port. The received number indicates the desired room temperature for Arduino.

To limit the sensor reading fluctuations, the control of relay changes after at least 10 successful consecutive reads of the same temperature from the sensor.

Raspberry Pi

The software that runs on Raspberry Pi does the following:

  • It waits on the temperature updates from Arduino, and stores the Updates in Memory (for the latest update) and in simple file based H2 database (for historical data),
  • It exposes REST API for UI to get the temperature information and receive the new settings,
  • It schedules temperature changes according to schedule stored in the JSON file.

I started the code in Python, but it was running slow. I did a simple comparison of execution time for Prime number algorithms, and Java 8 was beating Python. On a single core Raspberry Pi 1, it was a good incentive to change the platform. I chose Kotlin programming language as it was new to me and I wanted to learn it.

As a framework for Event driven application I choose Vert.x 3. For Serial Port communication, a bit dated RXTX library.

The UI / Phone controller app

The Web App I build works on computers as well as mobile devices. I did choose React as a UI framework with Material UI components. The lot is build with Webpack into a small set of html/js files.

The testing phase

The testing phase involved connecting everything together, starting it, and hoping that I will not sense the smell of burning electrics and experience no explosions. In other words, a standard scientific and engineering approach 🙂 .

I do run the setup for 4 weeks continuously and it not failed so far.

Summary

This is the first time I used my skills to build something that interacts with physical world. It gave me a great feeling of achievement and satisfaction. I know that I could buy something that looks much nicer and probably works better but I learned a lot during the process.

Raspberry Pi 3 was released while I was building my design and I switched to it. You can see it in the pictures. I also want to switch Arduino Uno prototyping board to Arduino Nano.

All the code and more detailed technical description is available for you to grab from my GitHub repository on https://github.com/greggigon/Home-Temperature-Controller .

My approach to JSONP limitations

Why JSONP?

Kanban columnDuring the development of My Personal Kanban I stumbled across interesting problem. One of My Personal Kanban features that I was developing, was the possibility to upload Kanban to Google Cloud (Google App Engine application).

My Personal Kanban is designed to work off the local file system, without the need of Internet connection. It means that trying to send something into Interweb is going to hit modern Browser security settings.

The browser security feature prevents web request from being made to a site with a different domain. It also stops from making a request to anything other the same file if you have opened any web application from the local file system. This kind of behaviour is default across any modern web browser.

Fortunately, there is a special type of requests browser will allow happening and it’s JSONP. It’s a GET request with a callback parameter. Callback is a name of the function that the browser will call when it receives successful response from the web.

HTTP GET request limits

My Personal Kanban is written in JavaScript with Angular; server side on Google App Engine is a very simple Servlet written in Groovy.

When I finished my first implementation and started to test it locally with Google App Engine SDK it all looked good. However, upload stopped working when I tested with a real GAE deployment.

Quick research confirmed that different web server implementation might have different settings for Maximum Length of HTTP GET parameters. Those GET parameters are used to send JSONP request data to the web server. Google App Engine has different limit than GAE SDK (which uses Jetty).

I also discovered that the upload was working in one browser but stopped working in another. As it turns out, browsers have its own limits of length of HTTP GET request. It is literally the length of the URL you will put in your browsers address box.

My Personal Kanban is sending a bit of data. It’s not Megabytes, however still too much for the HTTP GET parameters.

Choices of workaround

I thought of writing My Personal Kanban as Chrome extensions. It would enable me to overcome the JSONP limitations however it would bind my application to work on Chrome only. So I ditched the idea.

I decided to chop data into small chunks and send it to the server. To minimize errors of the transfer I invented this Client-to-Server protocol:

  1. All calls during transmission to server are in order, so the data can be assembled in correct way.
  2. First a handshake is made announcing the beginning of transmission for specific user, with information of how many data chunks will be sent.
  3. Chunks of data are sent only if previous chunk was sent successfully.
  4. Finally MD5 hash of data is sent so the server can verify that what was received is correct.

On server side I decided to store chunks for a user in session which in case of Google App Engine is stored in Memcache backed by Data Store. What happens on the server:

  1. Server receives a handshake and creates new Array for data chunks (or removes previous one if transfer was not completed or not successful).
  2.  Server receives data chunks and places them in the Chunk Array stored in session.
  3. When server receives Kanban hash it concatenates the Array in order into String and validates against received hash. If the hash is valid it stores the Kanban in the Data Store.

Details and code samples

The uploaded Kanban is Encrypted with user key and kept on the Cloud encrypted to ensure data privacy. I’ve chosen Rabbit as encryption algorithm. As a side effect to encryption, transmitted data doesn’t need to be encoded and sanitized.
For encryption I’m using fantastic CryptoJS library. CryptoJS also includes MD5 hash implementation.


md5Hash : function(stringToHash){
	return CryptoJS.MD5(stringToHash).toString();
},

encrypt: function(stringToEncrypt, encryptionKey){
	var utfEncoded = CryptoJS.enc.Utf8.parse(stringToEncrypt);
	return CryptoJS.Rabbit.encrypt(utfEncoded, encryptionKey).toString();
},

decrypt: function(stringToDecrypt, encryptionKey){
	var notYetUtf8 = CryptoJS.Rabbit.decrypt(stringToDecrypt, encryptionKey);
	return CryptoJS.enc.Utf8.stringify(notYetUtf8);
}

Thanks to fantastic Angular Promise API it is very easy to implement ordered transmission of data.

var encryptetKanban = cryptoService.encrypt(kanban, this.settings.encryptionKey);
var kanbanInChunks = splitSlice(encryptetKanban, 1000);

var promise = sendStart(kanbanInChunks.length);
angular.forEach(kanbanInChunks, function(value, index){
	promise = promise.then(function(){
		return sendChunk(value, index + 1);
	});
});

return promise.then(function(){
	return checkKanbanValidity(encryptetKanban);
});

My Personal Kanban is Open Source project and available for browsing at https://github.com/greggigon/my-personal-kanban/

Conclusion

The above approach made it possible to upload data to the server from any browser eliminating issues related to default browser’s security settings.
Unfortunately it comes with a cost of more HTTP requests and custom server side coding.

For small amount of text data it is good enough for me, perhaps it would be good enough for you. Let me know your thoughts.