Round Robin Database

From time to time, the HR80 radiator controller send the temperature they measure with an internal sensor. I wanted to display this data in a chart, and used RRDTool, which I already knew from previous (software) projects of mine.

Let’s quote wikipedia:

RRDtool (acronym for round-robin database tool) aims to handle time-series data like networkbandwidthtemperatures,CPU load, etc. The data are stored in a round-robindatabase (circular buffer), thus the system storage footprint remains constant over time.

It also includes tools to extract RRD data in a graphical format, for which it was originally intended.

Bindings exist for PerlPythonRubyTclPHP and Lua.

Okay, as I have six of this HR80 radiator controllers in my house, I created a round robin database for these using RRDTool:

rrdtool create temperature.rrd --step 300 \
DS:DG_WOHNEN:GAUGE:600:10:50 \
DS:DG_BAD:GAUGE:600:10:50 \
DS:EG_WOHNEN_1:GAUGE:600:10:50 \
DS:EG_WOHNEN_2:GAUGE:600:10:50 \
DS:EG_WOHNEN_3:GAUGE:600:10:50 \
DS:OG_BAD:GAUGE:600:10:50 \
RRA:AVERAGE:0.5:1:1200 \
RRA:MIN:0.5:4:2400 \
RRA:MAX:0.5:4:2400 \
RRA:AVERAGE:0.5:4:2400

This creates the six RRD data sources, step width are 5 minutes (300 seconds). The python script receiving and decoding the HR80’s messages just writes the temperature value received to this RRD:

# Update RRD
if deviceId1 in controller:
rrdtool.update(
'temperature.rrd',
'--template', controller[deviceId1],
'N:' + str(temperature))

Creating a chart of this round robin database is a piece of cake. I use the following RRDTool command:

#!/usr/bin/env python

import rrdtool

ret = rrdtool.graph( “./temperature.png”, “–start”, “-1d”, “–vertical-label=Temperatur”,
“-w 800”,
“-h 400”,
“DEF:m1=temperature.rrd:DG_WOHNEN:AVERAGE”,
“DEF:m2=temperature.rrd:DG_BAD:AVERAGE”,
“DEF:m3=temperature.rrd:EG_WOHNEN_1:AVERAGE”,
“DEF:m4=temperature.rrd:EG_WOHNEN_2:AVERAGE”,
“DEF:m5=temperature.rrd:EG_WOHNEN_3:AVERAGE”,
“DEF:m6=temperature.rrd:OG_BAD:AVERAGE”,
“LINE2:m1#0000FF:DG Wohnen\\r”,
“LINE2:m2#00FF00:DG Bad\\r”,
“LINE2:m3#00FFFF:EG Wohnen 1\\r”,
“LINE2:m4#FF0000:EG Wohnen 2\\r”,
“LINE2:m5#FF00FF:EG Wohnen 3\\r”,
“LINE2:m6#FFFF00:OG Bad\\r”,
“GPRINT:m1:AVERAGE:Avg m1\: %6.0lf “,
“GPRINT:m2:AVERAGE:Avg m2\: %6.0lf “,
“GPRINT:m3:AVERAGE:Avg m3\: %6.0lf “,
“GPRINT:m4:AVERAGE:Avg m4\: %6.0lf “,
“GPRINT:m5:AVERAGE:Avg m5\: %6.0lf “,
“GPRINT:m6:AVERAGE:Avg m6\: %6.0lf “,
)

print ret

An example chart created by this command:
temperature
This shows a time series of temperature measurements of all my six HR80 radiator controllers. You can see the temperature going down at 22:00 from 21° celsius to 17° celsius at 8:00 in the morning, where it again goes up in direction of 21° celsius.

Raspberry Pi in action

I modified the standard firmware of the RFBee in a way that puts the CC1101 in “asynchronous mode”, and just tunneled the RF data received through the RFBee’s serial interface. Using a XBee Explorer USB, I can receive this serial data over a USB cable on my Raspberry Pi.

Image

What was missing is a little python script that decodes the messages received “over the air”. Continuously receiving data from the serial port puts a heavy load on the pi’s CPU, but currently this is the easiest solution to receive the RF data without the need to built some custom hardware. But maybe, in the future …

 

About the RFBee

The HR80 radiator controllers and the CM67z controller units communicate via RF in the 868 MHz frequency band.

In Europe, 863 to 870  MHz band has been allocated for license-free operation using FHSS, DSSS, or analog modulation with either a transmission duty cycle of 0.1%, 1% or 10% depending on the band, or Listen Before Talk (LBT) with Adaptive Frequency Agility (AFA). To listen to this communication, a RF module called “RFBee” can be used. It provides easy and flexible wireless data transmission between devices and is based on a AVR Atmega168 (8 MHz internal clock frequency) working as a fully functional Arduino connected via SPI to a TI CC1101 RF transceiver.

rfbee

 

 

 

 

 

Pros:

  • Default firmware can be used to easily implement a point-to-point or point-to-multipoint network.
  • If you are free to decide how the frames sent over the air look like (e.g. length indicator or CRCs) then you can use CC1101’s built-in package handling functions.

Cons:

  • If you want to receive RF frames that are not supported by the CC1101’s built-in package handling functions, then you have to write your own customized firmware using Arduino, and you have to dive into the CC1101 specification. However, you can use large parts of the “original” firmware, which is available as source code.
  • With a Atmel ATmega 168 clocked with only 8 MHz, you don’t have too much computing power to do complex coding/decoding of frames received over the air.

My home control equipment

hr80In my home, there are six HR80 radiator controllers and two CM67z room units. These “room units” act as kind of controllers to the radiator controllers and provide central points from which to configure the system and set the time and temperature profiles for each zone. At a given time, as defined within a zone profile, the CM67z room unit transmits the required temperature setpoint to the respective HR80 radiator controllers. For communication, the HR80s use bidirectional radio frequency communication on the 868 MHz band. Unfortunatelly, one CM67z can only handle two zones. As there are two CM67z controller units in my home, I can control a maximum of four temperature zones.

Objectives:

  • It would be nice to integrate these radiator controllers into a home automation software solution.
  • It would also be nice to add some more HR80s and have more than the current four temperature zones in my home.
  • Absolutely cool would be the ability to monitor and control the temperature in the zones remotely using a web app on a mobile phone.

Let’s start!