Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat

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

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?

http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate

Nicht schön, aber wenigstens mal alles zusammengefasst.

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.

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.

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.

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.

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.

Mark T. schrieb:
> Es sind tatsächlich vier Flanken pro Umdrehung, Foto anbei.

Wow, danke, gute Arbeit!

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

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.

ad

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.

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.

Anbei die Modifikation der "USB"-Buchse zum Kontaktieren von 'RESET'.

Links: Comet // Rechts: Thermy

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.

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 ;-)

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 ;-)

-- -- 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.

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.

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.

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.

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 :-)

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.

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.

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

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.

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.

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.

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.

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.

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

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...

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.

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...

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.

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.

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.

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?

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 ;-)

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

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...

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.

Temoc schrieb:
> Dann würden sie wohl kaum den AVR rauswerfen..

Wie jetzt?

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. ;-)

Ich werde gelegentlich auch weiterproggen, ist fest eingeplant. In 
meinen Code muss ich mich dann auch wieder einlesen ;-)

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.

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.