Announcement: there is an English version of this forum on 
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
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.