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).
Output of the Gnuradio FS20/FHT decoder
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.
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
Judging by pinouts – MCU in question is likely Samsung’s S3C/F8275, whilst RF part likely to be Axem
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.
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.
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
Is the programming download for the i-temp terrier PRC i 30 no longer available. I have been informed that the software has been taken off the the market, i have the USB stick have tried the htpp://www.saveonheatingbills/helpSupport/downloads.html but it goes to the pegler sales sight. As you have probably gathered i am not conversant with these valves i have seven set to the factory settings for bedrooms and sittingrooms , which is ok but i would like to be able to fine tune them.