This is the new Thread about the OpenHR20 Firmware from
http://openhr20.sourceforge.net .

For generic Questions about the HR20, please look&ask in
Beitrag "Honeywell Rondostat HR20E per AVR steuern und konfigurieren"
Please write in English, thanks!

@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...
).
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/publ...

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

                Overhead 
              ============
                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/Heizungsst...

(@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/eve... 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/Heizungsst...

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

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

 // rfm_config.h
#define RFM_INT_EN() (PCMSK0 |= _BV(RFM_SDO_PCINT), PCINT0_vect())
#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

 // rfm_config.h
#define RFM_INT_EN()  PCMSK0 |= _BV(RFM_SDO_PCINT);
#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

    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?

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)
20:40:54.515> D: d4 26.02.09 20:40:54 A V: 52 I: 1845 S: 1900 B: 3312 Is: ff3a
20:42:54.421> D: d4 26.02.09 20:42:54 A V: 54 I: 1838 S: 1900 B: 3312 Is: ff78
20:44:54.421> D: d4 26.02.09 20:44:54 A V: 54 I: 1838 S: 1900 B: 3312 Is: ff78
20:46:54.421> D: d4 26.02.09 20:46:54 A V: 54 I: 1838 S: 1900 B: 3312 Is: ff78
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
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
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
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!!!
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
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

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:

bool RTC_IsLastSunday(void)
{
    if (RTC_DOW == 7){ // sunday ?
        return 0;  // not sunday
    }
    ....

shouldn't that be:

bool RTC_IsLastSunday(void)
{
    if (RTC_DOW != 7){ // sunday ?
        return 0;  // not sunday
    }
    ....

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:

void RTC_add_one_second(void)
{
   static const uint8_t days_per_month[12] = \
      {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
   
   if (++sec>59)
   {
      sec = 0;
      if (++min>59)
      {
         min = 0;
         if (++hour>23)
         {
            hour = 0;
            // recognize leap year (correct until 2099!!!)
            if (((year&0x03)==0) && (month==2)) // if year can be divided by 4
            {
               days = 29;               // it's a leap year with 29 days in Febr.
            }
            else
            {
               days = days_per_month[month-1];
            }
            
            if (++day>days)
            {
               day = 1;
               if (++month>12)
               {
                  month = 1;
                  year++;
                  EEPROMwriteB(13, year);
               }
               EEPROMwriteB(12, month);
            }
            EEPROMwriteB(11, day);
         }
         EEPROMwriteB(10, hour);
      }
   }
}

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/openhr2...

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.

Wireless RFM12 modification documentation is available on SVN
http://openhr20.svn.sourceforge.net/viewvc/openhr2...

- internal version is inside HR20. It allow to use debbugger. It is more
compact. It is safer for childen etc. But it need expert skill of
soldering. Solder wires "touch" to MLF package is nightmare.

- external version is outside HR20 on system connector. It not need open
HR20, easy to install. But not allow connect debuger to HR20. And it can
be mechanicaly damaged. (thx to Mario)

Jiri

Jiri,
thank you for your explanation of the master functionality.

I want to use the wireless HR20s a bit differently then you. Most of the
time the units shall work independently with their own settings and I
just want to override these settings occasionally, e.g. if I want to
switch off the heating completely or the circulation pump is not
running.....
Then I want to add small wireless nodes that monitor windows and doors
with a small reed contact. This is first just for monitoring and second
to switch on and off the HR20s in the same room where I see an open
window or door (for some minimum time off course).
Next thing I already started is the wireless remote control of most of
the internal and external lights and also some other electronic devices,
all with the same RFM12 receivers (433MHz in my case).
When all this is completed, I also need a gateway between PC and this
wireless network. And then a WEB interface would be nice, too.

These are the plans, I hope to find the time for it.

BR,
Jörg.


PS: Since some weeks I have a very small problem compiling the
'wireless' version of the firmware. If I double-click the .aps file, I
get a message about missing files and I see that the file path of these
files is 'C:\jirik\hr20\rfmsrc\...'. Am I doing something wrong with the
SVN update? I know that I can simply 'locate' these files on my HR20
folder, but every time I update I have to do it again.

@Jorg:
Don't worry about missing file.
.aps file is not used for compilation, just for debug and edit (I use
Kate and PSpad for edit). Compilation use Makefile.
Jiri

Information about RFM12 SW:
It is still incomplete and it is not prepared to use.
I hope that first "Alpha" version will be prepared around 20.3.
If you will want to use it, it is right time to buy/prepare HW. I will
need testers ;-)

Jiri

Project is not moved. But we not release any final version. You must
download it from SVN.

Hi Jiri and all the other HR20 users,
I have just recognized a strange problem with on of my HR20s with one of
the latest firmware versions.

After mounting the HR20 and after the calibration run, I found that the
valve opened at a readout value of about 41% valve position. I then
corrected the minimum valve position to 38%. After a week or so I found
that the temperature in the room was always to high and the valve
already at its minimum position of 38. I could hear that the valve was
still open. I therefor corrected the minimum valve position to 30%
(default value) again. Yesterday evening I found that the valve was
again wide open (24°C in the room) although the valve was at 30%
position. After a calibration run the minimum position where the valve
opened was again ~41%.

(Strange thing is that this behavior is very similar to what I
experienced with my very old HR20s from time to time.)

Is there any chance that the controller misses pulses from the postion
encoder? Did anyone else experience the same problems? Is this perhaps
hardware dependent?

BR,
Jörg.

@Jörg Becker:

Have you log file? I could be more than one reason.

- you have some "noise" on impulse conter input and current noise filter
fail (create log file it is helpful)

- it is +-1 problem on ends. It can count false +1 on motor start or not
count first pulse on movement. On worst situation after 100 movements
you will have 100 impulses error on position but it is not probbaly (win
in lotery it absolute sure compare to this :-) ).

I would like to found where is bug. Because it can be problem on code.
Can you create log (calibration + minimum 20 movements)

Because we can't mesasure position without any error (motor start can
create false pulse very easy), valve use automatic calibration on Sun
10:00AM.

To break this problem, current SW don't stop motor inmediately after
wanted pulses but it will stop motor with delay. Idea was stop motor
ouside problematic position around motor pulse edge. You can tune this
value (config.motor_eye_noise_protect, position 0x15 on trunk), default
value is 40% of motor pulse cycle.

Jiri

I too figured out a problem regarding loss of pulses.

Situation: Room was heated up to about 24°C, valve position displayed as
30% but valve was not closed (nearly open, seen after disassembly of
Controller Head). After new calibration everything seems to be ok. But
the question is - how long?

In this context, could somebody give me a little explanation in how the
calibration of the Motor travel works. It seems to be a little bit
tricky.
Especially the interaction the various subroutines.

Ulf

I too figured out a problem regarding loss of pulses.

Situation: Room was heated up to about 24°C, valve position displayed as
30% but valve was not closed (nearly open, seen after disassembly of
Controller Head). After new calibration everything seems to be ok. But
the question is - how long?

In this context, could somebody give me a little explanation in how the
calibration of the Motor travel works. It seems to be a little bit
tricky.
Especially the interaction of the various subroutines.

Ulf

Most probaly is that SW not count one pulse add one false pulse when
motor stop and run back later. WE NEED LOG FILE. A am not able replay
this situation now.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!WARNING! Do not use "On" setting but some temperature only. It will
pull valve position to physical limit every second

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


It will be fixed very soon.

Touched Revisions on main trunk is 175-221

Update to Rev 222 is RECOMENDED.
It was fix problem with "On" setting.

PS: Motor position measure will be improved later

Thanks for LOG file to everybody.

At this moment I have new valve position measurement. It works, but need
some cleanups. It will be prepared for SVN tomorrow (I hope).

@Ronny: Can you send me your valve range? You can get it by command
"T08" and absolute valve position (command "T09").
Valve position on log is what you want to have (can't be change live on
motor movements), valve position on LCD is calculated from absolute
position and show live position. It use near to same equation, but 16bit
fixed point aritmetic have some +-1 error. It is strange, that diffence
between this two values is bigger than 1.

Jiri

Hello,

You can test latest method to count motor pulses. Any LOGs will be
welcome.
Revision with change is 225. This version is not tested on all
conditions.

If you want stable version on this moment, please use Rev222.

Jiri

EDIT: new pulses calculation - minor bug fix in Rev225

@Ronny:
Strange. T08 and T09 values look correct for 10% (10.28%).
Can you update SW to rev 225? I will look to this problem later. Do you
change some values in EEPROM?

Jiri

I would like to inform you, that wireles communication works.

Rev 227 is ALPHA version
(http://openhr20.svn.sourceforge.net/viewvc/openhr20/rfmsrc/)

Some notes:
- PHP&sqlite is needed
- It can run on PC or Linux based routers (for 24/7 access, low powered
devices see to OpenWRT project)
- linux instalation is without problem. Windows users must use
"Serproxy" and connect daemon.php to localhost TCP port.
- daemon.php come from communication test code. It is buggy and
sometimes lost some request. User must make another request. I will not
fix it but I will create complete new daemon.
- It is need to setup serial port to 38400/8/1 (linux machines have
"start" file)

PS: it need to write HowTo setup document. (volunteer?)

Jiri

PS: When somebody will create PCB for wireles "master", please send me
one. Thanks.
My current master is nest of wires.
Jiri

Window open function looks buggy. See to my log. It have false "close"
detection. I will try it improve. PS: table is from wireless extension,
it is nice to monitor all valves near to real time. See to attachment

addr  time  mode  valve  real  wanted  battery  error  window  force
17  2009-03-28 09:45:15  -  30  15.03  4.5  2.668  0  0  0
17  2009-03-28 09:44:55  -  30  14.78  4.5  2.663  0  0  0
17  2009-03-28 09:42:53  -  30  14.7  4.5  2.667  0  1  0
17  2009-03-28 09:41:15  -  30  15.13  4.5  2.663  0  0  0
17  2009-03-28 09:40:02  -  30  15.29  4.5  2.662  0  0  0
17  2009-03-28 09:37:14  -  30  15.44  4.5  2.661  0  1  0
17  2009-03-28 09:36:11  -  30  15.7  4.5  2.668  0  1  0
17  2009-03-28 09:33:14  -  30  16.29  4.5  2.668  0  0  0
17  2009-03-28 09:31:23  -  30  16.54  4.5  2.662  0  0  0
17  2009-03-28 09:30:15  -  30  16.5  4.5  2.668  0  1  0
17  2009-03-28 09:29:14  -  30  16.8  4.5  2.668  0  0  0
17  2009-03-28 09:25:34  -  30  16.99  4.5  2.662  0  0  0
17  2009-03-28 09:25:14  -  30  16.92  4.5  2.663  0  1  0
17  2009-03-28 09:24:17  -  30  17.13  4.5  2.669  0  1  0
17  2009-03-28 09:21:22  -  30  17.47  4.5  2.666  0  0  0
17  2009-03-28 09:21:15  -  30  17.43  4.5  2.666  0  1  0
17  2009-03-28 09:19:44  -  30  17.54  4.5  2.668  0  1  0
17  2009-03-28 09:17:15  -  30  17.97  4.5  2.663  0  0  0
17  2009-03-28 09:16:36  AUTO  45  17.77  17  2.667  0  0  0
17  2009-03-28 09:15:47  AUTO  30  17.6  17  2.669  0  1  0

Wireless aplication screenshot

Wireless aplication screenshot (false window close detection problem)

Wireless aplication screenshot #3 (timers)

@reinis: it look like bad XTAL. I have 6x HR20 and usual precision is
better than +-2sec/day except one (8 sec/day).
But with wireless extension it is not problem it is syncronized from
master. And master can be syncronized from internet.

reinis,
before Rev207 there was a bug in the daylight saving routine (see our
postings on 2009-03-04). As you are using Rev192, it is very likely that
you hit that problem.

BR,
Jörg.

@Jorg & reinis: Jorg have true. This bug was fixed and I was not abble
to see that you are use too old version before bugfix.

Wireles extension: New Rev 228 with graphs. I was not abble to find any
library for lightweight XY grapg. All was too havy for embeded router.
Therefore I was create one oprimized for this project. I will improve
look&feel but you can see result from Rev 228 on attachment.

Hi Jiri,
regarding the wireless version (Rev207), I have some questions:
- when I compile it, I get

Program:   16478 bytes (100.6% Full)

is this ok?
- how does the HR20 with this version behave, if I do not have a master
running? Does it use its individual settings then? Does it send the 4
minute reports wireless instead of via RS232?

BR,
Jörg.

PS: I quite regularly (but not always!) see that the temperature reading
changes by some degrees (1.5 to 2?)while the motor is running (all
firmware revisions). Is there any explanation for this? Can this cause
any trouble? I am asking because yesterday morning the bathroom was cold
and the display showing 'OPen' without any cause. Nobody had opened the
window nor the door and half an hour earlier the temperature had been
ok. I have never managed to get this response ('Open') by really opening
the window (not even with the original firmware). In most cases when I
tried this (open window), the temperature did not fall fast enough. So
it is even more strange what I saw yesterday.

@Jörg:

Please use recomended compiler WinAVR-20071221 or disable something on
debug.h

Q: how does the HR20 with this version behave, if I do not have a master
running?
A: you can use RS232 connection in same way as before this modification.
But if you use only wireless and master not runnig, software will save 4
minutes report to buffer, after buffer overload (it is small for maximum
7 reports) data will be lost.

Q: Does it use its individual settings then?
A: yes, setting is individual for each valve. But you can manualy change
AUTO/MANU mode or wanted temperature easily from one page.

Q: Does it send the 4 minute reports wireless instead of via RS232?
A: yes, you can see example on screenshots

Jiri

Jorg: Temperature reading during motor run: You are right, motor measure
too big noise for exact measure. We will must change it.
But till now I was not have any accident from this, because we are use
15 second average for temperature controler. But window open detector
have noise filter only from 5 values. You can try change this filter
setting it is config.window_open_noise_filter setting (0x23
configuration).

But I wrote request to disable measure during motor run into TODO list.

Jiri

Jiri,
first of all, I saw your graph from Rev228. This is very nice!

- Regarding the wireless version, I want to have reports via RFM12
without using a master, e.g. for logging. Means that the HR20 works
exactly as with the normal version but with wireless reports instead of
RS232. Have to find out how this works.
The other question was whether the wireless version will use its own
(stored in the HR20!) settings, if the master fails working (or is not
present at all). I understand that if the master is running, it takes
full control.

- Regarding the temperature measurement, I do not understand why the ADC
buffer is 60 entries long and only 15 are used for the average (compile
time options, not changeable during runtime). Does this make any sense?

BR,
Jörg.

PS: I still have a lot of questions concerning the code and
unfortunately not enough time to go through it and understand it in
detail. I am just busy working on my remote switches with RFM12. Got
first PCBs and will try getting these to work during the next time.

Jorg: you are not abble use current wireless code without master. Simply
before master syncronize communication an without master you are not
abble use encryption. But I thing that master is extremely simple and
cheap. If master fail, you are not abble communicate. Current code don't
support communication between two valves (and we have not free flash).

And mainly: "master" is interface between computer and valve wireless
network. How you want to control this network without this interface?

60 measured items on table is used for window open detection. We need to
compare current value and 1 minute old value.

For clarification. CurrentSW can be modified to direct communication
between valves or between remote thermometer to valve. But it still need
"master" for manage network and encryption.

For direct communication without valve you need some caint of "MESH"
network. It is possible if you disable some existing part of SW to save
flash space (for example rs232 com). But it is more complicate than
current communication. It need complete new protocol, complete different
SW layer. And volume of work for RFM12 is sufficient university
dissertation for few peoples (it is not only few lines of code). Another
chance is buy some existing solution (and use another more expensive
wireless modules).

New improvements for 1.00 version are in rev 229:

- configuration for disable/enable ADC measure when motor run
- bug fix for false positive window close detection

Jiri

@rhb: It is unbelivable for me, that Rev 225 can lost some motor steps.
Absolutly strange.

You don't want to use "partial" calibration, you can use current manual
calibration mode. (Unmount head from valve, manualy close valve, this
position will be saved as "close",  press "C" and mount head to valve
back - keep "C" pressed during this operation) After this calibration
proccess on LCD will not show "Ad 1" etc but "A  1" etc. Motor
recalibration will only touch to "open end" and go back to wanted
position because know "closed position" - saved in EEPROM.

Recalibration is done automaticaly every Sunday on 10:00, you can change
it on main.c

Return to automatic mode is same, butt preess and hold "PROG" button not
"C".

PS: I trust you this problem but I can imagine where is problem, it need
LONG log file from Rev 225 or up.

PSS: how you measure second temperature?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
All: we still have problem with window open close detection. After last
change it is better, but it can be false positive or negative again. I
will completly rewrite this part later this week, I have idea how.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Hello Jiri,

my "partial calibration" was only a thought for a workaround to
automatically correct the actual position. I saw the part of the
program, were the full recalibration is done on sunday 10am, but I
wanted to save battery power...
(Thank you for the explanation of the manual calibration, I didn´t
figured out this from the source code - as I said, I´m learning)

My theory is, that the the motor doesn´t lose steps, but because of the
strong spring in the valve the motor is turned back a little bit AFTER
it (and the "photo eye") was switched off and so the actual position is
distorted. So maybe it would help to deactivate the "photo eye" a little
bit later - what do you think?

I started a new log today with original version 229, what do you mean
with LONG time? 1,2 or more days? Or until the valve isn´t closed? Now
this will takes longer because of the warm weather and mainly closed
valve...

Ronny

PS: I measure in my "recirculation temp version" the second temperature
by adding a second thermistor to pin 60 (ADC1) of the ATMEGA and GND (I
don´t need the wireless part) and a resistor between pin 60 and pin 58.
I know, that I decrease the precision of the measurement of the room
temperature with this modification.

@rhb: manual calibration is almost equal to "partial calibration" as you
want. Because range of valve is defined, every calibration in this mode
is simple (go to "open end" and it's done)

@Jiri

here are the long log. At this evening the error happens again. The
valve seems closed (30%), but the heater is warm.
At the beginning (after the calibration) the valve is real closed at 40%
and now the valve is a little bit open at 30%.
The log was made with original version 229. I changed only the
pid-interval to 120 seconds.

Ronny

Due to problems with window detection I made completly new window open
detection.

You can test in Rev 232

Configuration options:

    /* 22 */ uint8_t window_open_detection_diff; //!< threshold for window open detection unit is 0.1C
    /* 23 */ uint8_t window_close_detection_diff; //!< threshold for window close detection unit is 0.1C
    /* 24 */ uint8_t window_open_detection_time;
    /* 25 */ uint8_t window_close_detection_time;

How it works:
Program save temperature AVG every 15 seconds. For window open
detection, program compare current actual value with higest value in
selected interval.
Interval is in 15sec unit in window_close_detection_time and detection
threshold value is in window_close_detection_diff.

Window open detection is similar.

Default values is 0,5degC difference on 2 minutes interval. Maybe that
we will need change it.

Jiri

PS to @rhb: thanks for log, I will analyze it today or tommorow.

@rhb: Strange, your log looks perfect. No problem. Where is your
position where valve start opening? (normaly after restart)

On start or end of movement you can found x/X and y/Y chars. This is
signalization where motor stop (logical level). It must be "x" and "y"
every time because we want to stop on low level. When motor move
sometimes during eye is off, sometimes we will see "Y" after x. But it
never happen. (except calibration, but it is due to HW movement limit)

Rev 234 contain paranoid filter for temperature measure (noise
cancelation)
You can try it

Jiri

Hello Jiri,

I think, that I have a log with the error. At this evening the valve was
open at 30% (after calibration it is closed at 40%, so the error is
greater than 10). I set the eeprom valve_max to 90 and then I set the
wanted temperature to 30° (see 06.04.09 20:12:38). The valve wants to
open to 90%, but at nearly 86% the valve blocked and the scale jumps
from 86 to 100% and went then to 90%.

Ronny

@hrb:

- I am surprised, you are realy losing pulses. But it is not on log.

- Jump from 86->100 is correct and I wrote this behavior into SW. In
this situation calculated position is 86%, but valve stop on hard break.
This hard break must be 100% by definition, therefore SW fix current
position to 100% and will continue go to wanted position 90%. This is
partial recalibration initiated by error detection.

Main question is WHY you losing pulses? Have you only one HR20? Can you
try mount this HR20 into another valve?

I have 5x HR20 with my SW byt never see situation like this. Strange.
Problem is that your log looks perfect. Any pulse during motor run can't
be lost becasuse in this condition we can see in log longer time for one
pulse. (second column is time for one pulse) and it looks perfectly
stable without glitches.

Only one idea is, that your valve is too strong and it is abble change
position when motor is stopped. Probably after opening. But in this case
we will see sometimes "X" after "y" but it newer happen in your log.

Strange, strange, strange.

Jiri

Wireless extension: Have somebody "master" hardware already? I would
like ask, before I will change used MCU from ATMEGA16 to ATMEGA32.
Reason is RAM size needed for buffers. If somebody have deprecated
hardware with ATMEGA16, please tell me it !!!NOW!!! (if it is not
possible replace MCU in socket)

Jiri

Hello Jiri,

sorry for the delay, but I tried a second (different) HR20 on the
bathroom valve. But for the warm weather it tooks a little bit longer,
because the valve was closed most of the time. But now I saw the same
situation: I set the max position to 90% - the valve wants to set to 88%
and came to the hard break and jumps to 100 - see the log. I have the
same theory as you: the valve (or the valve spring) is too strong and
can change the position, if the motor is stopped, maybe only a few
seconds after the motor stops. Do you have an idea how this can be
solved?

Ronny

rhb: I have  idea to keep motor eye enabled few secons after motor stop.
But it will be done after few weeks, today I have more urgent tasks.

Jiri

I am using 868Mhz modules but it is easy use same modules but for 433.
Problem can be that current SW realy need "master" board. Current
communication protocol is simple and not support some "MESH"
functionlity.
!But! it is open project and your idea with "betty remote" is nice.
Everybody can modify it to this way, but it is lot of work.

Jiri

@puchti100:
nice, it is solution.

I have few technical notes:
- RFM12 can be connected directly to valve but it will need modification
to your wireless protocol
- be careful if you use battery power, wireles communication is hungry
- alternate SW have public protocol on RS232, you can drive it direcly
without connection to encoder.

Any news on the development?

I'm going to move during the turn of the year and then would like to use
some RFM-enhanced HR20.
At the moment, I've only got two with the stock firmware, because I
couldn't get my USBprog JTAG to work yet :(
But I would buy a "real" JTAG adapter if I need to :)

Hi jdobry,

I guess you mean the firmware compiled from the repo/rfmsrc/OpenHR20
directory?

And you are using the "internal_RFM12" hardware modification? Is it
difficult to use the external one?

And what's your master? A HR20 with a special firmware or an extra piece
of hardware?

Please excuse my pile of questions, if there is any documentation please
point me to it :)

I hope I'll be able to improve the documentation soon :)

My answer from yesterday evening didn't make it into the forum :(

By reading through the thread I found out that the master is an
ATmega+RFM12, connected to an OpenWRT router.

Hmm, you're right about the risks of an external module, but I thought
it could be easier to connect a cable to the 10-pin connector but put
the module inside.

Can both - internal and external - be used? There are preprocessor
defines, but also a warning message in
\rfmsrc\doc\external_RFM12\README.txt.

jdobry, do you already have a PCB for master hardware?

Or does anyone else have a layout?

If not, I would design one and order some PCBs...

Ok, that will be my task for the weekend :)

Maybe we should start a new thread for designing the PCB:
http://embdev.net/topic/158895

But I'm unsure about the connection to a router. Does yours have a
serial interface?

Hello,

I use my HR20 (currently one) with an external 433MHz RFM12 module from
Pollin. I modified the initialization of the RFM. I set the Band to
433MHz  and the capacitor to 12.5pF. The frequency is 434MHz and the
range limit is set to +3-4 for 433MHz band ,respective to the
programming guide. My master is an ATMEGA32 on an prototype PCB  powered
via USB. Now my problem: I start the master and the daemon and the first
5minutes all work well .Then I receive only errors for hours, sometimes
it work for a few packet and then the same problem. If I restart the
master , the first minutes it work well. What´s wrong ? Have somebody an
helpful hint ? Maybe is there an wrong initialization value for 433MHz.

Thanks in advance!
Ronny

Hello Jiri,

did you mean the Debug log in the database or the log from the daemon ?
The Masterclock is from RFM and it is 10MHz , i have veryfied it whit an
oscilloscope. THe Slave doesn't show E4 and if i change the time on my
HR it will set back automaticly to the time of the master.

Here a short dump :
2009-12-08 12:38:07      @07.48 ERR04df 24 06 3f e4 44 43 b5 0f 87 1d...
2009-12-08 12:37:07      @07.49 ERR04de 24 06 18 e5 38 f7 08 55 b7 b0...
2009-12-08 12:37:01      ?
2009-12-08 12:36:07      @07.50 ERR04dd 24 06 63 38 37 91 0e 06 60 c5...
2009-12-08 12:35:07      @07.49 ERR04dc 1a 06 9f 7b 8a e8 dc 5e b7 c3...
2009-12-08 12:34:07      @07.49 ERR04db 1a 06 51 80 12 51 cf e8 0a c6...
2009-12-08 12:33:07      @07.49 ERR04da 1a 06 7c d0 06 01 67 d6 97 c3...
2009-12-08 12:32:07      @07.48 ERR04d9 1a 06 ee 43 5d 7e cf f9 22 47...
2009-12-08 12:31:07      @07.49 ERR04d8 10 06 f1 b3 10 9a 73 b1 5a ca...
2009-12-08 12:30:07      @07.47 ERR04d7 10 06 38 65 40 95 3d 99 6e 17...
2009-12-08 12:30:01      ?
2009-12-08 12:29:07      @07.48 ERR04d6 10 06 80 aa d5 32 4d b3 48 ec...
2009-12-08 12:28:30      @30.11 ERR04d5 8c 70 ec 16 26 33 de ad 7c 2e...
2009-12-08 12:28:07      @07.48 ERR04d4 10 06 9e 84 0f 48 e1 6f 7b 6b...
2009-12-08 12:27:07      @07.45 ERR04d3 06 06 e7 f5 fd 16
2009-12-08 12:27:01      1)?
2009-12-08 12:26:01      @58.57 ERR04d2 3f b7 3d 45 91 08 04 55 ac 3c...
2009-12-08 12:25:07 <06> -D m32 s03 - V46 I1884 S1900 B2941 E00
2009-12-08 12:25:07 <06> -D m27 s49 - V45 I1885 S1900 B2940 E00
2009-12-08 12:25:07 <06> -D m23 s39 - V45 I1890 S1900 B2947 E00
2009-12-08 12:25:07 <06> -D m19 s28 - V45 I1890 S1900 B2956 E00
2009-12-08 12:25:07 <06> -D m15 s16 - V45 I1890 S1900 B2953 E00
2009-12-08 12:25:07 <06> -D m11 s06 - V45 I1890 S1900 B2946 E00
2009-12-08 12:25:07 <06> -D m06 s55 - V44 I1897 S1900 B2956 E00
2009-12-08 12:25:07 <06> (06){
2009-12-08 12:25:07      }
2009-12-08 12:25:07      @06.13 PKT04d1
2009-12-08 12:24:07      @07.54 ERR04d0 4c 06 86 c7 c2 14 5c b1 10 b0...
2009-12-08 12:23:07      @07.54 ERR04cf 4c 06 5e bf 45 ae c3 c4 b3 11...
2009-12-08 12:23:01      )?
2009-12-08 12:22:07      @07.53 ERR04ce 4c 06 50 de 31 23 24 86 62 0a...
2009-12-08 12:21:07      @07.54 ERR04cd 4c 06 b9 c1 c0 35 56 74 1b c9...
2009-12-08 12:20:07      @07.54 ERR04cc 4c 06 25 9d bf 22 22 ec fd 52...
2009-12-08 12:19:07      @07.54 ERR04cb 4c 06 9d 3e 1f 97 a3 ec c6 d8...
2009-12-08 12:18:10      @09.95 ERR04ca 4c 06 e0 24 03 12 bb 1f 4a bb...
2009-12-08 12:17:07      @07.54 ERR04c9 4c 06 f7 2d 46 33 e2 67 88 d2...
2009-12-08 12:16:07      @07.53 ERR04c8 4c 06 23 54 02 7b ac 24 e9 80...
2009-12-08 12:15:07      @07.55 ERR04c7 4c 06 9b 1e 10 aa ad 18 d2 aa...
2009-12-08 12:14:07      @07.53 ERR04c6 4c 06 38 b1 45 f5 7d a7 87 b9...
2009-12-08 12:13:07      @07.54 ERR04c5 4c 06 2d a6 5d 22 18 c0 7d 07...
2009-12-08 12:12:07      @07.54 ERR04c4 4c 06 d1 e3 50 72 91 a3 f1 97...
2009-12-08 12:11:07      @07.54 ERR04c3 4c 06 11 38 b5 a1 64 fd 0c 98...
2009-12-08 12:10:07      @07.54 ERR04c2 4c 06 96 e8 a5 af 38 3e f1 a6...

Ronny

How often is the Time of the Master synced whit the PC ?

The timedrift on my ALIX2 is very strong , so i update the Time from a
NTP server every 10 minutes. Could this problem influence the decryption
?

Ronny

Hello Jiri,

I think i found the problem. I tried following on my server :

voyage:~# ntpdate ptbtime3.ptb.de;sleep 60;ntpdate ptbtime3.ptb.de
 9 Dec 09:29:38 ntpdate[30871]: step time server 192.53.103.103 offset -0.749543 sec
 9 Dec 09:30:37 ntpdate[31034]: step time server 192.53.103.103 offset -1.480186 sec

Lo and behold! The drift whitin 1 minute is around 1,5 seconds.
Then i tried to update the clock every minute , it looks better. At
least i tried to update via ntp every 10 seconds and every packet is OK
...

It seems i should fix the problem on my Server ...

Regards,

Ronny

Hi Peter,

I've started one, but haven't got further than flashing yet :(

Hello Jiri,

Yes I use ntpd , but it was not precise enough. Now i found a other
solution. I have modified the handling of the time update at the
master.The request is send every minute , but it ignore the the answer
if onsync greather than 0xe1. This should be a time of 1 hour.

I found a other problem in the daemon. The serial connection will only
work if the system set the right baudrate. I add a
exec('stty -F /dev/ttyUSB0 38400 '); to the daemon. Now it is anytime
the right baudrate.

Ronny

Hi Jiri,
now that we are back in heating period again :-(, I have changed two of
my HR20 running older versions of the OpenHR20 firmware (still without
wireless) to the newest (?) version 234.
Experience so far: both failed miserably, showing 'Open' for hours and
both rooms cold this morning and again this afternoon (my wife is not
amused).

Best thing for me at the moment would be to disable the window open
detection completely (any hint how to do that easily by changing
parameters ?).

Regarding your last post about wireless. I think one of the reasons why
this is not used by so many people is:
- the lack of an easily available master unit
- the way you are using it (with a router as master control, maybe too
complicated for most of us ???)

What I would love to do is have the individual units run on their own
with their own sets of parameters and monitor these units via wireless
with a master unit most of the time. Only in some special situations I
want to control the units remotely, e.g.:
- if the circulation pump is not running (at night)
- if i leave the house for a weekend holiday
- .....

BR,
Jörg.

Hi Ludger,
thanks a lot for this info regarding window open detection. I will try
that immediately.

BR,
Jörg.

Jiri,
I think the idea with a programmable timeout after window open detection
is the best , because I can not imagine how it COULD work automatically
regarding the huge variety of circumstances (we have the same -15°C here
at the moment as you and the room temperature falls extremely fast and
never recovers. Temperature regulation is also not nearly perfect.
Because of the low temperatures outside and high heating water
temperature I see extreme overshoot in very small rooms with
comparatively big radiators whereas in other rooms temperature increases
very slowly with valves full open).

One other (maybe optional) possibility if the HR20 is located near to
the window/door would be to use one of the cheap reed contacts for
burglar alarm and cable this directly to the HR20 interface connector.

And, yes, I know that everyone is allowed to change the sources :-), but
there is simply not enough time for me to do that.

BR,
Jörg.

Jiri, Ludger,
for me the .aps file in the wireless directory works perfectly, whereas
the one in the trunk directory does not. Calling make from command line
works (although I am not the command line guy, started with that 35
years ago and am happy that we have fully integrated graphical
development environments now!).

If the .aps is not maintained any more, than it should perhaps be
deleted.

BR,
Jörg.

PS: Ludger, changing the parameters for wod worked for me, warm bathroom
this morning, happy wife :-),.... thanks again.

Jiri,
has anything been changed on the serial routines? These worked ok in
V2.03 which I used in my HR20 before changing to V2.34.
Now I get a number of rubbish symbols when the HR20 answers to a command
before the correct answer (like yyyyyD: d4...) and nearly only rubbish
(yyyyyyyyyyyyyyyyyyyyyy......) when the units send their message every 4
minutes. I have no clue at the moment what's going wrong.

BR,
Jörg.

Jiri,
thank you for the info. I got it to compile and work.

BR,
Jörg.

Marcus,
the original algorithm is written in the HR20 Datasheet:

"Bei Temperatur-Änderung von 1,5°C/3Min. schließt das Ventil u.
öffnet wieder bei Temperaturanstieg o. spätestens nach. 45 Min."

-> slope must be at least 1,5°C in 3 minutes to detect a window change,
and a 45 minutes timeout is used.

The datasheet can be found at Reichelt.de:
http://www.reichelt.de/?;ACTION=6;LA=3;ARTICLE=787...

it can also be found there:
http://www.rondostat.net/fileadmin/content/02_pdf/...
:)

@ Marco,

thank you for your support, I've read the consumer documentation. I
think the threshold of 1,5°C is in many situations too much - it takes
too long till the software detects the open (only tilted?) window. There
should be an integrated dynamic component, consisting of the
in-,decreasing PID-Value's tendency and the sign of the D-Part (last
measured temperature higher/lower than the current value)?
Last night I advanced my PID by this extension and to time it's looking
good.

Marcus

Well, I've used the original HR20 firmware last year, and it did
recognize my open balcony door almost immediately. Of course I opened it
completely and did not tilt it.

Marco

An open balcony door causes a big and fast heat loss - the temperature
decreases rapidly, so it's easy to detect this. But a slow loss - about
a few centigrades/PID-cyle cannot be recognized by this way. I think the
valve constantly opens until the limit (or setpoint) is reached, or am I
wrong?

Marcus

Yes you're right, that's a big heat loss. But isn't opening a window
completely the "better" way to exchange the air in a room?

I don't know anything about the original nor the OpenHR20 algorithm :(

Yes, indeed. But not every window can be completely opened - like mine
in the attic. I also consider this function as a kind of protection for
forgetful people who forget to close their doors/windows - it's not
really required for a few minutes air exchange.

Marcus

PS:Do you use OpenHR20 on your valve(s)?

Jiri reported about some very cold days when his /window open/-detection
falsely recognized an open window. Maybe a reed contact connected to a
GPIO would be more suitable?

I'm not using OpenHR20 yet, I'll be moving at the end of February and
then start with OpenHR20.

I'm seeking for a solution, without any external switches cabled to the
valve. The evaluation of wireless informations, for example a window
open detection or distant temperature values is already is already
supported  by my software but not used. Perhaps in the (distant)
future...

Marcus

Here's my master board. Any suggestions? Anyone who is interested in a
PCB when I order some?

http://embdev.net/topic/158895#1533392