OpenHR20: Firmware for Honeywell Rondostat HR20E

"make" is "GNU make" And it is added to winavr (not only)
It using "Makefile" to compile project.

Hi all,

I'm new here and want to control my home using the HR20-style and a 
simple and modified Moduline 15, to turn on and off the central heating 
unit.

I've (almost) read the entire thread, but still have some questions:
1. Have anybody used the HR20-Style instead of the 'old' HR20?
2. Does anybody know if the RFM12B works and if it's the same soldering? 
(http://jeelabs.com/products/rfm12b)
3. Is there some step by step manual how to do the complete 
modification? It's pretty hard to find  all the steps in this thread... 
If not, I will try to make one and ask for your verification.

Thanks in advance!

BTW There are a lot of posts about the master board. I use a lot of 
these: http://jeelabs.com/products/jeenode (Quite cheap and easy to use)

Justin

jbodry:

Thanks for the quick reply!

1) I will order one and try and post my findings
2) Just SW wise I suppose?
3) I will work on this and post it back


By "Current SW is not Arduino compatible" you mean the Master side?
Because I have my own protocol for wireless transfer (For any type of 
device like lamps, switches, dimmers, temp sensors and so on), just have 
to change the slave source...

I ordered an AVR Programmer 
(http://www.ebay.nl/itm/ws/eBayISAPI.dll?ViewItem&item=170725446910&ssPageName=ADME:B:EOIBSA:NL:1123#ht_1730wt_1398), 
but that doesn't work?

Correction after checking the 'schaltplan':

2) Just SW wise I suppose?

should be

2) One less to solder ;-)

Justin: I use HR20 style home expert with jiris soft for about a year 
now. Electronics are 100% kompatible (I did not want to write "the same" 
because I never had the old hr20)

I also did a search for "AVR JTAG" on ebay, but I'm not sure if that's 
the right way to find the right programmer. Where to look for? Is this 
one also possible for example: 
http://www.ebay.nl/itm/USB-JTAG-adapter-Programmer-Debugger-for-AVR-atmega-/190531487895?pt=LH_DefaultDomain_0&hash=item2c5c8fc897#ht_4364wt_1398

Richard G. wrote:
> Justin: I use HR20 style home expert with jiris soft for about a year
> now. Electronics are 100% kompatible (I did not want to write "the same"
> because I never had the old hr20)

Thanks for your reply! I will also put this in the 'manual' ;-)

jdobry wrote:
> For JTAG programming (HR20 connector)  you need JTAG AVR tool. Cheapest
> is this
> 
http://www.ebay.com/itm/AVR-JTAG-AVR-USB-Emulator-Simulator-Wide-Operating-Voltage-Buffer-Chip-/160685211172?pt=LH_DefaultDomain_0&hash=item256995be24
> But it is clone of obsolete HW. This means, that support only "old
> school" AVRs. Ex: support mega169p used on HR20 but not almost same
> mega329 on HR25.

I've modified a similar cheap JTAG programmer to allow it to program the 
329 used by the HR25. Obviously I didn't buy a Dragon due to my 
community spirit and not my cheapness. ;)

I've taken AVRminiProg and hacked it to use the serial port. The changes 
are truly awful but get the job done. It allows JTAG programming the 
HR25s in the same way as HR20s. The original ebay programmer I've got 
had unprotected code, allowing that to be read and flashed back to 
restore its former abilities. More details at 
https://sites.google.com/site/slangey/misc/honeywell-hr25/jtag-usb-ice-mk1 
. It may be a different one from the on Jiri posted, but likely similar 
at HW layer at least.

Bruce

PS I was surprised the stick code was unprotected. I gave up trying to 
disassemble and change the code for the 329... perhaps others have more 
strength and/or better disassemblers.

Hi everybody,

I accidentally destroyed the temperature sensor on my HR20, can anybody 
on this list help me get the data for the sensor, so I can get a 
replacement?

Thanks in advance.

HI Stan,

Thanks. Based on the document I found the following:

The Analysis.pdf documents the sensor to be an NTC thermistor, and lists 
a lot of measurements at various temperatures.

From this I got the following:
25 degr.C = 397 counts, probably measured with a 10 bit ADC.
Supply to AVR: 3.3V
Thus, 397 counts equals 1.279 volt.

From the schematic and tracing the images of the board, I found:
The R3 SMD Resistor is marked 43C, suggests it's 27k4, 0.5%

Calculation: (See this as a simple schematic, top to button)
3.3V
27k4 = 2.021V = 73.74uA
1.279V
NTC = NTC Nom. calculated to 17k34
0V

Closest match to the calculated NTC value seems to be Vashay/dale 
01M1752SPC3 or 01C1752SPC3, both have 17k5 as nominel value.

However, both are not easily available, and costs as much as a new HR20 
or HR25. :-(

Jiri: If I want to increase p part, In which situation should I use p or 
p3

Hi Stan,

Yes, almost that price (20 EUR without shipping).
But looking around I did find some cheaper alternatives, such as at 
Mauser, where the price goes down to only about US$ 5 (without 
shipping)... but the ETA lead time is at least 7 weeks.

I'm considering if it won't be quicker to use a more readily available 
(and cheaper) NTC and simply rewrite the conversion table. Well... time 
will tell...

Hi Bernard,

reading the device signature does definitely work without setting a fuse 
first. Surely JTAG is enabled in stock HR20.

Does anybody has any experience using AVR Studio 5? Version 4 can't be 
installed in Windows 7....

I would love to use a linux version (avr dude), but to make sure the 
fuses are right, I would like to set this in Windows first. (using the 
screen captures)

I found most settings in AVR Studio 5 to set the fuses and lock bits, 
but not the Advanced and Board settings. Maybe these are only available 
when the board is connected?

One other question:
Should the cable be connected like picture 904 or like 847?

Thanks!

Justin M. wrote:
> Does anybody has any experience using AVR Studio 5? Version 4 can't be
> installed in Windows 7....

Hmm, I have AVR Studio 4.18 installed on Win7 32 bit, and I use an AVR 
Dragon for JTAG.

Has anyone already ported or have hints for porting the master code to a 
Nanode RF? (arduino (328p) + ethernet + RFM12b)

Marco G. wrote:
> Justin M. wrote:
>> Does anybody has any experience using AVR Studio 5? Version 4 can't be
>> installed in Windows 7....
>
> Hmm, I have AVR Studio 4.18 installed on Win7 32 bit, and I use an AVR
> Dragon for JTAG.

I've got it installed also. (Win7 64 bit)
You'll have to wait for ages, but it will finish in the end...

Hi,

three days ago I flashed the last 3 HR20 with HW window detection, now 
all 6 valves use a reed contact. That works great :)

But 2 valves (Kinderzimmer + Schlafzimmer) now have problems to 
reach the wanted temp, see the attached pictures. Is that the same 
effect Richard has seen?
Wohnzimmer for example is working, even I flashed it the same day with 
same software and EEPROM.

Both failing valves have fresh batteries, and I tried to remount them 
several times. To which position do I have to turn the blue part before 
mounting? Near 0% or near 100%?

This is my setup:

1

#define MENU_SHOW_BATTERY 0

2

#define MOTOR_COMPENSATE_BATTERY 0

3

#define NO_AUTORETURN_FROM_ALT_MENUES 0

4

#define MENUES_AUTOBROWSE 1

5

#define CALIBRATION_RESETS_sumError 0

6

#endif

7

#define BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE 0

8

#define BOOST_CONTROLER_AFTER_CHANGE 0

9

10

#define CONFIG_ENABLE_D 0

"If temperature is far away from wanted temperatur"
It is exactly why we have "P3" regulator. In other words if we have 
difference 1 degree = 100 in 0.01 units.

impact = P*100 + P3*100*100*100 = P*100 + P3*1000000

P3 impact can be stopped by valve limitation very easily.

After rising the I_Part to 0x50 (might not need to be so high) it is 
fine :)

Can anyone confirm this wiring? (Well, drawing in the first place :-) ) 
(NC == NOT CONNECTED I guess)
Thanks!

Jiri Dobry wrote:
> "If temperature is far away from wanted temperatur"
> It is exactly why we have "P3" regulator. In other words if we have
> difference 1 degree = 100 in 0.01 units.
>
> impact = P*100 + P3*100*100*100 = P*100 + P3*1000000
>
> P3 impact can be stopped by valve limitation very easily.

Sorry still do not catch it - If I want to increase p part, In which 
situation should I use p or p3

P and P3 are used always. Difference is in dependency to error value 
(difference between wanted and real temp). P is linear, P3 is cubic.

hi at all,

i'm developing my own firmware for the HR20 and i have some questions 
about to save power.

my HR20 is currently running in POWERSAVE mode and it needs 330uA 
current. In POWERDOWN mode it will need 110uA but with LCD not working, 
it will work in POWERSAVE mode.

in which mode are you running the HR20? and do you have some ideas for 
me for to save more power?

thank you very much

Jan

but with idle or sleep, the lcd dosn't work, damn.
but thank you for the tip to disable the pullups, and i made every 
unused input to an output, now i have a consumption of 283uA.

did you have measured yours HR20 current consumption?
and how do you initialize the lcd controller, like in the analysis of 
the HR20 document?

what interrupt do you use, to wake up the mega169. timer2?


PS: i write my own fw, because i have an existing system here in my 
house that consists of temp.sensors and an main-heater-ecu, which are 
using the rfm12 to communicate, and now i want to integrate the HR20 
into this system.

but the problem is, i programm in bascom and i have no knowledge in 
programming in C.

and i've tested all powermodes, my min. consumption is 280uA. i use the 
timer2 overflow too for waking up the processor. but in powerdown mode, 
the timer is disabled, and for that, the processor didn't wake up from 
sleepmode.

you have 30...40uA in powersave/idle mode???

Jan

good morning jdobry,

i have tested some different lcd-init.parameters, and i can decrease the 
consumption to 217uA, but it's still too much.

please, can you tell me which hardwaremodules you switch off? especialy 
the 3
V3-Pin (pine.6 from mega169). when i set this to logiclevel 0, the 
current is more than 18mA, only when i set it to logiclevel 1, there is 
minimum current.

i think, that the hardware arround the atmega causes the current 
problem. i have an other board, with attiny84 und rfm12, and this board 
current consumption is 5,6uA in sleep.

thank you,

Jan

So, i solved the problem. now i have a current consumtption of 36uA with 
lcd.

Jan

Hi Ronny,

yes it is my own extension, and yes, I wanted to browse through the 
temperatures and valve position automatically.
But no, it does not work :(

This is what I changed in menu.c, maybe you can check and correct it:

1

#if NO_AUTORETURN_FROM_ALT_MENUES 

2

            && ! (((menu_state>=menu_home2) && (menu_state<=menu_home5)) || menu_state==menu_service_watch)

3

#elif MENUES_AUTOBROWSE

4

            && 1)    // (config.menues_autobrowse))

5

            {

6

                if ((menu_state>=menu_home_no_alter) && (menu_state<=menu_home3))

7

                    menu_state++;

8

                if (menu_state==menu_home4)

9

                    menu_state=menu_home; // return to main home screen

10

                ret=true;

11

#else

12

            ) {

13

                menu_state=menu_home; // return to main home screen

14

                ret=true;

15

#endif

Jiri: If I use Rev364 I get this error:

1

avr-gcc -mmcu=atmega169p -I. -gdwarf-2 -DF_CPU=4000000UL            -Os -mcall-prologues -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=obj/motor.o  -std=gnu99 -ffreestanding  -Wl,--relax  -fdata-sect

2

ions -MMD -MP -MF .dep/hr20.elf.d obj/motor.o obj/controller.o obj/rs232_485_hw.o obj/watch.o obj/com.o obj/wireless.o obj/rfm.o obj/cmac.o obj/xtea-asm.o obj/rtc.o obj/main.o obj/keyboard.o obj/adc.o obj/eeprom.o obj/menu.o obj/lcd.o --output hr20.elf -Wl

3

,-Map=hr20.map,--cref     -lm

4

5

c:/programme/winavr20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/crtm169p.o: In function `__vector_default':

6

(.vectors+0x38): relocation truncated to fit: R_AVR_13_PCREL against symbol `__vector_14' defined in .text section in obj/rs232_485_hw.o

7

make: *** [hr20.elf] Error 1

8

Build failed with 1 errors and 11 warnings...

when I use the old(R363) "rs232_485_hw.c, rs232_485.h" no error

Basti wrote:

> PS: there is still someone who works on this project? or at least it
> used?

I am using it on 6 HR20, 5 of them with HW window detection (magnet 
contact at the window). Master HW is attached to a FritzBox 7270v3 and 
running fine, since AVM has updated the USB stack in FritzBox firmware 
05.xx.

Btw, I found out that even if the HW window detection says that the 
window is open, the heating starts again after about 30-60 minutes. Is 
that timeout intended?

sure I do use 4 HR20 with R364 and having some trouble with make/compile 
of R364 ... see some posts above. I wrote theese extensions:
TEMP_COMPENSATE_OPTION BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE 
BOOST_CONTROLER_AFTER_CHANGE

Usally I have those Options set:
HW_WINDOW_DETECTION=-DHW_WINDOW_DETECTION=0
RFM=-DRFM=0
NO_AUTORETURN_FROM_ALT_MENUES=-DNO_AUTORETURN_FROM_ALT_MENUES=1
TEMP_COMPENSATE_OPTION=-DTEMP_COMPENSATE_OPTION=1
BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE=-DBLOCK_INTEGRATOR_AFTER_VALVE_CHANG 
E=1
BOOST_CONTROLER_AFTER_CHANGE=-DBOOST_CONTROLER_AFTER_CHANGE=1

If I run MakeAll without any of theese Options mentioned above (e.g. 
with R364 makefile) this happens:

1

avr-gcc -mmcu=atmega169p -I. -gdwarf-2 -DF_CPU=4000000UL

2

-Os -mcall-prologues -funsigned-char -funsigned-bitfields

3

-fpack-struct -fshort-enums -Wall -Wstrict-prototypes

4

-Wa,-adhlns=obj/motor.o  -std=gnu99 -ffreestanding  -Wl,--relax

5

-fdata-sect

6

ions -MMD -MP -MF .dep/hr20.elf.d obj/motor.o obj/controller.o

7

obj/rs232_485_hw.o obj/watch.o obj/com.o obj/wireless.o obj/rfm.o

8

obj/cmac.o obj/xtea-asm.o obj/rtc.o obj/main.o obj/keyboard.o

9

obj/adc.o obj/eeprom.o obj/menu.o obj/lcd.o --output hr20.elf -Wl

10

,-Map=hr20.map,--cref     -lm

11

12

c:/programme/winavr20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/crtm169p.o:

13

In function `__vector_default':

14

(.vectors+0x38): relocation truncated to fit: R_AVR_13_PCREL against

15

symbol `__vector_14' defined in .text section in obj/rs232_485_hw.o

16

make: *** [hr20.elf] Error 1

17

Build failed with 1 errors and 0 warnings...

But as I said, when I use the old rs232 routines (from common)
everything compiles fine.

It may also be a linker/compiler prob. Because if I set controller.c 
line 185 as a coment:
//                      CTL_temp_wanted_last=temp;
everything works fine too ...

Marco G. wrote:

> Btw, I found out that even if the HW window detection says that the
> window is open, the heating starts again after about 30-60 minutes. Is
> that timeout intended?

That's the screenshot.

@Jiri:
Good point, I didn't see that.
But the frost protection exits the window open mode, and even if the 
window is still open, the heating tries to reach the wanted temperature 
and wastes the energy.

If the temperature here drops again (at the moment it's +5°C), I will 
try to add a timeout (30 minutes?) for the  window open mode, until 
that timeout the frost protection is disabled.

Hello,

I use this project too . In my configuration there are 3 HR20 and the 
Master based on the PCB from Marco (stan) . I have added an Humidity 
Sensor and a barometric pressure sensor to my master.
I have played a littlebit whit the onewire extensions and i think it is 
a good idea. But it is not the the right place in the communication 
routine because the conversion take a really long time(max 750ms). And 
this will break the timing for the communication whit the HR20 from time 
to time and this will lead to an higher current consumption because they 
must retransmit the corrupted message. A better approach is to use an 
own thread in the scheduler and a interrupt driven communication with 
the onewire devices. The communication part should only en-queue the 
order. Maybe it is not necessary to use an interrupt driven 
communication.But at the conversion it should not block the execution.

greetings,

Ronny

@basti/jiri: Who is going to make revision 365 ?

I would like to send my changes regarding the options (written by me) 
and controller.c
TEMP_COMPENSATE_OPTION
BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE
BOOST_CONTROLER_AFTER_CHANGE

OK. I didnt look into SVN before posting ... can I send the changes to 
you then (mailadr.?) ?

BTW: I jus tried 366 - moving the rs232 routines fixed my building issue 
;-)

@basti: Maybe I did not communicate very well ...
I have improoved the code from the options mentioned above and need 
somebody to check them into SVN ... pls send me your mailadr via PN ...

@Jiri: Would you please add me to the members list of the project, so I 
can add my changes ..

I've got a master up and running on both a mega16/32 10MHz (random ebay) 
and a Nanode RFX/Wi-Node 16MHz (www.nanode.biz). Both use the RFM12B, 
but I can't get it to run at 19200 baud reliably, even side by side. It 
only seems to work properly at 9600 baud. Has anyone else experienced 
this, i.e. is this a known difference with the RFM12B?

Hi,

I'm new to the Rondostat HR 20 and I just took my first one apart today. 
The chip is the ATMEL MEGA 169PV. I hope this isn't off topic.
My question is this: When the timer calls for the Rondostat to be turned 
ON, which pin on the ATMEL goes high? My idea is to disconnect this pin 
and supply externally my own timer voltage so I can turn the Rondostat 
on independently of the Rondostat timer. Is this feasible and if so do I 
tie the pin high or low with a resistor or just leave it floating?

Thank you in advance if you can help.

Regards

Dermot

I've just got hold of the schematic and can now see that it appears that 
pins 18 and 19 control the motor through a H bridge. The output from the 
timer is internal and I won't be able to isolate it.

Just one final question: Does anybody know what type of 
Reflexlichtschranke (Optical transistor switch?)is used?

Regards

Dermot

Dermot,

why would you add something externally? You can change the firmware 
yourself and adapt it to your needs :)

Hello Dermont,

Like Marco say there is no need to control the Valve directly. The HR20 
is more than a stupid Valve. It is a PID-controller. If you really need 
only a dumb Valve , there are so cheaper device on the Market. A better 
approach will be to control the device via a pin on the side programming 
connector. This will need a little bit work on the firmware but much 
lesser than your approach required.

Maybe some of this valve are an solution for you : 
http://www.merten.de/download/DL_doku/639124_Stellantrieb_24_V_D.pdf

Ronny

Thanks for the comments Marco and Ronny.

I appreciate what you say about adapting the firmware but I'm afraid the 
learning curve for me would be far too steep. I have no background in 
electronics or programming. I have a little experience with PICAXE 
projects and PIC Basic.

I looked at the simple valves but they are all mains AC operated and 
much more expensive than the Rondostat, which I like because of the 3V 
battery supply.

What I intend to do is to disable the Amtel chip by cutting the 
connection to pin 21 and just use the H bridge, to actuate the motor, 
and the opto reflector (IC2)on the PCB and connect them externally to a 
PICAXE chip.

Do either of you know why IC2 is connected to 3 pins on the Atmel chip 
and what are the resistors R12, R13 and R14 for? I would have thought 
that just one output from IC2 was necessary to connect to an ADC pin. I 
don't know exactly what the spec of IC2 is, does anybody know what it 
is? My understanding of these opto reflectors is that when they are 
positioned near a black surface they output say 3v and when positioned 
near a reflective surface they output a much lesser voltage (or is it 
the other way around?). All you have to do then is feed this output to 
the ADC of a suitable PIC and you can control how your motor stops and 
starts.

Once I have that accomplished I will attach an electronic timer, taken 
from an electric socket timer, to my PICAXE and I will then be able to 
control the Rondostat as precisely as I want.

Thanks again for you comments.

Regards

Dermot

Hello Dermont,

Maybe another aproach for you is to use the serial Interface of the 
HR20. You can use your PICACE to send commands to the valve. For example 
you can use it to set manualy at high or a low temperatur so the valve 
will open and close.
But you should beware of problems with the powerconsumption. Bad 
Software will leak many energy and your batterys are realy fast empty. 
Designing software which realy saves energy is not a simple thing.

Regards,

Ronny

Thanks for the advice Ronny.

By the way I think I've found the spec for IC2. It seems to be a 
Kingbright Sub-miniature photoreflective sensor. See spec at 
http://www.kingbright.com/manager/upload/pdf/KTIR0811S%28Ver.11%29.pdf

Regards

Dermot

hi,

i successfully flashed a hr-20 with the software from the svn.

now i connected my pc through serial port, using hterm.
if i put in the batteries i only see rubish.

i tried to send commands like ?BATT and CR, but no response.


my serial port is a usb cable, i have lowered tx voltage through two 
resistors. rx is directly connected.

9600baud, 1 stop bit, no parity.

any hints? thx!

Hello,

what kind of data did you see. I am not sure, but i think the protocol 
has changed to an other version since a while.
Which version did you compile (from rfmsource path)? The only occurrence 
of such am command i found is in a really old version in 
openhr20/branches/before_refactoring_1/source/ .

Maybe you see some data like this in the API-spec from the HR20 article 
on mikrocontroller.net ( 
http://www.mikrocontroller.net/articles/Heizungssteuerung_mit_Honeywell_HR20)

Regards

Ronny

i did the svn checkout. but i didn´t use the rfm source.
i receive some data after inserting the batteries, i can post the data 
in the evening.

i also tried some commands from the article ...

i downloaded the code from the website - it´s totally different to the 
stuff in the svn ...

so, i flashed the .elf from the original folder.

now after inserting the batteries there is a bunch of bytes received

170 177 125 053 035 111 091 155 159 191 115 053 059 191 155 159 157 157 
191 159 157 139 153 143 139 .....

display shows version 1.0 (last time it said 0.99)

any hints? baudrate 9600 stop1 no parity

is the voltage level to low for the rx?

I'm using the frontend/tools/*.php. On upgrading to ubuntu 12.04, the 
trick of using sqlite.so from an older ubuntu version stopped working. 
To use php5-sqlite, I've changed:

sed -i -e 's/fetch/fetchArray/g' *.php
sed -i -e 's/SQLiteDatabase/SQLite3/g' *.php

I converted over my old db with (and renamed etc.):
sqlite db.sqlite .dump | sqlite3 db.3.sqlite

It seems to work again. :)

Also, not that it makes much odds, I've also done this to daemon.php - 
hopefully this is correct?
       fwrite($fp,$date); fwrite($fp,$time);  // was other way around

i use a 5V serial port but i transformed the tx with two resistors. the 
rx is not amplified which is usually not a problem.

i receive data after switch on and after a minute or so, but it doesn´t 
send any replies if i send commands.

i´m still not sure which commands to send. maybe i plug in a rfm device 
...


i just need it to work for a demonstration :(

(anyone from munich here?)

Hello ,

Did you try to simply loopback TX to RX to see if your converter is 
really working.

Here is the Message that is send if you put in the batteries :
"V:OpenHR20rfm 1.1 Jan 27 2012 15:35:43" (similar).

@Jiri : Could a wrong FUSES Setting lead to this problem ? (Clock 
Prescaler)

>>Did you try to simply loopback TX to RX to see if your converter is
really working.

i tried that, but before the converter - i´ll try this in the evening, 
thanks!

fuses should be ok, first i set them manually, last try i used the .elf 
file. but i will also check the fuses later.

thx

Hi,

I'm using the latest version from SVN and had some problems with serial 
communication. It was absolutely unreliable so I took a look at the 
code. I found that the UART RX interrupt gets disabled after one 
received byte (rs232_485_hw.c) and gets re-enabled some time later 
(motor.c: RS_enable_rx()).
After uncommenting the deactivation of RXEN, my communication went fine.

My question: why gets the RX interrupt disabled? Battery-saving reasons, 
especially with unconnected UART pins?

Regards
Björn

Hi all,

I have aquired a number of Aldi Thermy thermostats, also know as / 
similar to Eurotronic Sparmatic Basic/Comet/Zero.
These have been discussed since 2010, the most current thread is 
Beitrag "Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"
Several people have started working on firmware for these devices, but 
only travelrec seems to have something usable so far, written in ASM.
For some reason, the connection to OpenHR20 has not really been made, 
despite all the interest shown.

Since I just today came across a note stating that there has in fact 
been support for the Basic for a couple of months, I was wondering if 
anyone could summarize what the project is featuring, as the wiki page 
is hopelessly outdated. I believe there is support for RFM12 radios, 
master thermostats, a base station and PHP code for a web server?

michal wrote:
>
> Also I have problem with programming master.hex with avrdude:
>
> avrdude: input file master.hex auto detected as Intel Hex
> avrdude: ERROR: address 0x820002 out of range at line 455 of master.hex
> avrdude: write to file 'master.hex' failed
>
> what is wrong? Valves programs OK.

avrdude doesn't support flash+fuse writing with one .hex file 
simultaneously.
So you have to disable folling lines in rfmsrc/master/main.c

// default fuses for ELF file

/*FUSES =
{
    .low = 0xA0,
    .high = 0x91,
};*/

You should write flash with hex file and eeprom with eep file in 
avrdude. Fuses should be set separate with avrdude.

fuse offsets
0x820000 LFUSE
0x820001 HFUSE
0x820002 EFUSE

correction:

hfuse      0x820000
lfuse      0x820001
efuse/fuse 0x820002
lock       0x820003

Hi,
I try to compile the RFM branch software and got stuck in the linker 
with the following problem:
Error  17      Program Memory Usage   :  15589 bytes   95,1 % Full
        Data Memory Usage     :  1088 bytes   106,3 % Full  (Memory 
Overflow)
        EEPROM Memory Usage   :  400 bytes   78,1 % Full  OpenHR20-RFM 
0  0  OpenHR20-RFM


How are you able to compile the software?
I took AtmelStudio 6 and added the source files from the SVN. In the 
compile and linker settings I have added the optimization settings like 
in the makefile.

What else will I have to configure to get my binary?

Alright I will try it with the WinAVR-20100110 IDE this afternoon. Is 
this described anywhere, which IDE has to be used?

What is the current usage of RAM/ROM when using the stated version?

Hi,
I am new to OpenHR20, but I really appreciate what you have done so far 
:-).
I have bought couple of HR25 (to get bigger flash :-) ) and now I would 
like to connect RFM12B to make them wireless. I can't use the HR20 
internal connection, as the PA3/COM3 pin is taken by the new LCD, so I 
am looking for alternatives.
I was thinking about using the external pinout, but I was wondering, 
will the JTAG interface be still usable with RFM12B connected? It looks 
like the RFM pins are tri-state when the chip-select is not active, am I 
right?

Thanks for the quick response. I understand I can use JTAG pins (when 
JTAG is disabled) for RFM communication. My question was if it is 
possible to use JTAG also for debugging (firmware flashing, development 
and testing) with RFM connected (without debugging RFM communication of 
course).
The CS signal then would have to be on PE2 instead of TMS. But if it is 
active without clock, then this won't work, right?
I really don't want to loose JTAG by soldering RFM (at least not yet), 
so I would probably have to go for the internal wiring with PA3/COM3 
replaced by PE2...

OK, thank you for your help. So this does not look like a good solution.

Another idea :-).
CS (nSEL) of RFM12 connected internally to PF0 with added external 
pull-up to 3.3V. During reset state, PF0 should be tri-state, so with 
the pull-up, RFM should be inactive. Only with PF0 asserted low, RFM is 
listening.
Then SDI of RFM can be connected to TDI/PF7. SDO can stay on PE6 with 
interrupt capability.
This way, JTAG should be fully working (except when PF0 is low), and RFM 
too (without JTAG).

Does this make sense? :-)

Yes, I was thinking about that too, maybe lifting the MCU pins from the 
board? But I don't think I am able to do that, too risky. These too pins 
are such a waste, damned Honeywell ;-).

Lifting MCU pins is impossible. It use "QFN package" :-(

Hi,

I've just picked up 3 Honeywell Rondostat HR-20 thermostats which I 
would like to put OpenHR20 on it. And I've read to most of this thread 
and used Google Translate to read the wiki page about OpenHR20.

Since I'm not an electronics expert I'm a bit stuck with how to flash 
the HR20.

As soon as I get the basics under the belt I'm going to try and adapt 
the HR20 to connect to my PLC installation that controls the lightning 
etc.

Can someone help me out so I can get started? What hardware do I need? 
What software do I need? Which pre-compiled file can I use to flash a 
stock HR20?

I'm on Mac, Windows or Linux (although prefer either Mac or Linux). I 
have some basic electronics equipment (FDTI breakout board / Bus Pirate 
v3) I used for Arduino tinkering.

Am I correct to assume that I can use the Bus Pirate with avrdude to 
flash the HR20?

Kind regards,
Niels R.

Niels R. wrote:
> Am I correct to assume that I can use the Bus Pirate with avrdude to
> flash the HR20?

Basically you need a JTAG cable, avrdude, and a firmware. I haven't used 
bus pirate personally, but it claims JTAG support, so you should be fine 
as long as avrdude can talk to it.
Regarding firmware, look at sourceforge 
(http://sourceforge.net/projects/openhr20/), there is a pre-compiled 
download available.

For the RFM addon modification, how did you manage to solder the wires 
diectly to the pins of µC?
I just started soldering the first wire to pin PA3 and it instantly 
broke. So the first device that won't be used anymore for this.

Ok I managed to solder the wires using the second option with the JTAG 
pins. But now I got problems with the display. After the reset all 
segments light up for a short time, but when the normal text comes to 
display some segments are not correctly driven, the text is nearly 
unreadable.
Are there any problems known which lead to incomplete display content?

Currently I am using the latest SVN release of the HR20_rfm_ext_sww.

> Solder wires to MCU is not easy. You need profesional skill, flux and
> iron.

You can also try my internal wiring 
(http://embdev.net/topic/118781#1590044). It's without a MCU pin 
connection. Makefile settings is "HR20_rfm_ext_sww".

Marko B. wrote:
>> Solder wires to MCU is not easy. You need profesional skill, flux and
>> iron.
>
> You can also try my internal wiring
> (http://embdev.net/topic/118781#1590044). It's without a MCU pin
> connection. Makefile settings is "HR20_rfm_ext_sww".

Thanks I already found the alternative wiring in the code and then 
figured out that this is the external wiring firmware.

It seems to work fine now, also the display is working now without any 
missing segments. Is there any way to figure out if the RFM wiring 
works? Maybe request some RFM status via UART?

My master is not yet ready to go, so I have nothing to check the 
hardware...

I've attached a patch to flip the LCD display upside down. This is 
useful for UK style radiators with vertical HR20/25s. It allows 
(statically just now) choosing between the two. To enable "#define 
LCD_UPSIDE_DOWN 1" (in config.h for example). Enabled it uses an extra 6 
bytes of code space. Disabled, no difference in size.

To make it easy to do this, I've changed around the character mapping so 
reversing the bits results in a rotation. Also, it changes the wheel 
direction to work as I'd expect.

If you want the patch in another form, please let me know. Also, I have 
other changes waiting to be cleaned up/tested/reviewed (to allow the 
master to run on a arduino with RFM12, etc.). Should I create a git repo 
that the changes could be picked up from?

Hi!

With the original firmware my HR20E sometimes manages to open the valve 
beyond the mechanical limit. Turning it back again doesn't work, so the 
radiator keeps on heating like hell.
I poked around in motor.c of the OpenHR20 a bit and this is what I came 
up with: https://gist.github.com/4184988
I know it's ugly, but I'm currently trying this on a single radiator. 
Seems to work so far. I verified the maximum position by setting the 
desired temperature to On and removing the HR20E once the motor stopped 
turning.
Do you see any problems with my approach or are there suggestions for a 
better method?

Hi,
I got some problems with the RFM software. I have connected a RFM12 
module to the HR20 using the external wiring. For the HR20 software 
everything seems to work fine, there is no error in display.
But the master is probably not receiving anything from the HR20. I can 
not control, update or read status from the HR20. I used the standard 
address that is hardcoded in the software from SVN.

I did the same with a second device and it works like a charme. 
Shouldn't the device view the E4 error if there is no sync with the 
master?

Hi,
First thing of all -- thank you for this project, this is really great 
work!

Still, I have many questions... I have a little bit of experience with 
arduino, but i'm not a pro electronic engeenier... For OpenHr20 part of 
the documentation is in this forum, part in the svn, aprt is in english, 
but part is in german. Is there any step-by-step tutorial showing how to 
flash HR20, how to add RFM12 and connect it together?

As far as i understand the following steps are necessary to run openhr20 
firmware and connect thermostats wirelessly using RFM12:
1) flash the selected firmware "mode" (in this case rfm_ext_sww?) using 
a JTAG programmer into the atmega in HR20. Is it ok to use the binaries 
provided for download on sourceforge or should I compile it by myself?
2) Add RFM12 using external wiring (the easiest method) or mixed-wiring 
from http://embdev.net/topic/118781#1590044 (I want to put RFM12 inside 
HR20, but which firmware mode should I use in this case)?
3) Build a master board: basicly, an atmega, which reads data from 
RFM12, puts it on serial port, which is converted to usb.

And it should work, right? But the following questions emerge and (I 
admit - i didn't read carefully the whole forum thread, but it is really 
long now...) I didn't find answers to them:
1) Is it necesseray to use HR20E or is HR20 sufficient? What's the 
difference between these two versions?
2) The info in svn in rfmsrc/doc/external_RFM12/README.txt says "DO NOT 
USE IT WITH CURRENT SOFTWARE". So which version should I use?
3) What's about keys and addresses used for wireless communication? Do I 
have to setup them in the code, or can I set up them after falsh? If so 
- how? I only found info that "editing an EEPROM is possible" - not 
really useful unless you exectly know what is stored in that EEPROM?
4) Is there any 'user guide' for HR20 using OPenHR20 firmware? What was 
changed in comparison to the original firmware and how to set that 
options?
5) I know, that after falshing rfm_ext version I can no longer use JTAG 
connector for debugging (and that's OK)? But will serial communication 
work? And will HR20 with rfm_ext work without master node, only based on 
settings set using buttons and encoder or serial port?

I know that's a lot of questions, but answering them you'll probably 
help many less adavanced users :) Or maybe even someone starts to write 
"Setup Howto" :) ?

Best regards and thanks once again fro your work.

Hi Star Keeper,

I assume you have flashed the correct firmware.
The E4 error is displayed a few minutes after power on, when no 
sync-frame was send by master.

How do you interact with the master?

I've started to put some of my code changes on github 
(https://github.com/bruce33/openhr20/)
It contains all the subversion history, which is nice for browsing. I'll 
continue to update this repository.

All fairly minor changes. They include support for masters based on 
atmega32 and 328p (arduino style boards) e.g. the Nanode and WiNode, 
updates for building/running on more modern linux based systems and 
rudimentary individual RFM12 frequency tuning. See commits for full log.

@Jens Tode
I already solved the problem. It was simply a problem while flashing. 
The fuse for preventing EEPROM write was set and the address that was 
programmed in the EEPROM was the same like another device I have in use.

After restting the fuse, the address in EEPROM was changed and the 
communication is working now!



I currently implement my own stand-alone master using a STM32 with 
cortex-m3. I have running a lwIp with udp server and webserver. The plan 
is to write a android app soon, to replace the webserver interface. But 
that's future..

Currently I got stuck while porting the AVR assembler code in the 
crypto_init function. Can somebody say what the assembler code there 
does? Is an equal C-code available?

@Star Keeper

Sounds good.

I am actually working on a similar project, but I use a LPC1768.

For the assembler part of crypto_init you can try the attached code.
I tried my best to translate it into c and tested it in MSVS6, should 
work.

I also attached a screenshot of my app I am working on.

Best regards,
Jens

Edit:
In the attached c-file the include should obviously be in the first row 
;)

Thank you very much!
When you say "should work" means that you can use this code wih the 
normal RFM-code on the valves or is this theretically tested in MSVC 
only?

Well I will figure this out but it is always better to know what to 
expect ;-)

Seems that your project is more advanced than mine. But christmas 
vacation is on it'S way..

@Star Keeper

I debugged the crypto_init and used those values to verify my c-code.
Including the code into my LPC-Project will be done during christmas
vacation.

Hi Olivier,

Programmer:
since the HR20 uses two batteries you have to ensure, that your 
JTAG-Programmer works at 3V.
Have a look at ebay, there you will find several programmers which could 
be jumpered for 3V or 5V operation.
Same price like in your link.

If mega169 is listed, what usually should be, you can take that 
programmer.
The "PV" just marks specific versions (voltage range, newer version of 
chip, etc.). For the programmer it should make no differences.

Software:
Take newest version from svn.

Serial connection:
To connect it to your pc you have to use a rs232 transceiver or a 
ttl-usb converter.
Take a look into com.c to see which commands are supported.

Best regards,
Jens

Hi @all,

first of all many thanks to Jiri and all the others working on this 
project!

I had a little problem with "software-based" open window detection.
The program stucks in routine CTL_window_detection in controller.c.

Debugging the code showed me, that ring_buf_temp_avgs_pos was 240.

After initializing ring_buf_temp_avgs_pos with zero in adc.h it know 
seems to work.

I use WinAVR-20100110.

Best regards,
Jens

I can compile the rfmsrc tree from above mentioned git directly or with 
some 'const' additions from svn sources. I use the latest Crosspack AVR 
(CrossPack-AVR-20121207) on OSX. But when I program it to the thermostat 
it does not run. Some numbers will show on the display and I can press 
some buttons, but nothing really useful.

If I use the prebuilt binaries from source forge they seem to work.  No 
real live testing yet though.

Are the binaries built from the latest revision or is it my setup? Still 
trying to figure out how to get debugging working.

I'm quite new to microcontroller programming. Can I use the AVR Dragon 
programmer as a USB to serial connection too? Or should I use something 
like a bus pirate?

My plan is to connect an electric imp through SPI and create an iPhone 
app for remote controlling the thermostat.

MISO and MOSI shows, that You like to use an ISP-programmer on a 
JTAG-port (TDI, TDO). If Your programmer can not be switched to JTAG, 
You can't use it for programming the HR20.

Hi Olivier,

as Helge already wrote: it is NOT possible to "map" isp to jtag.

If money doesn't matter get yourself a genuine JTAG-programmer from 
Atmel.
These should support 3V operation.

And if you like to solder check out evertool:
http://www.siwawi.arubi.uni-kl.de/avr_projects/evertool/index.html

I build it up a couple of years ago and still use and love it.

Here are some others:
http://www.mikrocontroller.net/articles/JTAG#Hardware

And here is one on eBay:
http://www.ebay.de/itm/270835653356

But i have no idea how reliable these cheap eBay programmers are!

Jens

Hi Olivier,

just to add to what has been already said - if you really want to use 
ISP programmer, there should be a way, as all three (MOSI, MISO, SCK) 
signals are connected to control buttons. So if you don't mind opening 
the case and connecting (maybe soldering) directly to the board, it 
should work if you connect to these three signals, plus of course GND, 
reset, maybe Vcc. Please note that I have not tried this approach myself 
:-).

Hi @all,

as you can read above, I try to implement a master on a lpc1768.
En- and decoding works, sending sync also works, but i am stuck in 
sending regular packages like mode changes etc.

When do i have to send a package?

If i understand code for master correctly it must be right after 
receiving a package from HR20.

Is that right, or do I have to wait for next interval?

How do I have to understand the package counter?
With the actual code it is possible that HR20 increments it, even if 
package was not for him.
(From a radio wall socket for example).

Best regards,
Jens

@steved: It looks nice. Do you have a plan to make this project public? 
If yes, send me your sourceforge account name and I will grant access to 
repositories for you.
Do you still use Makefile or you are using AtmelStudio6 IDE? I would 
like ask because current Makefile contain some tricks to make code 
smaller and I cant imagine how to do it on AS6 IDE. Except this it is 
not multiplatform and can't be (based on MSVS).

Jens Tode wrote:
> I had a little problem with "software-based" open window detection.
> The program stucks in routine CTL_window_detection in controller.c.
> Debugging the code showed me, that ring_buf_temp_avgs_pos was 240.
> After initializing ring_buf_temp_avgs_pos with zero in adc.h it know
> seems to work.

@Jiri ... shouldnt this got to svn (and isnt it adc.c that has to be 
changed) ??

Another problem that I encoutnered was wih the RFM implementation. Every 
minute the device sends the own status. The package that is used to send 
the data is not initialized every time it is sent. That leads to 
situations in which the data holds not the correct values. Also the data 
counter for this package is not initialized each time, which results in 
an increasing package size until the buffer limit ist reached.

I think I could provide some diff this evening, when I have access to my 
code.


Another point that I have seen is the automatic valve protection. It 
seems that every saturday at 10 o'clock the valve opens completely and 
then closes to normal state. First of all I don't think that it is 
neccessary to do this every week and then I would prefer to do this 
while a normal heating phase and not all the time even if the frost 
protection phase is active.

Star Keeper:
Status data is NOT send every minute. It is send after change on 
reserved second time slot.

Weird, my master receives ever minute data from each client. As far as I 
was able to debug this the client sends the data from the function 
"wirelessTimer" in wireless.c. There the case WL_TIMER_FIRST is entered.


Another thing that got my attention was line 357 in wireless.c there ist 
a if clause with following brackets but they have no effect because 
there is statement directly after the if-clause:

1

            if (rfm_framepos>(rfm_framebuf[0]&0x7f)) rfm_framepos=(rfm_framebuf[0]&0x7f);

2

3

            {

4

                bool mac_ok;

5

                #if ! defined(MASTER_CONFIG_H)

Is it desired, that the code after the if-clause is executed every time 
or should this normally be the content of the if-clause?

@jdobry
I tried to figure out why my devices send every minute a status telegram 
and not only on change as you suggested. The reason is that each time 
they receive a sync packet from the master the variable time_sync_tmo is 
set to 20 (file wireless.c) and then in main.c the value of 
time_sync_tmo leads to a setting of "wirelessTimerCase = 
WL_TIMER_FIRST". This causes the sending of the status packets.

Can you tell me what the intention of the variable time_sync_tmo is? And 
what is the function of WL_TIMER_FIRST?

@Star Keeper

After HR20 sends status the receiver is on for 80ms.
Within these 80ms you have to send an empty package (framebuf[0]=0x06, 
framebuf[1]=0x0, cmac).
When HR20 received this empty package, it sends status message every 4 
minutes, but keeps listening for sync package on 0 and 30 sec.
Without sending empty package you will get status message every minute.

Okay that sounds plausible, I was wondering why the original master 
always sends empty packets, even when there is no new data for the 
client.
In my Implementation I have removed this empty packet because it made no 
sense to me. ^^

I hope that fixing this will increase my battery life time. I had one 
valve with new bateries running for 2 month now and the batteries were 
empty. I was hoping to get a batery life time of one year or more.

My battery life depend to HR20 usage. In another word on volume of valve 
movements.
On child room battery must be replaced after one season. I have also one 
HR20 not mounted to heating, just for try life time only with LCD and 
wireless communication. It works almost 2 years and still working.
I am using cheap alcaline batteries from IKEA because it's easy write 
date of plug in on yellow body.

I also use cheap batteries from LIDL, and they last about one season.
But if the master daemon process on my FritzBox dies and I do not 
recognize that within hours, the battery life goes down immediately.

Guess the battery drains when the HR20 has no sync (E4).

I have successfully flashed the prebuild software (original_sww). If I 
connect to the serial line, I can see output every 4 minutes:


February 2, 2013 5:33:35 PM GMT+01:00: READ: D: d4 02.02.12 17:32:54 A 
V: 59 I: 2054 S: 2100 B: 4960 Is: 002e E:04


It is not exactly what I expected from reading the Basis_Protokoll.pdf 
from the repository.

If I try to send some commands like:

?VER\r\n
or
?CLOCK\r\n

there is no response. I looked into the source and it seems like maybe 
simply

V\n

is used for querying the version. But in both cases there is no 
response.

Am I doing something wrong? Do I need to enable serial communication?

Jörg Becker:
Serial communication use "unix" end of line. Try putty as serial 
terminal. Switch to right end of lines and try this commands. "D<enter>" 
or "V<enter>". It is case sensitive.

HI Jörg,

thanks for the quick answer. I already tried to use carriage return '\r' 
instead of new line '\n'.

I'm using an electric imp to connect to the thermostat, so no putty 
available here.

Hi all,
I've forked @bruce_a github repo and added some features:
1) cleanup of some deprecated php functions,
2) added easy compile scripts with sane(?) default options for 
compilation of rfmsrc/OpenHR20 and master on arduino
3) added support for RRD graphs (see attached sample), which can 
effectively hold and plot long term statistics.

If you're interested, grab the changes here:
https://github.com/piontec/openhr20
(I'm also merging my changes with bruce's fork)
Tutorial for setting RRD graphs is in
rfmsrc/doc/rrd-stats.txt

Nevertheless, I also have some questions, please have a look at my next 
post :)

Hi all,

I'm having problems tuning my 3 openhr20 thermostats.

I can't grab the idea how the PID implemented in openhr20 is working. As 
far as I found out, there is only PI part (that's what the configuration 
options allow to alter). But my controller acts as if there was a "D" 
part also. Please have a look at openhr20_opening.png. After the 
temperature change, the valve remains closed for some time, but than it 
starts to open, despite the fact, that the temperature is still to high. 
And because it opens, the temperature never reaches the set value 
(altough it seems it could). How can i fix that?

Another issue: I have a valve, where valve change of 1% (as far as I 
understand, the samllest possible step) results and quite visible 
temperature change (see osc.jpeg) and as a result, the temperature is 
constantly oscilating around the set value. Can i change that and make 
the valve adjustment step finer?

@jdobry: maybe you could share your ideas in some branch? It seems to 
me, that they could be really usefull, even when the protocols would 
show the rounded value of valve position.

And of there is no "D", why my valve starts to open and heats up the 
room even when the wanted temperature is much lower than the real one? 
How can I tune that?

And according to the fork... I needed Bruce's at328p port of master and 
he put that on github - and it's so easy to fork a project on github :) 
Maybe it would be worth the work to move openhr20 there too? If not, 
I'll try to put my changes into sf.net (someday).

Hi,
I am still working on my own master implementation. Currently I got 
stuck at the force communication mechanism. As far as I understood I 
have the possibility to trigger a communication with the valve using the 
two bytes "force_address" in the sync command. Is that correct?

I have problems using this mechanism the valves do only respond after 
four minutes and not as expected whithin the next 30 seconds. Which 
criterea must be met to force the valve to respond directly in the next 
time slot and not after the four minutes?

Hi Star Keeper,

yes, you have to use force address when sending sync command.

How did you encoded the address you want to force?
The OpenHR shifts x times right, corresponding to it's own address and 
then checks if it's 1.

An answer after 4min means that OpenHR has not recognized force command.

As far as I know, OpenHR answers 30sec+address after forcing.

I did not encode the address, there is on byte reserved per address and 
I write the plain address to it. For example if the address is 0x12 then 
I send this value in the corresponding force_address byte.
As far as I have understood the code of the valve there is no shifting 
or something like this.

I have found this code in main.c:

1

(

2

  (RTC_GetSecond()>30) &&

3

  (

4

    (RTC_GetSecond()&1)?

5

    (wl_force_addr1==config.RFM_devaddr):

6

    (wl_force_addr2==config.RFM_devaddr)

7

  )

8

) || 

9

(

10

  (wl_force_addr1==0xff) &&

11

  (RTC_GetSecond()%30 == config.RFM_devaddr) &&

12

  ((wl_force_flags>>config.RFM_devaddr)&1)

13

)

I think there are two possibilities to force the communication.

- First possibility is to use the two force_addresses.
- Second would be somthing like a broadcast with bits for each address 
in a force_flag variable.

With the first possiblity I would expect the device to respond in the 
seconds 30-59. The even seconds are used for force_address1 and the odd 
seconds for force_address2. -> But it does not work..

The second possibility would trigger the valve to respond within the 
next minute in the second 0-29 depending on the own address. I think I 
will have to test that instead.

The problem why the valve does not answer the force_address packets is 
founded in the fact that the valve does not receive these packets at 
all. I can see that the master sends the sync packet on 0th second and 
on 30th second. But only the first sync in the 0th second is received by 
the valve.

I have setup a second RFM12 hardware to have some sort of packet sniffer 
and I can see that the master really sends two packet but only one is 
received by the valve software.

Is there some sort of shutdown mechanism in the valve software that 
prevents the valve from receiving my packets in the 30th second?

Hi,
Altough I'm still having some problems with my openhr20 instalaltion, I 
wrote a detailed and complete (?) tutorial, that shows how to start form 
scratch and build the system step-by-step. Please visit the following 
URL to check it out:
http://piontecsmumble.wordpress.com

Comments, corrections and new topics are welcome!