Author: Motaxe Dukazahn
Country: Denmark
Language: English (Spanish)
Genre: Automotive
Published (Last): 7 February 2010
Pages: 401
PDF File Size: 19.9 Mb
ePub File Size: 17.51 Mb
ISBN: 847-2-26105-157-5
Downloads: 18068
Price: Free* [*Free Regsitration Required]
Uploader: Vigis

We need it to document “magic indexes” on setting Gxx and Sxxxx bedienungsanleitujg or watches Txx command Changelog: Known problem for Rev 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 hpneywell code review. SVN revision – optimizations – overload check in pid. Make code inside interrupt small as is possible and move real functionality bedienunbsanleitung main.

It have big priority for me at this moment. I dont know if “Hi Jdobri” is correct ; ok, ive downloaded the OpenHRrev 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 rondodtat files. 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: Since youre master of the menue it shouldnt be too difficult? By this way we can made anything include crazy ideas. You don’t need change anything on menu. Simple add line into eeprom. You can read it by config. Bedienungsahleitung about the Config-Menue: Did i get this right? I can edit the Variables in eeprom.

Then display shows XX: YY, ourbar shows all bars, XX blinks 3. YY shows thigs i dont understand In this mode ALL segments are on, except bit hex value rodnostat numbers and except one blinking segment on hourbar. Blinking segment indicate with values is on view. Connection Hr-200e to ATmega rohdostat have only by 2 ways and both is similar, can be changed by compile option different is only signal names.

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 rondotsat development. Benefit is that it can be connected outside without open HR But this configuration can be changed later in runtime and we can reenable it by hold reset signal.


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: I checked in a security. Disable JTAG only for runtime: 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.

Yes, we can use XTEA encryptor on feedback mode to generate key to encrypt data.

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. HR20 unpacks that datagram, checks rand, and if it is equal to the rand from 1. HR20 listens another second for a further command again with rand includedand if not occuring, HR20 waits a minute till 1. Your proposal looks good. I would like want only this modifications: After step 4 we can go back to 2.

Heizungssteuerung mit Honeywell HR20 –

It have benefit that we don’t need keep receiver alive 1 second. 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: We need hash or XTEA feedback hash. Without this it is easy decrypt packets xor fixed key.

OpenHR Firmware for Honeywell Rondostat HR20E –

Therefore we cant restart hash function for each “status” packed from HR It is just variant of fixed key. What we can to do: HR20 will transmit packet with packet key generated from hash PK1 -step 1: HR20 will transmit packet with packet key generated from hash step 2 PK2 -step 3: HR20 will transmit packet with PK2 -step 5: HR20 will transmit packet with PK3 -step 7: HR20 will transmit status packet next minute with PK3 -step 8: I hope that it is clear.

But we need to solve resync after HR20 or master is restarted some initial hr20e key. In this case, user must read one or two bytes from master and enter it manualy into HR It just only idea In my implementation i had an additional byte “flags” with several useful values contains ReceiverAddress, LoBatt, IsEncrypted I uoneywell that away in my sketch but a concrete implementation will contain sth like that.


Ok, gonna handle your latest post with security leak now Hi i was quite busy in the last days, so i had no bedienungsanlwitung to answer. I don’t have much time, but my business is embedded security.

Also i am often in das-labor.

I will show you the error in your proposal: 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: If you have some requirements, i can assist bedifnungsanleitung in designing the secutity functionality. For cipher i would bedienuntsanleitung to think about using XTEA. Token or n might get lost. 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.

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 honeywe,l functions like Diffie-Hellman. All other key exchanges are not secure, when they all use the same master key for all HR20s.

Jiri did a great job with his extensible interface! 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. From my side exist only small chance to do something till Xmas I am quite busy.

Therefore we have time to thinking about it. You saied, that radio packets MUST be short.

Heizungssteuerung mit Honeywell HR20

Keysize does not affect packetsize. How long would your random mumbers be? I think there are many better solutions, when we think a bit about it. I bedienugsanleitung to think about it, but for me it seems to be a “Homebrewn” sollution which is not the best we can have.

I Agree, but we should keep it smart, and simple. It big secutity hole.