Hacking Wireless Radiator Valves with Gnuradio

I have an ongoing project to improve the performance and automation of the heating system in our house, given the ever-rising cost of energy.  As part of this project I am planning to zone the central heating system to allow the temperature of each room to be controlled independently, and to do this I need a way of remotely controlling the radiators.  Because of the level of integration I am looking for I’ve been unable to find an off-the-shelf solution that meets my needs at a price that is acceptable.  Time to start hacking!

The Conrad FHT8V wireless thermostatic radiator valves (TRVs) are available for around £30, which is the sort of price I’m prepared to pay to get this project up and running.  I would ideally like to talk directly to these valves from my own controller, so I bought one of the £60 starter kits which includes the remote thermostat and took a look at the on-air protocol using Gnuradio.

To receive the signal a cheap RTL SDR dongle was used.  This has the Elonics E4000 tuner, which has almost continuous coverage from about 65 MHz to nearly 2 GHz.  The TRVs operate in an ISM band on 868.35 MHz.  Helpfully, the protocol has already been reverse engineered, making building a receiver a simple task.  The modulation is on-off keying with the symbols encoded as mark and space times of two different lengths, so a custom block was needed in order to decode and frame the messages.  This was written in C++ and integrated with the rest of the receiver in Python.

The code can be found here, and should serve as a simple introduction into writing custom Gnuradio blocks.

The flow graph is coded in Python without using Gnuradio Companion because I felt it was easier to get the separate decoding thread working in this way, and is simply:

Source -> 50 kHz channel filter -> Demod (Magnitude squared) -> Decimate -> Custom Decoder

Modtool was then used to generate the boilerplate code for the custom block:

$ gr_modtool.py create fs20
$ cd gr-fs20
$ gr_modtool.py add framer_sink -t sink
Operating in directory .
GNU Radio module name identified: fs20
Code is of type: sink
Block/code identifier: framer_sink
Full block/code identifier is: fs20_framer_sink
Enter valid argument list, including default arguments: 
Add Python QA code? [Y/n] n                                                                                           
Add C++ QA code? [Y/n] n

The decoder block performs symbol decoding, rejecting pulses of unacceptable length, passing the resulting binary values to a state machine for packet synchronisation and parity checking.  Once enough bits have been received the packet is pushed onto a queue for asynchronous processing from Python.

To build, ensuring Gnuradio is in your path and that you have CMake:

$ cd gr-fs20
$ mkdir build && cd build
$ cmake ..
$ make
# make install

The decoder can then be run in-situ with:

$ ./fs20rx.py

The asynchronous part of the decoder runs in a separate thread within the Python script.  Packets are popped off the message queue as they arrive and are checksummed using the FHT algorithm, which is subtly different to the FS20 one.  If the packet is valid then the length of the message is inspected to determine whether it came from the thermostat or a window sensor.  Messages are then pretty-printed on stdout as they are received (which is about every 2 minutes).

Gnuradio FS20 receiver/decoder

Output of the Gnuradio FS20/FHT decoder

6 thoughts on “Hacking Wireless Radiator Valves with Gnuradio

  1. Niall

    Hi,
    I see you looked at the Pegler iTemp radiator valves as well (from your posting on another blog). I would be very interested in your write up you mentioned.

    I noticed that these valves look like a rebranded
    ELV – ETH comfort200 valves. And if so, there is a technical manual
    http://www.mikrocontroller.net/attachment/104157/98294_eth_200_arr_km.pdf
    (in German)
    Which gives circuit diagrams – but I see the chips are labelled IC1 etc.

    I am looking to start a similar project – wireless radiator valves in each room, talking to a thermostat in each room – calling the pump when needed. Prob all controlled by some small computer like the Raspberry PI. I am a coder, but not low level.

  2. Mike Post author

    Hi

    I haven’t done the write up yet due to other commitments but the executive summary is that I didn’t find them to be very hackable. The protocol seems to be code-hopped in some way, although with quite short bursts, but this will still make reverse engineering it difficult. They do seem to be the same as those ELV ones internally (good spot!), so the technical manual may be helpful. If I can ID the microcontroller then reprogramming may be an option.

    Have you found some off the shelf thermostats you are planning to use? I wanted something super-cheap, and although the JeeNode is pretty close to what I’m after it still fell short in a few respects, hence my own design (see other post).

    Mike

  3. MarcinP

    Judging by pinouts – MCU in question is likely Samsung’s S3C/F8275, whilst RF part likely to be Axem

  4. Mike Post author

    Hi. Yes I think I had come up with S3C/F8275 and Axsem AX5051. It seems likely that the MCU would be the mask ROM version so opportunities for hacking are probably limited.

  5. Derek

    Hi Mike,

    I have installed eight of the i-Temp i30 TRVs and am keen to achieve ‘zoned’ control via my HA project.

    Noticed the MAX! Cube LAN gateway
    http://www.conrad.com/ce/en/product/560896/eQ-3-MAX-Cube-LAN-Gateway

    and wondered if this would work with the i30s – however, the support desk at eQ-3 advise me that it won’t.

    Am handy enough with RFM12Bs and AVRs but your comments re the complexity of reverse engineering the RF protocol rather puts me off (as my knowledge of this stuff is not as advanced as yours).

    If you do give the i-Temp protocol another shot, I’d be keen to hear about it.

    Keep up the good work!

    Cheers,
    Derek.

  6. Mike Post author

    Hi Derek,

    From my limited evaluation I got the impression the radio link is only really useful for offsetting the temperature using the remote control. There may be other features but without a transmitter to reverse engineer they are not going to be easy to discover. I believe I tracked down the CPU and radio used in the unit (which agrees with someone else’s comments above), but the CPU is almost certainly the mask ROM version so hacking it that way will be out of the question.

    I actually find my i30 to be very noisy in comparison to the Conrad/ELV one – noisy enough that my wife complains about it!

    Mike

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>