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.
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.
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:
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:
| pin | description |
|---|---|
| 1 | Do not connect |
| 2 | Vcc target sense |
| 3 | (JTAG TCK) |
| 4 | (JTAG TMS) |
| 5 | TXD (uninverted 3V level) |
| 6 | (JTAG TDO) |
| 7 | (JTAG TDI) |
| 8 | RXD (uninverted 3V level - 120k pull-up) |
| 9 | GND |
| 10 | Vbat (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.
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.
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:
| error | text | description |
|---|---|---|
| E02 | Missing Value | This command needs a parameter. |
| E04 | Not Implemented | Command not correctly parsed 1). |
| E05 | Value out of Range | |
| E08 | A/D-Error | |
| E09 | Time-Out |
| NOTES: | 1) May be due to incorrect parity setting. |
The HR-20E seems to be responding to the following commands:
| command | example reply | description |
|---|---|---|
| <CR> | V02 | Empty command. Used for synchronization/wake-up. |
| K<CR> | V02 | Empty command.1) |
| Raaa<CR> | M0069664 | Read 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:11 | Firmware version and date.1) |
| U<CR> | U 04.06.07 12:59:54 | Return current date and time.1) 2) |
| V<CR> | V010200:HR20-PI, R1.3.0 | Firmware version.1) |
| Waaadddd<CR> | M0069664 | Write 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. |
It seems the memory map seems to be arranged as follows:
| address | description |
|---|---|
| 000-07f | EEPROM memory |
| 080-0ff | EEPROM memory repeated. Seems the 8th address line is not used. |
| 100-1ff | uController memory |
| 200-211 | uController registers (I/O) |
Known memory locations:
| address | R/W | description | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 005 | R/W | Display Bar and daylight-saving (EEPROM). Always update location 005 and 138 with the same values. | ||||||||||||||
| 006 | R/W | Selected high and low temperature settings. hhll. Each of the temperatures
are encoded in the following format:
| ||||||||||||||
| 009-00b | R/W | Last time and date set. Used after power failure. Format:
| ||||||||||||||
| 00f | R/W | eess 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:
| ||||||||||||||
| 010 | R/W | End and start times for the second heat period for monday. | ||||||||||||||
| 011 | R/W | End and start times for the first heat period for tuesday. | ||||||||||||||
| 012 | R/W | End and start times for the second heat period for tuesday. | ||||||||||||||
| 013 | R/W | End and start times for the first heat period for wednesday. | ||||||||||||||
| 014 | R/W | End and start times for the second heat period for wednesday. | ||||||||||||||
| 015 | R/W | End and start times for the first heat period for thursday. | ||||||||||||||
| 016 | R/W | End and start times for the second heat period for thursday. | ||||||||||||||
| 017 | R/W | End and start times for the first heat period for friday. | ||||||||||||||
| 018 | R/W | End and start times for the second heat period for friday. | ||||||||||||||
| 019 | R/W | End and start times for the first heat period for saturday. | ||||||||||||||
| 01a | R/W | End and start times for the second heat period for saturday. | ||||||||||||||
| 01b | R/W | End and start times for the first heat period for sunday. | ||||||||||||||
| 01c | R/W | End and start times for the second heat period for sunday. | ||||||||||||||
| 102 | R | BCD encoded display data. 0tod, temperature tens (t), ones (o), decimal position (d). | ||||||||||||||
| 110-112 | R/W | Current time. Format:
| ||||||||||||||
| 12b | R/W | Binary 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. | ||||||||||||||
| 136 | R/W | 00tt where tt is the current set temperature. Format:
| ||||||||||||||
| 137 | R/W | FFww where ww is the time for the window-function (turns off heat
when window is opened). Time vvx6min.:
| ||||||||||||||
| 138 | R/W | E0bs, where b
determines what is displayed on the bar in the top part of the LCD:
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. | ||||||||||||||
| 206 | R | Unsupported. Returns E09:Time-Out. | ||||||||||||||
| 207-208 | R | Current values from A/D-converter (room temperature). Format unknown. | ||||||||||||||
| 209 | R | Unsupported. Returns E08:A/D-Error. Display shows E 4. | ||||||||||||||
| 20a | R | Unsupported. Returns E08:A/D-Error. Display shows E 4. | ||||||||||||||
| 20b | R | Unsupported. Returns E08:A/D-Error. Display shows E 4. | ||||||||||||||
| 20c | R | xxtt, where tt is current set temperature:
|
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).
The HR-20E seems to be responding to the following commands:
| command | example reply | description |
|---|---|---|
| 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 |
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.
Linux
Electronics
Nostalgia
Code
Projects
Spiff
Links