@jdobry:
very busy weekend! gonna try your latest release tomorrow when i have a 
JTAG-adapter again.
gonna give you feedback about how the firmware works.
will try to get familiar with the general firmware architecture then, 
for example questions like "how can i issue a task evry sixty seconds" 
which shall be the RFM's staus broadcast in sooner future...
so long!

Hi Jdobri!
(what is your first name? I dont know if "Hi Jdobri" is correct ;)

ok, ive downloaded the OpenHR20-rev 103 and started to play with it...
I will try to integrate a RFM status sender for first approach.
I can say now, i will have to make changes in several files. For example 
main.c in
  if (task & TASK_RTC) { ... if (RTC_GetSecond() == g_RFM_devaddr) ...
and so on.
I would try to encapsulate all RFM-stuff  in #ifdef RFM-blocks, so a 
project-fork wouldnt be neccesary.
But im not sure if i can guarantee that it will be possible to 
distinguish RFM and notRFM-code clearly in all future.
So, what do you want to do?
Can you give me an SVN-Account for the project? Im sure you will be 
anoyed very soon if i start to mail you my code all the time...
So, tell me your plans!
Greets from Munich,
Mario

PS: First Request: I'd like to have the global variable uint8_t 
g_RFM_devaddr to be adjustable by menu (1-254, others reserved for 
broadcast or future usage) and storable in EEPROM.  Since youre master 
of the menue it shouldnt be too difficult? ;)

Question about the Config-Menue:

Did i get this right?
I can edit the Variables in eeprom.h via:
1. Pushing [AUTOMANU + TEMPSUNMOON + PROG] for 3 seconds.
2. Then display shows XX:YY, ourbar shows all bars, XX blinks
3. with the scroller i select variable number XX, then i push [PROG], 
then YY blinks and i can set XX's value (within the range given in 
eeprom.h).

now its getting unclear: it looks like if i push [PROG] i'm back in 
selecting a XX again. is the other value now stored? or how can i cancel 
it (i guess via AUTOMANU] )? and what's happening if i push 
[TEMPSUNMOON] ? hourbar except one bar blinks, scroller selects a 
horbar, XX:YY shows thigs i dont understand...
[AUTOMANU] always exits eeprom-edit-mode?

regards!

Feature Request:

in normal mode, [TEMPSUNMOON] shows current temp, valvepos, RTCtime, 
default display. i think that the RTCdate would also be interesting for 
a common user.

regards!

RFM Pin wiring:

you wired yor RFM like ths:

rfm_sck  = atmega169_pf1 //solder direct to atmega :-(
rfm_sdi  = atmega169_pf0 //solder direct to atmega :-(
rfm_nsel = atmega169_pa3 //solder direct to atmega :-(
rfm_sdo  = atmega169_pe6 //crop via on backside of PCB as shown in 
picture
rfm_nirq = open

as discussed yesterday, rfm_nirq = open, because rfm_sdo can serve as 
irq-notifier. we will read the sdo-state after we drove rfm_nsel low.
i assume that it will be high when the rfm is still busy sending, and 
edging low when ready (irq-event like "byte sent over radio in txmode or 
fifo-filled in rxmode). we need to clarify when we go into the sleep 
mode then and how we wake up/resume in main-loop.

... ive looked once again on pCB and schematic, it really looks like 
that there is no other way than soldering 3 pins directly to the 
atmega169? this is really a VERY sophisticated soldering job.
is it possible to disable the atmega's jtag-interface during runtime 
only?
that would make the soldering job really easy, we could even wire the 
RFM externally so that people dont have to open the HR20. of course, 
disabling jtag via fuses requires a working bootloader and is (as far as 
i know) not reversible...
are there any alternatives than soldering to those tiny nasty 
atmega-pins?

Hi,

disable JTAG:
i have googled it but couldnt find something useful. the only rumor i 
read was that "disabling JTAG at runtime doesnt mean setting the 
DisableJtagFuse" which would be very good because this could really 
cause trouble when the frmware crashes and cant execute any "ReEnable 
the JtagFuse again" command.
do you have a sniplet how to use JTAG-Pins as IOpins at runtime without 
messing with the fuses?

I would like to get this working soon, because i cant solder my RFM to 
the Atmega's pins directly - these ones are too small for me :(

Idea:
Is a "mixed version" of RFM wiring (JATG vs. internal pins) possible as 
well?
That eans using JTAGpins<=>RFM except RFM's nSEL, which we wire to PE6 - 
that is the pin that is reachable by cropped via on PCB, so its possible 
to solder.
Idea:
In JTAGmode PE6 is HighZ => RFM's nSEL is not tied to GND and not 
SELected => RFM's other pins should be HighZ (gotta look that up...) 
which means the RFM shouldnt disturb the Programming Traffic between 
JTAGprogrammer and Atmega => no need to unplug the RFM when JTAGging.

Security:
I checked in a security.c module. mainly uses XTEA (yet written in C) 
for en/decryption in cipher feedback mode. has the nice side effect, 
that we dont need the code for XTEA-decipher (see 
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher_feedback_.28CFB.29 
).
i also abused the XTEA-code for a hash function in for 
chall-resp-authentication. code not yet tested but function interface 
shouldnt change.

Hi!

Disable JTAG: ok will check that register in the atmegas manual. thanks!
mixed wiring: yes youre right, JTAG-firmwareupload is possible (if RFM's 
pins are really HighZ when nSEL=High) but debugging is not possible.
i think it's ok as it is - you can use your directly soldered pins and i 
the JTAG (and cant JTAGdebug, but i dont need that often).
its just pin definitions (see my rfm code its completely adjustable with 
some #defines).

security:
dont worry about the syncing! the CFB resets with every sent-out 
datagram again. it is just feedbacking within one datagram. otherwise it 
would be impossible for a receiver who was offline for several datagrams 
to resynchronize. id suggest this data format:

payload = [rand,currtemp,wantedtemp,valepos]
enc_payload = security_encrypt(payload)
packet_nocrc = [deviceID,enc_payload]
length = sizeof(packet_nocrc) + 1 // + 1 for crc
crc= crc8([length,packet_nocrc])
rfm_send([length,packet_nocrc,crc])

if you want to you can encrypt the deviceID as well. but point is that 
we must use additional crc for checking air damage (crc is better for 
that than any hashes). rand is a random number that "salts" our 
security_encrypt => equal payload (except different randoms) will 
produce completely different enc_payloads. so its not possible to create 
a codebook. this salting rand could be also used for chall-resp-authes.

i was just thinking ...
do we need a hash-function at all?
if the master authenticates via sending the rand value back within an 
encrypted message, then the master has proofen that he knows the shared 
key.

so scenario:
1. hr20 status broadcast every minute
(length,devID,encrypted[rand,currtemp,wantedtemp,valepos],crc)

2. master receives that, decrypts packet and has rand in plain format.
when master wnts to send a command to the HR20 he sends (within one 
second after HR20's broadcast):
(length,devID,encrypted[rand,CommandTotheHR20],crc)

3. HR20 unpacks that datagram, checks rand, and if it is equal to the 
rand from (1.), CommandTotheHR20 is executed

4. HR20 sends back
(length,devID,encrypted[ResultCommandTotheHR20],crc)

5. HR20 listens another second for a further command (again with rand 
included), and if not occuring, HR20 waits a minute till (1.)

what do you think? rand is encrypted in all air messages and different 
in every (1.)

Hi!

well, SPI is not the problem, the SPI-function itself is very very fast,
Problem is as discussed the waiting between SPI and SPI.
if you could write some code where i could integrate something, would be 
fine!

Air-Protocol: In my implementation i had an additional byte "flags"
with several useful values (contains ReceiverAddress, LoBatt, 
IsEncrypted...).
I left that away in my sketch but a concrete implementation will contain 
sth like that.

"1 second" is of course a too long time period. we could shorten it.

Dont let us mix up all those SYNCS: you meant the sync-pattern the RFM 
sniffs to
(and when he detects it he loads everything following into the RxFIFO) -
Yes the Sender must Send Sync and 0xAA0xAA-Preamble before (and trailing 
0xAA as well!).
i also left that away in the sketch for keeping it simple.

Commands: yes com-proto-reuse would be nice but ascii-over-air makes 
datagrams too long -
too dangerus. we must compress/binarize it somehow. also sending 
multiple commands
without delimiter if fixed length in one packet is good - then we can 
leave away the relisten for one second
from step 5.
Ok, gonna handle your latest post with security leak now...

Hi

i was quite busy in the last days, so i had no time to answer.
I don't have much time, but my business is embedded security.
Also i am often in das-labor.org, which is located near my home
(about 5 minutes walk)

Mario Fischer wrote:
> do we need a hash-function at all?
> if the master authenticates via sending the rand value back within an
> encrypted message, then the master has proofen that he knows the shared
> key.

Encryption != Authentication.

I will show you the error in your proposal:

An Attacker would receive from HR20
> (length,devID,encrypted[rand,currtemp,wantedtemp,valepos],crc)
He is not able to dencrypt this, but the master will anser e.g.:
> (length,devID,encrypted[rand,CommandTemp=20],crc)
Note: the attacker is not able to dencrypt this.
But he can se, which part of both encrypted parts is the same.
So he knows enc(rand).

Now what the attacker can do some days later:

The HR20 sends:
> (length,devID,encrypted[randnew,currtemp,wantedtemp,valepos],crc)

The attacker can replay the old command:
> (length,devID,encrypted[randnew,CommandTemp=20],crc)

There are many ways to avoid this. This can be done by using different 
keys for encryption on both sides (key_H2M: HR20=enc Master=dec, 
key_M2H: Master=enc HR20=dec).

Better it would be to use a MAC like CMAC[1], which can be done with
the Block-Cipher.

If you have some requirements, i can assist you in designing the 
secutity functionality.

For cipher i would consider to think about using XTEA. Alternatives are 
AES (about 1000 Words) or (better) PRESENT [2]. PRESENT is optimized
for very small hardware, but I think it should also be quite small on
the AVR. Nevertheless also XTEA would be OK.


[1]http://en.wikipedia.org/wiki/CMAC
[2]http://crypto.rub.de/imperia/md/content/texte/publications/conferences/present_ches2007.pdf

Hi guys,

ok im also thinking about the auth&encrypt stuff again.
some facts:
- we already decided for XTEA, seems secure "enough" (yes sounds sleazy 
but code must be short => XTEA is excellent trade off)
- and we cant use long keys, digests or random numbers over air since 
radio packets MUST be short. the counterpart to short key is that our 
"slave" only accepts auth-tries every minute at all, so we must primary 
defend offline-attacks.
- the amount of packet-ping-pong between auth/chal/comd/reply must be 
short for battery.
- we can not use any circulating P[n] -> P[n+1] tokens because master or 
slave can be offline for a while. Token or n might get lost.
- yes encryption alone doesnt replace auth or protects from playback.

let me ask you guys again about the leak here, i still dont see it:

1. Slave sends (simplified):
Encrypt( [rand1,statusinfo] )

2. Master sends
Encrypt( [rand2,rand1,command] )

3. Slave sends (if rand1 was recognized)
Encrypt( [rand3,rand2,result] )

i agree with dario that attacker could see enc(rand).
so i putted a rand2 on start of message in 2 which will scramble all the 
rest of the packet (->CFB mode) (lesson learnd ;)
beside, even if the attacker could catch a rand/enc(rand)-pair, then he 
couldnt offline-calc the key: rand is shorter than the key so many keys 
would produce the same rand.
and the attacker would have to run thru the key-span (big) and not thru 
the random-span (small).

ok, whats the weakness in this protocol?
we have lots of power/packetsize/battery/pingpong-constraints guys, we 
must keep it simple!

Another thing:

to distribute the keys in HR20 (Slaves) and Master
we should think about the possible solutions:

a) Keys are compiled in the Software
b) Keys in EEPROM
   - can be entered using serial interface
   - can be entered using Service mode

I would prefer to enter the keys in EEPROM.
For maxium Security the key must at least 64 Bit,
better 80 Bit. So it would consume 8 to 10 Bytes
in Configuration Memory.

A key exchange between Master and Slave is only
possible, when we would use asymmetric functions
like Diffie-Hellman. All other key exchanges are
not secure, when they all use the same (master)key
for all HR20s.

Dario

@dario:

key distribution: already done. its stored in eeprom and
changeable via HR20's LCD/Button/Wheel-interface.
Jiri did a great job with his extensible interface!
=> key distribution is no problem.
i coded the keysize variable length. if shorter than xtea-key it will be 
padded (no user wants to enter a 16-byte key in every HR20 so i think 
padding is ok. it's not home-banking ;)

i think i see now the point you wanted to show with your "a few days 
later":
but thats a tradeoff we have to accept: if the rand is only one or two 
bytes long than it will some day repeat. again a trade-off for 
short-radio-packets.
but even if the attacker has an old packet with matching rand. then he 
could inject a packet of which he doesnt know what it will do.

@dario:
if you are interested, you can look at the current state-of-the-code in 
the

http://openhr20.svn.sourceforge.net/viewvc/openhr20/rfmsrc/

branch of the project. new files are rfm.* and security.*
security is as mentioned still in a draft state.
i will think about the "do we need hash function if we have 
symetric-cfb-encryption?" again... i still think we dont need hash 
because cfb-enc kills all plain-cipher-pair-recognition-possibillities 
...

Mario Fischer wrote:

> let me ask you guys again about the leak here, i still dont see it:
> 1. Slave sends (simplified):
> Encrypt( [rand1,statusinfo] )
> 2. Master sends
> Encrypt( [rand2,rand1,command] )
> 3. Slave sends (if rand1 was recognized)
> Encrypt( [rand3,rand2,result] )

I think you gonne send many data, which is not needed.
You saied, that radio packets MUST be short.

1. Keysize does not affect packetsize.
2. How long would your random mumbers be?
3. I think there are many better solutions,
   when we think a bit about it.
4. Security can be added later, you can implement
   2 Dummy functions on each side generate_msg and
   verify_msg, which can be filled later.

I have to think about it, but for me it seems to be
a "Homebrewn" sollution which is not the best we
can have.

Also XTEA is very old, PRESENT is much newer and provides
better security. I think it should not be bigger than XTEA;

> we have lots of power/packetsize/battery/pingpong-constraints
> guys, we must keep it simple!

I Agree, but we should keep it smart, and simple.
And in your proposal i see that many random numbers are send,
which leads in big overhead, at least double rate

1

                Overhead 

2

              ============

3

                Security

Let me ask a Question, befor i start to think about
a better solution:

Who is the Master?
- How much memory
- What computational power

If the HR20 shall talk to each other without a master,
than we have a problem. If not i think that the Master
can recover missing sync information, so that we don't
need to send the useless rand information. We would
need to send some additional Bits (32 to 80) for
authentication.

But I have to think about it.

Dario

Mario Fischer wrote:

> i think i see now the point you wanted to show with your "a few days
> later":

No, when a few days later another rand (randnew) is send, i can replay
the old command, which was the response to the old rand.

I think when we use 1 or 2 Byte rands, than it is better to use
no security at all, because it can be very easy broken.

But I think by adding 4 Byte additional data to the frame, than
we can get the security of 4*8=32 Bit and by adding 8 Byte we have
64 Bit security.

But i have to think about it, i will write a purposal document for
security when i am not so busy (during the holidays).


Dario

@dario

- i diddnt know PRESENT but a first google shows me that it has s-boxes 
... thats way to expensive!
- xtea is old, but look at known weaknes of it ...
- are there any other well-known and analyzed algorithms as short as 
xtea?
- no hr20-hr20 communication.
- only hr20->master->hr20 talks
- master ... dont know... a linux-box, a atmega32, ... but doesnt play a 
role: the computing-power-bottleneck is the HR20.
- random number lengths: i would guess 1 or 2 bytes. i know its short. 
but be realistic: anyance over a shorter living battery from long radio 
packets is more likely than someone who records about 256 or 65536 
commands (there is NOT a command EVERY minute!)

> But Dario is right, we cant repeat same data with 2 packet with same
key.

do you really want some session-key-generation-protocol? this requires 
lots of traffic!
the whole send encrypted random vice and versa is not my idea. i thik 
its occuring similar in kerberos (let me look it up) but its not my 
invention...

Jiri: im still trying to understand your post from 09.12.2008 23:48 -
could you summarize that all a little please?

how many transmissions each minute?
what is transmitted in every packet?

and im still insisting, that after one minute everything must be reset.
there may be no references to any randoms or packetkeys that occured one 
minute before.
master or slave can be offline always and the other doesnt know it!
so after one minute, everything has to start from scratch.

so long guys, i fall asleep now!

Mario Fischer wrote:

> - i diddnt know PRESENT but a first google shows me that it has s-boxes
> ... thats way to expensive!

Yes one 4Bit-to-4Bit S-Box = 16 Byte.

> - random number lengths: i would guess 1 or 2 bytes. i know its short.
> but be realistic: anyance over a shorter living battery from long radio
> packets is more likely than someone who records about 256 or 65536
> commands (there is NOT a command EVERY minute!)

But when we use 1 Byte an attacker needs 128 tries for the chance
of 50% to change the next random number and so to destroy any
further communication.

The attack is on: Encrypt( [rand2,rand1,command] )
The attacker would send some random data, to the HR20 as response.
When the HR20 decrypts this data and the second byte is accidently
rand1 (which is 50% for 128 Tries), it would save rand2 as new value, 
which the master (and the attacker) does not know.
=> After that no further communication is possible.

I will think about a solution to provide security with additional
4 to 8 Byte each packet.

> do you really want some session-key-generation-protocol? this requires
> lots of traffic!

I asked how the keys will be distributed, as they are in the
EEPROM this is not an issue anymore.

im almost in bed, but let me shot comment
> destroy any further communication.

thats why i insist on "reset everything every minute"
destroy any further communication would otherwise also be possible if 
only one minute's session fails - then both wouldnt be synced.

let me clarify: all my rand0,rand1,2,3.... are diced every minute from 
new!

in general, it is always possible that an attacker records a packet and 
playbacks it every minute - after latest 256 or 65536 minutes it will be 
considered as valid.
i can accept the threatof such an scenario, since long packets are very 
battery-consuming. i measured the rfm's current consumption during 
sending with shunt+osci, thats why 4byte-randoms are too expensive to 
me.

Open: The firmware's source code including encryption algorithms is open 
source. The encryption key is selectable by the user.

Encrypted radio Traffic is to protect your HR20-valves from unauthorized 
people to control your room temperature or even detect from outside that 
your room temperature is cold (so you might not be at home and they 
could break in).

No fundamental discussions about "who is interested in controlling my 
valves?" please! Protecting the system is not much code but always worth 
some thoughts about!

Guys, one Question:
If our radio packets are always smaller than a XTEA blocksize, then the 
whole CFB or OFB modes dont make sense:

Because in both modes, the first plainblock is just XORed with 
XTEAencrypt(Key,Initvector).
This means that the whole plainblock is just XORed with a constant 
bitpattern.
This would mean that even one captured Plain/Cipher-Pair would disclose 
this constant Key.
So i would suggest CBC mode or no modes at all if all radio telegrams 
are < 17 bytes (what i would recommend). on the other hand, telegrams 
smaller than 16 bytes would have to be blown up to a XTEA-block.

Hi Jiri and OpenHR20-Team,
today I managed to make the HR20 send a radio frame with the RFM12 
Module connected to the outside-accessible JTAG-Pins and PE2.
Well, almost -
I saw that quite often bytes are swallowed. For testing i let the HR20 
send a bigger frame with increasing bytes
<preamble> <fifo start patt> 0x01, 0x02, ... 0x13 <dummy byte>

on the receiver side i saw things like
0x01 0x02 .. 0x04 0x50 0x60 ...
                    ^^

in other words, sporadically swallowed bytes or nibbles and some noise.
Im quite sure its not the receiver which is swallowing the bytes, this 
device im using for long time and it always worked.
I also looked at with the scope to the distances between the 
SPI-16bit-Trains, their distances were not equal!
I suspect rather that the SDO line indicates the "ready to send next 
byte" (TX flow control) event to early, multiple times, ... or the 
InterruptRoutine sensing for SDO Edges somehow raises the "send next 
byte" codition too often or to early ...
Im not sure where the problem is. In my other applications, I flow 
controlled always with the IRQ line, which works fine.
The RFM datasheet tells us that the SDO line also is usamble for flow 
control, so we want to use this line (to save IOports).
For test purpose i will connect the RFM's IRQ to the ATmegas IRQ (PE6) 
and check wheather this is the cause of the stumbling TX flow control.
But im not sure, could be many sources
SDO not relieable for Flow Control,
OpenHR20's PinCHange-ISR has an error
main-task-loop has an error.

Updates will follow ...

@jdobry:
meanwhile i looked a little closer at the distances of the 
SPI-RFM-SendByte-Commands. I let every time such a write-command occured 
toggle a pin and looked at it with the osci, and their distances looked 
good.
im not sure if the problem is in the receiver. it might have been false 
what i wrote in my last posting, sorry. but i will test it a little more 
today and know more.

Full-Stroke-Issue:
I have a general question:
The HR20's Manual sais, that the HR20 knows a Default and a 
Full-Stroke-Mode of turning the Valves off and on. When coming out of 
the Box, HR20 is in Default-Mode. What is the use of this so called 
"Default-Mode"?
I thought, the HR20 works like this:
* When HR20 is screwed on Valve (detected by switch), then ...
* HR20 turns on Motor to rotate left,
  until the light eye doesnt pulse any more (gearwheels block)
* Set a lighteye_pulsecounter=0
* Turn on Motor to rotate right,
  until light eye doesnt pulse anymore and count pulses in between.
  Then set lighteye_pulsesmax = lighteye_pulsecounter
* Now the mechanic is in a defined state (valve=100%)
  and we know that
  [Valve0% .. Valve100%] <=proportional=> [0 .. lighteye_pulsesmax]
  Which this knowledge and pulsecounting,
  we can put the Valve to any % we want.

I guess this is the full-stroke mode. So, whats the Default-Mode?
What would be the meaning/benefit of it?
Whats the use of having a water tap that you dont open or close 
completely?

@Jiri:
My Description of the Valve-Calibration - is this like your Calibration 
Algorithm? And if so, how do the described Phases correspondend with 
your "C-1" "C-2" "C-3" Calibration Messages?
Your Code looks like if there is a "Manual Calibration" and a "Auto 
Calibration", but i couldnt find out when which mode is driven, and 
what's Manual at the manual Calibration.
And what are you working with PWM with the Motor?
I thought only the direction of the Motor is important when Setting a 
Valve-Position (which is selected by the 4 H-Bridge Transistors next to 
the Motor i guess), but why is Motorspeed interesting?

Could you tell us some words about these things? We will need this text 
snipplet later probably for the User Documentation.
Thanks!
Mario

Hi at all,

today I finished the first (Christmas) release V 0.2.2.25740 for the 
openHR20 Suite which allows comfortable managing of the module settings.

Since I was very busy adding functionality, not all things are well done 
and some problems may arise (if you find some, please report).

The SW is based on .NET Framework 3.5 and uses WPF instead of Windows 
Forms windowing. It was developed on a Vista notebook but should also 
work with XP. The 3.5 .NET Framework is not contained in the installer. 
If you don't have it already installed, you must obtain it from MS.
Basically WPF GUIs are very pale but the design can be changes 
tremendously. If anybody here has Expression Blend and has experience 
with good design, may contact me.

Only one hardware platform was used, so I can't say which problems may 
arise on others.

Unzip the attached setup and install the SW. Connect the HR20 via serial 
Port (or USB to Serial adapter as I did it), choose the correct COM Port 
and connect to it. You may read or set all/single Timers or Eeprom Data 
and save/load it to/from a File. You can also send manual commands, sync 
the date/time with the PC or log the traffic to a log file. The other 
functions are self describing I think.

The SW works with REV 103 of the HR20, but may also operate with elder 
versions.

Have fun with it.

Karim

A picture of the user interface is attached. At first I would like to 
make the SW stable before I add functions if I don't lose mood (e.g. 
script executing, graphical data logging, several Tabs for each 
connected module, connection via WEB Service, and what ever ideas 
comes).

Wow this looks good!
Will try it soon!
Karim, could you assure in your code, that the COM-port-stuff is not too 
much nested to the GUI-stuff.
This would make it easy to port your application to wireless HR20 
control.
Would probably require some Addressing-Layer in your Programm.
Communication would the go to a "RFM-Gateway"
(= FTDI<=>Atmel<=>RFM), which would probably not be totally transparent 
to your Programm.
The RFM-Gateway could do of course the HR20-comm totally transparent 
(especially since FTDI is a Comport) but a more generic firmware in the 
Radiomodem could make it a litte more flexible (use it as 
remote-therometer-receivre as well etc).
But your Screenshot looks good! Will try it soon, wish i could code in 
.NET ;-)

I wrote a short Status-Update about the Wireless-Branch in the Project's 
Artice Page.

http://www.mikrocontroller.net/articles/Heizungssteuerung_mit_Honeywell_HR20#The_Wireless_HR20_Branch

(@Jiri: sorry it is in german, but it contains nothing you do not 
already know anyway)

@Mario,
the COM Interface is placed in an one class. I will add an SW interface 
to it, which all communication classes has to implement, so that a 
seamless integration of any interface will be possible.

@Jiri,
the Suite is for me also an interesting technology project, since I have 
not written until yet a WPF application and I did like to use other 
technology stuff like reflection, data binding, user controls, which the 
.NET Framework offers, because I will need it at work next year.
- MONO is always behind the latest technology. It takes a while until a 
full implementation is available but if I interpret it right, as I even 
so they offer already the .NET 3.0 function set. I reduced the level of 
.NET in the project to 3.0 and until some minor changes, it works as 
before.
So the next release will require only .NET 3.0. Hope this helps for the 
Mono user. But I have no experience with Mono.

- The code will be made public after I have added comments and 
reorganized the code a bit. May I add the code into a new folder in the 
SF openHR20 project? Would that be ok for you?

- The size of the windows is currently fixed, because I don't know how 
to change it yet. It is different from Windows Forms but I think still 
not difficult. But that is on my list for change as soon as I know how 
to do it.
What monitor resolution do you use. My one has 1680x1050 and I can read 
it well.

Windows is the most used OS platform and .NET is quite powerful. Since I 
know how to program in .NET, it is the fastest way for me with 
acceptable effort to get a complex program although it is still a lot of 
work. And with Mono, even if it might not be possible yet, will open the 
door for other platforms. Hope you can live with that point of view.

@Frank,
the level shifter would allow to connect the RS-232 in parallel, but a 
special protocol would be required for communication which the I²C Bus 
(TWI-Two Wire Interface) has already implemented (master/slave, clock, 
addressing, collegian handling...). But in principle not a bad idea to 
use a level shifter plus a special protocol. I have also installed a 
cable ring to all heaters but planned to use I²C bus. The Atmel 
controller supports I²C bus. And the nice thing is, the needed TWI Pins 
(SCL (same as TCK, pin 4 of the connector), and SDA (TMS pin 3)) are 
already routed to the module outside connector. What we need is an 
interrupt routine which roots the traffic and at the PC a TWI to Serial 
or USB converter. An additional option is the 3 wire USI connection. But 
Jiri might be right, that long wires can be a problem for the signal 
edges although the overall speed can be as slow as wished. We will see.

The temperature can be set in the eeprom block (temperature0-3), but it 
is not a nice way because of the required calculation of the necessary 
value. Also missing is the possibility to assign this temps to the 
switching time. I will add both later.

Idea: PE2 is free to use and avail on the connector. I'll try to connect 
it to a PIR motion sensor.
If there are some events (PE2 is PCINT1 and can serve as an interrupt 
source) within a given time, the room is known as used and the 
temperature will be set to "comfort". If no motion is detected, 
temperature wil go to normal value given by timer.
I will modify a cheap motion detector whith a relay.

I think i will need a timer for it - Timer1 is not used yet?

By the way - how are you using the simulator? Is it possible to simulate 
the switches too? I only reach "E2" due to PB0 is always going back to 
0.

Hello Jiri and all,

in my holidays I modified the code to work with the Thermotronic 
thermostats. I did this by using #if - #endif stuctures to make the code 
working for HR20 as well. Maybe you want to include my modifications in 
the SVN - a new branch should be unnecessary.
The important differences between HR20 and Thermotronic are:
-different pins for switches etc. (scheme of TT can be found in another 
thread)
-no enable-pin for motor-pwm
-hardware USART used for motorencoder (so i actually disabled all debug 
functions)
-different thermistor - I modified the values but I´m not sure they are 
correct. Maybe the have to be updated in future. The Thermotronic doesnt 
show the measured temp so I cannot analyze as described in doc.

Thomas

Hi,

first I want to thank you for creating this project! I do some 
home-automation and this is just what I was looking for.

Yesterday I bought me a HR20, connected my spi-programmer to the 
corresponding pins and set the fuses to l:0xe2, h:0x9b and e:0xfd.
Then I uploaded the firmware I compiled out of the current SVN rev. It 
worked immediately but very unstable (random hangups). So i took the hex 
and eep files from the repository and it works like a charm.

Do you have any idea why my self-compiled version fails? I used the 
Makefile from the repo with only one little modification: my avrdude 
doesnt know the atmega169p so I hardcoded the atmega169 for avrdude (not 
avr-gcc).
Environment is Linux with avr-gcc version 4.3.0.

Best wishes
Björn

Hallo!
Das hier ist ja mal höchst interessant. Bin mittlerweile auch im Besitz 
eines solchen Reglers.
Ich habe verdammt lange nichts mehr mit einem AVR gemacht!

Wie bekomme ich mein Rondostat umprogrammiert?
Mir steht ein STK500 zu Verfügung. So wie ich das hier gelesen habe kann 
ich das ganze nur mit einem JTAG programmieren, den das STK500 nicht 
hat?

Bekomme ich das doch noch recht spontan programmiert?
Gibt es eine Schritt für Schritt Anleitung?

Gruß,

gammla

@gammla
Sorry, keine Anleitung bis jetzt - ist auch kaum möglich, da stark von 
dem vorhandenen Gerätepark abhängig.
Ich bin so vorgegangen:

1.) JTAG Programer gebaut. Ich habe dazu ein ATMEL-Eval-Board von Pollin 
angepasst. Anleitung findest Du bei Evertool-Light 
http://www.siwawi.arubi.uni-kl.de/avr_projects/evertool/#etlight Dort 
ist auch die Beschreibung, wie man die Firmware und die PC-Software 
beschafft und installiert. Achtung: Es muss ein anderer Quarz ins Board! 
Du brauchst auch nur den Teil fürs JTAG nachbauen - 1 Quarz, paar 
Widerstände, 1 LED und 1 Kondensator.
Die Steckerbelegung am HR20 findest Du in der Analyse 
http://carluccio.de/images/e/e1/Hr20-analyse.pdf. Ich habe 2 5-polige 
Platinenstecker benutzt, wie sie in PC für die Gehäuseanschlüsse oft 
verwendet werden.

2.) Aktuelle Toolchain für den Compiler installiert (Win-AVR) und 
danach das Atmel-Studio 4 (Nicht Studio 32!). Hinweise dazu auf der 
Seite von ATMEL.

3.) Das Repository mit den Sources geholt -> siehe dazu 
http://www.mikrocontroller.net/articles/Heizungssteuerung_mit_Honeywell_HR20#Subversion_Repository

4.) Anleitung zum Übersetzen und Übertragen im Repository unter

1

Open HR20\trunk\doc\Anleitung AVR Studio HR20.pdf

Das Device im Studio festgelegt als JTAG ICE.

Aufwand: Recherche 4 Tage (kannst Du Dir hiermit sparen), Löten 2 
Stunden, Software 3 Stunden (aber nur wegen der alten Version von 
Win-AVR).
Sieht nicht gut aus, tuts aber...

Hi,

I've written a little tool for the linux/*nix console to communicate 
with openhr20. It's very basic, just for my needs, but if there is 
interest, I will extend it. With it, you can set the current date/time, 
the wanted temperature and the mode. You can also get the status.
To compile it, you need cmake. If chosen this as it makes it easy to 
compile software for different architectures.

Björn

Ok the tool can now be found in the svn under tools/

Hello Jiri and Forum!

@Jiri:

PWM: could you explain a little about, what the use PWM in motor control 
is at all?
I thought, motor speed is not important at all because the valve 
position is not calculated by motorspeed (==PWM?) and motor's runtime - 
it is calculated (much more exact) by lighteye pulse counting - which is 
speed independant.
Could you tell me/us a little about meaning of PWM in motor control?

RFM: sorry, i did not have time for working with RFM last weeks. I hope 
i will find some time next week and/or the followings.

Hi Jiri,

ok the hex file from trunk/source 158 seems to work here. What log do 
you want to get? The output while adjusting or just any motor movement?

I still have the problem that my self-compiled hex does not work :-( 
Don't you have any idea what the reason could be? Which compiler version 
do you exactly use?

Bjoern

Hi Jiri,

thanks for your unrestless effort. Propably tomorrow I can send you a 
log file.

In rfmsrc you moved some files but didn't check in the appropriate AVR 
Studio aps project file. The Studio claims about missing files.

openHR20 Suite:

Unfortuantely MONO does not support WPF (only Windows Forms) and there 
are no plans yet to do so although parts of the community see high need 
for that (otherwise MONO is ded on the long run).
It would be possible to rewrite the Suite to run under Windows Forms 
instead of WPF, but since there is a Linux SW now available, it is not 
needed and the more flexible solution would be a WEB application.

Nevertheless I extended the Suite between christmas and new year and 
this could be released in a few days, if anybody likes to have it. New 
is a script sending feature (for ease use, can be derived from log 
file), the assignments of switching time and temperature (0..3) can be 
done now, the temperatures can be set with more comfort and a bug fix 
was done.
May I add the code to the SVN?

You have been right, the pins for TWI are not routet out, I did look at 
the wrong port. Using RS485 is a good idea.

@Jiri,

Yesterday I flashed REV 159, changed 0b to 32 and logged a calibration, 
window open/close and temp regulation over night. Log is still recording 
and I will send it to you in the evening today when I am back from work.

But what I found in the morning is, that the switching times I set are 
not used. I can set them and read them back which shows the correct 
values but they are not used. Is this a bug or is there anything else to 
set?

I have also a Thermotronic module and the code shows adjustments for 
this module which can be enabled per compiler switch. Is this 
implementation complete and does it work?

Regards,

Karim

Hi Jiri,

I will try to find out if the Thermotronic uses software PWM next week. 
At the moment i have less time. I hope I can finish my modification for 
new timeroptions next week, too.

@Karim: except for missing communication and missing PWM my Thermotronic 
works quite well. I think modification for RFM12 will be possible. The 
RX-Pin of hardware usart isn´t used, too. So maybe it will be possible 
to implement an unidirectional communication over RS232 for 
configuration and so on. Another solution would be a software-uart, but 
this would need much memory...

Thomas

@Jiri,

I don't think that manual mode is set, but may be you are rigth. I will 
check that later.

@Thomas,

Thermotronic schematic diagram can be seen here 
Beitrag "elektronische Heizungsregelung mit Thermotronic", but you may know that 
already. Would it be possible, to release tx pin an use instead one of 
PE4..PE7? It would enable full communication as HR20.

@reiffert,

this work is already done. Thanks to Jiri and Dario, the OpenHR20 SW 
allows 8 switching times per day and 4 temperatures they can be assigned 
to.

Ok, the original Thermotronic doesn´t use PWM. I think it is possible to 
change pinconfiguration to use hw-uart but you have to do changes on the 
pcb so I think this would be a solution for only a few people. A better 
way would be to use a rfm12 wireless connection.

Thomas

To integrate a rfm12 module, a user has to open the Thermotronic module 
an solder wires as well. Although it meight be a bit less complex than 
to cut a strip on the board and rearange a connection, still some 
wouldn't be able to do neither of both.

Here is an updated version of the hr20cmd tool. It has the ability to 
get and set the timer slots now.

Björn

Hello Jiri, Dario and the other guys from HR20 wireless!

I read Jiri&Darios Wireless Spec and have some annotations about it, i'd 
like to give now.

I hope it doesnt sound inpolite, it's for sure not meant that way!

Ok, nice evening!

*** ***

4.2. Sync Packets
Did i get this right? the Master sends regulary Sync-Frames containing 
the current DateTime every :00 and :30 second? (:00 is enough anyway i 
think).
Here i see a bootstrap problem:
If a slave hasnt a synced clock yet (regardless if he knows that his 
clock isnt synced), he doesnt know when the time Slot 00 occurs:
So he has to switch on the RFM receiver for about a whole minute, hoping 
he receives a Sync Frame, which is battery consuming and costing program 
space.
I would rather suggest, that a Sync-Packet is just a 
SETDATETIME-Command, the Master sends to the Slave,
after the Slave sent a BroadcastStatus packet (in his Timeslot with 
Second=OwnAddress).
Then the slave's clock can be synced as well.

I dont agree with your statement that Date&Time is needed for preventing 
replay attacks:
A Timestamp is worse for replay prevention than a random number.
4 byte MAC Code is totally overkill! This is wasting battery!
Beside, longer packets have a higher propability to get lost over the 
air.

5.2 Keys
I agree that it isnt recommended using Masterkeys in encrypted 
Communication.
But derived Keys like Kmac and Kenc make ONLY sense, if they are derived 
from the Master Key more than one time within the life time of the 
Masterkey!!!
Otherwise it doesnt have any impact on security.
If Kmac or Kenc is broken, Km is worthless as well!
I think you mixed that with the idea of session keys.

General Critic: The packets are too long, too many syncs from master the 
slave might not hear anyway, derived Keys that dont improve security.
A nonce derived from a datetime and a packet counter is predicatable!
A nonce = rand() is much better.
What is the CRT ? did you mean CTR?
Does all this fit into HR20 left codespace anyway?

Hello Jiri and OpenHR20 Team,
first of all, sorry if my comments on HR20 wireless spec were misplaced 
and sounded inpolite, both wasnt meant so!

today i checked out the openhr20 from svn and tested the rfmsrc-branch:
i could verify, that the (interrupt driven) RFM packet sending now works 
correctly, even for long packets (either my receiver was programmed 
wrong some months ago, or the old openhr20's sending code (non interrupt 
driven) swallowed some bytes), but anyway this looks good to me!
but i got one strange compiler message, saying that this code

1

 // rfm_config.h

2

#define RFM_INT_EN() (PCMSK0 |= _BV(RFM_SDO_PCINT), PCINT0_vect())

3

#define RFM_INT_DIS() (PCMSK0 &= ~_BV(RFM_SDO_PCINT))

creates this warning:
main.c:223: warning: implicit declaration of function '__vector_2'
it looks to me like a typo (PCINT0 is hard coded beside that) and i 
wrote

1

 // rfm_config.h

2

#define RFM_INT_EN()  PCMSK0 |= _BV(RFM_SDO_PCINT);

3

#define RFM_INT_DIS() PCMSK0 &= ~_BV(RFM_SDO_PCINT);

 instead, raising no warnings, and running correctly ...

until i mounted the valve for the motor calibration to start, which 
makes the HR20 reboot in infinite loop every few seconds. (reboot, 
running till blinking "2008", reboot, ...).
it also showed this reboot loop with #define RFM 0
could this be a consequence that moror control isnt via PWM?
any ideas? sorry i have no logs about that (yet).
regards,
Mario

Hello Jiri and the other guys from the 'development team'.

Fantastic project, the code worked more or less 'out of the box' for me. 
No problems with compiling and exactly the features added to the 
original code that I missed.
I have also been using the RFM12 in other projects and have tried that 
modification during the last days (external RFM12 connected via JTAG 
pins). After adding some code to get the necessary information like set 
value and measured value for temperature and the valve position sent via 
RF I can now at least log the data from one thermostat without cables or 
a notebook in the bathroom. I hope that this will help me to fix some 
problems I have with the regulation characteristics using the default 
settings.

I use two HR20 in quite small rooms (toilet ~3m² and bathroom~10m²) and 
the regulation with OpenHR20 and default settings works much worse for 
me than with the original HR20 firmware. When heating up in the morning 
(step from 15°C to 21°C) this happens much slower than with the original 
software but there is also a big overshoot. Than i quite often see a big 
permanent difference between set value and real temperature without any 
reaction on the valve setting. Strange, but as already said I will now 
first log the data before telling too much nonsense. And I know that 
these small rooms are very complicated in terms of regulation compared 
to larger ones. The doors and windows are also permanently (or at least 
quite often) opened and closed in these rooms and this makes everything 
even worse. But as already said, the original software seemed to handle 
this much better.

To correct problems like this or workon them, I first have to understand 
the code and function of the controller better.

One comment on the 'RFM' version: I have a blank display after some 
seconds only with this software. When changing the set value with the 
wheel, the changed value is displayed correctly again and then after 
some seconds it disappears again. The 'normal' version without RFM12 
works ok.

That's it for now, keep on the good work. And maybe someone has a 
suggestion, which parameters I could touch to improve the regulation.

BR,
Jörg.

Hello Jörg,

I can confirm, that the software does not regulate the desired value 
exact (about 0,8°C lower than set) and also it does not open the valve 
wide enough in my opinion to reach fast the desired temperature. In my 
30m² living room I have no overshot of the temp. The current setup might 
be ok for a large heater in a midsized room, but it is not optimal yet. 
Problem may also be the different valves (where is it completely open 
and closed?). The SW was optimized by Jiri for less movements and saving 
battery energy. Further work is required.
It would be good to have an algorithm, which adopts automatically to 
some parameter and may be also predict the temperature which will be 
reached on a valve setting. For that, a pulse response characteristic 
could help.
Open the valve 100% for a short time close it completely. Measure how 
long it takes until the temp rises, until it reaches the maximum and how 
it does fall. Calculate the mathematical formula and use it ;-).

Regards,

Karim

Jiri,
I am sorry, I simply do not have enough time at the moment. My logging 
attempts were not successful partly because I have problems with my 
circulation pump not working correctly (no, not with mine, but with that 
of my heating system :-) ).
When the pump works ok and the water temperature is not too high 
(dependant on outside temperature) the regulation with default values is 
not so bad, although I still sometimes (?) see permanent differences of 
nearly one degree like Karim.

One of the reasons why I want to have the RFM12 solution is, that I want 
the thermostats to do the regulation only when the circulation pump is 
running. And this is 'intelligently' controlled by my heating controller 
(Schäfer Domoxxx something). In times when the pump is stopped (variable 
interval at night with start time in the morning depending on outside 
temperature) the thermostats shall go into off position. The same goes 
for times when the pump is completely stopped due to high outside 
temperatures (programmable, set to >17°C in my case).

Regarding code with RFM12, I used your code nearly 100% and just added 
some extra bytes for sending set temperature, real temperature and valve 
position every two seconds. Worked ok more or less as I did not 'know' 
(or understand the code enough) that this software does not switch the 
temperatures to the preset values like the normal software does in 
automatic mode. It seems to be waiting for a master command to set a new 
value? So my remote (RF) logging attempts were not successful. Have to 
dig deeper into that code first (or wait for your solution :-) ).

BR,
Jörg.

Hello Jiri,

on last Sunday I flashed REV 180, but couldn't log long enough to make 
some effects clear. Today I discovered also a jump in the temperature, 
which I couldn't explain (within a few minutes from 16,76 to 17,26 then 
back to 16,76, 17,76, 17,30 and 16,82 which looked strange to me.

I have the feeling, that the temperature send to rs-232 and internally 
used are different, which could be the reason for the temp difference of 
about 1°C which I still can see.

When I increase the set temp from 17,5 to 18,5 °C the valve will be set 
to about 50 which still does not open the valve (at least not much) and 
even after 30min the valve will only be opened slightly to 52 or 53 
which is still not enough. As I have that logged more clearly I will 
send you a log.

Concerning a new regulator model, I have unfortunately no experience and 
would have to do a lot of experimenting and development work to get 
something reasonable to work.

Regards,

Karim

@Reinis,

since the eeprom data arrangement did change, the first openHR20 Suite 
release is not fully compatible. But I have a newer version, which I can 
offer next week (I will return on Monday evening home, so that hopefully 
till Thursday a new release can be provided). It has several new 
features and supports the latest eeprom layout.

Karim

Karim,
it seems that you activate RTS as well as DTR in your openHR20 Suite 
(both lines show ~+12V). Would it be a big deal to make these settings 
variable with maybe two check boxes?
I am using a 'standard' RS232 to TTL converter with optical isolation, 
which draws the power from the RS232 lines and needs RTS activated and 
DTR deactivated. Maybe I am not the only one with such a special wish 
:-)

BR,
Jörg.

Hello,

I'm new to this forum and I have been playing around with the new
firmware for the HR20E for some time. I just want to say that you've
done a really good job. But I've also found some minor problems:

- the parameter of the RTC_Setxxx functions has changed from int8_t
  to uint8_t. At least for hours and seconds this was not a good idea.
  The parameter can be negative if you set the values with the wheel
  and turn it anti-clockwise. E.g. for minutes you get the sequence
  01-00-15 instead of 01-00-59.

- setting of DEBUG_IGNORE_MONT_CONTACT to 1 doesn't work. In line 196
  of keyboard.c ( mont_contact= 1; ) the value should be 0. The 1 is
  forcing the E2-Error instead of ignoring it.

- After a reset setting of the year manually is sometimes wrong:
  If you don't touch the wheel and confirm the standard value of 2009
  with the PROG key the stored value is sometimes 2008 and sometimes
  2009. It depends on the current position of the wheel. At one position
  PB5 and PB6 are both LOW and at the next position both are HIGH. The
  variable state_wheel_prev is initialized with zero and so it doesn't
  reflect the HIGH values of PB5 and PB6. In this case when you press
  the PROG key a wrong KB_EVENT_WHEEL_MINUS is detected.
  I've found a solution for this but I'm not very happy with it.
  But here it goes:

  I've added the line

1

    state_wheel_prev = (~PINB & KBI_ROT1);

  to the end of the init function in main.c. It must go behind the
  call of task_keyboard() in order to not being overwritten. I've also
  defined state_wheel_prev as extern in keyboard.h.

Regards, Ulrich

Since I had my notebook with me and a bit time, I finished the next 
release  of the openHR20 Suite V 0.2.4.23954 today. See the readme.txt 
for the made changes after installation or the text below.

@Jörg, you may change the RTS/DTR signal state via the 
openHR20suite.cfg. Install the program, chut it, modify the new cfg and 
restart the program. Currently I did not like to add this settings to 
the GUI.

Report problems and errors please.

23.02.2009, V 0.2.4.X
Current day in switching time table has style bold instead of italic
With # in command window, comments can be added for better documentation 
of the log file
A detected open window will be shown in status bar
For com interface DTR and RTS signal state can be changed via 
openHR20Suite.cfg XML File.
Log File can be renamed as *.scp and used as script file
Readme.txt added to installation
New eeprom layout of REV 180 supported (Attention: Incompatible to old 
layout)
If an expected response is not received, an error comment is displayed 
in terminal

28.12.2008, V 0.2.3.X Not released
IsTemp progress bar is green when Target Temp is range +-0.5°C, below 
blue and above red.
Aktive day is shown in italic
Bugfixes on loading an saving data
Resizebale window, application starts with last size
Temp 0..3 can be set
Temp assignment to switching time possible
script execution added (see tooltip of command box)
Data names in data files changed -> incompatible

22.12.2008, V 0.2.2.25760
First release

Karim,
thanks, works perfect for me!!!

BR,
Jörg.

Hello Jiri,

I've tested your fixes and they are working for me. Thanks a lot.

Regarding your compiler question: I'm not a compiler expert but I've
found this one:
    Beitrag "Re: reihenfolge der bits in einem byte umdrehen"

In short, it states out that gcc is doing calculations in a way that
intermediate results are at least of type int (16bit). This is requested
by the C standard and casting the parameters to 8bit types doesn't
change this behaviour.
Another thing is that avr-gcc is working internally like a virtual 16bit
machine and treating with 8bit values is defined specially.
This could be the reason that your second example with casting of the
end result is working.

Regards, Ulrich

Karim,
I found some problems with your OpenHR20Suite, but maybe this is just 
because I do not use it correctly or I do not understand something.

If I read out temperature values, i get the reading 68:15 for empty 
entries (--:--) in the thermostat. If I enter --:-- in the program and 0 
0 for the temperature settings, the program just closes if I press 
'set'.
Next, if I enter new values directly in the thermostat and then read the 
timer settings again, nothing is changed on the screen. But the new 
settings are clearly present in the thermostat.

Any idea what I am doing wrong?

BR,
Jörg.

Karim,
now I see that you only show the timer entries for the individual days 
and not for settings the whole week (I use setting 1-7 on the 
thermostat). I thought that the settings for (1-7) would be copied to 
the individual days.

BR,
Jörg.

Hello Jörg,

thanks for the hints.

Week mode operation is not well supported in the program. That is one of 
the open points for the next release.
If I don't want to use a switching timer, --:-- is to be set at the 
module by the wheel. If I read then the time via program, I get x5A0, 
where x stays for the temps 0..3 to be used and 5A0=24:00, which marks 
not to use this switch setting.
The default in eeprom (see ee_timers in eeprom.h) after flashing is for 
not used switching timers xFFF=68:15 which is different from above after 
manual setting. 68:15 is not replaced by the suite with --:-- yet. And 
even worse, if you try to enter an invalid time, the program crashes. 
But I know that and in the About window I made a hint to not enter wrong 
values.

I plan to add a check for all entries and I would like to use masked 
text, but here MS made it not very easy to have a nice implementation. 
This subject is more complex to solve as you would assume and I need 
time to acquire a solution.

So don't enter an invalid time, only this range is allowed 
[00:00...23:59, --:--]. Don't try to set a displayed 68:15 red from 
device, because it lets the program crash.

You can switch from week to day mode by setting the timer_mode from 0 to 
1 in the eeprom data block.
The week times can be set via R00..R07 command. But I will make that 
available by direct setting in GUI.

@Jiri, is it required to have xFFF as default in ee_timers for not used 
switches and could this values be changed to x5A0?

BR,

Karim

@Jiri,

ok, I will do a fix for that in the next release.

Hi Jiri,
I still see some permanent differences in set value and real value 
without any reaction of the controller. Now I took a HR20 with newest 
firmware on my desk and waited until the real temperature reading 
stabilized to 18.32°C (with a set value of 19.0). Then I made some 
changes on the I value. But i do not understand the result. Do you have 
an explanation?

1

20:38:54.515> D: d4 26.02.09 20:38:54 A V: 51 I: 1851 S: 1900 B: 3312 Is: ff03  I value = 3 (default)

2

20:40:54.515> D: d4 26.02.09 20:40:54 A V: 52 I: 1845 S: 1900 B: 3312 Is: ff3a

3

20:42:54.421> D: d4 26.02.09 20:42:54 A V: 54 I: 1838 S: 1900 B: 3312 Is: ff78

4

20:44:54.421> D: d4 26.02.09 20:44:54 A V: 54 I: 1838 S: 1900 B: 3312 Is: ff78

5

20:46:54.421> D: d4 26.02.09 20:46:54 A V: 54 I: 1838 S: 1900 B: 3312 Is: ff78

6

20:48:54.453> D: d4 26.02.09 20:48:54 A V: 55 I: 1832 S: 1900 B: 3312 Is: ffbc  changed I value to 6

7

20:50:54.453> D: d4 26.02.09 20:50:54 A V: 55 I: 1832 S: 1900 B: 3312 Is: ffbc  nothing happens

8

20:52:54.453> D: d4 26.02.09 20:52:54 A V: 55 I: 1832 S: 1900 B: 3312 Is: ffbc  nothing happens, change I to 10

9

20:54:54.593> D: d4 26.02.09 20:54:54 A V: 51 I: 1832 S: 1900 B: 3312 Is: ffbc  valve closes!!!

10

20:56:54.593> D: d4 26.02.09 20:56:54 A V: 51 I: 1832 S: 1900 B: 3312 Is: ffbc  no change

11

20:58:54.593> D: d4 26.02.09 20:58:54 A V: 51 I: 1832 S: 1900 B: 3312 Is: ffbc  no change

I thought that increasing the I value would help the controller to get 
rid of the permanent difference by opening up the valve, but the 
opposite happens.
Ok, I wanted to watch this a bit longer, but after some minutes the 
automatic timer changed to 15.0°C and the valve closed down completely.

I am a bit puzzled.

BR,
Jörg.

Hi Jiri,

I will take a closer look at it at the weekend.

Don't worry about eeprom layout change. I do only have to copy the new 
Layout into my code, the rest is don't automatically per reflection 
mechanism. The only disadvantages are, I have to release a new version 
and that stored eeprom data in a file can't be used without problems.

Maybe I add a feature to load the eeprom structure from a file to have 
more flexibility for different versions.

If not already implemented, you could add a hysteresis, which allows 
lets say 0,2°C deviation before trying to regulate, to reduce motor 
movements.

And the Is value should be limited for keeping the contoller responsive 
even if it is what you call hijacked.

During the day (from 7:20 on), the wanted temp is set to 15,5°C, but my 
living room is always warmer, because of good isolation, solar radation 
and heat comming through the wall and floor of my neighbors ;-). The 
temp during the day can go up even in cold winter day to 21°C without 
having heater on. But in the evening it is getting colder, but most of 
the days not below 16°C when heater keeps off. Thats to cold for me. 
Therefor I programmed my controller to heat up to 17,5°C at 17:30 till 
midnight  which results in about 19-20°C where I sit.
Under this conditions the integrator will sum up to the rangellimit when 
wanted temp is 15,5 during the day and after midnight.

So far that to the conditions I have.

@Karim L.

I was try to add hysteresis which allows deviation before trying to 
regulate. But is was unstable solution. System was overregulated for any 
constant setting. (I can't remember if I commit this try or not, but I 
was try it)
I will try to use same "hysteresis" but only for integrator update 
condition. Do you remember to ">" or ">=" in my text from 2009-02-27 
10:35? We can use ">" around wanted temperature +- tolerance and ">=" or 
none condition outsite tolerance. I would be better.

Is value is already limited to (256*50/I_Factor). This mean that maximum 
effect is +-50% on valve. I can move this setting to EEPROM, but I don't 
belive that it is major problem.

PS: You have perfect conditions to "hijack" integrator. Well isolated 
room, where is external source of heat. And lower wanted temperature 
than natural in long time.

Jiri

"ffbc mean -68 decadic. If you increase I_Factor, valve must be closted,
see up to formula."

I see from the formula that this is the way it works, but does this make 
any sense? As you wrote, a negativ value means that the real temperature 
is lower than the wanted temperature. In this case Is becomes more and 
more negativ with time and the valve closes more and more. This is not 
really the desired effect. Is this a bug in the formula or a 
misinterpretation from my side?

BR,
Jörg.

@Jörg Becker
I thing that is correct:

ff03 is -253
ff3a is -198
ff78 is -136
ffbc is -68

Negative values can be calculated by (dec(value)-dec(0x10000))

Jiri

Jiri,
i know about representation of negative values. The problem is that your 
description in the mail from 10:35 is not 100% correct and is not the 
same as in the program code and that mislead me.

you wrote "e = error = current_temp - wanted_temp"
and that means that e is negative if the set value is higher than the 
real value.
Together with the term "Is+=e" this would mean that in my example the 
negative value of Is should get more and more negative, what it 
obviously does not do!

In the program code we find that:
"  error16 = setPoint - processValue;"
which has opposite sign than e
and
"  sumError += error16;"

which leads to the correct behavior that Is gets more and more positive 
over time if the real value is lower than the set value. So the code is 
correct.

The only problem is, as you explained, that you only change Is if the 
temperature value changes. So, in my example, if I only had waited some 
minutes longer and the temperature would have changed just a bit, Is 
would have become positive and the valve would have opened.

Thanks for your help to understand the code a bit better!

BR,
Jörg.

@Jörg Becker:

OPPS!
I was make mistake in my test. You are right. Correct error formula is

1

e = error = wanted_temp - current_temp

Jiri

@Thomas:

On receiver side you need another rfm12 and simple board with ATMEGA16. 
Sorry but I don't have better documentation than text specification in 
SVN now.

Jiri

Rev203 have improved integrator consequences. It can be less sensitive 
to ingegrator "hijack". Please test it.

***********************************************************
It is no fully tested now, last stested version is Rev 192.
***********************************************************

Hi Jiri,
I tried the new version with temp-tolerance set to 0.3°C and it works 
really nice for me. No big permanent deviations any more, that's good. 
Congrats!

I still have problems with my very small toilet room with oversized 
radiator. The temperature overshoots very much. One thing that helps is 
to decrease the PID interval (I have set it to 1 minute now). But I have 
no logging data, so I am still very uncertain about the effect.

After playing around with the various versions for some time now, I have 
one remark (not complaining, just asking for your opinion :-) ):
- After a reset (e.g. battery exchange) I have to 'type in' the whole 
date and time setting starting from the default value (01.01.2009). I 
would like it much more if at least the year, the month and the day 
would be stored to eeprom on every change (even for the day that means 
just 365 write accesses per year and the time and Ah needed are 
negligible). I have done this on a project where I want to be sure that 
after an erroneous reset (spikes, ESD) the system still has a date/time 
that is at least nearly ok. I also store the last hour value to eeprom 
and have the minute and second value uninitialized at startup (I just 
test if the value is reasonable, means in 0..60), so that in most cases 
I only loose some seconds.

BR,
Jörg.

@Jörg Becker:

Toilet room: without log I can tell nothing. But log from this extreme 
situation can be helpful.

Date in EEPROM: nice idea, you can me send patch. For me it is not 
significant, because I am use date/time setting  from wireless network 
(rfm12). But it can be useful for others.
PS: I haven't erroneous reset. Do you use batteries or external power?

Jiri

I am just going through the RTC routines:

1

bool RTC_IsLastSunday(void)

2

{

3

    if (RTC_DOW == 7){ // sunday ?

4

        return 0;  // not sunday

5

    }

6

    ....

shouldn't that be:

1

bool RTC_IsLastSunday(void)

2

{

3

    if (RTC_DOW != 7){ // sunday ?

4

        return 0;  // not sunday

5

    }

6

    ....

Regarding your question:
No, I did not experience resets with this project except during battery 
exchange.

BR,
Jörg.

@Jorg:
OPPS! Thanks for bugfix. You are right, it is bug.
Jiri

Just for your info, this is my (very simple) routine for RTC from one of 
my other projects:

1

void RTC_add_one_second(void)

2

{

3

   static const uint8_t days_per_month[12] = \

4

      {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};

5

6

   if (++sec>59)

7

   {

8

      sec = 0;

9

      if (++min>59)

10

      {

11

         min = 0;

12

         if (++hour>23)

13

         {

14

            hour = 0;

15

            // recognize leap year (correct until 2099!!!)

16

            if (((year&0x03)==0) && (month==2)) // if year can be divided by 4

17

            {

18

               days = 29;               // it's a leap year with 29 days in Febr.

19

            }

20

            else

21

            {

22

               days = days_per_month[month-1];

23

            }

24

25

            if (++day>days)

26

            {

27

               day = 1;

28

               if (++month>12)

29

               {

30

                  month = 1;

31

                  year++;

32

                  EEPROMwriteB(13, year);

33

               }

34

               EEPROMwriteB(12, month);

35

            }

36

            EEPROMwriteB(11, day);

37

         }

38

         EEPROMwriteB(10, hour);

39

      }

40

   }

41

}

BR,
Jörg.

@Jorg:
I know that current implementation isn't optimal. This was not my code 
and abble to see many point to optimize (some function can be "static" 
and more). But I has many more significant tasks.

RTC_IsLastSunday bug was fixed in Rev 207
thx: Jörg Becker

Jiri

Hello,

Schematic for RFM12 "master" board communication can be found here in 
SVN: 
http://openhr20.svn.sourceforge.net/viewvc/openhr20/rfmsrc/doc/master_board/

First alpha version of wireless comunication SW can be released very 
soon.

If somebody will be create PCB for this, please send me one. Notes: not 
all supply pins (5,6,17,18,38,39) must be used. LED can be moved to 
another pin than PD7(16) but tell me it. RFM12 DATA pullup PB0(40) can 
be moved to another pin or we can use pull-up resistor, but tell me it.

Jiri

Hi Jiri,
it would not be a big problem to do a pcb for the master. But it would 
be nice if you could explain what the exact function or way of use of 
the master is.
- Is it used as a stand-alone unit? What does it do then and how is the 
master itself configured?
- Is it used as a sort of RF gateway for a PC?
- Does it completely override the settings in all the connected HR20s?
- It does not have any inputs (keys, door or window open detection, ...) 
at all, no display, (no power supply), no temperature sensor, no RTC

Would be nice to understand that.

BR,
Jörg.

"master" have 2 functions:
- It control wireles network access to shared media (air) and broadcast 
real time
- it is gateway for Linux/Windows PC or linux based router (see to 
http://www.openwrt.org)

I will completly control all connected HR20.
It have not any input (it is not needed). It is gateway between serial 
line and RFM12.

I have same pinout like HR20, it mean that we can use same programming 
cable and same serial level or serial USB convertor. Power supply must 
be wired to connector.

SW on PC side have 2 parts: one is small daemon, second is web 
interface. Both is in PHP. It can run under Linux or Windows. Including 
Linux on small routers. It have amazing benefit for me, this router run 
24/7 and need small power (7W). You can control heating from anywhere 
24/7 including access from PDA.