Heizungssteuerung mit Honeywell HR20

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

von DarioC

Wie alles begann

Nachdem Uwe Felgentreu vor Jahren (genau am 17.11.2004 um 11:26) hier in diesem Forum den Thread mit dem Titel Honeywell Rondostat HR20E per AVR steuern und konfigurieren gestartet hat ist es nun langsam soweit, dass das Ganze auch ein Projekt wird.

Den Thread dazu kann der interessierte Leser hier nachlesen

Projektziel

Wir konzentrieren uns in erster Linie auf den Honeywell Rondostat HR20E mit der Softwareversion 2.04. Dass es ähnliche andere Geräte gibt behalten wir bei der Entwicklung im Hinterkopf.

Basierend auf dieser Hardware wollen wir eine neue Software entwickeln. Dabei können wir ausser der Hardware nichts weiter verwenden, da die Originalsoftware geschützt ist und nicht ausgelesen werden kann.

Phase 1

Die Software soll die Funktionen bieten, die die Originalsoftware auch bietet, später können diese dann um zusätzliche Funktionen erweitert werden. Die wichtigsten Funktionen sind:

  • Temperaturregelung
  • Echtzeituhr
  • Ausnutzen der Sleep Funktion
  • Anzeige Soll-Temperatur und der Uhrzeit
  • Einstellung der Soll-Temperatur
  • Uhrzeitgesteuerte Einstellung der Soll-Temperatur
  • Fenster-Offen-Erkennung
  • Ventilfreispülungsfunktion

Phase 2

Hier liegt der Sinn des ganzen Projektes: Durch diese zusätzlichen Funktionen wollen wir den Nutzwert des Thermostaten erheblich steigern:

  • Programmierung der Schaltzeiten und Temperaturen über externe Schnittstelle
  • Abfrage der Messwerte und Parameter über externe Schnittstelle
  • Vernetzung der Thermostaten untereinander
  • Zusätzliche externe Schnittstellen (neben UART auch CAN und Funk)
  • Erweiterung der Anzeige um
  • Bootloader, damit Leute mitarbeiten können, die keine JTAG haben. Mit einem JTAG könnte man den Bootloader Flashen, ohne den Thermostaten öffnen zu müssen. Von da an kann man über den Programmierstecker mit einem umgebauten Handykabel den Thermostaten neu flashen.

Lizenz

Die Software wird unter GPL v2 gestellt.

Forum, Diskussion

Der orginale Thread über den HR20 http://www.mikrocontroller.net/topic/17603 ist mittlerweile sehr lang und vereinigt sehr viele Sub-Topics. Aus diesem Grund wurde ein neuer Thread OpenHR20: Firmware for Honeywell Rondostat HR20E in http://embdev.net/topic/118781#new erstellt. Bitte alles Firmware-spezifische dort und in Englisch schreiben, da das Entwicklerteam international ist.

Subversion Repository

Das alte SVN Repository auf https://opensvn.csie.org war zu lahm,
daher haben wir ein Projekt auf Sourceforge angelegt.

Zugangsdaten

Projektseite: http://sourceforge.net/projects/openhr20/
Repository Location: http://svn.code.sf.net/p/openhr20/code/
Browse Repository: http://openhr20.svn.sourceforge.net/viewvc/openhr20/

Policy

Anonymous check out ist erlaubt.
Wer was committen will muss freigeschaltet werden.
Dazu brauche ich den Sourceforge Accountnamen.
Einfach eine Email mit Username und Password an hr20[at]carluccio[dot]de
Das mache ich dann von Hand und da ich nicht alle 10 Minuten Mails bearbeite kann das auch schon mal einen oder zwei Tage dauern.
Wenn sich ein Maintainer findet, gebe ich die Zugangsdaten gerne weiter.

SVN Client und Anleitung

Windows-User nutzen am besten den Tortoise-SVN-Client, den man kostenfrei hier runterladen kann.
Dort gibt es auch eine Anleitung zum Arbeiten mit SVN.

Analyse der Hardware

Die Analyse hat der Dario schon gemacht, zu finden ist die jeweils aktuelle Version als PDF hier oder hier im SVN.

Fuses

Here are the fuses set on the ATMega169V device:

Original OpenHR20
Extended 0xFD 0xFD
High 0x91 0x9B
Low 0x62 0xE2
EESAVE enabled disabled
BOOTSZ 1024 Words (1E00) 512 Words (1C00)
CKDIV8 1 0

TODOs

Main-Branch / all Branches of the Project

Task Remark Responsible Status
Code Review Check the code, complete doxygen coments OPEN
UserManual Write a User Manual, Screenshots are in \trunk\doc\Screenshots\ OPEN
PC-Software Write PC-Program to:
- Read and Write OpenHR20 Settings
- Log Status from OpenHR20
- Visualize Logfile
 OPEN
Bootloader Do we still need a Bootloader ?

The Wireless HR20 Branch

Dieser Projektzweig hat das Ziel, die HR20-Firmware so zu erweitern, dass sie über RFM12 FunkTransceiver fern-mess/steuer/regel-bar sind.

Status: Noch nicht einsatzbereit.

DONE:

  • Anschluss eines RFM12-Funkmoduls an die von aussen zugaenglichen JTAG-Pins. Die JTAG-Pins werden durch die "RFMizierte" Firmware nicht disabled sondern nur zur Laufzeit in IO-Ports verwandelt. Man kann also weiter mit JTAG draufflashen, muss das RFM aber vorher abstecken. Auch das JTAG-Debugging geht nicht mehr. Aber das COMport-Interface geht weiterhin, da die RxD/TxD-Pins nicht verwendet werden. Eventuell wenn uns der Platz für Code ausgeht, fliegt der COM aber raus, denn wer seine HR20 mit Funk ansteuert, braucht eigentlich keinen COM-Anschluss. Mal schaun wie eng es wird. Wer lustig ist kann das RFM auch ins HR20 reinbauen und mit kleinen Draehten von hinten an die Pinleiste verloeten. Fuer Aestethen und Leute die nicht debuggen wollen sicher interessant.
  • Senden eines 1/2/4/...minuetlichem StatusTelegramms über das RFM am JTAG. Das Telegramm wird moeglichst batterieschonend gesendet, d.h. zwischen rübertakten des naechsten zu sendenden Bytes an den RFM legt sich das HR20 in Powerdown. Dieses StatusTelegramms enthält
    • GeraeteAdresse,
    • Challenge bzw. Nonce (s.u. wozu)
    • IstTemperatur,
    • SollTemperatur,
    • VentilPosition,
    • Manual oder Auto-Mode,
    • FehlerBits (Abmontiert, Getriebe klemmt, Batterie leer)
    • Checksumme.
  • Einstellen der GeraeteAdresse über LCD, Tasten und Rad und im NichtFluechtigen Speicher behalten. Ist zwar etwas kryptisch einzustellen (set Configuration Byte), aber man muss keine eigene Firmware mit hard kodierter GeraeteAdresse kompilieren. Bei exaktem User-Manual (alle 3 tasten lange duecken, Drehen bis 22 kommt, Prog druecken, Geraeteadresse eindrehen, Prog druecken) aber sicherlich kein Problem.
  • Die Kommunikation wird durch einen gemeinsam bekannten Schluessel gesichert. Der Schluessel ist im HR20 einstellbar, analog wie die GeraeteAdresse.

TODO:

  • Verschluesseln der gesammten Kommunikation mit [XTEA] damit keiner sieht dass die Heizung kalt ist was zum Einbruch einladen koennte ;-) Keine Grundsatzdiskussion bitte, den Verschluesselungscode werden wir sowieso auch anderweitig brauchen.
  • nach dem StatusTelegramm ist das RFM kurz im Empfangsmodus um eventuelle Befehle (set SollTemp, set Manual/AutoMode, set Schaltzeit, set Uhrzeit, set VentilPos, ...) von einem Raumcontroller zu empfangen.
  • Dieser Raumcontroller ist (noch) nicht Teil des Projekts. Er kann z. B. eine typische AVR+FTDI+RFM-Schaltung sein, wie z. B. diese Hardware-Vorschlaege siehe AVR_RFM12 und Datenfunk_mit_dem_AVR. Viele von euch werden sicher eine simple Funk-zu-Serialport-Bruecke bauen, und ein Linux-Programm zur Steuerung zusammenkloppen. Evtl wird das auch mal ein Unter-Projekt.
  • Dieser Raumcontroller kann nun in einem Zeitfenster von ca 1/10 Sekunde nach HR20's StatusTelegramm dem HR20 einen Befehl geben. Das ganze wird mit einem Challenge-Response-Protokoll gesichert, damit keine unbefugten Raumcontroller vom Nachbarn einem die Heizung verdrehen. Wir diskutieren noch im Forum, aber wahrscheinlich kann man die Challenge-Respnse-Authentication auch mit XTEA-Verschluesselung durchfuehren (wuerde den Code für eine Einwegfunktion sparen, wir haben bald ProgramSpace-Probleme).
  • Nach der Verarbeitung eines authentisierten Befehls sendet der HR20 ein Telegramm mit dem Resultat des Befehls zurueck. Danach ist der HR20 wieder bis zum naechsten Status in einer Minute (oder alle 2/4 Minuten) Offline. HR20 darf seinen RFM nicht permanent auf Empfang lassen, da dies ein Batteriekiller waere.
  • Dokumentation für ein leichtes Nachbauen und Erweitern.

Wer noch Vorschlaege hat was rein soll, ab ins [Forum] damit.

API Beschreibung

Das Projekt wird mit doxygen dokumentiert, die API-Beschreibung kann aus dem Source-Code generiert werden.

UART Protocoll

This is the documentation for the UART Protocol in Release 74 of the SVN hosted on Sourceforge:

Com-Port Params

  • BAUD: 9600
  • Data: 8
  • Parity: N
  • Stop: 1

Automatic calibration

When the HR20 is mounted, then the automatic calibration is started. The Debug-Info during the callibration is printed to the com-interface like this: 

+ 0210
+ 047e
+ 0437
[... many lines deleted ...]
- 0681
- 0695
- 0694
+ 0210
+ 047e
+ 0437
+ 0417
+ 0454

Commands

All commands have FIXED format.

  • command X.....\n termination char
  • X is upcase char as commad name
  • hex numbers use ONLY lowcase chars

print version information

Command: 

 V<CR>

Response: 

 V: OpenHR20 SW version V.VV build DDDD $Rev: REV $

Where:

  • V.VV Version
  • DDDD Date at compilition
  • REV SVN Revision

Example: 

 V: OpenHR20 SW version 0.21 build Nov 13 2008 23:22:08 $Rev: 72 $

print status

Command: 

 D<CR>

Response: 

 D: dW DD.DD.DDDD TT:TT:TT M V: VV I: IIII S: SSSS B: BBBB E: EE XW
 D: dW DD.MM.YY TT:TT:TT A V: VV I: IIII S: SSSS B: BBBB Is: IsIs   ->new

Where:

  • W Day of Week (monday=1)
  • DD.MM.YY actual date
  • TT:TT:TT actual time
  • M|A manual/automatic mode
  • VV actual position of valve [%] (00=closed, 100=opened)
  • IIII actual temperature
  • SSSS desired temperature
  • BBBB battary voltage [mV]
  • IsIs Integratorvalue
  • EE Error Code
  • X
  • W Window Open detected

Example: 

 D: d3 01.10.08 12:00:16 V: 00 I: 2103 S: 1700 B: 3259 E:04 X
 D: d3 25.03.09 22:44:00 A V: 05 I: 2585 S: 2500 B: 3044 Is: ef56 ->new

print watched variable

Command: 

 Taa<CR>
  • aa watched variable see watch.c

Response: (return 2 or 4 hex numbers) 

 T[aa]=VVVV

Where:

  • aa watched variable see watch.c
  • VVVV value of watched variable

Example: 

 T[01]=0cca

get configuration byte

Command: 

 Gaa<CR>
  • aa hex address of configuration byte see eeprom.h

Response: 

 G[aa]=VV

Where:

  • aa hex address of configuration byte see eeprom.h
  • VV value of configuration byte

Example: 

 G[13]=2d

set configuration byte

Command: 

 SaaVV<CR>
  • aa hex address of configuration byte see eeprom.h
  • VV hex value for configuration byte (hex)

Response: 

 S[aa]=VV

Where:

  • aa hex address of configuration byte see eeprom.h
  • VV value of configuration byte

Example: 

 S[13]=2d

get timer

Command: 

 Rab<CR>
  • a day
  • b slot

Response: 

 R[ab]=cddd

Where:

  • c timermode
0 frost protection
1 energy save
2 comfort
3 supercomfort
  • ddd time (minutes since 00:00, hex)

Example: 

 R[10]=21a4
 R[11]=121c
 R[12]=23c0
 R[13]=14ec
 R[14]=2fff
 R[15]=1fff

comfort at 0x1a4 = 420 / 60 = 7 energy save at 0x21c = 540 / 60 = 9 comfort at 0x3c0 = 960 / 60 = 16 energy save at 0x4ec = 1260 / 60 = 21 Slot 5+6 not used.

set timer

Command: 

 Wabcddd<CR>
  • a day
  • b slot
  • c timermode (0 to 3)
  • d time time (minutes since 00:00, hex)

Response: 

 W[ab]=cddd

Example: 

 W[10]=21a4

Reboot

Command: 

 B1324<CR>
  • 1234 password (fixed at this moment)

Response:

set date

Command: 

 Yyymmdd<CR>
  • yy year
  • mm month
  • dd day

Response: 

 D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X

set time

Command: 

 Hhhmmss<CR>
  • hh hour
  • mm minute
  • ss seconds

Response: 

 D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X

set wanted temperature

Command: 

 Axx<CR>
  • xx temperature [unit 0.5C] (hex)

Response: 

 D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X

Example: 20°C = 40 * 0,5 °C = 28 (hex)

Example: 20°C = 20 * 2(unit 0.5°C) = 40 = 28 (hex) 

 A28<CR>

Attention: The value in the response is not the new value.
The new value is updated some secondes later, so be patient and wait.

set mode

Command: 

 Mxx<CR>
  • xx mode
00 = manu
01 = auto

Response: 

 D: WW DDDDDDDD TTTTTTTT V: VV I: IIII S: SSSS B: BBBB E:EE X

Bootloader

Um ein einfaches Update der Software, auch ohne Programmer und Zerlegen des HR20E zu ermöglichen, sollte ein Bootloader implementiert werden.

Grundsatzproblem: Fuer ein erstes Umflashen eines eben aus der Verpackung genommenen HR20s braucht man immer einen JTAG-Programmer um überhaupt erstmal den Bootlader selber draufzukriegen.

Anforderungen

  • Einfaches Update ohne öffnen des HR20E
  • Nutzen bestehender Programme (Terminalprogramm), das erspart das schreiben von Update Software
  • HR20E sollte nach dem Start prüfen ob Programm gültig und nur dann das Anwenderprogramm starten
  • Protokoll sollte Updatevorgang aus dem laufenden Betrieb unterstützen (Sprung in den Bootloader)

Vorschlag 1

X-Modem Protokoll (mit CRC)
Hier gibt es eine fertige Lösung für das Etherboot projekt, deren Übernahme gestattet ist.
Größe ist hier kleiner 1kB und wohl verkraftbar.

Vorteil:

  • etablierte Technik
  • von anderen Herstellern verwendet
  • wird von den meisten Terminal-Programmen unterstützt
  • Gesichert durch Checksumme

Nachteil:

  • Aufwendige Checksummen-Berechnung oder Lookup-Tabelle notwendig

Vorschlag 2

Verwendung des AVR_Bootloader_FastBoot_von_Peter_Dannegger: Der ist sehr klein, erprobt, leicht anwendbar und funktioniert auch sehr gut. Die Windows-Software für den Upload ist auch sehr gelungen. Auf Grund des o.g. Grundsatzproblems und der Tatsache dass die Neuentwicklung eines Bootladers sehr anspruchsvoll ist, halte ich es an dieser Stelle für besser, das Rad nicht neu zu erfinden.

Entwicklungsumgebung

Sonstiges

Altes Protokoll

Hier hat mal einer ein Protokoll eingegeben. Das scheint aber nicht zu der Version 2.04 zu passen. Ich habe es nicht gelöscht, falls es jemanden interessiert.

Andere Heizungsthermostate

Abgerufen von „https://www.mikrocontroller.net/index.php?title=Heizungssteuerung_mit_Honeywell_HR20&oldid=80797“