The Honywell Rondostat HR-20E

NOTE 2012-02-09: It seems people are still coming here for information about the HR20. Please be aware that this page describes the v1 hardware, which has been obsolete for several years. The new hardware (v2) is based on ATmega169, and an Open Source firmware exists. Please check the thread at embdev.net describing the new HR20E and the OpenHR20 firmware.

For now, this page is kept for historical reasons, but will probably vanish at some point.

Rondostat HR-20E RS-485 interface

This project is about controlling a Honeywell Rondostat HR-20E electronic radiator thermostat over an RS-485 bus. The idea for this project actually came shortly after I bought this thermostat at a local home-improvement center. After the unit was installed, I didn't think much about it for two years. Then I moved and took the unit with me. It's been sitting on the shelve for half a year now, and I decided to try and see if I could get on with this project.

Basically, the Honeywell Rondostat HR-20E is an electronic thermostat for use with central heating systems (water in the radiators). The HR-20E is installed on the individual radiator in place of the normal valve and allows the temperature to be set, but also allows programming times to turn on and off the heat on a weekly basis. You can have 2 programs (i.e. two times to turn on and two times to turn off) each day of the week.

Additionally, the unit has several nifty features, such as detecting when a window is opened (and turning off the heat). Also, when the heat is off (e.g. when the thermostat is set to manual mode in the summer), it will still occationally exercise the valve to avoid it becoming stuck.

Controlling the HR-20E

In order to control the HR-20E I first opened up the device and inspected the PCB. It uses a NEC 4-bit uController, which I was actually able to find a datasheet for, but this did not get me much further. I also noticed that the HR-20E has a small removable panel, and behind it is a 10-pin header, which is presumably some kind of programming/debugging connector.

Using the datasheet and doing some measurements I would attempt to determine if it would be possible to control the HR-20E through this interface. If not, it would have to be controlled by simulating button presses and reading status from the LCD. Although my search in the datasheets did not give great results, I found this thread on a German microcontroller forum, which describes how the 10-pin connector in fact does provide a serial interface to the device, and also linked to a document describing a lot of details concerning the communication protocol.

On this page I will gather the information I have found, and when I get the thing working, the source code will be available here. Although most of the information has been discovered by other people, I want to repeat it here for a couple of reasons:

Electrical interface

The HR-20E runs on 3V supplied from two AA-batteries in the unit. The serial port available in the debug connector also uses 3V levels, and a level-converter is therefore needed to interface with a PC serial port. I used a MAX3232, which does the level translation and works with a 3V supply. For the experiments I have done so far, I simply powered the MAX3232 from the battery voltage available in the HR-20E debug connector.

The debug connector is hidden behind a small panel on the left side of the thermostat (when the adjustment knob and LCD is facing towards the user). The panel can be pryed off with a sharp knife, small screw driver or similar, but it actually seems to be easiest to "push it off" from the inside.

According to the pin-numbering on the PCB layout, pin 1 is in the bottom right corner when viewing the HR-20E from the side (with the adjustment wheel on the right and the radiator on the left). Following standard numbering of the 2x5 connector, the pin directly above it (i.e. rightmost on the top) is pin 2. Note that this pin-numbering is opposite to the one described in the German documents. I looked at the PCB in order to determine what is pin 1, so I will use this numbering, and hopefully this notice will avoid any misunderstandings of the pin numbering. The connector pinout is as follows:

pindescription
1Do not connect
2Vcc target sense
3(JTAG TCK)
4(JTAG TMS)
5TXD (uninverted 3V level)
6(JTAG TDO)
7(JTAG TDI)
8RXD (uninverted 3V level - 120k pull-up)
9GND
10Vbat (3V)

The connections shown in bold in the above table are the ones we are interested in. If the MAX3232 is not powered by the HR-20E's batteries, the Vbat may not be needed.

Protocol details (v1)

It appears there are two different versions of the HR-20E firmware with considerably different protocols. Since the unit I have for testing has a V010200 firmware, this is all I have tested with so far.

The v1 firmware in the HR-20E uses an asynchronous serial transmission at 2400 baud for debugging. This is what we will be using to remotely control the device.

The serial communication parameters are 8-E-1 (that is, 8 bits, even parity and 1 stop bit). No flow control - neither software (xon/xoff) nor hardware (RTS/CTS or DTR/DSR). Also note that you need even parity. Normally parity is not used, but the HR-20E needs it, or only very few commands will get through.

The protocol is ASCII-based, and timing requirements are not very strict, so you should be able to test out the commands with your favorite terminal program (even the dreaded HyperTerminal could do in a pinch, i think). The commands are line-based (i.e. terminated with a <CR>). The commands are not case sensitive. No spaces or punctuation in the commands are accepted.

The serial communication of the HR-20E seems to go into sleep-mode when no command has been received for some time (around 30 s). It may therefore be necessary to wake up the communication by first sending an empty command (i.e. a single <CR%gt) until the V02 reply is received.

Protocol v1

The v1 protocol (i.e. firmware version V01xxxx) is described here.

When sending a command, the reply will always start with a letter identifying the reply, optionally followed by additional data. If an error occurs, the reply starts with E. The following are the error codes known so far:

errortextdescription
E02Missing ValueThis command needs a parameter.
E04Not ImplementedCommand not correctly parsed 1).
E05Value out of Range
E08A/D-Error
E09Time-Out
NOTES:1) May be due to incorrect parity setting.

The HR-20E seems to be responding to the following commands:

commandexample replydescription
<CR>V02Empty command. Used for synchronization/wake-up.
K<CR>V02Empty command.1)
Raaa<CR>M0069664Read memory. aaa is an address in HEX. Reply is Maaadddd, where aaa is the address, dddd is the 16-bit data (in HEX).
T<CR>V010200:Tue 15.07.1997 15:11Firmware version and date.1)
U<CR>U 04.06.07 12:59:54Return current date and time.1) 2)
V<CR>V010200:HR20-PI, R1.3.0Firmware version.1)
Waaadddd<CR>M0069664Write memory at location aaa (3 HEX digits) with value dddd (4 HEX digits). Reply is Maaadddd, where aaa is the address, dddd is the data.
NOTES:1) Parameters seems to be ignored.
2) First letter in reply is the same case as command sent.

Memory map

It seems the memory map seems to be arranged as follows:

addressdescription
000-07fEEPROM memory
080-0ffEEPROM memory repeated. Seems the 8th address line is not used.
100-1ffuController memory
200-211uController registers (I/O)

Known memory locations:

addressR/Wdescription
005R/WDisplay Bar and daylight-saving (EEPROM). Always update location 005 and 138 with the same values.
006R/WSelected high and low temperature settings. hhll. Each of the temperatures are encoded in the following format:
0fOff
148.0°C
198.5°C
1e9.0°C
......
dc28.0°C
e1On
009-00bR/WLast time and date set. Used after power failure. Format:
009mm00 where mm is minutes (00-59) in hex (00-3b)
00addhh where dd is day in month (00-31) in hex (00-1f), hh is hour (00-23) in hex (00-17).
00byywm where yy is year (00-99) in hex (00-63), w is weekday (0=monday, 6=sunday), m is month (1-12) in hex (1-c).
00fR/Weess where ee is the end and ss is the start of the first heat period for monday. Each of the times are in the following format:
0fOff
0000:00
0100:10
0200:20
......
8f23:50
ffThis program unused
010R/WEnd and start times for the second heat period for monday.
011R/WEnd and start times for the first heat period for tuesday.
012R/WEnd and start times for the second heat period for tuesday.
013R/WEnd and start times for the first heat period for wednesday.
014R/WEnd and start times for the second heat period for wednesday.
015R/WEnd and start times for the first heat period for thursday.
016R/WEnd and start times for the second heat period for thursday.
017R/WEnd and start times for the first heat period for friday.
018R/WEnd and start times for the second heat period for friday.
019R/WEnd and start times for the first heat period for saturday.
01aR/WEnd and start times for the second heat period for saturday.
01bR/WEnd and start times for the first heat period for sunday.
01cR/WEnd and start times for the second heat period for sunday.
102RBCD encoded display data. 0tod, temperature tens (t), ones (o), decimal position (d).
110-112R/WCurrent time. Format:
110mmss where mm is minutes (00-59) in hex (00-3b), ss is seconds (00-59) in hex (00-3b).
111ddhh where dd is day in month (00-31) in hex (00-1f), hh is hour (00-23) in hex (00-17).
112yywm where yy is year (00-99) in hex (00-63), w is weekday (0=monday, 6=sunday), m is month (1-12) in hex (1-c).
12bR/WBinary xxxxxxxx:xxxaxxxx where a is auto (1) or manual (0).
NOTE: Display is not fully updated: Sun/moon not switched off when going to manual mode. Bar not turned on/off. In automatic mode they will be updated at the next switching time.
136R/W00tt where tt is the current set temperature. Format:
0fOff
148.0°C
198.5°C
1e9.0°C
......
dc28.0°C
e1On
Value can be updated to set temperature, but will be overwritten in automatic mode by timer at set times. In manual mode this setting will be unaltered unless changed by turning the temperature knob on the device.
137R/WFFww where ww is the time for the window-function (turns off heat when window is opened). Time vvx6min.:
00Off
016 min
0212 min
......
138R/WE0bs, where b determines what is displayed on the bar in the top part of the LCD:
0Bar not displayed
1On and Off times (default)
2On and Off times + current time (flashing)
3Temperature
4Valve-position
s Determines if daylight-saving is used (1=off, 3=on).
NOTE:When updating this memory location, also set location 005 to the same value.
NOTE:Display is not updated until switching between manual and auto mode.
206RUnsupported. Returns E09:Time-Out.
207-208RCurrent values from A/D-converter (room temperature). Format unknown.
209RUnsupported. Returns E08:A/D-Error. Display shows E 4.
20aRUnsupported. Returns E08:A/D-Error. Display shows E 4.
20bRUnsupported. Returns E08:A/D-Error. Display shows E 4.
20cRxxtt, where tt is current set temperature:
00Off
148.0°C
198.5°C
1e9.0°C
......
dc28.0°C
ffOn
NOTE: To set the temperature use memory location 136 instead.

Protocol details (v2)

The information in this section is based on different sources found on the 'Net. Since I do not have a v2 unit (yet), I have not been able to test any of the following. If I ever get one of these units I will try to reverse-engineer the protocol and describe it here. If possible I will have the micro controller detect the firmware version of the HR-20E and act accordingly.

The v2 firmware of the HR-20E uses an asynchronous serial transmission at 9600 baud for debugging.

The serial communication parameters are 8-N-1 (that is, 8 bits, no parity and 1 stop bit). No flow control - neither software (xon/xoff) nor hardware (RTS/CTS or DTR/DSR).

Protocol v2

The HR-20E seems to be responding to the following commands:

commandexample replydescription
D<CR>???
I<CR>Serial number
Raaa<CR>Read byte at address aaa
Txx<CR>???
V<CR>Version info
Waaadd<CR>Write one byte of data dd at address aaa

uController interface

In order to control the HR-20E over an RS-485 bus a microcontroller will be used to provide the interfacing. Currently the idea is to use an Atmel ATmega88 (could be changed to ATmega48 or ATmega168 if the control store requirements turn out to be smaller or larger). A software (bit-banging) UART will be implemented to support the communication with the HR-20E. Since this communication uses only 2400 baud, and the parity has to be calculated anyways, a software UART seems to be a good match for this job.

The RS-485 bus will be connected to the hardware UART of the uController using a MAX3082 half-duplex slew rate limited transciever. A protocol for controlling the units on the RS-485 bus will be developed.

Since the HR-20E serial communication uses 3V logic levels, while the RS-485 transciever must be supplied with 5V, some level conversion is needed. The uController will probably be supplied with 5V and level conversion done between the HR-20E and the micro.

Last updated: 2012.02.09