EmbDev.net

Forum: µC & Digital Electronics OpenHR20: Firmware for Honeywell Rondostat HR20E


Author: Mario Fischer (superdude)
Posted on:

Rate this post
2 useful
not useful
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!

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
SVN revision 100
    - improve motor control
    - check EEPROM layout on startup

From this version EEPROM layout is fixed. This mean that you can enable 
"preserve EEPROM" fuse and your setting can be saved.

Change EEPROM layout case is tested on code. You will see "EEPr" on LCD 
after restart, startup is blocked. With empty EEPROM you will see same 
message.

*I don't know any missing functionality or bug at this moment.*

Permanet problem is missing documentation generated from sources. We 
need it to document "magic indexes" on setting (Gxx and Sxxxx commands) 
or watches (Txx command)

Changelog:
http://openhr20.svn.sourceforge.net/viewvc/openhr2...

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Known problem for Rev100:
After change of PID constants you must change wanted temperature. 
Problem is teoretical internal value overload. I never saw this problem, 
but I found it on code review.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
SVN revision 101
    - optimizations
    - overload check in pid.c
    - change default setting for PID

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
SVN revision 103
    - motor stop threshold for calibration / runtime can be different

EEPROM layout is changed, you can't preserve old contend.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
@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!

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@ Mario Fischer:

execute task every second:
add it into "if (task & TASK_RTC)" section on main.c

execute it every 60 second have many choices
- use own counter inside "if (task & TASK_RTC)" (worst)
- same section as before, but inside new "if (minute)" condition 
(better)
- same section, add condition "if (RTC_GetSecond() == 
config.network_addreess)" (best)

For interrupt from RFM you must add code inside "ISR (TIMER0_OVF_vect)" 
and set "task |=TASK_RFM12" inside. Make code inside interrupt small as 
is possible and move real functionality inside main.c "if (task & 
TASK_RFM12) task&=~TASK_RFM12; ....."

f you have some code sniplets, please contact me by email. It have big 
priority for me at this moment.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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? ;)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Plan is keep latest STABLE version in main trunk and create branch for 
next development. By this way we can made anything include crazy ideas.

You don't need change anything on menu. Simple add line into eeprom.h 
structure config_t and line into ee_config array. Don't forget change 
eeprom layout map version to something for development (exaple #define 
EE_LAYOUT (0xd0) ).
You can read it by config.g_RFM_devaddr and change it by service menu 
(long press all buttons -select configuration press PROG change value 
and press PROG)

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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!

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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!

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Service mode:

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)
4. press PROG save selected value and go to step 2

any where on service menu:
AUTO - escape service menu without save
C - change service menu from EEPROM setting <-> watched variables and 
back

Watched variables - see to watch.c. In this mode ALL segments are on, 
except 16-bit hex value on numbers and except one blinking segment on 
hourbar. Blinking segment indicate with values is on view. Ekvivalent 
COM command is "Txx<enter>"

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
RFM Wake up will be done by interrupt PCINT9 and setting task|=TASK_RFM.
When we process this event, we must to do task&=~TASK_RFM and it will 
allow sleep in main loop.

Connection RFM to ATmega we have only by 2 ways and both is similar, can 
be changed by compile option  (different is only signal names).

1) connect wire directly to ATMEGA as in my pictures

2) use JTAG pins. JTAG is possible disable in runtime and it is also 
possible to use it for programming but for it we must hold reset signal. 
It is not problem. But it is no possible share this pins for debug. 
Therefore it can be possible way for end-user, not for development. 
Benefit is that it can be connected outside without open HR20.

JTAG disable by fuses is not reversible by JTAG interface because it is 
disconnected. But this configuration can be changed later in runtime and 
we can reenable it by hold reset signal.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Disable JTAG only for runtime: write one to the JTD bit in MCUCSR. 
Datasheet chapter 9.8.7

We don't have any reason to mixed version of wiring. In this case we 
will lost JTAG and we must solder inside HR20. It is not possible share 
one pin on JTAG interface. JTAG can be completly disabled, nothing more.

Problem with share JTAG pins it not programing, but debug.

Security:

Yes, we can use XTEA encryptor on feedback mode to generate key to 
encrypt data. see to 
https://roulette.das-labor.org/trac/browser/microc...

But it have problem. Cipher on RX and TX side must by synchronized 
otherwise is not possible to decrypt data. On wirelless is usual lost 
same data, therefore in this case we can lost synchronization. It is 
complication.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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.)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Mario Fischer:

Your proposal looks good. I would like want only this modifications:

- use upper bit of length or devID to indicate HR20->master or 
master->HR20 communication (benefit: we can reject unwanted packes 
before decoding)

- remove step 5. After step 4 we can go back to 2. It have benefit that 
we don't need keep receiver alive 1 second. Timeout can be smaller (max 
aprox 100ms)

- use SYNC byte before communication, RFM support it in HW. It can 
filter possible noise from others wireless comunications. I am sure that 
you know this RFM feature but you forget write it in proposal.


And some technical notes:

- If you wan't, I can integrate RFM SPI layer into current code 
(interrupts, create task etc.)

- It will be nice reuse/modify current COM code (same commands, same 
results).
-- We can modify numbers in commands/responses to "compressed" version 
(not use hex coding but raw format)
-- wireles layer will encapsulate COM packets and manage encryption.
-- it not need \n as command termination char (size of wirelles packet 
is known)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
We need hash or XTEA feedback hash.
Without this it is easy decrypt ((packets) xor (fixed key)).

Therefore we cant restart hash function for each "status" packed from 
HR20. It is just variant of fixed key.

What we can to do:

step 2 on master: we must reply to HR20 with command or empty packed 
(length,devID,encrypted[rand],crc)
step 2 on HR20: after success on receive calculate next step of hash 
function to generate packed key

What can happen (success):

-step 1: HR20 will transmit packet with packet key generated from hash 
(PK1)

-step 1: master receive it and decrypt it with PK1

-step 2: master transmit packet with PK1 and calculate PK2

-step 2: HR20 receive packet, decode it by PK1 and calculate PK2

What can happen  next (fail):

-step 3: HR20 will transmit packet with packet key generated from hash 
step 2 (PK2)

-step 3: master receive it and decrypt it with PK2

-step 4: master transmit packet with PK2 and calculate PK3

-step 4: HR20 fail to receive packet, PK3 is NOT calculated

-step 5: HR20 will transmit packet with PK2

-step 5: master receive it and try to decrypt it with PK3 it fail, but 
will be successfuly decrypted with PK2

-step 6: master transmit packet with PK2 ( calculation of PK3 not 
needed)

-step 6: HR20 receive packet, decode it by PK3 and calculate PK3

What can happen  next (another fail):

-step 7: HR20 will transmit packet with PK3

-step 7: master fail to receive

-step 8: HR20 will transmit status packet next minute with PK3

-step 8: master receive it and decrypt it with PK3

-step 9: master transmit packet with PK3 and calculate PK4

-step 9: HR20 receive packet, decode it by PK3 and calculate PK3


......

I hope that it is clear. PK numbers is not significnt 
(PK[n+1]=hash(PK[n])). But we need to solve resync after HR20 or master 
is restarted (some initial fixed key)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I thinking.

(some initial fixed key) must not be fixed. It can be fixed part + 
something from user for every init.

In this case, user must read one or two bytes from master and enter it 
manualy into HR20.

It just only idea .....

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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...

Author: Dario C. (dario)
Posted on:

Rate this post
0 useful
not useful
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...

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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!

Author: Dario C. (dario)
Posted on:

Rate this post
0 useful
not useful
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

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
@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 
...

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Dario C:

You are right.

For clarify: If attacker have 2 encrypted data with some KEY and know 
information that it contain common par of source data (rand) it is 
security hole. Attacker can easier calculate key. And from PK(n) can 
calculate PK(n+m) (with hash it is simple, with XTEA in feedbak it can 
be nightmare). (Example in history is repeat random part of KEY in 
encrypted communication used at ENIGMA - decrypted in Poland 1934 by 
Rejevski)

we must have something like protocol specification before coding. From 
my side exist only small chance to do something till Xmas (I am quite 
busy).

Therefore we have time to thinking about it.

Author: Dario C. (dario)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Mario: "we can not use any circulating P[n] -> P[n+1]"

NOT we can't do it like this. It big secutity hole. When one of station 
is offline it is not problem. See to my comments from 09.12.2008 23:48

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

Author: Dario C. (dario)
Posted on:

Rate this post
0 useful
not useful
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

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
@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...

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Dario C:

I know about PRESENT but it is too expensive

PRESENT - AVR C implementation  - 1514 bytes of flash and 256bytes in 
RAM

XTEA - AVR C implementation - 754bytes of flash, 0 bytes in RAM

XTEA - AVR ASM implementation - 504bytes of flash 0 bytes in RAM

source: http://www.das-labor.org/wiki/Crypto-avr-lib/en

We have aprox 3kB of free flash in current SW. Save every byte is fine.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Mario: you dont need any session-key-generation-protocol

It is simple. You have key for packet (PK) , and master key (MK)

And you ca to do:

//have function encrypt(data,key)
PK(n+1) = encrypt (PK(n), MK);

You can calculate it on both sides withou any 
session-key-generation-protocol

You must only keep synchronization you cant decrypt PK(324245) encrypted 
packet by PK(6756324)

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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!

Author: Dario C. (dario)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Mario:
how many transmissions each minute?
- not change from your proposal

what is transmitted in every packet?
- not change from your proposal

You don't need sedn any aditional data for key change. Becasuse  you can 
calculate PK(n+1) from PK(n) if you know master key (stored in EEPROM)

You only must try for decryption use PK(n) and when you have not success 
PK(n-1). If you have not success with PK(n), it mean that one or more 
packets was lost and second side not change PK

Author: rossi75 (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi guys,

i followed this and the other threads a long time.

what i read out since now is that in between there is an open firmware 
available.  now, you want to get/send data from/to the HR20 via a rfm 
module. but why should this be encrypted? the WHY is here missing. since 
now i thought it should be an OPEN firmware? Maybe i didnt understand a 
block or i missed one?

cu,
olly...

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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!

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Mario Fischer Datum: 10.12.2008 16:19
plainblock is just XORed with a bitpattern.
But this bit pattern is different for each packet.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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 ...

Author: Robert (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

I have a problem with my HR20E ordered at Conrad, it is the same problem 
at all three of them:

They work fine in the Full-stroke mode. Yet, in the default-stroke mode, 
radiators stay cold after about three days, even though the HR20E shows 
a higher target-temperature. Removing the Rondostat and turning the blue 
wheel by hand, the radiators get warm. When it gets above the 
target-temperature, they are turned of properly and the Rondostat will 
work fine for another three days or so.

This should not be a battery problem. The batteries are new and 
brand-products, and the Rondostat makes no sign of having a power 
shortage at any point. It should neither be a problem with the valves 
since the radiators get warm when I turn the blue wheel by my self, and 
since the problem does not occur in the full-stroke mode.

It seems to me, that after a few days in the default-stroke mode, the 
Rondostat does not know anymore at which position it is, and does not 
open the valve as it thinks the valve is already open.

Does anyone know a solution for this? In the Full-stroke mode, the 
temperature deviations from the target-temperature are too high since my 
radiators heat up very fast.

Thanks for your answers,

Robert

Author: Frank (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi

just managed to flash the first HR20. I used the Atmel Eval Boarad from 
Pollin modified according to the Evertool LIGHT by Rainer Rakow.
Starting test now...

Is there any readable user manual or anyone working on it?

Robert, i ordered 8 HR20 from CONRAD and had no problems found. Did you 
rewind the blue weel before installing the head? But carefull - its easy 
to overwind!

I read about similar problems in another thread - in one case some coins 
helped to reduce the distance between the nozzle of the valve and the 
regulator pin.

Frank

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Robert:

I have 5 valves (exacly same) and only one of them have same broblem. It 
not depend to HR20 unit, but on valve. With original SW you can only use 
"full stroke" mode. You not able change anything or discover it.

And it is one of reason why I wrote another SW for HR20. In my case it 
is solved.

@Mario Fischer:
I will try discover where it problem tomorow.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
@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?

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Karim L. (louk)
Posted on:
Attached files:

Rate this post
0 useful
not useful
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

Author: Karim L. (louk)
Posted on:
Attached files:

Rate this post
0 useful
not useful
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).

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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 ;-)

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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)

Author: Robert (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi

Thank you for your answers.

@Frank:
I am sure the wheel was on the "all open" position, before I mounted it 
on the valve. I am not sure whether the problem can be solved by coins. 
If the distance would be too large, the pin of the valve would be out 
and the valve open. In my case the valve is closed after three days. But 
still I can give it a try.

@jdobry:
I am not sure I correctly understood what you ment. What is a SW? And 
how did you change it?

Thanks a lot,

Robert

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Robert:
Original software in valve is 2.04 from Honeywell. We don't know how to 
set it via serial line, how to bugug problematic situation etc.

Therefore we wrote complete different SW for this valve. It have some 
extensions for debug and some more functionality. And don't have "cold 
valve" problem as is discoverd by you.

For change SW you needd JTAG programer, see to this thread history.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim L.
I was try your SW 0.2.2.25740 version. And this is result:
- not able to run under MONO, It use too many non implemented functions 
in mono.
- it always use anti-aliased fonts and don't respect setting in windows. 
It is hard to read on hudge monitor with high resolution
- layout have fix size, unable to use bigger window
- About dialog contain information about GPL II license, but where it 
sources?

Thanks for this SW, it can be useful. It's pitty that it can run only 
under MS Windows. Many of us have another system.

Author: Frank (Guest)
Posted on:

Rate this post
0 useful
not useful
@Robert: If you dismount the head you can check the position of the blue 
weel - is the pin all in or all out or in between? You can get mor 
Information when you connect yor PC to the serial port of the HR20. But 
keep in ´mind that ist side is in 3,3V-logic.

By the way, what is the easyest way to connect the HR20 to the serial 
port of a PC? Found this Beitrag "1 Transitor + 2 Widerstände = Verwirrung", 
intended for I2C but should work on RS232 too (?).

@Karim: very fine - it runs on my XP but not yet connected (s.a.).
Could your progy also work on an I2C-bus? I have 25 m cable going along 
every radiator in my flat. It would save me from laying my hands on 
every HR20 twice on each holyday :)

Frank

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Frank:
easyest way to connect the HR20 is use MAX232 for serial line or another 
cheap solution is use USB cable with USB->serial convertor for mobile 
phones. (Ulder mobile phones don't have USB and this cable not contain 
level changer for RS232 line, but use 3.3V logic). Example is (tested) 
KQ-U8A cable ( http://stephane.aubert.free.fr/KQ-U8A/ ). I buy each by 
aprox 3.20 EUR


I2C-bus is not supported on OpenHR20 software. Except this I can't 
recomend I2C bus over all valves. This bus is not protected to noise and 
cables will be too long.

Author: Frank (Guest)
Posted on:

Rate this post
0 useful
not useful
Hey Karim

first look on your tools is all great. It works fine - but: were can i 
select the temperature for each on/off-time pair (snow/moon/sun on LCD)?

Great work!
Frank

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: Frank (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim
An I²C-Bus slave for Attiny was in the last issue of Elektor in germany: 
http://www.elektor.de/jahrgang/2009/januar/i2c-sla...
The best is, no special port is needed for it. We could use any line - 
especially the serial lines, replacing the RS232 by the I²C.

By the way, in the same issue there is an article about to conntect a 
RFM12 to AtMega.

@jdobry
I²C-Bus as a house-bus you find in Funkschau 9/2004 or at 
http://www.hauscomputer.gmxhome.de/. It seems very simple.

My idea was to connect each rondostat with a power-line instad of 
batterys, I²C-Bus for Comunication and a PIR-switch. The later is to 
overide energy-save-mode if a person is in the room (e.g. school ends 
earlyer). PE2 is still free!?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I2C have some problems. Generaly it have open-collector bus. This mean 
that logical "1" is defined by resistor. On long cables, it have slow 
edges and mainly it have zero protection for noise. This problem can be 
fixed by active current injection on level change, but it need special 
chipset. Except this we can't use hardware support on HR20, because it 
need pins PE5 and PE6. Pin PE5 on HR20 is connected to ground, and it is 
not possible disconnect it without remove chip. SW implemented I2C is 
possible but I thing that RS485 is better for cables in home. RS485 HW 
is extremely simple, see to 
http://www.datasheetcatalog.org/datasheet/maxim/MA...

But you can to do anything that you want, Source is GPL and you don't 
have any restriction. But because I have not cables, I must use wireless 
comunication.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Experience after 4 weeks on 4 valves

- valve have more actions compare to original SW. It must be improved. 
Have anybody any idea?

- battery low detector is not sufficient. At low battery SW usualy 
detect flase Error3 before battery low. I have some ideas how to imrove 
it, but your ideas is also welcome.

- current temperature measure convert each measure to tempereture and 
calculate average from last minute. Result after average have better 
precision than is measured (overscan). But it can be reason to many 
action on valve. I will try prepare version with average from RAW ad 
data and calculate temperature from result. Overscan can be used or not, 
i don't know what is better.

Author: peppe (Guest)
Posted on:

Rate this post
0 useful
not useful
HI @ all,
i have some questions.
is there an bootloader also implementated, so it is possible to flash a 
new Firmware over the Uart? The problem is, that i have the 
JTAG-Ice-MKII debugger only for the next seven days, and than i have to 
give it back.

The next think, i want to know. Is there a posibility to use the SPI,
i want to connect a can tranceiver to it, i saw that the pins PB0 to PB6 
are use for the buttons and the engine.

wbr
Peppe

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@peppe: It is possible use bootloader to flash this device. But I am do 
not use it.

SPI: It is near ti impossible reconnect buttons to other pins. Therefore 
only one chance is SW implementation of SPI protocol. See to branch for 
RFM12 wireless communication (on development, not work now)

Author: Frank E. (vierauge)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Frank E.

If you are not using RS485, PE2 is free. (used for debug, disable it on 
debug.h)

Timer1 is free and it is disabled (you must remove this power save 
feature)

I am not using simulator, just JTAGICE debuger connected to real HW. But 
on simulator you can manualy change pin status when SW is stoppend, or 
you can create input files, see to atmel docs. But I thing, that it is 
too complicated.

Jiri

Author: Thomas V. (thomas_v)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Thomas V

Modification for Thermotronic would be nice. Please contact me by email 
for access to SVN or send me patch set.

Schematic is here 
http://www.mikrocontroller.net/attachment/29357/sc...

Author: Björn B. (elmo)
Posted on:

Rate this post
0 useful
not useful
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

Author: Gammla N. (gammla)
Posted on:

Rate this post
0 useful
not useful
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

Author: Frank E. (vierauge)
Posted on:

Rate this post
0 useful
not useful
@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...

Author: Björn B. (elmo)
Posted on:
Attached files:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@ Björn Biesenbach
nice tool! Do you wan't to place this project into SVN? If yes contact 
me by email.

Author: Björn B. (elmo)
Posted on:

Rate this post
0 useful
not useful
Ok the tool can now be found in the svn under tools/

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I made hudge experimental change in motor controller. Version before 
this revision use constant PWM for open and another constant for close.

This experimental revision try to use constant speed and try to control 
PWM.

Benefits:
- we can use slower movement and it is more quite
- I hope that it will more resistant to false "Error3" detections
- speed is independent to battery voltage

Second experimental change:  limitation of "P" part of valve position 
controller. "I" part of this controller will found valve position inside 
regulation area. I hope that it will reduce motor movement outside valve 
regulation area. It save battery. It use config.P_max eeprom constant 
and it can be improved.

Because it is EXPERIMENTAL, it is not in SVN main trunk. If you want to 
test it, please use "Rev 152" from rfmsrc branch. Change "#define RFM 1" 
to "#define RFM 0" in config.h


If you want to help with development, PLEASE SEND ME LOGFILE FROM YOUR 
VALVE. Thans.

Jiri

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I forget to one warning. Rev 152 have changed numbers of settings in 
eeprom. Please see to eeprom.h

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Rev  152 and 153 in branch rfmsrc is buggy (measure wrong motor 
calibration, will be fixed today, please wait.)

Motor speed is not significant for valve position. But old versions use 
constatnt pwm for control motor speed. This has this problems:

- high pwm constants are noisly
- high pwm constatns have hard touch on the end of motor movement range
- low pwm have problem with false "Error3" detection (motor can be too 
slow)
- speed depend to actual battery voltage, therefore is near to 
impossible find this constants for open/close

Jiri

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Bug on motor calibration is on "manual callibration". It is fixed for 
rfmsrc branch in Rev 155

New motor speed controller looks nice and better than original constant 
PWM.

!!! Bug is not fixed on main trunk now !!!

I wan't to find maintainer for version 1.00 (main trunk)
We need to integrate changes from Rev 155 (bug fix)
We need to integrate changes from Rev 152,153 (motor speed controller)

Any volunteer?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello,

Motor speed controller is in SVN (Rev 158 in trunk / Rev 157 in rfmsrc).
If you can, send me log frou your valve/HR20 combination.

- If you will have problems (heating still cold or too hot) try to 
increase config 0x0b

- If your motor speed is too high decrease config 0x12.
- If your motor speed is too low increase config 0x12.

Jiri

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I have best results with "I" constatnt  = 1
You can set it in service menu or by COM (S0601<enter>)
Current default value is 3

Can you confirm this result? I will change default value.

Jiri

Author: Björn B. (elmo)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Bjoern:

I need complete log (motor calibration, and all motor movement, both 
have some significant information)

About compilation: I know only gcc version, but significant is also 
version of AVR lib. Version? Distribution? You can try to disable 
"#define  TASK_IS_SFR 1" to 0 (disable interrupt optimizations) and 
replace "OPT = s -mcall-prologues" to simple "OPT = 2" in Makefile

Jiri

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
If you want to use rev 152-158 please change configuration 0b to 0x32 
(hex) It contain bug (Valve can still close, same bug as original SW see 
Datum 21.12.2008 13:28 in this thread). I know why and I have solution. 
It will be fixed later.
Jiri

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim L:

I thing that your tool in SVN will be welcome. Please add it into 
"tools" folder.


@All:
Please try Rev 159 and send me log. Current default "P" limiter (config 
0b) in SVN is 100 (0x64 hex). But I want to test it with smaller value 
(ex 32 = 0x20 hex). Please change it.  This will reduce motor movement 
outside live regulation arrea, but it is not fully tested. Bug from last 
rev is fixed (I hope).
I want to have log file from 10 hours or more (integration of controller 
error is slow)

Jiri

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim L: switching times working without problem for me on all 4 walves 
with OpenHR20 SW. It has not in MANU mode? Strange, it may be new bug?

Thermotronic: I thing that it works, but I haven't this HW to confirm 
it. This modification is done by  Thomas V. and I only review it. Main 
difference from HR20 is missing communication (pin is used for something 
else) and no PWM control for motor (haven't support in HW).

Can somebody confirm to me that original SW in Thermotronic not use SW 
implementation of motor pwm (HW is not possible)?

Jiri

Author: Thomas V. (thomas_v)
Posted on:

Rate this post
0 useful
not useful
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

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: reiffert (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi there,

I'm going to try all the stuff as soon as my JTAG Adapter arrives!
So far it sounds soooo nice.


Meanwhile ...

Do you think it's possible to take a new software branch for
having more than 4 switching times, let's say 6 or 8 switching times per 
day?
Additionally I'd like to have more than 2 temperatures, say 4 
temperatures,
e.g.

07:00-09:00   21 Celsius
09:00-16:00   19 Celsius
16:00-22:30   21 Celsius
22:30-07:00   18 Celsius

How can this be achieved so that it doesnt conflict with all the 
radio/wireless approaches there are?

Please gimme some helping hand, for what I've seen so far, I can change
the software in C with some version of the AVR studio... Am I right?

Having more than 4 switching times, together with more than 2 
temperatures
will surley let me reprogramm all the setup stuff etc.

What do you think?


Kind regards
Thomas Reifferscheid

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: Thomas V. (thomas_v)
Posted on:

Rate this post
0 useful
not useful
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

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Björn B. (elmo)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Here is an updated version of the hr20cmd tool. It has the ability to 
get and set the timer slots now.

Björn

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Mario:
4.2.
- We need broadcast date/time for encryption also.
- boot strap is not problem. It happen only ONCE afret battery change 
and price is 15mA on 30 second (maximum) It mean 0.002mAh - not problem
- sync packet on 00 and 30 is not exactly same. It is needed for force 
communication from selected slave. Time slot 31-59 can be used as block 
for one slave long communication.
- use random number rater than time is worst because it complicate 
protocol, try it and you can see. For security is ony byte random number 
nothing. Two bytes looks better, but if false feeling 
(http://en.wikipedia.org/wiki/Birthday_paradox)
- 4 byte MAC code is nothing, you must calculate energy. Cost is 
4.6e-5mAh per packet. This mean that 132000 status packets (one year 
average) take 6mAh. It is nothing.
- For save energy we MUST have very accurate time synchronization. 
Enable receiver for 1 second have same cost like send 360 bytes!

5.2 I can't agree, that it not improve security. It is no way how to 
calculate Km from Kenc or Kmac. This mean that if you have Kmac you are 
not abble calculate Kenc nad vice versa.

CRT is misstyping

Jiri

PS: It is not pollite for others discus this document on this thread 
when it is not public now. (it is not secret, we will add it on SVN 
later)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
New revision 175:
Changes:
- controler use new configuration for linear "P" gain
- controler configuration for quadratic "P" gain
- new config option (0a) for min valve position (default 30%)
- new config option (0b) for max valve position (default 80%)
- optimization

Improvemets:
- linear/quadratic controller have best result for me (send me your log)
- valve min/max setting save batteries because not all range of valve is 
active. If you have problems (valve still open or close) please change 
it. I am not abble to find algorithm to find it automaticaly (every idea 
have some condition when must fail. I belive that range 30%-80% is 
correct for major part of valves, but you can set narrower range and 
save more battery energy.

If nobody found any problem I plan release Rev 175 as STABLE version 
1.00.

If you want to do something:
- doxygen comments need improvement to generate USER DOCUMENTATION
- create Thermotronic patch for rfmsrc branch
- create schematics picture for RFM12 master HW (text specification is 
in SVN)
- I want to find maintainer for stable 1.xx version. I have last one 
HR20 without RFM12 modification and I will not have HW for test this SW.

Author: Mario Fischer (superdude)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
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)) 
is correct:

1) please don't remove branches around macro body or use ";" on end, it 
make problems if you use macro in expression
2) PCINT0_vect() is dummy call interrupt to insurance that no interrupt 
will be lost (signal is level based, interrupts is on edge)
3) If you want to remove this false warning, add this
void PCINT0_vect(void);
into rfm_config.h


Reboots: I thing that you are use external power not bateries. Right? 
Problem is that old code has problem with motor movement with older 
batteries and create false positive "E3". Therefore from Rev153 motor 
have "I" controller for speed stabilize and motor startup use 
config.motor_pwm_max value. This works amazing on batteries, but worst 
with external power (HR20 have not any capacitor for absorb power shock 
from motor start because it is not needed with batteries) With external 
power you must add big capacitor into power lines. If you use USB as 
power source it is worst, because USB have current limitter (USB 
specification) and power line shock is hudge.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
New release candidate  for ver 1.00 is Rev 180.
Please test it.

Changes:
- fix setting to AUTO mode

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Information about wirelles:

Rev 181 is just proof of concept for bi-directional communication. It is 
not usable for real live, I must refactor some code and add real 
functionality.

Jiri

PS: I am not abble maintain 1.00 versions after release. I have not Hw 
and I have not time also. Any volunteer for maintain it?

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Jörg Becker: thank you for feedback. I know that default setting after 
last modification is not perfect. It works for me (used on 4 rooms, 
bathroom still use original SW for comparation)
Karim have true, we have to many different conditions (valves rooms etc) 
but too less data for final setting (send me you log).
You can try change setting:
PP_Factor (05): proportional gain for quadratic error
P_Factor  (06): proportional gain for linear error
I_Factor  (07): gain for integrated error

Try increase I_Factor, it can solve problems with small rooms. If you 
can, send me log file.

RFM12: this state still in pre-apha state. Too many parts is changed, 
but not finished. Could you send me your modification on RFM12? May be I 
can use some part from it. Current code will need some special SW/HW 
called "master" to control wireless network and for encryption. It make 
it incompatible with simple wireless listening and loging.

@Karim L.: I fully agree, that current controller part can be improved, 
but it need some suficient matematical model. We not have it.

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
I have a problem with version 180.

I had the valve behind a curtain. So it was very hot but the valve was 
full open! The temperature was shown at 9 °C (I measured about 40°C with 
another thermometer).
I pulled off the HR20-head and watched the temperature, while it cooled 
down. It decreases from 9 to 0.0 °C and then it jumps to 25.5°C (in my 
opinion the real temperature at this time).

Is there a problem with high temperature measuring?

Ronny

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@rhb: thanks for bug report. I was repeat it and this bug is real. I 
will fix it.

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Rev 192 is bug fix for measured temperature > 25.5.

- temperature was measured correctly
- Rev192 is new release candidate for 1.00 version

@rhb: I was found bug only on LCD value, can you explain it better? What 
was valve value on LCD on "%".

Jiri

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim L: internaly used temperature and RS232 log is SAME values. It is 
past 15 second average.

Only one exeption is debug output (DEBUG_PRINT_MEASURE). This is RAW 
values before 15second average. This debug is DISABED in default 
compilation.

Author: Artax (Guest)
Posted on:

Rate this post
0 useful
not useful
@Jiri:

Please take a look to the following source code lines.
From my point of view the type of the variable valve is changed too 
often and may force neagative effects.
controller.c line 57:
static uint8_t pid_Controller(int16_t setPoint, int16_t processValue, int8_t old_result);

controller.c line 70:
int8_t CTL_update(bool minute_ch, int8_t valve) {

controller.c line 137:
valve = (int16_t)pid_Controller(calc_temp(temp),temp_average,valve);

controller.c line 225:
static uint8_t pid_Controller(int16_t setPoint, int16_t processValue, int8_t old_result)

Artax

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@ Artax:
All this lines is correct:
temperature can be measured - unit is 1/100 degree(int16_t)
temperature can be wanted - unit 0.5 degree (uint8_t) - calc_temp() 
macro change it into 1/100deg unit and int16_t type.
valve position have int8_t variable and range 0-100

PS: I know that it is not best practice change types often. But we don't 
have a choice, because it was save many bytes in RAM and Flash. Current 
situation : incomplete RFM code take 15102bytes form 16KB Flash. This is 
one of many "ugly" parts of code. Most ugly is non existed division into 
layers and interfaces between this layers. We dont have space for it.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@ Artax:
signed values on valve is remaining code from old valve renage (-50 to 
+50).

It can be cahnged to uint8_t
Ex:
uint8_t CTL_update(bool minute_ch, uint8_t valve);
And it can save 4 bytes in flash.

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
@jdobry

measured temp is ok in rev. 192, thanks for your very fast response!

The overheating was my fault, your question was the right hint: the 
default min. valve position in eeprom (30%) was to high for this small 
room and valve. Now I set it to 5% and everything is ok.

Ronny

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@rhb

Valve limitation is not depend to room size but only on valve type.
Every valves have wider range than active part. This is for my valves.

  0-45  - valve is closed, when I try go from 45 to 0 force for movement 
growing and this have not efect for regulation but big effect to battery 
live and gears abrasion.

  45-70 - this is active part of valve, in this change valve position 
have effect to water stream

  70-100 - valve is open, movement of valve have effect near to nothing.

All this values are not exact and it depend to valve type.

Author: Axel (Guest)
Posted on:

Rate this post
0 useful
not useful
"All this values are not exact and it depend to valve type."

Not only valve type but even more on the pressure the water pump for the 
heating water builds up.

Especially modern self adjustable water pumps can be a real nightmare in 
this sence as the pressure in smaller rooms can be quite different 
depending on how the other rooms behave.

I had the situation where the water pump would detect night shutdown for 
some reason and reduce its power significantly without obvious reason.

Turning this feature off reduced my problems, however I did not even 
know it had this feature as I had to open the pump to get to some small 
dip switches to control this.

Axel

Author: Thomas Peterson (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello

I have buy an other HR20

www.thomas-peterson.de/h20/front.jpg
www.thomas-peterson.de/h20/back.jpg

I will draw a new circuit  diagramm for this.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Thomas Peterson:
It looks like Thermotronic.

Compare it with this picture:
http://img407.imageshack.us/img407/8021/thermotron...

Schematics is here:
Beitrag "elektronische Heizungsregelung mit Thermotronic"

Author: Reinis (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello Jiri, Karim L. and the other team-members from the 'development 
team'.

Very good, phantastic project, I´m not a electronic specalist and a 
managed to flash 3 hr20 (original v2.04) with the guidance in this 
forum, (currently I use the latest F0.97 rev.192 without rfm) for me it 
works fine so far. But i have also an older hr20 (original v1.xx) and 
with the same interface cable it was not possible to get a connection, 
it works only with the newer HR20.

For setting the hr20 i used the openHR20suite dated 22.12.2008) from 
Karim L. The program works in general fine, sometimes I have a longer 
waiting time for read / write the data’s but maybe this is related to my 
interface cable.

If a new version of openHR20suite is available I would be interested to 
test it. I had some problems with the valve range adjustment (30-80%) in 
openHR20suite, this I could not find in the openHR20suite.

many thanks and best regards
reinis

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Reinis (Guest)
Posted on:

Rate this post
0 useful
not useful
@karim,

that would be very nice if you can provide an updated Version of 
openHR20suite matching the latest eeprom layout.

Can you give me a hint how i can log the data's from HR20 (Valve Pos., 
SW Temp. and Act. Temp.)i saw some recordings?
Was this done with openHR20suite (e.g. i have a recorder which would 
work with DDE-Link if you provide this to other applications) or is it a 
other program?

thx + br Reinis

Author: Ulrich Wilkens (xxbsd)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Ulrich Wilkens:

Thanks for bug report!

1) RTC_Setxxx and overflow: It look like bug in compiller. I know that 
code mix signed and usigned types. And it is correct for 8-bit 
aritmetics. For example minute 00-1 is 255 and 
(uint8_t)255+(uint8_t)60=59. But compiler use 16 bit aritmetic to add 60 
and I don't know why ((255+60)%60=15). This function:
void RTC_SetMinute(int8_t minute)
{
    RTC_mm = ((uint8_t)minute+(uint8_t)60)%(uint8_t)60;
}
is compiled wrong to:
  37                 .global  RTC_SetMinute
  39                 RTC_SetMinute:
  40                 .LFB8:
  41                 .LM3:
  42                 /* prologue: frame size=0 */
  43                 /* prologue end (size=0) */
  44                 .LVL2:
  45                 .LM4:
  46 000e 90E0          ldi r25,lo8(0)
  47                 .LVL3:
  48 0010 CC96          adiw r24,60
  49                 .LVL4:
  50 0012 6CE3          ldi r22,lo8(60)
  51 0014 70E0          ldi r23,hi8(60)
  52 0016 0E94 0000     call __divmodhi4
  53 001a 8093 0000     sts RTC_mm,r24
  54                 /* epilogue: frame size=0 */
  55 001e 0895          ret
  56                 /* epilogue end (size=1) */
  57                 /* function RTC_SetMinute size 9 (8) */
Compiler use 16 bit aritmetic to adition

but this code
void RTC_SetMinute(int8_t minute)
{
    RTC_mm = (uint8_t)(minute+60)%60;
}
create correct result:
  37                 .global  RTC_SetMinute
  39                 RTC_SetMinute:
  40                 .LFB8:
  41                 .LM3:
  42                 /* prologue: frame size=0 */
  43                 /* prologue end (size=0) */
  44                 .LVL2:
  45                 .LM4:
  46 000e 845C          subi r24,lo8(-(60))
  47                 .LVL3:
  48 0010 6CE3          ldi r22,lo8(60)
  49 0012 0E94 0000     call __udivmodqi4
  50 0016 9093 0000     sts RTC_mm,r25
  51                 /* epilogue: frame size=0 */
  52 001a 0895          ret
  53                 /* epilogue end (size=1) */
  54                 /* function RTC_SetMinute size 7 (6) */
Could me somebody tell WHY?

2) DEBUG_IGNORE_MONT_CONTACT - fixed, thanks
3) wheel error, I was know about this bug, but it has not priority. 
Thanks for bug fix.

*****************************
fixed in Rev 195 version 0.98
*****************************
This fixed code is not tested, tell me if it solve problem.

Author: Karim L. (louk)
Posted on:
Attached files:

Rate this post
0 useful
not useful
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

Author: Reinis (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim,

i just tried your latest version of openHR20suite, excelent !!!

It works much faster with read/write as the older one i used and data-tx 
is now much more reliable.
Also your idea with the red error line is good.

thanks and br
Reinis

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
Karim,
thanks, works perfect for me!!!

BR,
Jörg.

Author: Ulrich Wilkens (xxbsd)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Karim L.

For not used timers I need any invalid time. x5a0 is also correct.

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@Jiri,

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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I was try the best algoritmus with my valves in my flat. From feedback I 
know, that it is not perfect for everybody. (info from Karim L.) I will 
be changed soon (this wekend probably).

I will describe better current situation:
e = error = current_temp - wanted_temp
temperatures is in fixed point, unit is 1/100 degree

        abs(e)*e*PP_Factor/256 + e*P_Factor + Is*I_Factor
valve = ------------------------------------------------ + 50
                            256

where "Is" is integrator with this limitter:

                                    256*50    
   maximum Is change in one step = --------
                                   P_Factor
    
   if ( ((current_temp<last_temp) && (current_temp<wanted_temp)) 
      ||((current_temp>last_temp) && (current_temp>wanted_temp))) {
      
       // update integrator
       Is+=e;   
   } 

You can see consequences:
 - if current temperature is not changed from last, integrator is not 
updated
 - if temperature grow and current_temp<wanted_temp (and vice versa), 
integrator is not updated

This limitation I was add to limit motor movement around wanted 
position. Without this, near to every 4 minutes SW will move motor back 
and forth. It have devastation consequence for battery live.

Another reason is hijacking of integrator. Why? Please fancy this 
situation: wanted temperature is 17 degree, real temperature is 19 
degree, we have opened door from heated space. In this situation, valve 
is fully closed. But without limitation, error value must be -3 (-300 in 
1/100 deg unit) and integrator will integrate this value every step. 
Result after few hours is clear. Integrator will be on limit and not 
allow motor movement when you change wanted_temp.

Valve changes < (pid_hysteresis/265) is ignored (noise protection) 
(default pid_hysteresis is 120)

At this moment I thing that this limit conditions is too hard.
----------------------------------------------------------------
@Jörg Becker:
Is: is integrated value
ffbc mean -68 decadic. If you increase I_Factor, valve must be closted, 
see up to formula. Small changes of I_Factor needn't change of valve 
because it's smaller than (pid_hysteresis/265) Try calculate formula 
from up.

----------------------------------------------------------------

What I can do? (and probably will do):

- I can change comparation in "i" change consequences from ">" to ">=" 
(and vice versa) After this it will be more sensitive to hijacking of 
integrator.

- Itegrator can be reset after every change of wanted_temp. It is usual 
in numeric PID controllers. But after this change temperature 
stabilization take more time. It can be improved with default "zero 
error" position in EEPROM (current value is hardcoded 50% - see to 
formula, new default value can be around 55%) (@Karim L. > it need 
change of EEPROM layout)

----------------------------------------------------------------
PS: If this explanation is not clear don't worry ask me.
Jiri

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I forget in "What I can do?" part: (update)

- I can change comparation in "i" change consequences from ">" to ">="
(and vice versa) After this it will be more sensitive to hijacking of
integrator when valve is fully closed or open. And it will better to 
repair temperature offset. It can be abble repair hijack, but it take 
long time.

- Itegrator can be reset after every change of wanted_temp. It is usual
in numeric PID controllers. But after this change temperature
stabilization can take more time. It can be improved with default "zero
error" position in EEPROM (current value is hardcoded 50% - see to
formula, new default value can be around 55%) (@Karim L. > it need
change of EEPROM layout)
Reset interator will solve part of hijacking problem. After this 
"hijacking" is possible only for constant wanted_temp without any 
changes in long time when valve is fully closed or open. I don't have 
any idea to solve this. Motor calibration on Saturday 10:00AM will 
cancel this hijack, but it can be too late in some situations.

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
"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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello

How can i resive the data from termotronic?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Thomas:

Thermotronic version of SW don't support serial communication due to 
hardware limitation. Serial line pin is used for another function.

You can have two choices:
- wireless comunication - rfm12 - now exist on pre-alpha state, it is 
not prepared for end user, wait aprox 1 month

- prepare another type of communication or simulate serial line on SW 
(not exist now)

Jiri

Author: Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
@jdobry

Ok when i buy the rfm12 and connect it, what must i do on the receiver 
site?

Have you an Link?

Thanks for all :)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
OK special thx :)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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.
***********************************************************

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@Jorg:
OPPS! Thanks for bugfix. You are right, it is bug.
Jiri

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
RTC_IsLastSunday bug was fixed in Rev 207
thx: Jörg Becker

Jiri

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
"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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Bronco (Guest)
Posted on:

Rate this post
0 useful
not useful
Apologies if this is in the wrong forum, but I would like to load up the 
software to my HR20.

What is the easiest way to connect to pc? and what are the details of 
each of the pins which I must connect to RS232? thanks

Author: Guest (Guest)
Posted on:

Rate this post
0 useful
not useful
@Bronco:
To load up the software you need a Programmer that supports JTAG, e.g. 
AVR Dragon: 
http://www.atmel.com/dyn/Products/tools_card.asp?t...

The details of the pins are described in the documentation.

Author: Bronco (Guest)
Posted on:

Rate this post
0 useful
not useful
Great. I will look up JTAG. I presume then I will need a JTAG to Rs232 
if I want to communicate from pc to rondostat?

Author: petero (Guest)
Posted on:

Rate this post
0 useful
not useful
The software is not downloadable from sourceforgenet. Has the project 
been moved elsewhere?
thanks.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Project is not moved. But we not release any final version. You must 
download it from SVN.

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Bronco (Guest)
Posted on:

Rate this post
0 useful
not useful
ok. got the avr dragon.

could someone guide me on the steps to connect to the HR20?

I assume

a) connect JTAG cable from AVR Dragon to HR20
b) use AVR Studio (not sure how)
c) load up hex file from svn repository to flash HR20

could someone help me with some details:

a) do I need to set some JTAG pins?
b) If I want to communicate with HR20 without flashing to getState is 
this possible? or do I need to flash (basically I am scared of flashing 
until I know exactly what I am doing).

regards

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
@Jörg Becker:

I saw the same situation, but I thought, that was my fault, because I 
played with the sources and sent the log/debug messages every second. So 
I thought because of this the motor loose steps.

Unfortunately I don´t have any logs, because everything was fine until 
after a new calibration...

Ronny

PS: Has anyone also my (strange) situation:
I have   long-distance heating, but without a heat exchanger in my house 
- only a valve, that closes the whole system (every heater in every 
room), if  the temperatur of the recirculation water is too high. That 
means, if one heater (in my case in the bath-room) produces too high 
temperature in the recirculation tube, the valve closes and also the 
heater in the the living room gets cold. I cannot change this behavior, 
because we rented this flat.
So I tried the following: I putted a second temperatur sensor to the 
HR20 and tried to control the recirculation temperatur of any heater 
independently.
Has anybody suggestions how/where this can be done? My idea: decrease at 
the end of the function CTL_update the valve value proportional to the 
recirculation temperatur.

Author: Ulf Dürhammer (ulduerham)
Posted on:

Rate this post
0 useful
not useful
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

Author: Ulf Dürhammer (ulduerham)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
!

!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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Update to Rev 222 is RECOMENDED.
It was fix problem with "On" setting.

PS: Motor position measure will be improved later

Author: rhb (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hello,

@Jiri Dobry

here are a logfile about the loss of pulses problem. I measured it from 
22nd march at 00:00 till 23rd of march ~21:00. The valve was calibrated 
at the beginning of the measure. Now the log says 5% valve position, but 
the service menu (pressing 2 times -C-) says 10%.
The environment: a small bathroom with a big heater and a strong spring 
in the valve (means: if I pull the head from the valve the valve opens 
itself - I have other valves in my flat, where the valve stays at the 
momentary position, if I remove the head). I have very agressive 
settings at this valve: update every 1,5 minutes and a small differenz 
between wanted/actual temperature.

hope this helps to find the problem

Ronny

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
what I forgot:

this is release 198

Ronny

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello Jiri,

at first: thanks for your incredible work at this project!

I´m not so familiar with microcontroller programming and it´s hard to 
understand for me what you did in the program - but I´m learning... And 
so I have to show respect to your work.

Unfortunately I had to recalibrate my bathroom HR20 before I read your 
posting, so that the error isnt there now. I made a T08 and got 
T[08]=01dc and for T[09]=00e5.
A log line is now
D: d2 24.03.09 20:25:04 A V: 48 I: 2349 S: 2400 B: 3052 Is: 10aa
and the valve position is identical in the service menu. Maybe I have to 
wait until the error occurs again, for my experience this will be in 2 
days. Therefore I didn´t flashed your new version, because  another 
hidden problem could be there

Ronny

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello,

here is the problem on Version 198 again:
Log-File says 5% valve position and service menu says 10%!
D: d3 25.03.09 22:43:21 A V: 05 I: 2525 S: 2500 B: 3047 Is: ef56 X
T[08]=01f0
T[09]=0033
D: d3 25.03.09 22:44:00 A V: 05 I: 2585 S: 2500 B: 3044 Is: ef56
D: d3 25.03.09 22:45:20 A V: 05 I: 2548 S: 2500 B: 3048 Is: ef56

Ronny

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello Jiri,

I will update to 225 now.
I changed the following eeprom-value:
/* 08 */ temp_tolerance; to 50h
/* 09 */  PID_interval; //!< PID_interval*5 to 10h
/* 0a */ valve_min; // valve position limiter min ;to 30h
/* 0c */ valve_max; // valve position limiter max;  to 3ch

and s:ome strange settings - I cannot remember, that I changed this 
values
/* 0d */ motor_pwm_min;   //!< min PWM for motor;   to fah
/* 0e */ motor_pwm_max;  //!< max PWM for motor;  to 1e

Ronny

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jiri Dobry (jdobry)
Posted on:

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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jiri Dobry (jdobry)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Wireless aplication screenshot

Author: Jiri Dobry (jdobry)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Wireless aplication screenshot (false window close detection problem)

Author: Jiri Dobry (jdobry)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Wireless aplication screenshot #3 (timers)

Author: reinis (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello jiri,

your last inputs are very interesting. I think i have to upgrade to a 
wireless version now....

I use at the moment Rev. 192 and since 3-4 days i have problems with the 
time, each day the time changes with one additional hour (issue with 
sommertime ?? the actual time is e.g. 10:00 but HR20 shows 11:00 ,next 
day 12:00 and so on).

regards
reinis

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: reinis (Guest)
Posted on:

Rate this post
0 useful
not useful
@jiri, regarding the 1 hour timeshift, i think it has something to do 
with the follwing function:

void RTC_AddOneSecond    (void)

Add one second to clock variables

Note:
        * calculate overflows, regarding leapyear, etc.
        * process daylight saving
              o last sunday in march 1:59:59 -> 3:00:00
              o last sunday in october 2:59:59 -> 2:00:00
                ONLY ONE TIME -> set FLAG RTC_DS
                reset FLAG RTC_DS on November 1st

over a longer time/several weeks the time was always correct on all of 
my hr20. The problem started only last week and on all of the three 
hr20. I resetted the time on the next day i had again a 1 hour offset 
but only until today (summertime change). This morning the 1 hour 
timeshift was not there anymore and i did a manual set to summertime 
(daylight saving).

regards
reinis

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@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.

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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).

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: rhb (Guest)
Posted on:

Rate this post
0 useful
not useful
I have until now the problem with loss of steps (original version 225).
I think that because of the strong spring in the valve the real valve 
position shifts a little bit every time the valve is closed.
So I want to correct these "shift values" by a "partial" calibration to 
save battery.
 That means: I want to correct the actual valve position only by driving 
the valve to the real open position (until the motor stops).

Has somebody a hint for me?

Ronny

PS: I have solved my problem of the recirculation temperature (see Post 
on: 2009-03-17 13:38)
at the beginning of CTL_update I save lastProcessValue and sumError. 
After calling of pid_Controller I compare the recirculation temperature 
with a value stored in eeprom. If the temperature is too high (with 
hysteresis) , I close the valve and restore lastProcessValue and 
sumError from the saved values. This works for me in a reasonable way...
But the problem of loosing steps exists also with the original software 
from the SVN.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Author: Ronny H. (rhb)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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)

Author: Ronny H. (rhb)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Rev 234 contain paranoid filter for temperature measure (noise 
cancelation)
You can try it

Jiri

Author: Ronny H. (rhb)
Posted on:
Attached files:

Rate this post
0 useful
not useful
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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: Ronny H. (rhb)
Posted on:
Attached files:

Rate this post
0 useful
not useful
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

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: torrz (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

the RF-Modul sends at 433 MHz and you need a master to controll the 
units?

Maybe the "Betty Remote" can be used to control the single units (or 
all).
It has a cc1100 included.

Take a loot at (german only):

http://bettyhacks.com/wiki/index.php/Main_Page

Greets
torrz

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
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

Author: puchti100 (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello,

first a big respect to all members in this forum which do a great job to 
developing the new firmware.

I was looking for an alternative and found a way to control my HR20 by 
my iPhone.

Here a brief description:
I use a master (ATiny2313) and a slave (ATiny2313) which communicate per 
radio (RFM12 modules) bidirectional.
The HR20 is connected to the slave and the iPhone communicates via the 
master with the HR20. To set the temperature on the HR20 the uC (slave) 
is connected parallel to the encoder-pins of the HR20. To display the 
set and the current temperature the uC (slave) receives the information 
via the HR20-RS232-connector. Then the slave transmits the values to the 
master and then to the iPhone.

For a better understanding watch:
Youtube-Video "How to control a HR20 thermostat per iPhone"

It's only the first experimental step and the development is going on 
(pcb layout, control more then one HR20 and so on). But it works.

Many greetings,
puchti

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@puchti100:

I thing that control with WEB interface is more comfortable. Please find 
snapshots in this thread (example 
http://embdev.net/attachment/48705/status.png). It also works on iPhone, 
I was test it. It need any PC or embeded linux based router (it is cheap 
and power efficient)

But you can create complete another solution, it is your choice and your 
time.

Alternate SW you can drive directly via serial line; you don't need 
connect wires to encoder (It can work only on one encoder position as 
you know)

PS: How you connect "master" (ATiny2313) and iPhone?

Jiri

Author: puchti100 (Guest)
Posted on:

Rate this post
0 useful
not useful
At my home I've been controling all my audio and video equipments and 
also lights per iPhone since one year. I use the iPhone app "CF iViewer" 
and the controller of the manufacturer Crestron. It could also be a 
PC-application, web interface or a Touchpanel-PC.
In the past I had the wish to integrate the HR20 into "my system". 
That's why I looked for a way to do this.

I added a schematic to show how the communication works.

puchti100

Author: puchti100 (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
sorry! here the schematic...

Author: puchti100 (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
sorry again... to fast...
here the correct schematic (copy-and-paste mistake in the HR20-symbol)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@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.

Author: Emmbeggs (Guest)
Posted on:

Rate this post
0 useful
not useful
good evening everyone,

Can someone please tell me where a user can find generic celebrex online 
without a prescription?  I've been referred to 
http://www.drugpricegrabber.com but I'm unsure how to determine whether 
their site is trustworthy.

Author: Bronco (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

I have connected the rondostat to avrisp, via JTAG cable.

I am trying to use AVR Studio.

Which Amtel chip does the rondostat have? How can I check?

thanks

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Chip is ATmega169P. Programmer can read and check chip signature without 
programming.

Author: davidfat (Guest)
Posted on:

Rate this post
0 useful
not useful
I'm about to buy some HR20s to join this very interesting HR20 
development. However, I got a few questions.

1) there is HR20E and HR20N. The HR20N seems cheaper. What's the 
difference? Are they both ok for OpenHR20?

2) are there different versions of HR20? are they all ok for OpenHR20? 
(like the Linksys WRT54G with a lot hardware difference for different 
versions)

3) I plan to add a Zigbee tranceiver. Has anyone already done this? The 
PCB size is about 20mm x 30mm x 3mm. Is there such room inside the 
valve?

Many thanks
David

Author: davidfat (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

This thread seems a bit quiet recently, maybe, because the weather is 
still warm and there is not much need for heating.

Anyway, after a few days research, I plan to do the following based on 
the current code/design;

- Add a different wireless transceiver (client). It is going to be an 
A7105 based transceiver. The reason for different transceiver is that it 
works at 2.4G and hence smaller antenna and faster data rate. Also, it 
takes 3 wire SPI instead of 4. So I can use the PE2 (Sorry about the PIR 
idea. But I think it can go with another A7105 transceiver.), RXD and 
TXD. They are a lot easier to solder.

- Build a, maybe too ambitious, server. The server will have,
 1. Graphic LCD 128x64;
 2. A keypad and dial;
 3. AVR MCU; (can be ARM but I do not want to involve another different 
tool chain)
 4. Two A7105 tranceivers: one for normal using; one for alternative 
channel when there is jam;
 5. One Blutooth module with the RS232 profile, which can be used to 
connect a PC;
 6. It's going to be powered from main through an adaptor.

- Build a boilder switch (another client). This switch has an A7105 
transceiver and a simple AVR. It is going to be powered by batteries 
only.

Each client will have to register with the server. The server Assign a 
key and a device ID to the client. The A7105 can help to filter the 
device ID. However, the communication packet will be encrypted with the 
key.

Periodically the client will connect to the server to post its own 
status and check out command. The detail of the protocol has not been 
decided yet.

If a client, after certain retries, can not connect to the server, it 
will switch to the alternative channel.

Time for bed now. I'll post more later.

David

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@davidfat:

2.4GHz is not good idea for this. Many building have steel/concrete 
parts and this building have BIG problem with wifi from room to room 
communication. It is same wavelength. Except this, in city center I can 
found over 50 wifi networks and it make communication near to 
impossible, noise is too big.
Data speed is not critical, battery life is bigger broblem. Antena 
length is not problem on 868MHz (RFM12 modules, antena fits inside valve 
I will post photos), and wavelength is better for comunication throw 
walls.

For "server" I has another goal. For me is not critical direct 
connection to computer, but connection to internet. It can be maintained 
remotely. Therefore I was use minimal AVR based protocol translator and 
mips/linux based small router.

But stand alone server is significat for many others people, I hope that 
your ideas have many potential users (probably include you)

@Others:
I have some small changes  in code on todo list, It come from real 
usage.

- battery warning or error will be one way. When battery is on end of 
life and not on drain it measure too opimistic values.

- less communication. Enable slave receivers twice every minute for few 
miliseconds is too expensive (battery life). Current plan: communicate 
on changes or every 2(4) minutes or twice every minute if user activity 
is detected.

- improvements on WWW interface.

Author: davidfat (Guest)
Posted on:

Rate this post
0 useful
not useful
@jdobry

868MHz has better path loss. However, given similar size, its antenna 
may be not as efficient as a 2.4GHz one. I'm interested to see your 
antenna inside the HR20.

Higher throughput for a network is still good, at least, a) it takes 
less time to transmit, hence saving power; b) the channel is less used, 
so better latency.

I also feel the bandwidth can be used in 868MHz is actually just 1MHz 
(868MHz~869MHz). When there is interference, there is less space to 
maneuver. Although 2.4G band is quite busy, the protocols there can 
normally use FHSS or DSSS to make robust link.

One more thing worries me about the RFM12 is that, according to its 
datasheet, its lowest working voltage is 2.2V. If the HR20 is powered by 
NiMh batteries, the voltage may be blow that when there is still half 
capacity left. Have you got chance to test an RFM12 at something like 
2.0V?

The server sounds better to be made with a PoE interface, and it'll need 
an ARM.

Re the transceiver power consuming. Suppose a short heart-beat packet is 
sent from a client to the server every 10 second. The heart-beat packet 
consists of 4 byte preamble, 4 byte server ID, 4 byte client ID and 2 
byte CRC. The packet is FEC encoded, hence take 7/4 of the raw length. 
So it has (4 + 4 + 4 + 2)  8  7/4 = 196bits. Given 250kbps, it takes 
0.784ms. The client will also try to receive a wake-up packet from the 
server, which is of same size. So roughly the whole procedure will take 
about 2ms. A7105 has RX current 16mA and TX 19mA. One heart-beat costs 
about 35mAmS. In one day there are 24*3600/10 = 8640 such communication, 
and it costs 0.084mAh. A good battery gives ideally 2000mAh, which means 
65 years. Let me know if this is possible or I did my calculation wrong. 
I don't see RFM12 consumes more power. Why you can't do it twice every 
minute?

When there is need to post server any status from the client, the client 
will wake up by itself. Or if the server wants to talk to the client, it 
sends a wake-up right after the client heart-beat. The client 
transceiver goes to sleep after certain time no RF activity.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@davidfat:
You calculation about battery life is bad. Problem is not energy for 
send data (it is small). Problem is here:
- internal PLL loop for frequency syntetizer need some time to 
stabilization, it is more time than for TX data.
- current for RX is near to same as for TX, and because timing can't be 
perfect, you need enable it few ms before packet.
- "heart-beat" packet must be also encrypted. Reason is potential 
synchronization poisoning from attacker.

PS: Where is datasheet for A7105?

Jiri

Author: davidfat (Guest)
Posted on:

Rate this post
0 useful
not useful
@jiri
At 2.4G the PLL seems to lock faster. According to the datasheet I think 
the extra overhead would be about 200us. However, without testing, I 
can't confirm. I would say bad programming if you can only get real-time 
response in a few ms. It is quite possible to get sub-100us timing 
accuracy, or even better with a simple device like AVR, for example, the 
heart-beat proceding can totally be done in the ISP. You don't need to 
identify someone before he/she can knock at your door. You just need to 
do the checking/encryption before letting him/her in.

The datasheet is here 
http://bbs.ednchina.com/Upload/Blog/2009/3/7/6e103...

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@david:

- Oscilator start-up overhead is 2mS (page 7 of datasheet)

- timing precision cant be better than 3.9mS Reason is 32768Hz x-tal and 
prescaler /128 . If you will use smaller prescaler you will increase 
volume of CPU wake-ups and it is not good for bateries. Use internal RC 
oscilator for this situations is also possible, but battery hungry.

Author: davidfat (Guest)
Posted on:

Rate this post
0 useful
not useful
@jdobry

- Even if it's 2ms, it only lowers the battery life for transceiver from 
65years to 32.5 years. Also, the standby state consumes much less power 
than TX/RX state. The 2ms is the time from sleep to standby. Interestly, 
although in the table it gives 2ms, in the diagram on page 38, it is 
0.9ms (from sleep to PLL).

- Absolute timing does not matter. When sending the heart-beat, MCU a) 
wakes up at certain time, b) disables all other request (for better 
determinstic timing), c) changes to 1MHz or so, d) wakes up the 
tranceiver, e) goes to idle/sleep(if possible) for 2ms, f) sets up the 
PLL, and idle for 80us, g) triggers the heart-beat sending, (the 
heart-beat packet can be stored inside the transceiver, so everytime you 
only need to trigger it), h) sleep/idle 0.7ms, i) keeps checking until 
TX finish, j) sets transceiver to RX, k) sleep/idle 1ms, l) checks if 
any wake up packet received, m) transceiver goes to sleep. I think 
that's pretty much the whole heart-beat procedure.

Author: Mr_Manor (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi

Build environment?
Just found this project and is very eager to try to build the software 
and hack my HR20 thermostats. I have more than 10 in my house.

Unfortunately I'm not very good at German so I have some troubles 
understanding the "Heizungssteuerung mit Honeywell HR20" page. Is it 
correct that I need WinAVR or "AVR Studio 4" to compile and they are 
both Windows only tools?

I am not wery experienced with Windows and have no license so I really 
would prefer a Linux based development platform. From the discussion 
above I see that some of you prefer *nix as well. Is it possible to 
build and download the project on a linux platform?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Mr_Manor:

AVR Studio is needed only for debugging, not for compilation.
For compilation WinAVR-20071221 compiler is recomended. Reason is that 
newest GCC produce significantly longer code and it can be too big into 
flash. But it depend to configuration. Linux distributions usualy 
contain AVR GCC and avr-libc. You must try it.

Or you can use precompiled HEX from repository.

For programming use avrdude tool.

Jiri
PS: from where are you?

Author: Mr_Manor (Guest)
Posted on:

Rate this post
0 useful
not useful
@jdobry

ok, thanks for your answer. I have installed VirtualBox and XP within so 
I hope that will enable me to compile. I'm very interested in the 
Wireless branch - several years ago I was into hardware so I think I am 
able the build the radio into the device. Is the project state as 
described on on the wiki page up to date?

I will most likely return with more questions when/if I get a build 
environment working ;-)

I'm from Ugerløse,Denmark.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Mr_Manor:
Information in wiki is not 100% up to date. But information in SVN is 
up2date. SVN contain schematics and photos for wireless modification. 
And if you want know communication protocols you must read source files, 
it contain human readable documentation. Low level wireles layer have 
documentation file in SVN (PDF and OpenOffice file).

Many greetings from Czech rep. Jiri

PS: I also use Linux at home, 100% in desktop and 80% in laptop. 
Remaining 20% of laptop time is WinVista because linux have not comfort 
tools for AVR debug :-(

Author: Thomas Fogh (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,
Is it possible to switch between full-stroke/default-stroke mode on a 
"not-hacked" HR20? (I don't have the necessary hardware).

BR, Thomas Fogh

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Thomas Fogh: It is for ORIGINAL SW:

FULL stroke mode: unmount valve, press and hold "C" button, mount valve 
and you will see "FULL" on LCD

DEFault stroke mode: unmount valve, press and hold "PROG" button, mount 
valve and you will see "DEF" on LCD

Author: Thomas Fogh (Guest)
Posted on:

Rate this post
0 useful
not useful
@jdobry:
Thanks! But what's the "C" button?
I have the "auto/man", "prog" and the day/night temperatur buttons.
BR, Thomas Fogh

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I mean day/night middle button. Because moon looks like "C" :-)

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
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 :)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Marco G." RFM12 sotware simply works on my home. I have plan to some 
improvemnts, but nothing critical.

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
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 :)

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Marco G.
Diferrences between internal and externel RFM12
- with external RFM 12 you can't use ICE debugger
- external module can be easily damaged or accidenataly disconnected. It 
is significant if you have childens.
- internal version need expert skill for soldering, chiset pins is 
extremely small.

And you are right. "Master" is RFM12 + Atmega connected to OpenWRT based 
router (I was test it with Asus GL500-deluxe and Buffallo WHR-G54S) It 
provide web interface for valves ( Yes, it can be used by iPhone :-) or 
any bother browser )

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
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.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Warning in  \rfmsrc\doc\external_RFM12\README.txt is little bit 
obsolete.
You can not use it with birary files in SVN, it need recompilation where 
you change hardware type.

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
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...

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
No I don't have PCB. Just prototype on universal PCB and wires. If you 
will have it, please send me one.

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
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?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Marco G.:
My router have serial interface inside. (3V3 logic levels)

Author: BlakeTRaposo (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello All,

I am new to this forum so thought to be first introduce myself, i from 
Gray Mountain and interested in Internet Surfing, Forum Posting and 
Listening Music specially the old clasics

Even i thought forum posting is one of the best way to enhance knowledge 
as well grab new things, that is the reason me joined this forum, i 
found this forum very informative and valuable, it is really great to be 
a part of this forum.

Thanks & Keep Sharing!

Author: Ronny Kunze (Company: Sinus Messtechnik GmbH) (rising_edge)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Ronny Kunze:
Can you send me any log? One of possible problems is time 
synchronization. Master broadcast real time and slaves enable receiver 
for synchronization packet. Real time is one of parameter to encrypt 
packet and if master have another time than slaves, encryption not work 
and it can't decrypt packages.

Master clock is not from XTAL but from RFM12 clock output (10MHz). Maybe 
that you change it on init sequence.

What happen when sync is lost?
- Master normaly send SYNC packet on 00 and 30 second in every minute
- Slave show "E4" error
1) Slave try enable receiver for 4 minutes till receive SYNC
2) When SYNC is not found,  receiver will be disabled for 40minutes 
(save batteries) and after go to step 1)


Jiri

Author: Ronny Kunze (Company: Sinus Messtechnik GmbH) (rising_edge)
Posted on:

Rate this post
0 useful
not useful
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

Author: Ronny Kunze (Company: Sinus Messtechnik GmbH) (rising_edge)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
It looks like lost SYNC.
"Master" ask daemon on computer for time every minute and daemon tell 
time in 1/100 precision. Do you use Windows or Linux? I am not sure if 
Win&PHP combination can use this precision. Part of encryption key is 
created from time. Therefore key in 0.99 second is not same as 0.01 
second. If daemon is not abble te tell time in this presisoon, time in 
master must float over +- 1 sec adn it is not abble to comunicate. It is 
just idea.

PS: I use NTP for real time in router where runs daemon. But absolute 
value is not significant.

Author: LunkeseFefnon (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi!

I'm looking for http://www.michaelmceleney.com - Iowa City Real Estate

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Ronny Kunze:

I read the log ant it is definitively lost of SYNC. See too log and 
follow my sentences:

- Log is in reverse order
- You have slave with address 6. This means that timeslot for 
communication is from 6.00 to 6.99 second


2009-12-08 12:25:07 @06.13 PKT04d1
- Is correct packet received in 6.13

2009-12-08 12:24:07 @07.54 ERR04d0 4c 06 86 c7 c2 14 5c b1 10 b0...
- Correct packet from 06 (see to second byte) but received too late on 
7.54
- Packet like this can't be accepted, because encryption key is expired 
and normaly this is possible only on "replay attack"
- This means that master receive from daemon wrong time. Maybe without 
correct 1/100 second and "jumping" around correct time.

If you want to have better verbose log (include time sending 
daemon->master) you can start daemon without redirect to /dev/null 
because it generate verbose log compare to log stored in database 
(database engine is too slow for it on embeded routers)

I apologise to code qality on current "daemon". This peace of code was 
hang together as proof of concept when I need to debug code in master 
and slave. I was plan to rewrite it completely, but it not happen (have 
not time and urgent motivation). But it works.

Author: Ronny Kunze (Company: Sinus Messtechnik GmbH) (rising_edge)
Posted on:

Rate this post
0 useful
not useful
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

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Can you use ntpd (daemon) and not ntpclient? It is abble to compensate 
drift.

Author: Peter Pfennig (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello,

is there a how-to-file or wiki for beginners/dummies?

Peter

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
Hi Peter,

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

Author: Ronny Kunze (Company: Sinus Messtechnik GmbH) (rising_edge)
Posted on:

Rate this post
0 useful
not useful
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

Author: Ludger (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello,

i have just converted my 2. Hr20 to the Open Hr20 with an RFM12 module.
when i measure the current, the Hr20 takes around 1 mA. This current 
consumption seems a little bit high.

Ludger

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Ludger: I know that we have some problem with wireless and power. Normal 
cheap alcaline batteries is empty after 2-3 months. I will try fix it on 
xmas vacation.
Till now I has feeling, that nobody except me use use wireles in HR20, 
but it slowly changes in last two months. :-)

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Ludger (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi Jörg,

i have had the same Problem with my HR20. Here are my settings to 
disable the window open detection.

Author: Ludger (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
next try

Author: Ludger (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello Jiri,

I think the problem with the current consumption, ist the crystal 
oscilator of the RFM module, it's always on. I can measure the output 
frequency of 10Mhz. You can switch off the the oscilator output to save 
some energy.


Ludger

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
Hi Ludger,
thanks a lot for this info regarding window open detection. I will try 
that immediately.

BR,
Jörg.

Author: TravelRec. (Guest)
Posted on:

Rate this post
0 useful
not useful
Why don´t you switch off the RFM completely with a little transistor, if 
it has nothing to do? I would implement short time slots in the 
protocol, where the module is active and waiting for incoming data or 
transmitting.

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Opps, RFM oscillator must be enabled only in master (it is used as clock 
for ATMEGA) but not in valves. I will fix it early (I hope today). We 
don't need switch off RFM by transistor, it can be switched off by 
command, I don't know where is problem for now, but I will find it.

Window: In current SW is this third version for window detection, and I 
have similar problem. Do you have anybody idea to improve window 
detection algorithm? For next version I will prepare window open timeout 
( from 1-255 minutes ) When HR20 clear window open flag automatically. 
Current detection is too sensitive, and today during change from 21 -> 
17 degree detect window open in 3 rooms. Temperature decreasing too fast 
(outside temperature was -16)

Master: It can be connected directly to PC, not to router. It is less 
complicated, but you can not set valves remotely. Remote control is 
fundamental feature for me, sorry. This SW can be installed on PC but is 
is not optimal. If you have not permanently enabled PC, you will not 
have logging.

GPL: it is GPL SW, this mean that everybody can modify it by own felling 
what is better :-)

Author: jdobry (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Today outside temperature in my location.

Author: TravelRec. (Guest)
Posted on:

Rate this post
0 useful
not useful
>We don't need switch off RFM by transistor, it can be switched off by
>command,

Sure, but how big is the quiescent current consumption in power down 
mode? Is it noticeable, compared to the Mega169, or not?

Author: Ludger (Guest)
Posted on:

Rate this post
0 useful
not useful
@ TravelRec

Hi,

i have running to RFM12 + SHT75 + Tiny45 for almost a year now. And the 
batteries ( 2 Alkaline AA ) are the first. The current consumption quit 
low


Ludger

Author: TravelRec. (Guest)
Posted on:

Rate this post
0 useful
not useful
Ahh, okay. In my tests the Mega169P needs around 25µA during sleep with 
LCD active and cyclic main calls 4 times a second. If the RFM takes more 
than 10µA all the time, then the battery life will decrease 
dramatically.

Author: Jörg Becker (jbecker)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Ludger (Guest)
Posted on:

Rate this post
0 useful
not useful
@ Jiri,

i know about the GPL, but i have some problems to compile the source 
file correctly for a running HEX file. The compiler has the right 
version and use the makefile for compiling. Do you use AVR studio for 
building the HEX ?
I got always a lot of compiler warnings.

regards
Ludger