@Jens: I use also constants. But assembler is not my best friend. ;-) So 
i used the infomations from the pdf.

@jdobry: It's not a problem. I bought my HR20 in 2010. Now I found the 
time to modify it... :-o

@the Problem: You both shift the single bytes and put the carry to the 
next byte and that not in the normal direktion... :-o But in the pdf 
(http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf) it's 
a normal left shift over all 64bit. So I think it's wrong what you 
doing!?

@Wojtek: I'm using this code and wiring: http://www.hs-coburg.de/20775.3
On the HR20 no Softwarechanges needed - but the master must run on the 
raspberry - that's what i'm working on.

hey guys,
I don't think that I have understood were you expect to have problem.

Currently I'am running the original HR20 firmware together with an 
selfmade server on Cortex-M3 basis. The encryption that I have taken for 
the master is somewhere from the internet and is coded in plain C. The 
communication works, which lead me to the conclusion that everything is 
fine in the asm implementation of jdobry.

A part of my files is taken from here:
http://armcryptolib.das-labor.org/trac

I don't know where the other part comes from, so I simply attached the 
files for reference.

When you say there is a problem in encryption, will the communication 
not work at all or will it stop working only in some cases?

Hi Star Keeper,

cmac and xtea not the problem. My "problem" is only the generation from 
K1 and K2. The security.pdf told me, that i have to left shift the whole 
L. But Jiri and Jens making not only a left shift. Take a look at the 
sourcecode from Jens (see his post from 2012-12-20) and compare it with 
capter 6.1 from this pdf: 
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf (it's 
a link from Jiri)

But in the reality it don't care. I have implemented it in my program 
like Jens in his sourcecode. Now my Program on the raspberry generate 
the same K1 und K2 like the HR20. It's working. :-)

Another question: I think, i have to acknowledge the data that my HR20 
is sending every minute. Because it's already the same dataset and every 
4 minute is a new set attached. But what format is the acknowledge? Only 
an empty Packet from Master to HR20 with length=0 and without cmac or 
anything?

Greets,
Michael

Hey folks, I just stumbled upon this project (after fiddling with ELV 
Max! thermostats for a bit, but I need a bit more control) and it seems 
perfect for my use. I'll be using a HR-25 thermostat and I'm going to 
try to attach it to a 802.15.4 mesh network. If I get anywhere, I'll 
post updates here :-)

However, I was looking at the code in svn and looked around the trunk 
for quite a while, until I found out the rmfsrc part of the repository. 
It looks like the trunk is no longer developed and all new commits 
happen on the rfmsrc part, is that correct? If so, wouldn't it make 
sense to drop the current trunk (or move it to some branch) and then 
make the current rfmsrc directory the new trunk?

Hi Matthijs,
welcome to the HR community :-).
I would recommend to also have a look at Bruce's git repo 
(https://github.com/bruce33/openhr20), which contains some improvements 
and bugfixes over the svn version. I think it's now the de-facto master 
repository.
That being said, the git repo still has the same layout as the svn one, 
so it does not really responds to your concern. I agree that some code 
reorganization and repo cleanup would help. Removing the old trunk and 
replacing it by a branch or tag would be probably a good starting point.
I believe the current status may be related to the fact that noone 
claimed the git to be officially the master one, and doing any 
reorganisation if there is even the slightest chance of someone merging 
the changes back to svn sounds like an integrators nightmare.

So maybe it's a good time to start a discussion - can we consider bruces 
git repo as a new master and abandon the svn repo (making it read-only 
and reflecting the change in documentation and web pages)?

Oeh, a git repo? Didn't see that one yet. I for one would welcome a git 
repository over an SVN repo anytime :-D Making it the official one would 
make sense to me, but like you say that really requires deprecating the 
old repo and pointing it to the new one to prevent confusing. Given that 
the SF project doesn't really contain anything other than the SVN repo, 
I'd say it makes sense to use github for the entire project, including 
the issue tracker?

Exactly, and I would even go a bit further, e.g. I find quite difficult 
to find interesting stuff in this single-thread forum. So maybe even 
moving into dedicated discussion forum with actual threading and 
sections could be a benefit.
But that needs approval and action from current maintainers, which have 
rights to the current svn repo, to the wiki, etc. That's why I initiated 
this discussion (I was planning to do it for a long time, but your post 
was a good trigger for me ;-) ).
I hope they find the time to respond and give us their opinion.

Chris wrote:
> I noticed a possible bug: When the motor is running and I press the
> middle button to view valve position, it sometimes does not react. When
> I press several times, it resets (all lcd segments on, asks for
> date/time).

Hi Chris,

I tried to reproduce the reset on my unit, but were not successful. Is 
it reproducible on yours? Can you give me better description of the 
steps to reproduce? What is your HW/SW configuration? If you have added 
RFM module, are you sure that your soldering is 100%, i.e. it can't be 
HW issue because of mechanical stress caused by the button press? If you 
have more units, can you reproduce the same on different unit?

Tomas

I just got two HR-25's today. Haven't powered them up yet, but did pull 
one apart to see its insides :-)

Since it was a bit tricky to open up, I thought it would be nice to make 
some notes. I also took pictures of its insides.

When opening up, these are the steps to follow:
 - Open up the battery compartment using two knobs at the sides near the 
valve end of the unit (also documented in the manual).
 - Pull up both of the knobs from the case. Both knows connect to a pin, 
and both pins are connected to eachother in the middle. Just pull the 
knobs, or wedge a screwdriver behind them to pull them apart and out of 
the case.
 - Pull off the main dial at the front. Just grab it and pull.
 - In the battery compartment at the back and behind the dial at the 
front are two plastic clips keeping the top cover in place. Using a 
screwdriver, press those to release the top cover.

You can now see the PCB. To pull that one out as well:
 - Remove the tiny screw at the top
 - Carefully pull out the PCB halfway. Note the gold-colored prong at 
the top right of the PCB (which normally slightly sticks out into the 
battery compartement). If you pull the PCB, it will likely snag against 
the chassic. Just press it down a tiny bit so it can slide alongside the 
PCB on the bottom of the plastic rail that supports the PCB.
 - The wires to the motor are too short to pull it out completely, so 
the motor needs to be removed too.
 - The motor is secured to the chassis using clips on the black plastic 
frame. Underneath the PCB you can see one of these clips, the other two 
are accessible through the rectangular holes in the battery compartment 
(use a screwdriver or something like that to get them loose).
 - Now pull out both the motor and the PCB.
 - When pulling out the motor, make sure you only pull out the motor and 
the white gear. There are number of black gears, which are best left 
inside (though if you accidentally pull them out, take all four of them 
apart and put them back one by one, two on each pin in the chassis).

I also took a load of pictures from the inside of the HR-25, which are 
available here: 
http://www.flickr.com/photos/46098841@N04/sets/72157636325061713/

I´ve build a RS-485 interface with a 3,3 volt step down converter for 
the HR20.

It uses pin PE2 to switch the send/receive pin.

It works for me just with a little change of the openhr20 software.

I also have a schematic and layout for a RS232 - RS485 converter which i 
use to access my hr20 valves.


regards   uwe

Hi,

no - after 2 days, i have given up. It takes a whole of time, to read 
the protocol out of the sourcecode. So I have redesigned the master PCB 
(smaller then the old one and without an layout bug) and now i'm waiting 
for the delivery of the pcb's. I think, it's the easiest way. The winter 
is in front of the door. ;-)

Greets,
Michael

@B0B81:

I did following:

1. I switched the "send" functions from the HR20 off.
    Now nothing is send when there´s no order.

2. I give every HR20 a number

3. In the receive function, the HR20 is checking the number
    (first received byte), if it is different:  do nothing.

4. When the HR20 answers, the first byte is his number.


I control the hr20s with a plc but i think this makes no difference.



Regards  Uwe

Chris wrote:
> Another question: Can I run the rondostates at 5V or even up to 5,5V?

I would not recommend it. As far as I was able to find, most components 
have maximum rating over 5V (atmel CPU 5.5V, RFM12B 6V, motor 6V, I 
don't know about the LCD), so you may not fry it, but it is still way 
over the level recommended in the spec sheets, so I would be surprised 
if everything worked as you expect.

If you have a 5V source you need to use, perhaps it's easiest to just 
add a 3.3V regulator? As a bonus, you get a nicely regulated voltage 
instead of just whatever the battery cares to provide like the normal 
circuit has...

I started to flash the Rondostat with the OpenHR Firmware.
I encountered some errors while flashing:

Here is the log:

1

** making backup...

2

*** backing up fuses...

3

4

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

5

avrdude: AVR device initialized and ready to accept instructions

6

7

Reading | ################################################## | 100% 0.01s

8

9

avrdude: Device signature = 0x1e9405

10

avrdude: reading lfuse memory:

11

12

Reading | ################################################## | 100% 0.00s

13

14

avrdude: writing output file "2013-11-02_18:49:07/lfuse.hex"

15

avrdude: reading hfuse memory:

16

17

Reading | ################################################## | 100% 0.01s

18

19

avrdude: writing output file "2013-11-02_18:49:07/hfuse.hex"

20

avrdude: reading efuse memory:

21

22

Reading | ################################################## | 100% 0.01s

23

24

avrdude: writing output file "2013-11-02_18:49:07/efuse.hex"

25

26

avrdude: safemode: Fuses OK

27

28

avrdude done.  Thank you.

29

30

*** backing up flash and eeprom...

31

32

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

33

avrdude: AVR device initialized and ready to accept instructions

34

35

Reading | ################################################## | 100% 0.01s

36

37

avrdude: Device signature = 0x1e9405

38

avrdude: reading flash memory:

39

40

Reading | ################################################## | 100% 3.17s

41

42

avrdude: writing output file "2013-11-02_18:49:07/hr20.hex"

43

avrdude: reading eeprom memory:

44

45

Reading | ################################################## | 100% 0.50s

46

47

avrdude: writing output file "2013-11-02_18:49:07/hr20.eep"

48

49

avrdude: safemode: Fuses OK

50

51

avrdude done.  Thank you.

52

53

*** writing openhr20 flash and eeprom...

54

55

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

56

avrdude: AVR device initialized and ready to accept instructions

57

58

Reading | ################################################## | 100% 0.01s

59

60

avrdude: Device signature = 0x1e9405

61

avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

62

         To disable this feature, specify the -D option.

63

avrdude: erasing chip

64

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

65

avrdude: reading input file "hr20.hex"

66

avrdude: input file hr20.hex auto detected as Intel Hex

67

avrdude: writing flash (15854 bytes):

68

69

Writing | ################################################## | 100% 4.08s

70

71

avrdude: 15854 bytes of flash written

72

avrdude: verifying flash memory against hr20.hex:

73

avrdude: load data flash data from input file hr20.hex:

74

avrdude: input file hr20.hex auto detected as Intel Hex

75

avrdude: input file hr20.hex contains 15854 bytes

76

avrdude: reading on-chip flash data:

77

78

Reading | ################################################## | 100% 3.04s

79

80

avrdude: verifying ...

81

avrdude: 15854 bytes of flash verified

82

avrdude: reading input file "hr20.eep"

83

avrdude: input file hr20.eep auto detected as Intel Hex

84

avrdude: writing eeprom (408 bytes):

85

86

Writing | ################################################## | 100% 1.13s

87

88

avrdude: 408 bytes of eeprom written

89

avrdude: verifying eeprom memory against hr20.eep:

90

avrdude: load data eeprom data from input file hr20.eep:

91

avrdude: input file hr20.eep auto detected as Intel Hex

92

avrdude: input file hr20.eep contains 408 bytes

93

avrdude: reading on-chip eeprom data:

94

95

Reading | ################################################## | 100% 0.50s

96

97

avrdude: verifying ...

98

avrdude: verification error, first mismatch at byte 0x0015

99

         0x21 != 0x00

100

avrdude: verification error; content mismatch

101

102

avrdude: safemode: Fuses OK

103

104

avrdude done.  Thank you.

105

106

*** done!

After that I was unable to flash anymore because avrdude complained 
about my Signature 0xffffff.

I stumbled over a post http://embdev.net/topic/118781#3112836 from Frank 
where he has gotten the same Problems.

So I conected Reset to Ground an I was able to flash the device

Now I get this Message:

1

sebastian@sebastian-SX20S:~/openhr20/rfmsrc/OpenHR20$ sudo ./flash_hr20.sh*** making backup...

2

*** backing up fuses...

3

4

avrdude: AVR device initialized and ready to accept instructions

5

6

Reading | ################################################## | 100% 0.01s

7

8

avrdude: Device signature = 0x000000

9

avrdude: Yikes!  Invalid device signature.

10

         Double check connections and try again, or use -F to override

11

         this check.

12

13

14

avrdude done.  Thank you.

15

16

sebastian@sebastian-SX20S:~/openhr20/rfmsrc/OpenHR20$ sudo ./flash_hr20.sh

17

*** making backup...

18

*** backing up fuses...

19

20

avrdude: AVR device initialized and ready to accept instructions

21

22

Reading | ################################################## | 100% 0.01s

23

24

avrdude: Device signature = 0x000000

25

avrdude: Yikes!  Invalid device signature.

26

         Double check connections and try again, or use -F to override

27

         this check.

28

29

30

avrdude done.  Thank you.

31

32

sebastian@sebastian-SX20S:~/openhr20/rfmsrc/OpenHR20$ sudo ./flash_hr20.sh

33

*** making backup...

34

*** backing up fuses...

35

36

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

37

avrdude: AVR device initialized and ready to accept instructions

38

39

Reading | ################################################## | 100% 0.01s

40

41

avrdude: Device signature = 0x1e9405

42

avrdude: reading lfuse memory:

43

44

Reading | ################################################## | 100% 0.00s

45

46

avrdude: writing output file "2013-11-03_15:58:36/lfuse.hex"

47

avrdude: reading hfuse memory:

48

49

Reading | ################################################## | 100% 0.01s

50

51

avrdude: writing output file "2013-11-03_15:58:36/hfuse.hex"

52

avrdude: reading efuse memory:

53

54

Reading | ################################################## | 100% 0.01s

55

56

avrdude: writing output file "2013-11-03_15:58:36/efuse.hex"

57

58

avrdude: safemode: Fuses OK

59

60

avrdude done.  Thank you.

61

62

*** backing up flash and eeprom...

63

64

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

65

avrdude: AVR device initialized and ready to accept instructions

66

67

Reading | ################################################## | 100% 0.01s

68

69

avrdude: Device signature = 0x1e9405

70

avrdude: reading flash memory:

71

72

Reading | ################################################## | 100% 3.14s

73

74

avrdude: writing output file "2013-11-03_15:58:36/hr20.hex"

75

avrdude: reading eeprom memory:

76

77

Reading | ################################################## | 100% 0.50s

78

79

avrdude: writing output file "2013-11-03_15:58:36/hr20.eep"

80

81

avrdude: safemode: Fuses OK

82

83

avrdude done.  Thank you.

84

85

*** setting fuses...

86

87

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

88

avrdude: AVR device initialized and ready to accept instructions

89

90

Reading | ################################################## | 100% 0.01s

91

92

avrdude: Device signature = 0x1e9405

93

avrdude: reading input file "0x99"

94

avrdude: writing hfuse (1 bytes):

95

96

Writing | ################################################## | 100% 0.01s

97

98

avrdude: 1 bytes of hfuse written

99

avrdude: verifying hfuse memory against 0x99:

100

avrdude: load data hfuse data from input file 0x99:

101

avrdude: input file 0x99 contains 1 bytes

102

avrdude: reading on-chip hfuse data:

103

104

Reading |                                                    | 0% 0.00savrdude: jtagmkI_read_byte(): timeout/error communicating with programmer (resp )

105

*** writing openhr20 flash and eeprom...

106

107

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

108

avrdude: AVR device initialized and ready to accept instructions

109

110

Reading | ################################################## | 100% 0.01s

111

112

avrdude: Device signature = 0x1e9405

113

avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

114

         To disable this feature, specify the -D option.

115

avrdude: erasing chip

116

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible

117

avrdude: reading input file "hr20.hex"

118

avrdude: input file hr20.hex auto detected as Intel Hex

119

avrdude: writing flash (15854 bytes):

120

121

Writing | ################################################## | 100% 4.08s

122

123

avrdude: 15854 bytes of flash written

124

avrdude: verifying flash memory against hr20.hex:

125

avrdude: load data flash data from input file hr20.hex:

126

avrdude: input file hr20.hex auto detected as Intel Hex

127

avrdude: input file hr20.hex contains 15854 bytes

128

avrdude: reading on-chip flash data:

129

130

Reading | ################################################## | 100% 3.04s

131

132

avrdude: verifying ...

133

avrdude: 15854 bytes of flash verified

134

avrdude: reading input file "hr20.eep"

135

avrdude: input file hr20.eep auto detected as Intel Hex

136

avrdude: writing eeprom (408 bytes):

137

138

Writing | ################################################## | 100% 1.12s

139

140

avrdude: 408 bytes of eeprom written

141

avrdude: verifying eeprom memory against hr20.eep:

142

avrdude: load data eeprom data from input file hr20.eep:

143

avrdude: input file hr20.eep auto detected as Intel Hex

144

avrdude: input file hr20.eep contains 408 bytes

145

avrdude: reading on-chip eeprom data:

146

147

Reading | ################################################## | 100% 0.50s

148

149

avrdude: verifying ...

150

avrdude: 408 bytes of eeprom verified

151

152

avrdude: safemode: Fuses OK

153

154

avrdude done.  Thank you.

155

156

*** done!

Why I'm getting this error:

jtagmkI_read_byte(): timeout/error communicating with programmer (resp )

It seams that I managed to flash everthing in the right way.
But after installing the master and the rfm-12b I keep getting Error E4.

daemon.php writes following lines:

1

O0000

2

 < OK

3

 < d1 11.11.13 14:27:00

4

 < RTC?

5

H0e1b0000

6

 Y0d0b0b

7

 < (01)?

8

 < OK

9

 < OK

10

 < (02)?

11

 < (03)?

12

 < (04)?

13

 < (05)?

14

 < (06)?

15

 < (07)?

16

 < (08)?

17

 < (09)?

18

 < (0a)?

19

 < (0b)?

20

 < (0c)?

21

 < (0d)?

22

 < (0e)?

23

 < (0f)?

24

 < (10)?

25

 < (11)?

26

 < (12)?

27

 < (13)?

28

 < (14)?

29

 < (15)?

30

 < (16)?

31

 < (17)?

32

 < (18)?

33

 < (19)?

34

 < (1a)?

35

 < (1b)?

36

 < (1c)?

37

 < (1d)?

38

 < N1?

39

O0000

40

 < OK

41

 < d1 11.11.13 14:27:30

How can I control if both master and OpenHR are functioning well?

Hi,
the idea behind the baud rate setting is that faster baud rate means 
less time needed to transfer all the data required, thus less battery 
power used for transmit. But it also means, as you noticed, less robust 
communication and smaller range. So you need to find the setting that 
works best for your installation.

Do you think that lousy AVR oscillator can affect wireless 
communication? If yes, how?
RFM12 has its own oscillator, which should be better, so IMHO only 
bit-banging SPI communication can be affected. Am I overlooking 
something?

Ah, now I got it. When Chris was complaining about baud rate, he meant 
WIRED serial communication, not wireless. Sorry, my bad.

I had some timing issues with RS-232 during debugging as well. I had 
changed the UART setting to use normal speed instead of double speed (by 
removing the setting of U2X bit in UCSR0A and changing the UBRR divisor 
to 16 from 8 in rs232_485_hw.c) and the issues seems to be resolved. You 
may want to try that as well, Chris, maybe it will help you too.
Does anyone know why the double speed was chosen as default? Any 
particular reason, or just a coincidence? :-).

Also, AVR054 application note (http://www.atmel.com/Images/doc2563.pdf) 
could be of interest in the case of multiple MCUs connected together.

I thought I got a good deal on RFM12b radio modules, but it turned out 
they are the newer RFM69CW. Supposedly the footprint is compatible, but 
the software is different. They also apparently have some other 
advantages over RFM12b e.g. range & encryption.

Any views on whether it's worth trying to add support for these radios 
to the codebase? If not, I'll stick them back on eBay.

Rhys

As RFM12B is being phased out (AFAIK hoperf promised they will keep 
manufacturing it for the time being, but it's not recommended for new 
designs) it would make sense to start experimenting with newer types. So 
I would say go for it, if you have the time :-).
This might be of interest if you decide to start on it: 
https://github.com/LowPowerLab/RFM69

If you are getting ERRxx message it means that there is an error :-). 
First, make sure that you have your thermostat close to the master to 
rule out communication problems. Next, make sure that your crypto key is 
the same in master and in the thermostat (please be aware if you are 
flashing your arduino master via arduino style bootloader, you can't 
flash eeprom, where the keys are stored, you need to use serial console 
to set the key or update the whole eeprom. I spent few days figuring 
this out ;-) ).
If this does not help, I will think a bit more :-).

Wavemaker wrote:
> Tomas Kopal, Thanks for the hints. I've rechecked the encryption keys.
> But these are absolutely identical. Note, I did have some communication
> already working. I thus simply continued following pointec's articles.
> And in fact I managed to get everything working. So I must say that the
> errors are not bothering me (too) much. However, of course they should
> not be there. And if it is helpful for the project if I test some more,
> then I'm happy to that.

Ahh, I thought that you were getting errors but no communication. In 
case your communication is working, and you are getting these errors at 
random times, it just means there is some interference with other 
transmitters (cordless phones, alarms, microwave owen...) being 
interpreted as having valid preamble by your RFM12. But the 
encryption/crc check will take care of that, so you can safely ignore 
that. It just means more processing by the MCU, so a bit more battery 
wasted. If you are getting too many of these, you can try tuning your 
radio to different frequency. But without some analyzer, it's mostly 
trial and error game...

> One other thing I wonder: Did anybody think of cutting the HR20
> thermistor and then remounting it using wires at some distance away from
> the unit, such that the measured temperature is more representative for
> the room? Did anybody do this? It seems to me that it could allow more
> realistic/accurate setpoints. However, I imagine that it would require
> some adjustments to the default control settings? Would it also require
> some changes to the code on the unit? Or should this simply work?

I haven't tried, but I suppose that long wires will not do much good to 
the precision of the thermistor. I think that better option is to use 
dedicated thermometer with it's own wireless transmitter, or or even 
wired to master, but I do not think this is supported by the master sw 
at this time.

Wojtek Sim wrote:
> something is wrong with xtea calculation.
> during the crypto_init with same values (Default key 0x01 0x23 0x45 0x67
> 0x89 0xab 0xcd 0xef) the master code returns 0x3b d6 f1 a6 ac 20 b2 b4
> (for k_mac first step) but the hr20 code Returns e2 57 7e 26 de 63 d0 54
>
> whats wrong ? the K_m value is the same but different values are
> calculated. I checked the lss files and its look fine, so its the same
> function inside...
>
> the code is same the values and fuction also, only one Thing is
> different the master is 328P ... but it should be not a Problem.
>
> Any idea ? maybe somebody can check what is the right value ?
> (xtea_enc(K_mac, K_mac, K_m); /* generate K_mac low 8 bytes */)

I am also using 328P in the master, and with the default keys 
communication works. So it is not MCU specific, I guess. Check your 
compiler flags, maybe some signed/unsigned problem?

Wojtek Sim wrote:
> @Tomas
> maybe my modifications for 328P caused this strange behaviour.
> did you download the master 328P code, I did not found the branch for
> 328P.

If you want to take a look at my version, it is here: 
https://github.com/KickerTom/openhr20. It is a fork of Bruce's code, but 
not all changes are merged back there yet. Hope this helps, good luck.

Here is my master configuration report:

Configuration
Hardware type: MCU atmega328p at 16000000Hz
RFMFLAGS=-DRFM_TUNING=1 -DSECURITY_KEY_0=0x01 -DSECURITY_KEY_1=0x23 
-DSECURITY_KEY_2=0x45 -DSECURITY_KEY_3=0x67 -DSECURITY_KEY_4=0x89 
-DSECURITY_KEY_5=0x01 -DSECURITY_KEY_6=0x23 -DSECURITY_KEY_7=0x45 
-DRFM_FREQ_MAIN=433 -DRFM_FREQ_FINE=0.35 -DRFM_BAUD_RATE=19200
MASTERFLAGS=-DNANODE=0 -DJEENODE=1
==================================

AVR Memory Usage
----------------
Device: atmega328p

Program:    7660 bytes (23.4% Full)
(.text + .data + .bootloader)

Data:       1169 bytes (57.1% Full)
(.data + .bss + .noinit)

EEPROM:      104 bytes (10.2% Full)
(.eeprom)

LOL wrote:
> Question: Is there a user manual for the OpenHR20 firmware somewhere
> around? I was able to map all functionality (I hope), but it seemed odd
> that not a single readme documenting the new functionality was around.

None that I would be aware of. I also had to find all the functionality 
by reading the code.

Hi,

one question, i downloaded the HR20.hex and HR20.EEP from /trunk/source 
from svn.code and flashed the hex-file, this works. but the .eep file 
cannot be flashed, because it seems to be to big, my programm says "file 
is too large to fit into buffer". and without flashing the .eep file, 
the HR20 shows "EEPr" on the LCD. i read the code, and it's because of 
checking the eeprom-layout at start-up, and i can not flash the .eep 
file.

how did you flash the .eep file? is there another .eep file?

and: did someone have the original software for the HR20. i downloaded 
it before i flash the new software, but i didnt work after flashing the 
old software.

thanks

Jan

Jan Wmann wrote:
> Hi,
>
> one question, i downloaded the HR20.hex and HR20.EEP from /trunk/source
> from svn.code and flashed the hex-file, this works. but the .eep file
> cannot be flashed, because it seems to be to big, my programm says "file
> is too large to fit into buffer". and without flashing the .eep file,
> the HR20 shows "EEPr" on the LCD. i read the code, and it's because of
> checking the eeprom-layout at start-up, and i can not flash the .eep
> file.

Hi

what tools are you using to flash the eep file? For me, using JTAG and 
Atmel Studio, it works just fine (mind you, it's with self-built files, 
I never tried flashing the pre-built one, but I suppose it should be 
ok).
You definitely want that flashed, the firmware won't work without it.

>
> how did you flash the .eep file? is there another .eep file?
>
> and: did someone have the original software for the HR20. i downloaded
> it before i flash the new software, but i didnt work after flashing the
> old software.
>
> thanks
>
> Jan

As far as I know, there is no way to get back to the original firmware, 
the MCU has a no-read fuse set, so you can't extract the original 
firmware from it. So no, I do not have it and I doubt anyone else have 
it. Once you flash the MCU, you are on your own, there is no way back.

Thank you,

i try to flash the hex and eep file with bascom, where flashing the 
hex-file successfully worked.

due to your anwser i tried it with atmel studio 6 and AVRISP MKII, but 
the studio does not know the chip "atmega169". it only knows 
atmega169A,P and PA. it dosn't work with one of these chips. 
faultmessage "unable to enter programming mode" appears.

Can i add another controllers to atmel studio 6? or do you have another 
idea?

thank you

Jan

ATMega169P is the right one... ;-) You have an other problem... :-o

Greets,
Michael

Jan Wmann wrote:
> due to your anwser i tried it with atmel studio 6 and AVRISP MKII, but
> the studio does not know the chip "atmega169". it only knows
> atmega169A,P and PA. it dosn't work with one of these chips.
> faultmessage "unable to enter programming mode" appears.

Wait, AVRISP MKII ? That is ISP programmer only, isn't it? How did you 
connect it?
Rondostat thermostats needs to be programmed via JTAG, which is wired to 
the connector. ISP lines are used for other purposes, and I think (but I 
may be wrong, I haven't really checked or tried) they are unusable for 
ISP programming...

yes, i programm with isp. have soldered a programmer to RESET, VOLTAGE 
and GROUND at the connector and MISO, MOSI and SCK to the switches 
(prog, auto/man,etc). and with bascom and the bascomprogrammer it works 
good.

tomorrow i will test with the EESAVE fuse. the wiring musst me correct 
due to the fact that i can programm it with the other isp-programmer.

thank you

Jan

so, shame on me  :-)

now it works, and the problem was, that i had from my last project the 
isp-speed to high. i set the isp-speed to 125kHz and now it works.

thanks to you for your help

Jan

Hey folks,

the OpenHR20 project has moved and is getting new maintainers. We're 
moving to github for the code and Google Groups for discussion. If 
you're still interested in the project, make sure you subscribe to the 
new list / forum and perhaps also to the github project.

For more info, see this post on the new group: 
https://groups.google.com/d/msg/openhr20-development/NMD_Un5_aCc/AO4AJFlR_AgJ

Hi,
I haven't tried, but I think there is no inherent problem in using NRF24 
module instead of RFM12B. It should even fit into the thermostat casing, 
there is plenty of space in there. Not sure what range you would get, 
and what would be the power consumption though.
Wiring should be similar, except NRF24 has a dedicated IRQ line and two 
chip enable signals instead of one. But I think that should be solvable.
The biggest problem would be the software. Control of NRF24 is, I think, 
completely different to what RFM12B expects, so you would have to 
rewrite that part in OpenHR. I tried making the RFM code a bit more 
separated, trying to use RFM69, but I haven't got too far (yet). It's 
doable I think, but it depends on how much time you want to spend on 
this (and on your experience with embedded SW).
I am not sure what you mean by flashing atmel MCU with arduion sketch? 
Like programming the thermostat via arduino IDE? Possible, but I would 
not recommend it. The flash in HR20 is quite packed with OpenHR sw, 
which is quite size-optimized. I think that similar functionality won't 
fit when implemented in Arduino framework. (HR25 has more flash, so the 
situation is different there.) Also, OpenHR is not using Arduino 
framework, so you would have to rewrite the whole thing. More work than 
adding NRF24 support to OpenHR, IMHO.
Also, I am not sure what exactly you want to achieve. Usually, generic 
systems for home automation are not very well suited to control the 
whole network of thermostatic valves IMHO, looks like micromanaging to 
me. I would probably look more to build the system with some central 
unit, as OpenHR currently does with its master, and then connect this 
central unit to the home automation system. But YMMV :-).

@Tomas Kopal

Thanks Tomas for your headsup und information and sorry for spoiling the 
thread recently...

Piontecs mumble's great documentation proposes the process of using 
Linux for the make process...

Unfortunatly, Since i am not very familiar with Linux anymore, i cannot 
use It for the make process.
I started using Atmelstudio with JTAGICE some month ago and find it 
quite usefull and handy to do devs in a timely manner..
Initially Started with Arduino IDE but for coding more than a few lines 
this is not very suitable...

So i would love to do the dev process in AS6.2.
Maybe there is a chance for me to get this started to transfer the files 
of the project from Linux make files to As6.2 with some help from you or 
other mates. I have seen AS6.2 allows for external makefiles, but i 
havent found much info how to use it.

As i already mentioned i'd love to contribute to the project as much as 
i can in regards to things i can do - like testing, and once i got some 
experience in compiling the sources and documentation the sources and 
processes. I have also quite some experience with RF circuitry as i'm a 
licensed Radio Amateur - currently just playing around with some newer 
RFM modules from Hope.

You mentioned a wiki, which you setup on Github for this project, but i 
found no link to it - i'd love to create some info pages there as well.

Kind regards, Mike

I have answered on the mailing list. For reference, this is the reply:

https://groups.google.com/d/msg/openhr20-development/B0X2Ujb9ed0/gaLGE3S3sEwJ

And here is the wiki link, for anyone interested:

https://github.com/OpenHR20/OpenHR20/wiki

Hi @all,

I'm using OpenHR20 firmware quite a while now and I'm very happy with 
it. Some time ago I found those ESP8266 low cost WiFi modules which just 
need an serial interface. The protocol is quite easy (some AT commands 
for configuring and a few for UDP- or TCP-connections). Would it be 
possible to modify OpenHR20 firmware to use those WiFi modules directly 
attached to the HR20 serial interface?

The problem I see is, how to configure WLAN- and IP-settings. But as a 
fitst step it seems sufficient to be, if those things can be configured 
in the source before compiling.

Is anyone else intrested in such a feature?

Greets
  Sebastian.

Hi Sebastian,

I don't see any reason why this module should not work with OpenHR, 
assuming you adapt the code accordingly (which may not be as simple as 
it may sound, as the current RFM code is not very well separated).
Regarding addresses - we already have an address for every unit, which 
can be specified while building the firmware, or set later via 
engineering menu. I suppose it would be quite easy to adapt to IP 
address, "MAC address" for auto-configuration, or revamp the settings 
completely and do proper connection setup. Depends only on how much time 
you want to spend on this :-).

I would recommend using one of IQRF transceivers (www.iqrf.org) 
DCTR-5xDAT. It has very nice framework easy mountable to HR20. You could 
use SPI or UART to communicate with HR20. I am now working on connecting 
it to HR20.

Milan Musec wrote:
> I would recommend using one of IQRF transceivers (www.iqrf.org)
> DCTR-5xDAT. It has very nice framework easy mountable to HR20. You could
> use SPI or UART to communicate with HR20. I am now working on connecting
> it to HR20.

I would be quite interested in your experience with this radio. I had 
some bad experience so far with trying to get reliable signal with 
antenna inside of the housing (but with different radio, different 
antenna, even different frequency), so I wonder what this PCB antenna 
can deliver. Also, I would be a bit afraid of power consumption of this 
radio module, so any info about real battery lifetime would be nice.
Please keep us posted...

I've managed to build the OpenHR20 firmware and flash an HR20 device 
with it. It appears to be working in the sense that I can communicate 
with it via the serial port, and it appears to be functioning as 
expected when attached to the heater. However, I'm having trouble 
setting the timers.

Maybe I don't understand the timer settings, so perhaps someone will be 
kind enough to guide me through a simple setting: I want to program all 
days (1-7) so that at 6:30 the temperature is set to 21 C, and at 22:30 
the temperature is set to 17 C.

This is what I tried:

1. I held the "PROG" button then pressed "PROG" again when "1-7" started 
to flash.
2. To set the 6:30 temperature, I pressed the thermometer (middle) 
button to select the night/day, then dialed 6:30 and pressed "PROG".
3. To set the 22:30 temperature, I pressed the thermometer button to 
select night, then dialed 22:30 and pressed "PROG".
4. For the remaining timers, I dialed "--:--" and pressed "PROG" for 
each of them.

However, the second timer (which should read 22:30) stays at 09:00, even 
if I attempt to program it by writing over the serial port. In fact, the 
only timer I seem to be able to set is the very first timer.

Am I doing something wrong?

I figured out what I did wrong: I had checked out the code repository at 
http://sourceforge.net/projects/openhr20/ and it seems to build version 
0.99 of the firmware.  However, the compiled binaries that one may 
download from Sourceforge appear to be version 1.0, and that version 
works.

Where (or how?) do I find source code that is up to date?

Yup, the latest source is now here: https://github.com/OpenHR20/OpenHR20

I still need to update the sourceforge page to point there (but wanted 
to clean up some documentation first, but haven't found the time yet so 
far...)

Thanks. The current source code on Github doesn't appear to work on my 
devices, but I'm not currently in the mood for debugging. The HR20 
devices seem to work with the binary of version 1.0, so I'll just 
consider it "closed source" for now.

I know what you mean; it's just that as long as I have no idea which 
revision of the code it was compiled from, the chance of finding the bug 
was introduced becomes somewhat difficult.

EDIT: Strike that. I managed to make it work. Thanks for your help!

Hi Peppe,

welcome back :-).

The best description I know of is in repository, 
rfmsrc\doc\hr20-security.pdf. If you need more details, I am afraid you 
will have to check the source code.

Edit: Sorry, I should have read more carefully, I though you want 
communication between master and the units. For the daemon.php, I don't 
think there is anything better than the code, sorry.

Tomas

Peppe wrote:
> Until now i am able to send the date and time to my valves. I tried to
> re-ing the deamon.php but at the point where the special command "P" is
> generating i am lost.

It's usually better to check also the avr sources (e.g. 
rfmsrc/master/com.c) for better understanding. The protocol between the 
master and PC is quite closely related to the communication of master 
with the units. So looking at the document I referenced before still 
makes sense.
Regarding the P command, I believe this has something to do with 
"forcing communication" with the units in next time slot. The php checks 
if there are any pending commands and then asks the corresponding unit 
for a communication window apart of normal communication slot.

>
> How did you manage to run it on the raspberry Pi, did you connect the
> original master to the pi an run the frontend on it, or let you run the
> hole master software on the raspberry pi?

Yes, I have the master running on a small avr 328P based board 
(JeeNodeSMD from Jeelabs.org), and connect it to the raspberry via 
serial. Raspberry is then running php daemon and web server.

> If you have the master connected to the Raspberry pi and run the
> daemon.php on it, i like to ask you if you can share your raspberry
> image with me :)

That is of course possible, however I haven't really done any 
modifications apart from setting the correct serial port in daemon.php 
and few adjustments to rooms setup, so I am not sure what would you 
gain.

Armin wrote:
> Hello,
>
> first of all I have to say: this is an amazing project and the
> developers did an outstanding job so gar! I just successfully flashed my
> first HR20 with openHR20 using the ICSP interface! :)
> Now I just have a problem regarding the radio modules. A few weeks ago,
> when I bought them on ebay, the only ones that were available were
> RFM69CW type. Despite them being pin-compatible, they require different
> software. Earlier in this thread I read that another forum member was
> trying to modify the source code to communicate with the RFM69CW. Is
> there any update on this? Did anyone successfully accomplish this? :)
>
> thanks! greetings from Munich

That member could be me :-). Unfortunately, real life took over in the 
past year and I had no time for not only RFM69 support, but for this 
project as a whole :-(. I hope in the next one, I will be able to get 
back on track and make some progress.
But if you are able and willing to code, any contribution is welcome 
:-).

Hello comunity,

i´m new to this project and i have ordered a HR25 for first testing 
because of the 32kB flash.

Can you recommend me a cheap JTAG debugger to programm it without 
opening the device?

I found one on ebay...

http://www.ebay.de/itm/JTAG-ICE-ATmega-AVR-USB-Emulator-debugger-programmer-/192075040262?hash=item2cb8908606:g:YFQAAOSwYlJW3yue

In the description is no Atmega329 mentioned...
Can any one confirm that i can flash OpenHR20 with this or an similar 
JTAG debugger?

If not, will it work for the HR20 (Atmega169)?

Thanks.

Thank you very much.


Now i habe some other questions...

I found the OpenHR20 project source on github and on sourceforge.

If i compare the modified date of files on github with that on 
sourceforge, i think there could be some differences in the code base.

Is it right that the source on github is the newest or best source to 
take?

Are there all commits from sourceforge also on github?

From where downloaded you your sources?

I think this firmware will work well and become successful! 
http://getessayeditor.com/blog/improve-your-dissertation-using-online-editing-services 
will help you to improve your dissertation via online editing services!

jdobry wrote:
> It will work, but not with latest Atmel studio based on MS Visual
> studio. You don't need to open valve, connector cover is enougth. Note
> connector on JTAG and connector on valve have different pinout. You will
> need to make adapter.

My first question was if it will work with the Hr25 (Atmega329) and it 
doesn´t work. I can´t programm my HR25 with that fucking JTAGICE Clone. 
:-(

Thanks for help to waste money for this unuseful JTAGICE Clone.

Jo N. wrote:
> Thank you very much.
>
>
> Now i habe some other questions...
>
> I found the OpenHR20 project source on github and on sourceforge.
>
> If i compare the modified date of files on github with that on
> sourceforge, i think there could be some differences in the code base.
>
> Is it right that the source on github is the newest or best source to
> take?
>
> Are there all commits from sourceforge also on github?
>
> From where downloaded you your sources?

Code from sourceforge was imported to github. AFAIK there were no 
commits in sourceforge since then, so github should have everything what 
sourceforge has, and more. Which does not mean it must be better ;-).

Regards

Tomas

Jo N. wrote:
> jdobry wrote:
>> It will work, but not with latest Atmel studio based on MS Visual
>> studio. You don't need to open valve, connector cover is enougth. Note
>> connector on JTAG and connector on valve have different pinout. You will
>> need to make adapter.
>
> My first question was if it will work with the Hr25 (Atmega329) and it
> doesn´t work. I can´t programm my HR25 with that fucking JTAGICE Clone.
> :-(
>
> Thanks for help to waste money for this unuseful JTAGICE Clone.

Although I understand your feelings (also bought few useless clones), 
you should have confirmed with the seller, and complain there, not here.

Anyway, maybe if you provide more details than "it doesn't work" then we 
might be able to help you. If the adapter really can program the chips 
stated in the description (namely Atmega169), I don't see much reason it 
should not be able to program also HR25 with Atmega329.

Hi,

hunt_work_er wrote:
> hey guys,
>
> can you please tell me, where I can find the newest sources? In the Git
> repo is one project in OpenHR20/tree/master/rfmsrc/OpenHR20 and an other
> project in OpenHR20/tree/master/trunk/source. Which one ist the newest
> one?

You found it correctly, the newest should be in the github repository 
https://github.com/OpenHR20/OpenHR20. In this repo, the folder rfmsrc is 
the latest. The other one is old code without wireless support, but also 
without many other changes. We need to clean up the repo, but it has not 
been done yet.

> I guess the first one, but I can't find an eep file.
> With the sources from rfmsrc and the eep from trunk, I get the message
> "EEPr" while "booting" the HR20. It stops while checking the EEPROM
> layout check.

I am not sure what you mean by "can't find an eep file". There are no 
resulting binaries in the repo. You need to compile the sources first. 
Use either make or the compile_hr20.sh script, but modify the parameters 
for your configuration first. After compiling, you should be able to 
find the binaries (including eep file) in the bin folder.

>
> Can you please give me a short tutorial?
>
> P.S.: I am using an AtmelICE. The HR20 won't get an RFM module, but a
> small external PCB with CAN interface.

CAN-bus for thermostats? Sounds interesting, hope you post some more 
details later :-).

Tomas

Tomas K. wrote:
> You found it correctly, the newest should be in the github repository
> https://github.com/OpenHR20/OpenHR20. In this repo, the folder rfmsrc is
> the latest. The other one is old code without wireless support, but also
> without many other changes. We need to clean up the repo, but it has not
> been done yet.

I thought so, but I was confused about the "missing" eep file.
I guessed, i had to flash a standard layout to the EEPROM. I didn't 
know, that the compiler creates that file.
I found the eep file in my bin folder. Thank you!

Tomas K. wrote:
> CAN-bus for thermostats? Sounds interesting, hope you post some more
> details later :-).

Of course, I will write my experiences her, and I guess, I will have 
some questions here. ;)

Jonas

I'm thinking of powering the HR20 via its connector. Is this possible? 
And if so, is the HR20 3.3 volt tolerant, or does it require a 3.0 volt 
input that corresponds to being battery powered?

Hi everybody. Fantastic job. COngrats to developers.

I'm just trying to control a lcd on ATMEGA3290PA on a customized LCD.THe 
lCD controller is the same.
 I can't find the meaning of this part of code:

// Look-up table to adress element F for one Position. ( 32 : 10 )
const uint8_t LCD_FieldOffsetTablePrgMem[] PROGMEM =
{
#ifdef THERMOTRONIC
    39,    //!<  Field 0
    35,    //!<  Field 1
#else
    40,    //!<  Field 0
    36,    //!<  Field 1
#endif
    31,    //!<  Field 2
    27     //!<  Field 3
};

// Look-up table to adress a segment inside a field
const uint8_t LCD_SegOffsetTablePrgMem[] PROGMEM =
{
     2,    //  Seg A            AAAA
     3,    //  Seg B           F    B
    27,    //  Seg C           F    B
    25,    //  Seg D            GGGG
    24,    //  Seg E           E    C
     0,    //  Seg F           E    C
     1     //  Seg G            DDDD
};

I really appreciate your help. thank you

Hi,
I just updated to windows10, installed the same toolchain like in 
Windows7: WinAVR-20100110, AVRStudio4.18SP3

and did not make any changes to all the sources. As I only did some 
small changes to the code years agon I have no idea what the prob. might 
be.... please help the novice !!!!

A "rebuild all" brings a fatal error when compiling motor.c.

I guess it has something to do with the .dep directory. It looks like it 
cant be created ?? What rights does the directory need or why could the 
statement in the makefile fail ?
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)

1

Compiling C: motor.c

2

avr-gcc -c -mmcu=atmega169p -I. -gdwarf-2 -DF_CPU=4000000UL  -DRFM=0 -DTEMP_COMPENSATE_OPTION=1 -DHW_WINDOW_DETECTION=0   -DNO_AUTORETURN_FROM_ALT_MENUES=1   -DBLOCK_INTEGRATOR_AFTER_VALVE_CHANGE=1 -DBOOST_CONTROLER_AFTER_CHANGE=1 -Os -mcall-prologues -fun

3

signed-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=obj/motor.lst  -std=gnu99 -ffreestanding  -Wl,--relax  -fdata-sections -MMD -MP -MF .dep/motor.o.d motor.c -o obj/motor.o 

4

5

In file included from motor.c:49:

6

eeprom.h:144:1: warning: "EE_LAYOUT" redefined

7

eeprom.h:141:1: warning: this is the location of the previous definition

8

9

motor.c:518: fatal error: opening dependency file .dep/motor.o.d: No such file or directory

10

11

compilation terminated.

12

make: *** [obj/motor.o] Error 1

When I manually created the dep directory, the .o files where created 
and at the end I ran into the next prob:

1

Creating Extended Listing: hr20.lss

2

avr-objdump -h -S -z hr20.elf > hr20.lss

3

      0 [main] sh 2704 sync_with_child: child 1272(0x1EC) died before initialization with status code 0xC0000142

4

  39803 [main] sh 2704 sync_with_child: *** child state waiting for longjmp

5

/usr/bin/sh: fork: Resource temporarily unavailable

6

make: *** [hr20.lss] Error 128

so I changed the "shell mkdir $(OBJDIR) 2>/dev/null" in the makefile to 
"shell mkdir -p $(OBJDIR)" and everything compiles.

2 error 128 messages remain:

1

Creating load file for EEPROM: hr20.eep

2

avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \

3

    --change-section-lma .eeprom=0 --no-change-warnings -O ihex hr20.elf hr20.eep || exit 0

4

      0 [main] sh 7732 sync_with_child: child 320(0x1E0) died before initialization with status code 0xC0000142

5

  44365 [main] sh 7732 sync_with_child: *** child state waiting for longjmp

6

/usr/bin/sh: fork: Resource temporarily unavailable

7

make: [hr20.eep] Error 128 (ignored)

8

9

creating Binary for use with bootloader

10

avr-objcopy hr20.elf -S -R .eeprom -R .fuse -O binary hr20.bin

11

12

Creating Extended Listing: hr20.lss

13

avr-objdump -h -S -z hr20.elf > hr20.lss

14

      0 [main] sh 1180 sync_with_child: child 8196(0x1E0) died before initialization with status code 0xC0000142

15

  41663 [main] sh 1180 sync_with_child: *** child state waiting for longjmp

16

/usr/bin/sh: fork: Resource temporarily unavailable

17

make: *** [hr20.lss] Error 128

18

Build failed with 1 errors and 24 warnings...

if I do the eeprom generation in cmd(no admin) it works:
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" 
--change-section-lma .eeprom=0 --no-change-warnings -O ihex hr20.elf 
hr20.eep  || exit 0

Richard G. wrote:
> /usr/bin/sh: fork: Resource temporarily unavailable

I don't use win10, so I can't check, but quick google found this:
http://www.avrfreaks.net/forum/windows-81-compilation-error?page=all
Does not look OpenHR20 specific though.

- first probs where beacause of the PATH variable where I had the winavr 
tools not at the beginning

- sencond prob is because of an old dll (for W10 I found a dll for 
vista)
C:\Program Files\WinAVR20100110\utils\bin\msys-1.0.dll has to be 
exchanged
http://www.avrfreaks.net/forum/windows-81-compilation-error?page=all

Did somebody changed the library to support rfm69?
Thanks