Hallo zusammen,
erstmal ein großes Lob an Alle. Ja auch ich verfolge diese Sache schon
länger im Hindergrund mit, da ich einige der hier erwähnten Teile auch
in meinem Besitz führe.
Ich war sehr erstaunt als Patrick von Ähnlichkeit des HR40 zum HR20
schrieb, darauf öffnete ich meinen HR40. Er hat ein ganz anderes
Platinenlayout, besitzt eine RJ22-Buchse für einen Fernfühler und der
Chip ist mit 'NECIRELAND 4515 926 HR40 1.00 0001E8002' beschriftet.
Da giebt es wohl verschiedene Baureihen !?
Bilder folgen.
Gruß Ralf
Meiner hat, wie man dem Layout entnehmen kann diesen Anschluß für den
Fühler nicht. Auf der Verpakkung wie auf dem Regler steht: HR40 V 2.04.
Werde Fotos davon zusammen mit dem Rest Morgen ind Netz stellen.
edit:
Kannst du vielleicht davon auch Bilder reinstellen? - Dann könnte man
eine Typensammlung machen. Vielleicht für ein späteres FAQ oder so
sinnvoll.
Jens Müller wrote:
>> Aber, nächster Fehler:>
[...]
>> avr-size: supported targets: elf32-avr elf32-little elf32-big srec> symbolsrec tekhex binary ihex>
Damit hatte ich auch Probleme, ich habe mir jetzt damit geholfen:
Hi,
habe ich das richtig verstanden? Da der HR20 ein JTAG Anschluß hat,
können wir ihn nur einen JTAG ICE oder JTAG ICE mkII programmiern. Was
gibt es denn da günstiges auf dem Markt? Reicht der USBprog 3.0 aus dem
Shop ?
Ja, so habe ich das auch verstanden. Aber ich habe leider auch noch
keinen Weg meinen HR20 zu programmieren. erstmal muss ich zugeben, das
ich mich nicht so wirklich mehr auskenne bei Mikrocontrollern, ist schon
länger her, dass ich damit zu tun hatte (und das war ein 8051 Typ).
Jetzt habe ich mir auch ertmal den USBProg gekauft und bin dann direkt
an die entsprechenden Pins des Controllers. Mit der "AVRISP mk2 Klon"
Firmware. Ich hoffe ich kriege das zum laufen, im Moment habe ich
Probleme mit dem USBProg.
Achja, das beschriftete Bild der HR40 Platine ist hier:
http://patrickbueker.de/de/publications/pictures/img_4042bearb.jpg
Einige Bauteile sind noch nicht beschriftet, konnte ich noch nicht
zuordnen.
Ein Thermotronic habe ich mir auch mal gekauft, werde mir das auch mal
anschauen. Weiter oben hatte ja schon jemand was gepostet.
Vom Thermotronic hab ich auch mal ein Bild gemacht.
Statt den gelben und schwarzen Kabeln gehört normal der
Temperatursensor. Die Pins gleich daneben, für den Motor, habe ich auch
selber eingelötet, um die Platine besser aus-/einbauen zu können, hier
war das Flachbandkabel direkt eingelötet.
Hi Tobias,
Du schreibst:
> wie weit bis du gekommen, hast du eine Temperturanzeige im Simulator?> Bei mir kam keine Anzeige.
Je nach dem welche version Du hast kommt auch keine Anzeige.
In der aktuellen Version sollte es aber gehen, wenn Du einen
Breakpoint int main() in der mian.c in diesem Bereich setzt:
1
// POST Screen
2
LCD_AllSegments(LCD_MODE_ON);// all segments on
3
delay(1000);
4
LCD_AllSegments(LCD_MODE_OFF);
5
LCD_PrintDec(REVHIGH,1,LCD_MODE_ON);// print version
6
LCD_PrintDec(REVLOW,0,LCD_MODE_ON);
7
LCD_Update();
8
delay(1000);
9
LCD_AllSegments(LCD_MODE_OFF);// all off
Jeweils bei dem delay könnetst Du ein Breakpoint setzten, nach dem
Befehl
1
LCD_AllSegments(LCD_MODE_ON);// all segments on
sollten alle Segmente an sein. Und nach
1
LCD_PrintDec(REVHIGH,1,LCD_MODE_ON);// print version
2
LCD_PrintDec(REVLOW,0,LCD_MODE_ON);
3
LCD_Update();
Sollte da die Revision stehen.
Was passiert bei Dir?
Dario.
Hallo zusammen,
nachdem ich jetzt schon länger mitlesen, wollte ich erst mal meinen
Respekt an alle Bastler hier aussprechen. Ich finde das Thema hoch
interessant, obwohl ich nur Servicetechniker für Automatisierungstechnik
(SIMATIC) war und jetzt Maschinenbau studiere. (hab´s also nicht so mit
Programmieren... :)
Nachdem überlegt wurde, ob es evtl. nicht Alternativen gäbe, die die
rein mechanische Komponente abdecken, ist mir heute im hiesigen Baumarkt
folgendes Teil aufgefallen.
Ich hab jede Seite der Verpackung fotografiert, aber keine Ahnung, ob es
auch klappt, diese Fotos als Gast hier auch reinstellen zu können!
Gruß
Andreas
ps. wenn kemand die Fotos hier reinstellen kann, kann ich diese jemanden
auch gern per mail schicken, wenn mir jemand seine Adresse gibt...
Hallo Andreas,
hast Du das Teil nur abgelichtet oder auch gekauft?
Was soll denn das gute Stück kosten?
Das Produkt ist von Ansatz her eigentlich keine schlechte Idee, da man
die Regelung weiterhin dem Thermostaten überlässt wie auch die
Temperaturwahl. Zum Abschaltzeitpunkt wird zwischen Thermostat und
Ventil vermutlich ein mechanischer Offset eingerichtet, der für ca. 4°C
Absenkung sorgt.
Uhrzeiteinstellung ist vermutlich nicht nötig. Da steckt ne nicht
einstellbare Uhr drin und die merkt sich zu welcher Zeit eine Ansenkung
oder eine Aktivierung betätigt wurde und wiederholt das jeden Tag bzw.
im Wochenrhythmus. Angenommen es sind zwar 21Uhr aber die interne Uhr
steht auf 16Uhr. Man drückt den Knopf HZ an. Sieben Tage später wird zur
Internen Zeit 16Uhr die HZ eingeschaltet, obwohl es tatsächlich 21Uhr
sind aber das ist dann so gewollt.
Das bedeutet aber auch das die Programmierung im Voraus nicht möglich
ist. Man muss zu der Zeit wo man eine Schalte haben will da sein und
einen Knopf drücken. Die Schalte wird dann im Wochenrhythmus wiederholt.
Sommer/Winterzeit Schalte ist somit nicht möglich. Es gibt keine
Temp.Anzeige, keine Anzeige der eingestellten Zeiten (Blindflug), keine
Möglichkeit einen abgesetzten Temp.Sensor einzusetzen ausser der
Thermostat bietet das.
Da Gehäuse ist etwas globig. Wenn die LED allerdings während dem
Heizbetrieb ständig leuchtet, wage ich die 5 Jahre Batterielebensdauer
zu bezweifeln.
Der HR20E benötigt im Leerlauf schwankend 60-120uA, wenn man bedient ca.
2mA und wenn der Motor läuft ca. 20mA. Eine LED benötigt je nach
Ausführung 5-20mA.
Mir gefällt der HR20E besser, wegen Anzeige, Programmierung und
Flexibilität. Zwischen An- und Abschalttemperatur können auch mehr wie
4°C liegen und wenn das Teil umprogrammiert ist, wird man es fernsteuern
können, auf die Regelcharakteristik Einfluß nehmen und weitere
Anwendungen realisieren können.
Gruß
Karim
Ich habe mal etwas gesucht in der Hoffnung bei Atmel vielleicht auf eine
Application-Note zu dem Thema zu finden. Da die verschiedenen
Konstruktionen sich so ähneln wäre das ja möglich.
Leider bin ich nur auf folgenden Artikel gestoßen:
http://www.atmel.com/dyn/resources/prod_documents/battery.pdf
Das gesamte Heft auch hier:
http://www.atmel.com/journal/documents/JOURNAL_2.pdf
Dort wird zwar ein Thermostat beschrieben, aber nicht im Detail.
Vielleicht existiert doch eine Application-Note?
@ Ralf H. (Gast)
Dein HR40 wird vermutlich eine andere, frühere Serie sein. Es gibt
nämlich auch HR20 mit NEC-Chip. Das würde auch darauf hindeuten, dass
beide damals auch schon vom Innenleben gleich waren.
So,
ich habe mich einmal an die Doku des bestehenden Source Codes gemacht.
Eine Vorabversion befindet sich auf www.carluccio.de/hr20
Das Ganze kann mit doxygen aus den Quelltexten erzeugt werden.
Das Doxygen Config File liegt im svn.
Dario
Hallo Dario,
kanst Du bitte mal die Rev. 33 überprüfen.
In einer ältere Version war RTC_MM noch declariert.
Ich erhalte folgende Fehler:
Build started 7.3.2008 at 17:34:22
avr-gcc.exe -mmcu=atmega169p -Wall -gdwarf-2 -std=gnu99
-DF_CPU=1000000UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -MD -MP -MT rtc.o -MF dep/rtc.o.d -c ../rtc.c
../rtc.c: In function 'RTC_Init':
../rtc.c:110: error: expected ';' before 'RTC_hh'
../rtc.c:115: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c:115: error: (Each undeclared identifier is reported only once
../rtc.c:115: error: for each function it appears in.)
../rtc.c: In function 'RTC_GetMonth':
../rtc.c:138: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c:139: warning: control reaches end of non-void function
../rtc.c: In function 'RTC_SetMonth':
../rtc.c:231: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: In function 'RTC_AddOneSecond':
../rtc.c:438: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: In function 'RTC_AddOneDay':
../rtc.c:482: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: At top level:
../rtc.c:504: error: conflicting types for 'RTC_DaysOfMonth'
../rtc.c:66: error: previous declaration of 'RTC_DaysOfMonth' was here
../rtc.c: In function 'RTC_DaysOfMonth':
../rtc.c:505: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c:514: warning: control reaches end of non-void function
../rtc.c: In function 'RTC_IsLastSunday':
../rtc.c:546: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: In function 'RTC_SetDayOfWeek':
../rtc.c:583: error: 'RTC_MM' undeclared (first use in this function)
make: *** [rtc.o] Error 1
Build failed with 13 errors and 2 warnings...
// Tobias
Hallo Tobias,
> kanst Du bitte mal die Rev. 33 überprüfen.> In einer ältere Version war RTC_MM noch declariert.
Jepp, da habe ich beim Dokumentieren wohl auch einen Fehler reingehauen.
Sollte in der Rev34 behoben sein.
Lass es mich wissen, wenn Du noch Probleme hast.
Dario.
Hallo,
ich hab´s nur fotografiert und nicht gekauft,
da ich mittlerweile 8x HR20 in unserem Haus verbaut habe.
Der Preis war glaub ich irgendwas zwischen 20-25 Euro.
Das das HR20 komfortabler ist, ist mir auch bewusst,
aber hier stellte ja jemand die Frage nach einer Alternative,
die nur aus einem Stellmotor besteht. Deswegen hab ich bei
diesem Gerät an euch gedacht.
Gruß
Andreas
Achja, wo ich schon hier bin, möcht ich euch gleich über einen Fehler
informieren, der bei meinen neuen HR20 aufgetreten ist.
Bei mir ist seit etwa 4 Jahren ein altes Model dieses Thermostats ohne
Problem und zuverlässig im Einsatz, deswegen hab ich vor 4 Wochen bei
conrad.de zugeschlagen und 7 Stück zu je 29,90 Euro gekauft.
Wie sich rausstellte sind alle 7 nun ein neueres Model, nur leider macht
sich bei diesen jetzt ein kleines Problem bemerkbar, das beim alten noch
nicht war. Sporadisch gehn alle 7 Thermostate zurück in den
Einstellmodus in dem man Datum und Uhrzeit einstellen muss. Dies
passiert entweder ganz von allein, oder wenn man am Stellrat die
Themperatur nachregelt. Dumm für mich ist, dass fast alle HR20 von oben
nicht einsehbar unter Fensterbänken sind, und so steht dann das eine,
oder andere im Eingabemodus, regelt dabei nicht mehr und jeder fragt
sich, warum die Heizkörper kalt bleiben.
Der nette Herr an der Hotline von KAZ Hausgeräte GmbH sagte mir, dass
dieser Softwarefehler bekannt sei und diesen ab und zu ein paar Geräte
haben, jedoch hat er noch nie 7 davon auf einmal gehabt. (hab ich wohl
ne Serie Montagsgeräte erwischt :/ ) Er hat mir auf jeden fall geraten,
die Geräte an Conrad zurück zu schicken und Austauschgeräte zu nehmen.
Vielleicht ist dieser Fehler bei euch ja auch schon mal aufgetreten?
Wollt euch dieses Verhalten auch nicht vorenthalten! : )
Gruß
Andreas
Hallo Andreas,
Du kannst die Thermostaten doch auch um 90° gekippt montieren. Dann
kannst Du drauf schauen.
Zu den Aussetzern habe ich bei einem Modul folgende Erfahrung gemacht.
Am Metallbügel der nach dem einlegen der Batterie diese brückt ist eine
kleine Lasche dran, die dazu dient, mit dem Fingernagel die Lasche
bedienen zu können. Die liegt so dicht an dem grauen Zahnrad, dass wenn
das Zahnrad zum Modul hin bewegt wird, die Zähne an der Lasche streifen
können und der Bügel mitgezogen wird/schwenkt. Folge ist, dass die
Batterien garnicht oder nur halblebig miteinander verbunden sind.
Abhilfe schafft ein leichtes Auf- oder Zubiegen dieser Lasche, um Sie
aus der "Gefahrenzone" zu bringen. Wenn Du das nächste Mal ein Modul im
Startmodus findest, öffne die zwei Verriegelungen, nimm das Modul ab und
prüf mal den Sitz des Metallbügels.
Das Verbiegen der Lasche geht im eingebauten Zustand schlecht. Das
ausbauen ist etwas kniffelig, wegen dem Kunststoffschnapper. Da sollte
man Fingerspitzengefühl walten lassen, damit nix bricht.
Gruß
Karim
So,
ich habe nun meine 6 Rondostat bestellt. Ich hoffe mal die sind Version
2.04, also mit Atmel Chip.
"C" hat da ja im Moment ein Angebot :-)
Jetzt muss ich nur noch Zeit haben die alle zu Montieren :-)
Wenn ich das richtig verstanden habe, kann man die ja von außen neu
flashen über JTAG ?
Ist das Protokoll für die Serielle schon definiert ? Da kann ich sicher
helfen, sowas ist mein täglich Brot :-)
Dann könnte ich schon mal an meinem Protokollumsetzer an den AXLink Bus
meiner AMX arbeiten ;-)
Gruss
Jürgen
Achtung ! Der Tipp mit der Rohrzange ist unvollständig !
Vorsicht ! : wenn man zu weit auf den Stift fasst, kommt der Bereich -
den die Zange gefasst bzw. beschädigt hat - später beim Reindrücken-
fahren des Ventis evtl in den Bereich der O-Ring Dichtung. Also: bitte
nur ganz ganz kurz anfassen. Am Besten, man nimmt eine wirklich
gute/neue Combizange. Denn diese ist vorne so scharfkantig/winkelig,
dass sie den Stift ganz vorne greifen kann. Dieser Brereich kommt später
nicht in die Nähe des O-Rings.
Mit freundlichem Gruß
Lothar Peters
Heizungs- und Sanitärbedarf (Hürth)
durch Zufall (Google - HR-E 20 :-) bin ich auf diesen Thread aufmerksam
geworden. Ich bin begeistert. Nur bin ich leider ekin Elektroniker :-(
Ich bin Heizungsmonteur Kesselbauer Schmied.
Passt zwar nicht - bin aber leidenschaftlicher Bastler und stell am
Liebsten ALLES in Frage. Daher regt mich, was diesen Thread betrifft
eher ein primitiver Gedanke:
Da ich hier einiges gelesen habe und ich soeben bei Saturn im EKZ-Hürth
(Köln)
einen HR-E 20 gekauft habe, sah ich schon mal beim Einlegen der
Batterien die Version 2.04. Das weiß ich nun. Aber. Was ich nicht weiß:
Kann man die Anschlüsse (seitliche Kappe) irgendwie nutzen, um eine
schnelle Umschaltung auf Absenken zu forcieren?
Das mit manuell und wieder automatik ist mir zu primitiv. Dann könnte
ich auch einen konventionellen Thermostatkopf auf nd zu drehen :-)
Wenn man mit einer einzigen voreingestellten Absenktemperatur leben
kann, dann wäre das optimal. Ein Klick und er steht auf absenken. Das
gleiche wieder zurück. Ich hoffe das man mich verstehen konnte :-)
Wahrscheinlich wäre es für den Hersteller eine zusätzliche Erweiterung
gewesen. Vielleicht habe ich es nicht gelesen. Aber, wie ich es sehe,
hat der HR-E 20 diese Funktion nicht. Einfach einen Knopf, der alle
anderen Funktionen nachrangig schaltet. Klick = Absnken (bis zum
rücksetzen) und Klick = Hochfahren. So. jetzt reichts erstmal. Antwort
wäre sehr hilfreich.
Danke
PS. löscht sich das Programm beim Akkuwechsel ?
Hallo Karim,
bei neuen Heizkörpern ist das schon klar, dass man da das HR20 um 90
Grad drehen und dann drauf schauen kann, aber bei alten Heizkörper und
das sind so ziemlich alle in meinem Haus (Altbau) sind die Thermostate
so montiert, dass du von vorne auf das Stellrad guckst. Man könnte das
HR20 umd 360 grad drehen und könnte in keiner Position das Display
ablesen... :(
Andreas
Hallo Lothar
Du schriebst:
> durch Zufall (Google - HR-E 20 :-) bin ich auf diesen Thread> aufmerksam geworden.
Ich liebe Google, machmal ist es doch zu was gut.
> Ich bin Heizungsmonteur Kesselbauer Schmied.> Passt zwar nicht
Doch, da hebe ich gleich 1000 Fragen an Dich, zum einen bezüglich
des Projektes hier zum anderen meine private Heizungsanlage betreffend.
Wenn Du Zeit und Lust hast mir ein paar Fragen zu beantowrten, dann
schreib mir bitte mal eine Mail.
> Version 2.04.> Kann man die Anschlüsse (seitliche Kappe) irgendwie nutzen, um eine> schnelle Umschaltung auf Absenken zu forcieren?
Mit der Software der Version 2.04 nicht, aber es wäre eine Idee das
in die hier programmierte Version einzubauen. Allerdings sehe ich da
ein kleines Problem und zwar wie kann man das synchronisieren.
Wenn ich 4 Thermostate habe und drei stehen auf abgesenkt und einer auf
Komfort, dann würde nach dem Impuls drei auf Komfort und einer abgesenkt
sein. Nehmen wir mal an die werden mit Schaltuhr alle um 17:00 auf
Komfort geschaltet und die Uhren gehen leicht unterschiedlich, dann ist
das gar nicht so unwahrscheinlich.
Daher würde ich zwei Eingänge vorschlagen, einer für Komfort und einer
für Absenken. Muss ich mir nochmal Gedanken zu machen, inwiefern sich
das negativ auf die Lebensdauer der Batterie auswirkt, aber ansonsten
ist das progammiertechnisch kein Problem.
> PS. löscht sich das Programm beim Akkuwechsel ?
Keine Ahnung, die Hardware könnte es, ob die das programmiert haben
weiss
ich nicht.
Dario
Hallo Jürgen,
Du schriebst:
> Jetzt muss ich nur noch Zeit haben die alle zu Montieren :-)> Wenn ich das richtig verstanden habe, kann man die ja von> außen neu flashen über JTAG ?
Stimmt, aber wenn Du nicht einmal die Zeit findest die zu montieren,
dann hast Du erst recht nicht die Zeit die auch neu zu flashen.
Der Vollständigkeit halber: Von Außen geht JTAG immer. ISP geht, wenn
man es aufschraubt und die ISP-Kabel selber anlötet. Und wenn man erst
mal einen Bootloader drin hat, kann man auch den Atmel auch von außen
über die serielle Schnittstelle (RS232 3,3v) programmieren.
> Ist das Protokoll für die Serielle schon definiert ?
Nö, nur die ersten Denkansätze sind da.
> Da kann ich sicher helfen, sowas ist mein täglich Brot :-)
Ach, erzähl!
Was machst Du, nur Protokolle definieren, oder auch programmieren.
> Dann könnte ich schon mal an meinem Protokollumsetzer an den> AXLink Bus meiner AMX arbeiten ;-)
Was ist ein AXLink Bus und was ist eine AMX
Dario, der jetzt erstmal Googeln geht....
Dario C. wrote:
> Stimmt, aber wenn Du nicht einmal die Zeit findest die zu montieren,> dann hast Du erst recht nicht die Zeit die auch neu zu flashen.> Der Vollständigkeit halber: Von Außen geht JTAG immer. ISP geht, wenn> man es aufschraubt und die ISP-Kabel selber anlötet. Und wenn man erst> mal einen Bootloader drin hat, kann man auch den Atmel auch von außen> über die serielle Schnittstelle (RS232 3,3v) programmieren.
Montiert sind die Jetzt, uff die alle synchron einzustellen (3
Heizkörper in einem großen offenen Raum) ist ja je ne mords Arbeit :-)
>> Ist das Protokoll für die Serielle schon definiert ?> Nö, nur die ersten Denkansätze sind da.>>> Da kann ich sicher helfen, sowas ist mein täglich Brot :-)> Ach, erzähl!> Was machst Du, nur Protokolle definieren, oder auch programmieren.
Mich Tag für Tag mit Protokollen anderer Geräte Rumschlagen und diese
von der AMX aus ansteuern, meist sogar nur per Telefonischem Support. Da
weis man eben was man besser machen kann.
>> Dann könnte ich schon mal an meinem Protokollumsetzer an den>> AXLink Bus meiner AMX arbeiten ;-)> Was ist ein AXLink Bus und was ist eine AMX
AXLink ist einer der Steuer Busse der AMX. Die AMX ist letztendlich ein
Freiprogrammierbares Steuersystem. Dessen Support und Programmierung ist
mein Täglich Brot.
Aber das ist für das Projekt jetzt eher unwichtiger. Ich denke man muss
nur ein Gutes und einfach zu parsendes Protokoll definieren. Dann kann
jeder mit seinem Bus dran von Außen, oder sogar mit dem PC.
Wenn die zur Verfügung stehenden Daten feststehen, also Temperatur, Max
Temp, Min Temp usw, kann ich da gerne einen Vorschlag machen. Eventuell
auch mithelfen. Aber meine Zeit ist zur Zeit eher Limitiert.
Was ich mir noch überlegt habe, könnte man nicht auch optional I2C als
Schnittstelle anbieten ? Es wäre so einfacher mehrere Thermostate an
einen IC zu koppeln. Ich muss mir mal die Schnittstelle vom Thermostat
nochmals ansehen.
> Dario, der jetzt erstmal Googeln geht....
Und Erfolg gehabt ?
Gruss
Jürgen
Hallo Jürgen
Du schriebst:
>> Was machst Du, nur Protokolle definieren, oder auch programmieren.> Mich Tag für Tag mit Protokollen anderer Geräte Rumschlagen> [...]> Da weis man eben was man besser machen kann.
Schön, ich möchte eigentlich ein universelles Protokoll, was alles kann.
Sprich nicht nur Heizung, sondern Lichtschalter, Lampen, Dimmer,
Sensoren, Alarmanlage, Türöffner und was ich sonst noch so habe.
Nach Möglichkeit alles über einen Bus, und wenn es geht auch irgendwie
geschützt gegen Übertragungsfehler und Kollisionen.
Dann könnte man an die jeweiligen Geräte die unterschiedlichsten
Interfaces anbinden (CAN, RS232, I2C, RFM12) Speziel für das letzte
braucht man zwingend eine Kollisionserkennung und / oder Vermeidung,
da es ja ein Funktprotokoll ist.
> Die AMX ist letztendlich ein Freiprogrammierbares Steuersystem.> Dessen Support und Programmierung ist mein Täglich Brot.
Das habe ich auch auf Google gefunden und das gefällt mir sehr gut.
Ich habe nämlich noch kein System um die vielen einzelnen Geräte zentral
zu bedienen. Ich dachte an ein EPAI-Board mit TFT und Touchscreen. Suche
zur Zeit noch nach einem Touchscreen (15-19"), was kostet denn so ein
AMX? Preise habe ich irgendwie keine gefunden, ist bestimmt sauteuer.
Dario
Dario C. wrote:
>>> Was machst Du, nur Protokolle definieren, oder auch programmieren.>> Mich Tag für Tag mit Protokollen anderer Geräte Rumschlagen>> [...]>> Da weis man eben was man besser machen kann.> Schön, ich möchte eigentlich ein universelles Protokoll, was alles kann.> Sprich nicht nur Heizung, sondern Lichtschalter, Lampen, Dimmer,> Sensoren, Alarmanlage, Türöffner und was ich sonst noch so habe.>> Nach Möglichkeit alles über einen Bus, und wenn es geht auch irgendwie> geschützt gegen Übertragungsfehler und Kollisionen.
Das würde ich nicht tun sondern so:
Ich würde Empfehlen ein Basisprotokoll zu machen, das einfach in einem
Terminalprogramm verwendet werden kann.
Erfordert die Hardware eine Prüfsumme, kümmert diese sich um die
Verpackung.
RS232 und I2C sollten so sicher sein, das hier keine Prüfsumme notwendig
ist. Zumindest auf kürzen Längen und niedrigen Datenraten.
CAN hat seine eigenen Sicherungsalgorhythmen.
RFM12 braucht auf alle Fälle eine Prüfsumme.
Stelle dir das so vor: (jeweils ohne [] die dienen nur der
Veranschaulichung)
Basisprotokoll: [?TEMP-MAX]
Antwort [@TEMP-MAX=22]
Abgeschlossen mit CR und eventuell LF
Bei RMF12 eben so
[R009][?TEMMP-MAX][Checksumme 16 Bit]
[R012][@TEMP-MAX=22][Checksumme 16 Bit]
Das Protokoll ist jetzt mal Ohne groß nachdenken Entstanden.
Jedes Kommando ist per CR abgeschlossen.
Jedes Kommando beginnt mit einem Kennzeichen ("!" tue was, "?" sag mir
den aktuellen Wert, "@" Antwort), Das Kommando Schlüsselwort Endet mit
einem immer gleichen Zeichen, hier eben "-". Sehr einfach zu parsen.
Einfach zu Implementieren, das Basisprotokoll wird einfach eingefügt in
die Schnittstellen abhängigen Protokolle.
Kann auch einfach im Terminal Simuliert werden für Tests.
Um das Auszudenken, müsste man Allerdings mal alle Angedachten
Funktionen in einer Liste haben. Dann kann ich da mal länger drüber
nachdenken
> Dann könnte man an die jeweiligen Geräte die unterschiedlichsten> Interfaces anbinden (CAN, RS232, I2C, RFM12) speziell für das letzte> braucht man zwingend eine Kollisionserkennung und / oder Vermeidung,> da es ja ein Funkprotokoll ist.
Siehe oben. Schwierig ist es natürlich, wenn die Jeweilige Anbindung
keine eigene Intelligenz hat sondern nur Pegelwandler ist. Aber man wird
so oder so nicht jedes Protokoll implementieren können.
> [...]> zur Zeit noch nach einem Touchscreen (15-19"), was kostet denn so ein> AMX? Preise habe ich irgendwie keine gefunden, ist bestimmt sauteuer.
Uff, grob gesagt fängt das bei ca 3000€ an, aber das ist Off Topic. Wenn
Du mehr wissen Möchtest, gerne per PM.
Gruss
Jürgen
Hallo Jürgen,
I²C Bus wäre auch mein Favorit, weil ich bei der letzten Renovierung
einen Kabelring verlegt habe, wo ich die Module mit Daten und Strom
versorgen kann. Der Bus läuft beim Atmel unter TWI (SDA liegt auf Port
E7 und SCL auf Port E6). Port E6 wird leider schon für die
Reflexlichtschranke benötigt. Die müsste man auf Port E9 Umwehrdrahten
und die SW anpassen oder einen Tiny verwenden und an die RS-232 klemmen,
der die Daten nur durchreicht. Ist aber alles noch viel Arbeit, die erst
später angegangen wird. Zuerst muss das Teil mal so spielen wie bisher.
Wenn Du Lust hast, kannst Du einen Parser schreiben, der reinkommende
Befehle analysiert.
void Parser_ReceiverChar( char c)
{
static string cmd_str;
......
......
if (bCMDComplete)
{
// Befehl vollständig eingelesen
ParseCmd( string cmd_str);
cmd_str="";
}
else
strcat( cmd_str, c);
return;
}
Die Funktion würde von der RS232 bei jedem empfangenen Zeichen
aufgerufen. Ist eine Befehlszeile als Vollständig eingegangen erkannt
(CRLF), wird sie an den Parser übergeben:
void ParseCmd( string cmd_str);
Der Parser ermittelt den Befehl, die Anzahl der Parameter und ruft die
zugehörige Bearbeitungsmethode auf.
Analyse...
CMD=...
Param1=...
Param2=...
Param3=...
switch(CMD)
{
GET_BDS1: // Kommando BDS1 adr?
Get_ByteDataSet1(Param1);
break;
SET_BDS1: // Kommando BDS1 adr, data
Set_ByteDataSet1(Param1, Param2);
break;
GET_BDS2: // Kommando BDS2 adr?
Get_ByteDataSet1(Param1);
break;
SET_BDS2: // Kommando BDS2 adr, data
Set_ByteDataSet1(Param1, Param2);
break;
GET_BPDS3: // Kommando BPDS3 adr, passw?
Get_ByteProtectedDataSet1(Param1, Param2);
break;
SET_BDS3: // Kommando BPDS3 adr, data, passw
Set_ByteProtectedDataSet1(Param1, Param2, Param3);
break;
STIME: // Kommando 19:18:30
// Setzt die Uhrzeit Std, Min, Sek
Set_Time( Param1, Param2, Param3 );
break;
SDate: // Kommando D 15.03.2008
// Setzt das Datum Tag, Monat, Jahr
Set_Date( Param1, Param2, Param3 );
break;
SProgTime: // Kommando ST 1, 2, 08:30 (Abschaltzeit Montag 8:30)
// Setzt eine Programnmierzeit für einen Wochentag
Set_ProgTime( Param1, Param2, Param3 );
break;
GProgTime: // Kommando ST 3, 2? (Abfrage der zweiten Schaltzeit für
Mittwoch )
// Fragt eine Schaltzeit eines Wochentages ab
Get_ProgTime( Param1, Param2, Param3 );
break;
GVersion: // Kommando V?
GetVersion();
break;
default: // Unbekannter Befehl, Fehlerhinnweis senden
SendErrorInfo(cmd_str);
}
Im Prinzip könnte das wie oben aufgebaut sein. In CMD wird das erkannte
Kommando (#define, enum) abgelegt. In Param1-3 die mitgelieferten
Parameter. Im Switch wird die Bearbeitungsfunktion mit den zugehörigen
Parametern aufgerufen. Einleitungssequenzen für Kommandos können
natürlich auch wie von Dir vorgeschlagen aussehen (!, ?, @). Das bringt
mich noch auf eine Idee. !DS1, P#, P1, P2, ...PN\CR\LF würde bedeuten
Setze Data Set 1, es folgen P# (Anzahl) Parameter P1...PN.
Zunächst mal wird es nur darum gehen, in eine Interne Datenstruktur an
einer bestimmten Adresse ein Byte zu schreiben oder zu lesen. Geh mal
von 3 Datesets aus wobei das dritte Passwortgeschützt ist.
Wenn noch genug Speicherplatz bleibt, könnte man auch komfortablere
Befehle realisieren wie das Setzen der Zeit, Datum, Schaltzeiten,
Versionsabfrage usw.
Wäre schön, wenn Du ein Grundgerüst für den Parser liefern könntest mit
den zwei Schnittstellenfunktionen:
void Parser_ReceiverChar( char c); und
void ParseCmd( string str);
Die anderen Funktionen kannst Du als gegeben annehmen. Wenn das Gerüst
mal steht, kann man es relativ leicht um weitere Befehle erweitern, die
Namen der Befehle ändern bzw. die Anbindung vervollständigen.
Im Moment schlage ich mich mit dem Thema Regelungstechnik rum. Dabei
habe ich ein Problem mit dem Integrierer. Wenn die Temperatur ständig
über der eingestellten steht (z.B. Thermostat steht auf 16°C und Raum
ist aber über 18°C Warm, dann summiert der Intergrierer ins unendliche.
k
Ik = Sum (Soll-Ist)
0
Wo legt man da sinnvollerweise eine Grenze? Werden negative Werte
zugelassen?
Empfiehlt sich für eine Simulation der Heizstrecke ein PT2 glied und von
welchen Totzeiten (Tu) für das Ansprechen und T95 (Zeit für erreichen
von 95% der Solltemp.) kann man in der Praxis bei einer Heizung
ausgehen. Das hängt natürlich von Raumgröße, Heizkörper,
Vorlauftemperatur, Isolation, Aussentemperatur ab. An die
Heizanlagenpraktiker: Wie ist die zu erwartenden Bandbreite für das
Ansprechverhalten (Tu, T95) der Heizung?
Je wärmer schon ein Raum ist, desto langsamer vollzieht sich wohl ein
zusätzlicher Temperaturanstieg. Wenn das Ventil linear ausgefahren wird,
ändert sich der Durchfluß auch linear oder überproportional?
Falls sich jemand mit der Thematik auskennt, wäre ich für ein paar Tips
dankbar.
Gruß
Karim
Ich kann mir mal meine Gedanken machen, wie Prinzipiell das ganze
Aussehen soll.
Erst muss die Basis stehen, also das Protokoll, dann kann ich die Parser
Routinen machen.
Dann wäre es aber wohl Sinnvoll wenn ich auch SVN Zugriff hätte.
Ich muss aber gleich von Vorne herein sagen, das ich Zeitlich etwas
knapp bin. Wenn dann kann ich nur am Wochenende, aber Nächste Woche hat
das ja 4 Tage ;-)
Ich würde mir dann das Protokoll zu Ende denken, Grob Notieren und dann
den Parser schreiben und testen.
Gruss
Juergen
Hallo Dario, Hallo Karim,
Ich habe mir jetzt erst mal WinAVR und Co installiert (Arbeite
normalerweise mit Linux). Danke der Anleitung im SVN war das ja einfach
:-) Danke an den Autor.
Allerdings lässt sich das aktuelle SVN nicht übersetzen. Das sind ein
paar ";" an der falschen Stelle. Und ein Kommentar ist wohl falsch ("/*"
statt "//").
wie gesagt werde ich mir das mal ansehen und meine Gedanken zu einem
Protokoll machen und versuchen einen Parser aufzusetzen.
Wäre es Möglich auch SVN Zugriff zu bekommen ?
Dann könnte ich meine Ideen dort direkt pflegen und so schneller
Feedback von Euch bekommen.
Gruss
Jürgen
Hi Dario
natürlich kannst du mir Fragen stellen. Aber bitt direkt an:
peters-lothar@online.de
PS. dass diese Elektronik keinen aufwendigen Speicher besitzt, habe ich
mir schon gedacht...
Aber.. nun.. ich bin kein Elektroniker.. aber man könnte doch -so fern
man alles richtig macht und diesen Aufwand betreiben möchte -
Parallele Stromversorgung vorsehen oder nicht ?
Ich meine, wenn man zusätzliche Akkus vor dem Wechsel kontaktiert dann
habe ich doch - parallel - keine erhöhung der Spannung sondern nur die
Stromstärke erhöht - oder nicht ?
Es fließt doch kein größerer Strom und nach dem Kontakt der zusätzlichen
Akkus kann ich doch in aller Ruhe - sofern dieses Gefummel auf dem
beengten Raum glückt - die leeren Akkus entfernen. Oder ?
bis dann
Lothar
Hallo Lothar
Du schriebst:
> PS. dass diese Elektronik keinen aufwendigen Speicher besitzt, habe ich> mir schon gedacht...
Da hast Du mich falsch verstanden. Die Elektronik hat einen solchen
Speicher. Die Frage ist aber, ob die Programmierer den auch benutzt
haben.
Ich habe es gerade einmal getestet bei einem Original 2.04er:
Man kann die Batterien wechseln und danach ist die Programmierung noch
vorhanden, nur die Uhrzeit muss man neu stellen.
Dario
@jsachs: Mit welcher Distribution? Unter Gentoo habe ich die passende
Crossdev-Toolchain recht fix installiert bekommen, danach mußte ich halt
noch einzelne Änderungen am Code vornehmen ...
Ich hatte mir auch mal ein paar Gedanken gemacht, was alles steuerbar
sein sollte. Hier mal ein Anfang:
- aktiviere/deaktiviere Debug output
- aktiviere/deaktiviere Echo
- show (and set) actual valveposition
- show and set timetable with temperatures
- show actual temperature
- show Time and date / DLS /Leap Jear
- show/set serial number
- show/set tuning Parameters (P,I,D,DB (DEADBAND) - for PID controller?)
- show Battery Voltage
- show Battery Change Date
- show/set Mode (Auto / Manual)
- show Last-Error Log min-temp - max-temp
- show Calibration Data / start Calibration
- show/set valve Lift minEnd maxEnd
- show/set window function (max-time, temp-fall responsiveness)
- show/set valve-protection (ON/OFF, period)
- show/set alarm (temp, battery)
- reset device / bootloader
- set password
- reset/download/upload Configuration
Jens Müller wrote:
> @jsachs: Mit welcher Distribution? Unter Gentoo habe ich die passende> Crossdev-Toolchain recht fix installiert bekommen, danach mußte ich halt> noch einzelne Änderungen am Code vornehmen ...
Ich nutze Suse Linux 10.3. Das ist auch nicht das Problem. Ich
programmiere AVRs schon Jahre unter Linux in C(++). Anfangs auch in
Assembler, aber das war mir doch zu mühselig :-)
Die RPMs für Suse 10.3 sind die im OSS Repository.
Aber so ist es erstmal einfacher. Wenn alles Läuft kann ich das immer
noch unter Linux weiter machen :-)
So spare ich mir im Moment auch die Makefile pflege.
Danke trotzdem
Jürgen
@Dario und Karim,
Ich war mit meinem Protokoll schneller als das Wiki :-)
Habe das mal da eingetragen, bin aber schon viel weiter, aufgrund der
Diskussion hier.
Ich habe meinen Vorschlag mal im SVN unter "/doc/protokoll/"
einsortiert.
Und habe das auch fast schon Implementiert. Der Speicherverbrauch ist
Minimal, das meiste liegt im Flash.
Bin Momentan an den ISRs, dann kann ich das auf meinem atmega16 mal
testen. an meine HR20E will ich noch ned ran :-)
Mein Hauptproblem ist das ich noch keinen Umsetzer auf 3,3V habe.
Gruss
Juergen
Jürgen Sachs wrote:
> Mein Hauptproblem ist das ich noch keinen Umsetzer auf 3,3V habe.
Eventuell ein Daten-Kabel vom Siemens Handy vorhanden? Soll gehen!
--- Test auf eigene Gefahr ;-)
Hallo Jürgen,
elegant liesse sich das mit der RS-232 lösen, wenn Du einen Simulator
für den UART einsetzen würdest, wie es Ihn hier
http://www.helmix.at/hapsim/#hapsimdownload gibt. Dazu müsstest Du aber
auf Windows (das Standardbetriebssystem ;-) umsteigen oder nach einer
Lösung für Linux suchen.
Dann könntest Du Dir den ganzen Kabelsalat ersparen und das bequem
simulieren. Wäre super praktisch.
Gruß
Karim
Mal was zur Temperaturmessung:
Ich habe nun die Temperaturkennline versucht aufzunehmen. Dazu habe ich
ein Original HR20 genommen und in den Ansichtsmodus 02:02 gestellt
(Ist-Temperatur anzeigen) und mein Bastel-HR20 so programmiert dass es
mir immer den A/D Wert des Thermofühlers anzeigt.
Dann die beiden den PTC ausgelötet und einen Stecker angelötet.
Nun habe ich eine Spindeltrimmerkaskade 28k-58k an den original HR20
angeschlossen und den Poti so eingestellt, dass dieser 5C° anzeigt.
Dann habe ich den Poti an meinen HR20 angeschlossen und den ADC Wert
abgelesen. Daraus habe ich eine Tabelle erstellt.
Eine Funktion durch diese Messwerte zu legen war weniger erfolgreich.
Ein einigermaßen gutes Ergebnis konnte ich erst durch ein Polynom
dritten Gerades erzielen.
Zusätzlich habe ich ein normales Thermometer neben den original HR20
gelegt um die Unterschiede zu Messen, wobei ich darauf gekommen bin,
dass der HR20 immer 1-2°C weniger anzeigt. Es scheint som dass der
Temperaturunterschied in Heizungsnähe direkt bei der Messung
ausgeglichen wird.
All das veranlasst mich nun dazu die Temperaturkennline disket mit
einigen Messpunkten zu erfassen und dazwischen linear zu interpolieren.
Mit den folgenden Kennlinienpunkten bin ich schon ganz zufrieden.
ADC - Temp °C
675 - 5,0
614 - 10,0
549 - 15,0
472 - 20,0
397 - 25,0
340 - 30,0
304 - 34,0
Meine Idee ist nun folgende:
1
// Values for ACD to Temperatur conversion.
2
// Will be stored in EEPROM later, so they can be adapted later
Hier mal was zu dem Problem, dass einige die HR20 immer das Jahr
anzeigen, weil sie sich sporadisch resetten.
Ich habe jetzt auch einen HR20, bei dem das auftritt.
Nachdem ich das näher analysiert habe liegt es tatsächlich an den
Batteriekontakten. Konkret lag es in meinem Fall lag es nicht daran,
dass die Lasche von dem Zahnrad verschoben wird, sondern schlicht
daran, dass man durch einfaches Klopfen gegen den HR20 die Spannungs-
versorgung kurzzeitig unterbrechen und damit einen Reset auslösen
konnte.
Bei mit lag es an einer Kombination aus alten Akkus (mit korrodierten
Kontakten) und zu schwach eingestellten Federn. Wenn man den Hebel zum
Entfernen der Batterien dreht, sollten einem die Batterien schon ein
kleines Stück entgegenkommen. Ist das nicht der Fall ist Abhilfe leicht:
Einfach mit einem breiten Blech das Drehrad abhebeln.
(Das Drehrad ist nur über das Gehäuse geklippst).
Dann die Batterielaschen nach innen biegen.
Wenn alles richtig lief, stehen die Batterien jetzt ein deutliches
Stück am anderen Ende über und werden durch die Lasche in das
Gehäuse gedrückt.
Viel Erfolg
Dario.
Ich habe mal den Parser grundlegend eingebaut.
Allerdings musste ich aus technischen Gründen wieder zu Linux als
Entwicklungsumgebung wechseln. Ich hoffe es geht alles unter Windows.
Feedback willkommen !
- Im Moment gehen Notify für Temperatur, Version und Batterie.
- Im Moment gehen Kommandos für Temperatur, Version und Batterie.
Allerdings Temperatur und Batterie noch mit Fake Werten. Ich muss erst
mal sehen wo ich die Echtwerte herbekomme.
Gruss
Juergen
Also bei mir geht's.
Insbesondere ist delay in main.h definiert.
Linking: main.elf
avr-gcc -mmcu=atmega169 -I. -gdwarf-2 -DF_CPU=4000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=obj/main.o -std=gnu99 -Wundef -MMD -MP
-MF .dep/main.elf.d obj/main.o obj/adc.o obj/lcd.o obj/rtc.o obj/motor.o
obj/serialprotocol.o --output main.elf -Wl,-Map=main.map,--cref -lm
- so lautet der Linker-Befehl bei mir.
Warum sieht das bei Dir so anders aus?
Ah jetzt ja.
Ich hab im Moment eine angepasste Umgebung am laufen, da ich zum
entwickeln einen mega16 nehme. Mir fehlt noch die 3V Anpassung für
meinen usbprogV3.
Da brauche ich nicht alle Programmteile.
Aber so wie das aussieht muss ich mir da jetzt was basteln damit ich
meinen HR20E direkt programmieren kann.
Spätestens bei der rtc.c ist Schluss mit Kompatibilität :-(
Und nachdem ich hier die Funktionen aufrufen muss, geht nichts mehr.
Danke, ich habe überall nach der Funktion gesucht, außer in der main.c.
Juergen
Eine Frage zu dem Seriellen Protokoll.
Hier kam der Wunsch auf Datasets zu lesen und zu schreiben.
Was genau soll hier geschrieben / gelesen werden ?
- Variablen
- EEPROM
- Flash
Wenn ich die Infos hätte könnte ich das Theoretisch (ich kann es nicht
testen) Implementieren.
Gruss
Juergen
Jürgen Sachs wrote:
> Eine Frage zu dem Seriellen Protokoll.> Hier kam der Wunsch auf Datasets zu lesen und zu schreiben.>> Was genau soll hier geschrieben / gelesen werden ?> - Variablen> - EEPROM> - Flash
Verstehe ich das so, das Du wissen möchtest was über den seriellen Port
alles Veränderbar/Abfragbar ist?
Zum HR-20
-soll Temp (Wert oder auch "off")
-man./auto
-Fenster-offen-Frkennung ein/aus
-Zeit/Datum & Programme + Temp´s (um alle von der Haussteuerung zu
setzen)
vom HR-20
-eingestellete Temp (kontrolle)
-Ventielöffnung in Prozent
-ist Temp (Messung des HR-20)
-Batterie Zustand (wenn es möglich ist den zu ermitteln)
Das fällt mir gerade ein und ist bestimmt nicht vollständig.
Gruß
Jan
Jan David wrote:
>> Eine Frage zu dem Seriellen Protokoll.>> Hier kam der Wunsch auf Datasets zu lesen und zu schreiben.>>>> Was genau soll hier geschrieben / gelesen werden ?>> - Variablen>> - EEPROM>> - Flash>> Verstehe ich das so, das Du wissen möchtest was über den seriellen Port> alles Veränderbar/Abfragbar ist?
Jein, hier wurde immer wieder das Wort Dataset lesen und schreiben
verwendet. Hier wollte ich wissen was gemeint ist.
Aktuell kann die Software (Theoretisch, ich konnte es noch nicht auf
einem HR20) testen:
- Temperatur
- Ventilöffnung
- Batteriespannung (laut Code kann man die messen, auch wenn ich laut
Schaltplan keine Verbindung zu einem AD Eingang sehe)
- Version
- Uhrzeit
Generell werden alle Veränderungen Automatisch gemeldet, die Uhrzeit nur
jede Minute.
Im Moment kann man nur manuell einen "Calibrate" des Ventils auslösen.
Rein sollte (Übernehme ich nachher ins Wiki):
- Soll Temp setzen
- Manuell / Auto Umschaltung
- Datum / Zeit Einstellung
- Sommer Winterzeit setzen
- Programm für die Wochentage 1-7, vermute hier auch 2 Zeiten pro Tag
- Temperatur für Absenk Temp und Normal Temp
- Bootloader starten für Update
Setzen und abfragen, wo möglich.
Aber mir ginge es um die Datasets, oder war hier die Tagesprogramm
Programmierung gemeint ?
Gruss
Juergen
"- Batteriespannung (laut Code kann man die messen, auch wenn ich laut
Schaltplan keine Verbindung zu einem AD Eingang sehe)"
Vielleicht über einen integrierten Spannungsregler?
Jens Müller wrote:
> "- Batteriespannung (laut Code kann man die messen, auch wenn ich laut> Schaltplan keine Verbindung zu einem AD Eingang sehe)">> Vielleicht über einen integrierten Spannungsregler?
So wie ich das sehe hängt die Spannungsversorgung des uC nur an einem
Digitaleingang "PE6". Da aber genug Analog Eingänge frei sind, kann man
das sicher noch "Patchen" wenn man will :-)
Hauptsache wir bekommen eine Meldung "Battery low". Die Original
Software kann das ja auch.
Hallo,
hab gerade nicht viel Zeit. Nur soviel. Die Batt. Spannung wird dadurch
ermittelt, dass man die Refferenzspannung per interner Aufschaltung
misst, wobei man als Refferenz die Spannungversorgung des ADC verwendet.
Das kann man so programmieren und über den Weg ist es möglich die
Versorgungsspannung zu messen, ohne irgendetwas verdrahten zu müssen.
Die Datasets die gelesen und geschrieben werden sollen sind noch nicht
definiert. Dabei wird es sich aller vorraussicht nach um eine Struktur
handeln, die diverse Daten wie sie oben von Euch schon beispielhaft
aufgezählt sind enthalten.
Beschreiben und lesen geht dabei mit weniger komfort, weil einfach
bestimmte Bytes im Speicher bearbeitet werden und man genau wissen muss,
was man tut. Damit lässt sich alles setzen auch ohne das man High Level
Befehle dafür implementiert.
Gruß
Karim
Karim L. wrote:
> Hallo,>> hab gerade nicht viel Zeit. Nur soviel. Die Batt. Spannung wird dadurch> ermittelt, dass man die Refferenzspannung per interner Aufschaltung> misst, wobei man als Refferenz die Spannungversorgung des ADC verwendet.> Das kann man so programmieren und über den Weg ist es möglich die> Versorgungsspannung zu messen, ohne irgendetwas verdrahten zu müssen.
Wenn Du das sagst glaube ich dir mal :-) Hauptsache deine Funktion
liefert den richtigen Wert. Für mich ist die eine "Black Box".
> Die Datasets die gelesen und geschrieben werden sollen sind noch nicht> definiert. Dabei wird es sich aller vorraussicht nach um eine Struktur> handeln, die diverse Daten wie sie oben von Euch schon beispielhaft> aufgezählt sind enthalten.> Beschreiben und lesen geht dabei mit weniger komfort, weil einfach> bestimmte Bytes im Speicher bearbeitet werden und man genau wissen muss,> was man tut. Damit lässt sich alles setzen auch ohne das man High Level> Befehle dafür implementiert.
Hmm, das müssen wir mal genauer definieren. Weil das Dataset Kommando ja
wieder wissen muss wohin mit den Daten.
==============
Im übrigen bin ich nun soweit das ich einen funktionierenden Bootloader
für das XModem Protokol habe. Habs Heute getestet, wieder mit meinem
mega16. Klappt prima mit Hyperterminal.
1) File auswählen
2) senden drücken
3) AVR rebooten
4) Übertragung startet
5) wenn fertig wird wieder ins Hauptprogramm gesprungen
Allerdings ist der mega169 Bootloader viel größer, vermutlich durch
andere Startfiles. Das sehe ich mir noch an.
Ich habe hier auf fertige Routinen zurück gegriffen, siehe File Header
im Unterverzeichnis "Bootloader/hr20boot.c".
Leider braucht der fast 1 kb. hier kann man viel machen, aber unter 512
Byte zu kommen halte ich für fast unmöglich. Als Größe haben wir eben
512 Byte, 1 kByte oder eben 2 kByte.
==============
Das nächste Problem ist die Größe des eigentlichen HR20 Programms.
Ohne Optimierung ist es 15 kb groß, mit nur noch 9kb.
Auch das sehe ich mir an, aber so war es gedacht, das der Compiler hier
viel Optimieren kann.
Gibt es einen Grund das Ihr noch ohne Size Optimierung arbeitet ?
Gruss
Juergen
Den Code hat bisher Dario geschrieben. Der hat schon einige Erfahrung
damit und hat das so schnell geschrieben, dass ich da nicht ganz
mitkomme. Hab hier und da zu der einen oder anderen Idee beigetragen und
beschäftige mich zurzeit mit der Regelungstechnik.
Beim Bootloader dachte ich an den Einsatz dieser
http://avrubd.googlepages.com/avrub.htm Version, weil man die auch für
andere Megas einsetzen kann und sich dann nicht alles wieder neu
zusammensuchen muss.
Wenn der AVR losstartet, sollte er eine Checksumme über den Codebereich
ermitteln und mit einem Eintrag im Code vergleichen. Stimmen beide
überein, ist alles ok und es wird zur Main Routine der Hauptapliaktion
verzweigt. Wenn nicht, wird der Bootloader gestartet, der dann auf Daten
an der Schnittstelle wartet und im Display wird boot ausgegeben oder ein
Punkt blinkt.
Die Checksumme muss man entweder ins EEprom schreiben, auf eine Adresse
legen, die bei der Checksummenbildung nicht miterfasst wird oder den zu
brennenden Code zweistufig generieren. -> Code erzeugen, Chaecksumme
berechnen, Checksumme in Code (Konstante) eintragen, Komplement für
Checksumme berechnen und ebenfalls eintragen die dafür sorgt, das die
erste Eintragung neutralisiert wird, so dass die Checksummeneintragungen
nicht die bereits ermittelte Checksumme ändert, Code erneut übersetzen
und flashen.
Diese Prüfung sichert, dass bei fehlerhaftem Flashen der Bootloader
wieder aufgerufen wird und nicht ein JTAG nötig wird, um das Modul
wieder in Gang zu setzen.
Der Bootloader sollte auch vom Menü startbar sein und muss es auf
jedenfall per Befehl an der Schnittstelle.
Gegen den Einsatz der Optimierung spricht nix ausser das es beim
Debuggen Probleme bereiten kann. Da sollte es ein Pragma geben, um
gegebenenfalls gezielt Bereiche ohne Optimierung übersetzen zu können,
in denen man einen Fehler suchen möchte.
Wenn jetzt schon 9kB mit Optimierung verprasst sind, werden wir
wahscheinlich den Code etwas straffen müssen.
Den Zeitaufwand habe ich etwas unterschätzt. Muss sagen, dass ich nicht
soviel Zeit spendieren kann, wie ich gerne würde, so dass es bei mir nur
in keinen Schritten weiter geht und mansche Dinge wollen erst erarbeite
sein. Bitte daher nicht böse sein, wenn masche Antwort auf sich warten
lässt.
Gruß
Karim
Karim L. wrote:
> Beim Bootloader dachte ich an den Einsatz dieser> http://avrubd.googlepages.com/avrub.htm Version, weil man die auch für> andere Megas einsetzen kann und sich dann nicht alles wieder neu> zusammensuchen muss.
Ich habe mich mal auf XModem festgelegt. Das ganze ist ebenfalls sehr
einfach portierbar und wir brauchen keine zusätzliche Software zum
FLashen schreiben.
Allerdings will ich den jetzt kleiner kriegen, daher wird die
Portierbarkeit leiden.
> Wenn der AVR losstartet, sollte er eine Checksumme über den Codebereich> ermitteln und mit einem Eintrag im Code vergleichen. Stimmen beide> [...]> Diese Prüfung sichert, dass bei fehlerhaftem Flashen der Bootloader> wieder aufgerufen wird und nicht ein JTAG nötig wird, um das Modul> wieder in Gang zu setzen.
Das habe ich mal soweit geprüft. Es wird im Bootloader gestartet, und
nach ca 10 Sekunden in die Applikation gesprungen. Steht hier nur Müll
resetet der Atmel (oder eben Manuell) und springt wieder in den
Bootloader. Hab das mit ner Übergroßen Mülldatei probiert, war kein
Problem.
Sol wirklich eine Checksumme rein, könnte man auch folgendes machen:
- nach erfolgreichem übertragen der Firmware wird eine Checksumme
berechnet und vom Controller in die letzte Page vor dem Bootloader
geschrieben. kostet allerdings 128 Byte (Seitengröße).
> Der Bootloader sollte auch vom Menü startbar sein und muss es auf> jedenfall per Befehl an der Schnittstelle.
Jep, kommt als nächstes. Sollte kein Problem sein, Eventuell über einen
Reset durch den Watchdog. Geplant ist aber ein direkter Sprung in den
Bootloader.
> Gegen den Einsatz der Optimierung spricht nix ausser das es beim> Debuggen Probleme bereiten kann. Da sollte es ein Pragma geben, um> gegebenenfalls gezielt Bereiche ohne Optimierung übersetzen zu können,> in denen man einen Fehler suchen möchte.> Wenn jetzt schon 9kB mit Optimierung verprasst sind, werden wir> wahscheinlich den Code etwas straffen müssen.
Ja, ich habe mir mal angesehen was den Code so aufbläst. Ich bin kein
Assembler Spezialist, aber was der Compiler ohne Optimierung macht ist
... (Das ist klar, man sagt mach mal und Optimiere nichts).
Aber das aus einer Funktion die nur einen Wert einer Variablen Meldet 40
Befehle werden... Mit Optimierung ist es wie es sein soll.
Am Code sehe ich nicht allzu viel Optimierungs Potential ohne das die
Lesbarkeit leidet. Zudem muss man dran denken, das Funktionen wie ATOI
und ITOA auch etwas Platz brauchen. Aber kürzer bringt man das fast
nicht hin.
> Den Zeitaufwand habe ich etwas unterschätzt. Muss sagen, dass ich nicht> soviel Zeit spendieren kann, wie ich gerne würde, so dass es bei mir nur> in keinen Schritten weiter geht und mansche Dinge wollen erst erarbeite> sein. Bitte daher nicht böse sein, wenn masche Antwort auf sich warten> lässt.
Ja, mir geht es hier ähnlich. Was ich Heute nicht schaffe und evtl
Morgen, bleibt liegen bis zum nächsten Wochenende.
Ich muss jetzt nur zusehen wie ich den HR20E geflashed bekomme mit
meinem usbprogV3. Das Levelshifterboard macht ja 3.3V, das ist etwas
viel nehme ich an.
Dann könnte ich endlich mal am Lebenden Objekt testen. Im Moment ist nur
noch alles Theorie und Simulator.
Gruss
Juergen
Karim L. wrote:
> Für die Pegelanpassung kannst Du einen MAX3222 verwenden, den es z.B.> bei Rechelt gibt:
Für die RS232 ja. Mir geht es im Moment erst mal um den JTAG. Irgendwie
muss mein Bootloader ja mal in den HR20E rein ;-)
> http://www.reichelt.de/?SID=28JATM4qwQARwAAAUphcs495a2de94ead88ac931d991e5f91449e;ACTION=4>> Datenblatt:> http://www.ortodoxism.ro/datasheets/maxim/MAX3222-MAX3241.pdf
Verflixt ich habe nur den ST232CN hier. Der kann nur 4,5 - 5,5V.
> Spannungsversorgung kannst Du dabei vom Modul anzapfen.
Mein Hauptproblem ist das ich nachher an ein Modul ran muss das im
Moment auf 5V Designed ist. Das aber nur mit RX un TX. Aber da bastle
ich mir was. Das schöne ist das ich die Invertierung der Signale an
meinem Modul beeinflussen kann. Ich nehme an hier baue ich mir was mit
zwei Transistoren und 2 Pullups. Ich bekomme ja nie negative Spannungen,
dann sollte das einfach gehen.
Ob das auch beim JTAG geht weis ich nicht. Aber ich glaube da ist keine
Signal Bidirektional ?!
> Finde es gut, wenn mehrere an dem Projekt arbeiten, weil es entlastet.> Ein etwas höherer Aufwand entsteht dabei mit dem Koordinieren und das> der rote Faden nicht verloren geht.
Das Problem hat man immer wen mehrere an einem Projekt arbeiten. Aber es
klappt doch prima im Moment !
Jeder hat seinen Bereich.
Gruss
Juergen
Du kannst zum Flashen an den Batterieanschlüssen vom HR20E von einer
externen Qeulle oder dritte Batterie 4.5-5V drauf geben. Der Atmel kann
dass schlisslich und beim Rest der Beschaltung sehe ich kein Hindernis.
Aber achtung, die Spannung darf nicht höher sein. Hatte schon mal mit
einem Spike von meinem Netzteil ein Modul ins Nirvana befördert.
Ansonsten müsste es auch mit einem Inverter per Transistorschaltung
gehen, um ein 3.3V an ein 5V System anzukoppeln auch wenn nur 3.3V zur
Verfügung stehen. Musst aber schauen ob die Signale schon invertiert
sind oder nicht. Eventuell brauchst Du dann zwei Invertierer
hintereinander.
Gruß
Karim
Karim L. wrote:
> Du kannst zum Flashen an den Batterieanschlüssen vom HR20E von einer> externen Qeulle oder dritte Batterie 4.5-5V drauf geben. Der Atmel kann> dass schlisslich und beim Rest der Beschaltung sehe ich kein Hindernis.> Aber achtung, die Spannung darf nicht höher sein. Hatte schon mal mit> einem Spike von meinem Netzteil ein Modul ins Nirvana befördert.
Aaaah, Supper... Da hatte ich bedenken das das geht.
Der usbProg kann Spannung vom USB liefern über ne Shotky Diode.
Eben nachgemessen. kommen 4,7V raus, perfekt !
Ich hatte da zuviel bedenken wegen Lichtschranke und Motor. Nicht das
die Treiber durch den höheren Strom kaputt gehen. Aber ist ja nur zum
Flashen.
> Ansonsten müsste es auch mit einem Inverter per Transistorschaltung> gehen, um ein 3.3V an ein 5V System anzukoppeln auch wenn nur 3.3V zur> Verfügung stehen. Musst aber schauen ob die Signale schon invertiert> sind oder nicht. Eventuell brauchst Du dann zwei Invertierer> hintereinander.
Jep, aber das ist kein Problem. Wie gesagt kann ich die Invertierung
auch in Software machen.
Besten Dank für die Tips.
Juergen
Karim L. wrote:
> Du kannst zum Flashen an den Batterieanschlüssen vom HR20E von einer> externen Qeulle oder dritte Batterie 4.5-5V drauf geben. Der Atmel kann> dass schlisslich und beim Rest der Beschaltung sehe ich kein Hindernis.> Aber achtung, die Spannung darf nicht höher sein. Hatte schon mal mit> einem Spike von meinem Netzteil ein Modul ins Nirvana befördert.
@Karim
Ich habe das eben mal probiert. Aber ich scheitere schon am auslesen der
Signatur. Hier bekomme ich immer 0xFFFFFF.
Das hatte ich mit dem Pollin Board auch schon, da war die Verkabelung
dann falsch.
Ich habe es jetzt nach dem Bild im SVN unter
doc/steckerbelegung/steckerbelegung.jpg verkabelt.
Auch schon TDO und TDI vertauscht und zig mal geprüft.
Eine Idee woran das liegen kann ?
Hallo Jürgen
Du schriebst:
> Ich habe es jetzt nach dem Bild im SVN unter> doc/steckerbelegung/steckerbelegung.jpg verkabelt.> Auch schon TDO und TDI vertauscht und zig mal geprüft.> Eine Idee woran das liegen kann ?
Ich tippe mal es liegt am USB Prog!
Ich habe den auch und dazu die Pegelwandlerplatine [1] und damit habe
ich es auch nicht hinbekommen, weder zu programmieren noch die Signatur
auszulesen.
Mit meinem JTAG-Clone von Olimex[2], der an der seriellen Schnittstelle
hängt habe ich hingegen kein Problem, nur ist es da besser alles über
eine externe 3 Volt Quelle zu versorgen, weil meine alten Mignons nur
noch 2,3 Volt bringen und das nicht zum Betrieb des JTAG ausreicht.
Wie gesagt, mit dem USB-Prog habe ich es auch noch nicht geschafft und
ich habe mir einen Adapter HR20 auf JTAG[3] gebaut, den ich beim JTAG
und beim USB-Prog mit Flachbandkabeln benutze, daher schließe ich Fehler
in der Pinbelegung und der Verkabelung einmal aus.
[1] http://tinyurl.com/2alysy
[2] http://www.olimex.com/dev/avr-jtag.html
[3] http://www.carluccio.de/img/hr20/dev_board.jpg
Dario
Dario C. wrote:
> Ich tippe mal es liegt am USB Prog!>> Ich habe den auch und dazu die Pegelwandlerplatine [1] und damit habe> ich es auch nicht hinbekommen, weder zu programmieren noch die Signatur> auszulesen.
Ups, hab ich mir doch Heute auch den Pegelwandler bestellt. Wenn das
nichts hilft, wäre es echt schade... Eventuell liegt es ja am ATmega169
?
Anderes Timing oder der gleichen.
Im Zweifel löte ich die SPI an und führe diese nach draußen.
> Mit meinem JTAG-Clone von Olimex[2], der an der seriellen Schnittstelle> [...]
Hmm, noch einen Programmer wollte ich mir nicht zulegen, ich habe schon
2 :-)
Vielleicht bekomme ich ja mit meinem Oszi noch raus woran das liegt. Zur
not eben über SPI.
> [...]> und beim USB-Prog mit Flachbandkabeln benutze, daher schließe ich Fehler> in der Pinbelegung und der Verkabelung einmal aus.
Danke für die Links. So ein Adapter Board zu bauen hatte ich als
nächstes vor. Dummer weise ist einer meiner HR20E hinüber und ich muss
mein "Testobjekt" erst mal wieder in den Offiziellen Dienst schicken.
Dachte erst der hätte dieses Kontaktproblem an den Batterien, aber der
macht keinen Mukser mehr.
Danke fürs Feedback.
Juergen
Andy24 wrote:
> Habt ihr auf der basis von diesem Programm angefanngen oder komplett> neu?
Das ist eine komplette Neuentwicklung.
Die Hardware ist aderst aufgebaut und bietet mehr Möglichkeiten.
Es wäre auch sicher nicht klug das Herstellerprodukt 100% zu kopieren,
das könnte Rechtliche Probleme geben.
Was ist der Grund für deine Frage ?
Gruss
Jürgen
Das Programm was da angeboten ist, bedient bloss das vorgänger Modul,
dass nicht mehr verkauft wird. Beim neuen HR20E stehen leider die
Einstellfunktionen über die V24 nicht zur Verfügung bzw. wenn es welche
gäbe, sind sie nicht offengelegt.
Drum ist es nötig, die SW neu zu schreiben die im Modul steckt und eine
Schnittstelle zu implementieren, die wieder das Fernsteuern erlaubt.
Weiterer Vorteil wäre, dass man eigene Funktionen implemetieren kann.
Ein Programm wie das auf der verlinken Seite zu schreiben ist dabei das
geringste Problem. Das ist mit dem Visual Studio in C# schnell
geschrieben.
Gruß
Karim
Hallo,
finde das Projekt sehr gelungen und habe mich auch schon ein bischen
damit beschäftigt. Im Repository vermisse ich eine Datei HR20protocol.c,
die im Makefile explizit verlangt wird
.
.
## Compile
HR20protocol.o: ../source/HR20protocol.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<
.
.
AVR Studio findet beim Zusammenbauen des Projekts einige Funktionen
nicht, die möglicherwiese in der fehlenden Datei sind, oder?
Gruss Wolf
Hallo Wolf,
Du schriebst:
> Im Repository vermisse ich eine Datei HR20protocol.c,> die im Makefile explizit verlangt wird
Jürgen Sachs hat in der rev 53 das Makefile komplett umgestellt.
Vorübegehend schlage ich vor Du lädst Dir das makefile aus einer
Revision davor z.B.: Rev 42.
Da steht dan drin:
Dario C. wrote:
>> Im Repository vermisse ich eine Datei HR20protocol.c,>> die im Makefile explizit verlangt wird
Die Datei ist nur zum Testen bei mir. Die wird nicht benötigt. Dieses
Makefile war nicht fürs Repo gedacht.
> Jürgen Sachs hat in der rev 53 das Makefile komplett umgestellt.> Vorübergehend schlage ich vor Du lädst Dir das makefile aus einer> Revision davor z.B.: Rev 42.
Das war so nicht gedacht. Das Makefile war nur zum Test nicht für das
Repo.
Danke für den Hinweis.
Das Makefile nochmals überarbeiten. Mir ist die komplette Umstellung gar
nicht aufgefallen.
Gruss
Juergen
W.-d. W. wrote:
> Hallo,>> finde das Projekt sehr gelungen und habe mich auch schon ein bischen> damit beschäftigt. Im Repository vermisse ich eine Datei HR20protocol.c,> die im Makefile explizit verlangt wird
Die Datei war nur für Tests gedacht, ebenso wie das Makefile.
Ich hab die Ursprüngliche Datei wieder hergestellt und angepasst.
> AVR Studio findet beim Zusammenbauen des Projekts einige Funktionen> nicht, die möglicherwiese in der fehlenden Datei sind, oder?
Bei mir unter Linux geht es problemlos.
Nur avr-size beschwert sich über nicht passende Parameter. Das ist aber
durch den Unterschied von winavr zu Linux avr tools gegeben. Da gibt es
einen Trick im Makefile, den ich mal einbauen kann.
Ich hoffe jetzt geht wieder alles.
Danke noch fürs Feedback.
Gruss
Juergen
Jürgen Sachs wrote:
> Ich hoffe jetzt geht wieder alles.> Danke noch fürs Feedback.
Hallo,
vielen Dank für die prompten Reaktionen.
Zu den bei mir gefundenen "Fehlern" etwas genauer (ich verwende AVR
Studio 4.13 SP2 und WinAVR 20071221):
Die Fehlerlemendungen beziehen sich auf in serialprotocol.c auf die UART
Register, die zum Mega32 passen, aber nicht zum Mega169P (!!). Ich hab
den Code erstmal so "umgebogen"
.........
#define UDR UDR0 <--- !
#define UCSRB UCSR0B <--- !
#define UDRIE UDRIE0 <--- !
// Functions
/*!
************************************************************************
*******
* Initialize and clear serial buffer, setup Baudrate
*
* \note
* - Initialize buffers
* - set Baudrate
************************************************************************
******/
void parserInit(uint16_t baud)
{
inBuffer.bytesInBuffer = 0;
outBuffer.bytesInBuffer = 0;
byteToSend = 0;
parserError = P_ERR_NONE;
parserErrorCmdType = CMD_TYPE_REPLY;
cmdComplete = false;
// Baudrate berechnen
//long ubrr_val = ((F_CPU)/(baud*16L)-1);
uint16_t ubrr_val = ((F_CPU)/(baud*16L)-1);
UBRR0H = (unsigned char)(ubrr_val>>8); <-------- UART Register
UBRR0L= (unsigned char)ubrr_val; <--------- Mega169P
/* Enable receiver and transmitter */
UCSR0B = (1<<RXEN0)|(1<<TXEN0);
/* Set frame format: 8data, 2stop bit */
UCSR0C = (_BV(UCSZ00) | _BV(UCSZ01)); // Asynchron 8N1
...
Damit funktioniert dann die Compilation.
Was mich nur wundert ist, warum es bei Euch keine Probleme gegeben hat?
An anderer Stelle allerdings berücksichtigt der Code schon gewisse
Besonderheiten des AVR169P z.B hier:
...
#ifdef AVR_IOM169_H
ISR(USART0_UDRE_vect)
#else
ISR(USART_UDRE_vect)
#endif
...
Gruss Wolf
W.-d. W. wrote:
> vielen Dank für die prompten Reaktionen.> Zu den bei mir gefundenen "Fehlern" etwas genauer (ich verwende AVR> Studio 4.13 SP2 und WinAVR 20071221):
Immer gerne, ich finde es gut wenn es auch jemand außer uns testet.
> Die Fehlerlemendungen beziehen sich auf in serialprotocol.c auf die UART> Register, die zum Mega32 passen, aber nicht zum Mega169P (!!). Ich hab> den Code erstmal so "umgebogen"
Gerade eben geprüft.
Ich habe für den Mega169 kompiliert, nicht für den Mega169p, da heisen
die Register anders. Ich sehe mir das an und baue da mal ifdefs ein.
Wenn ich noch richtig weis gibt es Platinen mit mega169 und mega169p.
Gruss
Juergen
Ich habe das jetzt mal umgebaut und die notwendigen ifdefs eingebaut.
Da sollten noch viel mehr Fehler auftauchen als in der "parserInit()".
Ich konnte das aber noch nicht testen auf einem "Target" da werde ich
erst am Wochenende dazu kommen.
Im Moment ist der Mega169 und der Mega169p unterstützt. Dabei dachte ich
immer die sind identisch und die "P" Variante ist ein Strom spar Typ.
Gruss
Juergen
Hi everyone
I have the same not serial responding version of HR20E
After inserting battery controller sends to Tx (9600 8-N-1):
HR20 SW Version 202 vom 09. Nov. 2005 12:00 HW Version 2
and later for an each 4 minutes:
>D: 2.4.2008 U: 19:31 V: 66 I: 2252 S: 2300
Best regards
Jürgen Sachs wrote:
>> Bei mir unter Linux geht es problemlos.> Nur avr-size beschwert sich über nicht passende Parameter. Das ist aber> durch den Unterschied von winavr zu Linux avr tools gegeben. Da gibt es> einen Trick im Makefile, den ich mal einbauen kann.>>
Hi,
ich hatte hier ( Beitrag "Re: Honeywell Rondostat HR20E per AVR steuern und konfigurie" )
schonmal eine Änderung am Makefile gepostet, die wiederum auf Jens
Müllers Beitrag aufsetzte. Das sollte dann unter Linux und Windows
gehen. Vielleicht kann das ja mal jemand unter Windows testen und dann
in Repoitory aufnehmen?
Ich muss jetzt erstmal mit meinem neuen AVR Butterfly rumspielen und in
den AVR einarbeiten, hoffentlich kann ich dann auch was beitragen.
Hallo,
ich habe mir einen JTAG ICE Nachbau bestellt. Der hat 27,33 EUR gekostet
und kann USB auf 3,3V.
Der Adapter spricht auch:
Setting device parameters for jtag programming .. OK
Entering programming mode.. OK
Reading signature.. 0x1E 0x94 0x05 ..OK
Leaving programming mode .. OK
Nur bei:
Reading fuse bits (low to high).. FAILED!
Beim Setzen der FUSE bits bin ich mir aber unsicher, sieht bei mir ganz
anders aus als bei \hr20\doc\fuses
wir verwenden doch alle die Version 4.13 Build 571
Also bei mir war das Problem eine zu Hohe Geschwindigkeit.
Kannst ja mal schauen ob das Drosseln kannst bei deinem JTAG. Nicht über
1/4 des CPU Takt.
Gruss
Juergen
Hi,
die Lösung:
Hello, Tobias.
Yes - I know about that. But this is not problem of hardware - this is
error in AVR Studio, you can find about this problem in Internet. You
use AVR studio 4.13 SP2, isn't it? Please reinstall AVR Studio to 4.13
SP1 version from CD and all must be ok. Please inform me - this is help
you?
Best regards, Sergey
Vielen Dank an Sergey
Jetzt habe ich auch die gleichen FUSES.
Hi,
http://www.atmel.no/beta_ware/as4/414rc1/releasenotes.txt
Atmel schreib unter Punkt : 6948 , das das Problem mit dem Lesen und
Schreiben der fuses in Version 4.14 RC1 behoben ist. Vielleicht ist das
ganze Bug Fix für unsere Entwickler interessant.
Hallo Entwicklerteam HR20E,
laßt uns bitte nicht im Stich. Wir warten hier draußen sehnsüchtig
auf eine Lösung zur Ansteuerung von HR20E per I2C bzw RS232. Da sich
aber seit einem Monat hier nichts mehr rührt, hoffe ich doch, das es mal
wieder weiter geht. Meldet Euch doch mal, wie der aktuelle Stand
ist.
Mit vielen Grüßen
Detlev
Hab im Moment ziemlich Stress an allen Fronten. Hab das Projekt aber
nicht abgehakt. Muss erst mal wieder Kräfte sammeln, bevor ich mich
wieder dran geben kann. Arbeit gibt es schliesslich noch genug. Freut
mich aber, das ich nicht der Einzige bin, der Interesse am I²C Bus hat.
Kann leider noch nicht sagen, wann ich wieder dazu komme, etwas
beizutragen.
Gruß
Karim
Ja, I2C ist interessant, nur die Kabellängen sind doch nicht so lang
möglich. Oder? Die Steuereinheit wird ja an einem Zentralen Punkt sitzen
und Kabel zu den ganzen HR-20E im Haus gehen (Kabel liegen schon).
Gruß
Jan
Yep, Kabellänge könnte ein Problem werden. Allerdings ist I²C Bus nicht
so sehr schnell und der Master bestimmt den Takt, den man runter
schalten kann. Mit einem speziellen Protokoll kann man eventuell auch
auf einer schlechten Leitung arbeiten (Checksumme mitschicken,
bestätigung von Datenempfang, bei Fehler Daten neu anfordern,
Zeitfenster für Response usw.). Wird sich zeigen.
Also Ansteuerung über RS232 funktioniert schon recht gut.
Es fehlt noch an einigen Details wie die Programmierung der
Schaltzeiten.
Leider hat mich mein Rechner verlassen und ich muss alles neu aufsetzen.
Auch ist es Geschäftlich gerade mehr als Stressig.
Aber auch ich werde weiter machen an dem Projekt.
Meine nächste Idee wäre hier RS485. Das ist einfacher umzusetzen als
RS232. Zudem kann man über den freien Pin PE2 die Datenrichtung für den
RS485 umschalten. Leitungslänge ist kein Problem.
Dann wäre nur eine kleine Platine mit einem RS485 Wandler notwendig, die
man an den 10Pin des HR20E steckt.
Regelung der Heizung benötigt auch nicht viel Tempo bei der Ansteuerung.
Gruss
Juergen
Hallo,
bezüglich I2C noch einige Anmerkungen. Ich habe meine Haussteuerung
vollstänig mit I2C realisiert. Bezüglich der Kabellängen kann ich auf
folgenden Beitrag verweisen:
I2C als Feldbus (I2C mit langen Leitungen)
[[http://www.cc2net.de/Tips/tips.html]]
dort wird von bis zu 50 Meter Leitungslänge berichtet. Die bei mir
realisierten Leitungslängen betragen maximal ca. 15 Meter. Bei cc2net
gibt es übrigens nützliche Bausteine für den I2C z.B. I2C-Bus-Extender,
I2C-Koppler, I2C-Tranceiver usw.
Viele Grüße
Detlev
Hallo zusammen,
ich habe mich nicht durch das ganze Forum gelesen, da doch einiges zu
lesen da ist. Jedoch habe ich erfahren, dass es wohl Probleme gibt/gab
bei unterschiedlichen Versionen von Rondostat.
Mein Anliegen ist folgendes:
Ich möchte den Rondostat ebenfalls mit RS232 ansteuern. Andernfalls
würde ich die Taster und den Drehgeber Simulieren.
Kann man den Speicher über RS232 auslesen und neu beschreiben?
Möchte die Parameter für die Regelung später mit einem Touchscreen
einstellen können (eDip 240-7).
Vielen Dank für eure Hilfe.
@ h.fuchs
Du schriebst:
> ich habe mich nicht durch das ganze Forum gelesen,> da doch einiges zu lesen da ist.
Was erwartest Du nun von uns?
Das wir Dir den Thread vorlesen?
SCNR.
Dario
vielleicht erwartet er deiner Ansicht nach zu viel und möchte doch bitte
im Thread nachlesen. Aber 1.) ist deine Antwort wenig konstruktiv und
2.)wäre es schön, wenn sich Leute - die offensichtlich so
hochqualifiziert sind wie die Teilnehmeer in diesem Forum - einmal
Gedanken über eine interne Suchmaschine machen könnten. Programmierer
wissen sicherlich wovon ich rede. Das wäre allerdings in tausenden von
Foren und anderen hilfreichen Seiten angebracht. War nur n Vorschlag.
Gruß
Lotharaus Hürth
Im Moment ruht das Projekt und ist nicht soweit, dass man den Rondostat
mit der neuen SW verwenden kann.
Tastatur und Drehgeber kann Fuchs zwar simulieren wenn er will aber das
ist Murks hoch 10. Viel spass dabei.
Hab noch ein technisches Problem mit meinem neuen Notebook und immer
noch keinen Programmer. So bald beides verfügbar ist, werde ich mich
wieder an das Projekt geben. Kann aber noch einen Monat dauern. Optimal
wäre es, wenn es bis zu den Ferien hinhaut. Denke mal, dass wir aber
dieses Jahr noch eine verwendbare Release hinbekommen werden (hoffe es
zumindest).
Der Thread ist zu lange und da hier jeder Posten kann, ist viel dabei,
dass besser gelöscht gehört. Vielleicht sollte man einen neuen Thread
aufmachen.
Gruß
Karim
Karim L. wrote:
>> Tastatur und Drehgeber kann Fuchs zwar simulieren wenn er will aber das> ist Murks hoch 10. Viel spass dabei.
Hatte ich auch erst überlegt, aber hat einfach zu viele Nachteile. Der
Größte: keine Rückmeldung!
>> Der Thread ist zu lange und da hier jeder Posten kann, ist viel dabei,> dass besser gelöscht gehört. Vielleicht sollte man einen neuen Thread> aufmachen.>
Dadurch gehen aber viele Infos flöten die sich immer dazwischen befinden
und es gibt bestimmt schon sehr viele die hier nach dem Fortschritt
schauen. Ein neuer Thread ist auch nicht vor "vielen" Posten geschützt.
Wenn man nun aber auf einen geschützten Bereich wechseln würde, gebe es
keine neue Unterstützung und passive Zuschauer mehr.
Hallo,
ich würde als nächstes gerne 485 Implementieren, die rs232 geht schon
recht gut.
485 daher, da Protokoll usw gleich bleiben kann und nur ein weiterer Pin
notwendig ist. Das Protokoll wäre dann aber, zumindest im ersten
Schritt, Master Slave, die einzelnen HR20 werden also gepollt, jedoch
Intelligent.
Master -> Slave : Hast Du was neues ?
Slave -> Master : Antwortet mit Neuigkeit oder "NONE"
Master -> Slave : frägt solange bis None zurück kommt und dann den
nächsten. Das natürlich "gemächlich", wir wollen ja Strom sparen :-)
Würde man den RS485 4 Adrig ausführen, könnte man die
Spannungsversorgung mitführen, also +12V (oder weniger), A, B, GND.
Die Umschaltung RS485 auf RS232 erfolgt zum einen Automatisch über die
Erkennung der externen Platine und optional über einen neuen Befehl.
Die Erkennung der Externen Platine würde über einen Widerstand an der
"PE2" Leitung am 10 Pin erfolgen. Dieser "R" sorgt auch dafür das ohne
angeschlossenen HR20 der Treiber auf Empfang steht.
Auf der Platine wäre dann:
- RS485 Wandler
- Spannungsaufbereitung 12V auf 3V für HR20E
- "R" für Erkennung
Würde also sehr kompakt möglich sein.
Wäre das so OK ?
Zu I2C. Bei I2C sollte man das Protokoll ganz anders aufbauen. Generell
müssten dort alle Daten "I2C" Typisch als Byte Array verfügbar sein und
jeweils einer bestimmten Funktion zugeordnet sein. Byte 1 Also MAX Temp,
Byte 2 MIN Temp usw. Der I2C Master entscheidet wie viel Bytes er liest
und demnach welche Werte er bekommt.
I2C wird eher nicht wie eine RS232 zum Transport eines richtigen ASCII
Protokolls benutzt.
Zum Temperatur Preset für die Wochentage sollte man sich überlegen was
man alles Möchte. Ich vermute 4 Schaltzeiten pro Wochentag sind mehr als
genug. Wenn man mehr will kann man ja vom Zentralen Controller über den
Bus eine Virtuelle Einstellung über z.B. Preset 0 vornehmen und damit
unbegrenzte Schaltzeiten fahren. Der Controller muss dann eben jede neue
Schaltzeit laden.
Gruss
Juergen
Wenn die Platine in eine Unterputzdose passt wäre dass sehr hilfreich.
Zu den Schaltzeiten: Es ist richtig das der externe Controller das
übernehmen kann, ist bei mir ja auch so geplant. Aber einige wollen den
HR-20 noch allein laufen lassen, was bei mir nur bei
Haussteuerungsausfall gedacht ist.
Die Platine würde eher direkt an dem HR20E sitzen, eben an dessen 10
Poliger Schnittstelle. Zumindest die erste Version. Was auch Sinn macht,
sonst muss man ja RX, TX, GND, Batt und PE2 zur Platine führen.
In eine UP-Dose passt Sie in jedem Fall.
Jetzt frei gedacht würde unten aus der Platine ein 10 Polige Buchse
ragen die in den HR20E gesteckt wird. Auf der Oberseite wäre dann eine 4
Polige Schraubverbindung für den RS485 Bus und die Bauteile. Ist der
HR20E so montiert das die Platine Richtung Wand Zeigt wäre Sie nicht zu
erkennen.
Es wäre eine Überlegung wert hier RJ11 oder RJ45 Stecker zu nehmen.
Allerdings braucht man dann zwei Buchsen auf der Platine um
durchschleifen zu können. Netzwerkkabel wären ideal für RS485, da
verdrillt und abgeschirmt und überall billig zu haben.
Der HR20E braucht bei einer Versorgung über den Bus natürlich keine
Batterien mehr.
Und Ja, der Zentrale Controller kann die Kontrolle übernehmen.
Wobei ich dazu tendieren würde, einen "Preset 0" zu schaffen, der nur
Temporär gültig und auch nicht ins EEPROM geschrieben wird. Wird dieser
aktiviert, regelt der HR20E nur noch nach dieser Einstellung. Wird
dieser deaktiviert, läuft alles nach den gespeicherten Presets.
Eine direkte Ansteuerung des Ventils halte ich nicht für Sinnvoll. Fällt
der Bus oder die Zentrale aus, kann es ganz schön Warm werden :-) Wird
nur die Solltemperatur vorgegeben, kann nichts passieren.
Ein Preset besteht hierbei aus Solltemperatur, der Startzeit sowie dem
zugehörigen Wochentag.
Die Endezeit wird ja durch die nächste Startzeit bestimmt.
Für die eigentlich Regelung brauchen wir ja nur die Solltemperatur, der
Rest ist schnick schnack ;-)
Abhängig von der Differenz Soll und Ist Temperatur wird dann das Ventil
angesteuert.
Gruss
Juergen
Ich hatte mir das so gedacht das es ein Kabel mit dem Pfostenstecker für
den HR-20 auf der einen Seite und ein RJ45 Stecker auf der anderen Seite
wird. In der Wand sitzt dann einfach eine Rj45 Dose und dahinter die
Platine. Von dort dann durch die Wand das Kabel zum zentralen Controller
(die Kabel liegen bei mir schon und sind IY (St) 6x2x0.6 Telefonkabel).
Der Controller soll dann immer nur die Soll-Temp vorgeben und der HR-20
regelt selbst, was dann auch die von Die beschriebene Ausfallsicherheit
bietet (gerade ja bei Selbstbauprojekten ;-))
Das Ganze ist ja auch mit der alten Version des HR-20 möglich, nur
leider bei der neueren nicht mehr was mir halt sorgen macht, da ich
leider bei der Umprogrammierung nicht mithelfen kann (und hier ist es so
ruhig geworden).
Gruß
Jan
Das Kabel sollte Ok sein.
Theoretisch sollte es kein Problem sein ob die Platine am HR20 sitzt
oder in der Dose. ABER: Der HR20E arbeitet nur mit 3V. Lange
Kabelstrecken sind mit dem Pegel nicht drin. Auch die Stromversorgung
wird schwieriger. Immer an die Störeinstrahlung denken.
Daher werde ich die Platine am HR20 befestigen und von dort auf mein
bestehende Verkabelung gehen (alles CAT5e).
Einzig die Optik ist nicht so schön wenn die Platine am HR20 hängt. Ein
Kabel geht so oder so zum HR20.
Mal sehen was ich da über die nächsten Wochen machen kann.
Gruss
Juergen
Kabelstrecke: Dosen immer max 30cm vom HR-20 entfernt.
Kabel von Dose zum Zentralen-Controller: bis 30m Cat3 - halt
Telefonkabel.
Wo ist denn der aktive Rest von hier geblieben?
Das Projekt ist noch nicht für den Produktiveinsatz geeignet.
Es gibt nur Grundroutinen, die Temperaturregelung und Zeitsteuerung
fehlen noch ganz.
Ich bin aber guter Dinge das es eine Alpha Version zu den kalten Tagen
geben wird.
Meine Kollegen haben hier ja schon gut vorgelegt.
Gruss
Juergen
Hallo an alle frimelfans!
meiner einer hatte seit 3 Jahren ne ZeitschaltUhr -verbunden mit einem
Heimeier stellschalter sag ich mal(funtioniert mit ne ausdehnugnskissen
bei 230 Volt)
meine Idee war noch nene temperaturfühler zu integriere, aber , das teil
macht einfach zu viel lärm, weil es das Ventil in ruckartigen stößen
bewegt, also besser nicht kaufen( macht kanck-knack knack, im
sekundentackt)
Erinnerte mich immer um 22:00 Uhr, das es Zeit wird schlafen zu gehen
:-)
so nun bin ich auch an dem HR20E dran, scheint lautlos zu sein,
zumindest leiser, wie der Wassserfluss durch die Heizung.
Uhrsrünglich wollte ich einfach das Bedinteil per Kabel verlängern, weil
ich nicht unter dem Flipper zur Heizung kriechen will um es mir wärmer
zu machen. aber die Idee, es per PC zu steuern, der eh immer an ist,
gefällt mir(in jedem fall zusätzlich), das bedienteil kommt ans Sofa,
das steht fest.
Der anfang des Threads klang gut und einfach, aber nun Version 2.04?
Keine einfache möglichkeit, wie von:
http://kulknet.homeip.net/Steffen/Softwareprojekte/RondoSet/RondoSet.htm
na einfach war es für ihn nicht, aber es hat geklappt.
Also nehm doch bitte wieder den roten Faden auf.
Mein wunsch wäre: Rondostat --> USB --> Sorftware einstellen ,
Temperatur in der taskleiste anzeigen.
((Hotbutton, damit sich die weiblichen besucher ausziehen, weils so warm
wird ::--))
mein Betrag wäre testen/hr20e zerstören zur not, und mit viel geduld
auch was mit Visual C++
Hallo zusammen,
ich habe zwar schon einige Erfahrung mit AVRs aber noch nicht im
Zusammenhang mit JTAG, deshalb eine Frage. Verstehe ich das Richtig,
dass durch die Einstellung der Fuses im Originalzustand der Weg zu einer
eigenen Firmware eine Einbahnstraße ist? Oder gibt es eine Möglichkeit
die originale Firmware über das JTAG Interface auszulesen und bei
Problemen zurück zu spielen?
In der PDF-Doku habe ich außerdem gelesen: "Um das Verhalten der
Spannung in Abhängigkeit der Temperatur zu messen, wurde die Funktion
der Originalsoftware genutzt, welche die Ist-Temperatur kontinuierlich
auf dem Display anzeigt." Wie bringe ich die Firmware dazu die
Ist-Temperatur anzuzeigen? Ich habe gefunden wie das mit der alten
Version geht, aber zu der 2.04 um die es hier geht finde ich das leider
nicht.
Danke schonmal
Sebastian.
Hallo,
ich versuche gerade, einen hr20e mit einem Atmega16 anzusteuern, komme
aber nicht weiter.
Zwar empfange ich beim Einschalten die Versionsmeldung des HR20e, aber
mehr klappte bisher nicht.
Sende ich einen Lese- oder Schreibbefehl, erhalte ich "not implemented"
zurück.
Den Atmega versorge ich über die Stiftleiste am Thermostat. RX und TX
habe ich direkt verbunden, ohne Widerstände, PullDowns usw.
Der Atmega hat einen externen 4Mhz Oszillator.
Im Anhang mal das Code-Schnipsel (Avr-gcc), das die "Adresse" 136 lesen
soll.
Ergebnis ist "not implemented". Bei Befehlen erhalte ich auch nur "V02"
zurück anstelle von z.B. "M1231234".
Die Pausen zwischen den chars musste ich einbauen, ansonsten kommt
überhaupt keine Rückmeldung vom hr20.
Die LCD-Ausgabe im Interrupt ist natürlich Murks, aber zum Testen tut
es.
Vielleicht hat jemand einen Tip?
Gruß,
Freisi
Hello,
Due to problem with https://OpenSVN.csie.org/hr20 repository we have
another source repository on https://sourceforge.net/projects/openhr20/
Current status on project:
- it is able use it as controler for fixed temperature
- complete new light serial protocol (incomplete, but possible to use)
- timers is not implemented (I am working on it)
- LCD menu+keys is working, but without timer programing, service menu
allow setup internal parameters (hold all fronend buttons)
What you can to do?
1) test it, or try to tune PID controler
P constant is at configuration position 05
I constant is at configuration position 06
D constant is at configuration position 07
scale for constants is at configuration position 08
2) improve Doxygen documentation
3) any sugestion is welcome. If you wan't make some changes at code,
please inform me. I would like prefer to do not make conflicts in code.
Asks:
Karim L.: Can I use
http://img407.imageshack.us/img407/3056/burgtwisterplatinest3.jpg in
project documentation
jdobry wrote:
> Due to problem with https://OpenSVN.csie.org/hr20 repository we have> another source repository on https://sourceforge.net/projects/openhr20/
I am not aware of any problems...
I can still use the old repo.
Also some revision are missing in the new one. this is no good. We
should not use two repos to gain the same project...
I would prefer to continue with sourceforge, but first import ALL
revisions from the old one.
According to the wiki we are still using the opensvn.csie.org.
Maybe some other developers could clear up things.
Juergen
@jdobry,
you may use the Image for documentation.
For this kind of regulator as far as I analysed it, you can forget about
the D component and also the I component will not yield much
improvements. The original SW seems to use P regulator with some non
linear adjustments which has only slight effects. You will get quiet
good results with a simple P regulator. Unfortunately I have still no
time to continue the work although I still want it.
The old repository is still working fine and I would prefer to continue
using it.
Für die Anderen. Soweit ich das untersucht hatte, wirkt bei der Original
SW überwiegend ein P Regler mit ein paar nicht linearen Eingriffen, die
man aber auch weg lassen kann. Genauen Zusammenhang konnte ich noch
nicht ermitteln, die Abweichung vom P Regler ist aber gering. Wegen der
Trägheit des Systems reicht der P Regler aus.
Hab leider noch keine Zeit weiter am Projekt zu werkeln.
Gruß
Karim
I have this problems with https://OpenSVN.csie.org/hr20 :
1) slow communication 0-5kB/s (I have 5mbit/s connection)
2) too many lost communications. Example: when I try to create branch, I
must do it around 2 hours. Each try take around 1-2 minute and
communication was usualy lost.
If you wan't to use my sources, it is also under GPL. It is completly
rewriteln, because old code from https://OpenSVN.csie.org/hr20 is too
buggy.
For example you can't use shared variables between interupts and main
code without locks. "volatile" keyword is not sufficient and have
different meaning. Temperature measurement for <5C is wrong. Battery
measure is wrong. Impulse counter from motor is wrong (real impulses is
aroud 737-740 and you measure 820-900) Code is too big, you will not
able add all of this parts (writeln with same style): keyboard, LCD
menu, configuration storage, wireless communication.
PS: you are right that "new" repository don't have all revisions. But
current code use very small part of old code. Compare it. For example,
communication is completly new.
I am able to realease beta version with more possibilities than original
2.04SW this or next week. But you can still use
https://OpenSVN.csie.org/hr20
@ Karim L.: thanks for picture, I will use it.
PS: Old code have problem with current throw pullups. It dramaticaly
reduce battery life. You must disable it temporary (1 wire from wheel
and 1 wire from "mont" contact).
Hello jdobry,
seems you have done a nice work. In my opinion the code was consuming to
much memory too. To the other points I can't say much, because I was not
involved.
But I think you found at least a good starting point of this orphan work
made mostly by Dario here. In case you want to take the scepter of the
project, I would please you to do a good documentation, so that every
body can reproduce the thoughts of the implementation and is able to
build the project by himself.
You might also publish work left to do or which is just in progress to
prevent double work or get support.
Best Regards,
Karim
Hallo Leute,
ich habe den Thread teilweise durchgelesen. Mich wundert, dass niemand
spezifisch auf den Regelalgorithmus eingeht. Ich habe hier im Wohnzimmer
den Funkthermostat von ELV. Leider sind die Eigenschaften des
implementierten Reglers eher ungünstig. Der Temperaturverlauf zeigt
zumindest bei uns ein starkes Überschwingen, wenn der Raum aufgeheizt
wird. Hier wäre eigentlich ein selbstoptimierender Algorithmus
notwendig, oder wenigstens die Möglichkeit, Regelparameter anzupassen.
Aber bei derart unterschiedlichen Konstellationen aus Anordnung von
Thermostat und Heizung, Raumgrößen, Wärmeverlusten, Heizleistung, Größe
der Heizkörper etc. gibt es halt keine optimale Variante.
ciao
Marcus
To Karim L: "double work" is nightmare of many projects.
This was main reason why I was post message to this thread about SVN on
SF.net (also created by Dario C.)
Current status is that I have many parts "in process". I have controler
part on my PC, but not tested and I am writing LCD menu for timer
programing.
I hope that reconstruction with basic functionality like original SW
this week. I will inform you about possible tasks.
But at this moment you can:
- add some "watched variables" into watch.c - nice for debug
- tune my PID setting in real situations, it may be completly wrong
- review my code. I am sure, that it contain bugs. I wrote it very
quickly and it need review. I can do it, but comebody other have another
point of view and it is better.
- setting and functionality for "auto lock" after timeout feature.
setting is 0=disable function, 1-255 is timeout to auto lock I have
small dauthers :-)
Later (please wait for my check in)
- menu.c is not optimized and it is not follow coding standard. May need
small rework.
Differences from original SW:
- 8 point of setting per day (original 4)
- 4 temperatures (original 2)
- service menu is another from original. For my code it is long press
all buttons. Original need press "PROG" button and switch on.
@Marcus,
wenn der Heizkörper zu groß ist bzw. eine zu hohe Wärmespeicherkapazität
hat, kann es zu einem überschwingen kommen. Mit einem klassischen Regler
bekommt man das Kaum in den Griff. Eher müsste man die Sprungantwort
ermitteln entlang der man das Ventil steuert in Kombination mit einem P
Regler, der kleinere Differenzen ausregelt.
@jdobry,
I can try to review your code and add smaller parts of code. But as I
said, I will currently have not the necessary time for a full support.
But others here may provide help as well.
For an adaptive valve control, it is required to have different hardware
valves or at least knowledge about existing differences on the market,
which I don't have. Some hints from heating engineers would be helpful
as well. But we can try to search for the required infos before
implementing an algorithm.
Hello,
For new valve calibration I need some data from more valves. If you want
to use OpenHR20 SW later, please send me data from your valve. For test
you need ttps://sourceforge.net/projects/openhr20/ SW !!revision 55 !!
After reset motor try to found calibration and send some data to serial.
I need this data and type of your valve. Please send me log (jdobry at
centrum dot cz).
This is example from my valve in graph. Blue is open, red is close. Y
scale is time between motor pulses.
http://img261.imageshack.us/my.php?image=valve1sg5.png
Jiri
Hi Jiri,
I have logged the output from four (three different)
valves with revision 55.
The results are stored here: http://datundwat.de/HR20-Valve.zip
The following files contain the serial-output:
HR20_Bad.log
HR20_Buero.log
HR20_Wohnzimmer_1.log
HR20_Wohnzimmer_2.log
I took some pictures of the valves:
Bad.jpg
Buero.jpg
Wohnzimmer.jpg (I have two of them)
Each logfile contains the output of more calibrations,
each started with a manual reset.
Dario.
Thanks to DarioC and ThomasG I have real mesure from few valves.
Values is different from my valve values.
Result is, that noise protection for "motor eye" must be improved. It is
not sufficiend near to close position
Situation near to open
________|--|___________________|--|___________________|--|______________
_____|--|___________________|--|
Situation near to close
________|--------------------------------|______________________________
_______________________
Current SW protection have fixed value and catch noise on this
edge"---|___"
It must be improved to dynamic change depend to cycle length. I will
prepare it for next revision.
I thing that SW will be prepare for 1.0BETA release very soon. Byt I
have big problem to find any time for user documentation (I am litle bit
overloaded on my job and I don't have motivation)
Therefore what you can to do:
- write Doxygen comments for generate user documentatio to
--- eeprom values numbering and setting
--- watched values numbering and meaning
--- communication protocol
--- user manual for menu&setting
--- user manual for automatic and manual valve calibration (manual cal:
unmount HR20 from valve, close valve manualy to close positon not to
hard end, pres&hold "C" button and remount HR20 to valve, It is similar
like HR40 manual calibration. Return to auto is similar but press&hold
"PROG" button
Some information about revision 72 at
https://sourceforge.net/projects/openhr20/
- eeprom contend is NOT compatible with previous version
- new method to detect motor range
- new method to calculate motor eye noise protection value
-> result? I need new calibration logs from your valves. It works
perfectly for me. I hope that detection of "close" position is much
better than before.
Latest TODO list is here:
http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/source/TODO.txt?view
TODO list looks long, but it not contain any critilcal task or relative
bigger task.
I realy want somebody who will write user documentation in doxygen.
Reason for doxygen usage is simple, documentaion on external file is
usualy obsolete.
I realy need review of code. Some parts I code very quickly without self
review.
Remark to SW Revison72:
Values for motor eye tunning is not final. It is just first idea.
/* 0e */ uint8_t motor_end_detect; //!< stop timer threshold in % to
previous average
/* 0f */ uint8_t motor_eye_noise_protect; //!< motor eye noise
protection in % of previous average
Commands:
G0e<enter> read 0e value
S0exx<enter> write xx(hexa) as value
Default value for:
0e - 150% of eye cycle
0f - 40% of eye cycle
(0e) value means that motor is stopped when time exceed 150% of previous
cycle average
(0f) is value in % of cycle where is eye not used. It is mask for
problematic area.
Revision 75 is little bit experimental
- experimental approximation of human temperature feeling
(add valve position to real temperature, humans feel warm heating and
we can use smaller real temperature)
- experimental change of PID constants (stability test)
For this moment this is setting with best results for this moment. It is
not fare from original SW:
S0532<enter> (default in EEPROM)
S0602<enter>
S0719<enter>
S0864<enter> (default in EEPROM)
But it is not exactly what I wan't. Better can be some form of fuzzy
logic. Do you have some material for this problem someone? I have only
teoritical experience from university, but it is too fare for me.
Hi all,
We can test rev 86.
Major change is non-linear PID controller
It is much better for reduce motor actions and save batteries. I hope
that it is better than original SW for my room and valve.
Motor position for constant temperature
http://img92.imageshack.us/img92/9367/motorzn7.png
X scale is minute/4
results from rev86 can be improved but we need some changes at "I" part
of PID controler limits (I will prepare it for next revision)
remark: rev 87 is identical to Rev 86, changes is only in TODO list and
change log
Dank der unermüdlichen Arbeit von Jiri
haben wir nun einen Stand erreicht, wo der Open-HR20 mehr kann
als der originale HR20.
Ich selber habe schon fünf HR20 mit der neuen Software im Einsatz
und konnte noch keine Probleme Feststellen.
Jetzt brauchen wir
- Tester, Tester, Tester, Tester, Tester.
- eine PC-Software umd mit dem HR20 zu kommunizieren,
die Schnittstelle ist ja jetzt bekannt und man kann
viel einstellen.
-----
Thanks to Jiri
we know have a software which can do all the things the original HR20
can do.
Now we need:
- Tests, Tests, Tests, Tests, Tests
- PC-Software to control the OpenHR20
DArio
new revision 90
- updated motor.c
- add verbose output for temperature
If you want to help me with window open functionality please change in
debug.h this line
#define DEBUG_PRINT_MEASURE 0
to this
#define DEBUG_PRINT_MEASURE 0
and send me log including window open.
Revision 91 is small bugfix for rev90
Here:
http://img253.imageshack.us/img253/302/motor2fv0.png
you can see results from Rev91 in graph
X scale in minutes
blue - wanted temperature (20.5)
red - measured tempetature
yellow - valve position
It is simply best what I ever see including original SW
PS: if you can send me log in window open and close condition in your
environment it will be helpfull. Please enable bebug (see my last post)
Hallo,
Habe gerade 8 Stück von Conrad bekommen, Version 2.04 - Sonderangebot!!!
Ich hab gerade das Pollin Evalboard gebaut und werde am Wochenende den
ersten Regler damit umprogrammieren.
Hi Jiri,
I have downloaded and compiled the project, which worked well. Recently
I purchased a JTAGICE MKII and I am trying to get it connected to the
HR20.
I am still busy with other stuff but I think I can spend now several
hours to the project to add help where required. I would like to write a
windows program for remote setting the HR20, which can be extended to
pick up loggings or download new SW.
Also very important is a clear easy to understand description how to get
started (where to get the tools and SW, how to install and configure,
how to connect, how to remote control...). It will increase the number
of users for testing and may be adding features. Thats what I would like
to do first as soon as I get my HR20 flashed.
On the first sight of the code you have done a good job. Many thanks for
the effort you spent.
Since I have no experience with flashing Atmel controllers it would be
nice to get brief hints for the required settings concerning clock rate
(4MHz?), fuse bits, lock bits and other required settings.
Best regards,
Karim
Dr. G. Reed wrote:
> Kann man mit AVR Studio und einem STK500 den HR20 programmieren ?
In dem gekauften Zustand, kann man den HR20 nur über JTAG programmieren,
dazu braucht man einen AVR JTAG oder einen Clone davon, zum Beispiel von
Olimex.
Wenn man aber die Mühe nicht scheut, kann man sich die Leitungen für den
ISP anlöten. Dazu muss man ein paar Käbelchen (MOSI, MISO, SCK, RST, VCC
und GND) anlöten und mit dem ISP Programmer verbinden, dabei beachten,
dass die Leitungen alle 3V Pegel haben und nicht 5V.
Denkbar wäre es auch mit dem JTAG einmalig einen Bootloader zu
programmieren und von da an die neue SW über die serielle Schnittstelle
einzuspielen, dazu reicht dann ein normales Handy-Kabel auf PL2303
Basis. Nachteil ist, dass der Bootloader etwas Speicher verbraucht und
das die maximale Größe des Programms dann um diesen Betrag kleiner wird.
Einen Bootloader hatte ich mal programmiert und der sollte eigentlich
auf dem HR20 laufen, oder eben den JTAG von Olimex, der kostet nicht
viel und kann 3V.
http://www.olimex.com/dev/avr-jtag.htmlhttp://www.olimex.com/dev/avr-usb-jtag.html
Dario
Karim L. wrote:
> Since I have no experience with flashing Atmel controllers it would be> nice to get
brief hints for the required settings concerning clock rate
> (4MHz?), fuse bits, lock bits and other required settings.
Connect the JTAG with the folowing Pins:
1 /Reset Reset
3 TMS JTAG
4 TCK JTAG
5 TDO JTAG
8 TDI JTAG
9 + Batt Batterie
10 GND
Then connect 3V to the HR20 (and the JTAG) and start AVR Studio.
You can select ATMEGA169P ans you use default values for Clock, etc.
Press "READ SIGNATURE" and it should display the Signature of the ATMEGA
and the text: "The signature matches the selected device"
Then you can:
- ersae the Flash
- Change Fuses
- EESAVE to disabled
- BOOTSZ to 512 Words
- CKDIV8 to 0
- New Fuses should be:
- Extended: 0xFD
- High: 0x9B
- Low: 0xE2
- program Flash
- program EEPROM
- Have fun!
Dario
Vierauge wrote:
> Habe gerade 8 Stück von Conrad bekommen, Version 2.04 - Sonderangebot!!!
Wie teuer waren die?
> Ich hab gerade das Pollin Evalboard gebaut und werde am Wochenende den> ersten Regler damit umprogrammieren.
Das glaube ich nicht Tim.
Programmieren kannst Du sie eigentlich problemlos nur über JTAG, ich
glaube nicht, dass Du es ohne weiteres mit dem Pollin Board schaffst.
Lies einfach meine anderen Antworten von heute.
Dario
Hallo Dario,
hab eben den JTAGICE MKII angeschlossen, der wird auch erkannt aber das
AVR Studio beschwert sich darüber, dass die Versorgungsspannung vom
Target zu niedrig wäre (1,338V). Habs aber gemessen und die liegt bei
2,8V. Ist Dir da was bekannt?
Kann es sein, dass man sich um die Fuse und Lockbits usw. nicht zu
kümmern braucht, weil die Einstellungen über JTAG ausgelesen und
zunächst als Default übernommen werden?
Gruß
Karim
Für die Linux/BSDler:
ich habe gerade meine ersten Rondostat erfolgreich programmiert:
AVRDragon am usb-Port, avrdude mit libusb-Support und ein JTAG-Kabel
wie von Tobias Koch am 8.4.2008 oben beschrieben. Folgendes Kommando
habe ich benutzt:
avrdude -p m169 -c dragon_jtag -P usb -e -U flash:w:hr20.hex \
-U eeprom:w:hr20.eep -U efuse:w:0xfd:m -U hfuse:w:0x9b:m -U
lfuse:w:0xe2:m
Musste vorher einmal dasselbe Kommando ohne eeprom-Update durchlaufen
lassen, die Fuses müssen dafür wohl zuerst korrekt sein.
Himtronics
Karim L. wrote:
> warst gerade schneller.
Was für ein Zufall, hast Du auch nebenbei Football geguckt?
Ich habe das Thanksgiving-Game geguckt und das war so langweilig,
dass ich nebenbei auf dem Sofa mal ein paar Anfragen bearbeitet habe.
> Problem mit der Spannung weg ist. Ne Idee?
Woher hast Du den Strom. Ich habe das Problem, dass es mit Batteriern
nicht immer geht. Da bricht die Spannung wohl auch mal recht stark
zusammen. Derzeit habe ich folgende Schaltung:
USB - PL2303 Handykabel - HR20
USB - USB/RS232-Kabel - JTAG - HR20
Am HR20 dann:
HR20 || JTAG || PL2303
-----+--------++-----+--------++--------
1 | /Reset || 6 | /Reset ||
3 | TMS || 5 | TMS ||
4 | TCK || 1 | TCK ||
5 | TDO || 3 | TDO ||
6 | TxD || | || TxD
7 | RxD || | || RxD
8 | TDI || 9 | TDI ||
9 | +Batt || 4+7 | VCC || 3V
10 | GND || 2+10| GND || GND
Beide Kabel stecken im USB desselben Computers.
So kann ich Programmieren und die serielle Ausgabe beobachten
ohne umzustöpseln und Batterieen brauche ich auch nicht.
Wie machst Du es?
Dario
Leute meint ihr nicht das es gegenüber Jirji (jdobry) fair wäre wenn ihr
die Diskussionen hier besser in Englisch statt in Deutsch führt?
Er investiert viel Zeit in das Projekt und versteht dann nicht was ihr
hier schreibt.
Please use english instead of german. I think it is good when jirji can
read what you wrote.
Artax
Hallo Dario,
danke für die Antwort. Fußball habe ich keines geschaut, war Zufall. Bei
mir ist die Glotze meistens aus.
Hab einen JTAGICE MKII Clone. Da war ein Kabelsatz dabei, zum
"fliegenden" Verdrahten. In der Doku zum JTAG stand dass Masse auf Pin 2
und 10 liegt. Nach Merphy habe ich 2 gewählt. Deswegen ging es nicht. Es
muss Pin 10 sein, eventuell muss man Pin 2 mit an Masse hängen.
Hab jetzt aber noch eine Frage. Gehe ich recht in der Annahme, dass in
der Datei hr.epp die EEPROM Daten sind und im hr.hex die Flash Daten
stecken die zu brennen sind?
Ist der Bootloader für späteres Flashen über die V24 schon mit drin?
Gruß
Karim
Artax wrote:
> Please use english instead of german. I think it is good when jirji can> read what you wrote.
Sure, but if i answer to topics that are not souce related, like setting
up an enviroment and programming the HR20 with a JTAG this is no issue
for Jiri.
He knows how to compile and programm. I think answering questions in
German to german useres, which are not Source-Code related is OK.
Dario.
By the Way, I found an Error:
Revision:
93
Error:
when setting date and time (after reset od with longpress of AUTO)
it is possible to set an invalid date e.g.: 31th november
Dario.
Hallo Dario,
hab das Teil jetzt geflasht bekommen. Die Revion im config.h File habe
ich noch auf 0.93 erhöht, sonst sieht man am Gerät beim Einschalten
nicht die aktuelle Revision.
Die Idee mit dem PL2303 Kabel finde ich gut, die gibt es für 3,5 EUR bei
ebay. Hab aber keines gefunden, das mit Vista zusammenspielt. Da muss
man drauf aufpassen.
Gruß
Karim
Hallo Dario & Juri,
the day setting (limiting to the maximum days in the month) fails,
because in function RTC_DaysOfMonth() (Modul rtc.c) a wrong index is
used to get the day of month out of the table. -1 must be added to the
index.
uint8_t dom = pgm_read_byte(&RTC_DayOfMonthTablePrgMem[RTC_MM-1]);
Karim
Logfile for Open Window.
Here is my logfile with temp values while windows was opened.
I entered V<CR> three times before opening the Window.
Outside Temp was about 2°C, room temp about 21°C.
HR20.log: 565
1
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
2
T: 2094
3
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
4
T: 2094
5
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
The temperatur falled to 14,7°C.
Before closing the windown I entered V<CR> two times.
HR20.log: 2395
1
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
2
T: 1477
3
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
The temperature started to climb to 19,4°C, but the HR20 showed
"OPEN" and the Valve was closed.
Then i pressed AUTO two times at 18:21 and the HR10 resumed
to heat to 21°C
HR20.log: 9179
Dario: thanks for window open log.
Dario & Karim: thanks for bug report & bugfix
------------------
For next revision I have update for PID controller. Problem is delivery
delay from valve action to real temperature change.
PID controlers can use in this situation "Smith predictor" but in this
case we need verry accurate model of this predictor. Otherwise it make
controler unstable. I worry, that we are not abble to create generic
model for it. We are using too many different valves in too many
different rooms.
But I hope, that I found I found work arround. It works for me, but it
take some hours to test in in real conditions.
Jiri
Revision 94 contains improved PI controller.
Test it. You you can send me log, it would be nice.
It's works perfectly for me, but I can't test all conditions.
Jiri
PS: window open detection is still without change. Open detection is
correct, close detection not work.
Hello window close detection can be problem.
From measures, we can found increase of temperature is only
0.13 to 0.20 degree / minute
temperature resolution is only aprox 0.07 degree
current method (compare current temperature and 1 minute old
temperature) can works, but we must change one eeprom constant
"S1c12<enter>" for 0.18 degree/minute window open/close detection
But I worry that we will have too many false positives.
We can:
1) test it with "S0112<enter>" settings
2) found better method (I have not any idea at this moment)
Any idea?
Revision 95 is try to improve window detect.
WARNING: EEPROM contend and layout is changed. Previous numbers of Sxxxx
is obsolete.
significant config is:
G1d / S1dxx : window_thld = treshold for window open/close detection
unit is 0.1C
G1e / S1exx : window_noise_filter, number how many times must be 1
minute difference over window_thld
It is not tested fully. We will see.
Jiri
Revision 96 improve window close detection
G1d / S1dxx : window_open_thld = treshold for window open/close
detection
unit is 0.1C
G1e / S1exx : window_open_noise_filter, number how many times must be 1
minute difference over window_open_thld
G1f / S1fxx : window_close_noise_filter, number how many times must be
teperature > (temperature at t-1min). Condition teperature ==
(temperature at t-1min) not interrupt this counter, but not increase it
Test it,
Jiri
default window_open_thld configuration is too small and have false
positives.
Change value to 32 with this command or change "1d" configuration in
service menu.
S1d20<enter>
Jiri
Hallo,
mal ein DAU-Feedback zur OpenHR20-Firmware von
openhr20.svn.sourceforge.net:
Ich habe gerade erfolgreich die Version 0xF083 kompiliert und
eingespielt.
Entgegen der Aussage hier im Forum habe ich es aber nicht ueber SPI
einspielen koennen (MISO,MOSI,SCK sind ja an kleinen Vias recht gut mit
Lackdraht anzuloeten), aber der Upload ist mir nicht gelungen.
Hab ich was falsch gemacht oder ist SPI-Reprogramming disabled?
Der Upload hat dann doch mit dem JTAGICE mkII gefunzt.
Erste Frage: ist grundsaetzlich die Menuefuehrung aehnlich der
Orginalfirmware?
Nach rumprobieren wuerde ich sagen: ja, bis auf folgende Unterschiede:
Der Mittlere Button zeigt kurz IstTemp / Valve% / Zeit an, richtig?
Im Prog_Modus kann man zwischen 4 Temperaturen waehlen
(Mond,Sonne,Sonne+Mond,Schneestern = Eco/SuperCOmfy/Comfy/Frostschutz),
richtig?
Gibt es sonst noch Unterschiede, was verstellt und angezeigt werden
kann?
Wenn ja, ist das irgendwo dokumentiert bisher? Tweaks wuerden mich auch
interessieren.
In der Anfangs-MoorCalib-Phase lustige Ausgaben aufs Display geschrieben
("Ad 3" glaub ich) werden - was bedeutet das? Gibts sonstige Meldungen
auch, und was heissen sie?
Ausserdem hab ich entdeckt, dass schon jemand ein RFM-FunkModul auf die
Platine geloetet hat und sogar ein Schematic dazu. Gibts dazu auch
irgendwo auch Code und oder sonstige Doku? Das RFM-Interface wuerde ich
schon fuer eine absolute KillerApplication halten ;)
Ok, dann danke fuer eine Aufklaerung, und ein grosses Lob an die
Entwickler!
Gruesse aus Muenchen
Mario
Hallo Mario,
eine Bedienungsanleitung gibt es leider noch nicht. Den Bediencode hat
Jiri geschrieben bzw. um jetzigen Stand vollendet. Wenn man es genau
wissen will, muss man in das Modul menu.c, eeprom.h und eventuell andere
Dateien durchsehen.
Eine Bedienunsganleitung sollten wir haben und um Jiri zu entlasten,
sollte die jemand anders in englisch schreiben.
Die sollte enthalten:
-Beschreibung des Funktionsumfangs
(Wieviele Schaltzeiten und Temperaturen, Auto/Man Modus, Fenster offen
Erkennung, automatische Sommer/Winterzeit Schalte, Fehlercodes Ex,
Beschreibung der Adx Werte, Anbringen auf das Ventil, Einlegen der
Batterie und besoonderheiten der Verriegelung usw.)
-Bedienfolgen über Knöpfe und Drehrad
-Pin Belegung
-Serielle Schnittstelle
-Befehle der Programmierschnittstelle
-Service Menü
-Kalibrierwerte
-Flashen des HR20 mit diversen Tools mit kurzer Beschreibung wie zu
verbinden ist (Kabel, Adapter), wie man die SW benutzt, wo man den Code
zum Flashen herbekommt
-Debug Ausgaben
-Sobald implementiert, Flashen per Bootloader
Wenn Du möchtest, kannst Du das anfangen.
Gruß
Karim
Hallo Karim,
Ich bin gerne bereit Dokumentation beizusteuern.
Allerdings bin ich der Meinung, dass man nicht alles erklaeren muss.
"Anbringen auf das Ventil" steht ja wohl in der mitgelieferten
Bedienungsanleitung.
Und generell sollten nur die Unterschiede und neuen Features der
OpenFirmware gegenueber der orginalen FW in ein Manual, denn
weniger Text ist leichter verstaendlich.
Noch ein Usabillity-Feedback zum Schaltzeiten-Programmieren:
Hat man jetzt 4 Schaltzeiten pro Tag (also sowas wie
"7:00=SonneMond,9:00=Mond,17:00=Sonne,23:00=Mond") oder mehr? Und was
passiert wenn man in der letzten Schaltzeit auf oder ueber die 0:00
geht?
Mich verwirrt das etwas.
Ich werd mir den Code anscauen und schon rauskriegen, wies gemeint ist,
aber noch bin ich DAU und danach sollte sich das Menu-ing evtl ein
bischen orientieren ;)
Ansonsten wuerd mich immer noch der RFM-Support interessieren:
Wer ist denn derjenige, der das RFM-Modul auf die Platine geloetet hat
und einen Schaltplan gemalt hat? Gibts da auch Code dafuer?
@jdobry:
window_open_thld ist ein gutes Stichwort:
Wollte sowieso anmerken, dass mein HR20 staendig OPEN gemeckert hat,
obwohl das Ding stundenlang auf dem Schreibtisch bei konstanter
Raumtemperatur lag. Da scheint wohl irgendetwas ueberempfindlich zu
reagieren.
Ich haette eine WindowOpenDetection sowieso gerne abschaltbar oder
zeitlih-verzoegerbar einstellbar, da das ein ziemlicher Batteriekiller
sein kann, besonders wenn sie etwas ueberempfindlich ist.
First of all, you did a great job in implementing a new firmware in the
HR20!
I'm interested in building a control panel for the HR20 which is away
from the radiator and connected to the HR20 via RS-232.
The reason for this is, that the HR20 is mounted on top of my radiator
below the floor. In this case the built in temperature sensor cannot be
used to measure the room temperature.
Would it be possible to implement a RS-232 command that accepts
temperature values from an external device. So i can send e.g. every
second or minute the room temperature to the HR20 an it ignores the
internal temperature sensor?
Probably two commands are needed:
disable internal temperature sensor
receive temperature from external sensor
What do you think?
Regards,
STB
Hallo Mario
die Original Bedienungsanleitung ist ziemlich lausig und gerade das
Montieren bereitet vielen Schwierigkeiten.
Zu den Schaltzeiten. Es gibt 4 Paare von Ein/Ausschaltzeiten. Wenn ----
im Display steht, bedeutet das, die Schaltzeit wird nicht verwendet.
Hab das auch noch nicht alles genau gesichtet, könnte mir aber
vorstellen, dass Fehlbedienung möglich ist. Falls Dir da was auffällt,
bitte berichten.
Bin gerade dabei, ein Windows Programm zum Fernsteuern zu schreiben. In
dem Zuge werde ich einige Details ermitteln auch wegen der Zuordnung der
Temperaturen zu den Schaltzeiten.
Das RFM Modul hat glaube ich Dario verwendet, eventuell auch Jürgen
siehe oben. Es gibt an anderer Stellen in diesem Forum (z.B.
Beitrag "RFM12 - Funkmodul",
Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module") lange Threads zu diesem
Modul. Da findet man auch Codebeispiele. In der momentanen SW habe ich
keine Integration gesichtet.
Den Schwellwert für die Open Window Erkennung kann man über Datum S1d
verstellen. Hole Dir die neue Revision. Vermutlich hat da Jiri den
Default schon angepasst, ansonsten kannst Du über Serielle Schittstelle
mit dem Befehl S1d20 den Wert auf 20 stellen. Dann sollte es besser
sein. Über den Parameter kann man dann auch die Erkennung ganz
abschalten bzw. auf unempfinlich schalten.
Gruß
Karim
Hi D. E.,
I see the same need for that. I is allways better to measure the
temperature there, where you sit.
The easiest way would be, to solder out the sensor add a shielded caple
of desired length, place the sensor where you want and reconnect it to
the module.
Sending the temperature via rs232 to the module would be also a nice
option.
Regards,
Karim
Hi Karim,
danke fuer die schnelle Antwort!
Also Schaltzeiten und WindowOpen werd ich jetzt gleich mal ausprobieren!
*RFM:*
Zu der RFM-GEschichte, ok, da sprech ich den Dario mal direkt drauf an,
bzw wahrscheinl wird er es eh bald hier lesen.
Wollt zum RFM noch ein paar Anmerkungen machen:
Wenn das HR20 nur seinen Zustand
(IstTemp,SollTemp,Valve%,BatteryStatus,...) gelegentlich melden soll,
dann ist die ganze Geschichte an sich kein Problem. Seine eigene ID
sollte er halt noch mit in das Funktelegramm dazupacken damit man die
Dinger auseinanderhalten kann.
Schick waers wenn man diese ID in einem Programmiermodus einstellen
kann, denn man will nicht unbedingt fuer jeden Thermostaten ne eigene FW
kompilieren.
Interessanter aber auch komplizierter sieht die Sache aus, wenn man den
RFM bidirektional beteibt: Interessanter, weil man dem HR20 eben auch
Sollwerte/Stellwetrte/Schaltzeiten/Uhrzeit/... befehlen kann.
Generell gibts da aber 2 Sachen zu beachten:
1. Strom sparen: Der RFM sollte nicht unbedingt permanent auf Listening
geschalten sein, weil er so relativ viel Strom frisst. Er sollte nur
gelegentlich mal kurz hoeren ob was gesendet wird. Um diesen Zeitpunkt
zu erkennen gibts mehrere Moeglichkeiten:
1.1.Die Conrad-Funkheizungsventile zB horchen nur alle 117 Sekunden auf
ein Telegramm. Da muss auch (vom Raumcontroller IMMER eins gesendet
werden, zwecks Clock Recovery). So kann mans machen, ich find aber
1.2. besser: Der HR20 sendet zu regelmaessigen Zeitpunkten ein
Statustelegramm. Danach ist er jeweils 1 Sekuned auf Lauschen
geschalten.
Das finde ich eine bessere Art des Syncens, denn es setzt keinen
permanent laufenden Sender (Raumcontroller) vorraus, UND man ist
wahrscheinlich eh an regelmaessigen Statusmeldungen interessiert. Das
ganze eignet sich auch noch ganz gut um
2. Sicherheitsaspekte zu beruecksichtigen: Damit keine Unbefugten dem
HR20 Befehle geben duerfen, bietet sich eine einfache Absicherung via
Challenge-Response an: In seiner regelmaessigen Statusmeldung sendet der
HR20 auch gleich eine Zufallszahl mit, ueber die sich ein "Befehlsgeber"
beim HR authentisieren kann. Das waere dann relativ sicher (PlayBack
Attack).
Ich hab mal sowas fuer einen FUnkschalter (2RFMs und 2 AVRs) gecodet,
das koennt ich da gerne einbauen falls interesse.
Die Kommunikation koennte dann so aussehen:
1. HR sendet regelmaessig
/[HR's ID,SollTemp,IstTemp,Valve,RandomNumber]/
2. Falls ein Kommando an den HR gehen soll, so muss die Gegenseite
innerhalb von 1 Sekunde folgendes zuruecksenden:
/[HR's ID,Hash(RandomNumber,Key),Kommandos]/
3. Der HR prueft ob /Hash(RandomNumber,Key)/ passt (beide Seiten kennen
Key), und wenn ja exect er das Kommando und sendet Antwort zurueck.
Die Kommandos selber koennten der Einfachheit COM-Port-Befehle sein, am
besten mehrere auf einmal, die dann nacheinander an den COM-Interpreter
geleitet werden (so muss man keinen neuen Kommandointerpreter
schreiben).
Die gesammelten Antworten gehen dann als ein Paket zurueck:
/[HR20'sID,Antworten]
Falls das irgendwer fuer brauchbar haelt (hallo Dario ;) wuerd ich da
gern was in die Richtung machen. Ein paar Codeschnipsel fuer RFM
speziell in der OpenHR-Firmware laufend wuerden mich auf jeden Fall
interessiern.
@Mario Fischer: message for me you must write in english. I am not abble
to read german, sorry.
@ D. E.: push temperature from external source is possible (remove
temp_average macro, create int16_t variable with same name, create com
function for write into this value) We will need something like this on
2.xx versions with master/slave control (cable or wirelless)
Edit: your last reply and my intersected, but nevermind...
I know the RFM@HR20-pictures, but are there also some lines of code?
ok, heres the english version:
Some Ideas about the RFM-Module in a HR20:
If the HR20 should just broadcast it's state
[CurrentTemp,WantedTemp,ValvePos,BatteryStatus,...], it's implementation
is quite simple. The only thing to be aware of is to definetly switch
the RFM off when not in use and to send a individual Device ID within
the broadcasted status message.
It would be nice if this ID could be programmed via Menue and not be a
constant in the firmeware's source code (no own compiling for each
HR20).
If the HR20 should be able to receive commands from a "master" it gets
more interesting and sophisticated:
Interesting, because now it is possible to remotely adjust WantedTemp,
ValvePos, SwitchingTimes, ..., sophisticated because you have to take
care about power saving and security.
1. Power saving:
RFM's receiver circuit may not be switched on the whole time, it
consumes too much power. It is ok, if it only listens "sometimes" for a
short while if a command is being sent.
This "sometimes" can be done in multiple ways:
1.1 In the Remote-Heating-Valves from Conrad Electronics, the Valve
listens for a command for 1 second every 117 seconds. The rest of the
time the valve's receiver is switched off. For clock recovery, a master
("room controller") MUST send every 117 a telegram (even when no valve
change is needed).
This is one solution but i like better the other one:
1.2 The HR20 sends regulary a status telegram. After this sending, the
HR20 turns on the receiver for 1 second. Within this second, the master
must send a command (if he wants to). That is a nice way of clock
recovery, because it doesnt require a regulary sending master like at
Conrad, and you will be interesed in HR20's status anyway. Also the
status broadcast can be used to acheive
2. Security:
To avoid that unauthorized "masters" may send commands to the HR20, a
simple challenge-response could be implemented easily. It just requires
a hash function and a shared key, so it's not very
programspace-consuming.
2.1 When the HR20 broadcasts a status message, it also sends a random
number n(each time a different):
/ [HR20'sID,Random,CurrentTemp,WantedTemp,ValvePos,BatteryStatus,...] /
2.2 If the master wants to send a command to the HR20, he has to respond
within one second with this Telegram
/ [HR20'sID,hash(Random+SharedKey),Command] /
2.3 The HR20 checks weather the hash is as expected (can only be correct
if opponent knew the right SharedKey), and if so, Command is executed
and the response is sent back
/ [HR20'sID,Response] /
For code-reuse, Command could be the same format as the COM-protol, so n
extra parser is needed.
After step 2.3. the HR20 will listen another second for a further
possible command. If no command occurs, the HR will turn of the entire
RFM off till the next status broadcast.
I implemented such a protocol with 2 RFMs and 2 AVRs so i could recycle
some code and add it to the project if desired. Some code snipplets
about the RFM that was soldered to the HR20's PCB would be interesting
for a start up (not for getting familiar with the RFM (i know him ;),
but rather for how to integrate it into the Firmware).
XTEA seems short, but it is just a symetric-algorithm (am i right?).
so this doesnt protect you from sending unauthorized commands to the
HR20, since playback-attacks are always possible.
i would say that messages like "ID32: set wanted temp 24.5C" do not need
to be encrypted. but the should not be recorded and resent to the HR20
while i am on hollidays ;)
so i would suggest challenge-response, which just requires a hash
function which requires even less than 500B.
Hallo zusammen,
zunächst einmal ein ganz grosses Lob für die viele Arbeit in die
Heizungssteuerung.
Ich bin jetzt auch ein wenig eingestiegen und habe folgende Frage:
Habt Ihr schon die Speicherplätze 0x006, 0x136, sowie 0x00f bis 0x01c
(galt für die Version 1.xx; siehe Werner Cornelius) für die Version 2.04
ausfindig machen können?
Befehle kann ich - zwar leidlich, da die Verbindung immer mal wieder
abbricht - an einzelne Speicherplätze z.B. per Norton Terminal senden,
diese scheinen aber anders besetzt zu sein!
Das Zuweisen eines Wertes an bestimmte Speicherplätze (z.B. an 0x080)
funktioniert zumindest. Mir fehlen aber die "richtigen"
Speicheradressen.
Könnt Ihr mir weiterhelfen?
Vielen Dank, Gerd
@Mario Fischer: Thanks for english translation.
You are right, XTEA is symetric-algorithm and we can't use it without
challenge-response in encryped packets due to replay attack. I know.
You are right that with batteries we can't use RFM12 permanetly. For
this moment I have this idea:
1.1 (by your numbering) in points:
- master MUST send time synchronization packets
- after time synchronization HR20 will have windows for tramsit
- HR20 transmit windows is smaller (200ms) and in order of network
address (address 1 have window 1, addr 2 window 2 etc)
1.2 Problem is that we must solve colisions in shared media. this is not
2point protocol. I worry that this version can have collisions.
2. security:
I am using seed-hash algoritm in one my web aplication. I agree that it
is possible use.
For this moment I don't know what encryption is best.
But your protocol have one disadvantage: Status packets from HR20 is
not encrypted. It means that anybody can know mode of usage of your
rooms. It is very easy to find time when nobody leave in home. And
bad-man can plan unwanted visit :-( I belive that it can be fixed.
From your text it is clear that you are little bit fare than I. Current
code haven't any line for RFM12 modules. Previous priority was another,
and now is right time to thing about next steps. Therefore some code
sniplets will be very helpfull. If you want, I can try to integrate it
into project. (jdobry at centrum dot cz)
Technical: you can see on RFM@HR20-pictures that SPI interface is not
used. Simply before pins are used for keys and reconect it on curent PCB
is nightmare. SPI need SW implementation.
I have HW for master. It is ATMEGA16 with RFM12 connected to SPI and
have RS232 serial line. Plan is connect this master to some linux based
router (cheap and need less power than computer, usualy run 24/7 and
have connection to internet. For HW see to OpenWRT project). ATMEGA will
communicate with RFM module and manage low level network and encryption
layer. On serial line we will have something that current OpenHR20
procokol with network addresing extension.
********************
** ADVICE NOTE: **
********************
At this moment I will add only this items from TODO list:
- com: add command for manu/auto and wanted temperature change
- improve watch.c (add more significant values for Txx command)
After this we can release 1.00 BETA version. (I hope)
Next I plan to leave v1.xx OpenHR20 development. For my interrest I need
to continue on wireless communication for OpenHR20 (v2.xx) on branch.
Therefore we need to find maintainer for 1.xx line. Some volunteer?
PS: it is one of basic principes of public projects. Anybody can improve
project for self and result is better and more generic.
Hi jdobry,
thanks for thinking about my suggestions!
Some comments on your comments ;)
1.1. do i understand you right? you want to have a master that
round-robinly sais "id 1, if you want to say something, do it now" pause
"id 2 ..." ...
okay, good approach for collission avoidance, but i see the problem,
that if the master is offline once (battery change, power plug out,
firmware update, or simply one HR20 doesnt recognize the telegram for
radio noise), all clock recovery is lost. you would somehow have to
"reboot" all your HR20s or they would have to enter in some kind of
"resync mode" ... looks complex to me!
thats why i favour
1.2. i see your collission remark, but i dont think they are likely:
packet transmission time is very short compared to intervals (sth like
10 bytes @ 19kbs every 120 seconds for assumptions). i dont think a
collission is very likely. but we could very simply improve it that HR
with ID i sends in an interval of something (120sec + i*sec + 0.1*rand).
i think this would make colls very unlikely.
2. ok, could be a fundamental discussion, if plain status messages
indicating eco-temperature on heater attracts burglars - but anyway,
your point is good.
beside, sym. chipering of the messages sent does make sense anyway,
because otherwise an attacker could calculate the key offline:
attacker snoops one message session, which means he gets Rand and
HashVal.
Then he can calculate offline
for (i=0; i<KEYMAX;i++) if (HashVal==hash(Rand+i)) printf "Key= i"
note that offline brute force in ths scenario can make sense, because
radio packets must be short, which means 128bit keys make packets so
long that packet losses become likely.
a online brute force attac can be easily avoided: if authentication
fails, HR20 waits a penalty time till it accepts next auth try.
the whole thing is a trade off between security, package loss and
battery saving anyway. we can't secure it like a WLAN, but i think these
kind of security thoughts are good.
looking at the available home automation radio crap you see that the
dudes who built did not give a single thought about security...
I tried the latest FW this evening (since the version before permanently
told me "OPEN") -
the HR reported "bATT" after booting and told me that the temperature
was 11C, the motor did not calibrate or move in any way.
The strange thing about it is, that the HR was powered by a power supply
device running with clean and stable 3.3 V.
The original FW of the HR never complained about low battery.
The previous version of the Open FW i tried also reported bATT in the
beginning, but later it disappeared (also powered with stable 3V3 from
supply device).
Is there a problem with the ADC checking the battery?
@Mario Fischer:
I thing about it and 1.2 communication would be better. TX packet need
more current than RX, but with 1.2 I need TX short time. In 1.1 case I
need enable RX for longer time, tepend to packet timing tolerance.
PS: for 1.1 I mean send only one packet from master, windows for slaves
is calculated from this timestamp.
Your problem: "HR reported bATT after booting" is caused by empty
EEPROM, check it. (empty EEPROM default value is 0xFF and it mean 5.12V,
your voltage is smaller ;-)
Offline attack is possible only teoreticaly. "As of 2004, the best
attack reported on XTEA is a related-key differential attack on 26 out
of 64 rounds of XTEA, requiring 2^20.5 chosen plaintexts and a time
complexity of 2^115.15 (Ko et al, 2004)." -
http://en.wikipedia.org/wiki/XTEA
TEA (XTEA predictor) is used in XBOX and you probably know, that it have
succesfull attack. But XTEA is better and motivation to attack some
heating system mis much smaller than attack XBOX
Hi jdobry,
First Question:
Should we open a new Thread
"OpenHR20: Firmware for Honeywell Rondostat HR20E" ?
This one is quite long and touches lots of other HR20 issues.
Security:
Offline-BruteForce: Of course BruteForce with 128 Key is not efficient.
But transporting radio telegrams containing 128 bit long challenges of
responses seemed to radio-expensive to me. It is important to keep the
packets short for energy saving and not getting them destroyed by air
noise.
But the whole discussion about BitLengthes of Random, Response and Key
are a little too off-topic in the current project phase. We can discuss
that later as well, since we almost agree anyway ;)
EEPROM & Empty Battery:
Ok i will flash the EEPROM as well! This sounds also like it is the
cause for ths strange temperature (Conversion Table) and why the motor
doesnt want to move (to save the weak battery)...
I will give feedback when i tried it with the flashed EEPROM. Hope the
WindowOpen is stable now ;)
RFM on SPI:
Im not sure if i got u right but connecting the RFM to the hardware SPI
is not that neccessary. It saves probably some CPU-cycles and some lines
of code, but Software SPI is really easy and cheap and we can select
Pins that we find nice to solder ;)
I would suggest to wire the RFM's IRQ-Pin as Well to an available
IRQ-Pin of the AVR, because during the sending, you can put the AVR to
sleep between SPIing a sendbyte to the RFM and waiting till the RFM sent
it ... it's quite simple some extra uAmps ;)
@Mario Fischer:
Create another thread is good idea.
EEPROM: problem is, that you must write Flash and after EEPROM in this
order. Problem is that we have "preserve EEPROM" fuse in AVR disabled.
And rewrite flash need erase device and EEPROM is also lost.
You can get measured battery value by serial line, (command T01 or D)
or you can read it on LCD on service menu (press & hold all buttons,
after this press "C", move wheel to second bar on hourbar line. value is
hex)
RFM on SPI:
- SW SPI - I agree, this is not problem
- I hope that I found pins easy to solder
- IRQ will be used, see to my pictures, pin PE6. It is small work
arround, we don't have any free pin on AVR. (PD0 is not possible use by
AVR LCD controller design, PE5&PE7 have connection bellow MCU, I have
tools to remove MCU and put it back, but it is not usual). See to RFM
documentation, SDO is possible use as IRQ, but only with active nSEL and
before egde on SCK. We must only disable/enable nSEL and after wait to
IRQ.
A new thread is a good idea.
I've bought some other electronic radiator controllers, one HR40, one
THERMOtronic and two HR20E. Like I said earlier in the thread they seem
to be identical or pin-compatible in the inside. So I'll check if I can
program those too. (Maybe we can name the thread ... and others)
I'll also begin the documentation and manual as soon as my JTAG device
arrives and I have a working openHR20E to test with.
Thanks for the great work!
I created a new Thread
* OpenHR20: Firmware for Honeywell Rondostat HR20E * in
Beitrag "OpenHR20: Firmware for Honeywell Rondostat HR20E"
Please put all Questions&Answers about this open Firmware there.
Please write in English there.
Hallo,
ich versuch´s noch mal - hatte bisher keine Antwort erhalten - oder bin
ich vielleicht im falschen Forum?
Ich beschäftige mich auch ein wenig mit der Steuerung des HR20 und habe
folgende Frage:
Habt Ihr schon die entsprechenden Speicherplätze 0x006 (Komfort- und
Spartemp), 0x136 (Solltemp), sowie 0x00f bis 0x01c (Wochentage - galt
für die Version 1.xx; siehe Werner Cornelius) für die Version 2.04
ausfindig machen können?
Befehle kann ich - zwar leidlich, da die Verbindung immer mal wieder
abbricht - an einzelne Speicherplätze z.B. per Norton Terminal senden,
diese scheinen aber anders besetzt zu sein!
Das Zuweisen eines Wertes an bestimmte Speicherplätze (z.B. an 0x080)
funktioniert zumindest. Mir fehlen aber die "richtigen"
Speicheradressen. Es ist ausserdem nur das Senden von jeweils einem
Befehl möglich (nicht zwei, wie bei der Version 1.xx)
Könnt Ihr mir weiterhelfen oder mir schreiben, woran ich mich wenden
kann?
Vielen Dank, Gerd
@Gerd,
Nobody knows the commands when ever existent for version 2.04, which has
a total different behavior as the old version.
Therefor the SW was completely new written and has allready more
functions as the old one (e.g. additional On/Off Times + comfort temp.)
and can be remote controlled.
But you have to use a programmer to flash the device. Later on the
module will include a bootloader, so you can exchange the SW over rs-232
but the first version must never the less be flashed with a programmer.
You can get the code here https://sourceforge.net/projects/openhr20/
Currently I am working on a windows program for comfortable remote
control. The other freaks are tossing on wireless connections and later
on WEB access is intended.
Regards,
Karim
Hallo,
Ich habe mir auch den HR20E bei Conrad bestellt und bei drei Geräten das
gleiche Problem:
Im Voll-Hub-Modus funktionieren sie problemlos. Im Standard-Hub-Modus
(default) bleiben nach circa drei Tagen die Heizkörper kalt, obwohl das
Gerät eine hoehere Solltemperatur anzeigt. Nimmt man das Thermostat ab
und dreht das blaue Regelrad ganz auf werden die Heizkörper schnell warm
und wenn es zu warm wird auch wieder automatisch und richtig
abgeschaltet.
Die Batterien sind neu und Markenprodukte, daran sollte es nicht liegen.
Die Ventilstifte in der Heizung werde von selbst herausgedrueckt, denn
wenn man das blaue Regelrad selbst aufdreht wird die Heizung warm. Das
Problem mit dem Batteriefach, dass vom Regelrad aufgedreht wird kann es
auch nicht sein, da das die Thermostate im Voll-Hub-Modus keine Probleme
machen.
Mir scheint als wuesste das Thermostat im Default-Hub-Modus nach ein
paar Tagen nicht mehr ob es schon richtig aufgedreht hat, glaubt es
waere offen und bleibt an der Position.
Weiss jemand eine Lösung hierfuer? Im Voll-Hub-Modus sind mir die
Temperaturschwankungen zu hoch, da die Heizkoerper sehr schnell heiss
werden.
Danke für eure Antworten,
Robert
I was looking for this for a long time now. Need input on this amzon is
giving 300 off on it
<IMG>http://www.imagefrost.com/img/ih/iG.jpg</IMG>;
Is it worth the price...? and has anyone used sony bravia can give any
input.
Thanks
>Autor: Robert (Gast)>Datum: 21.12.2008 09:59
Habe deine Frage in neuem Thread nochmals eingestellt, da ich exakt
dieselben Probleme habe:
Beitrag "Honeywell Rondostat HR20: technische Probleme"
Ich denke, die Fortführung dieses uralten Artikels macht keinen Sinn
mehr.
Weiteres siehe genannter neuer Beitrag.
Klaus
Hi,
habe eine Wohnung mit dem Rondostat 20E übernommen, aber ohne
Gebrauchsanweisung.
könntest Du mir bitte die wichtigste/n Seiten zumailen.
Sind nirgens im Web und der Vertreiber will 5€ dafür.
Danke
:)
Thread beobachten
Seitenaufteilung abschalten
