Hi, Ich öffne diesen Thread als Nachfolger des Beitrag "Alternative Firmware für Sparmatic Zero Heizungsthermostat" Threads zum Sparmatic Zero. Hier kann dann auch technischer zum Comet gesprochen werden :) Der Zero v2 ist erkennbar am zum Comet sehr ähnlichen Platinenlayout. Er hat keinen JTag Header mehr, dafür aber unterm Batteriefach 2x 6 Testpads sichtbar. Zero <-> Coment entscheiden sich hauptsächlich durch den Drehimpulsgeber im Comet, während der Zero dafür 2 Tasten mehr hat. Nun fange ich direkt mit einer Frage an: Wie wird die Batteriespannung gemessen? Ein etwas abstruser Ansatz, sofern mein Schaltplan stimmt: PE2 auf low, PE1 auf Pullup und dann mit ADC0 messen (Aref = Avcc). Hier ergibt sich dann die (bekannte) Flussspannung der Diode, durch rückwärts rechnen erhalten wir also unsere Versorgungsspannung. Ein anderer Spannungsteiler (Messen mit Aref=int. 1,1V) oder eine bessere Referenz als diese Diode fällt mir im Schaltplan nicht auf. Im anderen Thread steht noch die Erkennung der leer/herausgenommenen Batterien im Raum. Dort wurde der AIN1 als Interrupt vorgeschlagen. Bei mir ist der allerdings offen, sofern nicht unterm Mega169 noch ne Leiterbahn drangeht.
Angehängte Dateien:
-
sch_hr2.png
140 KB
Hallo Matthias, Rückwärts: Bandgap 1.1v Messen (Kanal 14) mit Referenz Vcc. Vcc = ( 1024 / ADC ) * 1.1V Jürgen
Ah man kann die Bandgap Referenz auch messen - ich dummerchen :) Dankeschön.
Ist es möglich, Bilder der Platinen hier einzustellen? In der Diskussion um Knut Ballhause habe ich von meinem bei Aldi erworbenem Gerät zwei Bilder gefertigt. Ich weiss aber nicht, ob das die Bilder des Gerätes sind, welches hier behandelt werden soll. Gruss Robert
Das Aldi Gerät "Thermy" gehört ebenfalls dazu, ja.
Hier sind die Links zu den Sparmatic Comet-Daten zum Vergleich (von Leopold B.): Schaltplan und Bilder von der Leiterplatte: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" http://www.mikrocontroller.net/attachment/92338/SparmaticComet_Schaltplan.png http://www.mikrocontroller.net/attachment/92339/SparmaticComet_TOP.jpg http://www.mikrocontroller.net/attachment/92340/SparmaticComet_BOT.jpg Spannungsverlauf an ADC2/PF2 beim schließen: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" http://www.mikrocontroller.net/attachment/93404/SparmaticComet_Spannung_an_PF2_beim_Schliessen.png LED Segment Belegung: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" http://www.mikrocontroller.net/attachment/92916/SparmaticComet_SegmentMapping.png Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Hallo Matthias, Danke erstmal für Deine Aktion mit dem neuen Thread. Der Schaltplan müsste nochmal überarbeitet werden, da einige Unklarheiten und Fehler drin sind, ich werde mich mal bei machen, wenn ich dazu komme. Ansonsten denke ich, dass ich Dir dieses WE noch eine eMail schicke. Hättest Du Bock, für das Projekt einen Artikel zu schreiben, in dem alle Informationen ihren Platz finden und die entsprechenden Downloadlinks zur Verfügung stehen würden?
Hm, wir haben den zu Zweit in gründlicher Feinarbeit erstellt :) Einige Widerstandswerte sind nachgemessen, da teilweise eine komische Beschriftung der SMD Packages erfolgt ist. Klar, die Mosfets sind eigentlich Bipolartransistoren, das wissen wir inzwischen. Die Polung der Reflexlichtschranke ist auch nicht überprüft, außerdem ist die Sender/Empfänger zuordnung geschätzt. Der "Rest" sollte eigentlich stimmen. Nen Artikel wollte ich eigentlich erst anlegen, wenn das Projekt etwas fortgeschritten ist. Dennoch kann ich ja schonmal die bereits vorhandenen Informationen eintragen. Quellcode noch am Wochenende wäre super :) Ich werde wohl heute abend mal ein bisschen anfangen, ein Projekt aufzusetzen. LCD Initialisierungscode gibs ja schon im anderen Thread, dann muss ich das nicht nochmal austüfteln. Viel weiter kommt man erfahrungsgemäß am ersten Projektabend eh nicht.
http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate Nicht schön, aber wenigstens mal alles zusammengefasst.
Angehängte Dateien:
Hallo nochmal, anbei der überarbeitete Plan. Im Grunde habe ich die Daten von Leopold B. benutzt, überprüft und mit Werten versehen. Ausserdem habe ich versucht, das Ganze modular und übersichtlich anzuordnen. Der Zero 2 und der Comet unterscheiden sich lediglich durch den Drehgeber, der beim Comet einen Grey-Code ausgibt und an die Pins für die Tasten "PLUS" und "MINUS" angeschlossen ist. Ansonsten ist die Hardware direkt funktionskompatibel. Die Sache mit der Lichtschranke muss ich noch mit einem Zero 2 eines Bekannten testen... Hoffe, dass ich nichts übersehen habe.
Habe gerade beim Tracen festgestellt, dass PIN E5 (Pin7 am Mega169P) beim Comet für eine Hintergrunfbeleuchtung des Displays vorgesehen ist. Der Pin geht auf Landings für 0603 SMD-LEDs mit entsprechenden Vorwiderständen gegen '0V'. Wenn man sich also die Mühe macht, das Display von der Platine zu pflücken und die Landings entsprechend zu bestücken, kann also eine nette Hintergrundbeleuchtung realisieren. Alle LED-Farben, ausser denen mit höherer Flussspannung als 2.4V, müssten funktionieren.
Angehängte Dateien:
-
thermy1.jpg
68 KB -
thermy2.jpg
170 KB -
thermy3.jpg
230 KB
Aktuelles ALDI-Angebot: Energiespar-Regler für Heizkörper zu € 14.99 EAN 29082285 -> Art.-Nr.: 8228 EUROTronic Technology GmbH; Südweg 1; D-36396 Steinau-Ulmbach Art.nr. 700 100401 | Verp.nr. 900 000116 www.thermy.de 3 Tasten, 1 Encoder (Drehgeber) Mini-USB, sonst keine zugänglichen Pads oder Stifte Gehäusehälften sind an 4 Punkten verschweisst (ca. 2 mm Stift durch Bohrung und dann plattgeschmolzen). Davon lassen sich zwei per Zange abscheren, die anderen müssen ausgebohrt werden. Vorsicht, das Gehäuse ist dünn. Anbei ein paar Bilder.
PCB Beschriftung:
REG
RE V.0.0
Das Getriebegehäuse war möglicherweise im ersten Design nicht stabil
genug, da die auf der Motorseite untergebrachte Beschriftung (EUROtronic
Logo etc.) durch Rippen unkenntlich gemacht ist.
Angehängte Dateien:
-
Motor_Versorgung.PNG
7,9 KB
Hallo Matthias, nicht daß ich's selbst untersucht hätte (noch kein Comet im Haus), aber aus mehreren Versionen, die zum Teil sinnfreie Schaltungen zeigen. Da ich vermute, daß auch kein Chinese Dioden einfach mal von Masse nach Masse lötet, macht folgendes mit den gegebenen Bautteilen am meisten Sinn: Der Elko soll die Batterie von Motorstrom entlasten, wird dazu langsam über R9 geladen. R10 begrenzt die direkte Stromentnahme aus der Batterie und erlaubt über RC-Glied als Tiefpass die Messung des Motorstroms via ADC2: Imot = 1,4 * (1024 - ADC) [mA] mit Vref = Vcc Der Faktor 1,4 ergibts sich aus 3V / 2,2 Ohm , ist also von der Batteriespannung abhängig, d.h. es geht mehr um dem Strom-Trend, "Strom steigt an" -> "Motor muß mehr Kraft aufwenden" -> "Anschlag erreicht". Wer den Comet schon besitzt, kann ja mal messen :-) Spannung am ElKo sollte nach einlegen der Batterie sehr langsam ansteigen. 1M * 100µF -> im Minutenbereich Wenn der Motor startet, bricht die Elko-Spannung ein. Gruß, Jürgen
JW schrieb: > nicht daß ich's selbst untersucht hätte (noch kein Comet im Haus), > aber aus mehreren Versionen, die zum Teil sinnfreie Schaltungen zeigen. > Da ich vermute, daß auch kein Chinese Dioden einfach mal von Masse nach > Masse lötet Die im Schaltplan von Matthias und mir gezeigte Schaltung ist korrekt. Die Diode liegt nicht von Masse nach Masse, sondern von '0V' nach Masse und schützt den Controller vor Verpolung der Batterien. JW schrieb: > Der Elko soll die Batterie von Motorstrom entlasten, wird dazu langsam > über R9 geladen. Nein. Mitnichten. JW schrieb: > R10 begrenzt die direkte Stromentnahme aus der Batterie Auch nein. Jedenfalls nicht absichtlich. JW schrieb: > und erlaubt über RC-Glied als Tiefpass die Messung des Motorstroms via > ADC2: Das ist korrekt. JW schrieb: > Spannung am ElKo sollte nach einlegen der Batterie sehr langsam > ansteigen. > 1M * 100µF -> im Minutenbereich Da es nicht so verschaltet ist, trifft dies nicht zu. Der Elko lädt sofort, da er wie in den Plänen oben angeschlossen ist.
Kann mir mal jemand erklären, warun der 1M Widerstand am Port PE0 Pin 2 eingebaut wurde? Und wo liegt der auf der Platine? Gruss Robert
An Mark T. vielen Dank für die guten Fotos. Daran erkennt man, dass die Lichtschranke in der Tat nur noch für des Erfassen der Endposition im ausgefahrenen Zustand da ist und keine Pulse mehr misst. Gut zu wissen!
Ich korrigiere mich: gemeint ist R9 (soeben gefunden, war anderes Layout). Unklar ist dessen Funktion. Grüsse R.
R. Freitag schrieb: > Kann mir mal jemand erklären, warun der 1M Widerstand am Port PE0 Pin 2 > eingebaut wurde? Und wo liegt der auf der Platine? Ich nehme mal stark an, dass dieser Widerstand im Verbund mit der Diode D2 und dem Widerstand R19 (im aktuellen Plan) dazu dient, das Herausnehmen der Batterien festzustellen, um eventuell noch Daten im EEPROM zu sichern. Der Widerstand liegt bei den Cometen neben der Fräsung in der Platine und ist 01E beschriftet. Beim Zero 2 liegt er unter dem Controller in der Reihe rechts neben den 3 Cs.
Hallo Matthias, Eigentlich hätte mich für Dein Projekt interessiert. Hatte gedacht dies ist ja ein neuer Thread ... Leider schon wieder gekapert. Trotzdem viel Erfolg!
Anscheinend lesen wir aneinander vorbei. Ich bezog mich auf den folgenden Schaltplan: http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate der in diesem Thread geposted wurde, und da ist der R9 an Pin 2 gegen Masse geschaltet. Das macht für mich keinen Sinn, ich will den ohnehin entfernen, weil ich die Schnittstelle brauche. Und deswegen fragte ich nach dem Sinn dieses Widerstandes.
R. Freitag schrieb: > Anscheinend lesen wir aneinander vorbei. Das glaube ich nicht. An Pin2 Des Controllers ist nur ein Widerstand und der ist in allen Plänen vorhanden, wenn auch mit unterschiedlichen Werten und Bezeichnungen. Die vermutete Funktion ist hier beschrieben: Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" R. Freitag schrieb: > Das macht für mich keinen Sinn, ich will den ohnehin > entfernen, weil ich die Schnittstelle brauche. Würde ich vielleicht nicht machen, da Du durch diesen Schritt das Gerät inkompatibel machst. Es sind doch eigentlich genügend Schnittstellen vorhanden, zum Beispiel die 4 JTAG-Pins.
k.i.d. schrieb: > Eigentlich hätte mich für Dein Projekt interessiert. > Hatte gedacht dies ist ja ein neuer Thread ... Keine Angst, Matthias und ich bleiben dran ;-)
Der Widerstand, den ich meine, ist vom Port gegen Masse geschaltet. Eine Verbindung zu irgendwas anderem sehe ich nicht. Sieh nochmal nach, in http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate an Pin 2. Gruss Robert
Jaaa doooch! ;-) Ich weiss, welchen Widerstand Du meinst. Dieser Widerstand aber nicht nach Masse geschaltet, sondern nach 0V, also Battrie (-). Werden die Batterien entnommen, wird vom Elko C8 über R19 eine positive Spannung auf 0V zurückgespeist. Dies könnte nun der Pin2 erkennen und einen Interrupt auslösen, bevor die Spannung aus dem Elko zusammensackt. Alles klar?
Das ist ziemlich intelligent :) Eigentlich benötigen sie ja nur für diese Aktion überhaupt das getrennte GND/0V Netz. Naja, gleichzeitig ists noch der Verpolschutz.
Genau! :)
Wozu der Aufwand? der Controller wird ohnehin nur im Minutentakt arbeiten müssen. Also schläft er in der Regel. Vor dem Schlafen gehen schreibt er seine Daten ins EEPROM und fertig, wozu braucht er eine solche Schaltung? Und ein Wechseld er Batterie kommt auch nicht alle Tage vor. Gruss Robert
R. Freitag schrieb: > Vor dem Schlafen gehen > schreibt er seine Daten ins EEPROM und fertig, Dann ist das EEPROM ziemlich schnell kaputt, oder man müsste einen aufwändigen Ringpuffer bauen. R. Freitag schrieb: > der Controller wird ohnehin nur im Minutentakt > arbeiten müssen. Oder wenn jemand an den Tasten spielt... Bei der neuen Firmware mit wechselnden Displayanzeigen und externer Steuerung wird auch etwas mehr Interaktion nötig sein. R. Freitag schrieb: > Und ein Wechseld er Batterie kommt auch nicht alle > Tage vor. Nein, kann aber jederzeit passieren. Ohne das sofortige Einstellen stromfressender Aktionen gäbe es keine Chance für sicheres Abspeichern.
Leopold hat anscheinend in C fuer den Comet entwickelt (mind. Displayansteuerung) - gibt es von ihm noch mehr Quellcode bzw. hat matze88 diesen und baut darauf auf? Wenn ihr eine Basisstation plant, moechte ich hiermit vorschlagen, dass diese auch mit einer Benutzerschnittstelle und der Moeglichkeit zum Schalten bzw. Ansteuern einer Heizungsanlage (Gastherme) ausgestattet werden kann. Also z.B. SPI Grafikdisplay, Drehencoder oder Touch, und dann einen PWM Ausgang als Steuerspannung und Schaltausgang um die Heizung ganz abzuschalten (Pumpe). Also vielleicht ein paar Pins ueber Stiftleisten verfuegbar machen, damit man Erweiterungen per Huckepackplatine leichter realisieren kann.
Mark T. schrieb: > Wenn ihr eine Basisstation plant... Nu mal sachte ;-). Ich denke, wir werden rechtzeitig bekanntgeben, wenn nach erfolgreicher Implementierung der nötigsten Dinge im Regler eine Zentrale erforderlich wird. Auch denke ich, dass diese Zemtrale ungleich aufwändiger wird, als das Umschreiben der Firmware für die Regler. Machen kann man viel, aber man darf auch den Aufwand und die eintausend Wünsche der möglichen Nachbauer und Nutzer nicht vergessen.
Wer ist denn 'wir'? Ich meinte Matthias Larisch, der im andern Thread schrieb: > Wir arbeiten derzeit zu zweit an dem Projekt, herauskommen soll eine > komplette Heizungssteuerung für eine Gasetagenheizung. Grobkonzept sieht > zwei der Sparmatic Regler vor sowie eine "Basisstation", an der die > Heizung mit dran hängt. Jetzt am WE gehts vermutlich richtig los, von > daher würde uns gerade jetzt dein Code helfen :) Es geht eh nicht darum, > dass wir den direkt verwenden - wir erstellen alles für gcc kompatibel > neu. > Zur Ansteuerung gibts dann noch ein nettes Webinterface, Schnittstelle > wird wohl ein LPC1378 am USB Port eines Routers, Datenverarbeitung der > Einfachheit halber dann auf diesem großen System.
Aaah, siehste, lesen muss man. Das 'wir', das ich meinte, bezog sich erstmal auf Matthias und mich, weil es wäre ja Quatsch, jetzt noch einen Thread zu öffnen, da es um dieselbe Sache geht. Wenn ich das falsch verstanden habe, möge man mich berichtigen. Ich habe es so aufgefasst, dass wir uns hier öffentlich abstimmen, Infos sammeln und austauschen und die Daten landen dann im Artikel. Zum Regler: Ich habe gerade mal den Motor zum Laufen gebracht und sowohl der alte Comet aus 2010, als auch ein neuer Comet aus 2011 und der Thermy nutzen die Lichtschanke zur Erkennung der Position. Für einen kompletten Fahrweg werden etwa 380 Pulse gegeben. Die Annahme, dass die Lichtschanke nur zur Erkennung der Endposition benutzt wird, ist somit falsch.
Angehängte Dateien:
-
thermy4.jpg
440 KB -
thermy5.jpg
230 KB
Knut Ballhause schrieb: > Daran erkennt man, dass die > Lichtschranke in der Tat nur noch für des Erfassen der Endposition im > ausgefahrenen Zustand da ist und keine Pulse mehr misst. Gut zu wissen! Es sind tatsächlich vier Flanken pro Umdrehung, Foto anbei. Ausserdem noch ein zurechtgezerrtes Bild des PCBs für's Wiki. Zum Basteln eines Programmierkabels hier die normale Belegung des USB Mini-B Steckers: http://pinouts.ru/Slots/USB_pinout.shtml
Ich sehe du hast den Fehler in deiner Annahme auf anderem Wege entdeckt :-)
Mark T. schrieb: > Es sind tatsächlich vier Flanken pro Umdrehung, Foto anbei. Wow, danke, gute Arbeit!
Knut Ballhause schrieb: > Wow, danke, gute Arbeit! Die sich auf das Lösen von vier Torx-7 Schrauben beschränkt.. Ich verstehe allerdings nicht, warum sie den 'Encoder' nicht symmetrisch gemacht haben.
Eine Zentrale sollte auf der gleichen Hardware laufen. Dann kann man Treiber wiederverwenden. Ich habe derzeit eine Idee, was ich haben will, sozusagen Anforderungen im Rohzustand: -) RS232 Schnittstelle (Forth und Kommunikation PC) -) mindestens 64 Satelliten -) Kommunikation per Modul -) Anschluss von reinen Thermometern möglich (als Messkopf) -) Hausbusanschluss -) Kachelofenanwesenheitsdetektor -) Steuerung von Ventilatoren, Kachelofenbedienelementen, Heizungen, -) Offene_Fenster_Erkennung -) LCD Display (min 2 Zeilig) Das vorhandene Display wird entfernt, die Batterieentnahmeerkennung ebenso, Anschluss für eine RS232 Schnittstelle und 29-7 IO-lines sind vorhanden. Hat jemand für ein Sende/Empfangsmodul einen Treiber geschrieben? Grüsse Robert
Mark T. schrieb: > Die sich auf das Lösen von vier Torx-7 Schrauben beschränkt.. Die Bilder sind gut! > Ich verstehe allerdings nicht, warum sie den 'Encoder' nicht symmetrisch > gemacht haben. Muss man nicht, da es genügt, eine Flanke zu sehen, um zu wissen wie weit das Rad gedreht hat. Die alten Zahnräder der alten Zeros hatten lediglich einen Spiegelpunkt mit 3mm Durchmesser, der war weitaus schlechter zu erfassen, da er sehr schnell an der Lichtschranke vorbei war und die Pulse somit extrem kurz waren. Hier hat man weitaus länger Zeit, da die Reflektionsflächen geschätzte 8mm lang sind. R. Freitag schrieb: > Eine Zentrale sollte auf der gleichen Hardware laufen. R. Freitag schrieb: > Das vorhandene Display wird entfernt, die Batterieentnahmeerkennung > ebenso, Anschluss für eine RS232 Schnittstelle und 29-7 IO-lines sind > vorhanden. Warum denn das? Das schränkt die möglichen Fähigkeiten sehr stark ein. Eine Zentrale sollte auch deutlich mehr können, als ein popeliger Stellantrieb. Da dürfte das Flash und vor allem das RAM sehr schnell knapp werden. R. Freitag schrieb: > Hat jemand für ein Sende/Empfangsmodul einen Treiber geschrieben? ???
Knut Ballhause schrieb: > Warum denn das? Das schränkt die möglichen Fähigkeiten sehr stark ein. > Eine Zentrale sollte auch deutlich mehr können, als ein popeliger > Stellantrieb. Da dürfte das Flash und vor allem das RAM sehr schnell > knapp werden. Wir haben 16 K. Wir brauchen: -) Treiber LCD Display -) Treiber Sende/Empfangsmodul (Funkmodule) -) Schnittstelle zum PC per RS232 oder Ethernet -) Eingaben: einige Digitaster und evtl den Drehgeber. Aufgaben der Zentrale wären nur das Weitergeben von Sollwerten an die Satelliten und das Empfangen von Temperaturen durch die Temperaturmodule und die Heizungswerte, die Zentrale soll dann die gesammelten Werte an den PC weitergeben, der dann die Berechnung der Vorgabewerte übernimmt. Gruss Robert
Moin, um mal kurz auf die Kommentare einzugehen: a) Motor-sensor: tolle Arbeit :) Kann man dann sicher gut verwerten. Auch bin ich froh, dass das Einlesen einfach über den Pin Change geht, ohne ADC. Das ist schön einfach. b) Das "Wir" das ich zu meinem/unseren Projekt schrieb bezieht sich auf einen Freund von mir und mich. "Wir" verwirklichen das wie bereits hier zitiert und im anderen Thread von mir geschrieben, dabei sind mir andere Anforderungen egal :) Wir verwerten jeglichen Code den wir in die Finger kriegen, sofern frei verfügbar bzw. für den Zweck zur Verfügung gestellt. Anforderung ist auch hier die Steuerung einer Vaillant Gastherme, entweder über 3-4 oder besser 7-8-9, um wenigstens die Brennerleistung etwas zu drosseln, da die Anlage für unsere kleine Wohnung maßlos überdimensioniert ist und somit bei Wärmeabnahme an nur einer Stelle sehr schnell hohe Vorlauftemperaturen erreicht und dann abschaltet (so schnell, dass das Beheizen des 2. Zimmers alleine nicht möglich ist). Pumpen etc. werden wir nicht steuern, aber sicherlich ist die Hardware flexibel genug, dass das von jedermann nachgerüstet werden kann. Display etc. brauchen wir (erstmal) nicht, Eingabe soll a) per Webinterface, b) notdürftig an den Thermostaten und c) per Android App erfolgen und wird auch in dieser Reihenfolge implementiert. Danach kann man immernoch über ein Display an der "Basis" nachdenken. Gruß, Matthias
Matthias Larisch schrieb: > Display etc. brauchen wir (erstmal) nicht, Eingabe soll a) per > Webinterface Sollte tatsächlich reichen, auch wenn ich kein smartphone als UI habe. Allerdings habe ich kein USB am Router, so dass für ein eigenständiger Server interessant wäre. Lässt sich ja alles dranbasteln. Aber nochmal meine Frage von oben: gibt es noch weiteren Quellcode von Leopold (er hat einige Schnipsel zur Displayansteuerung im anderen Thread gepostet)? Anderes Thema: die von Knut gebaute Adapterplatine für das RFM Funkmodul (Beitrag "Re: Preisgünstiger Heizungsregler bei Praktiker") passt nicht mehr. Man kann aber bei den ISP oder JTAG Pads im rechten Winkel eine etwa 2x2 cm große Leiterplatte unterbringen und kann etwas in die andere Gehäusehälfte ragen.
Angehängte Dateien:
-
usb_mini-b.jpg
180 KB
Eine Frage zum USB-Verbinder: unter dem sichtbaren Stück Spritzguss ist mit Sicherheit der für USB nicht genutzte Kontakt und eine Feile kann ihn freilegen? Sonst zerlege ich den Stecker ganz und gehe direkt ans Ende vom Steckkontakt. Das wiederum geht bestimmt auch direkt aus 1 mm FR4...
Mark T. schrieb: > Eine Frage zum USB-Verbinder: unter dem sichtbaren Stück Spritzguss ist > mit Sicherheit der für USB nicht genutzte Kontakt und eine Feile kann > ihn freilegen? Ja. Das ist bei allen mir bisher untergekommenen Steckern so. Der Kontakt ist aber sehr kurz und fein. Fädeldraht ≤0.2mm ist da Pflicht. Eine gute Idee ist es, den fertig angetüddelten Stecker mit Epoxy zu füllen, damit a) alle Drähte dran bleiben und b) die Kontaktzunge im Steckergehäuse bleibt. Mark T. schrieb: > Sonst zerlege ich den Stecker ganz und gehe direkt ans Ende vom > Steckkontakt. Das wiederum geht bestimmt auch direkt aus 1 mm FR4... Geht sicher, dauert aber länger. Zu achten ist hierbei auf die voreilenden Kontakte für GND und VBUS.
R. Freitag schrieb: > Aufgaben der Zentrale wären nur das Weitergeben von Sollwerten an die > Satelliten... Bei 64 Satelliten hättest Du gerade mal die Möglichkeit, 10..12Bytes pro Satellit im Speicher vorzuhalten (je nach Programmnutzung des SRAMs), wenn das reicht... >... und das Empfangen von Temperaturen durch die Temperaturmodule > und die Heizungswerte Dann bleiben nur noch 5..6 Bytes für Senden und Empfangen... > die Zentrale soll dann die gesammelten Werte an > den PC weitergeben, der dann die Berechnung der Vorgabewerte übernimmt. Willst Du die ganze Zeit einen PC mitlaufen lassen? Das kann doch ein ausreichend dimensionierter Controller viel eleganter und auch stromsparender.
Ich bin der Ansicht, dass das Userinterface ohnehin graphisch aufgebaut werden sollte, und auch mouseoperable sein soll. Das erzwingt die Verwendung von GUIs, zB Qt oder sowas. Dann kann aber die Auswertung der Daten auch auf dem PC laufen. Er speichert im Hintergrund die von der ZE gesendeten Daten, das soll so ca 1 mal pro Minute sein. Er kann eine Langzeitanalsys vornehmen und ist in der Lage, bestimmte Situationen nach vorgegebenen Kriterien zu erkennen. Betrachtet man das ganze Heizungsnetzwerk als Baum, dann sind die Messknoten und die Heizungsregler Leafelements, die ZE ist ein Gateway zwischen den Leafelements und dem PC. Die Datensammlung und der Transport finden per ZE statt, das UI wird vom PC bereitgestellt und der PC speichert auch Langzeitverläufe, um Informationen über die Regelstrecke zu gewinnen. Dies ermöglicht (mit Messsung der Aussentemperatur) auch die empirische Bestimmung von K-Werten. Erforderlich sind noch Windrichtung und -Stärke und die Aussentemperatur, sowie die Sonneneinstrahlung. Ich halte es für wenig sinnvoll, ein UI und eine Datenbankanwendung auf einem Controller zu schreiben. Ein Tablet oder Mininotebook reichen vollkommen. Grüsse Robert
OK, also aus der Geschichte um die oben beschriebene Zentrale halte ich mich ´raus.
Und was soll denn dann als ZE entwickelt werden?
Mittels Ohrstäbchen, Superkleber und 2x9mm Treibschrauben lassen sich die Comet und Zero2 wieder verschließen, wenn man sie aus Umbau- oder Reparaturgründen öffnen musste. Genaue Anleitung folgt, wenn der Kleber getrocknet und die Halbschalen erfolgreich verschraubt sind.
Angehängte Dateien:
-
usb_mini-b2.jpg
170 KB
Knut Ballhause schrieb: > Ohrstäbchen, Superkleber und 2x9mm Treibschrauben Clever (aka Wattestäbchen und Sekundenkleber). Anbei ein Foto von den 'runtergefeilten Innereien meines USB Steckers. Wie kommt man denn beim aktuellen Thermy (siehe meine Fotos) an die #RESET Leitung ran? Sonst kann ich mir das Löten ja sparen?
Das PCB meines Thermy scheint bis auf die zusätzliche Reflexlichtschranke sehr ähnlich dem Comet (http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#Comet_.2F_Thermy_2). Möglicherweise ist also auch auf dieser Rückseite ein Pad für #RESET. Aber ich weiß nicht, wie ich es 'um die Ecke' kontaktieren kann.
Mark T. schrieb: > Clever (aka Wattestäbchen und Sekundenkleber). Genau. Das Obergehäuse hat nach dem Öffnen durch abknipsen/ausbohren 4 Stäbe, 2 am Batteriefach und 2 in der Mitte des Gehäuses. Die Stäbe am Batteriefach werden entweder komplett entfernt, indem man sie mit einem Laubsägeblatt oder einer dünnen Schleifscheibe von den Trageteilen abtrennt. Die Trageteile müssen weitegend unversehrt bleiben, da an sie die Wattestäbchen geklebt werden. Zweite Moglichkeit ist es, nur 2/3 der Stäbe zu hinterschneiden und 1/3 der Trageteile nicht zu hinterschneiden und den Stab auf die Hälfte der Trageteillänge zu kürzen. Auf den verbleibenden Stummel und in die Schneidfuge werden die Wattestäbchen geklebt. Diese sind dann kurz über der Gehäuseoberkante abzuknipsen. Die beiden Stäbe in Gehäusemitte sind zurückzuschneiden auf etwa 4mm unterhalb der Gehäusekante. Der Haltesteg, an dem der Stab angeformt ist, wird weitere 4mm eingeschnitten und ausgeknipst, so dass wieder etwa 4mm freier Stab stehen bleiben. Auf diesen Stummel werden wiederum die Wattestäbchen geklebt. Auch diese beiden Stäbchen werden kurz über der Gehäusekante abgeknipst. Wenn der Kleber gut getrocknet ist, kann man die Schrauben vorsichtig eindrehen. Als Kleber habe ich übrigens ein Cyanacrylat-Gel benutzt, welches nach dem Abbinden noch etwas elastisch bleibt. Die Klebflächen der Wattestäbchen sollten mit einer feinen Feile oder Schmirgelpapier aufgerauht werden, um die Oberfläche zu vergrößern. Mark T. schrieb: > Anbei ein Foto von den 'runtergefeilten Innereien meines USB Steckers. Sieht gut aus. Mark T. schrieb: > Wie kommt man denn beim aktuellen Thermy (siehe meine Fotos) an die > #RESET Leitung ran? Sonst kann ich mir das Löten ja sparen? RESET ist immer als PAD auf der Topseite der Platine ausgeführt. Das Einfachste ist es, ein Loch mit 1.5mm Durchmesser 1.5mm über die USB-Buchse zu bohren, und zwar genau in der Mitte. Am Stecker muss dann ein leicht gebogener Federdraht mit ebenfalls 1.5mm Abstand zum Steckerblech angebracht werden, der fast so lang, wie der Stecker selbst ist. Beim Bohren unbedingt darauf achten, dass der Bohrer lediglich das Gehäuse durchstößt und nicht tiefer als 5mm eindringt, da sonst das LCD zerstört werden kann. Am Besten gelingt dies mit einem langsamlaufenden Akkuschrauber. Mark T. schrieb: > Das PCB meines Thermy scheint bis auf die zusätzliche > Reflexlichtschranke sehr ähnlich dem Comet Ist es auch.
Programmierstecker: Es gibt ja bereits eine detaillierte "Foto-Story" zum Thema Modifikation eines USB Mini-B Steckers: Beitrag "Re: Preisgünstiger Heizungsregler bei Praktiker". Leider hast du wohl recht und das Gehäuse muss bearbeitet werden. Alternativ könnte man den Resetkontakt zuerst einführen und dann den Stecker. Das ist doch eine Idee, die man auch mechanisch realisieren könnte. Hier nochmal der Link zum WIKI: http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate
Neuer Vorschlag für eine Zusatzplatine (RFM12) im Thermy mit Encoderrad: Eine Leiterplatte lässt sich am besten in der Ebene des Encoderrades unterbringen; zwischen Motor und Encoderrad, an der 'Trennwand' des Gehäusedeckels (rechtes Teil in thermy2.jpg aus Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"). Es steht praktisch der ganze Gehäusequerschnitt zur Verfügung und keine Stege oder Befestigungsteile geraten in den Weg. Egal welche Pads man nutzt, 4 davon lassen sich direkt durch Löten verbinden, wenn man eine zweiseitige Platine macht (und ich werde machen lassen, Bedarf: 8). Die anderen zwei werden dann aber fummelig. Federkontakte und eine Platine zum einklipsen wär natürlich schöner..
Angehängte Dateien:
-
USB_Reset.jpg
11 KB
Anbei die Modifikation der "USB"-Buchse zum Kontaktieren von 'RESET'. Links: Comet // Rechts: Thermy
Angehängte Dateien:
-
Stecker_Federdraht.jpg
20 KB -
Stecker_Federdraht1.jpg
15 KB -
Stecker_Federdraht2.jpg
22 KB -
Stecker_Federdraht3.jpg
29 KB
Und der verwendete Stecker.
Kleine Zwischenmeldung: Die Motoren laufen, die Lichtschranke wird erfasst und die Adaption auf verschiedene Ventilköpfe funktioniert. Die Erkennung läuft nach folgendem Prinzip ab: - Ventil komplett öffnen, Getriebe an Anschlag fahren und Getriebeposition auf 0x0000 setzen - Getriebe zufahren und Motorstrom im Freilauf messen und abspeichern - wenn Motorstrom nicht ansteigt, Vorgang nach 0x01A0 Positionen abbrechen - Wenn Motorstrom ansteigt und 10 Zählstufen über dem Freilauf liegt, Ventilposition speichern, dies ist die Berührungsposition 'Ventil offen' - Getriebe weiter zufahren, bis Motor stehen bleibt, Position abspeichern, dies ist die Position 'Ventil geschlossen' - Motor 10 Positionen zurückfahren, um Getriebe zu entlasten und Stopp Beim Programmieren habe ich festgestellt, dass der Thermy etwa 1/3 weniger Zählimpulse liefert, als der 2010er Comet. Den 2011er Comet habe ich noch nicht getestet.
Moin, Ich bin noch nicht ganz so weit. Wir werden die nRF24L01 Funkmodule einsetzen, um die Thermostate zu synchronisieren. Haben wir bei itead für 4$ gekauft, bei ebay gibts die auch für 2,10€. Mir stellt sich gerade ein Problem: Der SS Pin ist bei den ZeroV2 und Cometen der '+' bzw. Rotary Eingang. Wie stell ich das möglichst intelligent an, dass mir ein Tastendruck nicht das SPI in den Slave Mode versetzt? Meine "beste" Idee ist: Pin vor SPI Zugriffen als Ausgang mit Low Pegel festlegen. Zusätzlich muss der Pinchange Interrupt davor deaktiviert und danach wieder aktiviert werden, damit man nicht nen "Software-"Interrupt auslöst. Ausgang mit High-Pegel ist zu riskant, falls jemand die Taste in dem Moment drückt. Es ist ja nicht schlecht, dass quasi Multi-Master SPI unterstützt wird, aber dieses Feature ist hier doch etwas ungünstig. Übrigens habe ich Probleme, das Teil zu programmieren. Mein avrdude/usbprog findet es einfach nicht. Habe sowohl mal nen 800 Ohm Pullup an MISO gesetzt, damit die 2,8V ausreichen, als auch das Thermostat über die USB Buchse mit 5V versorgt (mit 30 Ohm in Reihe, ohne Batterien; In diesem Modus bleibt das Display dunkel, da wir quasi die Situation "Batterien entfernt" nachbauen, wo er nurnoch schnell die Uhrzeit sichert). Hatte jemand ähnliche Probleme? Reset funktioniert, außerdem hatte ich bei zu langsamem SPI Takt auch schon das Phänomen, dass das Thermostat eine PC Verbindung erkannt hat, im Display stand PC2. Alle Drähte sind zweifach nachgemessen und richtig angeschlossen.
Matthias Larisch schrieb: > Der SS Pin ist bei den ZeroV2 und Cometen der '+' bzw. Rotary Eingang. > Wie stell ich das möglichst intelligent an, dass mir ein Tastendruck > nicht das SPI in den Slave Mode versetzt? Verwende ein Software-SPI. Matthias Larisch schrieb: > Mein > avrdude/usbprog findet es einfach nicht. Borge oder kaufe Dir einen AVR-ISP mkII, ein STK500 oder einen Dragon. Die können das. Das mit den 5V ist mehr oder weniger Murks, da der Mega169PV nur bis maximal 4.5V spezifiziert ist und daher kaputt gehen könnte. Kleiner Zwischenstand: Manueller Modus läuft bei mir, das heißt, der Heizkörper wird auf die eingestellte Temperatur geregelt. Derzeit keine Timer, kein Menü, keine Extras.
Knut Ballhause schrieb: > Matthias Larisch schrieb: >> Der SS Pin ist bei den ZeroV2 und Cometen der '+' bzw. Rotary Eingang. >> Wie stell ich das möglichst intelligent an, dass mir ein Tastendruck >> nicht das SPI in den Slave Mode versetzt? > > Verwende ein Software-SPI. Hm, Mal schauen. Da finde ich es dann doch sinnvoller, den SS Pin extra zu behandeln. >> Matthias Larisch schrieb: > Das mit den 5V ist mehr oder weniger Murks, da der > Mega169PV nur bis maximal 4.5V spezifiziert ist und daher kaputt gehen > könnte. Diese Quelle finde ich nicht. Absolute Maximum Ratings sagen 6,0 V, Normal Operating Conditions geben 5,5 V an. Datenblatt ATmega169PV Rev. 8018P-AVR-08/10.
Angehängte Dateien:
-
brd.png
6 KB
Per Buchse geht es bei mir mit AVRISP bislang auch nicht, direkt an die Pads angelötet schon. Evtl. liegt es am Widerstand? Siehe Beitrag "Re: Preisgünstiger Heizungsregler bei Praktiker". @travelrec: Ich wollte entsprechend meines Vorschlages von weiter oben auf Basis deiner RFM12 Platine (Rev_01) etwas machen, was in meine Thermy passen würde (wie sieht es mit PLatz in den anderen Gehäusen aus?). Allerdings sagtest du, dass du mit den JTAG Signalen arbeiten wolltest - was ist dann mit !IRQ und !RES ? Anbei ein erster Entwurf - jedoch das RFM12 in SMD. Antenne möglichst unabhängig von der Frequenz, also einen passenden Draht anlöten, Chipantenne, oder eine fraktale Antenne mit auf's Board, für 434 und 868 MHz :-)
Matthias Larisch schrieb: >> Das mit den 5V ist mehr oder weniger Murks, da der >> Mega169PV nur bis maximal 4.5V spezifiziert ist und daher kaputt gehen >> könnte. > > Diese Quelle finde ich nicht. Absolute Maximum Ratings sagen 6,0 V, > Normal Operating Conditions geben 5,5 V an. Datenblatt ATmega169PV Rev. > 8018P-AVR-08/10. Hast Recht, der alte Mega169 ohne Suffix war nur bis 4.5V... Matthias Larisch schrieb: > Hm, Mal schauen. Da finde ich es dann doch sinnvoller, den SS Pin extra > zu behandeln. Musst Du wissen. Die ISP-Pins würde ich ohnehin nur ungern mit einem anderen Bauteil fest verdrahten, da es sonst zu Programmierproblemen kommen kann. Ich würde für einen direkten Einbau in das Gehäuse die 4 JTAG-Pins + Versorgungsspannung vorziehen. Mark T. schrieb: > Allerdings > sagtest du, dass du mit den JTAG Signalen arbeiten wolltest - was ist > dann mit !IRQ und !RES ? Braucht man für den grundsätzlichen Betrieb des RFM-12 nicht. Muss man zwar über SPI den Status pollen, aber es funktioniert. Mark T. schrieb: > (wie sieht es mit PLatz in den anderen Gehäusen aus?) Im Comet ist weit weniger Platz, nur unterhalb des Motors bis zur Platine, ich würde sagen 2.5cm x 4,5cm x 2cm. Denkbar wäre auch, das Funkmodul außen an die 'USB'-Buchse anzustecken und mit einem kleinen Extra-Controller (Tiny24 o.ä.) über die ISP-Pins anzusteuern. Das wäre dann ohne Eingriff in die Thermostaten möglich und würde auch mit anderen Steuer-/Bussystemen zusammenarbeiten.
Mark T. schrieb: > Per Buchse geht es bei mir mit AVRISP bislang auch nicht, direkt an die > Pads angelötet schon. Bei mir gehen alle per Buchse. Hast Du den Reset auf sicheren Kontakt überprüft? Hast Du den AVR-ISP mkII mit der Spannung des Thermostaten versorgt?
Hat irgendjemand außer mir den Zero V2? Ich habe die Befürchtung, dass das SPIEN Fuse deaktiviert ist. Ich bin nicht in der Lage, per SPI-ISP Programmer auf das Teil zuzugreifen...
Ach was, natürlich geht das... Mist :) Also: USB Pin am Rand ist auf Masse gelegt. Also der, neben dem mit normalen Kabel nicht erreichbare. Er sah auf der Platine so unbenutzt aus, dass wir den per Drahtbrücke mit dem SCK verbunden haben. So gings natürlich nicht. Auf den Fehler muss man erstmal kommen. Nun geht der SPI Mode einwandfrei. Ein einfacher Tip zum USB-Kabel basteln: Masse vom Schirm nehmen, der frei werdende Massepin nach Entfernen der äußeren "Plastik"-Zugentlastung und herausziehen des eigentlichen Plastik-Stecker-Inserts vorn am Kontakt so abbrechen/abdremeln, dass noch etwa 1 mm übrig bleibt. Dieser mm wird nun mit dem Nachbar Pin verbunden. So kontaktiert er den SCK- und nicht mehr den GND Pin und man braucht den Stecker nicht völlig zerfriemeln.
Matthias Larisch schrieb: > Er sah auf der Platine so unbenutzt aus, dass wir den per Drahtbrücke > mit dem SCK verbunden haben. So gings natürlich nicht. Auf den Fehler > muss man erstmal kommen. Laut Schaltplan ist die Belegung der Buchse eindeutig ;-)
Habt ihr den nRF24L01+ schon getestet? Ich komme nicht zuverlässig durch die Wohnung..
Getestet hab ich´s noch nicht, aber 2.4GHz haben es in bebautem Areal prinzipiell schwerer, als 866MHz oder 433MHz. Mit Klasse1 Bluetooth Modulen kommen wir durch 3 Wände oder 2 Decken, dann ist Ende. Hängt aber alles sehr vom verwendeten Baumaterial ab.
USB/GND/Schaltplan: Ich dachte, du hättest das einfach so da hin gelegt, quasi als "Nutze Schirm für GND". So hatten wir das irgendwie auch ausgemessen damals :) Naja, Pech gehabt. nRF24L01+: Nein, die sind noch nicht in Europa angekommen. Ich entwickele gerade noch am Protokoll, wir werden auf den ganzen Enhanced Shockburst Krams verzichten, um flexibel kommunizieren zu können. Auch ein einfaches Ack/Retransmission System wird dabei zum Einsatz kommen, das sollte damit dann zuverlässig funktionieren. Bei den Datenblatt-Werten sind mir allerdings auch schon Zweifel an der Tauglichkeit gekommen. Durch den 250 kBps Modus kannst du die Reichweite allerdings deutlich erhöhen, da die Empfängerempfindlichkeit um ~ 10 dB ansteigt. Im 1 MBps Modus hat man ungefähr 10-20 dB weniger erlaubte Streckendämpfung als bei typischem WLan, da die Sendeleistung so gering ist und die Empfangsempfindlichkeit nicht weltbewegend.
Matthias Larisch schrieb: > Bei den Datenblatt-Werten sind mir allerdings auch schon Zweifel an der > Tauglichkeit gekommen. Das stellt man leider immer nur in den folgenden Tests fest. Da aber gerade bei den Heizungsreglern eher wenig Daten übertragen werden, diese aber zuverlässig durch Wände und Decken müssen, ist das Subgigahertz-Band meiner Meinung nach besser geeignet. Die Tests mit dem RFM12B liefen zumindest ausreichend stabil, um alle Heizkörper eines Einfamilienhauses ohne Maschenstruktur, also mit einfacher Punkt-zu-Punkt-Verbindung zu erreichen.
Hast du schonmal erfolgreich den "Power-Loss" Interrupt getestet? Bei mir funktioniert er nicht.
1 | ISR(PCINT0_vect) |
2 | {
|
3 | displaySymbols(LCD_TOWER, LCD_TOWER); |
4 | /* emergency wakeup on power loss, motor step counter */
|
5 | if(POWERLOSS_PORTIN & (1 << POWERLOSS_PIN)) |
6 | sysShutdown(); |
7 | /* any other case is motor step */
|
8 | motorStep(); |
9 | }
|
10 | |
11 | void pwrInit(void) |
12 | {
|
13 | PRR = (1 << PRTIM1) | (1 << PRSPI); // | (1 << PRUSART0); // disable some hardware |
14 | set_sleep_mode(SLEEP_MODE_PWR_SAVE); |
15 | PCMSK0 |= (1 << PCINT0); /* emergency power loss IRQ */ |
16 | EIMSK |= (1 << PCIE0); |
17 | }
|
Natürlich wird die pwrInit() auch aufgerufen, testweise habe ich mal das USART nicht deaktiviert, falls da zufällig der IO Port auch mit ausgeht, hat aber auch nichts geholfen. Ich habe bisher noch nicht mit dem Multimeter geschaut, sondern einfach nur darauf gewartet, dass beim Herausnehmen der Batterien der Interrupt ausgelöst wird. Erkennen sollte ich das entweder am "Funk"-Symbol oder am Blanking des Displays (Das passiert derzeit in der Shutdown) - nichts davon passiert. Beim Motor-Step erscheint aber das Funk Symbol, d.h. der PinChange Interrupt tut grundsätzlich. Herausnehmen der Batterien führt nun nur dazu, dass nach etwa 10 Sekunden der Displayinhalt langsam verblasst :) Die Funktion ist zwar für mich irrelevant, aber es sollte ja eigentlich funktionieren?! An meiner ISP Beschaltung kanns nicht liegen, die hatte ich schonmal vollständig entfernt. Außerdem: In der Vorabversion die du mir geschickt hast hat sich ein Fehler bei den Display Segmenten eingeschlichen. Laut gängiger Interpretation hast du die Segmente für die Schrägstriche unten vertauscht, also k und m.
Hallo, gibt es denn eine "beta" Testversion der Comet Software ohne Funk aber mit Drehregler? Oder Source zum selber compilieren...
Matthias Larisch schrieb: > Hast du schonmal erfolgreich den "Power-Loss" Interrupt getestet? > Bei mir funktioniert er nicht. So weit bin ich noch nicht. Sleep habe ich eingebaut, Regelung geht, am Menü bin ich gerade bei, so dass man dann irgendwann auch mal ´was einstellen kann. Bin momentan leider etwas busy.... Matthias Larisch schrieb: > Laut gängiger Interpretation hast > du die Segmente für die Schrägstriche unten vertauscht, also k und m. Ich hab´s von der Skizze im Artikel übernommen, kann man aber sicher ändern... __ __ schrieb: > gibt es denn eine "beta" Testversion der Comet Software ohne Funk aber > mit Drehregler? Für Beta ist´s zu früh, ich würde eine Beta-Version posten, wenn alle Funktionen grundlegend laufen, so dass man das Gerät verwenden kann. Was brauchst Du denn genau? Der Drehgeber ist übrigens schon ziemlich schrottig, so dass die Firmware gut entprellen muss ;-)
Mit nur 250 kbit keine merkliche Verbesserung der Reichweite mit dem nRF24L01+ auf dem Standardkanal 2402 MHz :-(
@__ __ (unrouted) Für source war es schon immer zu früh, wie die Historie zum Thema zeigt. Im besten Fall darf man seine funktionierende Firmware mit einem neuen HexFile verflashen. Wie hies es sinn gemäß irgendwo weiter oben im früheren Thread: "wer ist schon so blöd seine Source ohne bezahlung zu veröffentlichen"
-- -- schrieb: > Für source war es schon immer zu früh, wie die Historie zum Thema zeigt. > Im besten Fall darf man seine funktionierende Firmware mit einem neuen > HexFile verflashen. Ich glaube, du verwechselst hier etwas. Wenn Du mit einer nicht voll funktionsfähigen Pre-Alpha etwas anfangen kannst, dann poste Deine e-Mail-Adresse oder schicke ´ne PM. PS: Lesen bildet. Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"
Knut Ballhause schrieb: > Was > brauchst Du denn genau? Na wenn sich der Heizungsregler adaptiert und auf eine konstante Temperatur regelt welche man z.B. über das Drehrad einstellt, dann ist das ja schon mehr als diese Geräte teilweise von selbst können.
__ __ schrieb: > Na wenn sich der Heizungsregler adaptiert und auf eine konstante > Temperatur regelt welche man z.B. über das Drehrad einstellt, dann ist > das ja schon mehr als diese Geräte teilweise von selbst können. Wie meinst Du das? Bislang können das alle käuflich zu erwerbenden Geräte. Die Probleme fangen eher da an, die Ventile auf längere Zeit zuverlässig zu fahren. Oder die Bedienung ist kompliziert oder nicht ausreichend.
wdress2011 Merry schrieb im Beitrag #2428063: > Hättest Du Bock, für das Projekt einen Artikel zu schreiben, in dem alle > Informationen ihren Platz finden und die entsprechenden Downloadlinks > zur Verfügung stehen würden? Guck mal, hat der Matthias schon längst gemacht ;-) http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate
Matthias Larisch schrieb: > Hast du schonmal erfolgreich den "Power-Loss" Interrupt getestet? > Bei mir funktioniert er nicht. Schalte mal die Steuerpins für die H-Brücke und E2 auf Eingang, wenn sie nicht gebraucht werden, dann sollte es funktionieren. Hab´s noch nicht probiert, mache ich aber noch :-).
Knut Ballhause schrieb: > Schalte mal die Steuerpins für die H-Brücke und E2 auf Eingang, wenn sie > nicht gebraucht werden, dann sollte es funktionieren. Jupp, geht!
Oh man :) Dankeschön, klappt hier nun auch.
Super! Ich habe das mal im Artikel ergänzt.
Hallo, seid ihr mit der Firmware und/oder der Basisstation schon weitergekommen?
Haben noch genügend anderes zu tun - demnach hier: nein. Heute Abend wird der Funk in Betrieb genommen, das Thermostat besitzt schon alle Hardwarefunktionen, die komplette Thermostatlogik fehlt aber noch (Ventilfahrt geht schon :) ). Eventuell stell ich morgen mal ein bisschen was bei Github rein, ich würde aber gerne vermeiden, dass der frühe, unfertige Code geforkt wird, weil da noch einiges passieren wird.
Danke für die Info.
Mal ne andere Frage: ist der Programmierstick und das Protokoll schon untersucht worden?
Von mir nicht.
So, nachdem hier scheinbar nicht viel passiert ist (keine Sorge, im Hintergrund wird fleißig entwickelt): Gestern habe ich bei uns im Aldi die Thermostate für 12€ gesehen. Da waren noch relativ viele da. Eventuell betrifft das ja noch mehr Aldis? Ich habe mir bei dem Preis nochmal eines mitgenommen - ist ja echt ein gutes Angebot. nRF24L01+ Anbindung kann man übrigens für größere Bauten vergessen, sofern man kein vermaschtes Netz aufbauen möchte - die Reichweite ist mit unserer 2 Zimmer Wohnung bereits erschöpft.
Frohe Weihnachten, liebe Mitleser, hier wird auch weiterentwickelt, die Menüsteuerung ist gerade in Arbeit, danach geht´s an die Timer. Bei den Versuchen am Heizkörper wurde der Regelalgorithmus angepasst. Auch bei diesen Reglern hat sich der interne Temperaturfühler als nachteilig erwiesen, da er einerseits durch die Anordnung hinter den Batterien sehr träge ist, andererseits der Luftstrom im Gerät sehr ungünstig verteilt ist, so dass der Heizkörper den Thermostaten direkt beeinflusst. Somit kommt es zu Überschwingern bei der Regelung, die eigentlich gar keine sind. Mit einem externen Sensor wird man daher eine viel genauere Regelung hinbekommen, bei weniger Regelaufwand durch den Thermostaten selbst.
Matthias Larisch schrieb: > nRF24L01+ Anbindung kann man übrigens für größere Bauten vergessen, Mit den RFM12 klappt das besser. Bei 1000 Baud komme ich mit dem 868Mhz-Modell und einer Platinenfaltantenne im Haus durch 3 Decken und/oder 3 Wände und auch bis in den entferntesten Winkel des Anbaus, was etwa 15m Luftlinie durch alle möglichen Baumaterialien entspricht. Im Freifeld, was aber für den Anwendungszweck eher unrealistisch ist, werden über 50m erreicht.
Angehängte Dateien:
-
progstick.JPG
1,5 MB
Servus, seit heute spiel ich mit dem Programmierstick rum (Das Foto is nicht besonders gelungen). Da ich nur Linux-Rechner besitze bin ich dran interessiert, selber ein Programm zur Verwaltung zu schreiben. Dazu nun etwas reverse engineering: Das original Programm speichert die Einstellungen in einer Datei mit dem hübschen Namen "________.___" im Hauptverzeichniss des 8MB großen Sticks ab, sie ist immer 0x800 Bytes groß. Wo diese dann im Flash des Comet abgelegt wird weiss ich nicht. Das Format hab ich hier mal im Pseudo-Code aufgelistet: http://tiki.seesslen.net/tiki-index.php?page=mase%3Aprojects%3Acometcrunch Die Struktur für die Datei ist "sCometCrunch". Vielleicht ist das auch für alternative Firmwares interessant, um sie kompatibel mit dem Stick zu halten. (Der große Atmel-Chip hat die Bezeichnung "ATMEL 0847", der kleinere "atmel 90USB162")
Maximilian Seesslen schrieb: > Der große Atmel-Chip hat die Bezeichnung "ATMEL 0847" Nö, der heißt AT45DB642D und ist ein 64MBit DataFlash. Es enthält die PC-Software und die Einstellungen. Der kleine MLF ist ein Tiny25.
Ich habe nur einige Beiträge überflogen und stellte fest, dass man sehr viel Arbeit in die Entwicklung elektronischer Komponenten gesteckt hat. Zunächst mal eine kurze Frage: Soll mit dem Thermostat und seinem Ventilunterteil eine Raumtemperatur geregelt werden? MfG
Wolfgang-G schrieb: > Ich habe nur einige Beiträge überflogen und stellte fest, dass man sehr > viel Arbeit in die Entwicklung elektronischer Komponenten gesteckt hat. > Zunächst mal eine kurze Frage: Soll mit dem Thermostat und seinem > Ventilunterteil eine Raumtemperatur geregelt werden? > MfG Ja! Das ist meiner Meinung nach auch eine sehr sinnvolle Anwendungsmöglichkeit :-)
>Ja! Das ist meiner Meinung nach auch eine sehr sinnvolle >Anwendungsmöglichkeit :-) Im Prinzip schon, aber schade um die viele Arbeit. Zu einem Regelkreis gehört mehr als nur die Elektronik. Knut Ballhause schrieb: >Somit kommt es zu Überschwingern bei der Regelung, ... Und ich behaupte, die Ursache liegt hauptsächlich am Ventilunterteil. Die Konstruktionen neuester Bauart sollen vorzugsweise den Einfluss von Fremdwärme berücksichtigen und schließen bei einem p-Bereich von 1K z. B schon nach 0,2mm. Eine REGELUNG im klassischen Sinn ist damit unmöglich. Leider wollen oder können sogar namhafte Ventilhersteller noch nicht einmal die Ventilkennlinie -Durchfluss-Stellweg- rausrücken. Solange es keine HeizungsREGELventile gibt, ist es m. E. für jede elektronische Weiterentwicklung zu schade um die Zeit. Klingt zwar hart, aber so sehe ich es. MfG
Wolfgang-G schrieb: > Und ich behaupte, die Ursache liegt hauptsächlich am Ventilunterteil. Recht haste, aber wenn die Firmware erstmal halbwegs funktioniert, wird man die Regelparameter einstellen und somit auf das Unterteil anpassen können - so der Plan. Bei meinen Tests habe ich festgestellt, dass 0815-Unterteile aus´m Baumarkt bestens funktionieren. Je teurer die Teile werden (Fachhandel), desto "digitaler" arbeiten sie und desto mistiger ist das Regelverhalten. Da ich beide Varianten im Haus verbaut habe, kann ich mit verschiedenen Regelparametern testen.
Wolfgang-G schrieb: > Zu einem Regelkreis > gehört mehr als nur die Elektronik. In der Tat. Aber mit der Firmware kann man schon eine ganze Menge ´rausholen, wenn man weiß, was man programmieren soll, also wie die Regelschleife sich unter verschiedenen Umständen verhält.
Knut Ballhause schrieb: >aber wenn die Firmware erstmal halbwegs funktioniert, wird >man die Regelparameter einstellen und somit auf das Unterteil anpassen >können - so der Plan. Bei meinen Tests habe ich festgestellt, dass >0815-Unterteile aus´m Baumarkt bestens funktionieren. Mit meinem Beitrag wollte ich nur mal den Blick dafür schärfen, dass bei schlechtem Regelverhalten das Ventilunterteil eine nicht zu unterschätzende Rolle spielen kann. Auch mit bester Elektronik lassen sich mechanische "Fehlkonstruktionen" nicht beheben. An Baumarkt hatte ich noch gar nicht gedacht. Gibt es zu dem Ventil (0815-Unterteile) die Ventilkennlinie -Durchfluss in Abhängigkeit des Stellweges bei konstantem Differenzdruck- ? MfG
Wolfgang-G schrieb: > Gibt es zu dem Ventil > (0815-Unterteile) die Ventilkennlinie -Durchfluss in Abhängigkeit des > Stellweges bei konstantem Differenzdruck- ? Nein, das vielleicht nicht, aber die Ventile von Danfoss und Heimeier, die dort für um 12EUR verkauft werden, haben ein recht weiches Schließverhalten, so dass der Regler einen weiten Steuerbereich hat. Das hat gegenüber einem Ventil, welches von eben auf gleich komplett auf oder zu macht, eindeutig Vorteile. Da die Regelschleife aber geschlossen ist, spielt der Ventiluntersatz nur diejenige Rolle, dass der Algorithmus auf dieses Ventil abgestimmt werden muss. Ein Algorithmus für alle Ventile funktioniert vielleicht nur ausreichend, aber nicht optimal. Auch nicht zu vergessen ist der Einfluss einer schwankenden Vorlauftemperatur bei kleinen oder nur auf Teillast laufenden Anlagen, die das Regeln zusätzlich erschwert.
Knut Ballhause:
>aber die Ventile von Danfoss ...
diese Ventile wurden 2008 bei uns im Rahmen der "Modernisierung der
Heizungsanlage" in unserem 90 WE Wohnblock verbaut. Da fing der Ärger
erst richtig an. Zunächst lausig kalt und die Thermostatventile zeigten,
wenn nicht gerade voll aufgedreht, Zweipunktregelverhalten. Leider war
es nicht möglich, die Ventilkennlinie aufzutreiben, sodass ich zunächst
nur Mutmaßen kann. Was ich gesehen habe, ist ein Ventilteller an Stelle
eines Ventilkegels, wie er normalerweise bei Regelventilen üblich ist.
Also Prinzip Wasserhahn wie im Garten.
MfG
Wolfgang-G schrieb: > diese Ventile wurden 2008 bei uns im Rahmen der "Modernisierung der > Heizungsanlage" in unserem 90 WE Wohnblock verbaut. Da fing der Ärger > erst richtig an. Wolfgang-G schrieb: > Zunächst lausig kalt und die Thermostatventile zeigten, > wenn nicht gerade voll aufgedreht, Zweipunktregelverhalten. Dann scheint/schien es verschiedene Modelle zu geben. Meine hier haben eine Durchflusssteuerschraube und funktionieren hervorragend. Seit 2000... Wolfgang-G schrieb: > ist ein Ventilteller an Stelle > eines Ventilkegels ??? Hast Du mal ein Foto?
Meine sehen so aus: http://eis.i-net-hosting.de:8080/erez4/cache/heimundbad_zubehoer_heizkorper_RA-N_013G0034_02_tif_be370be128dc1807.jpg
Foto habe ich nicht, aber ein Datenblatt. Auf der Schnittzeichnung (bei mir S.9) ist der Ventilteller gut zu erkennen MfG
Also vom mechanischen Aufbau sind die Teile mit meinen identisch und sollte eigentlich gut funktionieren. Wenn Du den Druckstift manuell mit z.B. einer Münze eindrückst, solltest Du den Wasserzufluss im letzten Drittel des Stellweges "weich" abriegeln können, erkennbar am stetig abnehmenden Fließgeräusch.
>Wenn Du den Druckstift manuell mit z.B. einer Münze eindrückst, solltest Du >den Wasserzufluss im letzten Drittel des Stellweges "weich" abriegeln >können, erkennbar am stetig abnehmenden Fließgeräusch. Das ist mir zu ungenau. Normalerweise sollte der Hersteller die oben genannte Ventilkennlinie liefern. Die Kennlinie sollte eine Exponentialfunktion sein, deren Krümmung der eines Heizkörpers entgegengesetzt ist. Im Idealfall wäre die Resultierende aus beiden Kurven eine Gerade. Das ist regelungstechnisch der Idealfall. Aus einem Heiztechnikforum musste ich mir allerdings erklären lassen, dass heute ein Thermostatventil nur noch bei Fremdwärme schließen soll. Damit reicht dann auch ein Ventilteller. Deshalb sagte ich: Schade um die Zeit. Oder man findet doch das richtige Ventilunterteil. MfG
Wolfgang-G schrieb: > Das ist mir zu ungenau. Für die Genauigkeit sorgt doch der Regler. Oder nicht?! Ob das Ventilunterteil einen Teller oder einen Schließkegel oder sonst einen Mechanismus hat, ist letztenendes doch völlig egal, da man so oder so die Durchlaufgeschwindigkeit des Wassers mehr oder weniger stark beeinflusst. Diese Beeinflussung wird über den Regelalgorithmus, also den gefahrenen Weg pro Temperaturdifferenz angepasst und alles wird gut. Wolfgang-G schrieb: > Die Kennlinie sollte eine > Exponentialfunktion sein, deren Krümmung der eines Heizkörpers > entgegengesetzt ist. Im Idealfall wäre die Resultierende aus beiden > Kurven eine Gerade. Das ist regelungstechnisch der Idealfall. Für den Anwender bedeutet dies ein wenig Probieren und Verändern der Parameter, aber irgendwann hat man, was man braucht.
>Für den Anwender bedeutet dies ein wenig Probieren und Verändern der >Parameter, aber irgendwann hat man, was man braucht. Probieren muss nicht unbedingt sein, wenn Hintergrundwissen vorhanden ist. Und das wollte ich mit meinen Ausführungen teilweise vermitteln. Du nimmst doch bestimmt auch gleich ein log Poti als Lautstärkeregler, weil Dir bekannt ist, dass dann die Lautstärke proportional dem Drehwinkel ist. Da muss man nicht probieren. Mit ungenau meinte ich: >erkennbar am stetig abnehmenden Fließgeräusch. Da kannst Du auch gleich eine Glaskugel nehmen. Auch ein Bastler sollte so exakt wie möglich arbeiten. MfG
Junge, was willst Du eigentlich? Willst Du zur Entwicklung beitragen oder einfach nur ´rummosern, bevor Du überhaupt getestet hast, ob und wie die Regler arbeiten?! Mit den alten Zeros habe ich meine Hausanlage seit nunmehr 2 Jahren am Laufen und die Regelung gefällt mir ausserordentlich gut, mal von ein paar konstruktiven Macken (lautes Getriebe...) der Regler selbst abgesehen. Wolfgang-G schrieb: > Probieren muss nicht unbedingt sein, wenn Hintergrundwissen vorhanden > ist. Wolfgang-G schrieb: > Da kannst Du auch gleich eine Glaskugel nehmen. Auch ein Bastler sollte > so exakt wie möglich arbeiten. Selten solchen Quatsch gelesen. Das Probieren ist es, was den Bastler an seinem Projekt wachsen lässt. Aber wenn bei Dir in Theorie schon alles läuft, dann ist es schön für Dich. Vielleicht magst Du uns Deine Erkenntnisse in einem eigenen Thread mitteilen.
Servus, ich hab die comets jetzt scho a paar Wochen am laufen (derzeit 3 Zimmer). Sind ja schon nett... (original Firmware, nicht herausgeführte Temperaturfühler) Mir ist aufgefallen, dass ich bis zu 6°C Offset habe. Ansich ja nicht so schlimm, dazu hat man die Option des "Offsets" ja. Aber 6°C Offset sind schon ne Hausnummer. Im anderen Zimmer sind das "nur" 3°C, Zimmer ähnlich groß. Also die dumme Frage ob ihr aehnlich Erfahrung habt/Entwickler was wissen: *Toleranzen des Temperaturmessers (6°C?) *Toleranzen des Comet als Ganzen (Luftdurchzug, was auch immer) *Rausführung des Temperatursensors/-wiederstands sinnvoll *Einzelfall wegen meinen beschissenen Fenstern Ich kann mir derzeit keine Fussbodenheizung mit an den Wänden verteilten Thermostaten leisten ;D . Die Regelung der Comets an Heizkörpern als Kompromiss empfinde ich sehr angenehm. Macht eine Ermittlung des Offsets je Zimmer über (Laptop-)Software mit angeschlossenem Themperaturmessgerät Sinn (Langzeitmessung) oder ist dies aufgrund zu vieler Ausenfaktoren zu beschränkt sinnvoll (Ausentemperatur etc.)? Es geht mir dabei u.A. um die Alternativsoftware für den Programmierstick. Gruss, mase
mase schrieb: > *Toleranzen des Temperaturmessers (6°C?) Vernachlässigbar. mase schrieb: > *Toleranzen des Comet als Ganzen (Luftdurchzug, was auch immer) Toleranzen nicht, eher Trägheit. mase schrieb: > *Rausführung des Temperatursensors/-wiederstands sinnvoll Ja. Muss man aber nicht unbedingt. mase schrieb: > *Einzelfall wegen meinen beschissenen Fenstern Durchaus möglich. Es hängt sehr viel davon ab, wie der Heizkörper seine Wärme an das Zimmer abgibt, wie groß der Heizkörper ist und ob er irgendwie verbaut ist. Der Sparmatic misst die Temperatur in seiner unmittelbaren Nähe und das ist eben nicht zwingend die Zimmertemperatur. mase schrieb: > Macht eine Ermittlung des Offsets je Zimmer über (Laptop-)Software mit > angeschlossenem Themperaturmessgerät Sinn (Langzeitmessung) Ja. Damit hat man halbwegs verlässliche Werte, wenn die Außentemperaturen nicht zu stark in den Keller gehen. Dann nämlich wird die Vorlauftemperatur höher und die Außenwände kühler, was zu einer weiteren Verzerrung der Messung und dem tatsächlichen Wert im Zimmer führt.
Den Zero v2 gibt es derzeit im Kaufland für 14,99€ Hab mir heute mal 2 mitgenommen.
Knut Ballhause schrieb: >Junge, was willst Du eigentlich? Willst Du zur Entwicklung beitragen >oder einfach nur ´rummosern, bevor Du überhaupt getestet hast,... >Selten solchen Quatsch gelesen. Das Probieren ist es, was den Bastler an >seinem Projekt wachsen lässt. Aber wenn bei Dir in Theorie schon alles >läuft, dann ist es schön für Dich. Vielleicht magst Du uns Deine >Erkenntnisse in einem eigenen Thread mitteilen. Wenn meine Hinweise so angekommen sind, dann muss ich schlussfolgern, dass Du sie nicht verstanden hast. Diesmal sage ich: Schade um meine Zeit. Trotzdem viel Erfolg beim Probieren. MfG
moin moin, hab mir auch ein paar Thermy (Aldi) zugelegt, einen hab ich mal 'geopfert' und ein paar hochaufloesende Bilder gemacht. Vorsicht Bilder sind gut 600kb gross, falls einer noch mit 33.6K Modem unterwegs ist ;) , aber man soll ja was erkennen .... Positiv Ueberrascht hat mich der recht leise Antrieb (im vergleich zu den anderen Stellantrieben die ich hier habe) ich habe noch kein ISP kabel daher die Frage: kann man die Software auslesen ?, und was fuer Quarz sitzt da auf der LP, i vermute ein 32.768 khz f. die Uhr und der µC rennt mit dem internen RC, oder ? Passt das Schaltbild von ganz oben? @Knut du hast ja schon recht viel gemacht mit dem Teil, gibt da irgendwelche sources von dir ? vlG Charly
Charly B. schrieb: > Positiv Ueberrascht hat mich der recht leise Antrieb (im vergleich > zu den anderen Stellantrieben die ich hier habe) Ja, die Thermys sind bedeutend leiser, als die Sparmatic Comet von 2010 und 2011. Entweder, die haben noch andere Getriebebestandteile eingebaut, oder einfach mal etwas Fett verwendet ;-) Charly B. schrieb: > ich habe noch kein ISP kabel daher die Frage: kann man die Software > auslesen ?, Nein. Charly B. schrieb: > und was fuer Quarz sitzt da auf der LP, i vermute > ein 32.768 khz f. die Uhr und der µC rennt mit dem internen RC, > oder ? Korrekt. Charly B. schrieb: > Passt das Schaltbild von ganz oben? Nein nicht ganz, das zweitobere passt: Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Charly B. schrieb: > @Knut > du hast ja schon recht viel gemacht mit dem Teil, gibt da > irgendwelche sources von dir ? Ja gibt es. Da ich nicht fertig bin, kann ich Dir ´was per e-Mail schicken, sende mir mal eine PM.
Hi, >Entweder, die haben noch andere Getriebebestandteile eingebaut, >oder einfach mal etwas Fett verwendet ;-) das Ritzel auf der Motorwelle ist bei meinem Aldi-Gerät aus Gummi. Lasst kein Fett oder Kriechöl rankommen, sonst rutscht die ganze Sache durch!!! Falls doch passiert, Gummi und Welle mit Alkohol reinigen und den Schaft des Ritzel mit ein bisschen dünnem Draht umwickeln und verdrilen, und so auf die Welle pressen. Grüße, Alex
Alex schrieb: > das Ritzel auf der Motorwelle ist bei meinem Aldi-Gerät aus Gummi. Das erklärt natürlich einiges. Alex schrieb: > Lasst > kein Fett oder Kriechöl rankommen, sonst rutscht die ganze Sache > durch!!! OK, gut zu wissen ;-). Die Sparmatics sind doch etwas laut ohne Fett.
Huch, hier ist ja noch einiges passiert :) Unser Projekt liegt leider doch etwas auf Eis, aber "theoretisch" läuft die reine Thermostatsoftware soweit, allerdings derzeit ohne besondere Programmierfähigkeit etc., da das eigentlich der Einfachheit halber hauptsächlich über Funk gemacht werden soll (und das ist noch nicht fertig :) ). Die Sourcen sind noch nicht wirklich veröffentlichbar, zumal da auch noch einiges nicht wirklich funktioniert. Ich kanns ja trotzdem nachher mal hochladen, da ich im moment wirklich nichts daran mache. Der im Thermostat verbaute Temperatursensor ist ein Witz. Total träge das Teil! Eine deutliche Verbesserung dürfte mit einem abgesetzt montierten Raumtemperaturfühler erzielbar sein (welcher dann natürlich auch mit dem Thermostat kommunizieren können muss). Optimalerweise hat man zusätzlich noch Heizkörpertemperatur, Vorlauftemperatur sowie aktuellen Durchfluss träum.
Matthias Larisch schrieb: > Der im Thermostat verbaute Temperatursensor ist ein Witz. Total träge > das Teil! Naja, das liegt aber weniger am Sensor, als an dessen Verbau hinter den Batterien und vollflächig auf der Platine. Somit hat die Umgebung des Sensors eine enorme Wärmetragfähigkeit. Den Sensor an der Unterkane des Gehäuses hinter einer Ventilationöffnung zu verbauen, wäre cleverer gewesen. Nicht zuletzt deswegen habe ich den PID-Regler über den Haufen geschmissen und bin an einer adaptiven Regelung dran, ist aber ebenfalls noch nicht fertig.
Hm, bei mir hat sich natürlich mal wieder nichts getan. PID ist Schwachsinn, ja. PI wohl eher nicht. Allerdings ist mir noch etwas aufgefallen: Habe so ein Teil "original" im Betrieb (sogar nen Cometen, keinen Zero). Durch den I-Anteil mag das Teil meine Raumthermostat geregelte Gasheizung garnicht, der powert jedes mal voll auf, da der I-Anteil in der Aus-Phase der Heizung natürlich nach oben läuft. Da hat der gute alte Bimetall-P-Regler besser funktioniert und sitzt nun auch wieder dran (Natürlich rede ich nicht vom Zimmer, in dem das Raumthermostat hängt, sondern von den anderen Räumen). Ansonsten: Ab Montag gibts den Comet/ Zero bei Marktkauf fürn Zehner, falls den noch jemand sucht. Bewertungen bei Amazon sind übrigens desaströs, kann ich gewissermaßen nachvollziehen, das meiste bezieht sich allerdings auf die Originalfirmware.
Matthias Larisch schrieb: > PID ist Schwachsinn, ja. PI wohl eher nicht. So oder so nicht ganz einfach. Problem: Das Erfassen der Pulse der Lichtschranke funktioniert nicht zuverlässig, da sich das Getriebe durch die relativ geringe Übersetzung nach Abschalten des Motors wohl etwas verstellt. Im Ungünstigsten Fall genau an der Stelle, wo die Reflexmarke liegt. Dadurch verliert oder gewinnt man Pulse und die absoluten Positionen verrutschen, was tödlich ist für einen PI(D)-Regler. Das kann auch durch das wöchentliche Adaptieren nicht wirklich gerettet werden, da es schon nach 3 Tagen nicht mehr passt. Fazit: bei der originalen Firmware bleiben die Heizkörper irgendwann warm, auch wenn die Solltemperatur erreicht ist. Mit einer Regelung, die Relativpositionen anfährt, kann das nicht passieren. Diese passt sich immer an die aktuellen Gegebenheiten an, ist also adaptiv. Sie kann auch die Trägheit des Temperaturfühlers in gewissen Grenzen ausgleichen. Allerdings hat dies auch so seine Tücken und ich versuche gerade, den Algorithmus zu optimieren, da er bei Extremwerten (Fenster auf/zu, Vorlauftemperaturschwankungen) zum Überschwingen neigt. Aber ich denke, das ist nur eine Frage der Zeit. An sich funktioniert es mit +-0.7°C schon ganz gut. Matthias Larisch schrieb: > Bewertungen bei Amazon sind übrigens desaströs, kann ich gewissermaßen > nachvollziehen, Ich auch. Aber man kann es in den Griff bekommen. Es hängt alles von der Regelung ab. Ansonsten sind die Teile schon nicht schlecht, was die Mechanik und die Ausstattung angeht.
Hier gibt es noch eine OpenSource Version in C von einem holländischem Kollegen: https://github.com/wjroes/OpenZero
Hervorragende Arbeit! Grund für mich mein Haus mit Cometen auszustatten :)
Wer sich überlegt die Sparmatic zuzulegen um sie selber zu programmieren sollte das demnächst tun. Aus gut unterrichteten Kreisen ist zu hören das der µC demnächst durch was anderes (kein Atmel mehr!) ersetzt wird.
Es gibt hierzulande keine gut unterrichteten Kreise mehr. Diese PISA-Studie belegt das eindeutig. Das Nachfolgemodell basiert übrigens auf nem Quadcore A9 mit Android 4. Sagt zumindest unser örtlicher Asia-Imbiß. Der ist Chinese und muß das wissen.
Wieso? Kommt dann jemand vorbei und baut die 20 Stk. hier um? :)
Sollten tatsächlich keine AVRs mehr verbaut werden, schießt sich der Hersteller selbst in´s Knie. Dann kann nämlich keiner mehr die verbugte Firmware ändern und dann kauft die Dinger auch keiner mehr oder nur noch die, die´s nicht besser wissen...
@Knut: Kurze Frage, wie hast Du das mit der Kommunikation zwischen Thermostat und Raumtemperatursensor gelöst? Die Empfänger sind ja nicht aktiv, oder?
Die Empfänger werden 1x pro Minute für eine halbe Sekunde aktiviert. Kommt ein Signal vom Raumfühler, wird es ausgewertet und ggf. übernommen, kommt keins, wird das Funkmodul wieder deaktiviert. Nach dem Batteriewechsel bleibt das Funkmodul bis zum Eintreffen des ersten neuen Signals dauerhaft auf Empfang. Das ist aber wohl noch nicht die endgültige Lösung.
>Dann kann nämlich keiner mehr die verbugte Firmware ändern und dann kauft >die Dinger auch keiner mehr oder nur noch die, >> die´s nicht besser wissen... und dazu gehören bestimmt 99,9% der Käufer MfG
Knut Ballhause schrieb: > Das ist aber wohl noch nicht die endgültige Lösung. D.h. Du synchronisierst dann das 1-Minuten Intervall auf den Raumthermostat. Hast Du einen Fallback auf den internen Sensor drin, falls das Ventil nichts empfängt? Da ich zusätzlich zu Raumfühler und Ventil noch eine Zentrale mit Anbindung an den Heizkessel implementiere, bin ich noch am Rätseln wie ich die Kommunikation untereinander gestalte. Ob alles über die Zentrale läuft oder Raumfühler direkt mit Ventil redet. Über die Zentrale könnte jeder Sensor zu seinen Wachzeiten senden kann und kurz darauf etwas von der Zentrale empfangen. Würde zumindest die Synchronisation der Komponenten vereinfachen. Irgendwie fehlt mir da gerade noch die zündende Idee.
Horst schrieb: > Hast Du einen Fallback auf den internen Sensor drin, > falls das Ventil nichts empfängt? Nein, noch nicht. Horst schrieb: > Ob alles über die Zentrale > läuft oder Raumfühler direkt mit Ventil redet. Ich würde es so machen: Der Raumfühler steuert das Ventil und die Zentrale tauscht Daten mit den Raumfühlern aus. Auf die Weise kann man Adressen- und Protokollwust vorbeugen. Der Raumfühler kann dann auch eine bessere (größere) Antenne bekommen, die mehr Reichweite zur Zentrale hat. Und die Zentrale braucht sich nur mit 5...10 Raumfühlern zu unterhalten und nicht mit 20 oder mehr Ventilen. Horst schrieb: > Über die Zentrale könnte jeder Sensor zu seinen Wachzeiten senden kann > und kurz darauf etwas von der Zentrale empfangen. Würde zumindest die > Synchronisation der Komponenten vereinfachen. Irgendwie fehlt mir da > gerade noch die zündende Idee. Ventile müssten eingentlich nur empfangen können oder maximal einen kurzen Status senden. Die Raumfühler müssen flexibler sein, dürften aber aus Batterielaufzeitgründen auch immer nur kurz aktiv werden. Die Zentralle pollt die einzelnen Räume je nach ihrer Aktivzeit durch und verteilt die Aktivzeiten gegebenenfalls neu. Die Verbindung Zentrale/Raumfühler und Raumfühler/Ventil könnte auf verschiedenen Trägerfrequenzen ablaufen, damit sich beide Kanäle nicht in´s Gehege kommen. Dadurch har man mehr Freiheiten, wenn sehr viele Geräte in einem Haus in Betrieb sind. Bei sehr großen Häusern sollte man außerdem über ein vermaschtes Netz nachdenken...
Ich habe mich mit den RFM12 noch nicht so im Detail auseinandergesetzt, d.h. man kann diese zur Laufzeit auf eine andere Frequenz einstellen? Wäre natürlich eine Möglichkeit, je nachdem wieviele Kanäle man im 868er Band unterbringen kann. Der Begriff Zentrale ist in meiner Idee vielleicht etwas verwirrend. Für mich ist die Zentrale zunächst mal der Punkt an dem die Informationen der Räume zusammenlaufen und an die Heizungssteuerung weitergegeben werden. Die Heizungssteuerung errechnet dann aus diesen Informationen den Wärmebedarf und regelt Vorlauf und Kessel entsprechend. Die Bedienung sollte aufgrund des WAF über die Ventile erfolgen, da wir auch Räume haben die nur selten genutzt werden und dann sozusagen Adhoc geheizt werden können. Ebenso möchte ich einen zusätzlichen Raumfühler nur in großen Räumen nutzen, die auch mehrere Heizkörper haben. Hier wäre dann ein Ventil der Master und die anderen Ventile Slaves. Daher wäre für mich der Raumfühler nur eine zusätzliche Regelinformation für die Ventile. Grundsätzlich bevorzuge ich autarke Ventile, die auch bei Ausfall der Funkverbindung selbständig weiterarbeiten. Folgende Idee: Raumfühler und Ventile versuchen alle x Minuten zu senden. Dabei erfolgt zunächst ein Carrier Sense. Ist der Funkkanal frei wird gesendet und die Zentrale hat dann die Möglichkeit in einem kleinen Zeitfenster zu antworten. Ist der Funkkanal belegt, wird eine zufällige Zeit gewartet und dann erneut versucht zu senden. Auf diese Weise müssten sich alle Sender dann mehr oder weniger in ihrem Raster verteilen, oder? Ein Vorteil hat der Sommer: Man kann testen ohne den Hausfrieden zu stören ;)
Horst schrieb: > Ich habe mich mit den RFM12 noch nicht so im Detail auseinandergesetzt, > d.h. man kann diese zur Laufzeit auf eine andere Frequenz einstellen? > Wäre natürlich eine Möglichkeit, je nachdem wieviele Kanäle man im 868er > Band unterbringen kann. Sicher kann man das :-). Man braucht ja nur 2 Frequenzen. Man muss nur im zugelassenen Bereich für die verwendete Leistung bleiben und die Kanalbelegung auf <=1% halten oder vor dem Senden Kanalfreiheit prüfen. Horst schrieb: > Der Begriff Zentrale ist in meiner Idee vielleicht etwas verwirrend. Für > mich ist die Zentrale zunächst mal der Punkt an dem die Informationen > der Räume zusammenlaufen und an die Heizungssteuerung weitergegeben > werden. Die Heizungssteuerung errechnet dann aus diesen Informationen > den Wärmebedarf und regelt Vorlauf und Kessel entsprechend. Zentrale ist Zentrale... Da man an keine herstellerischen Gegebenheiten gebunden ist, hat man doch alle protokollarische Freiheit. Horst schrieb: > Die Bedienung sollte aufgrund des WAF über die Ventile erfolgen, da wir > auch Räume haben die nur selten genutzt werden und dann sozusagen Adhoc > geheizt werden können. Ich weiß, was Du meinst! Horst schrieb: > Hier > wäre dann ein Ventil der Master und die anderen Ventile Slaves. Daher > wäre für mich der Raumfühler nur eine zusätzliche Regelinformation für > die Ventile. Grundsätzlich bevorzuge ich autarke Ventile, die auch bei > Ausfall der Funkverbindung selbständig weiterarbeiten. Die Ventile können trotzdem funktechnisch Slaves sein. Alles andere würde wahrscheinlich zu viel Strom benötigen. Horst schrieb: > Folgende Idee: Raumfühler und Ventile versuchen alle x Minuten zu > senden. Dabei erfolgt zunächst ein Carrier Sense. Ist der Funkkanal frei > wird gesendet und die Zentrale hat dann die Möglichkeit in einem kleinen > Zeitfenster zu antworten. Ist der Funkkanal belegt, wird eine zufällige > Zeit gewartet und dann erneut versucht zu senden. Auf diese Weise > müssten sich alle Sender dann mehr oder weniger in ihrem Raster > verteilen, oder? Geht grundsätzlich, aber erfordert im Fall der Kanalbelegung viel Stromverbrauch durch die erneuten Versuche, der mit der Anzahl der Geräte innerhalb des Netzes steigt. So viel Reserve haben die Ventile mit ihren 2 Mignon-Zellen da nicht. Wird ein Telegramm aufgrund von Kanalbelegung aufgeschoben, setzt sich das für alle nachfolgenden Telegramme fort. Im Fall von Firmwarelaufzeiten kann es dann auch passieren, dass mehrere Ventile gerade Kanalfreiheit feststellen und wild durcheinander senden. Der nächste Sendeversuch schlägt dann möglicherweise auch fehl, weil dann wieder ein paar Ventile meinen, dass es jetzt klappen könnte und wieder durcheinander senden. Irgendwann funktioniert dann vielleicht mal ein Telegramm.
Knut Ballhause schrieb: > Die Ventile können trotzdem funktechnisch Slaves sein. Alles andere > würde wahrscheinlich zu viel Strom benötigen. Da steh ich irgendwie gedanklich auf dem Schlauch :) Ich hab eine Zentrale (Dauerversorgung), mehrere Ventile (Batterie) und ggf. noch ein paar Raumfühler (Batterie). Du meinst also, dass die Zentrale als Master das Zeitraster auf die Slaves verteilt? Dann fehlt mir immer noch die Idee wie Raumfühler und Ventil direkt miteinander reden. Oder läuft das dann auch über die Zentrale? Nicht nur funktechnisch, auch gedanklich noch ein großes Durcheinander. Knut Ballhause schrieb: > Geht grundsätzlich, aber erfordert im Fall der Kanalbelegung viel > Stromverbrauch durch die erneuten Versuche, der mit der Anzahl der > Geräte innerhalb des Netzes steigt. Wenn das Sendeintervall eines Ventils/Fühlers 5 Minuten beträgt und ich im Falle einer Kanalbelegung dieses um jeweils ~15 Sekunden verschiebe, die Intervalldauer aber gleich lasse, müssten die sich doch irgendwie automatisch im Zeitraster einordnen? Mein Wunsch ist es, dass alle Funkkomponenten sich automatisch aufsynchronisieren ohne manuellen Anlernprozeß.
Horst schrieb: > Knut Ballhause schrieb: >> Die Ventile können trotzdem funktechnisch Slaves sein. Alles andere >> würde wahrscheinlich zu viel Strom benötigen. > > Da steh ich irgendwie gedanklich auf dem Schlauch :) > > Ich hab eine Zentrale (Dauerversorgung), mehrere Ventile (Batterie) und > ggf. noch ein paar Raumfühler (Batterie). Du meinst also, dass die > Zentrale als Master das Zeitraster auf die Slaves verteilt? Dann fehlt > mir immer noch die Idee wie Raumfühler und Ventil direkt miteinander > reden. Oder läuft das dann auch über die Zentrale? Nicht nur > funktechnisch, auch gedanklich noch ein großes Durcheinander. Die Zentrale hat Dauerstrom. Daher kann sie stetig auf Empfang sein und die Frequenzen auf Belegung kontrollieren. Sie allein verteilt die Timeslots für die Übertragung. Wenn die Anzahl der zu steuernden Geräte und das Haus nicht zu groß sind, kann die Zentrale alle Daten von Ventilen und Raumfühlern einsammeln und bearbeiten und die modifizierten Daten zurückschicken. Ein Telegramm könnte Dann wie folgt aussehen: Zentrale sendet: Adresse->Code->Kommando->Daten (CRC) Gerät antwortet: Adresse->Code->Daten (CRC) Bei sehr vielen Geräten wird vielleicht das Priorisieren des Netzes notwendig. Hauptaugenmerk ist dabei immer ein möglichst niedriger Stromverbrauch, also auch wenig Rechenaufwand in den batteriegetriebenen Geräten. Sonst ist es mit dem WAF bald ganz schnell vorbei ;-). Selbst bei guten Batterien/Akkus kann die Laufzeit sehr kurz werden, wenn der Controller andauernd Protokolle prüfen und berechnen und immer auf der Lauer nach eintreffenden Meldungen liegen muss. > > Knut Ballhause schrieb: >> Geht grundsätzlich, aber erfordert im Fall der Kanalbelegung viel >> Stromverbrauch durch die erneuten Versuche, der mit der Anzahl der >> Geräte innerhalb des Netzes steigt. > > Wenn das Sendeintervall eines Ventils/Fühlers 5 Minuten beträgt und ich > im Falle einer Kanalbelegung dieses um jeweils ~15 Sekunden verschiebe, > die Intervalldauer aber gleich lasse, müssten die sich doch irgendwie > automatisch im Zeitraster einordnen? > > Mein Wunsch ist es, dass alle Funkkomponenten sich automatisch > aufsynchronisieren ohne manuellen Anlernprozeß. Ganz ohne Anlernprozess wird es nicht gehen. Bei jedem neu anzumeldenden Gerät wirst Du mindestens mal eine Taste drücken müssen, um es zur Anmeldung freizuschalten. Ansonsten kann es passieren, dass Du bei fünf Geräten die Batterien einlegst und die dann alle auf einen Anmeldeversuch der Zentrale hin antworten. Da keines der Geräte eine eindeutige Adresse hat oder das Herausfinden dieser Adresse über Ausschlussverfahren viel zu lange dauern würde, musst Du die Anmeldung eines Gerätes zu einer Zeit erlauben. Nach erfolgreicher Anmeldung reiht sich dieses Gerät in´s System ein und Du kannst ein anderes anmelden.
Knut Ballhause schrieb: > Hauptaugenmerk ist dabei immer ein möglichst niedriger > Stromverbrauch, also auch wenig Rechenaufwand in den batteriegetriebenen > Geräten. Sonst ist es mit dem WAF bald ganz schnell vorbei ;-). Ja, aber dafür ist im Regler schon ein WAF-Cheat drin. Ab einer Temperaturgrenze wird eine gewünschte Solltemperatur oberhalb nur noch über die Isttemperaturanzeige simuliert ;) Knut Ballhause schrieb: > Ganz ohne Anlernprozess wird es nicht gehen. Bei jedem neu anzumeldenden > Gerät wirst Du mindestens mal eine Taste drücken müssen, um es zur > Anmeldung freizuschalten. Ja, denke ich auch. Das Funkprotokoll wird wohl noch das kniffeligste. Und die Herstellung des ISP-Steckers. Würde eigentlich so eine kleine Solarzelle wie sie in Taschenrechnern usw. zu finden ist, nicht ausreichen, die Batterielaufzeit zu verlängern?
Horst schrieb: > Würde eigentlich so eine kleine Solarzelle wie sie in Taschenrechnern > usw. zu finden ist, nicht ausreichen, die Batterielaufzeit zu > verlängern? Wenn die Sonne direkt auf das Ventil brüllt, dann ja ;-), sonst eher nicht.
Kennt jemand eine Bezugsquelle für einen passenden MiniUSB-Stecker bei dem die Kontakte alle herausgeführt sind? Hab schon 5 Stecker/Kabel seziert aber bei keinem war der 5. Kontakt irgendwie erreichbar. Oder kennt noch jemand eine 6 pol. Alternative als Ersatz für die MiniUSB Buchse?
Guten Abend, Für welche "Version" ist die C Portation denn nun gedacht ? Funktioniert sie mit den leisen Thermys ? Eine Anbindung eines RFM12 würde mir in der C Version wesentlich leichter fallen. Daher die Frage.. Vielen Dank schonmal für die super Arbeit ! Grüße
Ich war gestern im Aldi und habe mir mal so ein "THERMy" Gerät mitgenommen. Das ist die 2. Verson mit dem verstärkten Gehäuse, dem Gummiritzel und der besseren IR-Reflex-Lichtschranke. Gekostet hat es nur 6,00 Euro ! Ich nutze oft die NRF24L01+ Module und werde auch mal eins mit einem Flachbandkabel an das Thermostat anlöten. (da gehen ja 7 Pins vom Chip auf ein paar Pads, ebenso VDD und GND) Ein mini-USB-Kabel habe ich mir noch nicht besorgt. (da ich die SPI-Pins eh raus lege brauche ich es aber auch nicht so dringend) Frage in die Runde: - Welche Firmware habt ihr für euer Projekt verwendet? - Hat jemand eine GUI gebastelt? Das wäre ganz gut, da man so die Zeiten/Intervalle von allen Thermostaten am Laptop einfach einstellen kann und dann sollten sie auch gleich über Funk aktualisiert werden. Die Geräte per SPI (USB-Kabel) zu Updaten ist auch eine Option, aber angesichts der NRF24L01+ Module für 1.56 Euro (im 10er Pack) ist diese Option schon sehr verlockend. Welche Sprache wird hier bevorzugt? C# oder Java?
Dennis Henning schrieb: > Eine Anbindung eines RFM12 würde mir in der C Version wesentlich > leichter fallen. Dann nimm doch die C-Version, die ist eine brauchbare Basis für eigene Weiterentwicklungen
Daher ja die Frage ob die C Portation für die Aldi Thermy's geeignet ist bzw. darauf lauffähig ist. Grüße
I have created a new version of the firmware specifically for the Aldi Thermy. There are some hardware differences between Aldi's and the one Knut has made firmware for. It is using an Atmel 169PA for instance. The code I have written so far is still very rudimentary. It allows you you control the buttons, set a temperature, set the time, not much else so far. I also wrote the code for communication with a RFM12 add-on so you can send commands over the air from a laptop for instance. One of the things I need to tackle is the optical sensor. It does not seem to work on my Thermy. I need to hook it up directly to a scope to see what's going on. Although I think you can manage without one since it does detect fully-open and fully-closed state. Willem
Hi Willem, have you managed to get the reflex coupler working meanwhile? It´s getting colder outside ;-)
Man kann auch ohne Optokoppler regeln. Je nach Reglerabweichung steuere den Motor immer nur für einen kurzen Moment an und öffne oder schließe das Ventil damit ein Stückchen. Die beiden Endpunkte erkenne ich anhand des Stromanstiegs. Funktioniert im Test soweit ganz gut, mal sehen wie das im Winter wird.
Hi Knut, You're right it is getting colder so I should get back to it. The last thing I did was soldering some wires to the reflex coupler. I hooked it up and even then I could not get it to work. I can do without it but I was nice if it worked. Now I am just measuring current to see if I've reached either end. I had the wireless board working but then it started to get warmer so I dropped it. Anyway I will need to pick it up again at some point now. How 'bout you? Willem
Thomas R. schrieb: > Man kann auch ohne Optokoppler regeln. Je nach Reglerabweichung steuere > den Motor immer nur für einen kurzen Moment an und öffne oder schließe > das Ventil damit ein Stückchen. Die beiden Endpunkte erkenne ich anhand > des Stromanstiegs. Funktioniert im Test soweit ganz gut, mal sehen wie > das im Winter wird. Geht grundsätzlich, verschlechtert aber die Reglereigenschaften. Abhängig von Getriebestatus, Batteriefüllung und Motortoleranz ergibt sich ein stets variierender Stellweg, was das System überschwingen lässt oder zu träge macht, je nachdem.
Willem, you have my mail address. If you like, you can post your measurements and the setup you made with the opto coupler, so we may set the thing up correctly in the firmware to get it working.
Knut Ballhause schrieb: > Willem, > > you have my mail address. If you like, you can post your measurements > and the setup you made with the opto coupler, so we may set the thing up > correctly in the firmware to get it working. Hi Knut, Thanks I would be interested in that. Funny thing is I hooked the reflex up with a LED in series and a pull-up on the other side. LED was working but not a reaction whatsoever. But I will try again and then come back and consult you. I have been working on an ignition module for engines and the Raspberry Pi the last half year so I did not get around to the Thermy :) Willem
Knut Ballhause schrieb: > Geht grundsätzlich, verschlechtert aber die Reglereigenschaften. > Abhängig von Getriebestatus, Batteriefüllung und Motortoleranz ergibt > sich ein stets variierender Stellweg, was das System überschwingen lässt > oder zu träge macht, je nachdem. Wie hast Du die Regelung gelöst? Der Fühler ist ja relativ träge und einigen Störgrößen ausgesetzt und das Getriebe, so wie Du schreibst, ist nicht gerade positionssicher. Am Heizungsmischer habe ich das gleiche Prinzip als Regelung (P-Regler auf I-Stellglied) realisiert, dort habe ich auch keine absolute Mischerposition, aber es funktioniert nach etwas Parameteroptimierung. Richtig testen kann ich es erst in der Heizperiode.
Im alten Thread tauchte die Frage auf: Wolfgang-G schrieb: > ohne alles lesen zu müssen: war der Originalregler ein P-, PI- oder > PID-regler?
Thomas R. schrieb: > Wie hast Du die Regelung gelöst? Die momentane Regelung ist eine Art Vorahnungsregelung, die die Temperaturdifferenz dreier Messungen in Relation zur Solltemperatur vergleicht und demzufolge bestimmte Ventilwege fährt, um zu kompensieren. Das geht momentan recht gut, aber ich sammle noch Erfahrungen. Die absolute Ventilposition spielt hierbei keine Rolle. Die Regelung ist bei schnellen Wechseln (Schalten von Komfort in Absenk-Modus und umgekehrt, bzw. Fenster/Tür offen) aber noch etwas träge. Da muss ich bestimmt nochmal ´ran...
Knut Ballhause schrieb: > Die momentane Regelung ist eine Art Vorahnungsregelung, die die > Temperaturdifferenz dreier Messungen in Relation zur Solltemperatur > vergleicht und demzufolge bestimmte Ventilwege fährt, um zu > kompensieren. Interessanter Ansatz! Ich habe versuchsweise einen Dreipunktregler mit PT1-Rückführung implementiert, aber im Moment muss ich noch warten bis es kalt genug zum Heizen ist :-) Was ich leider noch nicht testen konnte ist der direkte Temperatureinfluss des Heizkörpers.
Habe übrigens heute noch ein paar weitere Comet bekommen, diese sind nun nicht mehr zugeschmolzen, sondern mit einer kleinen Schraube (Kopf Torx-7) verschraubt. Sehr angenehm!
Jörg Wunsch schrieb: > nun nicht mehr zugeschmolzen, sondern mit einer kleinen Schraube > (Kopf Torx-7) verschraubt. Na super!!! Wo hast´n die her?!
Knut Ballhause schrieb: >> nun nicht mehr zugeschmolzen, sondern mit einer kleinen Schraube >> (Kopf Torx-7) verschraubt. > > Na super!!! Wo hast´n die her?! Rossmann (Versandhandel) verscherbelt sie derzeit für EUR 16. Die ersten drei, die wir gekauft hatten, waren noch zugeschmolzen, aber die nachgekauften jetzt haben Schrauben. Allerdings musste ich mir das T-7-Bit am Hals ziemlich dünn schleifen, damit es noch in die tiefe Bohrung der Gehäuseschale reinpasst.
Jörg Wunsch schrieb: > Allerdings musste ich mir das T-7-Bit am Hals ziemlich dünn schleifen, > damit es noch in die tiefe Bohrung der Gehäuseschale reinpasst. Klingt abenteuerlich. Brille aufgehabt? ;-) Jörg Wunsch schrieb: > Die > ersten drei, die wir gekauft hatten, waren noch zugeschmolzen, aber > die nachgekauften jetzt haben Schrauben. Vielleicht lesen die Entwickler von Sparmatic hier mit und denken, dass sie mehr Comet-Regler verkaufen könnten, wenn die outgesourceten Programmierer besser an die Hardware herankommen. ;-)
Knut Ballhause schrieb: > Jörg Wunsch schrieb: >> Allerdings musste ich mir das T-7-Bit am Hals ziemlich dünn schleifen, >> damit es noch in die tiefe Bohrung der Gehäuseschale reinpasst. > > Klingt abenteuerlich. Brille aufgehabt? ;-) Ja klar, am Schleifbock hängt eine Schutzbrille daneben. Man muss ja auch Vorbild für die Kinder sein. Es lässt sich schlecht zu anderen Arbeitsschutz predigen, wenn man sich dann selbst nicht dran hält ... > Vielleicht lesen die Entwickler von Sparmatic hier mit und denken, dass > sie mehr Comet-Regler verkaufen könnten, wenn die outgesourceten > Programmierer besser an die Hardware herankommen. ;-) Dann hätten sie den Firlefanz mit der JTAGEN-Fuse aber auch sein lassen können. Der ist flüssiger als ein Glas Wasser: solange OCDEN nicht gesetzt ist, kann man über JTAG trotzdem maximal einen chip erase absetzen, man hätte sich nur gespart, zuvor noch ISP benutzen zu müssen (um JTAGEN wieder zu setzen).
Jeder Programmierer denkt halt anders... oder auch nicht.
Knut Ballhause schrieb: > Vielleicht lesen die Entwickler von Sparmatic hier mit und denken, dass > sie mehr Comet-Regler verkaufen könnten, wenn die outgesourceten > Programmierer besser an die Hardware herankommen. ;-) Dann würden sie wohl kaum den AVR rauswerfen...
Knut Ballhause schrieb: > Temoc schrieb: >> Dann würden sie wohl kaum den AVR rauswerfen.. > > Wie jetzt? Weiter oben hatte doch jemand das Gerücht gestreut, dass die nächste Version nicht mehr mit einem AVR daher käme.
Ah ja. Na mal sehen...
Knut Ballhause schrieb: > Vielleicht lesen die Entwickler von Sparmatic hier mit und denken, dass > sie mehr Comet-Regler verkaufen könnten, wenn die outgesourceten > Programmierer besser an die Hardware herankommen. ;-) Wenn ich mir das recht ansehe, kratzt Rossmann offenbar gerade die letzten Lagerbestände aus den Ecken zusammen. Was wir da bekommen haben, scheinen also eher die ersten Seriengeräte der Comet zu sein denn irgendwelche neuren Modelle. Dadurch sind wir nun zu den verschraubten gekommen. ;-)
Hi Willem, are you going to publish your new/current code as a branch on https://github.com/wjroes/OpenZero ? I have added the link to the wiki page http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate Evtl. ist auch Mathias Larisch schon mit seiner Software weiter? Sollte das Projekt veroeffntlicht werden? Ich habe naemlich auch einen Haufen Thermys und wuerde etwas Arbeit beisteuern, Richtung Funk/Zeitsteuerung in C oder zur Zentrale - evtl. kann man Kraefte buendeln? Es wird sehr bald kalt und ich moechte nicht immer durch die Wohnung rennen und Heizkoerper umschalten muessen (Gasheizung) .. komme aber leider erst am Wochenende dazu, mich wieder etwas einzulesen.
Ich werde gelegentlich auch weiterproggen, ist fest eingeplant. In meinen Code muss ich mich dann auch wieder einlesen ;-)
Kann leider kein AVRASM - evtl. kann man sich auf Schnittstellen einigen, dann ist die Implementierung egal.
Vielleicht sollten sich ein paar "willige" Programmierer einfach zu einer kleinen Heizungsregler-Community zusammenschließen, das würde meiner Meinung nach zu schnellen und ausgereiften Ergebnissen führen. Natürlich müssten dann alle Ideen und Codeschnipsel zentral verwaltet werden - eine Aufgabe, die ich leider nicht erledigen kann. Megathreads hier im Forum sind zwar ein toller Anfang, aber auf die Dauer auch sehr anstrengend.
Naja, ich habe TravelRecs Code, wobei ich mir noch nicht völlig sicher bin, ob ich bis zum Letzten durch 5000 Zeilen Assembler durchsteigen möchte ;-), aber zumindest ist sein derzeitiger Code wohl als einziger bislang "aus der Dose raus" benutzbar. Dann hat mir Matthias Larisch seinen C-Code gegeben, an dem er aber schon lange nichts mehr getan hat. Da funktionieren laut seiner Aussage nur die Grundfunktionen. Was man auf jeden Fall mal gut abstrahieren muss, ist die Anbindung irgendwelcher Funkmodule. TravelRec hat RFM12 direkt angesteuert, Matthias hat nRF24L01, ich möchte abgesetzte ATmega128RFA1-Platinen benutzen (weil ich mich damit am besten auskenne, und weil ich sie auch gern standalone als abgesetzten Tempertursensor und als "Fenster offen"-Sensor benutzen möchte). Vermutlich werde ich meine Ventile erstmal mit TravelRecs Code 1:1 versehen und dann lange Winterabende benutzen um zu sehen, was man am besten weitermacht. Für eine Kooperation können wir ja den SVN-Server hier auf mikrocontroller.net benutzen, wenn mehr als einer an einem Projekt mitarbeiten möchte. Aber ich glaube, so weit, dass man da wirklich was koordinieren kann, sind wir noch nicht.
Ja, erstmal Ziele sammeln, dann Schnittstellen definieren. SVN ist OK, oder so wie Willem bei einem GIT host (da ist teilweise wohl auch Forum, Wiki und Issue Tracker dabei). Wenn Willem 'weiter' ist als Matthias und zudem noch aktiv, dürfen wir evtl. auf seinem Code aufbauen. Ich habe den Code aber noch nicht angeschaut.
Es sind ja doch einige an einer Firmware interessiert (und offenbar auch fleissig: Thomas R., Horst ?) Kannst du, dl8dtl, Matthias L. mal fragen, ob du seinen Code zugaenglich machen kannst? Ich vermute, dass er noch etwas mehr low-level Funktionen implementiert hat als Willem (schreibt er ja selbst). Jedenfalls waere eine Bestandsaufnahme hilfreich. Eine Mischung der beiden Arbeiten koennte dann die Grundlage fuer eine gemeinsame Entwicklung werden.
mark t schrieb: > Kannst du, dl8dtl, Matthias L. mal fragen, ob du seinen Code zugaenglich > machen kannst? Geht sicher, aber ich würde das für den Anfang gern auch überschaubar halten. Wenn du da mitmachen willst, meld' dich an (damit es eine einzige Identität pro Person gibt) und frag' ihn doch selbst. Sowie dann irgendwas Substanzielles da ist, mit dem man weitermachen kann, kann man damit ein SVN aufsetzen. (Github mag ich nicht so.) Solange aber außer TravelRec niemand aktiv was macht, muss man auch nicht irgendwelche Infrastrukturen aus dem Boden stampfen, Schnitt- stellen definieren oder sonstwas. Am Ende verbringen wir dann die Zeit nur noch in Meetings zur gegenseitigen Abstimmung. :-)
Gibt es eigentlich Erfahrungen mit der Batterielebensdauer? TravelRecs Firmware unterstützt ja den Betrieb mit NiMH-Akkus. Für die Geräte werden original 5 Jahre Batterielebensdauer propagiert. Falls diese 5 Jahre auch nur annähernd erreicht werden (selbst, wenn's nur 3 Jahre sind), würden sich aber Akkus nicht lohnen. Selbst die besseren Akkus sind dann per Selbstentladung schon breit, und die höheren Kosten würden sich über solch einen langen Zeitraum auch nicht amortisieren.
Die propagierten 5 Jahre können mit der originalen Firmware gar nicht erreicht werden. Dafür agiert sie viel zu oft und hat ein paar weitere Macken, die Strom kosten. Ich hatte für ein paar Wochen einen originalen Comet nur mal zum Testen und zum Vergleichen an einem Heizkörper. Der Motor lief mindestens 1x pro Minute ein kurzes Stück, die Regelung war also ständig aktiv. Zudem braucht der Controller selber ständig um die 20µA im Sleep mit LCD an und und die Batterieherausnahmefunktion ebenfalls nochmal 5µA. Die PullUps für den Drehgeber sind auch ständig an. Das heißt, wenn die Geberkontakte gegen Masse geschlossen sind, fließt auch noch der PullUp-Strom. Ich würde also nicht so viel auf schöngerechnete Werbung geben. Wenn man die Regler dann noch mit Funk ausrüstet, kommen noch ein paar 10µA effektiv und ständig hinzu. Da ich auf dem Display wechselnde Anzeigen wie Zeit und Isttemperatur habe, ist der Controller auch öfter kurz mal wach. Für mich lohnen sich Akkus ohnehin, da ich ein Rotationsprinzip für die Zellen in verschiedensten Applikationen anwende. Da ich die Akkus mit Solarstrom lade, hat das für mich auch noch eine ideellen Wert ;-)
Knut Ballhause schrieb: > Ich würde also nicht so viel auf > schöngerechnete Werbung geben. Mir erschien der Wert ja auch sehr reichlich, daher hatte ich nach Erfahrungen gefragt. Wie lange halten die Akkus so bei dir?
Mindestens die volle Heizperiode bei den Zeros mit Funk. Mit den Comets habe ich noch nicht die Langzeiterfahrung, da auch das Prog noch nicht fertig ist...
Von Matthias habe ich ("mark t") bislang nichts gehört, daher habe ich
mir Willems Code vorgeknöpft und will auch erstmal versuchen, den
optischen Sensor zum Laufen zu bringen, sowie die Batterie zu überwachen
(Spannung und Ausfall).
Ich werde pushen, wenn das funktioniert, also hoffentlich Sonntag.
Nun also zu Willems code: Willem R. schrieb: > I have created a new version of the firmware specifically for the Aldi > Thermy. There are some hardware differences between Aldi's and the one > Knut has made firmware for. It is using an Atmel 169PA for instance. > The code I have written so far is still very rudimentary. It allows you > you control the buttons, set a temperature, set the time, not much else > so far. > I also wrote the code for communication with a RFM12 add-on so you can > send commands over the air from a laptop for instance. > One of the things I need to tackle is the optical sensor. It does not > seem to work on my Thermy. I need to hook it up directly to a scope to > see what's going on. Although I think you can manage without one since > it does detect fully-open and fully-closed state. (Der RFM-Code ist noch nicht im repository https://github.com/wjroes/OpenZero, und offenbar noch nicht für Thermy, da der Encoder zwei Schritte pro Rast erkennt) Vorneweg, ich habe nur THERMy (=="therµ"?). Ich hab daher eine Config.h erstellt, in der über #defines die Hardware bestimmt werden könnte. Das lässt sich aber sicher noch geschickter anstellen. - Der Interrupt für den optischen Sensor läuft, wenn der interne Pull-Up Widerstand ausgeschaltet ist (sicherheitshalber habe ich auch den zweiten Pin am Fotosensor auf High-Z geschaltet.) Es werden bei der Initialisierungsfahrt nun die Endlagen bestimmt. Mit dem Schrittzähler wird das Auseinanderfallen des Antriebs nun verhindert (500 Impulse als Limit). Es gibt eine simple, blockierende Funktion zum ungeregelten Anfahren einer Position ohne Stromüberwachung. - Die Batterie/Akkuspannung kann gemessen werden (1/100V). Da steckt aber wohl noch ein Fehler drin. Bitte mal reinschauen, ich komme nicht drauf. - Der Stromausfall wird detektiert, aber daraufhin noch nicht viel gemacht (Teile vom AVR werden abgeschaltet). Achtung: ich habe im LCD Interrupt einige Dinge auskommentiert, damit Debug-Ausgaben nicht gleich wieder überschrieben werden. Ansonsten habe ich Kommentare hinzugefügt (auch Funktionsinfo im doxygen-Format). Sobald man sich mit dem Code etwas auskennt erscheinen sie natürlich trivial, aber für den Einstieg sind sie meiner Ansicht nach hilfreich. Ausserdem habe ich etwas "aufgeräumt" - Willem, ich hoffe, das ist so OK: svn history entfernt, Module verschoben, leere Module erstellt. Als Starthilfe zum Einlesen: Das Programm basiert auf mehreren "state machines", die bei Tastendruck und in den ADC- und LCD-Interrupts abgearbeitet werden. Interrupts sind in der Main.c, die Tastenbehandlung habe ich nach UI/Menu/Menu.c ausgelagert. Das Programm führt eine Initialisierung durch und wechselt dann in den Standby-Modus. Willem hatte eine An/Aus Regelung geschrieben, die ich nach Control/Control.c verschoben und dort auskommentiert habe, da mir immer der Antrieb auseinanderfiel. Man kann dann etwas im Menü navigieren und z.B. die Zeit stellen - allerdings klappt das mit meinem Thermy nicht, da der rotary encoder alle 2 Schritte rastet und auch nicht besonders zuverlässig erkannt wird. Willem ist da wohl noch dran und wollte das über Interrupts lösen (es gibt gute Algorithmen von Peter Danneger in der Codesammlung, auch zum Tastenentprellen). Aber mal eine Frage: Honeywell HR20 nutzt auch ATmega169(P..)! Thread: http://embdev.net/topic/118781 Beschreibung HR20 http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/doc/Analyse%20HR20.pdf?revision=366 Protokoll http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/doc/protkoll/Basis_Protokoll.pdf?revision=366 Ähnliche Hardware und offenbar alles schon implementiert - gab es schon mal Anstrengungen, das anzupassen, bzw. die Sparmatic Hardware dort zu integrieren? Wenn nein, wieso nicht? :-) Wie dem auch sei, meine Änderungen sind unter https://github.com/gnbl/OpenZero abgelegt (man kann die Daten auch runterladen, wenn man nicht bei github angemeldet ist). Speicher ist ca. 50 % leer.
http://embdev.net/topic/118781#1553458 > The code of openhr20 contains various ifdefs "thermotronic". its > activated in the makefile. I believe that is for "sparmatic basic" http://openhr20.svn.sourceforge.net/viewvc/openhr20/rfmsrc/ Dann war meine Arbeit ja umsonst! Wieso sagt mir das keiner :-) Allerdings ist offenbar die Doku bei den Kollegen ziemlich hinterher.
Moin! Ich habe gerade mal ein bisschen Zeit im Zug verwendet, um eure Einträge hier zu lesen :) Selbstverständlich habe ich kein Problem damit, meinen Code zur Verfügung zu stellen. Jörg hat von mir schon den kompletten Projektordner erhalten. Ich habe gerade mein Entwicklungs-Repository bei Github reingestellt. https://github.com/NerdyProjects/sparmatic-zero Ich hoffe, dass ich mit dem Code keinerlei Lizenzen verletze - ich denke, dass der Bootloader aus Code hier aus der Artikelsammlung besteht. Zudem basiert die erste Version der nRF24L01 Library auf einer "MIRF" genannten Implementierung ergänzt aus Code von der R0cket Badge. Zudem sind Ideen und Anregungen aus TravelRecs Code eingeflossen, z.B. die Display-Ansteuerung. Jeder darf gerne meinen Code verwenden - ich würde der Einfachheit sagen, dass die Veröffentlichung unter GPL erfolgt. Sollte dies für irgendwelche Entwicklungen / Verwendungen ein Problem sein, so benachrichtigt mich einfach. Bitte prüft vor Verwendung, ob nicht Codeteile doch von jemandem anderes stammen! Ich werde in naher Zukunft nicht weiter entwickeln, habe aber auch noch 3 Thermys hier. Sollte ich nochmal umziehen und hätte dann einen Verwendungszweck, so kanns natürlich passieren, dass ich die Software dann einsetze :) Gruß, Matthias
Hallo Matthias, danke fuer den Code - ihr seid ein Stueckchen weiter als Willem. Ich werde Mittwoch allerdings doch erstmal sehen, was erforderlich ist um OpenHR20 auf dem Thermy zum Laufen zu bringen. Ich vermute, dass das fuer mich der schnellste Weg zum Ziel sein koennte.
Anpassung OpenHR20 an neuere Zero, Comet(Thermy): Der Thermotronic Basic ist offenbar die Urversion der Sparmatics, und hat ein dem HR20 ähnliches Display. Die neueren Modelle Zero, Comet(Thermy) haben ein größeres Display mit anderem Mapping. LCD HR20 hier: http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/doc/lcd/segments_numbered.png?revision=366 LCD Sparmatic Zero, Basic (Thermotronic) hier: Beitrag "Re: Preisgünstiger Heizungsregler bei Praktiker" LCD Sparmatic aktuell hier: http://www.mikrocontroller.net/attachment/92552/SparmaticComet_LCD_Segment_Belegung.jpg Also Anpassungen mind. erforderlich hier: http://openhr20.svn.sourceforge.net/viewvc/openhr20/rfmsrc/OpenHR20/lcd.h?revision=366&view=markup
Ab Montag dem 08.10 hat Aldi Süd wieder THERMy im Angebot (14,99). Kann ich da bedenkenlos zuschlagen oder hat eines der verwandten Modelle (Comet, Zero) deutliche Vorteile? Plan wäre, erstmal alle Heizkörper von mechanischen Theromstaten auf die (unmodifizierten) elektronischen umzurüsten und dann irgendwann später wenn ich mal Zeit habe mit Custom Firmware umflashen (AVRISPMKII vorhanden) und über RS232 an ein Regel-Netzwerk anschliessen...
Ich habe den Plan, openHR20 anzupassen, erstmal wieder verworfen. Stattdessen habe ich mich Matthias Code zugewandt und unter https://github.com/gnbl/sparmatic2011 Änderungen für die Unterstützung der Encoder von Comet/Thermy gemacht. In config.h lässt sich der Encoder durch ein entsprechendes #define für die Zeros auch wieder deaktivieren (kann ich nicht testen, habe nur Thermy). Der wird jetzt mit Peter Dannegers Code im Flankeninterrupt ausgewertet, da für den Encoder der LCD-Interrupt nicht ausgereicht hat. Funkmodul und Bootloader sind per #define erstmal deaktiviert. Die Menüfunktionen funktioniert noch nicht so richtig. Es sind aber offenbar schon Routinen für Regler, Uhr und Parameterspeicher vorhanden. Muss man nur noch zusammenbauen :-) Wegen nRF24L01 Library: http://www.tinkerer.eu/AVRLib/nRF24L01 -> http://www.arduino.cc/playground/InterfacingWithHardware/Nrf24L01 Werde ich aber wohl nicht nutzen, da die Reichweite meiner Module zu klein ist. Andreas: Zero hat Tasten statt Rad, Thermy ist eine OEM-Version vom Comet. Es könnte aber wieder eine neue Version sein..?
Angehängte Dateien:
-
IMAG0047.jpg
680 KB
nAbend... ich habe mir gerade bein Lidl einen neuen Regler gekauft, der sah so aus wie ein Comet V2, inndn drin ist aberdas anhängende. Hat jemand weitere Informationen insbesonders die verwendete CPU?? Einen Programmierstecker finde ich auch nicht. Grüsse Robert
Das sieht aus wie die Medion-Teile, die Aldi vor den Sparmatic-Clones im Angebot hatte. Die sind zu diesem Projekt leider inkompatibel und die CPU ist nicht bekannt. Kannst Du bitte nochmal das Äußere von dem Ding oder ein komplettes Gerät fotografieren?!
Andreas Koch schrieb: > Ab Montag dem 08.10 hat Aldi Süd wieder THERMy im Angebot (14,99). > > Kann ich da bedenkenlos zuschlagen oder hat eines der verwandten Modelle > (Comet, Zero) deutliche Vorteile? Die Geräte sehen so aus, wie die alten Themys mit leichtem Facelifting. "USB"-Schnittstelle ist vorhanden, deutet also auf ein kompatibles Gerät hin. Die Thermys hatten immer ein leiseres Getriebe, verglichen mit dem Zero oder dem Comet. Ich würde an Deiner Stelle zuschlagen.
Angehängte Dateien:
-
IMAG0049.jpg
160 KB
Knut Ballhause schrieb: > Kannst Du bitte nochmal das Äußere von dem Ding oder ein komplettes > Gerät fotografieren?! Bitte sehr.
Dieses *#@$øΩ-Teil habe ich mir auch mal näher angesehen, ohne Ergebnis: Beitrag "Untersuchung Heizungsthermostat Lifetec MD12460"
Angehängte Dateien:
-
sparmatic-kabel.jpg
76 KB
Habe nun auch endlich mein Programmierkabel fertig. Statt ein USB-Kabel aufzudröseln, habe ich diesen Hirose-Stecker genommen: http://de.mouser.com/ProductDetail/Hirose-Connector/UX40-MB-5P/?qs=sGAEpiMZZMvFp%252byPHbnZY3w6i1RLcVof Dank geht nochmal an michael_h45 fürs Mitbestellen.
Sehr gut, dann kann's ja losgehen. Wenn jemand Code beisteuern moechte koennte ich vorerst Patches anwenden oder euch Schreibzugriff auf das github-Projekt geben. Wahrscheinlich koennte aber auch jeder sein eigenes repository dort haben und dann immer hin und her mergen. Es war noch ein kleiner bug im Menue (unsigned fuer Eingaben). Ich werde noch den angefangenen Shut-Down Code, den ich Willems Quellen hinzugefuegt hatte, einbauen. Die Temperaturanzeige nutzt einen Doppelpunkt, das werde ich auch nach Moeglichkeit beheben. Es hat sich auch ein falscher Freund eingeschlichen, "vent" werde ich nach und nach durch "valve" oder so ersetzen. Ich habe von den RFM12 noch keine Ahnung und wuerde mich vorerst auf die Fertigstellung des jetzigen Codes konzentrieren. SPI Routinen gibt es aber auch schon (wegen des nRF24L). Standardanzeige ist uebrigens die Ist-Temperatur, [+/-/wheel] veraendert die Soll-Temperatur, [Menue] lang fuehrt ins Menue. Adaptierung war auskommentiert und wartet nach Einfahren des Aktors auf Nutzereingabe. Happy hacking und nochmal Dank an Matthias, dass er seine ganze Arbeit zur Verfuegung stellt.
Angehängte Dateien:
-
IMG_1132_1_.jpg
62 KB -
IMG_1131_1_.jpg
54 KB
Hier mal das aktuelle Aldi Süd Angebot für 14,99€. Scheinbar wird ein Zahnrad über eine Lichtschranke auf der Platine ausgewertet. Weiss nich ob das die alten auch schon haben. Sorry für die schlechten Bilder sind nur vom Handy ;) Gruss, Jörg
Jörg Esser schrieb: > Scheinbar wird ein Zahnrad über eine Lichtschranke auf der Platine > ausgewertet. Natürlich. Somit wird die Getriebeposition respektive die Ventilposition abgetastet. Jörg Esser schrieb: > Weiss nich ob das die alten auch schon haben. Ja. Bei der ersten Revision (2011) war der Reflexkoppler noch an einer Tochterplatine befestigt. Die 2012er Thermys und Comets sahen der aktuellen Platine sehr ähnlich. Was ist denn für ein Controller verbaut? Mega169PA?
Ja ein Mega169PA. Kann es sein das der Temperaturfühler links vom Drehrad sitzt ? Ich würde gerne mit meiner Fussbodenheizung und einem verlängertem Fühler experimentieren. Hat das schonmal jemand gemacht ? Gruss, Jörg
Jörg Esser schrieb: > Kann es sein das der Temperaturfühler links vom Drehrad sitzt ? Ja, genau. Jörg Esser schrieb: > Ich würde gerne mit meiner Fussbodenheizung und einem verlängertem > Fühler experimentieren. Das setzt eine geschirmte, nicht allzu lange Leitung voraus. Jörg Esser schrieb: > Hat das schonmal jemand gemacht ? Ja. Ich habe aber den internen Fühler drin gelassen und einen externen per Stecker an einen freien ADC-Pin drangefummelt und per Programm umgeschaltet. Funktionierte mässig gut, da man die externen Sensoren nie genau mit der Kennlinie bekommt, wie die intern verbauten. Also musste die Wertetabelle zur Temperaturmessung angepasst werden. Jetzt verwende ich für meine FBH einen externen Fühler, der an einen alten Zero mit Funk angebunden ist.
Hallo, ist denn irgendwo ein Repository für Quellen eingerichtet worden? Gruss Robert
Übrigens gibt es am nächsten Mittwoch bzw. Donnerstag (je nach Bundesland und Feiertag) bei Aldi-Nord wieder Thermostate: http://www.aldi-nord.de/aldi_ab_mittwoch_3110_48_5_1051_16826.html Gehe ich recht in der Annahme, daß es sich hierbei um eine Sparmatic-Variante handelt, deren Firmware ersetzt werden kann?
Meiner sieht genauso aus. Und bei diesem scheint es zu gehen. Ich habe es aber nicht probiert, habe keine Zeit. Gruss Robert
Rufus Τ. Firefly schrieb: > Gehe ich recht in der Annahme, daß es sich hierbei um eine > Sparmatic-Variante handelt, deren Firmware ersetzt werden kann? Ja, sieht gut aus :-)
Nur mal ein kurzer subjektiver Vergleich Thermy/Comet: Ehrlich gesagt gefällt mir die ALDI(Sued) Thermy-Variante nicht ganz so gut wie Comets (Praktiker). Die drei Tasten sind "nur" Plastik-Lippen. Sie haben kaum Druckpunkt und ich finde sie sehr schwamig. Bei den Comets sind das noch aufgelegte Plastik-Elemente mit schönem Druckpunkt.. Auch finde ich das Rädchen extrem schwammig, die Rasterungen werden fast schon nicht mehr getroffen. Bei den Comets war das gerade noch so ok. Wenn das offengelegte SMD-Bauteil unter dem Thermy-Schriftzug allerdings der Temperatur-Sensor ist, ist das wiederum nett. Dann wär der Sensor "halbwegs" rausgeführt. (Kann es sein, dass die Thermys die Uhrzeit bei entfernen der Baterien nicht abspeichert?) Gruss, Max.
Ahrgh, sorry, ich hab nur mit dem 2011-comet verglichen. Aber zumindest das mit den Tasten dürfte trotzdem zutreffen (Themry vs. Comet-2012), Rädchen schaut gleich aus. Gruss, Max
Hallo zusammen, ich habe mir Ende letzten Jahres auch ein THERMy bei Aldi gekauft. Der sollte zwar erstmal nur Reserve sein, aber als ich dieses bzw. die vielen Projekte (in Sachen Thermostat) gefunden habe bin ich hell auf begeistert. Zum Glück habe ich schon hin und wieder mit nem ATmega experementiert. Nur leider kenne ich mich mit diesem GIT dingen überhaupt nicht aus ... Knut, kannst Du nicht mal kurz schreiben wie ich da ne schöne Firmware für den kleinen THERMy raus bekomme? Danke & Gruß Michael R.
>ich habe mir gerade bein Lidl einen neuen Regler gekauft, der sah so aus >wie ein Comet V2, inndn drin ist aberdas anhängende. >Hat jemand weitere Informationen insbesonders die verwendete CPU?? >Einen Programmierstecker finde ich auch nicht. Falls es noch jemand interessiert, die CPU ist eine 8bit von Samsung. Ich habe leztes Jahr mal recherchiert, könnte bei Bedarf nachschauen, wie die "genaue" Bezeichnung war. andy
@Michael: GitHub ist lediglich ein Online-Speicheranbieter. Wenn Du auf die weiter oben verlinkte Adresse klickst (https://github.com/wjroes/OpenZero), öffnet sich eine Seite mit einem Ordner und einem Textfile. In dem Ordner befindet sich ein komplettes C-Projekt des holländischen Programmierkollegen. Darüber gibt es einen Button, auf dem ZIP steht. Damit kannst Du das Projekt herunterladen und auf Deine Platte packen. Dann lädst Dir das aktuelle ATMEL-STUDIO und öffnest dieses Projekt. Soweit ich weiß, ist das Projekt gut dokumentiert, aber noch nicht vollständig.
Recht schönen Dank Knut (gut das Du auch hier immer wieder mal reinsiehst)! Viel einfacher geht es ja schon bald garnicht mehr. Ich werde meinen Erfolg (so er sich dann einstellen sollte) hier posten! Gruß Michael
Alles klar, ich glaube Willem liest auch hin und wieder mal mit. Wenn ich in Zukunft ganz viel Zeit habe, werde ich mich auch noch mal ausgiebig mit den Teilen beschäftigen, nachdem mich die alten Zeros nicht so sehr überzeugt haben, so rein von den Möglichkeiten der Hardware...
... gestern (28.1.'13) gabs die wieder beim Aldi Süd - da sind bestimmt noch einige über ... Kosten: 14.95€
Hallo, ich habe folgendes problem, ich habe beim thermy den drehimpulsgeber durch einen atmega ersetzt. ich mochte die temperatur manuell per µC einstellen. ich habe bemerkt das der thermy ca. alle 20-30 sec. irgendwas macht und ein bis drei drehgeberimpulse nicht mitbekommt und dadurch nicht correct mitzählt. wenn ich jetzt ausgerechnet in dieser zeit die temperatur einstelle funzt das nicht correct und ich habe ein halbes oder ganzes °C zu wenig oder zu viel. hat sich da schonmal jemand mit befasst? Gruß... Hannes
Hannes K. schrieb: > Hallo, ich habe folgendes problem, ich habe beim thermy den > drehimpulsgeber durch einen atmega ersetzt. Aha. Hannes K. schrieb: > ich mochte die temperatur > manuell per µC einstellen. Hmm, das kann der interne Controller aber auch blendend leisten. Hannes K. schrieb: > ich habe bemerkt das der thermy ca. alle > 20-30 sec. irgendwas macht Der macht sogar noch öfter ´was. Ich würde sagen 1x pro Sekunde mindestens. Hannes K. schrieb: > und ein bis drei drehgeberimpulse nicht > mitbekommt und dadurch nicht correct mitzählt. Das kann nur passieren, wenn die von Dir generierten Pulse zu kurz sind oder sich nicht an den Gray-Code halten. Pulse kürzer als 10ms wird die Firmware als Preller verwerfen. Mach also die Pulse langsamer.
Hallo Knut, ich habe die Pulsdauer momentan bei 60ms stehen, der code läuft einwandfrei vor und rückwärts. Bei 10ms schnell und 200ms langsam wird es kriminell und Thermy zählt nicht mehr richtig. Mein Problem ist das Thermy ab und zu einen Puls nicht mitzählt und ich nicht immer sicher sein kann das die gewünschte Temperatur eingestellt wurde. Wenn ich irgendwie feststellen könnte wann genau Thermy keine Drehimpulsgeber eingaben zulässt könnte ich meine Temperatur davor oder danach einstellen. Es kommt ca. alle 20-30sec. dazu das man für ca. 100ms keine Eingabe machen kann. Grüße... Hannes
Hannes K. schrieb: > Bei 10ms schnell und 200ms langsam > wird es kriminell und Thermy zählt nicht mehr richtig. Bei zu schnell, ist verständlich, aber zu langsam kommt mir komisch vor. Es ist natürlich so, dass der 2. Puls für den 2. Kontakt nicht ewig nach dem ersten kommen darf. Wenn Du Deinen Generator aber symmetrisch aufgebaut hast (Puls 1 - 50% Zeit - Puls2 50% Zeit), dann könnte das schon sein, dass die Drehrad-Entprell-Routine das nicht mehr entziffern kann. Dies bezieht sich auf die Originalfirmware. Meiner eigenen Routine ist das wurscht, die kann nur zu schnelle Impulse nicht werten, bzw. verwirft diese als Prellen. Das kommt bei normaler Bedienung aber nicht vor. Was ich mir auch vorstellen kann ist, dass die Originalfirmware nach dem letzten Drehen eine Zeit lang wartet und dann in einen tieferen Schlafmodus fällt, der erst wieder durch das tippen auf Tasten oder das Drehen am Rad zum Aufwachen des Controllers führt. Dann verliert die Firmware einige Klicks, bevor der Controller wieder rennt.
Das mit dem aufwachen habe ich auch berücksichtigt. Wenn ich zb. eine dauerrutine ausführe kann man den Effekt gut beobachten. Ich lasse Thermy zb. ununterbrochen 10 grad hoch und wieder runterlaufen dann kommt es nach einer Zeit immer wieder zu diesen Aussetzern also das ein einziger Schritt ausgelassen wird. Das passiert so alle 20 bis 30 sec. Grüße... Hannes
Hm, dann wäre es vielleicht besser, die originale Firmware durch etwas Funktionierendes zu ersetzen. Kannst Du den Effekt auch an einem unmodifizierten Regler mittels des Drehrades nachweisen? Falls ja, ist in der Firmware ein Stück Code, welches den "normalen" Programmablauf blockiert. Da die Temperaturberechnung ziemlich zeitaufwändig ist, könnte diese die Aussetzer hervorrufen. Man kann diese Berechnung aber auch so programmieren, dass Zeitgeber und Interrupte lässig weiterlaufen und es zu keinem Verhungern von Takten kommt. Das kann ja dann auch bei der Lichtschranke passieren und dann werden Ventilpositionen "verpennt".
Ich kann dieses Effekt an einem unverändertem Thermy auch nachweisen, wenn man das Rad dreht, geht in einer bestimmten Geschwindigkeit die Temeratur um 0.5¬ hoch oder runter. Dreht man schneller, geht das nicht mehr regelmässig, bei reduzierter Drehgeschwindigkeit tritt dieser Effekt auch ein. Gruss Robert
Ich werde das Problem morgen näher untersuchen es ist aber definitiv so das bei gleichbleibender Tastgeschwindigkeit ca. alle halbe Minute die Eingabe nicht aktiv ist und wenn man diesen Moment durch Zufall erwischt geht einem ein Schritt verloren. Vielen Dank für die Anregungen werde mich morgen wieder melden. Einen Schönen Abend vorerst. Grüße... Hannes
Hallo, heute habe ich den Thermy immer einen Schritt hoch und wieder runter laufen lassen, kontinuierlich bei 20ms. Ich habe festgestellt das dabei die Temperatur in unregelmäßigen Abständen von 2-20sec. immer ein halbes grad hochwandert. Ich bin daher davon ausgegangen der nur das down stellen ab und zu einen Schritt nicht erfasst wenn der Thermy was zu tun hat. Ich habe darauf hin den Thermy kontinuierlich mit 96 Downschritten auf Aus laufen lassen(96 damit er sicher bis auf Aus läuft auch wenn einige Schritte nicht gezählt werden) und dann wieder mit 80 Schritten Up laufen lassen sodas er auf 27,5 Grad stehen bleibt. Das hat zu 100% funktioniert und es ging nicht ein einziger Schritt beim Up zählen verloren. Ich habe das mehrere hundert mal laufen lassen und es funktionierte einwandfrei. Fazit: Beim Downstellen nimmt Thermy nicht immer alle Schritte an aber dafür werden alle Schritte beim Upzählen einwandfrei gezählt. Ich kann Thermy nun mit 96 Downschritten sicher bis auf Aus stellen, auch wenn dabei bis 4 Schritte verschluckt werden also von voll An bis Aus. Anschließend steppe ich dann hoch auf meine gewünschte Temperatur. Funzt einwandfrei :-) Damit ist mein Problem gelöst. Grüße... Hannes
Hannes K. schrieb: > Damit ist mein Problem gelöst. Naja - es umgeht einen Fehler und führt für Dich zum gewünschten Ergebnis.
Hallo Forengemeinde, aufgrund des im Norden unseres Landes ziemlich miesen Wetters habe ich an der Firmware weitergeschrieben. Wer sie ausprobieren möchte, findet das komplette Projekt angehängt. Es ist in ASM erstellt und mit ATMEL-Studio 6.0 und 6.1 kompatibel. Features: - Echtzeit und Ist-Temperatur-Anzeige im Normalmodus - Ähnliche Menüführung wie in der Original-Firmware - Menüpunkte PROG, TEMP, ZEIT, ADAP vollständig implementiert - Fuzzy-Regelalgorithmus - max. 4 Warm/Kalt-Zyklen pro Tag + 1 Nachtabsenkung (3. Temperaturwert) - vernünftig entprellte Tasten - funktionierendes Drehrad ToDo: - Fenster-Offen-Erkennung - Batteriemessung - Urlaubsfunktion - Werksresetfunktion - Offset-Funktion - Bugfixes - Umsetzung von Erweiterungen (Funk, externe Fühler) - vernünftige Code-Kommentierung Da es eine Betaversion ist, sind Bug möglich und wahrscheinlich. Ich würde mich über Anregungen und Kritik freuen. TravelRec.
Noch vergessen: - Batterieentnahme-Erkennung - Speichern der 3 Einstelltemperaturen im EEPROM TravelRec. P.S. Benutzung der Firmware und Flashen des Controllers auf eigene Gefahr! Keine Haftung für etwaige Schäden durch nicht erwartungsgemäß funktionierende Heizungsregler!
Neue Programmversion: Hinzugefügt: - Batterie-Leer-Anzeige - abschalten des Reglers und speichern der Uhrzeit bei erschöpfter Batterie BugFix: - Bargraph wurde bei Tageswechsel nicht aktualisiert
Neue Programmversion V005: Hinzugefügt: -Auto/Manuell Modus: Im Auto-Modus werden die Timer abgefragt und die Einstelltemperaturen aktualisiert. Es wird ein Bargraph und die entsprechenden Symbole für das aktuelle Temperaturintervall angezeigt. Im Manuell-Modus werden die Timer nicht abgefragt. Die aktuelle Einstelltemperatur bleibt bis zur manuellen Änderung bestehen. Es werden kein Bargraph und keine Temperaturintervall-Symbole angezeigt. Änderung: - kleinere Bugfixes
Ich hatte gerade wieder eine Idee. Gibs noch pins für nen 2 fühler? Evtl sogar was für 2wire? Dann könnte man über 2 fühler den vor und rücklauf messen um damit auf die raumtemperatur zu schliessen. Möglich? Ich denke hier an meine fussbodenheizung ;) Gruss Jörg
Jörg Esser schrieb: > Ich hatte gerade wieder eine Idee. Gibs noch pins für nen 2 fühler? Evtl > sogar was für 2wire? Grundsätzlich hast Du 2 Möglichkeiten: 1. Am JTAG-Header laufen 4 analoge/digitale I/Os und Betriebsspannung auf. Diese könnte man mittels Widerstand und NTC oder mit 2 Widerständen für Soft-I2C und entsprechend langer Leitung auf einen 2. Fühler umrüsten. Nachteil: Gehäuse öffnen und danach wieder irgendwie verschließen. Die Schweißpunkte müssen entfernt und durch eine andere mechanische Fixierung ersetzt werden. Oder man muss kleben und kommt später nicht mehr ´ran. 2. Du nutzt die USB-Buchse. Dort stehen 3 digitale I/Os und Betriebsspannung zur Verfügung. Daran kann man einen digitalen Fühler oder einen kleinen Controller mit analogem Fühler anschließen. Kommunikation wahlweise über SPI (ohne /CS) oder I2C...
BTW: Im Praktiker-Onlineshop gibt es die Comet-Regler derweil für 12.99€ plus Versand. Falls noch jemand günstig sein Haus ausrüsten möchte, bevor der Frühling Ernst macht... ;-)
Programmupdate: Hinzugefügt: - automatische Kalkschutzfahrt Freitags 11:00 Uhr Änderung: - Interruptfrequenz Soundausgabe (Motor-Buzzer) angepasst - fehlerhafte I/O-Registernutzung beseitigt - kleinere Bugfixes
Programmupdate: Bugfix: - manuelle Temperatureinstellung im Automatikmodus wurde nach bereits 1 Minute von Timereinstellungen überschrieben - bei der Timerprogrammierung wurden teilweise falsche Symbole angezeigt
Programmupdate: Hinzugefügt: - Haus-/Mond-Symbole sind im Automatikmodus stetig eingeschaltet, wenn die betreffende Heizzeit läuft und die Einstelltemperatur der programmierten Temperatur entspricht. Die Symbole blinken, wenn die Einstelltemperatur manuell verändert wurde, das heißt, von der programmierten Temperatur abweicht. Sie sind wieder dauerhaft eingeschaltet, wenn die Einstelltemperatur auf den programmierten Wert zurückgedreht wurde oder eine neue Heizzeit erreicht ist. - kleinere Optimierungen
Noch ein Hinweis: Die aktuell verkauften Sparmatic-Comet enthalten außer dem Aufdruck "comet" auch anstelle des älteren ATMEGA169PV den neueren ATMEGA169PA. Der neuere Controller hat einige Bits in einigen I/O-Registern verändert (siehe Migration-Note AVR529). Dies merkt man beispielsweise daran, dass nach dem Auffahren nach Einlegen der Batterien die OK-Taste nicht funktioniert, um das Ventil zu adaptieren. Hier muss das Projekt auf den ATMEGA169PA als Device im ATMEL-Studio umgestellt und neu assembliert werden. Dadurch werden die betreffenden Bits an die richtige Stelle geschoben. Danach flasht man die neue *.hex. BTW: Ziemlich wenige Wortmeldungen hier...
Angehängte Dateien:
-
Thermy_v2_Aldi.gif
810 KB
Knut Ballhause schrieb: > Die aktuell verkauften Sparmatic-Comet enthalten außer dem Aufdruck > "comet" auch anstelle des älteren ATMEGA169PV den neueren ATMEGA169PA. Ja, der ist auch in meinem Gerät vom Aldi drin. Ich muss mich jetzt noch überwinden und mein mini-USB-Kabel zerschneiden um das Gerät programmieren zu können. Mein Gerät (die Platine) sieht so aus wie im Anhang. Es ist ein Gif-Bild, damit kann man die Leiterzüge gut verfolgen ohne dass man das Ding immer umdrehen muss. Das mit der Größe tut mir Leid, aber kleiner haben ich es nicht hinbekommen.
Hans Jelt schrieb: > Es ist ein Gif-Bild Blink blink.. ;-) Hans Jelt schrieb: > Mein Gerät (die Platine) sieht so aus wie im Anhang. Bislang waren ALDI Thermy und Comet 100% kompatibel, sollte mich wundern, wenn sich das geändert hätte.
Es gibt eine Anpassung meiner bisherigen Firmware zur Verwendung an Mischventilen. Dies ist eine Testversion. Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Knut Ballhause schrieb: > anbei der überarbeitete Plan. Im Grunde habe ich die Daten von Leopold > B. benutzt, überprüft und mit Werten versehen. Ausserdem habe ich > versucht, das Ganze modular und übersichtlich anzuordnen. Dies ist wirklich ein sehr übersichtlicher Plan und er passt zu meinem Thermy V2 (Variante mit losen Tasten im Gehäuse, und mit der dämlichen eingelöteten Reflexlichtschrankenplatine.) Inzwischen gibt es aber seit einigen Jahren auch den Thermy V3 (passt zu dem Bild in 'Sparmatic_Heizungsthermostate', mit den Plastik-Zungen-Tasten und der weißen Platine ) Dieser V3 hat einen leicht geänderten Schaltplan im Bereich PORTF und PORTE. Ich würde diesen Schaltplan gerne hier einstellen, am besten ausgehend von dem V2-Plan. Dazu wäre es ganz nett wenn ich das Original des V2 im eagle- oder kicad -Format hätte, ich will nur ungern nur das png-file manipulieren. Kann mir irgend jemand den Schaltplan des V2 in einem original-Format zur Verfügung stellen? Geht das eventuell hier im Forum als Datei? Vielen Dank
Bitteschön.
Sorry, aber ich kann die Daten nicht lesen, nutze Eagle 4.16.
Angehängte Dateien:
-
ThermyV3-sch.png
70 KB
Thomas Husterer schrieb: > Danke, ThermyV3-Version zurück. Hier ist ein png-Bild von der Schaltung.
Hi, habe gerade mit Freude die Threads zu den Sparmatic entdeckt, die Heizkörper zentral und per Funk zu regeln steht auf meiner Long Term Projektliste. Hat denn schon jemand einen Platinchenentwurfmund ein Funkprotokoll fertig? Wäre mir beim Quickscan dieser Diskussion nicht aufgefallen, nur einen ersten Entwurf gab es oben, der sah aber noch unfertig aus. Viele Grüße, Conny
Geht es hier noch weiter, noch jemand dran? Vg,, Conny
Conny G. schrieb: > Geht es hier noch weiter, noch jemand dran? Guckst Du: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Hallo, letzte Woche gab es hier beim Aldi "Thermies". Weil es hier schon so viele freundlicherweise offengelegte Projekte und Informationen gibt, habe ich einige gekauft um damit so ähnlich wie Jörg Esser eine Fussbodenheizung zu steuern. Mit der Originalfirmware kann ich das nicht machen, weil die Fenster-Offen-Erkennung dazwischenfunkt, von daher bin ich ganz froh das es das hier alles gibt. Leider tut's weder die Firmware von Knut ( diese Version: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" ) noch die von https://github.com/gnbl/sparmatic2011: Bei beiden klappt die Adaptierfahrt nicht, es gibt nur einen ganz kurzen Ruck. Bei der 'sparmatic2011'-Firmware scheint es daran zu liegen, dass das Signal von der Reflexlichtschranke nicht ankommt und das System meint, der Motor bewege sich nicht. Mit der 'sparmatic2011' funktionieren auch die Tasten nicht, mit Knuts Software gehen die Tasten. Das Innenleben entspricht soweit ich das sehen konnte der "Thermy V3" wie hier beschrieben, allerdings steht bei mir eine "13" neben den JTAG-Pads, keine "12" wie auf dem Foto hier. Hat jemand eine Idee was da los sein könnte ? Ich habe schon die entsprechenden Stellen im ThermyV3-Schaltplan mit meiner Platine verglichen, kann da aber keine Unterschiede sehen. Fotos könnte ich ggf. einstellen. Die Fuses habe ich für beide Firmwares nach Knuts Angaben gesetzt (FF-D1-62).
Mathias K. schrieb: > Hat jemand eine Idee was da los sein könnte ? Ja, da wird ein ATMEGA169PA drin sein. Die Firmwares sind für einen ATMEGA169P kompiliert und dieser hat andere Interruptflagpositionen. Grob gesagt. BTW: Es sind nur die Firmwares für den Comet kompatibel, nicht die für den 2011er Zero! Also nur die hex-Dateien aus DIESEM Thread!
:
Bearbeitet durch User
Mathias K. schrieb: > Das Innenleben entspricht soweit ich das sehen konnte der "Thermy V3" > wie hier beschrieben, allerdings steht bei mir eine "13" neben den > JTAG-Pads, keine "12" wie auf dem Foto hier. Hallo Mathias, ich kann deine Beobachtung bestätigen, das Innenleben ist augenscheinlich identisch und bei mir verhält sich die aktuelle Thermy-Version auch genau so wie der Vorgänger "V3". (Lediglich die V2 hat eine leicht veränderte Pin-Belegung) Gruss thus
Guten Abend, @Knuth: ich hatte die Datei "Sparmatic_Comet_M169PA.hex" mit der 50Grad-Regelbereichserweiterung verwendet, das war es glaube ich nicht. Mit einem Hexfile aus diesem Thread geht's leider auch nicht. Die Sparmatic2011-Firmware tut's wohl deshalb nicht, weil die Pullups von Port B nirgendwo eingeschaltet werden, was aber IMHO nach dem Schaltplan zum Tastenlesen nötig wäre. Die Reflexlichtschranke wird an PE1 gelesen, was auch nicht zum v3-Schaltplan passt. Ich werd versuchen das anzupassen. Vielen Dank für Eure Antworten! Gruss Mathias
Ach ja, die Thermys - jetzt sehe ich die Unterschiede in der Beschaltung auch - gut, das kann nicht gehen... Warum ändern die denn die Beschaltung...?! Der Widerstand für die Batterie-Entnahme-Erkennung ist auch von E0 nach E5 gewandert... Falls jemand aktuelle Sourcen haben will, bitte eine PN schicken. Da ich keinen ThermyV2 habe (mann sehen die Dinger hässlich aus, hatte heute einen in der Hand), will ich das Programm auch nicht unbedingt modifizieren. Vielleicht wird es irgendwann mal Defines dafür geben...
:
Bearbeitet durch User
Mathias K. schrieb: > Die Sparmatic2011-Firmware tut's wohl deshalb nicht, weil die Pullups > von Port B nirgendwo eingeschaltet werden, was aber IMHO nach dem > Schaltplan zum Tastenlesen nötig wäre. Die Reflexlichtschranke wird an > PE1 gelesen, was auch nicht zum v3-Schaltplan passt. Ich werd versuchen > das anzupassen. Welches Layout hast Du denn jetzt genau? Lichtschranke an PE1 oder an PE3? Ich bin verwirrt.
:
Bearbeitet durch User
Sparmatic2011 hat, glaube ich, noch keine richtige Regelung, ich habe seit damals nicht weiter daran gearbeitet. Bitte neue Informationen ins Wiki schreiben, da habe ich damals auch ein paar Stunden investiert..
Ich selbst schrieb: >> Die Sparmatic2011-Firmware tut's wohl deshalb nicht, weil die Pullups >> von Port B nirgendwo eingeschaltet werden, was aber IMHO nach dem >> Schaltplan zum Tastenlesen nötig wäre. Stimmt nicht, die Pullups sind an, habe ein #define übersehen, Asche über mein Haupt. Wenn ich im Interrupthandler PCINT1_vect den Aufruf "keyPeriodicScan();" hinzufüge, funktionieren die Tasten. @gnbl: Wenn ich etwas Stabiles habe oder die Lust verliere, schicke ich Dir einen Patch. Dass es noch keine richtige Regelung gibt ist mit der Fussbodenheizung kein Problem, die heizt auch 2-Punkt-geregelt akzeptabel. Im Gegensatz zu den Thermies brauchen die normalen Stell"motoren" aber Dauerstrom um die Ventile offen zu halten. Wenn man die Heizanlage in die Nachtabsenkung schickt, wollen die Ventile natürlich alle aufmachen weil die Raumthermostatschalter nichts von Nachtabsenkung wissen. Diese Stromverschwendung abzustellen ist mal mein erstes Ziel, dann evtl. auch die Pumpe (100W, angeblich geht in dieser Anlage keine andere) im Mischerkreis auszuschalten wenn alle Ventile zu sind. Ich stelle mir vor, in den Thermies den NTC durch den Fototransistor eines Optokopplers zu ersetzen und die Raumthermostaten die LED schalten zu lassen. (Optokoppler wegen der Einstreuungen, die Kabel zwischen Thermostat und Stellmotoren sind lang, nicht wirklich verdrillt und liegen überall parallel zum 230V-Netz. Auf einer unbenutzen Ader habe ich neulich hochohmig 78V gemessen. ) >> Die Reflexlichtschranke wird an >> PE1 gelesen, was auch nicht zum v3-Schaltplan passt. Ich werd versuchen >> das anzupassen. > > Welches Layout hast Du denn jetzt genau? Lichtschranke an PE1 oder an > PE3? Ich bin verwirrt. Bisher hat für mich der ThermyV3-Schaltplan (weiss lackierte Platine) gepasst. Ich glaube daher dass der Fototransistor an PE3 ist. Ich habe mir den Motoranschluss extern herausgeführt. Morgen abend werde ich mal testen welches Port-E-Bit wackelt, wenn ich den Motor per Netzteil fahren lasse. Ciao Mathias
Mathias K. schrieb: > dann evtl. auch die Pumpe (100W, angeblich geht in dieser > Anlage keine andere) im Mischerkreis auszuschalten wenn alle Ventile zu > sind. Das wurde uns auch gesagt. Seitdem wir entgegen dem Rat eine Grundfos Alpha2 eingebaut haben, ist der Stromverbrauch der Heizung um 70% gesunken und die Anlage läuft immer noch einwandfrei (und nachts auch schön ruhig). Hier hilft wohl nur der Rat eines echten Fachmanns oder einfach das Probieren. Mathias K. schrieb: > Ich stelle mir vor, in den Thermies den NTC durch den Fototransistor > eines Optokopplers zu ersetzen Musst Du nicht. Nimm einfach einen Pin und Masse der USB-Buchse. Ist viel einfacher und erfordert keinen Umbau im Gerät. Brauchst Du die Funktion dann mal nicht mehr, brauchst Du nur den Stecker zu ziehen.
Hallo gnbl, inzwischen funktioniert bei mir die Adaptierfahrt mit sparmatic2011 und Thermy V3 und ich hänge den versprochenen Patch an. Man muss auch ein paar Sachen am Makefile ändern, daher wird die Sache wohl nicht ohne weiteres für beide Hardwareversionen gehen. gnbl schrieb: > Bitte neue Informationen ins Wiki schreiben, da habe ich damals auch ein > paar Stunden investiert.. Dem was dort schon alles zu der V3-Hardware steht, habe ich im Moment nichts hinzuzufügen. Gruss Mathias
Hallo rmrf, ich kann nicht versprechen, dass ich den Patch irgendwann integriere, da ich momentan nichts mit den Thermys mache (obwohl zunehmend Bedarf bestuende..). Aber wenn ich wieder dran bin sehe ich es mir natuerlich an. Ansonsten steht es ja jedem frei den Patch anzuwenden oder das repository auf github zu klonen und dort den Patch einzubauen. In jedem Fall danke fuer den feed-back.
Moin, Kälter wirds, daher bastle ich auch an dem Thermy V3 herum. In den Zeichnungen ist für den NTC immer nur 100k@25°C erwähnt - kennt jemand der Thermy-Erfahrenen den Temperaturkoeffizienten? Danke sehr!
Moin, Ich habe mir die Frage mal versucht, selbst herzuleiten. Das ganze basiert auf einer Demo von Torsten F. (Beitrag "Re: Preisgünstiger Heizungsregler bei Praktiker"), der in BASCOM einige ADC-Werte und die korrespondierenden Temperaturen hinterlegt hat. Ich weiß nicht woher diese stammen, aber die Infos unten sind nur so gut wie diese Zahlen. Darin findet sich folgender Code:
1 | 'Config für Temperatursensor |
2 | Config Adc = Single , Prescaler = Auto , Reference = Avcc |
3 | Config Portf.2 = Output |
4 | Dim Ist_temperatur As Single |
5 | Dim Adc_temp(10) As Word |
6 | Adc_temp(1) = 757 '0°C |
7 | Adc_temp(2) = 703 '5°C |
8 | Adc_temp(3) = 645 '10°C |
9 | Adc_temp(4) = 585 '15°C |
10 | Adc_temp(5) = 525 '20°C |
11 | Adc_temp(6) = 465 '25°C |
12 | Adc_temp(7) = 409 '30°C |
13 | Adc_temp(8) = 356 '35°C |
14 | Adc_temp(9) = 308 '40°C |
15 | Adc_temp(10) = 266 '45°C |
Lt. Schaltbild für den Thermy V3 (https://www.mikrocontroller.net/articles/Datei:THERMYV3-sch.jpg) liegt der NTC in Reihe mit einem 120k-Festwiderstand, gespeist wird die Schaltung mit VCC. Da hinter dem NTC mittels AD-Wandler abgegriffen wird, müsste der AD-Wandler bei 25°C einen Wert von
messen. Der ADC des ATMega hat eine Aulösung von 10bit=1023 Stufen, daher passt der dort theoretisch zu messende Wert:
gut mit dem oben für 25°C angegebenen überein. Für die verschiedenen Temperaturen ergibt sich dadurch: T[°C] ADC[Stufen] R_NTC[kOhm] 0 757 341.5 5 703 263.63 10 645 204.76 15 585 160.27 20 525 126.51 25 465 100 30 409 79.93 35 356 64.05 40 308 51.69 45 266 42.17 Durch Regression lässt sich eine Zuordnungsvorschrift aufstellen: - genau, durch die B-Parameter-Gleichung nach (http://en.wikipedia.org/wiki/Thermistor#B_or_.CE.B2_parameter_equation). [<math]R=R_0e^{B(\frac{1}{T} - \frac{1}{T_0})}[/math] Mit R0=100k und T0=293.15K ergibt sich für B ein Wert von 4010 mit sehr gutem Fit (R-Square/Adj R-Square=0.9999). In die Gleichung muss die temperatur in K eingesetzt werden. Die wollen wir aber bestimmen, daher noch schnell umstellen:
- einfach: Für uC ist eine Exponentiation vielleicht nicht das Einfachste, daher kann das Verhältnis versuchsweise auch linear approximiert werden.
Es ergibt sich P1= -0.1448 °C/kOhm und p2 = 43.27°C. Der fit ist jedoch extrem ungenau, (R-square: 0.9036, Adjusted R-square: 0.8915), die maximale Abweichung zwischen Kurve und Messwerten beträgt über 7.8°C bei den untersten Werten. - Kompromiss: Ein Polynom 2. Ordnung
liefert: - p1 = 0.0005176 °C/kOhm^2 - p2 = -0.3345 °C/kOhm p3 = 55.24 °C mit R-square: 0.987 Adjusted R-square: 0.9833 Die maximale Abweichung ist nur noch 3°C bei 0°C. Eventuell ist das gerechtfertigt, da der Widerstand sowieso an der Heizung direkt sitzt... Ein Polynom 3. Ordnung:
liefert:
p1 = -2.469e-06 °C/kOhm^3
p2 = 0.001915 °C/kOhm^2
p3 = -0.5541 °C/kOhm
p4 = 64.05 °C/kOhm
R-square: 0.9981
Adjusted R-square: 0.9971, die Maximale Abweichung ist nur noch 1°C im
betrachteten Bereich.
Habe die Regression gerade noch mal mit ADC und Temperatur durchgeführt: - B-Parameter:
- A = 264.2
B = 4616, R-square: 1
Adjusted R-square: 1
Aber blöd umzustellen und für uC sowieso zu kompliziert...
- Da wir R_NTC/R_NTC+x in die Gleichung einfließen haben macht sich hier
nämlich ein lineares Modell sehr gut:
- linear:p1 = -0.08933 °C/step p2 = 67.33 °C T in °C, ADC=[0...1023] R-square: 0.998 Adjusted R-square: 0.9977 maximales Residuum im betrachteten Bereich von 1.5°C, was für die meisten Zwecke mehr als ausreichend sein sollte, und ist außerdem schön einfach.
N'abend. Hab mir nen ISP USB Stecker gefeilt und versuche meinen Cometen per ISP anzusprechen und komme da nicht weiter. ISP Programmer ist der hier im Forum ganz gut bewertete Mysmartusb light: http://shop.myavr.de/index.php?sp=article.sp.php&artID=200006 Er läuft im STK500v2 Modus und ich hab ihn auf 3V eingestellt. Das zugehörige Flashtool erkennt den Controller nicht und wenn ich manuell Atmega169 einstelle, kommt ein Timeout wenn ich versuche, den Flash auszulesen. Ich hab's dann mit AVRDUDE 6.0.1 probiert: avrdude.exe -P COM14 -c stk500 v2 -p m169 -vv Der bringt mir keine vernünftige Device-ID. Entweder 0x000000 oder 0xffffff. Den Takt mit -B 50 reduzieren hilft nix. Die 5 USB-Pins sind korrekt mit dem ISP-Adapter verbunden, das hab ich mehrfach überprüft und durchgemessen. Dabei habe ich Pin 2 -> SCK und Pin 4 -> MISO verbunden sowie GND und VCC nachgemessen um sicherzustellen, dass ich die USB-Pins nicht falschrum interpretiere. Und wenn Reset absichtlich nicht verbunden ist, dann meldet AVRDUDE "initialization failed" und bringt gar nicht erst die falsche Device-ID, deshalb gehe ich davon aus, dass ich das Reset-Pad richtig getroffen habe. Ich hab dann das ganze auch mit eingelegten Batterien versucht. Dort resettet sich der Comet jedes Mal, wenn man versucht, den Flash auszulesen. Aber klappen tut's trotzdem nicht und AVRDUDE . SCK und MISO tauschen hilft auch nicht. Hätte nicht gedacht, dass das so kompliziert ist.... :(
Nachtrag: mit nem original AVRISP MKII klappts auch nicht - kann Device ID im AVR Studio (6.1) nicht auslesen.... Target Voltage wird erkannt (2.5V) Mit AVRDUDE geht's auch nicht. Hab dann mal mit nen Logic Analyzer das Auslesen mitgeschnitten (Trigger auf Reset 1->0). Sieht für mich als µC-Anfänger erstmal unverdächtig aus: http://up.picr.de/16561262sw.png Wenn jemand nen Tipp hat nur her damit!
Andreas K. schrieb: > Target Voltage wird > erkannt (2.5V) Setze mal neue Batterien ein. Wenn die Spannung zu niedrig ist funktioniert das ganze nicht.
Moin, Bin gerade bei dem Motor angelangt, wenn ich einen der beiden Pins auf HIGH setze höre ich nur ein kurzes Klacken des Motors - ist das am Ende ein Schrittmotor? Wie genau funktioniert die Ansteuerung? Besten Dank!
Für einen uC-Anfänger hast du ja schon ein super Equipment - wenn auch ein Netzteil dazugehört, hänge am Besten testweise mal das dran - 3-5V sollten ein stabiles Ansprechen des uC gewährleisten
An den Batterien liegt es nicht, der Controller läuft ab 1.8V sauber. Da die Brown-Out-Fuse auch beim gekauften Cometen nicht gesetzt ist, gibt es auch da keine Probleme. Ich würde auf den RESET-Kontakt tippen. Den zu erwischen ist nicht ganz einfach. Das Bohrloch muss exakt über der Oberfläche des RESET-Pads gebohrt sein (1,6mm über der Blechkante der USB-Buchse). Ist es zu hoch, bekommt der Reset-Draht keinen Kontakt zum Pad, wurde zu tief gebohrt, ist mitunter das Pad verletzt und der RESET-Draht trifft anstatt auf Kupfer nur auf nacktes FR4. BTW: Der Reset-Draht mussetwa 2mm tiefer in den Cometen ragen, als der USB-Stecker lang ist. An der Spitze des Drahtes sollte man ein sehr flaches U biegen, damit der Draht nicht an der FR4-Kante hängen bleibt und auf das Pad gleiten kann. Der Draht selber muss etwas federn können. Das Bohrloch für den RESET draht sollte 1,5mm im Durchmesser sein. Für den Draht nimmt man am besten 0,5mm Rundmaterial, idealerweise Phosphorbronze oder Messingdraht. Thermos That's schrieb: > wenn ich einen der beiden Pins auf > HIGH setze höre ich nur ein kurzes Klacken des Motors - ist das am Ende > ein Schrittmotor? Das Klacken bedeutet, dass der Motor kurz an den Anschlag läuft und die Firmware den Motor dann abschaltet. Das ist kein Schrittmotor, sondern ein normaler Spielzeug-Gleichstrommotor, wie er auch in CD-Schubladen und billig-Cd-Playern als Spindelmotor verwendet wird. Die Ansteuerung geschieht über eine diskrete H-Brücke. Thermos That's schrieb: > wenn ich einen der beiden Pins auf > HIGH setze Direkt am Motor? Das solltest Du bleiben lassen, das kann Dir im ungünstigsten Fall die H-Brücke braten.
:
Bearbeitet durch User
Danke für die Antwort, das passt. In der einen Drehrichtung war der
Motor im Anschlag, in der anderen ging die Brücke irgendwarum nicht.
Nach bewährter fachmännischer Reparatur ("überall rumdrücken") klappte
das dann auch wieder, scheine mir irgendwo einen Wackelkontakt
eingehandelt zu haben.
Der Controller ist bereits geflasht, ich wechsele die Pegel also
softwareseitig.
Thermos That's schrieb: > scheine mir irgendwo einen Wackelkontakt > eingehandelt zu haben. Es geht immer nur, wenn 1 Zweig der H-Brücke angesteuert ist. Man sollte per Software unbedingt vermeiden (verriegeln!), dass beide Zweige zeitgleich angesteuert werden, sonst gibt´s Rauchzeichen. Falls doch ein Wackler, zuerst die H-Brücke und das Motorkabel auf ordentliche Lötung prüfen.
Danke für die vielen Tipps - hab mich mal weiter mit der Materie beschäftigt. Den Reset-Kontakt habe ich mit nem Stück Federblech kontaktiert und das Gehäuse ist soweit aufgebort, dass ich das Pad sehen kann. Ausserdem: 1.) Mit eingelegten Batterien unterbricht der Comet die Adaption, wenn ich per ISP drauf zugreife. 2.) In meinem Screenshot oben vom Logic Analyzer sieht man, dass sich was tut auf dem Reset-Port. Das Signal liegt auf HI und wird ab und zu vom Programmer auf LO gezogen. Die Spannung für HI kommt jedoch VOM µC, nehme ich an. Und wenn ich nämlich den Reset-Pin weglasse, tut sich wiegesagt gar nix, d.h. Adaption wird nicht unterbrochen und kein HI-Pegel vorhanden. Die Stromversorgung ist denke ich auch nicht schuld weil: 1.) Wenn ich den Mysmartusb nehme, dann versorgt dieser den µC mit 3V. 2.) Wenn ich ein Netzteil mit stabilisierten 3V anschließe anstelle der Batterien, dann hab ich laut AVRISP MKII keine 3V Target Spannung sondern 2.6-2.7V, also unwesentlich mehr als mit Batterie. Hab inzwischen rausgefunden, dass ich mit den Logic Analyzer auch SPI decodieren kann. Dort sieht man dann, dass der Programmer auf MOSI versucht, dem Cometen ne Device ID zu entlocken, aber auf MISO nix gescheites reinkommt (entweder 0x00 oder 0xFF). Dass das ISP-Interface vom µC kaputt ist schließe ich auch aus, weil der Progmatic Programmierstick funktioniert wenn ich ihn anschließe...
So, ich hab's hinbekommen - beide Programmer finden jetzt die Device ID
:D :D :D
Hatte den Cometen schlussendlich geöffnet, sämtliche Schaltpläne
studiert und die ISP-Pads durchgemessen / mit den USB-Pins verglichen.
Daraufhin hab ich festgestellt, dass SCK und MISO doch vertauscht
waren... Ich muss demnach die Belegung vom Thermy verwenden
(GND/SCK/MOSI/MISO/VCC). Das hatte ich zwar schonmal probiert, aber
dabei wahrscheinlich den Reset nicht richtig kontaktiert.
Jedenfalls sagt mir Atmel Studio, dass es ein Atmega169P bzw. PA ist,
0x1E9405 -> kann das stimmen? Hab den Cometen im Okt 2010 bei Conrad
gekauft und er hat die Beschriftung auf den Tasten.
Detected device
Device names ATmega169P, ATmega169PA
Device signature 0x1E9405
Datasheet information
ATmega169P
CPU AVR8
Flash size 16 Kbytes
EEPROM size 512 bytes
SRAM size 1 Kbytes
VCC range 1,8 - 5,5 V
Maximum speed N/A
avrdude sagt folgendes (mit dem Mysmartusb light):
Programmer Type : STK500V2
Description : Atmel STK500 Version 2.x firmware
Programmer Model: STK500
Hardware Version: 3
Firmware Version Master : 2.10
Topcard : Unknown
Vtarget : 0.0 V
SCK period : 17.4 us
Varef : 0.0 V
Oscillator : Off
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.03s
avrdude.exe: Device signature = 0x1e9405
avrdude.exe: safemode: lfuse reads as 62
avrdude.exe: safemode: hfuse reads as D9
avrdude.exe: safemode: efuse reads as FF
avrdude.exe: safemode: lfuse reads as 62
avrdude.exe: safemode: hfuse reads as D9
avrdude.exe: safemode: efuse reads as FF
avrdude.exe: safemode: Fuses OK (H:FF, E:D9, L:62)
avrdude.exe done. Thank you.
:
Bearbeitet durch User
Nach dem was ich bisher gelesen hatte, dachte ich dass der Comet und der Thermy in etwa baugleich sind. Eventuell hilft dir folgendes: https://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#Modelle zur Identifikation. Edit: Hier steht auch noch mal das was du auf eigene Faust rausfinden musstest, doof... https://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#Pinbelegung
:
Bearbeitet durch User
Die Belegung der USB-Buchse ist bei allen Zero/Comet/Thermy-Reglern gleich. Andreas K. schrieb: > Jedenfalls sagt mir Atmel Studio, dass es ein Atmega169P bzw. PA ist, > 0x1E9405 -> kann das stimmen? Hab den Cometen im Okt 2010 bei Conrad > gekauft und er hat die Beschriftung auf den Tasten. Dann ist es definitiv ein Mega169P(V). Du musst also den Code für diesen Controller assemblieren/kompilieren. Das Fiese am Mega169PA ist, dass er dieselbe Kennung hat, aber unterschiedliche Interruptregister und -bitpositionen. Daher läuft ein für den P gebautes Programm nicht auf dem PA und umgekehrt.
@Thermos: Die Wiki-Seite kenne ich ;) Dort hab ich auch die 3 verschiedenen Sschaltpläne her... Letztendlich hatte mich aber die Aussage verwirrt, dass beim Aldi Thermy MISO und SCK vertauscht sind, denn bei meinem Cometen sind sie wie sich herausstellte auch vertauscht... Mein Comet sieht so aus und ist mit 4 6er Torx-Schrauben verschraubt: http://www.elv-downloads.de/bilder/artikel/Produkte/9/957/95797/Internet/normalneu/95797_F02_GeComet.jpg Naja, wenigstens hab ich jetzt was über SPI und ISP gelernt und konnte mit meinem Logic Analyzer rumspielen :D @Knut: Was meinst Du mit 'Kennung'? Atmega169 oder die Device ID?
Device ID.
Andreas K. schrieb: > Mein Comet sieht so aus Genau wie meine, nur mit Schweißnippeln anstelle der Schrauben. Ich habe auch neue Comets mit dem Comet-Aufdruck und alte und 2011er Thermys, bei allen ist die USB-Buchse gleich beschaltet.
Angehängte Dateien:
Falls Euch mal interessiert wie ein Comet (Originalfirmware) vs. einem mechanischen Thermostat regelt: anbei eine Grafik. SZ = Schlafzimmer, dort sind 2 Cometen, die ab 21 Uhr auf 17 Grad minimum eingestellt sind, ab 6:30 Uhr (bis 21 Uhr) auf 23 Grad. WZ = Wohnzimmer, mechanische Thermostate auf konstanter Einstellung, keine Absenkung. Man sieht, dass die mechanischen Thermostate sehr grob regeln (das entspricht auch dem subjektiven Gefühl dazu) und gerne mal sehr weit nach oben schiessen und dann wieder stark abkühlen lassen, die Hysterese liegt also bei eher 3 Grad. Der Comet regelt sehr fein, tagsüber hielt er konstant die 22 Grad. Der Temperatursensor steht am anderen Ende des Raums, die Comet selber haben wahrscheinlich 23 Grad, gleich am Heizkörper. Die Spikes nach Mitternacht haben eher mit offener Türe des SZ zu tun, als ich ins Bett ging und so wärmere Luft von aussen einströmt.
Ich glaube, beim Posten der Grafik ist etwas durcheinandergeraten? Conny G. schrieb: > als ich ins Bett ging und so wärmere Luft von aussen einströmt. Wie meinst Du das denn? ;-)
Knut Ballhause schrieb: > Ich glaube, beim Posten der Grafik ist etwas durcheinandergeraten? Wieso, was stimmt nicht? >> als ich ins Bett ging und so wärmere Luft von aussen einströmt. > Wie meinst Du das denn? ;-) Standard: Tür zu, Temp nachts 19 Grad. Um 1 bin ich beim Zähne putzen, währenddessen ist die Tür offen und Luft mit 22 Grad aus dem Flur strömt ins Schlafzimmer. Jetzt klarer? :-)
Conny G. schrieb: > Wieso, was stimmt nicht? Für mich sehen beide Diagramme gleich schlecht aus. Die Temperatur sollte ohne externe Störungen maximal ein halbes Grad nach oben und unten vom Sollwert abweichen. Sollten kurzzeitige Störungen auftreten, solle man diese auch nur als kurze Störung im Diagramm sehen. Bei Dir sieht es so aus, als wenn ständig die Tür oder ein Fenster geöffnet und geschlossen wird. Oder die Sonne scheint durch die Fenster, zumindest tagsüber, wodurch der Idealverlauf gestört wird. Das mit der warmen Luft war nur Kopfkino, vergiss es.
Ich finde die Kurve vom SZ gar nicht so schlecht. Ich finde die Peaks allerdings auch irgendwie komisch und zu identisch - es sei denn du bist wirklich beide male um ca. 3:00 ins Bett gegangen. Eine Vermutung wäre, dass um 3:00 die Heizung (Nachtabsenkung) einschaltet und der Heizkörper "plötzlich" warm wird, obwohl der Regler auf einer Stellung war, bei der vorher nicht geheizt wurde. Er regelt also nachdem die Heiz-Anlage "aufwacht" und die Heizkörper befeuert wieder runter...
Phil, das ist ganz sicher das Offenstehen der Türe im Schlafzimmer, das habe ich jetzt mehrfach beobachtet. Und ich gehe tatsächlich immer eher 2-3 Uhr ins Bett. Eine Stunde sieht man dem Diagramm kaum, ist ja ein Zeitraum von 36h insgesamt. Im Wz hat Knut wahrscheinlich recht, da war Sonne mit im Spiel, gerade an dem Tag. Trotzdem sehe ich auch jetzt noch, dass die mechanischen Thermostate wesentlich gröber / langsamer regeln, Hysterese 2 Grad.
Conny G. schrieb: > Trotzdem sehe ich auch jetzt noch, dass die mechanischen > Thermostate wesentlich gröber / langsamer regeln, Hysterese 2 Grad. Und natürlich in direkter Abhängigkeit zum mechanischen Verhalten des Ventils. Das wird durch den elektronischen Regler weitgehend ausgeglichen. Allerdings sollte bei einer guten Regelschleife die Regelung irgendwann aufhören, wenn keine Störgröße eingreift. Und dieses Verhalten kann man im Diagramm leider gar nicht sehen. Weiterhin ist der Temperaturfühler im Ventilkopf immer suboptimal, da der Regler immer mehr oder weniger direkt vom Heizkörper angestrahlt wird und daher ein ständiges Auf- und Zuregeln stattfindet, zumal wenn die Vorlauftemperatur unnötig hoch ist. Abhilfe schaffen da nur abgesetzte Sensoren.
Knut Ballhause schrieb: > Und natürlich in direkter Abhängigkeit zum mechanischen Verhalten des > Ventils. Das wird durch den elektronischen Regler weitgehend > ausgeglichen. Allerdings sollte bei einer guten Regelschleife die > Regelung irgendwann aufhören, wenn keine Störgröße eingreift. Im zwar hübschen, aber schlecht gedämmten Altbau ist eine Störgröße das schnelle Auskühlen des Raums :-) Jetzt bei Minusgraden fällt im Schlafzimmer die Temperatur in 3h um 4 Grad, sieht man schön, wenn dort die Absenkung um 21 Uhr greift. Geht jetzt bei -5 Grad draussen doppelt so schnell wie vor 1-2 Wochen +5 Grad. Mache die Absenkung auch nicht aus Energiespargründen (im Altbau quatsch, weil muss ja morgens alles wieder hochheizen), sondern für besseres Schlafklima. Und bgzl. abgesetzter Temperatursensor: ja, das würde ich mir langfristig noch vorstellen, dazu brauche ich Funkverbindung vom Comet zu meiner Home Automation. :-)
Conny G. schrieb: > dazu brauche ich Funkverbindung vom Comet > zu meiner Home Automation. :-) Hat die HA schon Sensoren im Haus verteilt?
Knut Ballhause schrieb: > Conny G. schrieb: >> dazu brauche ich Funkverbindung vom Comet >> zu meiner Home Automation. :-) > > Hat die HA schon Sensoren im Haus verteilt? Gerade dabei: Beitrag "ATMega328 und ATTiny45 mit I2C verbinden" Im ersten Schritt habe ich meine uralten ELV-Sensoren eingebunden, im Nächsten werde ich Sensoren selber machen, die dann direkt mein H.A.-Protokoll (868 Mhz RFM12) verwenden.
Die Hardware für den Funk gibt es hier: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" An der Firmware arbeite ich noch. Kannst Du aber auch selber machen. Achtung: Reichweite mit den RFM70 auf innerhalb eines Raumes oder durch maximal eine Wand begrenzt!
Edit: Funk-Hardware Dateien angehängt. Vorheriger Link beinhaltete nur den Kabelsensor...
Cool, danke! Weshalb das RFM70? Wäre das mit RFM12 kompatibel (zu bekommen) oder würde es mit RFM12 auch funktionieren? Und Tray um die Cometen nicht öffnen zu müssen?
So, bin endlich dazu gekommen Knut's Firmware zu flashen... Funktioniert alles soweit, einzig das langsame Blinken beim Einstellen von Zahlenwerten irritiert etwas und Zeitanzeige brauch ich eigentlich auch nicht. Soll- und Istwert-Anzeige ist auf jeden Fall super. Fehlen tut mir eigentlich nur noch ne Kindersicherung ;) Ansonsten - Fuse-Bits konnte ich erst nach dem Flashen setzen - ist das normal? Ausserdem konnte ich nur mit den AVRISPmkII die Fuses setzen - der Mysmartusb light verweigert mit dem mitgelieferten Progtool (AVR-Dude basierend) sowohl das Auslesen als auch das Flashen der Fuses. Flash auslesen klappt jedoch. Mit Atmel-Studio läuft er gar nicht. Ich werde den Mysmartbla wohl zurückgeben und mir was ordentliches holen. Reichelt hat grad den Dragon für rund 40EUR im Angebot...
Conny G. schrieb: > Weshalb das RFM70? Weil klein und günstig und mit Platinenantenne. Conny G. schrieb: > Wäre das mit RFM12 kompatibel Nein. Conny G. schrieb: > würde es mit RFM12 auch funktionieren? Ja, wenn man den Tray umroutet und dem RFM12 eine passende Antenne spendiert. Conny G. schrieb: > Und Tray um die Cometen nicht öffnen zu müssen? Genau. Das Herumfrickeln mit den Schweißnippeln ist alles andere als schön. Andreas K. schrieb: > So, bin endlich dazu gekommen Knut's Firmware zu flashen... > > Funktioniert alles soweit, Gut ;-) Andreas K. schrieb: > einzig das langsame Blinken beim Einstellen > von Zahlenwerten irritiert etwas Schnelleres Blinken schafft das LCD nicht wirklich. Andreas K. schrieb: > Zeitanzeige brauch ich eigentlich > auch nicht. War als Gimmick gedacht, wenn man keine Armband- oder Wanduhr hat ;-) Andreas K. schrieb: > Soll- und Istwert-Anzeige ist auf jeden Fall super. > > Fehlen tut mir eigentlich nur noch ne Kindersicherung ;) Kindersicherung kommt. Die hilft dann auch bei großen Kindern, die andauernd meinen, am Drehrad drehen zu müssen ;-) Andreas K. schrieb: > Ansonsten - Fuse-Bits konnte ich erst nach dem Flashen setzen - ist das > normal? Nö, normal ist das nicht, aber das liegt daran, dass die originale Firmware alle Lockbits gesetzt hat und somit können die Fuses nicht verifiziert werden, was eine Fehlermeldung auslöst. Nach dem Chip-Erase (beim Programmieren) sind die Lockbits wieder gelöscht und somit der Lesezugriff auf die Fuses freigeschaltet. Andreas K. schrieb: > Ich werde > den Mysmartbla wohl zurückgeben und mir was ordentliches holen. Reichelt > hat grad den Dragon für rund 40EUR im Angebot... Der Dragon ist OK für den Preis. Allerdings hat der ein paar Macken. Der AVRISPmkII kann alle Controller flashen, außer im HV-Modus. Das ist wichtig, wenn man mit XMEGAs und neuen TPI-Tinys viel zu tun hat.
Ich freu mich, dass Du der Kindersicherung gegenüber nicht mehr so abgeneigt bist wie am Anfang :) Wegen dem Dragon - kannst Du dessen Macken etwas konkretisieren? Hab schon oft derartige Bemerkungen gelesen, aber das einzige wovon ich weiss ist, dass die In/Outs sowie Spannungswandler nicht so gut geschützt sind (ESD-anfällig, Überspannung) und dass man dagegen noch diverse Schutzmassnahmen vornehmen sollte. Aber von der Kompatibilität her kann er doch alles, was der AVRISPmkII kann plus die High-Voltage-Sachen und Debugging, oder?
Andreas K. schrieb: > Ich freu mich, dass Du der Kindersicherung gegenüber nicht mehr so > abgeneigt bist wie am Anfang :) Hmm, war ich das..? Andreas K. schrieb: > kannst Du dessen Macken etwas konkretisieren? Hab > schon oft derartige Bemerkungen gelesen, aber das einzige wovon ich > weiss ist, dass die In/Outs sowie Spannungswandler nicht so gut > geschützt sind (ESD-anfällig, Überspannung) und dass man dagegen noch > diverse Schutzmassnahmen vornehmen sollte. Das ist das Hauptproblem. Das andere ist, dass es beim PDI mit diversen XMEGAs Probleme gibt und bis heute nichts dagegen getan werden konnte. Andreas K. schrieb: > Aber von der Kompatibilität her kann er doch alles, was der AVRISPmkII > kann plus die High-Voltage-Sachen und Debugging, oder? Prinzipiell ja. Der MkII ist eigentlich für alles und der Drageon für das, was der MkII nicht kann. Ich habe beide Geräte und den Dragon eigentlich noch nie wirklich gebraucht. Debugging mach ich nicht, da ich in Assembler unterwegs bin.
Angehängte Dateien:
-
Comet_Reset_Pin.JPG
110 KB
Meine Bemerkung zur Kindersicherung nehme ich mit Asche auf meinem Haupt zurück - es war ein anderer User, der anfangs mal keinen Bedarf dafür geäußert hat... dumdidum. Nen neuen ISP-Programmer brauch ich jetzt zum Glück doch nicht. Hab den Mysmartusb light 100% zum Laufen bekommen - mit AVR-Dude geht alles - inkl. Fuses und mit Atmel Studio jetzt auch (musste erst per Tools/Add Target nen STK500 hinzufügen...) Ansonsten - Mit der Regelung bin ich echt zufrieden, was jedoch verwirrt ist: wenn Ist>Soll, z.B. 22 statt 19 Grad, dann scheint der Regler immer wieder mal zu versuchen, das Ventil zu schließen, auch wenn es schon auf Anschlag ist. (Es dreht ein paar Sekunden, nicht nur kurz.) Ich weiss dass die Reglung adaptiv ist und das ist auch gut so, mich wundert nur, dass er jetzt scheinbar sogar noch weiter zudreht, als die Originalfirmware und dabei der Motor gar nicht abzusterben scheint. Hab jetzt noch nen 2. Regler aufgebohrt - im wahrsten Sinne :o) - und geflasht - mal sehen, ob der sich genauso verhält... Im Anhang ist noch ein Foto, wo man hoffentlich sieht wie weit oben man den Bohrer ansetzen sollte ohne den Kontakt auf der Platine zu zerstören.
:
Bearbeitet durch User
Andreas K. schrieb: > Hab jetzt noch nen 2. Regler aufgebohrt - im wahrsten Sinne :o) Wow - was für ein Loch :-P! Eins mit 1.5mm und rund hätte auch gereicht (für einen RESET-Draht)... Aber Hauptsache es geht. Andreas K. schrieb: > Ansonsten - Mit der Regelung bin ich echt zufrieden, was jedoch verwirrt > ist: wenn Ist>Soll, z.B. 22 statt 19 Grad, dann scheint der Regler immer > wieder mal zu versuchen, das Ventil zu schließen, auch wenn es schon auf > Anschlag ist. (Es dreht ein paar Sekunden, nicht nur kurz.) Eigentlich schließt er nur so lange, bis entweder der Motor stehen bleibt, oder der Motorstrom einen kritischen Wert überschreitet. Wenn das passiert, wird die Ventil-Zu Marke gesetzt und von dort aus der Fahrweg nach außen berechnet, den er bei der Testfahrt gemessen hat. Diese Vorgehensweise verhindert, dass das Ventil bei Verlust von Getriebepulsen halboffen bleibt und der Heizkörper nicht kalt wird. Ich hoffe, Du hast die neueste Firmware drauf, die ich per e-Mail geschickt hatte? Die Funktion ist noch neu und bisher an 4 Heizkörpern erfolgreich getestet. Beobachte das Verhalten in Bezug auf die Regelung mal genauer. Andreas K. schrieb: > Ich weiss dass die Reglung adaptiv ist und das ist auch gut so, mich > wundert nur, dass er jetzt scheinbar sogar noch weiter zudreht, als die > Originalfirmware und dabei der Motor gar nicht abzusterben scheint. Der Motor geht in jedem Fall aus, wenn das Ventil nicht mehr nachgibt. Zuvor sollte aber die Strombegrenzung greifen. Nutzt Du Batterien oder Akkus? Ich nutze Akkus, vielleicht muss man bei Batterien noch etwas Feinschliff machen, da der Motor mit mehr Spannung natürlich stärker ist.
:
Bearbeitet durch User
Knut Ballhause schrieb: > Wow - was für ein Loch :-P! Eins mit 1.5mm und rund hätte auch gereicht > (für einen RESET-Draht)... Aber Hauptsache es geht. > Is kein Draht - is ein Stück Federblech ;) > Der Motor geht in jedem Fall aus, wenn das Ventil nicht mehr nachgibt. > Zuvor sollte aber die Strombegrenzung greifen. Nutzt Du Batterien oder > Akkus? Ich nutze Akkus, vielleicht muss man bei Batterien noch etwas > Feinschliff machen, da der Motor mit mehr Spannung natürlich stärker > ist. Hm... hab richtige Batterien und werd's weiter beobachten. Auf jeden Fall war das Ventil schon zu (man hört sonst das Rauschen des Wassers durch's Ventil) und der Regler hat ab und an versucht, weiterzudrehen - und das nicht in so kleinen Stückchen wie sonst, sondern durchaus mehrere Sekunden lang. Hatte auch das Gefühl, dass da schon irgendwas im Reglergehäuse auf Anschlag war, kenn jetzt den mechanischen Aufbau leider nicht, aber so als ob das Gewinde zuende ist.
Andreas K. schrieb: > Auf jeden Fall war das Ventil schon zu (man hört sonst das Rauschen des > Wassers durch's Ventil) und der Regler hat ab und an versucht, Dann ist der Druck zu hoch und/oder die Ventilvoreinstellung falsch. Ich hatte bis Ende 2012 eine Standardpumpe im Einsatz und beschissene Regelcharakteristik an den Heizkörperventilen, egal ob konventionell oder elektronisch. Nach Umstellung auf eine 5-Watt-Pumpe habe ich nicht nur Regler, die regeln, sondern auch nur 10KWh für den ganzen Winter gebraucht.
Andreas K. schrieb: > und das nicht in so kleinen Stückchen wie sonst, > sondern durchaus mehrere Sekunden lang. Hatte auch das Gefühl, dass da > schon irgendwas im Reglergehäuse auf Anschlag war, kenn jetzt den > mechanischen Aufbau leider nicht, aber so als ob das Gewinde zuende ist. Das kann durchaus sein. Vielleicht ist der Ventilweg einfach zu lang. Lege mal ein 20ct-Stück in den Adapter, so dass dieses zwischen Ventilstößel und Reglerstößel als Abstandhalter fungiert.
Angehängte Dateien:
-
IMG_2354.jpg
63 KB -
IMG_2352.jpg
99 KB -
IMG_2353.jpg
120 KB
Knut Ballhause schrieb: > Conny G. schrieb: >> Und Tray um die Cometen nicht öffnen zu müssen? > > Genau. Das Herumfrickeln mit den Schweißnippeln ist alles andere als > schön. Ich habe heute meine 2. Lieferung von Cometen erhalten und auch das Wohnzimmer ist nun mit diesen ausgestattet. Habe einen der weiteren geöffnet, bei mir haben die gar keine Schweissnippel, jedenfalls nicht das Gehäuse, nur die Platine? Fotos anbei. Dann wäre es ja gar nicht so schwierig das Funkmodul intern unterzubekommen?
Ach, mal wieder ein neuer Gehäuseentwurf mit Klammern statt Schrauben. Ja, hier könnte man ein Funkmodul unterbringen.
Wenn ich das recht sehe müsste ich gemäß http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#THERMy_V3 nichtmal de Platine lösen, weil Lötpads für SPI vorne/oben sind, wo der "Batteriebügel" anfängt? Ansonsten scheint oberflächlich am weißen Stopplack geurteilt die Platine eher wie Thermy V3 zu sein? Hab ich dann Eurer Einschätzung nach die Portänderungen zu erwarten, die für den Thermy genannt wurden ( wenn ich die Zusammenhänge grade richtig habe)?
Diese Pads sind ja identisch mit dem "USB"-Port, dh ich könnte neue Firmware immer noch darüber, also "von außen", flashen?
Conny G. schrieb: > Diese Pads sind ja identisch mit dem "USB"-Port, dh ich könnte neue > Firmware immer noch darüber, also "von außen", flashen? Ja, solange Deine interne Elektronik nicht dagegenwirkt, also die Portpins in irgendeiner Art so belastet, dass die Programmierpulse nicht mehr durchkommen. Wie Dir vielleicht aufgefallen ist, kannst Du mit den 3 ISP-Pins allein kein Funkmodul ansteuern, weil Du mindestens noch /CS und die Interruptleitung brauchst. Daher musst Du Dich noch an den JTAG-Pads auf der anderen Seite bedienen.
:
Bearbeitet durch User
Conny G. schrieb: > Ansonsten scheint oberflächlich am weißen Stopplack geurteilt die > Platine eher wie Thermy V3 zu sein? > Hab ich dann Eurer Einschätzung nach die Portänderungen zu erwarten, die > für den Thermy genannt wurden ( wenn ich die Zusammenhänge grade richtig > habe)? Weiß jemand?
Neue Programmversionen hier: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" Nur für alten und neuen Comet-Regler und für 2011er und 2012er Thermy verwendbar.
Hi, habe ganz aufmerksam euren Thread verfolgt daraus entstand meine Frage. Und zwar gibt es doch bei jedem z.B. Drucker ein WLAN Modul welches sich im WLAN Netzwerk einbindet, wenn man auf "wireless" drückt. Auf einem Thermy Heizungsthermostat ist doch auch für ein "thermy Progammierstick" eine USB Buchse. Ist es möglich diese mit einer WLAN-Antenne zu verbinden und mit deiner (KNUT) Fireware diese dann mit PC etc. anzusteuern(AN/AUS). Ich bedanke mich herzlich für eine Antwort. Grüße Joh
joh90 schrieb: > Ist es möglich diese mit einer > WLAN-Antenne zu verbinden und mit deiner (KNUT) Fireware diese dann mit > PC etc. anzusteuern(AN/AUS). Sowas gibt es nicht, wäre aber auch nicht so wirklich sinnvoll. Über die SPI-Pins des ISP-Programmers und 3 weiterer Pins die man von drinnen nach draußen legen muss kann man ein nRF24L01+ Modul anschließen. Das Modul sendet zwar auch auf 2.4GHz, aber nutzt ein anderes Protokoll. Man braucht am PC dann auch noch ein nRF24L01+ Modul welches man dann über eine PC-Software anspricht und die Daten mit den anderen Modulen austauscht, so kann man neue Zeit- und Temperatureinstellungen einfach übertragen. Ich nutze diese Module zwar, hab aber noch keines an ein Heizungsthermostat angeschlossen.
Hallo, ich habe ein Problem: Auf meinen alten Meges-Eckventilen funktioniert der Sparmatic Comet nicht, weil er nicht genügend Kraft aufbringt um das Ventil zu schliessen. Ein Sparmatic Basic funktioniert hingegen sehr gut. Wenn ich den Comet testweise mit einem 5V Netzteil versorge, reicht die Kraft um das Ventil zu schliessen. Ich nehme mal an, das Problem ist hier die Strombegrenzung des Motors. Lässt sich evtl. eine Erhöhung der Strombegrenzung mit der Travelrec-Firmware erreichen? Am besten wäre es, wenn man das irgendwie als Parameter einstellen könnte. Oder ist ein HW-Mod die einzige Möglichkeit den Strom zu erhöhen?
Die Strommessung ist eine Sache, die verfügbare Kraft des Motors ist die andere. Wenn das Ventil zu schwergängig ist, bleibt der Motor einfach stehen. Da bringen volle Batterien vielleicht gerade noch genug Energie, aber wenn die Batterien etwas älter sind oder Akkus verwendet werden, reicht´s halt nicht. Bei meinen Heimeier- und Danfoss-Ventilen gab es bisher keine Probleme. Hardware- und Software-Mods bringen hier nichts.
Mit der Original-Firmware hatte ich bisher den Eindruck, dass nicht der Motor abgewürgt wird, sondern dass die Adaptierung deshalb nicht richtig erfolgt, weil die Stromschwelle, bei der abgeschalten wird, zu niedrig angesetzt ist. Jetzt hatte ich daran gedacht einfach den Shunt-Widerstand zu verkleinern mit dem der Strom gemessen wird. Nachdem ich aber nicht viel gutes über die Original-Firmware gelesen habe würde ich auch gerne deine Firmware nutzen. Deshalb die Frage: Verhält sich hier die Strombegrenzung anders als mit der Original-FW? Evtl. könnte ich mir den HW-Mod. dann ja sparen. Mit dem Sparmatic Basic bin ich eigentlich zufrieden. Der regelt schon seit jahren zuverlässig auf meinen schwergängigen Ventilen, fürs Schlafzimmer ist er aber etwas zu laut. Die Comets sind zwar leiser, scheinen sonst aber ein ziemlicher Rückschritt im Vergleich zum Basic zu sein. Das Gummiritzel musste ich beim Comet sogar schon festkleben, weil es immer von der Welle gezogen wurde.
Du kannst die FW gerne probieren, aber ich habe da so meine Zweifel. Für die Sourcen schicke bitte eine PN. Wann hast Du die Comets gekauft? Ich frage wegen des verbauten Controllers...
:
Bearbeitet durch User
Kann ich nicht mehr genau sagen, ich meine Ende 2011 oder Anfang 2012. Ich habe mal einen geöffnet. Der sichtbare Teil der Platine sieht exakt so aus, wie auf dem Bild zum "Comet ThermyV1.5" unter http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate . Die Beschriftung kann ich leider nicht lesen ohne das Ding weiter zu zerlegen. Zum Flashen hätte ich einen USB-ISP Adapter. Ich nehme mal an, den muss ich entsprechend dem Bild mit den 6 Pads links neben dem Drehgeber verbinden, richtig?
Richtig. Oder einen 5-Pin MiniB-USB-Stecker mit zusätzlichem Reset-Pin basteln... Wenn Du Dir wegen des verbauten Controllers nicht sicher bist, probiere einfach beide *.hex mal aus, wenn die Tasten nicht funktionieren, war´s die falsche... Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Ich benötige Heizkörperthermostate mit stark vereinfachter Funktionalität. Können sie mir dazu verhelfen? Mein Wunsch-Thermostat braucht nur zwei Temperaturen und einen Taster. Normalerweise arbeitet er mit der Spartemperatur - z.B. 16°C. Nach Druck auf den Taster schaltet er auf Heiztemperatur - z.B. 21°C. Nach einer Stunde schaltet er wieder automatisch zur Spartemperatur zurück. Ich wäre auch zufrieden, wenn der EUROtronic SPARmatic comet mit entsprechendem Programm arbeiten würde.
Hermann Wegmann schrieb: > Ich benötige Heizkörperthermostate mit stark vereinfachter > Funktionalität. Hermann Wegmann schrieb: > Mein Wunsch-Thermostat braucht nur zwei Temperaturen und einen Taster. > Normalerweise arbeitet er mit der Spartemperatur - z.B. 16°C. > Nach Druck auf den Taster schaltet er auf Heiztemperatur - z.B. 21°C. > Nach einer Stunde schaltet er wieder automatisch zur Spartemperatur > zurück. Ob stark vereinfacht oder nicht macht fast keinen Unterschied. Das eigentliche Programm misst die Temperatur, steuert über den Motor das Ventil, aktualisiert Uhr-Timer und zeigt etwas auf dem Display an. Hier stecken 80% des Programmieraufwandes. Wenn Du die vorhandenen ASM-Sources anpassen möchtest, dann PN an mich senden.
Angehängte Dateien:
-
20150214_151105.jpg
240 KB
Hier ein IOIO HT 2000 sieht stark wie ein Thermy V3 Board aus, nur mit neuer Motro Verbindung. Welche der zwei 3x2 Pads ist der ISP und wie ist dieser Belegt? Kann mir bitte jemand den neusten Source schicken?
Die oberen Pads sind die ISP-Pads. Untere Zeile davon in der Mitte ist Reset. Die anderen Pins liegen ebenfalls an der Mini-USB Buchse. Wegen der Sources habe ich ja Deine E-Mail...
Ist eigentlich das SPI Protokoll der Original Firmware bekannt? Oder muss man auf jeden Fall eine neue Firmware aufspielen um das Thermostat über die vorhandene USB Buchse programmieren zu können?
@ Tobias (Gast) Die vorhandene USB-Buchse + ein weiteres Pad ist doch direkt der ISP-Anschluss des Controllers.
Ja das ist mir bewusst ich meinte eher das Protokoll dass die PC bzw BT adapter benutzen um das Ding über die vorhandene Schnittstelle einzustellen, also Ziel Temperaturen für Tageszeiten usw. (nicht die Firmware flashen)
Das originale Protokoll ist mir nicht bekannt, da ich mir nie einen Programmieradapterstecker gekauft habe.
Hallo Leute, ich betreibe derzeit einen RPi als Thermostat. Bisher wird die Raumtemperatur über einen Heizlüfter konstant gehalten wengen starken Schwankungen in der Heiztemperatur. Ich würde den Heizkörper gerne mit einbinden und denke über eine Steuerung am Ventil nach. Ich möchte aber keine Regelung sondern eine Steuerung da ich die Temperatur am Heizkörper direkt über 2 Sensoren erfasse. Also: Steuerung des Ventils über Comet/Zero direkt ohne Regelung durch internen Temp-sensor und Rückmeldung der Ventilposition über Funk. Eine entsprechende Funktion konnte ich bisher in keiner der Firmwares entdecken. Gibt es hier schon etwas in dieser Richtung? Wenn nicht, hat jemand genug Kenntnis um Abzuschätzen ob das möglich ist?
Möglich wäre das in jedem Fall über die "USB"-Buchse. Im Programm ist dies noch nicht verankert, weil das noch niemand in's Spiel gebracht hat. Willst Du Daten übertragen oder nur 2 Pins für "Motor auf/zu" bedienen?
Hallo zusammen, super, dass sich jmd dieser Arbeit annimmt. Hatte bisher den Ansatz nur Motor und Getriebe zu verwenden und mit einem Arduino Nano oder so anzusteuern. Ich habe bereits ein 2,4Ghz Funknetz mit NRF24L01 Chips zu meinem Raspberry Pi. Könnte man diesen Funkchip an den Sparmatic Comet anbinden und dann darüber konfigurieren? Das wär hammer. Anbei gibt es bei Real online das Teil zur Zeit für 9,90 und ohne Versandkosten. Aber scheint wieder eine andere Version zu sein. Grüße
Dominik schrieb: > Hallo zusammen, > > super, dass sich jmd dieser Arbeit annimmt. > Hatte bisher den Ansatz nur Motor und Getriebe zu verwenden und mit > einem Arduino Nano oder so anzusteuern. Ich habe bereits ein 2,4Ghz > Funknetz mit NRF24L01 Chips zu meinem Raspberry Pi. > Könnte man diesen Funkchip an den Sparmatic Comet anbinden und dann > darüber konfigurieren? Das wär hammer. > > Anbei gibt es bei Real online das Teil zur Zeit für 9,90 und ohne > Versandkosten. Aber scheint wieder eine andere Version zu sein. > > Grüße Sorry. Also geht in die Richtung von thekk, nur ich habe schon konkret die Funkchips rumliegen.
Ja kannst den Mega169P der drin ist an dein NRF24L01 hängen. Musst nur selbst die FW anpassen oder neu schreiben. Kannst ja ma googeln ob es Board Settings für den Mega169P gibt das du den mit der Arduino IDE bespielen kannst.
Angehängte Dateien:
-
THERMYV3-sch.gif
170 KB
Hallo all, I have got the Thermy with White PCB disassembled. I am having trouble in understanding the current measurement for the motor and battery voltage measurement. In particular the circuit comprising of R18, R20, D3 and C9 is unclear to me. Is the pin PE5 used for power loss detection? If so, how is this done? Also why is there separate GND and 0V? I would appreciate if someone could clear these points to me. I have attached the schaltplan for the Thermy v3 which I believe is the latest. Thank you. Best regards.
Owais Fazal S. schrieb: > In particular the circuit comprising of R18, R20, D3 and C9 is unclear to > me. Current sensing for the valve motor. If the valve is fully closed, the current rises beyond a limit, and the software turns the driver circuitry off. This is used to auto-calibrate the valve position. > Is the pin PE5 used for power loss detection? Seems so. > If so, how is this > done? Without looking into the software, if you turn on the pullup of that pin, and the input reads back "high", the battery has obviously been removed. > Also why is there separate GND and 0V? So the controller itself can be powered off the electrolytic capacitor while the battery is absent.
Jörg, you are right with every point. @Owais: Sorry for not answering to your e-Mail these days. I´m a bit busy.
Hallo Jung, Thank you for your prompt response. I have measured the motor current and found out the stall current to be about 130mA whereas normal current draw of the motor when it is running is about 56mA. Can you please explain exactly how does the parallel arrangement of the resistor R18 and R20 help in measuring the current. I understand that the current measurement can be carried out using a shunt which I believe in this case is R18 2R2. On the software side the voltage drop on R18 can be measured using ADC and then current can be calculated using V/2R2. Please let me know if I understood this part correctly. Thank you.
Thermy gibts gerade bei Aldi Nord für 6€ in der Restekiste
Owais Fazal S. schrieb: > how does the parallel arrangement of the resistor R18 and R20 help in > measuring the current R18 is the shunt, R20 / C9 just form a lowpass filter (integrator).
@Jorg: Thank you for your response. If I understood correctly, normally c9 would present a large resistance due to DC current and voltage drop on R18 is measured as follows: Vin = ADCVal * Vref / 1024 And then current as: Imot = Vin / 2.2 Am I getting this right? @Knut: I realized you would be busy otherwise you respond quite fast ;) Thank you all.
Owais Fazal S. schrieb: > Am I getting this right? Basically yes. The R20/C9 lowpass just causes some additional delay, in the range of 1 MΩ · 100 nF = 100 ms.
@Jorg: Thanks for clearing that.
With the current measure it is not recommendet to wait for motor stall position - better switch the driver off, if the current reaches 100mA. This is enough to close all common valves. Higher forces may destroy the locking clamps. It is furthermore possible to detect the touch of the valve tip. This way you have the complete valve track as position values avaliable for calculation. Compared to the freewheeling current, the touch current is 10 or more percent higher.
:
Bearbeitet durch User
@Knut: Thank you for your suggestions. Is there a latest firmware for the Thermy shared on this forum? If so, I would be grateful if someone could share the link.
As I remember, I sent it to you, or am I wrong?
@Knut: Sorry, I have rechecked the conversation but there is no attachment. Can you please send it over again.
OK, will send you an e-mail tomorrow. Stay tuned...
@Knut: Thank you. I have tuned in ;)
Ahh - sorry, was out this week end. Try to send you the stuff today...
No problem, I am still tuned in :)
Hello, I have going through the alternative firmware for the Sparmatic Zero contributed by Matthias. What I can't seem to grasp is that how the PID output value is being translated into valve position. I understand that the control variables are all scaled by a factor of 256 as mentioned in the source code but since the output of the PID controller would be in deg/time-unit how is this translated to motor position exactly? Any help would be appreciated in this regard. Thank you. Regards.
Hi, I sent you another e-Mail. Owais Fazal S. schrieb: > I have going through the alternative firmware for the Sparmatic Zero > contributed by Matthias. Please be sure, that some things will not work on the Comet or Thermy, that are primary designed for the Zero. Different pinouts and a different display is used in each of the different device types.
Hello, @Knut: I have received the other e-mail. Thank you for the detailed clarification. Moreover, I understand that there are variations in the designs and some are not exactly pin compatible. I am just going through the control technique used here and then I will modify everything accordingly. Thanks for the heads up anyway :) Regards.
Guten Abend, Ich hab jetzt eine Zeit lang gelesen einiges Probiert, aber ich komm nicht weiter. Vielleicht liegt es einfach auch daran, dass ich bisher kaum was großes im Bereich AVR gemacht habe. Nun wollte ich einfach mal fragen gibt es im Moment ein fertiges "Paket"/"Projektmappe" oder eine funktionierende Version für den THERMy V3 mit den ATmega169PA. Ich brauche diese Custom Firmware einfach nur um über einem Bus mit dem Thermostat zu kommunizieren. Vielen vielen dank schon mal. Gruß Fabian
Was hast Du probiert und wo kommst Du nicht weiter? Welche Programmiersprache nutzt Du? Ich kann Dir ASM Sourcen schicken, wenn Du mir eine PN schickst. Dann kannst Du Dir die verschiedenen Module ansehen und bekommst vielleicht eine Ahnung von den internen Abläufen, um so die Firmware an den "Bus" anzupassen.
Guten Morgen, ich habe schon verschiedene Firmware's auf den THERMy v3 gespielt, aber bei jeder funktioniert etwas anderes nicht. Ich hab es mit: - OpenHR20_1.0 (Mit der Firmware funktioniert gar nichts.. Tasten, Motor ohne Funktion) - OpenZero (der Stellmotor spielt verrückt. Bei der ADAPT fahrt funktioniert er noch anschließend fährt er dauerhaft auf "zu" und stoppt nicht) - und mit Sparmatic_Comet_M169_ATM6_2013_03_29_V005c.rar (wie bei OpenHR20_1.0) probiert. Am liebsten wäre mir die Programmiersprache C. Ich will über einen CAN oder RS485 Bus (hab mich da noch nicht so festgelegt) die Soll Temperatur setzen. Danke Gruß Fabian
Hello, I have been going through the Sparmatic Zero firmware contributed by Matthias. I am having trouble in understanding the Programming part of the code in the files Programming.c if someone here has already gone through the code and could clear a few things regarding how the Program Data is maintained in the ProgramData array I would appreciate the help. Thank you. Owais.
Fabian W. schrieb: > - und mit Sparmatic_Comet_M169_ATM6_2013_03_29_V005c.rar (wie bei > OpenHR20_1.0) Du brauchst für den Thermy v3 eine entsprechende Firmware. Alle Versionen vor v006 sind nur für den Comet v2. Für den Thermy v3 und Comet v3 muss die Firmware für den Mega 169PA assembliert werden. https://www.mikrocontroller.net/attachment/244838/Sparmatic_V3_Thermostat_M169PA_ATM6.hex
Hi, da es bei Lidl gerade wieder Silvercrest Thermostate (Thermy V3?) im Angebot gibt, hab ich mir mal einen zugelegt und überlege ob ich nicht einen ESP8266 als MQTT Schnittstelle noch anbauen könnte. Laut dem Schaltplan der V3 wäre auch noch eine serielle Schnittstelle frei. Ich wollte fragen, ob jemand so freundlich wäre und mir den Sourcecode für den Thermy V3 zur Verfügung stellen könnte? Vielen Dank und viele Grüße.
Hallo Stefan, bist du fündig geworden? Ich habe mir auch iene paar Comet V3 zugelegt und würde die auch gerne zentral steuern ... MQTT und OpenHab stehen da ganz oben auf meiner Liste. Da gibt es auch ein Arduino Projekt dazu: https://forum.arduino.cc/index.php?topic=371928.0. Über den ESP8266 habe ich nur gelesen, dass er für einen Batteriebetrieb viel zu viel Strom zieht ;-( lG Gerhard
Hallo Gerhard, leider hab ich noch keinen Sourcecode für den Comet V3 :( MQTT und OpenHAB wäre auch meine bevorzugte Kombination... Ich schau mir das Arduino Projekt mal an. Das mit dem ESP8266 stimmt so nicht ganz.. Er verbraucht nur viel Energie wenn er permanent mit dem WLAN verbunden ist und rechnet. Im Deep-Sleep kann man ihn sehr lange mit einer Batterie betreiben. In meiner RoomNode betreibe ich einen ESP8266 mit einer 720mAh LiPo Akku der jede Minute aufwacht Raumdaten (Temperatur, Luftfeuchte, Fensterstellung, ...) erfasst diese im MQTT Broker ablegt und dann wieder schläft. Diese muss ich nur jedes Jahr einmal aufladen. Ich denke ein ähnlicher Betriebsmodus für die Thermostate wäre denkbar. Die Aktoren reagieren dann zwar nicht sofort sondern im worst case erst nach 1 Min. aber beispielsweise bei Z-Wave ist es auch so gelöst und es scheint niemand zu stören, zumal das Ansprechverhalten von Heizkörpern eh träge ist... Wenn du Interesse an einem entsprechenden Projekt hast können wir uns darüber gerne mal näher austauschen
Tobt euch aus - keine Garantie für nichts - kein weiterer Support - Assembler...
Knut B. schrieb: > Tobt euch aus - keine Garantie für nichts - kein weiterer Support - > Assembler... Vielen Dank, Knut. Ich finde es wäre höchste Zeit für eine Portierung nach C. Für mich und für viele andere ist das ein Blocker Erweiterungen zu machen, da die "Community" hinter Assembler halt ein Zehntel so gross ist wie die hinter C/C++. Ich wollte schon lange mal ein RFM-Modul dranhängen (habe inzwischen 6 der Regler im Einsatz), aber das Fehlen von Source in C hat mich immer dran gehindert. Der Zeitaufwand mich (wieder) mit Assembler zu beschäftigen ist einfach zu hoch, hab das vor 20 Jahren zuletzt gemacht.
Conny G. schrieb: > Ich finde es wäre höchste Zeit für eine Portierung nach C. Weiß ich doch, aber nicht für mich. Kümmert euch drum. Von ASM nach C ist ohnehin einfacher, als andersrum ;-). Hab aber keine Zeit, mich weiter der Sache anzunehmen. Meine Themostaten laufen, wie ich es brauche, mehr ist nicht...
Knut B. schrieb: > Von ASM nach C ist ohnehin einfacher, als andersrum ;-). Gut, dass du einen Smiley dahinter geschrieben hast. :) Die andere Richtung erledigt innerhalb von Sekunden ein Compiler … Ich hatte vor einiger Zeit mal vor, dein Assemblerprogramm wirklich zu verstehen, aber so viel Zeit hatte ich dann leider doch nicht.
Die andere Richtung erledigt innerhalb von Sekunden ein Compiler … Ja sicher, aber wenn Du C-Code in ein reines Assemblerprogramm wandeln willst, da Du nur Assembler kannst oder willst, dann krigste graue Haare ;-)!
OK, ein lesbares Assemblerprogramm ist natürlich was anderes als das, was ein Compiler gemeinhin rauswirft.
Jepp. Das kann man zwar deuten, aber ohne Marken und Kommentar ist es nur was für Maschinen oder Komplett-Cracks ;-).
Kommentare kannst du dir generieren lassen, bis hin zum kompletten Einbetten des C-Codes. Bringt aber nicht unbedingt viel, weil der Compiler durch die Optimierung auch schon mal im C-Code hin und her hüpft.
Zuerst einmal DANKE an Knut für den Code! Stefan M. schrieb: > Wenn du Interesse an einem entsprechenden Projekt hast können wir uns > darüber gerne mal näher austauschen Ja, würde ich gerne! Aber ich muss dich warnen: bei mir ist's mit programieren nicht weit her; ich bin eher der Code-Schnipsel Sammler und ein paar kleine Anpassungen schaffe ich dann auch selber;-) Wenn du auf Bais des ESP8266 schon einen stromsparenden RoomNode hast so könnte man den doch erweitern?!?
Ja die Idee es nach Arduino zu portieren hätte schon Charme. Der Verlinkte Eintrag auf arduino.cc scheint mir ein wenig sehr wirr und da du wohl auch noch keine Antwort auf die Frage nach den Sourcen bekommen hast, hab ich mal eine Hardware Portierung angefangen. Die erste Version mit der man den Code übersetzen und per avrispmkII auf den Regler spielen kann habe ich unter: https://github.com/geeks-r-us/arduino-cometv3.git als öffentliches Repo abgelegt. Einfach einen Checkout ins Arduino/Hardware Verzeichnis durchführen und die aktuelle Arduino Version sollte Comet als neue Hardware anzeigen. Ich habe die Pin Assigns einfach mal runter geschrieben die kann man aber noch anpassen wenn es anders mehr Sinn macht. Die Timer habe ich auch noch nicht zugewiesen... Der Plan wäre jetzt noch passende Bibliotheken für LCD, Encoder, Motor, etc. zu schreiben (ich hoffe ich verstehe da genug ASM um mir etwas aus den Sourcen von Knut abzuschauen) um dann die Steuerlogik möglichst einfach und flexibel halten zu können. Eine Brücke per SPI oder UART zum ESP um WLAN und MQTT anzusprechen ist dann wieder eine der leichteren Aufgaben :)
Ja, die neue Hardware sehe ich (OS X mit Arduino 1.6.11) > Der Plan wäre jetzt noch passende Bibliotheken für LCD, Encoder, Motor, > etc. zu schreiben (ich hoffe ich verstehe da genug ASM um mir etwas aus > den Sourcen von Knut abzuschauen) um dann die Steuerlogik möglichst > einfach und flexibel halten zu können. Vielleicht hilft das https://github.com/gnbl/sparmatic2011 als Quelle für die LCD Bibliothek?
Angehängte Dateien:
-
IMG_1781.jpg
220 KB -
IMG_1760.jpg
210 KB -
IMG_1768.jpg
210 KB -
IMG_1776.jpg
210 KB -
IMG_1778.jpg
230 KB -
IMG_1780.jpg
240 KB
Nur zur Info: Conrad u.a. verkaufen den "Sygonix HT100" bzw. "Sygonix HT100bt", letzterer mit integriertem BT4.0-Modul. Sygonix ist eine Conrad-Hausmarke. Beide Regler basieren auf dem Thermy(V3). Die Software von Knut läuf auf der Version ohne BT bei mir prächtig. Das Gehäuse ist ein bisschen größer und der Anschluss an das Ventil erfolgt mit Verschraubung (was ich persönlich besser finde als die blöde Klickrastung). Das Display ist etwas größer, was mir mit meinen alten Augen sehr entgegen kommt. Ich habe beide Regler mal aufgemacht und kurz durchgetestet. ISP und JTAG sind nur als Testpads vorhanden. Pads mit UART-Belegung sind vorhanden (an denen hängt bei der BT-Version ein CC2541-BT-Modul). Dann gibt es noch eine rote LED, die in der Original-FW immer dann leuchtet, wenn das Ventil voll geöffnet wird. Hauptsache, es blinkt irgendwas ... ;-). Ein bisschen klobig die Teile, aber mir gefallen sie besser als die Aldis. juju PS: Einen herzlichen Dank an Knut, der die (wohl) einzige bisher lauffähige FW hier eingestellt hat. Ein bisschen Assembler tut ja auch nicht weh.
Gibt es denn schon weitere Fortschritte? Stefan M. schrieb: > Die erste Version mit der man den Code übersetzen und per avrispmkII auf > den Regler spielen kann habe ich unter: > > https://github.com/geeks-r-us/arduino-cometv3.git > > als öffentliches Repo abgelegt. > > Einfach einen Checkout ins Arduino/Hardware Verzeichnis durchführen und > die aktuelle Arduino Version sollte Comet als neue Hardware anzeigen. Ich würde die Umsetzung für Arduino gerne unterstützen, programmieren ist kein Problem, allerdings Zeit... Ich kann die Beispiele in der Arduino IDE Übersetzten und bekomme im Display meines Thermy V3 auch etwas angezeigt. Die Übertragung mit USBasp geht aus der IDE leider (noch) nicht, musste ich von Hand mit avrdude machen. Gibt es weitere Leute, die daran Entwickeln, sodass man sich irgendwie abstimmen kann und und nicht Arbeiten doppelt macht? Gibt es schon Code, den man evtl. mit einfliessen lassen kann? Ein ganz grosses Dankeschön an Knut, der eine funktionierende Firmware aufgebaut hat und den Code hier zur Verfügung stellt. Leider funktioniert die Regelung bei mir mit der Firmware von Knut nicht, er versucht zwar zu regeln, öffnet aber das Ventil nicht weit genug, sodass kein Wasser fliesst. Ich vermute die Offen-Position wird nicht richtig erkannt.
Wenn das Ventil nicht weit genug öffnet, ist der Regler defekt oder von einer Version, zu der die Firmware nicht passt. Zwischen den verschiedenen Versionen, die im Laufe der Zeit auf den Markt kamen, gab es einige Umbelegungen von Pins, sowie einen Controllerwechsel. Das Erkennen des Ventilstößels ist beim Adaptieren verifizierbar anhand der beiden linken Bargraf-Segmente: das erste erscheint, wenn der Freilauf erkannt wurde und das zweite, wenn Kontakt zum Stößel besteht. Prüfe mal das Erscheinen der Segmente.
Hallo Ronny, ich freue mich über jede Hilfe :) Wie bei dir war es bei mir die letzten Wochen ein Zeitproblem neue Dinge zu committen. Ich hab mir aber für die nächsten Tage noch vorgenommen die Motoransteuerung fertig zu bekommen. Damit wären denke ich Hardware voll verwendbar und man kann sich Gedanken über die Funktionen und deren Umsetzung machen. Ich kann in die Arduino Konfiguration gerne noch den USBasp mit aufnehmen. Da ich aber keinen habe würde ich das Testen dir überlassen bzw. du kannst dich natürlich auch selbst daran versuchen. Eine grobe Beschreibung wie du die Konfiguration erweitern kannst findest du hier: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification Ich nehme das dann gerne auch mit ins Repo auf.
Jürgen H. schrieb: > Beide Regler basieren auf dem Thermy(V3). Es gibt hierzu mindestens einen Unterschied: Die Anschlüsse 2 und 3 (serielle Schnittstelle) sind bei der Version mit BT irgendwie verdrahtet, ich habe aber nicht herausfinden können, was da dran hängt. Gruss Robert
Stefan M. schrieb: > Damit wären denke ich Hardware > voll verwendbar und man kann sich Gedanken über die Funktionen und deren > Umsetzung machen. Ok, dann versuche ich mich mal am Menu, falls mir nicht doch noch etwas besseres einfällt (z.B. RTC). Knut B. schrieb: > Das Erkennen des Ventilstößels ist beim Adaptieren verifizierbar anhand > der beiden linken Bargraf-Segmente: das erste erscheint, wenn der > Freilauf erkannt wurde und das zweite, wenn Kontakt zum Stößel besteht. Danke für die Info, habe heute mal noch ein paar Dinge probiert. Die Segmente werden wie von dir beschrieben angezeigt. Allerdings hört man schon kurz nach Start der Adaptionsfahrt, das der Motor schon gegen das Ventil arbeitet, hier schaltet sich dann auch irgendwann das erste Segment ein. Wenn es schwer wird kommt dann das 2. Segment. Die Debug-Werte sind dann nach 2 Regelversuchen folgende (soll 40°, ist 21°): 24 FUZZ 66 POSI 66 VTOP 16 RWAY 384 VBAT Danach passiert nichts mehr. Das ist an einem Danfoss-Ventil. An der FBH im Bad ist am Rücklauf ein Heimeier, habe den NTC an ein Kabel gemacht und den Thermy dort ca. 2 Stunden laufen lassen. Hier funktionierte die Regelung, VTOP war hier 174. Der Stößel der Danfoss Ventile scheint bei "voll offen" ziemlich dicht am Regler zu liegen. Schraube ich den Klemmring des Thermys 1/2 Umdrehung locker, um den Abstand zu vergrößern, so bekomme ich VTOP 181. So funktionierte die Regelung dann auch mehrere Stunden, das kann man so aber nicht dauerhaft betreiben. Habe es auch mit einem 2. Thermy probiert, ein Problem mit der Hardware würde ich daher ausschliessen. Die Thermys wurden auch vor kurzen erst gekauft. Habe auch eins geöffnet, sieht aus wie hier auf den Bilden, weisse Platine.
OK, dann liegt es wohl tatsächlich am Ventil. Der Motor erreicht den Freilauf nicht, da er schon direkt nach dem Anlauf auf den Stößel drückt. Somit wird das Ventil später nicht voll geöffnet. Ich habe auch solche Dannfoss-Ventile, aber da klappt es noch. Der Motor muss etwa 1 Sekunde frei drehen können, so wie die Ventilerkennung jetzt programmiert ist. Im Betätiger des Reglers ist in der Mitte eine kleine Erhebung, vielleicht kannst Du diese wegschleifen. Dadurch müsstest Du genug Luft bekommen.
OK, danke, dann wäre das also klar. Die Idee mit dem abschleifen hatte ich auch schon. Im Moment sind aber alle wichtigen Heizkörper mit Thermys versehen und mit der original Firmware tun die erstmal was sie sollen. Nur würde ich sie gerne fernsteuern... Eine ganz andere Idee wäre, den NTC durch ein Digital-Poti zu ersetzen (z.B. X9C104) und dem Thermy so ferngesteuert über ein Mikrocontroller falsche Temperaturwerte vorzumachen. Dieser Weg wäre sicher einfacher als eine Firmware zu entwickeln die sich fernsteuern lässt. Allerdings wären dann auch die restlichen Funktionen, Display etc. nahezu nutzlos. Hatte schon jemand diese Idee?
Fernsteuern ginge über die USB-Buchse. Ich habe modifizierte Firmwares, die ein Dongle an der USB-Buchse auslesen, welches entweder einen externen NTC abfragt oder ein Funkmodul RFM70 enthält. Dies ist aber mangels WAF nie zur Perfektion getrieben worden aber vielleicht reicht es ja als Idee. Die USB-Buchse stellt immerhin 3 Controllerpins zur Verfügung (SPI), damit kann man schon was anfangen, zum Beispiel synchrone Interfaces oder einen kleinen ATTiny ansteuern...
Wie einige Beiträge bereits andeuten, ist dr Thermy auch mit BT erhältlich. Ich habe einige davon. Ich habe allerdings keine Erfahrung mit der Decodierung des Interfaces zwischen BT und Thermy. Ich werde erst in den nächsten Tagen meinen Logic analyzer starten. Grüsse Robert
Seit heute gibt es bei Lidl den Regler RT200BT mit Bluetooth, die den Thermys sehr ähnlich sehen und auch sind. Habe mir mal 2 gekauft und einen davon zerlegt. Das Display erscheint auf den ersten Blick kleiner als von den Thermys, ist aber gleich groß. Der Bluetooth Chip ist vom Typ DA14580, wenn ich die Leiterbahnen richtig verfolgt habe, ist der an RX TX (PE0 PE1) am 169PA angeschlossen. An den 4 Testpunkten im Batteriefach ist das ISP Interface mit folgender Belegung: Reset, MOSI, SCK, MISO. Zusammen mit den Batteriekontakten (+/-) lässt sich so der 169PA Programmieren ohne das Gehäuse zu öffnen. Die Beispiele aus dem Arduino Projekt funktionieren, Temperatur wird angezeigt und Tasten/Drehrad funktionieren. Die Firmware von Knut lässt sich zwar aufspielen, allerdings piept der Motor nur kurz und es wird OFF angezeigt und bleibt stehen. Vermutlich wird aus irgendeinem Grund ein zu niedriger Batteriestand festgestellt. Es fehlt auch irgendwie der große 100uF Kondensator? Den Bluetooth-Kontroller zu benutzen dürfte aber schwierig werden, Ich kann den Regler nur mit der EUROprog App finden, sonst nicht. Die Regler sind also versteckt, ohne weitere Infos kommt man da nicht ran. Man müsste dann also auch noch an die Firmware des DA14580.
In den Thermy BT-steuerbaren Geräten sind TI CC2541 als BT-Controller verbaut. Datenblatt ebenda verfügbar, Anschlussbelegung folgt gelegentlich.
Ja, versuch mal was du da heraus bekommen kannst. Ich könnte mir aber vorstellen, das die Sygonix HT100BT ebenfalls versteckte BT-Geräte sind und man auch an die Firmware des CC2541 ran muss. Gesteuert werden die ja auch mit der gleichen EUROprog APP. Oder kannst du den Regler außerhalb der APP als Bluetooth-Gerät sehen? Wie Stefan M. schon schrieb, wenn wir erstmal eine eigene Firmware auf Arduino Basis haben, wären solche Erweiterungen ja vergleichsweise einfach machbar. Ich bastle immer wenn es meine Zeit erlaubt am Menu für den Thermy herum, habe schon gute Fortschritte gemacht, evtl. gibt es demnächst mal ein kleines Demo.
Aus anderen Quellen verlautete bereits, dass die Firmware läuft, aber ohne BT.
:
Bearbeitet durch User
Den RT2000BT, der unter der Lidl-Hausmarke "Silvercrest" vertrieben wird, gibt es auch in einer anderen Hardwareversion, von mir gestern in Berlin gekauft (für 18 EUR). Hier werden zwei Platinen verwendet, die von Jürgen hier Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" schon gezeigte Platine mit einem CC2541 darauf (und der Beschriftung "RF-BLE-00-02"), und eine andere, neue Hauptplatine. Die sieht komplett anders aus als die von Ronny hier Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" gezeigte Variante und ist mit "CT_RF 02-00" beschriftet. Der Controller darauf ist der gewohnte Atmega169PA, er ist wie bei Ronny auch auf die Platinenoberseite gewandert. Zusätzliche Kontakte im Batteriefach gibt es keine. Bilder von der neuen Platine folgen, die Grundform ähnelt der hier gezeigten: Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"
Knut B. schrieb: > Tobt euch aus - keine Garantie für nichts - kein weiterer Support - > Assembler... Wenn ich das Teil auf meine älteren Regler (vermutlich V2) flashe, sehe ich nur noch ein "OFF" nach dem Start, aus dem es nicht wieder herauskommt. Egal, ob ich nun dein Hexfile nehme oder es selbst für einen ATmega169A assemblieren lasse. Die frühere Firmware von dir funktionierte zumindest größtenteils (auch wenn sie den heutigen Tag für einen Freitag hält ;).
Hallo Jörg, gib mal bitte mehr infos, was genau Du worauf geflasht hast. Gerne auch per Mail, um den Thread nicht zu überfrachten. Meine Regler (V2 und V3) spielen alle ganz ordentlich. Wenn Du OFF angezeigt bekommst, passt die verwendete Firmware nicht zum Pinning des Controllers oder aber die Batterien sind leer, was ich aber nicht glaube. Edit: Ach, ich sehe schon, Du hast die V3 Firmware auf einen V2 Regler gespielt. Nee, das geht nicht, weil die anders angeschlossen sind und der Batterietest somit fehlschlägt. Weiterhin liegt die Lichtschranke auf anderen Pins. Du kannst ja mal die Pläne vergleichen und die Sachen selber ändern und den Batterietest erst mal 'rausnehmen. Ich weiß aber nicht wie das bei den alten Reglern mit der Motorstrommessung funktioniert, ich glaube, da war auch noch ein Unterschied. Wenn das Datum nicht zum Wochentag passt, dann ist wahrscheinlich das Jahr falsch eingestellt. Das kann passieren, wenn das EEPROM beim ersten Anlaufen der Firmware auf 0xFF steht und man das erste Mal das Jahr einstellt und die Begrenzung auf 100 noch nicht greift. Der Kalender funktioniert nur bis 2099.
:
Bearbeitet durch User
Knut B. schrieb: > Du hast die V3 Firmware auf einen V2 Regler gespielt. Nee, das geht > nicht, weil die anders angeschlossen sind und der Batterietest somit > fehlschlägt. OK, ist das in der Firmware irgendwie als .ifdef gelöst, oder sind deine Firmware-Sourcen für V2 und V3 in der Tat völlig separat? Edit: die Frage kann ich mir nach einem Vergleich deiner alten V2-Sourcen und der oben geposteten für den V3 selbst beantworten: die sind ziemlich unterschiedlich.
:
Bearbeitet durch Moderator
Jojo, das sind 2 unterschiedliche Epochen, bei V3 hatte ich die Menü-Steuerung noch überarbeitet, weil die alte ziemlich frickelig war. Die Motoransteuerung wurde um die Strommessung erweitert und die Pinumbelegung wurde eingepflegt. Dann hatte ich noch mit externen Modulen zur Fernsteuerung herumgespielt, aber das ist leider nie ganz fertig geworden... :-(
Dann melde ich mich auch mal wieder zu Wort. Nach einem ärgerlichen Hardwaredefekt über die Feiertage habe leider nicht so viel von dem Dingen geschafft, die ich mir vorgenommen habe :( Was ich noch geändert habe: Ich habe noch eine Hardware für den Zero+ hinzugefügt und die Input Bibliothek angepasst, so dass sie nun auf beiden Plattformen die vorhandene Hardware unterstützen. So ist es dann auch einfacher noch eine Variante mit Bluetooth zu unterstützen. Woran ich aber immer noch hänge ist die Motorsteuerung. Der Motor will sich einfach nicht bewegen. Ich habe den aktuellen Stand eingecheckt und ein minimales Beispiel für die Motorsteuerung dazu gepackt. Würde mal jemand drüber schauen / testen ob ich da einen Denkfehler drin habe oder ob ich nach einem Hardwareproblem suchen muss?
Ich werde es mir bei Gelegenheit mal ansehen, wird aber frühestens am Wochenende etwas. Um ein Hardwareproblem auszuschliessen könntest du ja mal Knuts Firmware flashen. Ich meine auch irgendwo gelesen zu haben, das man sich die Transistoren der H-Brücke zerstören kann, wenn man diese falsch ansteuert. Mit dem Menu bin ich leider auch noch nicht viel weiter gekommen. Anbei aber mal eine kleine Demo, sollte auf V3 Kompatiblen laufen. In MODE, FENS und OFFS lassen sich mit OK weitere Ebenen/Funktionen aufrufen. Das Menu hängt am Interrupt und basiert auf Tabellen, also keine komplizierten switch ... case. Den Quellcode gibt es natürlich auch noch, sobald ich weitergekommen bin.
Hi, sorry for writing in English, but I cannot speak German (used google translator to sort of understand last few posts). My question is simple: is there a way how to remotely communicate with RT2000 or RT2000BT? And I don't mean that euroProg application, I mean custom communication, with messages like "open the valve to xx %", "get current temperature", "get battery level" (well, that's almost everything I need). So either via 2.4GHz or 433/866 MHz, with battery life at least 6 months. Is there such solution? Thanks
We are working on such a solution, but due to lack of time it maybe need some months before we are getting it to work. At least for 433/866MHz or WLAN(ESP8266) it should be possible. But for the built in Bluetooth I'm sceptical, because of the BT device of the RT2000BT is "undiscoverable", so we have to change the firmware of that BT device too. But it would be great, if you can help out for programming.
I'd really like to help, but I am afraid I am noobie in this area. I can code, C is fine for me, but I am just starting "doing" into the hobby (for which we have great czech word 'bastleni' coming from German - basteln ;), I have my first few wemos d1 minis on the way and I'll be doing my first tests with it. The reason I am asking here is that here, in Czech Republic, they have the Silvercrest valves on sale starting next monday, for some 12 EUR, so I am considering buying few (3 pcs) and give them a try. The next less expensive solution for me is eQ-3 Max cube + valves which is about 150 EUR... But I got quite OT now. I will follow this topic and if I can help with anything, I'll try. Have a good day
Angehängte Dateien:
-
K1002692.jpg
230 KB -
K1002693.jpg
230 KB
Anbei die am 14. schon angekündigten Bilder der neuen "Thermy"-Variante, die es vor nunmehr zwei Wochen bei Lidl unter der Eigenmarke "Silvercrest" zu kaufen gab. Die aufgesteckte BT-Platine entspricht exakt der von Jürgen hier Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" gezeigten, daher verzichte ich auf weitere Bilder davon.
Stefan M. schrieb: > Der Motor will sich einfach nicht bewegen. Habe mir den Code nun mal angesehen, der Motor läuft bei mir. Der geänderte Code ist im Anhang. Habe mich bei der Ansteuerung der Pins an Knuts Code orientiert. Anbei auch noch ein lauffähiges Beispiel mit meinem Menu, im DBUG gibt es nun MOTO und man kann mit dem Rad den Motor steuern und mit OK wieder stoppen. Das verwendet jedoch anderen Code, es werden einfach die Pins je nach Zustand gesetzt. Testen bitte auf eigene Gefahr. Einen Interrupt über den Sense-Pin scheine ich jedoch nicht zu bekommen. Ich denke die Motorsteuerung könnte man noch weiter abstrahieren. Vielleicht mit einer Klasse "Valve", welche im Wesentlichen nur die Funktionen open() und close() kennt. Als Parameter dann nur einen Wert, um wieviel geöffnet/geschlossen werden soll. Wofür ist eigentlich der 1K Widerstand an PE5 des Thermy V3?
Danke für deinen Test Ronny. Ich hab deine FW mal aufgespielt - dein Menü sieht gut aus :) leider keine Reaktion im Motor Menüpunkt. Ich hab die Anpassungen übernommen aber leider das selbe... vermutlich hab ich die Brücke gegrillt.. werde mich mal auf die suche nach passendem Ersatz umschauen. Den Interrupt habe ich nochmal raus genommen um die Fehlerquellen zu suchen. Hier wollte ich auch noch etwas schöneres machen als die ISRs in der ino-Datei. Das wäre auch mein Plan gewesen der Motorklasse nur wenige public-Funktionen für die Positionierung zu geben. Das Problem ist noch, dass die Motorsteuerung evtl. ja asynchron zum Rest ausgeführt und überwacht werden sollte.
Hast du es mit Batterien probiert? Am ISP ohne Batterien geht es bei mir auch nicht und zum testen deiner Hardware könntest du mal die FW von Knut nehmen. Ich stelle mir die Motor bzw. Valve Klasse anders vor. Die Regelung muss ja einfach nur sagen, um wieviel das Ventil geöffnet bzw. geschlossen werden soll, also z.B. 10%, 20%, 50% oder nur 1% (evtl. normiert auf 255). Wenn der Motor also schon 50% offen ist und die Regelung sagt open(20) dann ergibt das 70%. Somit muss die Regelung nicht wissen, wie der Motor funktioniert, sie muss nicht mal wissen wie weit die Öffnung aktuell ist. Wenn es schon 100% sind und die Regelung fordert nochmals open(20), dann bleibt es eben bei 100%. Wenn es hier nicht zu starken Überschwingern kommt oder zu stark auf die Batterie geht, sollte das reichen. Evtl. könnte man sich somit sogar das Adaptieren sparen. Ein Problem im Code habe ich noch entdeckt: in motor.cpp sollte in stop() der komplette Term für MOTOR_DDR geklammert werden (wie darunter bei MOTOR_PORT). Stefan M. schrieb: > Das Problem ist noch, dass die Motorsteuerung evtl. ja > asynchron zum Rest ausgeführt und überwacht werden sollte. Darüber habe ich auch schon nachgedacht, hierfür sind Klassen eben nicht gut geeignet. Vielleicht versuche ich mal zu verstehen, wie Knut das gelöst hat.
Stefan M. schrieb: > Das Problem ist noch, > dass die Motorsteuerung evtl. ja asynchron zum Rest ausgeführt und > überwacht werden sollte. Das ist zwingend. Die Lichtschranke muss, solange der Motor dreht (auch nach dem Abschalten, da der Motor nachläuft) permanent überwacht werden, sonst gehen Zählpulse verloren. Ebenso muss der Strom überwacht werden, um das geschlossene Ventil festzustellen. Ronny schrieb: > Somit muss die Regelung nicht wissen, wie der Motor > funktioniert, sie muss nicht mal wissen wie weit die Öffnung aktuell > ist. Wenn es schon 100% sind und die Regelung fordert nochmals open(20), > dann bleibt es eben bei 100%. Wenn die Regelung nicht weiß, wie weit das Ventil offen ist, wird sie nicht vernünftig funktionieren. Es wird heftige Temperatur-Überschwinger geben und der Motor wird ständig lange Wege fahren, was die Batterien leer saugt und die Nerven des Zimmerbewohners strapaziert. Ich habe lange an der Regelung getüftelt und habe bei eingeschwungener Raumtemperatur kaum Regeleingriffe und wenn, dann nur ein paar kurze Dreher kleiner 1 Sekunde Laufzeit vielleicht 1x pro halbe Stunde.
Hallo zusammen, bin sehr erfreud auf diesen Thread gestossen zu sein. Finde es sehr bewundernswert wie Knut Ballhause seit Oktober 2009 am Ball bleibt und sich regelmäßig hier zu Wort meldet. Am besten gefällt mir, das er die Firmware in ATMEL AVR Assembler geschrieben hat, was der Hauptgrund dafür war, mich durch diesen Wust an Informationen durchzuarbeiten. Danke dafür. Da unter anderem bei den Heizkosten am meisten in Punkto Energiekosten eingespart werden kann, hatte ich überlegt die " mechanischen " Thermostatköpfe durch elekronische zu ersetzten, da man sagt das 1°C Raumtemperaturabsenkung ca. 6% Heizenergie einspart. Ob das in einem sechs Parteien Miethaus, das mit Fernwärme versorgt wird Sinn macht weiß ich nicht. Auf jeden Fall habe ich mir einen solchen von ELV ( ETH comfort200 ) ausgeliehen und beim durchlesen der Beschreibung feststellen müssen, das ich damit nicht wirklich was anfangen kann, da ich keine allgemeine Wochenarbeitszeit von Mo bis Fr zur immer gleichen Zeit am selben Wochentag habe. Es besteht jedoch schon ein Rhytmus. Deshalb war ich auf der Suche nach etwas selbstprogrammierbaren und bin hier hängen geblieben. Allerdings stelle ich mir das ziemlich schwierig vor einen Schichtrhytmus zu programmieren, der zur Zeit folgendermaßen aussieht, sich aber auch alle Jahre mal ändert. F = Früh ; M = Mittag ; N = Nacht; # = Frei. F;F;M;M;N;N;N; #;#; F;F;M;M;M;N;N; #;#;#; F;F;M;M;N;N; #;#;#; usw. Dazu meine erste Frage : " Wie stelle ich so etwas in Assembler an ? ". Ich habe gerade mal etwas mehr als AVR ASM-Grundlagen und würde daher gerne mal ein Programm sehen, das so etwas benutzt, also das einen Kalender programmiert hat. Wenn ich bisher alles richtig verstanden habe ist der Comet von EuroTronic, sowie der ALDI Thermy ( Version3 ) und der Conrad Sygonix HT100 von der Elektronik her baugleich und das verlinkte ASM-Programm von Knut Ballhause läuft auf allen dreien. Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Da mir der von Conrad ( Sygnonix HT100 ) am besten gefällt, ich jedoch befürchte das sich die silberfarbenen Absetzungen ( Deckel sowie Einstellrad ) mit der Zeit abnutzen und dann schäbig aussehen, würde ich gerne von Jürgen Hamerski oder jemand anderem, der diesen Heizungsthermostat besitzt, wissen ob diese Absetzungen aus diesem silberfarbigen Material sind oder nur eine Lackfarbe, was praktisch meine zweite Frage bisher wäre. Bernd_Stein
:
Bearbeitet durch User
Bernd S. schrieb: > hatte ich überlegt die " mechanischen " > Thermostatköpfe durch elekronische zu ersetzten, da man sagt das 1°C > Raumtemperaturabsenkung ca. 6% Heizenergie einspart. Ob das in einem > sechs Parteien Miethaus, das mit Fernwärme versorgt wird Sinn macht weiß > ich nicht. Energie zu sparen ist immer sinnvoll, denn was nicht entnommen wird, muss an anderer Stelle nicht erzeugt werden. Wenn die Fernwärme aus Abwärme eines industriellen oder organischen Vorganges gewonnen wird, ist der Nutzen der Einsparung hingegen nicht gegeben.
Bernd S. schrieb: > da ich keine allgemeine > Wochenarbeitszeit von Mo bis Fr zur immer gleichen Zeit am selben > Wochentag habe. Es besteht jedoch schon ein Rhytmus. Das ist eine interessante Aufgabe. Ich würde das über verschiedene Blöcke programmieren. Die Zeiten für die einzelnen Schichten würde ich in Unterblöcken ablegen. Damit kann man sich dann Wochenmakros definieren, die sich auch gelegentlich schnell umbelegen lassen, wenn sich die Schichten vorhersehbar ändern. Aus den Wochenmakros wiederum könnte man ein Monatsmakro (nicht unbedingt kalendarisch, sondern genau 4 Wochen) erstellen. Durch die Verschachtelung der verschiedenen Ebenen kommt man mit dem recht begrenzten Display noch ganz gut zurecht. Die Makrodefinitionen würde ich in verschiedene Menüpunkte der Menügrundebene legen, so dass man die einzelnen Makro-Ebenen schnell erreichen und ändern kann, ohne die über- oder untergeordnete Ebene gleich mit zu verändern. So kann man einzelne Elemente tauschen (Kollege ist krank oder möchte die Schicht tauschen), ohne das ganze Gefüge durcheinanderzubringen.
Ich arbeite gerade an der Motorsteuerung, deshalb hier paar kurze Infos, auch um zu vermeiden, das jemand an der gleichen Stelle arbeitet. Ich bekomme nun den Interrupt von dem Reflexkoppler, kann die Impulse zählen, kann den Strom messen und habe auch schon einen einfachen Test, um beim Anschlag den Motor abzustellen.
Knut B. schrieb: > Wenn die Fernwärme aus Abwärme eines industriellen oder organischen > Vorganges gewonnen wird, ist der Nutzen der Einsparung hingegen nicht > gegeben. > Tja, das weiß ich leider nicht und ob ich wirklich Heizkosten in Zukunft sparen werde, weiß ich auch nicht, da ich die erste Heizperiode in dieser Wohnung verbringe. Knut B. schrieb: > Das ist eine interessante Aufgabe.... > Durch die Verschachtelung der verschiedenen Ebenen > kommt man mit dem recht begrenzten Display noch ganz gut zurecht. Die > Makrodefinitionen würde ich in verschiedene Menüpunkte der > Menügrundebene legen, so dass man die einzelnen Makro-Ebenen schnell > erreichen und ändern kann, ohne die über- oder untergeordnete Ebene > gleich mit zu verändern. So kann man einzelne Elemente tauschen (Kollege > ist krank oder möchte die Schicht tauschen), ohne das ganze Gefüge > durcheinanderzubringen.... > Also, mich hast du schon mal durcheinandergebracht ;-). Von Makros habe ich schon gelesen. Deine angesprochenen Ebenen verwirren mich dermaßen, das ich das für mich zur Zeit für eine unlösbare Aufgabe halte. Das einzige was ich in Bezug auf Kalender bzw. Rhythmus in AVR-ASM gefunden habe ist folgendes : Beitrag "Berechnung Wochentag, Kalenderwoche etc. in AVR-ASM!" Von dem ich allerdings gar nicht weiß, ob ich damit als Grundlage überhaupt was anfangen kann, um den oben angegebenen Schichtrhythmus realisieren zu können. Bernd_Stein
Das mit den Ebenen ist ganz einfach: 1. Ebene: Schicht Hier trägst Du die Heizzeiten ein, passend für die jeweilige Schicht Früh, Tag, Spät, Nacht 2. Ebene: Wochentag Hier gibst Du an, an welchem Wochentag Du welche Schicht hast. Dies geht natürlich nur, wenn die Woche einem bestimmten Muster folgt Alternative Ebene 2: Schichtmuster Du legst so viele Tage in Ebene 2 an, bis sich ein Turnus wiederholt oder eine Musterfolge abgeschlossen ist. Du brauchst so viele Felder, wie Du verschiedene Muster hast. 3. Ebene: Turnusabfolge Hier gibst Du die Reihenfolge der sich wiederholenden Muster an. Ein Datum musst Du bei der ganzen Geschichte gar nicht eingeben, weil Deine Arbeit sich mit hoher Wahrscheinlichkeit nicht an einem Datum, sondern an aufeinanderfolgenden Arbeits- unf Frei-Tagen orientiert.
Bin leider nicht sehr viel weitergekommen in den letzten Tagen. Anbei aber mal eine kleine Demo, habe darin auch mal schnell eine sehr primitive Regelung implementiert. Das taugt so natürlich nix und soll nur Zeigen, was bisher so geht. Wer es probieren will (natürlich auf eigene Gefahr), hier eine kurze Beschreibung der Menupunkte: ADAP - hier kann der Regler geöffnet und installiert werden. Nach drücken von OK wird das Ventil geschlossen und die Endposition wird erkannt. Der offene Ventilstössel wird allerdings noch nicht erkannt. TEMP - Hier kann die Zieltemperatur eingestellt werden REGL - Wenn dieser Menupunkt aktiv ist, läuft die Regelung und die Temperatur des NTC wird angezeigt und alle 30s aktualisiert. DBUG - Hier kann mit dem Drehrad der Motor gesteuert werden und die Impulse werden angezeigt. Den Quellcode gibt es später, ist noch zu experimentell. Bei Gelegenheit werde ich auch testen, ob es auch mit dem von mir gezeigten Lidl Regler RT200BT funktioniert.
Knut B. schrieb: > Das mit den Ebenen ist ganz einfach: > Ich danke dir erstmal für deinen Vorschlag. Leider begreife ich dies jedoch noch nicht, so das ich denke erstmal diesen Kurs durchzuarbeiten : http://www.weigu.lu/tutorials/avr_assembler/index.html In der Zeit hoffe ich, das es auch mal ein ASM-Programm zum Conrad Sygonix HT100BT ( Bluetooth-Modell ) geben wird oder ist DECT Hobbymäßig leichter zu programmieren ( Comet DECT )? https://www.youtube.com/watch?v=csXViC6H4Nw https://www.youtube.com/watch?v=O8TwVqa0og0 Bernd_Stein
Habe nun ein wenig Code aufgeräumt, hier nun also der Code für das Menu mit Beispielen. Den Code fürs LCD habe ich auch angepasst: Interrupt aktiviert und das Grad-Symbol hinzugefügt. Ob das mit dem Interrupt eine gute Idee so ist weiss ich nicht, können wir später entscheiden. @ Stefan M. Kannst du es bitte in dein Repository tun? Den Code für den Motor gibt es auch noch, sobald ich ihn aufgeräumt habe.
@ Ronny: Hab es ins Repository aufgenommen. Und habe auch die Transistoren für die Reparatur der H-Brücke hier liegen. Ich hoffe ich kann dann auch wieder zum Projekt beitragen.
Knut B. schrieb: > Conny G. schrieb: >> Ich finde es wäre höchste Zeit für eine Portierung nach C. > > Weiß ich doch, aber nicht für mich. Kümmert euch drum. Von ASM nach C > ist ohnehin einfacher, als andersrum ;-). OK, einfach ist relativ. :-) Ich hab's jetzt mal getan. Das ist Knuts alte (unfertige) Firmware für den V2 / Comet (davon habe ich ein paar), übersetzt in C. Im Moment ist bis auf ein paar Deklarationen alles in einer C-Datei, damit lässt es sich einfacher hin und her suchen. Es handelt sich dabei um eine ziemliche 1:1-Umsetzung von Knuts Assemblerquelle, wesentliche Motivation war/ist, den Code zu verstehen. Alle Variablen sind so wie bei Knut benannt, alle Funktionen auch, nur die führenden Unterstriche weggelassen, die bei ihm für interne Marken stehen. Auch die Kommentare sind weitgehend die aus dem Assemblerprogramm. Die einzige bewusste Ergänzung, die ich vorgesehen habe ist, Datum und Uhrzeit beim Start auszunullen, wenn aus dem EEPROM 0xFF gelesen worden ist. Der Start mit dem Jahr 2255 (von dem nur 2055 angezeigt wird) und um 255:255 Uhr war mir dann doch zu nervig. :-) Knuts Code hat keine Copyright/Verbreitungsfestlegung, auf Nachfrage meinte er, ich soll es als Public Domain auszeichnen. Das habe ich darum dann auch mit meiner C-Umsetzung so getan.
Jörg W. schrieb: > Ich hab's jetzt mal getan. Jörg, das ist eine Heldentat, vielen Dank! Das öffnet die Tür für viele nicht-ASMler auch mal was dran zu machen.
:
Bearbeitet durch User
Super Jörg! Jetzt noch für den V3, da ist alles wieder ganz anders ;-).
Knut B. schrieb: > Jetzt noch für den V3 Da halte ich's genauso wie du: wenn ich mal V3 habe, wird mich das interessieren, aber vorerst nicht. ;-)
Wenn sich jetzt noch jemand findet, der es als Github repository o.ä. hosted, dann kann die Community sich um solche Dinge kümmern :-)
Kann ich bei bedarf gerne machen. Würdet ihr dann noch ein passendes Readme.md mit Disclamer etc. schreiben?
So, hier nun der Motorcode, benötigt meine Änderungen von Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" @Stefan, kannst du es bitte in dein Github tun? An dem Motorcode gibt es sicher noch einiges zu tun, z.B. wird die Ventil-offen Position noch nicht ermittelt (evtl. ist das auch gar nicht nötig). In den Beispielen ist eine einfache Regelung implementiert, die ist wirklich sehr simpel, regelt bei mir aber schon auf etwa +/-0.5 Grad die Raumtemperatur. So langsam wird das ganze brauchbar. Ich mache mich dann als nächstes mal an den Code für die RTC. Wir sollten auch eine Klasse für die ganzen Daten (Datum, Uhrzeit, Programm, Offset usw.) einführen, damit wir global auf alles zugreifen können und so die Steuerung über WLAN/BT/Funk flexibel wird. Als Name fände ich "Storage" ganz gut. Evtl. macht es auch Sinn für das "Programm" eine eigen Klasse zu machen, so wären dann Sonderwünsche die hier formuliert wurden einfacher umsetzbar (z.B. 10 Tage statt 7 Tage Rhythmus). Zur Steuerung über WLAN habe ich zum ESP8266 kürzlich gelesen, das man kein DHCP verwenden soll, damit reduziert sich die Verbindungszeit von 3-4s auf <200ms. Habs probiert, stimmt tatsächlich. Inklusive einem HTTP-Request komme ich so auf etwa 1s Gesamtlaufzeit. Ein Test mit einem 2200mAh LiPo Akku und alle 6s einen HTTP-Request (die restliche Zeit DeepSleep) brachte eine Laufzeit von 3.5 Tagen. Wenn man also den HTTP Request alle 10-15 Minuten macht, ist eine Heizperiode locker drin. @Jörg Wunsch Vielen Dank und großen Respekt vor der Arbeit! Obwohl Knuts ASM-Code auch sehr gut verständlich ist, versteht man es so doch noch einiges besser.
Aha, der Akku hält eine Heizperiode, solange die Heizung nicht geregelt werden muß? :)
@ batman Und wie soll uns dein Beitrag jetzt weiterhelfen? Kannst du uns beim Programmieren aushelfen? Und rechnen kannst du doch sicher? Du kannst davon ausgehen, das ich bei meinen Überlegungen die Regelung mit einbezogen habe. Wenn man von meinem kleinen Test ausgeht (der es nicht ganz trifft, da noch ein LDO und ein Temperatursensor am ESP hing), dann kommt man bei 10 Min Intervall auf ca. 350 Tage, bei 15 Minuten ca. 525 Tage. Eine Heizperiode dauert ca. 220 Tage und wenn ich nicht irre, sind die Thermys mit einer Batterielaufzeit von ca. 3 Jahren angegeben. Und wenn man jetzt noch ein wenig optimiert (persistente HTTP-Verbindungen, MQTT oder irgendetwas mit UDP), dann sehe ich da kein Problem.
Conny G. schrieb: >> Ich hab's jetzt mal getan. > > Jörg, das ist eine Heldentat, vielen Dank! Hier noch ein Update. Ich habe noch einige kleine mehr oder minder schwere Bugs in der Umsetzung gefunden und repariert. Ich bin der Meinung, dass der C-Code jetzt erstmal genauso gut funktioniert, wie Knuts Assemblerversion. Einzige weitere Änderung gegenüber der Assemblerversion ist, dass ich MenuFunc wegfallen lassen habe und die Funktionszeiger mit in MenuTable integriert habe. Für mich selbst werde ich nun zusehen, daraus etwas zu zimmern, was „mehr C-like“ ist, bspw. PutString("ADAP") statt der einzelnen Ausgabe von jeweils vier Zeichen. Auch ist noch genug Platz im Flash, als dass man sich die formatierte Ausgabe einfach mit sprintf() organisieren kann, statt jedesmal irgendwelche Verrenkungen zur Umrechnung der Zahl, Unterdrückung von Vornullen etc. zu machen. Falls jemanden hier noch die V2 (Comet) interessiert, kann ich ja das Ergebnis meiner weiteren Arbeit hin und wieder posten.
Jörg W. schrieb: > Falls jemanden hier noch die V2 (Comet) interessiert, kann ich ja das > Ergebnis meiner weiteren Arbeit hin und wieder posten. Mach ich dann mal hier als Referenz für alle, die das interessieren möge. Ich habe aufbauend auf dem nach C umgeschriebenen Code von Knut Ballhause nun meine eigene Firmware weiterentwickelt. Hier eine Übersicht der Änderungen: . Beim Programmieren der Ende-Zeit eines Timers wird die Anfangs-Zeit als Vorgabe benutzt (statt 00:00); während der Programmierung blinkt „STRT“ bzw. „ENDE“ im Wechsel mit der Zeit . Menüs für die Temperatureinstellung implementiert („zu Hause“, „außer Haus“, „Nacht“) . Temperaturoffset implementiert (in 0,5-K-Schritten) . Automatik-Modus implementiert: ist er aktiv, wird die jeweilige Solltemperatur durch das Profil vorgegeben; bis zur nächsten Umschaltung kann diese dann manuell modifiziert werden . Programmier- und Temperaturdaten werden im EEPROM gesichert . Wochenend-Programmiermodus („T6-7“, analog zu den anderen Blockmodi) . Beim Batteriewechsel wird der Ventilzustand (Position und TopValue) im EEPROM gespeichert; wird dieser Zustand beim Start vorgefunden, dann erfolgt kein zwangsweiser Adaptionslauf . „RES“ macht nun einen Reset aller EEPROM-Daten . Aufrufreihenfolge beim Abspeichern von Datum und Uhrzeit korrigiert (war in der weiter oben geposteten Variante falsch herum, sodass diese Daten beim Batteriewechsel nicht gespeichert worden sind) . Urlaubs-Funktion implementiert: sie benutzt den normalen Automatikmodus, aber während der „im Haus“-Zeiten wird die „außer Haus“-Temperatur als Vorgabe genommen; Vorgabe einer Nachttemperatur bleibt jedoch wie sonst . Bedienungsanleitung geschrieben Die Firmware war gerade noch rechtzeitig vor dem Ende der Heizperiode fertig, sodass sie nun noch ein paar Tage lang getestet werden konnte. Was noch benötigt wird, aber jetzt mangels Testmöglichkeit fehlt: ein automatischer Aufruf der Adaptionsroutine, wenn sich das Ventil nicht mehr richtig schließt. Dafür brauche ich aber zuerst noch ein paar Ideen und Nutzungsdaten (wie oft öffnet/schließt Ventil, bis man merkt, dass es nicht mehr vollständig schließt?). Der Zustand ist aber allemal um Welten besser als mit der originalen Firmware.
Jörg W. schrieb: > Was noch benötigt wird, aber jetzt mangels Testmöglichkeit fehlt: ein > automatischer Aufruf der Adaptionsroutine, wenn sich das Ventil nicht > mehr richtig schließt. Die alten Zeros konnten den Strom des Motors noch nicht messen. Daher habe ich sie einfach immer bis zum Abwürgen des Motors drehen lassen. Das hat dann dazu geführt, dass sie ab und an aus der Verankerung sprangen und dann unter dem (heißen) Heizkörper lagen. Nicht zuletzt deswegen habe ich mich über die neuere Hardware mit der Strommessung gefreut. Ansatz: wenn Dein Programm merkt, dass die Temperatur trotz des vermeintlich erreichten 0-Punkts des Ventils zu hoch ist, drehe einfach 10 Ticks weiter in Richtung "Zu". Dies machst Du aber nur dann, wenn die Temperaturerhöhung über Nacht besteht, um Sonneneinstrahlung als Ursache auszuschließen. Ist der Regelbereich dann wieder in Ordnung, setze den neuen Wert als 0-Punkt.
Knut B. schrieb: > Die alten Zeros konnten den Strom des Motors noch nicht messen. Daher > habe ich sie einfach immer bis zum Abwürgen des Motors drehen lassen. Meinst du, es wäre sinnvoll, die Adaptation-Routine so auszubauen, dass sie auch für den Endanschlag den Strom misst? Für „free running“ und „valve touched“ hast du es ja schon drin gehabt. Was würde man als Kriterium nehmen, >20 % Steigerung des Werts? > Ansatz: wenn Dein Programm merkt, dass die Temperatur trotz des > vermeintlich erreichten 0-Punkts des Ventils zu hoch ist, drehe einfach > 10 Ticks weiter in Richtung "Zu". Das klingt sinnvoll. Werde ich einbauen, wird aber vermutlich erst in der nächsten Heizperiode sich richtig testen lassen. Im Moment gibt's da kaum noch Ventilbewegungen.
Jörg W. schrieb: > Meinst du, es wäre sinnvoll, die Adaptation-Routine so auszubauen, > dass sie auch für den Endanschlag den Strom misst? Für „free running“ > und „valve touched“ hast du es ja schon drin gehabt. Ja nee, geht doch nicht, weil die Hardware den Strom nicht messen kann. Hier wird lediglich die Drehzahl geprüft. Der Motor dreht halt schneller, wenn er frei läuft und langsamer, wenn er den Ventilstift niederdrückt. Da dies relative Werte sind, kann man diese nicht direkt dazu benutzen, um festzustellen, ob das Ventil schon geschlossen ist, oder nicht. Zumal der Motor in der Nähe des unteren Druckpunktes beim Anlaufen kaum noch Fahrt aufnimmt, da die Reibung schon so hoch ist. Da ist die Strommessung bei den V2 und V3-Geräten viel genauer und reproduzierbar. Edit: ach so, Du hast ja V2 Geräte - da musst Du mal gucken, ob die Strommessung geht. Die Werte verändern sich etwas, wenn die Batterie nachlässt, aber das ist dadurch, das VCC gleichzeitig die Referenzspannung für den ADC ist, ganz gut kompensiert :-)
:
Bearbeitet durch User
Knut B. schrieb: > Die Werte verändern sich etwas, wenn die Batterie nachlässt, Daher würde ich ja den Wert relativ zur normalen Ventilbetätigung benutzen. Der dürfte ja dann bei nachlassender Batterie auch bereits geringer sein. OK, mal sehen, das wird für die nächste Heizperiode übrig bleiben. Vielleicht hänge ich mir dann auch schon mal einen Funkmodul dran und sende die Debug-Info live nach draußen. Dann kann man die Vorgeschichte auch besser aufzeichnen, was so passiert ist, bis mal irgendwann das Ventil dann nicht mehr richtig schließt.
Jörg W. schrieb: > Vielleicht hänge ich mir dann auch schon mal einen Funkmodul dran > und sende die Debug-Info live nach draußen. > Dann wäre es schön, wenn du ein von den Chip's verbauen würdest der hier bereits eingebaut ist : Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Bernd_Stein
Bernd S. schrieb: > Dann wäre es schön, wenn du ein von den Chip's verbauen würdest der hier > bereits eingebaut ist : Sorry. Ich habe einige ATmega128RFA1 herumliegen und plane daher, diese irgendwie zusammen mit der µracoli-Bibliothek zu benutzen. Ich habe ohnehin schon etwas Infrastruktur für diese Teile da, um bspw. die Außentemperatur zu messen, da muss ich das Netzwerk eigentlich nur aufbohren dafür.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Sorry. Ich habe einige ATmega128RFA1 herumliegen und plane daher, > diese irgendwie zusammen mit der µracoli-Bibliothek zu benutzen. > Danke für die schnelle und unmissverständliche Antwort. Da brauche ich nicht weiter zu hoffen. Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen geantwortet haben, wahrscheinlich interessiert sie dieser Thread gar nicht mehr oder sie haben vergessen das *Häkchen bei Thread beobachten* zu setzen. Bernd_Stein
Bernd S. schrieb: > Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen > geantwortet haben Ich vermute, dass die RFMxx-Funkmodule bei den meisten hier das ist, was sie am ehesten für sowas benutzen würden.
Jörg W. schrieb: > Bernd S. schrieb: >> Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen >> geantwortet haben > > Ich vermute, dass die RFMxx-Funkmodule bei den meisten hier das ist, > was sie am ehesten für sowas benutzen würden. Ja, Rfm69. Wie ist denn die Reichweite des ATmega128RFA1? Eher wie Bluetooth, ein paar Meter und meist nicht mehr durch die nächste Wand?
:
Bearbeitet durch User
Conny G. schrieb: > Wie ist denn die Reichweite des ATmega128RFA1? Hängt von den Antennenstandorten ab. Freifeld haben wir schon mehr als 500 m erreicht, allerdings mit einem ordentlichen Dipol dran, nicht nur Stummel oder PCB-Mäander. Im Moment habe ich die „Basisstation“ im Arbeitszimmer neben meinem Server oben auf einem Schrank, sodass die Antenne relativ freie Rundumsicht hat. Von da hört sie normalerweise noch die auf dem Balkon (drei Wände dazwischen) am Boden liegende Pumpensteuerung des Gießsystems für die Balkonpflanzen. Wenn aber jemand dort die Kiste mit der Elektronik ein bisschen ungeschickt mit den Füßen in die Ecke baldovert, reißt die Verbindung schon auch mal ab. Eventuell überlege ich mir auch noch was mit sleeping routers, d. h. geroutet wird nur, wenn sie zyklisch aufwachen. Dann könnte ich jeden Knoten als Router benutzen. Dafür brauche ich aber eine halbwegs genaue Zeit (32-kHz-Quarz), im Moment wachen die im Netz befindlichen Sensoren nur „nach Nase“ (Watchdogoszillator) auf, da die Basisstation ja immer auf Empfang ist. p.s.: Die derzeitigen Sensoren haben nur einfache Antennen, teils ein Stummel (λ/4 ohne richtige Groundplane), teils ein Dipol direkt auf dem PCB.
:
Bearbeitet durch Moderator
Das ist ja ziemlich ordentliche Reichweite für die Angaben im Datenblatt. Hätte ich bei 2.4Ghz da gar nicht erwartet!
Die haben dank des Spreizgewinns (250 kbit/s bei 2 MHz Bandbreite) eine recht gute Empfängerempfindlichkeit. Das macht sich bezahlt.
Angehängte Dateien:
Nachdem keine Antwort bezüglich der silberfarbenen Absetzungen kam - hier nun die Antwort. Leider sind diese Teile lackiert. Jetzt was anderes. Wenn die Platine ausgehebelt wird, daran denken, das an der dafür günstigen Stelle ein Bauteil sitzt. Wahrscheinlich der Temperaturfühler. Am Layout bzw. an einigen Lötpads zum HT100, also ohne Blue Tooth ( BT ) gab es Veränderungen. Ich habe das ganze nicht genau untersucht, lediglich die auffälligen Sachen markiert. Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Bernd_Stein
:
Bearbeitet durch User
Da bei meinen Thermostaten der ATmega169PA verbaut ist, wollte ich
wissen wo die gravierensten Unterschiede zum PV Typ sind. Ich würde
sagen in den Power-Modes.
Ultra-Low-Power Consumption ( picoPower devices )
Active Mode :
1MHz, 1,8V : 215µA -> PA
: 330µA -> PV
32kHz, 1,8V including oscillator : 8µA -> PA
10µA -> PV
Im Power-Save-Mode ermöglicht nur der PA-Typ eine Stromreduktion von
750nA bei 1,8V.
Dachte auch im Speed Grade hätte sich was getan, da dort nur 1,8V - 5,5V
0-16 MHz stand, aber das ist nur ein Marketing-Trick. Auch hier ist bei
genauerem Studium festzustellen, das es auch hier eine Rampe für den
SOA ( Save Operating Area ) gibt. Beim PV-Typ stand dies wenigstens klar
zu erkennen :
1,8V - 5,5V 0-4 MHz
2,7V - 5,5V 0-8 MHz
Ok, der PA-Typ geht bis 16 Mhz, was natürlich beim PV-Typ nicht gegeben
war.
Bernd_Stein
:
Bearbeitet durch User
Zwischen dem PV und dem PA Typ gibt es Unterschiede bei einigen I0-Registern und deren Bitzuordnung. Bitte mal die Migration Notes konsultieren.
Bernd S. schrieb: > aber das ist nur ein Marketing-Trick. Nö, nicht ganz: vor den A-Typen gab es jeweils eine Variante, die für low-speed low-voltage definiert war und eine, die für high-speed 5 V only vorgesehen war. Mit dem "die shrink" der A-Versionen haben sie diese Unterscheidung nicht mehr benötigt, der komplette Bereich wird jetzt in einem Bauelement abgedeckt. Ansonsten ist der A-Typ einfach der Nachfolger. Sehr wahrscheinlich konnten sie diesen 1:1 statt des Vorgängers da einsetzen.
Knut B. schrieb: > Bitte mal die Migration Notes > konsultieren. > Das ist ja so eine Sache. Ich würde sagen die AVR506 und AVR529 sind da die Referenz. Aber dort steht für mich nicht erkennbar der Unterschied zwischen PV und PA. Überhaupt ist es für mich ein Rätselraten was die mit den Suffix meinen. PicoPower-Typen => P ? LowVoltage-Typen => V ? Wofür steht dann das A ? Man findet darüber keine eindeutigen Angaben. Bernd_Stein
Der Atmega169-V war die Low Voltage Variante des alten Atmega169. Dann kam die -P Variante. Diese ist für 1.8-5.5V mit niedrigem Stromverbrauch (Pico Power). Die -A Variante kam noch später und die kam dann mit dem oben erwähnten Die-Shrink inklusive Pico Power. Mit der -A Variante kam beim 169 auch das Verändern einiger Register, weshalb die Firmware für die V2-Regler dann auch nicht mehr auf den V3-Reglern lief. Die Interrupt-Bits für externe Interrupte liegen woanders. Und die Namen etlicher Register und Bits wurden an die der neueren Atmega-Serie angepasst, damit alle Datenblätter und Bibliotheken auf die gleichen Definitionen passten.
Angehängte Dateien:
-
IMG_4646.JPG
87 KB -
IMG_4648.JPG
120 KB -
IMG_4651.JPG
230 KB -
IMG_4653.JPG
230 KB -
IMG_4654.JPG
74 KB -
IMG_4655.JPG
140 KB
SiverCrest Heizkörperthermostat von Lidl mit USB, aber ohne Bluetooth. Auf der Platine ist "COMET" aufgedruckt. Welcher Schaltplan käme dieser Version am nächsten? Stromaufnahme des Stellmotors bei 2,5V: 30mA im Leerlauf 180mA bei Anschlag
:
Bearbeitet durch User
Bernhard S. schrieb: > Welcher Schaltplan käme dieser Version am nächsten? Weiß nicht.. Aber das sieht genauso aus, wie der Thermy von Aldi von vor 1 1/2 Jahren. -------- Und nein! Das ist kein USB! Auch wenn es wie USB aussieht, ist da doch eher SPI drin.
Da kommt ein USB-Programmierstick dran (muß käuflich erworben werden) - aus dem Internet Programm herunterladen (Web-Addy für Stick-Bestellung/Programm steht auf der Verpackung), installieren, gewünschte Programmierung am PC vornehmen und dann auf den Stick schieben (fasst glaube ich 6 oder 7 verschiedene Programmierungen). An Thermostat anstecken und die gewünschte Programmierung 'rüberziehen' - der Thermostat zeigt P1 - P6 (oder 7) im Display an - gewünschte Einstellung auswählen und mit OK bestätigen (IIRC). Der Stick enthält einen kleinen Akku oder einen Super-Cap, welcher sich am Computer über den USB-Anschluß aufläd - der Stick behält die auf ihm gespeicherten Einstellungen nur für eine recht begrenzte Zeit. Aber man hat sie ja noch auf dem Computer gespeichert und kann sie ja so wieder 'reaktivieren'...
Bernhard S. schrieb: > SiverCrest Heizkörperthermostat von Lidl mit USB, aber ohne Bluetooth. > Hallo Bernhard, endlich tut sich hier mal wieder was. Freue mich das noch ein Assemblerprogrammierer nun dabei ist. Gucke mir öfters deine Programme an. Danke, das du dir immer so viel Mühe gibst, das Andere es verstehen können und nachbauen. Mache leider immer was anderes, so das meine bisherigen ASM-Erfahrungen und das Wissen immer mehr "verblassen". Ich habe ja folgendes Problem mit den programmierbaren Thermostaten : Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" In deinen bisherigen Programmen habe ich leider nichts ähnliches gefunden, um dort mal abzukupfern ;-) Bernd_Stein
Hallo Bernd,
>...Freue mich das noch ein Assemblerprogrammierer nun dabei ist.
Ein Assemblerprogramm für den THERMOtronic ist momentan in Arbeit.
Werd's demnächtst hier veröffentlichen.
Noch kann es nicht viel, nur das LCD lässt sich erst vernünftig
ansteuern z.B. Bargraph und die Ziffern...
Bernhard
Bernhard S. schrieb: > Ein Assemblerprogramm für den THERMOtronic ist momentan in Arbeit. > Werd's demnächtst hier veröffentlichen. > Schön, was hast du denn genau vor ? Ist bei deinem wirklich der verbaut ? Habe ich aus einem anderen Thread von dir. > Eine Lösungsvariante für den ATmega136 (Heikörperregler THERMOtronic) > Bernd_Stein
Eine Variante für den THEROtronic, natürlich in Assembler: Beitrag "Heizkörperregler THERMOtronic ATmega169 Assembler"
Angehängte Dateien:
-
B1.jpg
230 KB -
Anschlussbelegung.jpg
470 KB -
Programmieradapter.jpg
180 KB
@Ronny Sehr gute Zuarbeit :-) Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Anbei die Anschlussbelegung des SilverCrest Bluetooth Smart
Ein Assemblerbeispiel für den Heizkörperregler SilverCrest Bluetooth ATmega169 in Assembler Beitrag "Heizkörperregler SilverCrest Bluetooth ATmega169 Assembler"
Achtung Laienfrage: Der Resetpin am "Thermy" / "Sparmatic Comet" ist nicht zufällig für einen kompletten Softwarereset nutzbar? Ich habe das Problem, dass ich Programmzeiten eingeben kann, sie aber nicht gespeichert werden. Ich kann ihn zwar per Menü Punkt RES zurücksetzen, das hift aber nicht. er setzt sich immer wieder auf 7 Uhr bis 22 Uhr zurück....
Mattes schrieb: > Der Resetpin am "Thermy" / "Sparmatic Comet" ist nicht zufällig für > einen kompletten Softwarereset nutzbar? Software-Reset hat ein AVR nicht. Man könnte es über einen Watchdog-Reset emulieren, aber da du dann sowieso in die Firmware eingfreifen müsstest, kannst du auch gleich stattdessen den Bug suchen.
Jörg W. schrieb: > Mach ich dann mal hier als Referenz für alle, die das interessieren > möge. Hallo, ich hoffe, ich hab's jetzt nicht übersehen, aber gibt's den Source schon wo auf github? Ich versuche mich gerade daran ein MRF24J40MA Modul zu integrieren und würde dafür gerne forken.. Falls nicht, Jörg: darf ich deinen Code auf meinem github hosten und darauf aufbauen?
Lukas R. schrieb: > Hallo, ich hoffe, ich hab's jetzt nicht übersehen, aber gibt's den > Source schon wo auf github? Nö, hatte ich keinen Bedarf dafür gesehen. Wenn du denkst, dass das wirklich lohnt, kann ich ihn aber da hochladen. Einen Github-Account habe ich, allerdings sträubt sich Git immer ein bisschen, wenn ich das benutzen will. :-) > Falls nicht, Jörg: darf ich deinen Code auf meinem github hosten und > darauf aufbauen? Ist doch Public Domain, da Knut Ballhause seinen Assemblercode (den ich letztlich nach C übersetzt habe) ebenfalls Public Domain gemacht hat.
Jörg W. schrieb: > Wenn du denkst, dass das wirklich lohnt, kann ich ihn aber da > hochladen. Einen Github-Account habe ich, allerdings sträubt sich > Git immer ein bisschen, wenn ich das benutzen will. :-) Also ich persönlich finde, es zahlt sich immer aus, schon allein wegen der Möglichkeit zusammenzuarbeiten und der history, aber ich mach das beruflich, also bin ich vielleicht etwas vorbelastet :) - Du kannst bei github ja das Web-Interface zum Hochladen verwenden, dafür ist wenig bis gar kein git-Wissen nötig. Wenns dir trotzdem zu mühselig ist, dann würde ich deinen (unveränderten) Code in einem Repository bei mir hosten, und meine Änderungen dann in einem fork machen, dann bleibt state komplett erhalten. Bzgl. Public Domain - das hab ich wohl gesehen, aber fragen wollte ich trotzdem :)
Mahlzeit! Nachdem wir in ein neues Heim umgezogen sind wo die Halterung für meine Cometen (v2, M169P) deutlich besser passt als im alten, habe ich die Regler mal wieder ausgegraben und wollte mal schauen, was es so neues gibt. Jörg hat sich ja viel Mühe gegeben mit der C-Portierung -> gleich mal aufgespielt. Leider ist es mir damit nicht gelungen die Schaltzeiten zu programmieren weil die OK-Taste irgendwie ganz und gar nicht entprellt ist (es schnippt viel zu schnell zum nächsten Punkt bzw. überspringt ein paar Zwischenpunkte) ... ...also wieder Knut's Firmware draufgespielt (mein Stand ist beta006 vom 04.02.2014 20:25:24) und keine Probleme. Bin ich der einzige mit diesem Problem bzw. hab ich was übersehen? Und: @Lukas: wo liegt Dein git-repo?
:
Bearbeitet durch User
Hmm, Probleme mit der OK-Taste habe ich nicht. Wenn du magst, kannst du ja mal meinen C-Code und Knuts Assemblercode an dieser Stelle vergleichen. Es ist ja nicht immer ganz einfach, die exakten Intentionen und Algorithmen von vielen Dutzend Seiten Assemblercode zu erfassen und dann tatsächlich in einer anderen Sprache wiederzugeben, insofern ist es gut möglich, dass ich mich da irgendwo mal geirrt habe.
Hm.... ich weiss ja nicht ob in Knut's Assemblervariante eine Tastenentprellung wirklich implementiert war, vorgesehen war sie auf jeden Fall und im C-Code gibt es eine entsprechende Variable "ButtonDebounce" welche wiederrum jedoch nirgendwo genutzt wird....
Andreas K. schrieb: > im C-Code gibt es eine entsprechende Variable "ButtonDebounce" welche > wiederrum jedoch nirgendwo genutzt wird Gerade nachgesehen. Im Assemblercode gibt's die auch, aber außer in einer Debugroutine wird sie nicht benutzt. Hatte sie damals nur stur aus dem Assemblercode in den C-Code kopiert (wie vieles andere auch). Ansonsten sollte der C-Code an dieser Stelle (ReadButtons) in der Tat eine 1:1-Umsetzung des Assemblercodes sein (dort in User.asm).
Hm... dann müsste ich das mal noch eingehender untersuchen, vielleicht EEPROM-Reset machen... Aber aktuell sind die Regler für mich leider nicht benutzbar (bzw. waren sie das noch nie) da sie schon nach 1..2 Tagen nicht mehr richtig schließen (Danfoss). Leider bin ich berufs- und familienbedingt mental schon zu sehr ausgelastet um hier selber Hand anzulegen... Deshalb: kennt jemand ein vergleichbares, käuflich erwerbbares System wo die Regelung wirklich zuverlässig funktioniert, d.h. insbesondere kein Überheizen durch verlorengegangene Ventil-Adaption? Ich hätte auch noch ne Idee für die automatische Erkennung ob neu adaptiert werden muss: bei Erreichen der Null-Position sollte ja der Motorstrom ansteigen. Mann könnte sich beim Adaptieren bzw. bei jeder Fahrt auf Nullstellung merken wie hoch der Motorstrom maximal war und wenn der deutlich geringer ist als beim letzten mal -> noch etwas weiter drehen bzw. neu adaptieren...
Andreas K. schrieb: > Ich hätte auch noch ne Idee für die automatische Erkennung ob neu > adaptiert werden muss: bei Erreichen der Null-Position sollte ja der > Motorstrom ansteigen. Müsste ich mal gucken. Hier ist das so nach ca. 'ner Woche, dass man mal wieder adaptieren muss.
Wenn man es clever anstellt, muss man zwischendurch gar nicht adaptieren. Einmaliges Einmessen beim Batterien einlegen reicht. Die Strommessung kann dafür herangezogen werden. Die alten Geräte vor 2012 konnten das noch nicht aber alle neueren Derivate können das. Leider bin ich nie dazu gekommen, meine Routinen daraufhin anzupassen, aber da alles soweit bei mir läuft, sehe ich nicht wirklich die Notwendigkeit, obgleich man einige Dinge in der Motorsteuerung sicher noch optimieren kann.
Knut B. schrieb: > Die Strommessung kann dafür herangezogen werden. Du meinst, wenn man weiß, dass man auf 0 schließt, stellt man sicher, dass der Strom wieder seinen ursprünglich gemessenen Wert erreicht? Wenn die Batterien nachlassen, wird man aber den ursprünglichen Strom gar nicht mehr erreichen können. Gut, dann müsste man wohl den später ermittelten Wert bis zum Batteriewechsel als neuen eintragen. Vielleicht habe ich nochmal Nerv, mir das anzusehen.
Man sollte den Strom relativ zum Öffnen-Strom messen und einen entsprechenden Schwellwert eintragen. Da die Referenzspannung für den ADC von der Batteriespannung abgeleitet wird, wird sich der gemessene Strom beim Schließen bei fallender Batteriespannung nur unwesentlich ändern. Sollte man durch Probieren verifizieren können.
Ich habe das Repository jetzt mal komplett auf Github geschoben: https://github.com/dl8dtl/sparmatic Ich habe mein altes Mercurial-Repo dahin migriert, sodass man auch meine damaligen lokalen Commits sieht. ;-) Habe vor paar Tagen einen Versuch implementiert, für das leidige Problem der nicht ganz schließenden Ventile einen Workaround einzubauen: wenn die Temperaturtendenz auf "steigend" im Zustand "heiß" oder "darüber" ist und das Ventil bereits (vermeintlich) auf 0 steht, dann wird ggf. versucht, die aktuelle Position leicht nach oben zu korrigieren, sodass weitere Schritte in Richtung schließen möglich werden. Damit soll ein ggf. erfolgter Schrittverlust des Schrittmotors kompensiert werden. Die Korrektur ist an ein paar Bedingungen geknüpft (nur im Winter; es muss innerhalb des letzten Tags eine Öffnung des Ventils gegeben haben; direkt nach einem Adaptieren wird eine Weile gewartet, da das Ventil ja gerade voll geöffnet war). Als nächstes würde ich noch eine Justiermöglichkeit für den Uhrentakt einbauen. Knut hatte da einen festen Fehlerwert eingebaut, der von dem meiner Quarze deutlich abweicht, sodass die Uhren auf Dauer einiges falsch gehen. Ich werde wahrscheinlich seinen Korrekturalgorithmus belassen, aber den Korrekturwert einstellbar machen.
Hallo Jörg, mein Tipp für das Schließen des Ventils: Ziehe die Strommessung heran und betrachte das Ventil als geschlossen, wenn ein bestimmter Motorstrom beim Zufahren erreicht ist. Diesen Strom kannst Du einstellbar machen, so dass schwegängige Ventile von normalgängigen unterschieden werden können. Wenn die Stromschwelle erreicht ist und der Motor dann abgeschaltet hat, setze auch den Schrittzähler auf 0, dann passen die Werte für das Öffnen immer wieder.
Meinst du, dass man dies bei jedem Stellen des Ventils bis auf 0 machen sollte?
Also für mich läuft das alles auf eine Art adaptive Adaptierung heraus :-D Die Adaptierung basiert ja auch auf Messung des Motorstromes... Aber könnte man nicht einfach jedes Mal wenn es auf 0 drehen soll das ganze als Adaption ausführen? ...oder wenn das zu viel Batterie verbraucht: nur bei jedem x-ten Mal adaptieren?
Wenn das Ventil zugedreht werden muss, dann muss es auch zu sein, sprich: Es muss die notwendige Kraft dazu aufgewendet werden. Dies kann über den Strom gelöst werden. Die Kraft sollte aber gut dosiert werden, sonst ist das Ventil nicht zu oder die Halterung reißt ab. Hier ist ein bisschen Empirie gefragt. Die Zählpulse, wie lang der Ventilweg ist, braucht man m.E. nur, wenn das Ventil geöffnet wird oder wenn man kleine Wege in Richtung "zu" fährt. Wenn die Regelung ausgibt, dass das Ventil komplett zu soll, dann misst man den Strom und weiß somit, wie weit man noch leiern darf. Und es wird nie wieder ein halbgeschlossenes Ventil geben. Da es von der Kraft her keinen Unterschied macht, ob man einen zuvor ermittelten Zähler bis auf 0 dreht oder gegen den Stromschwellwert fährt, werden die Batterien auch nicht schneller leer. Eine überschwingende Regelung beispielsweise verbraucht viel mehr im Verhältnis dazu.
Der Argumentation kann ich folgen … man müsste mal Messreihen machen, wie viel Strom fließt unter unterschiedlichen Umständen (normales Schließen mit voller/leerer Batterie, Anschlag erreicht volle/leere Batterie). Wenn's blöd kommt, muss man außer der Strommessung auch die Batteriespannung noch einbeziehen, um ein sicheres Kriterium zu haben.
:
Bearbeitet durch Moderator
Günstigerweise ist AREF=Vcc, was bedeutet, dass bei leerer werdender Batterie der gemessene Strom ansteigt, der reale Strom durch den Motor aber geringer wird. Ob es genau umgekehr proportional ist und sich somit nahezu aufhebt, kann ich nicht sagen. Die Batteriespannung kann ja einfach gemessen werden und wenn nötig, korrigiert man den gemessenen Strom etwas. Fakt ist, dass der Motor bei ziemlich leerer Batterie beim Zufahren auch zum Stillstand kommen kann, weil einfach der Saft nicht mehr ausreicht, um die Rotation gegen den störrischen Ventilstößel aufrecht zu erhalten. Das sind aber Extremwerte, die man recht leicht mit einem Labornetzteil nachstellen kann. Kritisch sind hier eher die verschiedenen Ventile, die von butterweich bis hakelig und vergriest daherkommen. Wir haben auf Arbeit auch ein paar "digitale" Ventile bei denen 1/10mm Ventilweg über auf und zu entscheidet. Das ist für die Regelung eine Herausforderung, insbesondere bei 80°C Vorlauftemperatur...
:
Bearbeitet durch User
Angehängte Dateien:
-
20181229_163704.jpg
220 KB -
20181229_163242.jpg
230 KB
Hallo, ich habe heute bei Aldi zufällig vier Comet Thermostate erworben nachdem ich vorher durch euren Thread und der Möglichkeit einer alternativen Firmware sensibilisiert war. Leider scheinen diese Thermostate keinen ATmega 169Px Controller sondern einen Cypress MB95F374L zu haben. Ein Micro USB für SPI ist wohl vorhanden. Hat evtl. schon jemand (Programmier-) Erfahrung damit? Lars
Das ist natürlich Grütze und es steht leider nicht außen dran. Nee, mit Cypress hab ich´s nicht so... Hat bestimmt 2Cent fuffzich weniger in der Herstellung gekostet, als mit ATMEL Chip...
Danke für´s Posten, dann macht ein Anderer nicht auch noch den Fehler, das Ding zu kaufen.
Knut B. schrieb: > Wir haben auf Arbeit auch ein paar "digitale" Ventile bei > denen 1/10mm Ventilweg über auf und zu entscheidet. Das ist offensichtlich "Stand der heutigen" Technik. Stichwort: Ventilkennlinie. Irgendwo hier im Forum hatte ich mich schon mal über das Zusammenspiel Ventilkennlinie/Heizkörperkennlinie ausgelassen. Kannst Du mir verraten, wie ihr das Problem gelöst habt. Als einen besseren Weg würde ich sehen, wenn jemand Heizkörperventilhersteller davon überzeugen könnte, Heizkörperventile mit gleichprozentiger Ventilkennlinie herzustellen.
Naja, neue Ventile funktionieren meistens erst mal eine Weile sehr gut, bis Kalk und Dreck das Ding unbrauchbar machen und die Dichtungen hart wie Stein sind. Wir haben einfach den Durchfluss des Heizkörpers im Rücklauf gedrosselt und schon verhält sich die Kiste kooperativ.
Knut B. schrieb: > Wir haben einfach den Durchfluss des Heizkörpers im > Rücklauf gedrosselt und schon verhält sich die Kiste kooperativ. Und ich hatte gehofft, dass es eine Lösung mit digitaler Technik gibt, um eine Regelung zu ermöglichen. An der Rücklaufverschraubung zu drehen entspricht nur eine Art -hydraulischer Abgleich- und verschlechtert das Regelverhalten, da die Ventilautorität sinkt.
Entscheident ist, ob die Heizung nachher funktioniert. Man kann naturlich die Regelung auch anpassen, dass nur minimale Ventilwege gefahren werden aber das müsste man dann auf jedes Ventil anpassen.
Knut B. schrieb: > Man kann > naturlich die Regelung auch anpassen, dass nur minimale Ventilwege > gefahren werden aber das müsste man dann auf jedes Ventil anpassen. Ich weiß nicht, ob Du dich schon intensiver mit Ventilkennlinien, Ventilautorität, kvs-Wert usw. intensiver beschäftigt hast. Wenn es wieder Ventile mit Regelkegel geben würde, dann wäre die Nutzung eines digitalen PI(D)-Reglers nahezu problemlos möglich. Z. Zt. teste ich gerade, ob evtl. doch auch mit den "Gartenwasserhähnen heutiger Bauart" eine gute Regelung möglich ist, wobei ich allerdings ein andere Marke (equiva) verwende und davon nur Motor mit Getriebe.
:
Bearbeitet durch User
wolle g. schrieb: > Ich weiß nicht, ob Du dich schon intensiver mit Ventilkennlinien, > Ventilautorität, kvs-Wert usw. intensiver beschäftigt hast. So intensiv es meine Heizungsanlage erfordert. Nicht wissenschaftlich. wolle g. schrieb: > Wenn es wieder Ventile mit Regelkegel geben würde, Das sind Stellkegel, geregelt wird im Regler, nicht im Ventil. wolle g. schrieb: > Z. Zt. teste ich gerade, ob evtl. doch auch mit den "Gartenwasserhähnen > heutiger Bauart" eine gute Regelung möglich ist Ich sag mal so: Der Raum ist sehr träge und selbst wenn das Ventil ständig auf und zudreht, ist es möglich, die Temperatur bei kleiner 1 Grad Abweichung konstant zu halten. Ich will den Aufwand nicht zu hoch treiben, ich möchte ja auch noch wohnen nebenbei. Die Zeiten des nächtelangen Programmierens und Recherchierens sind inzwischen vorbei. Und tagsüber muss ich ja arbeiten ;-). Ich lese aber gern mit.
:
Bearbeitet durch User
Knut B. schrieb: > Ich sag mal so: Der Raum ist sehr träge und selbst wenn das Ventil > ständig auf und zudreht, ist es möglich, die Temperatur bei kleiner 1 > Grad Abweichung konstant zu halten. Da habe ich andere Anforderungen an den Regelkreis. Da zeigt ja sogar ein stinknormaler mechanischer Thermostatkopf mit Dehnungskörper ein besseres Regelverhalten. >Das sind Stellkegel, geregelt wird im Regler, nicht im Ventil. Bleiben wir lieber bei Regelkegel. Auch mein google findet keinen Stellkegel. >So intensiv es meine Heizungsanlage erfordert. Ich habe den Eindruck, dass viele Heizungsbauer und Betreiber so denken. Sonst gäbe es wahrscheinlich nicht solche "Gartenwasserhähne heutiger Bauart" mit einem Ventilteller an Stelle eines Kegels.
:
Bearbeitet durch User
Knut B. schrieb: > Günstigerweise ist AREF=Vcc, was bedeutet, dass bei leerer werdender > Batterie der gemessene Strom ansteigt, der reale Strom durch den Motor > aber geringer wird. Ob es genau umgekehr proportional ist und sich somit > nahezu aufhebt, kann ich nicht sagen. Ich habe mal an drei verschiedenen Ventilen gemessen. Die Werte sind jeweils das, was Measure_Motor_Current() in der Variablen MotorCurrent ausspuckt. Der erste Wert ist der "FreeRunningCurrent", der zweite ist während des Stellvorgangs (nicht gleich nach dem Berühren des Stößels, irgendwo mittendrin), der dritte ist, wenn die Autokalibrierung abschaltet. Es sind mehrere Comet, aber alle am gleichen Heizkörper.
1 | Batterie Comet #1 Comet #2 Comet #3 |
2 | |
3 | NiMH #1 40:53:106 28:44:115 32:48:94 |
4 | NiMH #2 31:47:94 |
5 | LR6 voll 39:51:104 29:40:105 30:48:97 |
6 | 45:71:100 |
7 | LR6 leer 41:52:105 30:43:114 30:48:98 |
8 | 29:45:114 30:48:99 |
Es fällt auf, dass der gemessene Maximalstrom tatsächlich fast unabhängig von der Spannungslage ist, aber extrem exemplarabhängig. Bis auf einen Fall sind sie mehr als doppelt so hoch wie der Strom bei der normalen Ventilbetätigung. [Edit: Werte auf dezimal umgerechnet]
:
Bearbeitet durch Moderator
Was wäre denn nun ein sinnvoller Algorithmus? Adaptation() arbeitet ja offenbar so, dass der Motor bis zu einem Timeout (10 LCD frames je 64 Hz, also 156,25 ms, wenn ich das richtig sehe?) gegen den Anschlag gefahren wird. Wenn es dann keine weiteren Impulse vom Rotor gibt, wird abgeschaltet. So lange will man beim normalen Schließen des Ventils auf 0 sicher nicht vollen Strom ziehen. Eigentlich müsste es doch die sinnvollste Strategie sein, dass man versucht, den Punkt zu ermitteln, an dem der Strom nicht weiter steigt, oder? Vielleicht ja noch mit der zusätzlichen Bedingung, dass er mehr als das Doppelte von FreeMotorCurrent sein muss. Oder als Bedingung nehmen, dass die Position (durch die Lichtschranke) vorher auf 0 gezählt worden ist?
Gibt es eine Zusammenfassung wie diese Software Featuretechnisch zu den anderen Implementierungen steht? https://github.com/gnbl/sparmatic2011 sieht z.B. wesentlich aufgeräumter aus (wurde ja auch nicht erst vor kurzem von ASM nach C konvertiert), hat aber schon lange keine Aktivität mehr gesehen.
Nabend, ich hab mir als Bastelprojekt für 8 Euro einen Sparmatic Zero gekauft. Das Teil sieht aus wie dies von Conrad: https://asset.conrad.com/media10/isa/160267/c1/-/de/1091985_RB_00_FB/eurotronic-sparmatic-zero-heizkoerperthermostat-elektronisch-8-bis-28-c.jpg Ich scheitere schon daran, das Gehäuse zu öffnen. Kann mir da jemand weiterhelfen? Unter dem Batteriedeckel sind zwei Klipse, die sich aber sehr schwer bewegen. Der Rest des Gehäuses bewegt sich keinen Millimeter. Ich will das Gehäuse nicht zerstören. Martin
Martin B. schrieb: > Ich scheitere schon daran, das Gehäuse zu öffnen. Du hast vermutlich ein zugeschweißtes, oder? (Es gab auch mal geschraubte.) Mach die zugeschmolzenen Nippel vorsichtig ein bisschen warm und zieh sie dann auseinander. Die, die sich in den von unten zugänglichen Hohlräumen des Gehäusekörpers befinden, kann man leider nur (vorsichtig) abreißen.
So, das Teil ist auf. Da ist erstmal nix verschweißt. Ist alles geklippst. Sitzt halt ziemlich fest zusammen. Wenn man dann den Motor rausgenommen hat, sieht man unten die Platine liegen. Die ist dann tatsächlich mit 4 Schmelzpunkten am Gehäuse oberteil festgemacht. Wenn ich es nicht vergesse mache ich morgen mal Fotos davon
Vorsichtig weiter entnehmen, ansonsten reißt man schnell die stehend eingelötete Platine von den Pads unten ab.
Martin B. schrieb: > ich hab mir als Bastelprojekt für 8 Euro einen Sparmatic Zero gekauft. Welche Zielstellung verfolgst Du mit dem Bastelprojekt? Bei Interesse könnte ich einige Ergebnisse und Erfahrungen aus meinem Beitrag wolle g. (wolleg)30.12.2018 17:43 hier mal reinstellen.
Hallo, ich habe auch einen Eurotronic Comet mit dem geklipsten Gehäuse (wie Conny G. 04.12.2012 17:11 IMG2352.jpg). Ich habe, um mir alles anzuschauen und zu messen, die Platine von den vier Schmelzpunkten gelöst, in dem ich einfach mit dem Elektronikseitenscheider das geschmolzene über der Platine abgeknipst habe. Ich weiss jetzt leider nicht wie ich die Platine wieder fest bekomme. Ich dachte mit dem Motor drin wird genug Druck auf das Leitgummi ausgeübt das der Thermostat wieder funzt -> Fehlanzeige! Hat jemand eine Idee wie ich die Platine wieder fest bekomme ?
MitLeser schrieb: > Hat jemand eine Idee wie ich die Platine wieder fest bekomme ? Naja, sinnvoller wäre es gewesen, dass mit Heißluft etwas warm zu machen und dann hochzuziehen … zu spät. So wird wohl nur übrig bleiben, dass du die Platine anklebst. Das Gehäuse dürfte Polystyrol sein, das sollte sich gut kleben lassen.
Hallo Jörg, danke für die schnelle Antwort. Ja, Du hast recht, hätte ich besser machen können, aber meine Mittel hier zuhause sind beschränkt. Deshalb, würde Heiskleber funtionieren? Oder was empfiehlst Du?
MitLeser schrieb: > Deshalb, würde Heiskleber funtionieren? Heißkleber funktioniert ja praktisch überall. ;-) > Oder was empfiehlst Du? Ich würde wahrscheinlich erstmal gucken, ob man das mit so einem lösungsmittelbasierten Plastikkleber hinbekommt, denn der löst die Polystyrol-Pfosten ein bisschen an.
Angehängte Dateien:
-
FUSES.jpg
120 KB -
Lock_bits.jpg
100 KB -
Sygonix_HT100_ISP.jpg
200 KB -
ISP_Gehaeuse.jpg
97 KB -
ISP_Stecker.jpg
28 KB -
ISP_Verkabelung.jpg
91 KB -
Schaumstoff.jpg
190 KB
Da fängt man an und kann gleich wieder aufhören, weil wieder etwas dazwischen kommt. Was ich mir aber bisher erarbeitet habe, will ich hier hinterlegen, um nicht später einmal wieder ganz von vorn anfangen zu müssen. Den ATmega 169PA über die ISP-Schnittstelle mit dem AVRISP mkII anzusprechen hat schonmal geklappt. Dafür habe ich alllerdings eine LiIon-Zelle an die Leiterbahnen der Batteriekontakte gelötet. Die FUSES und LOCK-BITS sind im jeweiligen Screenshot zu sehen. Die entsprechenden PADs auf der Platine sind ebenfalls als Foto hochgeladen. Das Gehäuse musste an den entsprechend markierten Stellen bearbeitet werden, um den 10-Poligen Pfostenstecker lose anbringen zu können. Eine minimale Kante sollte jedoch erhalten bleiben, damit der Pfostenstecker nicht herausgezogen werden kann. Blöd ist, dass durch das Stecken und ziehen die Pinne machnmal mit wandern. Außer dem TxD-Anschluß PE1 bzw. Pin 3( UART ), haben alle anderen Adern einen 330 Ohm Widerstand bekommen. Damit die Masseleitung ( blau ) nicht am Rad scheuert sind die Pinne gekürzt und die Ader ganz nah am Gehäuse verlötet. Am besten eignet sich Flachbandkabel. 0,14qmm ist noch etwas zu steif. Weil die Platine mit verschweißten Plastikpinnen fest war, die ich weggeknippst habe, dachte mir das ich ein ca. 2mm dünnen Schaumstoff auf das Motorgehäuse klebe, was dann auf die Platine drückt, damit diese wiederum auf dass LCD-Leitgummi drückt. Bernd_Stein
Bernd S. schrieb: > Weil die Platine mit verschweißten Plastikpinnen fest war, die ich > weggeknippst habe, dachte mir das ich ein ca. 2mm dünnen Schaumstoff auf > das Motorgehäuse klebe, was dann auf die Platine drückt, damit diese > wiederum auf dass LCD-Leitgummi drückt. > So, nun wollte ich den Thermostaten ( TS ) wieder zusammenbauen und einmal gucken, ob er auch noch funktioniert. Erste Problem war natürlich wirklich die Displayanzeige. Zu Anfang waren kurz ein paar Striche zu sehen und dann nichts mehr. Musste tatsächlich die Schaumstoffdicke erhöhen und bin auch auf die schmale Seite gegangen, weil man hier näher zum Leitgummi ist. Man muss dabei darauf achten, dass das Zahnradfenster komplett frei bleibt. Ein guter Indikator für die richtige Dicke ist, dass sich das Fenster nicht eindrücken lässt, wenn man auf dass Motorgehäuse drückt. Ein Plektrum mit 1.14mm Dicke war sehr hilfreich, weil ich öfters das Gehäuse öffnen musste um mit der Schaumstoffdicke herum zu experimentieren. Es muss also nach dem einsetzen der Batterien, im Display eine Jahreszahl blinken ( 2010 ) und der Motor hat bei mir gedreht. Nach einstellen von Datum und Uhrzeit erscheint dann die Anzeige INST, was wohl für Installation steht. Also den TS angebaut und auf OK gedrückt, danach erscheint ADAP für die Adaptionsfahrt und die LED leuchtet wenn aufgeheizt wird. Bernd_Stein
:
Bearbeitet durch User
Hallo zusammen, weiß jemand zufällig was die Meldung FSLH zu bedeuten hat ? Könnte Flash bedeuten, aber was fange ich damit an ? In der Bedienungsanleitung steht nichts drinn und Tante G. weiß auch nichts. Nachdem ich die Akkus entnommen habe und einfach wieder eingesteckt, war die Meldung weg und alles so wie es sein soll ( siehe vorheriges Posting ). Die LCD-Anzeige ist in Ordung, alle Buchstaben waren beim Einstellen eindeutig wie in der Bedienugsanleitung beschrieben. Bernd_Stein
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.