Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat

[Jörg W. (dl8dtl) (Moderator)]

Knut B. schrieb:
> Conny G. schrieb:
>> Ich finde es wäre höchste Zeit für eine Portierung nach C.
>
> Weiß ich doch, aber nicht für mich. Kümmert euch drum. Von ASM nach C
> ist ohnehin einfacher, als andersrum ;-).

OK, einfach ist relativ. :-)

Ich hab's jetzt mal getan.  Das ist Knuts alte (unfertige) Firmware
für den V2 / Comet (davon habe ich ein paar), übersetzt in C.  Im
Moment ist bis auf ein paar Deklarationen alles in einer C-Datei,
damit lässt es sich einfacher hin und her suchen.

Es handelt sich dabei um eine ziemliche 1:1-Umsetzung von Knuts
Assemblerquelle, wesentliche Motivation war/ist, den Code zu
verstehen.  Alle Variablen sind so wie bei Knut benannt, alle
Funktionen auch, nur die führenden Unterstriche weggelassen, die bei
ihm für interne Marken stehen.  Auch die Kommentare sind weitgehend
die aus dem Assemblerprogramm.

Die einzige bewusste Ergänzung, die ich vorgesehen habe ist, Datum und
Uhrzeit beim Start auszunullen, wenn aus dem EEPROM 0xFF gelesen worden
ist.  Der Start mit dem Jahr 2255 (von dem nur 2055 angezeigt wird) und
um 255:255 Uhr war mir dann doch zu nervig. :-)

Knuts Code hat keine Copyright/Verbreitungsfestlegung, auf Nachfrage
meinte er, ich soll es als Public Domain auszeichnen.  Das habe ich
darum dann auch mit meiner C-Umsetzung so getan.

[Conny G. (conny_g)]

Jörg W. schrieb:
> Ich hab's jetzt mal getan.

Jörg, das ist eine Heldentat, vielen Dank!
Das öffnet die Tür für viele nicht-ASMler auch mal was dran zu machen.

[Knut B. (Firma: TravelRec.) (travelrec)]

Super Jörg! Jetzt noch für den V3, da ist alles wieder ganz anders ;-).

[Jörg W. (dl8dtl) (Moderator)]

Knut B. schrieb:
> Jetzt noch für den V3

Da halte ich's genauso wie du: wenn ich mal V3 habe, wird mich das
interessieren, aber vorerst nicht. ;-)

[Conny G. (conny_g)]

Wenn sich jetzt noch jemand findet, der es als Github repository o.ä. 
hosted, dann kann die Community sich um solche Dinge kümmern :-)

[Stefan M. (kein-nutzername-frei)]

Kann ich bei bedarf gerne machen. Würdet ihr dann noch ein passendes 
Readme.md mit Disclamer etc. schreiben?

[Ronny (Gast)]

So, hier nun der Motorcode, benötigt meine Änderungen von 
Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"

@Stefan, kannst du es bitte in dein Github tun?

An dem Motorcode gibt es sicher noch einiges zu tun, z.B. wird die 
Ventil-offen Position noch nicht ermittelt (evtl. ist das auch gar nicht 
nötig).
In den Beispielen ist eine einfache Regelung implementiert, die ist 
wirklich sehr simpel, regelt bei mir aber schon auf etwa +/-0.5 Grad die 
Raumtemperatur.

So langsam wird das ganze brauchbar. Ich mache mich dann als nächstes 
mal an den Code für die RTC. Wir sollten auch eine Klasse für die ganzen 
Daten (Datum, Uhrzeit, Programm, Offset usw.) einführen, damit wir 
global auf alles zugreifen können und so die Steuerung über WLAN/BT/Funk 
flexibel wird. Als Name fände ich "Storage" ganz gut.
Evtl. macht es auch Sinn für das "Programm" eine eigen Klasse zu machen, 
so wären dann Sonderwünsche die hier formuliert wurden einfacher 
umsetzbar (z.B. 10 Tage statt 7 Tage Rhythmus).


Zur Steuerung über WLAN habe ich zum ESP8266 kürzlich gelesen, das man 
kein DHCP verwenden soll, damit reduziert sich die Verbindungszeit von 
3-4s auf <200ms. Habs probiert, stimmt tatsächlich. Inklusive einem 
HTTP-Request komme ich so auf etwa 1s Gesamtlaufzeit.
Ein Test mit einem 2200mAh LiPo Akku und alle 6s einen HTTP-Request (die 
restliche Zeit DeepSleep) brachte eine Laufzeit von 3.5 Tagen. Wenn man 
also den HTTP Request alle 10-15 Minuten macht, ist eine Heizperiode 
locker drin.


@Jörg Wunsch
Vielen Dank und großen Respekt vor der Arbeit! Obwohl Knuts ASM-Code 
auch sehr gut verständlich ist, versteht man es so doch noch einiges 
besser.

[batman (Gast)]

Aha, der Akku hält eine Heizperiode, solange die Heizung nicht geregelt 
werden muß? :)

[Ronny (Gast)]

@ batman

Und wie soll uns dein Beitrag jetzt weiterhelfen? Kannst du uns beim 
Programmieren aushelfen?

Und rechnen kannst du doch sicher?

Du kannst davon ausgehen, das ich bei meinen Überlegungen die Regelung 
mit einbezogen habe.

Wenn man von meinem kleinen Test ausgeht (der es nicht ganz trifft, da 
noch ein LDO und ein Temperatursensor am ESP hing), dann kommt man bei 
10 Min Intervall auf ca. 350 Tage, bei 15 Minuten ca. 525 Tage. Eine 
Heizperiode dauert ca. 220 Tage und wenn ich nicht irre, sind die 
Thermys mit einer Batterielaufzeit von ca. 3 Jahren angegeben. Und wenn 
man jetzt noch ein wenig optimiert (persistente HTTP-Verbindungen, MQTT 
oder irgendetwas mit UDP), dann sehe ich da kein Problem.

[Jörg W. (dl8dtl) (Moderator)]

Conny G. schrieb:
>> Ich hab's jetzt mal getan.
>
> Jörg, das ist eine Heldentat, vielen Dank!

Hier noch ein Update.  Ich habe noch einige kleine mehr oder minder
schwere Bugs in der Umsetzung gefunden und repariert.  Ich bin der
Meinung, dass der C-Code jetzt erstmal genauso gut funktioniert,
wie Knuts Assemblerversion.  Einzige weitere Änderung gegenüber der
Assemblerversion ist, dass ich MenuFunc wegfallen lassen habe und
die Funktionszeiger mit in MenuTable integriert habe.

Für mich selbst werde ich nun zusehen, daraus etwas zu zimmern, was
„mehr C-like“ ist, bspw. PutString("ADAP") statt der einzelnen
Ausgabe von jeweils vier Zeichen.  Auch ist noch genug Platz im Flash,
als dass man sich die formatierte Ausgabe einfach mit sprintf()
organisieren kann, statt jedesmal irgendwelche Verrenkungen zur
Umrechnung der Zahl, Unterdrückung von Vornullen etc. zu machen.

Falls jemanden hier noch die V2 (Comet) interessiert, kann ich ja das
Ergebnis meiner weiteren Arbeit hin und wieder posten.

[Jörg W. (dl8dtl) (Moderator)]

Jörg W. schrieb:
> Falls jemanden hier noch die V2 (Comet) interessiert, kann ich ja das
> Ergebnis meiner weiteren Arbeit hin und wieder posten.

Mach ich dann mal hier als Referenz für alle, die das interessieren
möge.

Ich habe aufbauend auf dem nach C umgeschriebenen Code von Knut 
Ballhause
nun meine eigene Firmware weiterentwickelt.  Hier eine Übersicht der
Änderungen:

. Beim Programmieren der Ende-Zeit eines Timers wird die Anfangs-Zeit 
als Vorgabe benutzt (statt 00:00); während der Programmierung blinkt 
„STRT“ bzw. „ENDE“ im Wechsel mit der Zeit

. Menüs für die Temperatureinstellung implementiert („zu Hause“, „außer
Haus“, „Nacht“)

. Temperaturoffset implementiert (in 0,5-K-Schritten)

. Automatik-Modus implementiert: ist er aktiv, wird die jeweilige 
Solltemperatur durch das Profil vorgegeben; bis zur nächsten Umschaltung 
kann diese dann manuell modifiziert werden

. Programmier- und Temperaturdaten werden im EEPROM gesichert

. Wochenend-Programmiermodus („T6-7“, analog zu den anderen Blockmodi)

. Beim Batteriewechsel wird der Ventilzustand (Position und TopValue) im 
EEPROM gespeichert; wird dieser Zustand beim Start vorgefunden, dann 
erfolgt kein zwangsweiser Adaptionslauf

. „RES“ macht nun einen Reset aller EEPROM-Daten

. Aufrufreihenfolge beim Abspeichern von Datum und Uhrzeit korrigiert 
(war in der weiter oben geposteten Variante falsch herum, sodass diese 
Daten beim Batteriewechsel nicht gespeichert worden sind)

. Urlaubs-Funktion implementiert: sie benutzt den normalen 
Automatikmodus, aber während der „im Haus“-Zeiten wird die „außer 
Haus“-Temperatur als Vorgabe genommen; Vorgabe einer Nachttemperatur 
bleibt jedoch wie sonst

. Bedienungsanleitung geschrieben

Die Firmware war gerade noch rechtzeitig vor dem Ende der Heizperiode
fertig, sodass sie nun noch ein paar Tage lang getestet werden konnte.

Was noch benötigt wird, aber jetzt mangels Testmöglichkeit fehlt: ein
automatischer Aufruf der Adaptionsroutine, wenn sich das Ventil nicht
mehr richtig schließt.  Dafür brauche ich aber zuerst noch ein paar
Ideen und Nutzungsdaten (wie oft öffnet/schließt Ventil, bis man
merkt, dass es nicht mehr vollständig schließt?).  Der Zustand ist
aber allemal um Welten besser als mit der originalen Firmware.

[Knut B. (Firma: TravelRec.) (travelrec)]

Jörg W. schrieb:
> Was noch benötigt wird, aber jetzt mangels Testmöglichkeit fehlt: ein
> automatischer Aufruf der Adaptionsroutine, wenn sich das Ventil nicht
> mehr richtig schließt.

Die alten Zeros konnten den Strom des Motors noch nicht messen. Daher 
habe ich sie einfach immer bis zum Abwürgen des Motors drehen lassen. 
Das hat dann dazu geführt, dass sie ab und an aus der Verankerung 
sprangen und dann unter dem (heißen) Heizkörper lagen. Nicht zuletzt 
deswegen habe ich mich über die neuere Hardware mit der Strommessung 
gefreut.

Ansatz: wenn Dein Programm merkt, dass die Temperatur trotz des 
vermeintlich erreichten 0-Punkts des Ventils zu hoch ist, drehe einfach 
10 Ticks weiter in Richtung "Zu". Dies machst Du aber nur dann, wenn die 
Temperaturerhöhung über Nacht besteht, um Sonneneinstrahlung als Ursache 
auszuschließen. Ist der Regelbereich dann wieder in Ordnung, setze den 
neuen Wert als 0-Punkt.

[Jörg W. (dl8dtl) (Moderator)]

Knut B. schrieb:

> Die alten Zeros konnten den Strom des Motors noch nicht messen. Daher
> habe ich sie einfach immer bis zum Abwürgen des Motors drehen lassen.

Meinst du, es wäre sinnvoll, die Adaptation-Routine so auszubauen,
dass sie auch für den Endanschlag den Strom misst?  Für „free running“
und „valve touched“ hast du es ja schon drin gehabt.

Was würde man als Kriterium nehmen, >20 % Steigerung des Werts?

> Ansatz: wenn Dein Programm merkt, dass die Temperatur trotz des
> vermeintlich erreichten 0-Punkts des Ventils zu hoch ist, drehe einfach
> 10 Ticks weiter in Richtung "Zu".

Das klingt sinnvoll.  Werde ich einbauen, wird aber vermutlich erst
in der nächsten Heizperiode sich richtig testen lassen.  Im Moment
gibt's da kaum noch Ventilbewegungen.

[Knut B. (Firma: TravelRec.) (travelrec)]

Jörg W. schrieb:
> Meinst du, es wäre sinnvoll, die Adaptation-Routine so auszubauen,
> dass sie auch für den Endanschlag den Strom misst?  Für „free running“
> und „valve touched“ hast du es ja schon drin gehabt.

Ja nee, geht doch nicht, weil die Hardware den Strom nicht messen kann. 
Hier wird lediglich die Drehzahl geprüft. Der Motor dreht halt 
schneller, wenn er frei läuft und langsamer, wenn er den Ventilstift 
niederdrückt. Da dies relative Werte sind, kann man diese nicht direkt 
dazu benutzen, um festzustellen, ob das Ventil schon geschlossen ist, 
oder nicht. Zumal der Motor in der Nähe des unteren Druckpunktes beim 
Anlaufen kaum noch Fahrt aufnimmt, da die Reibung schon so hoch ist. Da 
ist die Strommessung bei den V2 und V3-Geräten viel genauer und 
reproduzierbar.

Edit: ach so, Du hast ja V2 Geräte - da musst Du mal gucken, ob die 
Strommessung geht. Die Werte verändern sich etwas, wenn die Batterie 
nachlässt, aber das ist dadurch, das VCC gleichzeitig die 
Referenzspannung für den ADC ist, ganz gut kompensiert :-)

[Jörg W. (dl8dtl) (Moderator)]

Knut B. schrieb:
> Die Werte verändern sich etwas, wenn die Batterie nachlässt,

Daher würde ich ja den Wert relativ zur normalen Ventilbetätigung
benutzen.  Der dürfte ja dann bei nachlassender Batterie auch bereits
geringer sein.

OK, mal sehen, das wird für die nächste Heizperiode übrig bleiben.
Vielleicht hänge ich mir dann auch schon mal einen Funkmodul dran
und sende die Debug-Info live nach draußen.  Dann kann man die
Vorgeschichte auch besser aufzeichnen, was so passiert ist, bis mal
irgendwann das Ventil dann nicht mehr richtig schließt.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Jörg W. schrieb:
> Vielleicht hänge ich mir dann auch schon mal einen Funkmodul dran
> und sende die Debug-Info live nach draußen.
>
Dann wäre es schön, wenn du ein von den Chip's verbauen würdest der hier 
bereits eingebaut ist :

Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"


Bernd_Stein

[Jörg W. (dl8dtl) (Moderator)]

Bernd S. schrieb:
> Dann wäre es schön, wenn du ein von den Chip's verbauen würdest der hier
> bereits eingebaut ist :

Sorry.  Ich habe einige ATmega128RFA1 herumliegen und plane daher,
diese irgendwie zusammen mit der µracoli-Bibliothek zu benutzen.  Ich
habe ohnehin schon etwas Infrastruktur für diese Teile da, um bspw.
die Außentemperatur zu messen, da muss ich das Netzwerk eigentlich
nur aufbohren dafür.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Jörg W. schrieb:
> Sorry.  Ich habe einige ATmega128RFA1 herumliegen und plane daher,
> diese irgendwie zusammen mit der µracoli-Bibliothek zu benutzen.
>
Danke für die schnelle und unmissverständliche Antwort. Da brauche ich 
nicht weiter zu hoffen. Schade, das die Anderen hier nicht auf meine 
vorhergehenden Fragen geantwortet haben, wahrscheinlich interessiert sie 
dieser Thread gar nicht mehr oder sie haben vergessen das *Häkchen bei 
Thread beobachten* zu setzen.


Bernd_Stein

[Jörg W. (dl8dtl) (Moderator)]

Bernd S. schrieb:
> Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen
> geantwortet haben

Ich vermute, dass die RFMxx-Funkmodule bei den meisten hier das ist,
was sie am ehesten für sowas benutzen würden.

[Conny G. (conny_g)]

Jörg W. schrieb:
> Bernd S. schrieb:
>> Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen
>> geantwortet haben
>
> Ich vermute, dass die RFMxx-Funkmodule bei den meisten hier das ist,
> was sie am ehesten für sowas benutzen würden.

Ja, Rfm69.

Wie ist denn die Reichweite des ATmega128RFA1? Eher wie Bluetooth, ein 
paar Meter und meist nicht mehr durch die nächste Wand?

[Jörg W. (dl8dtl) (Moderator)]

Conny G. schrieb:
> Wie ist denn die Reichweite des ATmega128RFA1?

Hängt von den Antennenstandorten ab.  Freifeld haben wir schon mehr
als 500 m erreicht, allerdings mit einem ordentlichen Dipol dran,
nicht nur Stummel oder PCB-Mäander.

Im Moment habe ich die „Basisstation“ im Arbeitszimmer neben meinem
Server oben auf einem Schrank, sodass die Antenne relativ freie
Rundumsicht hat.  Von da hört sie normalerweise noch die auf dem
Balkon (drei Wände dazwischen) am Boden liegende Pumpensteuerung des
Gießsystems für die Balkonpflanzen.  Wenn aber jemand dort die Kiste
mit der Elektronik ein bisschen ungeschickt mit den Füßen in die
Ecke baldovert, reißt die Verbindung schon auch mal ab.

Eventuell überlege ich mir auch noch was mit sleeping routers, d. h.
geroutet wird nur, wenn sie zyklisch aufwachen.  Dann könnte ich jeden
Knoten als Router benutzen.  Dafür brauche ich aber eine halbwegs genaue
Zeit (32-kHz-Quarz), im Moment wachen die im Netz befindlichen Sensoren
nur „nach Nase“ (Watchdogoszillator) auf, da die Basisstation ja immer
auf Empfang ist.

p.s.: Die derzeitigen Sensoren haben nur einfache Antennen, teils ein
Stummel (λ/4 ohne richtige Groundplane), teils ein Dipol direkt auf
dem PCB.

[Conny G. (conny_g)]

Das ist ja ziemlich ordentliche Reichweite für die Angaben im 
Datenblatt. Hätte ich bei 2.4Ghz da gar nicht erwartet!

[Jörg W. (dl8dtl) (Moderator)]

Die haben dank des Spreizgewinns (250 kbit/s bei 2 MHz Bandbreite)
eine recht gute Empfängerempfindlichkeit.  Das macht sich bezahlt.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Nachdem keine Antwort bezüglich der silberfarbenen Absetzungen kam - 
hier nun die Antwort. Leider sind diese Teile lackiert.
Jetzt was anderes. Wenn die Platine ausgehebelt wird, daran denken, das 
an der dafür günstigen Stelle ein Bauteil sitzt. Wahrscheinlich der 
Temperaturfühler.

Am Layout bzw. an einigen Lötpads zum HT100, also ohne Blue Tooth ( BT 
) gab es Veränderungen. Ich habe das ganze nicht genau untersucht, 
lediglich die auffälligen Sachen markiert.

Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Da bei meinen Thermostaten der ATmega169PA verbaut ist, wollte ich 
wissen wo die gravierensten Unterschiede zum PV Typ sind. Ich würde 
sagen in den Power-Modes.

Ultra-Low-Power Consumption ( picoPower devices )

Active Mode :

1MHz, 1,8V  : 215µA -> PA
            : 330µA -> PV
32kHz, 1,8V including oscillator :  8µA -> PA
                                   10µA -> PV

Im Power-Save-Mode ermöglicht nur der PA-Typ eine Stromreduktion von 
750nA bei 1,8V.

Dachte auch im Speed Grade hätte sich was getan, da dort nur 1,8V - 5,5V 
0-16 MHz stand, aber das ist nur ein Marketing-Trick. Auch hier ist bei 
genauerem Studium festzustellen, das es auch hier eine Rampe für den 
SOA ( Save Operating Area ) gibt. Beim PV-Typ stand dies wenigstens klar 
zu erkennen :

1,8V - 5,5V  0-4 MHz
2,7V - 5,5V  0-8 MHz

Ok, der PA-Typ geht bis 16 Mhz, was natürlich beim PV-Typ nicht gegeben 
war.


Bernd_Stein

[Knut B. (Firma: TravelRec.) (travelrec)]

Zwischen dem PV und dem PA Typ gibt es Unterschiede bei einigen 
I0-Registern und deren Bitzuordnung. Bitte mal die Migration Notes 
konsultieren.

[Jörg W. (dl8dtl) (Moderator)]

Bernd S. schrieb:
> aber das ist nur ein Marketing-Trick.

Nö, nicht ganz: vor den A-Typen gab es jeweils eine Variante, die
für low-speed low-voltage definiert war und eine, die für high-speed
5 V only vorgesehen war.  Mit dem "die shrink" der A-Versionen haben
sie diese Unterscheidung nicht mehr benötigt, der komplette Bereich
wird jetzt in einem Bauelement abgedeckt.

Ansonsten ist der A-Typ einfach der Nachfolger.  Sehr wahrscheinlich
konnten sie diesen 1:1 statt des Vorgängers da einsetzen.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Knut B. schrieb:
> Bitte mal die Migration Notes
> konsultieren.
>
Das ist ja so eine Sache. Ich würde sagen die AVR506 und AVR529 sind da 
die Referenz. Aber dort steht für mich nicht erkennbar der Unterschied 
zwischen PV und PA.
Überhaupt ist es für mich ein Rätselraten was die mit den Suffix meinen.

PicoPower-Typen  => P ?

LowVoltage-Typen => V ?

Wofür steht dann das A ?


Man findet darüber keine eindeutigen Angaben.


Bernd_Stein

[Knut B. (Firma: TravelRec.) (travelrec)]

Der Atmega169-V war die Low Voltage Variante des alten Atmega169. Dann 
kam die -P Variante. Diese ist für 1.8-5.5V mit niedrigem Stromverbrauch 
(Pico Power). Die -A Variante kam noch später und die kam dann mit dem 
oben erwähnten Die-Shrink inklusive Pico Power. Mit der -A Variante kam 
beim 169 auch das Verändern einiger Register, weshalb die Firmware für 
die V2-Regler dann auch nicht mehr auf den V3-Reglern lief. Die 
Interrupt-Bits für externe Interrupte liegen woanders. Und die Namen 
etlicher Register und Bits wurden an die der neueren Atmega-Serie 
angepasst, damit alle Datenblätter und Bibliotheken auf die gleichen 
Definitionen passten.

[Bernhard S. (bernhard)]

SiverCrest Heizkörperthermostat von Lidl mit USB, aber ohne Bluetooth.

Auf der Platine ist "COMET" aufgedruckt.

Welcher Schaltplan käme dieser Version am nächsten?


Stromaufnahme des Stellmotors bei 2,5V:

30mA im Leerlauf

180mA bei Anschlag

[Einer K. (Gast)]

Bernhard S. schrieb:
> Welcher Schaltplan käme dieser Version am nächsten?

Weiß nicht..
Aber das sieht genauso aus, wie der Thermy von Aldi von vor 1 1/2 
Jahren.

--------

Und nein!
Das ist kein USB!

Auch wenn es wie USB aussieht, ist da doch eher SPI drin.

[Michael W. (Gast)]

Da kommt ein USB-Programmierstick dran (muß käuflich erworben werden) - 
aus dem Internet Programm herunterladen (Web-Addy für 
Stick-Bestellung/Programm steht auf der Verpackung), installieren, 
gewünschte Programmierung am PC vornehmen und dann auf den Stick 
schieben (fasst glaube ich 6 oder 7 verschiedene Programmierungen). An 
Thermostat anstecken und die gewünschte Programmierung 'rüberziehen' - 
der Thermostat zeigt P1 - P6 (oder 7) im Display an - gewünschte 
Einstellung auswählen und mit OK bestätigen (IIRC). Der Stick enthält 
einen kleinen Akku oder einen Super-Cap, welcher sich am Computer über 
den USB-Anschluß aufläd - der Stick behält die auf ihm gespeicherten 
Einstellungen nur für eine recht begrenzte Zeit. Aber man hat sie ja 
noch auf dem Computer gespeichert und kann sie ja so wieder 
'reaktivieren'...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernhard S. schrieb:
> SiverCrest Heizkörperthermostat von Lidl mit USB, aber ohne Bluetooth.
>
Hallo Bernhard,

endlich tut sich hier mal wieder was. Freue mich das noch ein 
Assemblerprogrammierer nun dabei ist. Gucke mir öfters deine Programme 
an. Danke, das du dir immer so viel Mühe gibst, das Andere es verstehen 
können und nachbauen. Mache leider immer was anderes, so das meine 
bisherigen ASM-Erfahrungen und das Wissen immer mehr "verblassen".
Ich habe ja folgendes Problem mit den programmierbaren Thermostaten :

Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"

In deinen bisherigen Programmen habe ich leider nichts ähnliches 
gefunden, um dort mal abzukupfern ;-)


Bernd_Stein

[Bernhard S. (bernhard)]

Hallo Bernd,

>...Freue mich das noch ein Assemblerprogrammierer nun dabei ist.

Ein Assemblerprogramm für den THERMOtronic ist momentan in Arbeit. 
Werd's demnächtst hier veröffentlichen.

Noch kann es nicht viel, nur das LCD lässt sich erst vernünftig 
ansteuern z.B. Bargraph und die Ziffern...

Bernhard

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernhard S. schrieb:
> Ein Assemblerprogramm für den THERMOtronic ist momentan in Arbeit.
> Werd's demnächtst hier veröffentlichen.
>
Schön, was hast du denn genau vor ?

Ist bei deinem wirklich der verbaut ? Habe ich aus einem anderen Thread 
von dir.

> Eine Lösungsvariante für den ATmega136 (Heikörperregler THERMOtronic)
>

Bernd_Stein

[Bernhard S. (bernhard)]

Eine Variante für den THEROtronic, natürlich in Assembler:


Beitrag "Heizkörperregler THERMOtronic ATmega169 Assembler"

[Bernhard S. (bernhard)]

@Ronny

Sehr gute Zuarbeit :-)

Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"


Anbei die Anschlussbelegung des SilverCrest Bluetooth Smart

[Bernhard S. (bernhard)]

Ein Assemblerbeispiel für den

Heizkörperregler SilverCrest Bluetooth ATmega169 in Assembler

Beitrag "Heizkörperregler SilverCrest Bluetooth ATmega169 Assembler"

[Mattes (Gast)]

Achtung Laienfrage:

Der Resetpin am "Thermy" / "Sparmatic Comet" ist nicht zufällig für 
einen kompletten Softwarereset nutzbar?

Ich habe das Problem, dass ich Programmzeiten eingeben kann, sie aber 
nicht gespeichert werden. Ich kann ihn zwar per Menü Punkt RES 
zurücksetzen, das hift aber nicht. er setzt sich immer wieder auf 7 Uhr 
bis 22 Uhr zurück....

[Jörg W. (dl8dtl) (Moderator)]

Mattes schrieb:
> Der Resetpin am "Thermy" / "Sparmatic Comet" ist nicht zufällig für
> einen kompletten Softwarereset nutzbar?

Software-Reset hat ein AVR nicht.  Man könnte es über einen
Watchdog-Reset emulieren, aber da du dann sowieso in die Firmware
eingfreifen müsstest, kannst du auch gleich stattdessen den Bug
suchen.

[Lukas R. (lukas_r)]

Jörg W. schrieb:
> Mach ich dann mal hier als Referenz für alle, die das interessieren
> möge.

Hallo, ich hoffe, ich hab's jetzt nicht übersehen, aber gibt's den 
Source schon wo auf github? Ich versuche mich gerade daran ein 
MRF24J40MA Modul zu integrieren und würde dafür gerne forken..

Falls nicht, Jörg: darf ich deinen Code auf meinem github hosten und 
darauf aufbauen?

[Jörg W. (dl8dtl) (Moderator)]

Lukas R. schrieb:

> Hallo, ich hoffe, ich hab's jetzt nicht übersehen, aber gibt's den
> Source schon wo auf github?

Nö, hatte ich keinen Bedarf dafür gesehen.

Wenn du denkst, dass das wirklich lohnt, kann ich ihn aber da
hochladen.  Einen Github-Account habe ich, allerdings sträubt sich
Git immer ein bisschen, wenn ich das benutzen will. :-)

> Falls nicht, Jörg: darf ich deinen Code auf meinem github hosten und
> darauf aufbauen?

Ist doch Public Domain, da Knut Ballhause seinen Assemblercode (den
ich letztlich nach C übersetzt habe) ebenfalls Public Domain gemacht
hat.

[Lukas R. (lukas_r)]

Jörg W. schrieb:
> Wenn du denkst, dass das wirklich lohnt, kann ich ihn aber da
> hochladen.  Einen Github-Account habe ich, allerdings sträubt sich
> Git immer ein bisschen, wenn ich das benutzen will. :-)

Also ich persönlich finde, es zahlt sich immer aus, schon allein wegen 
der Möglichkeit zusammenzuarbeiten und der history, aber ich mach das 
beruflich, also bin ich vielleicht etwas vorbelastet :) - Du kannst bei 
github ja das Web-Interface zum Hochladen verwenden, dafür ist wenig bis 
gar kein git-Wissen nötig.

Wenns dir trotzdem zu mühselig ist, dann würde ich deinen 
(unveränderten) Code in einem Repository bei mir hosten, und meine 
Änderungen dann in einem fork machen, dann bleibt state komplett 
erhalten.

Bzgl. Public Domain - das hab ich wohl gesehen, aber fragen wollte ich 
trotzdem :)

[Andreas K. (uboot)]

Mahlzeit! Nachdem wir in ein neues Heim umgezogen sind wo die Halterung 
für meine Cometen (v2, M169P) deutlich besser passt als im alten, habe 
ich die Regler mal wieder ausgegraben und wollte mal schauen, was es so 
neues gibt.

Jörg hat sich ja viel Mühe gegeben mit der C-Portierung -> gleich mal 
aufgespielt.

Leider ist es mir damit nicht gelungen die Schaltzeiten zu programmieren 
weil die OK-Taste irgendwie ganz und gar nicht entprellt ist (es 
schnippt viel zu schnell zum nächsten Punkt bzw. überspringt ein paar 
Zwischenpunkte) ...

...also wieder Knut's Firmware draufgespielt (mein Stand ist beta006 vom 
04.02.2014 20:25:24) und keine Probleme.

Bin ich der einzige mit diesem Problem bzw. hab ich was übersehen?

Und: @Lukas: wo liegt Dein git-repo?

[Jörg W. (dl8dtl) (Moderator)]

Hmm, Probleme mit der OK-Taste habe ich nicht.

Wenn du magst, kannst du ja mal meinen C-Code und Knuts Assemblercode an 
dieser Stelle vergleichen. Es ist ja nicht immer ganz einfach, die 
exakten Intentionen und Algorithmen von vielen Dutzend Seiten 
Assemblercode zu erfassen und dann tatsächlich in einer anderen Sprache 
wiederzugeben, insofern ist es gut möglich, dass ich mich da irgendwo 
mal geirrt habe.

[Andreas K. (uboot)]

Hm.... ich weiss ja nicht ob in Knut's Assemblervariante eine 
Tastenentprellung wirklich implementiert war, vorgesehen war sie auf 
jeden Fall und im C-Code gibt es eine entsprechende Variable 
"ButtonDebounce" welche wiederrum jedoch nirgendwo genutzt wird....

[Jörg W. (dl8dtl) (Moderator)]

Andreas K. schrieb:
> im C-Code gibt es eine entsprechende Variable "ButtonDebounce" welche
> wiederrum jedoch nirgendwo genutzt wird

Gerade nachgesehen. Im Assemblercode gibt's die auch, aber außer in 
einer Debugroutine wird sie nicht benutzt.  Hatte sie damals nur stur 
aus dem Assemblercode in den C-Code kopiert (wie vieles andere auch).

Ansonsten sollte der C-Code an dieser Stelle (ReadButtons) in der Tat 
eine 1:1-Umsetzung des Assemblercodes sein (dort in User.asm).

[Andreas K. (uboot)]

Hm... dann müsste ich das mal noch eingehender untersuchen, vielleicht 
EEPROM-Reset machen...

Aber aktuell sind die Regler für mich leider nicht benutzbar (bzw. waren 
sie das noch nie) da sie schon nach 1..2 Tagen nicht mehr richtig 
schließen (Danfoss). Leider bin ich berufs- und familienbedingt mental 
schon zu sehr ausgelastet um hier selber Hand anzulegen...

Deshalb: kennt jemand ein vergleichbares, käuflich erwerbbares System wo 
die Regelung wirklich zuverlässig funktioniert, d.h. insbesondere kein 
Überheizen durch verlorengegangene Ventil-Adaption?


Ich hätte auch noch ne Idee für die automatische Erkennung ob neu 
adaptiert werden muss: bei Erreichen der Null-Position sollte ja der 
Motorstrom ansteigen. Mann könnte sich beim Adaptieren bzw. bei jeder 
Fahrt auf Nullstellung merken wie hoch der Motorstrom maximal war und 
wenn der deutlich geringer ist als beim letzten mal -> noch etwas weiter 
drehen bzw. neu adaptieren...

[Jörg W. (dl8dtl) (Moderator)]

Andreas K. schrieb:
> Ich hätte auch noch ne Idee für die automatische Erkennung ob neu
> adaptiert werden muss: bei Erreichen der Null-Position sollte ja der
> Motorstrom ansteigen.

Müsste ich mal gucken.

Hier ist das so nach ca. 'ner Woche, dass man mal wieder adaptieren 
muss.

[Knut B. (Firma: TravelRec.) (travelrec)]

Wenn man es clever anstellt, muss man zwischendurch gar nicht 
adaptieren. Einmaliges Einmessen beim Batterien einlegen reicht. Die 
Strommessung kann dafür herangezogen werden. Die alten Geräte vor 2012 
konnten das noch nicht aber alle neueren Derivate können das. Leider bin 
ich nie dazu gekommen, meine Routinen daraufhin anzupassen, aber da 
alles soweit bei mir läuft, sehe ich nicht wirklich die Notwendigkeit, 
obgleich man einige Dinge in der Motorsteuerung sicher noch optimieren 
kann.

[Jörg W. (dl8dtl) (Moderator)]

Knut B. schrieb:
> Die Strommessung kann dafür herangezogen werden.

Du meinst, wenn man weiß, dass man auf 0 schließt, stellt man sicher, 
dass der Strom wieder seinen ursprünglich gemessenen Wert erreicht? Wenn 
die Batterien nachlassen, wird man aber den ursprünglichen Strom gar 
nicht mehr erreichen können. Gut, dann müsste man wohl den später 
ermittelten Wert bis zum Batteriewechsel als neuen eintragen.

Vielleicht habe ich nochmal Nerv, mir das anzusehen.

[Knut B. (Firma: TravelRec.) (travelrec)]

Man sollte den Strom relativ zum Öffnen-Strom messen und einen 
entsprechenden Schwellwert eintragen. Da die Referenzspannung für den 
ADC von der Batteriespannung abgeleitet wird, wird sich der gemessene 
Strom beim Schließen bei fallender Batteriespannung nur unwesentlich 
ändern. Sollte man durch Probieren verifizieren können.

[Jörg W. (dl8dtl) (Moderator)]

Ich habe das Repository jetzt mal komplett auf Github geschoben:

https://github.com/dl8dtl/sparmatic

Ich habe mein altes Mercurial-Repo dahin migriert, sodass man auch meine 
damaligen lokalen Commits sieht. ;-)

Habe vor paar Tagen einen Versuch implementiert, für das leidige Problem 
der nicht ganz schließenden Ventile einen Workaround einzubauen: wenn 
die Temperaturtendenz auf "steigend" im Zustand "heiß" oder "darüber" 
ist und das Ventil bereits (vermeintlich) auf 0 steht, dann wird ggf. 
versucht, die aktuelle Position leicht nach oben zu korrigieren, sodass 
weitere Schritte in Richtung schließen möglich werden. Damit soll ein 
ggf. erfolgter Schrittverlust des Schrittmotors kompensiert werden. Die 
Korrektur ist an ein paar Bedingungen geknüpft (nur im Winter; es muss 
innerhalb des letzten Tags eine Öffnung des Ventils gegeben haben; 
direkt nach einem Adaptieren wird eine Weile gewartet, da das Ventil ja 
gerade voll geöffnet war).

Als nächstes würde ich noch eine Justiermöglichkeit für den Uhrentakt 
einbauen. Knut hatte da einen festen Fehlerwert eingebaut, der von dem 
meiner Quarze deutlich abweicht, sodass die Uhren auf Dauer einiges 
falsch gehen. Ich werde wahrscheinlich seinen Korrekturalgorithmus 
belassen, aber den Korrekturwert einstellbar machen.

[Knut B. (Firma: TravelRec.) (travelrec)]

Hallo Jörg,

mein Tipp für das Schließen des Ventils: Ziehe die Strommessung heran 
und betrachte das Ventil als geschlossen, wenn ein bestimmter Motorstrom 
beim Zufahren erreicht ist. Diesen Strom kannst Du einstellbar machen, 
so dass schwegängige Ventile von normalgängigen unterschieden werden 
können. Wenn die Stromschwelle erreicht ist und der Motor dann 
abgeschaltet hat, setze auch den Schrittzähler auf 0, dann passen die 
Werte für das Öffnen immer wieder.

[Jörg W. (dl8dtl) (Moderator)]

Meinst du, dass man dies bei jedem Stellen des Ventils bis auf 0 machen 
sollte?

[Andreas K. (uboot)]

Also für mich läuft das alles auf eine Art adaptive Adaptierung heraus 
:-D

Die Adaptierung basiert ja auch auf Messung des Motorstromes...


Aber könnte man nicht einfach jedes Mal wenn es auf 0 drehen soll das 
ganze als Adaption ausführen?

...oder wenn das zu viel Batterie verbraucht: nur bei jedem x-ten Mal 
adaptieren?

[Knut B. (Firma: TravelRec.) (travelrec)]

Wenn das Ventil zugedreht werden muss, dann muss es auch zu sein, 
sprich: Es muss die notwendige Kraft dazu aufgewendet werden. Dies kann 
über den Strom gelöst werden. Die Kraft sollte aber gut dosiert werden, 
sonst ist das Ventil nicht zu oder die Halterung reißt ab. Hier ist ein 
bisschen Empirie gefragt.  Die Zählpulse, wie lang der Ventilweg ist, 
braucht man m.E. nur, wenn das Ventil geöffnet wird oder wenn man kleine 
Wege in Richtung "zu" fährt. Wenn die Regelung ausgibt, dass das Ventil 
komplett zu soll, dann misst man den Strom und weiß somit, wie weit man 
noch leiern darf. Und es wird nie wieder ein halbgeschlossenes Ventil 
geben. Da es von der Kraft her keinen Unterschied macht, ob man einen 
zuvor ermittelten Zähler bis auf 0 dreht oder gegen den Stromschwellwert 
fährt, werden die Batterien auch nicht schneller leer. Eine 
überschwingende Regelung beispielsweise verbraucht viel mehr im 
Verhältnis dazu.

[Jörg W. (dl8dtl) (Moderator)]

Der Argumentation kann ich folgen … man müsste mal Messreihen machen, 
wie viel Strom fließt unter unterschiedlichen Umständen (normales 
Schließen mit voller/leerer Batterie, Anschlag erreicht volle/leere 
Batterie).  Wenn's blöd kommt, muss man außer der Strommessung auch die 
Batteriespannung noch einbeziehen, um ein sicheres Kriterium zu haben.

[Knut B. (Firma: TravelRec.) (travelrec)]

Günstigerweise ist AREF=Vcc, was bedeutet, dass bei leerer werdender 
Batterie der gemessene Strom ansteigt, der reale Strom durch den Motor 
aber geringer wird. Ob es genau umgekehr proportional ist und sich somit 
nahezu aufhebt, kann ich nicht sagen. Die Batteriespannung kann ja 
einfach gemessen werden und wenn nötig, korrigiert man den gemessenen 
Strom etwas. Fakt ist, dass der Motor bei ziemlich leerer Batterie beim 
Zufahren auch zum Stillstand kommen kann, weil einfach der Saft nicht 
mehr ausreicht, um die Rotation gegen den störrischen Ventilstößel 
aufrecht zu erhalten. Das sind aber Extremwerte, die man recht leicht 
mit einem Labornetzteil nachstellen kann. Kritisch sind hier eher die 
verschiedenen Ventile, die von butterweich bis hakelig und vergriest 
daherkommen. Wir haben auf Arbeit auch ein paar "digitale" Ventile bei 
denen 1/10mm Ventilweg über auf und zu entscheidet. Das ist für die 
Regelung eine Herausforderung, insbesondere bei 80°C 
Vorlauftemperatur...

[Lars W. (lars_w)]

Hallo,

ich habe heute bei Aldi zufällig vier Comet Thermostate erworben nachdem 
ich vorher durch euren Thread und der Möglichkeit einer alternativen 
Firmware sensibilisiert war.

Leider scheinen diese Thermostate keinen ATmega 169Px Controller sondern 
einen Cypress MB95F374L zu haben. Ein Micro USB für SPI ist wohl 
vorhanden.

Hat evtl. schon jemand (Programmier-) Erfahrung damit?

Lars

[Knut B. (Firma: TravelRec.) (travelrec)]

Das ist natürlich Grütze und es steht leider nicht außen dran. Nee, mit 
Cypress hab ich´s nicht so... Hat bestimmt 2Cent fuffzich weniger in der 
Herstellung gekostet, als mit ATMEL Chip...

[Knut B. (Firma: TravelRec.) (travelrec)]

Danke für´s Posten, dann macht ein Anderer nicht auch noch den Fehler, 
das Ding zu kaufen.

[Wolle G. (wolleg)]

Knut B. schrieb:
> Wir haben auf Arbeit auch ein paar "digitale" Ventile bei
> denen 1/10mm Ventilweg über auf und zu entscheidet.

Das ist offensichtlich "Stand der heutigen" Technik.
Stichwort: Ventilkennlinie.
Irgendwo hier im Forum hatte ich mich schon mal über das Zusammenspiel 
Ventilkennlinie/Heizkörperkennlinie ausgelassen.
Kannst Du mir verraten, wie ihr das Problem gelöst habt.
Als einen besseren Weg würde ich sehen, wenn jemand 
Heizkörperventilhersteller davon überzeugen könnte, Heizkörperventile 
mit gleichprozentiger Ventilkennlinie herzustellen.

[Knut B. (Firma: TravelRec.) (travelrec)]

Naja, neue Ventile funktionieren meistens erst mal eine Weile sehr gut, 
bis Kalk und Dreck das Ding unbrauchbar machen und die Dichtungen hart 
wie Stein sind. Wir haben einfach den Durchfluss des Heizkörpers im 
Rücklauf gedrosselt und schon verhält sich die Kiste kooperativ.

[Wolle G. (wolleg)]

Knut B. schrieb:
> Wir haben einfach den Durchfluss des Heizkörpers im
> Rücklauf gedrosselt und schon verhält sich die Kiste kooperativ.

Und ich hatte gehofft, dass es eine Lösung mit digitaler Technik gibt, 
um eine Regelung zu ermöglichen.
An der Rücklaufverschraubung zu drehen entspricht nur eine Art 
-hydraulischer Abgleich- und verschlechtert das Regelverhalten, da die 
Ventilautorität sinkt.

[Knut B. (Firma: TravelRec.) (travelrec)]

Entscheident ist, ob die Heizung nachher funktioniert. Man kann 
naturlich die Regelung auch anpassen, dass nur minimale Ventilwege 
gefahren werden aber das müsste man dann auf jedes Ventil anpassen.

[Wolle G. (wolleg)]

Knut B. schrieb:
> Man kann
> naturlich die Regelung auch anpassen, dass nur minimale Ventilwege
> gefahren werden aber das müsste man dann auf jedes Ventil anpassen.
Ich weiß nicht, ob Du dich schon intensiver mit Ventilkennlinien, 
Ventilautorität, kvs-Wert usw. intensiver beschäftigt hast.

Wenn es wieder  Ventile mit Regelkegel geben würde, dann wäre die 
Nutzung eines digitalen PI(D)-Reglers nahezu problemlos möglich.
Z. Zt. teste ich gerade, ob evtl. doch auch mit den "Gartenwasserhähnen 
heutiger Bauart"  eine gute Regelung möglich ist, wobei ich allerdings 
ein andere Marke (equiva) verwende und davon nur Motor mit Getriebe.

[Knut B. (Firma: TravelRec.) (travelrec)]

wolle g. schrieb:
> Ich weiß nicht, ob Du dich schon intensiver mit Ventilkennlinien,
> Ventilautorität, kvs-Wert usw. intensiver beschäftigt hast.

So intensiv es meine Heizungsanlage erfordert. Nicht wissenschaftlich.

wolle g. schrieb:
> Wenn es wieder  Ventile mit Regelkegel geben würde,

Das sind Stellkegel, geregelt wird im Regler, nicht im Ventil.

wolle g. schrieb:
> Z. Zt. teste ich gerade, ob evtl. doch auch mit den "Gartenwasserhähnen
> heutiger Bauart"  eine gute Regelung möglich ist

Ich sag mal so: Der Raum ist sehr träge und selbst wenn das Ventil 
ständig auf und zudreht, ist es möglich, die Temperatur bei kleiner 1 
Grad Abweichung konstant zu halten. Ich will den Aufwand nicht zu hoch 
treiben, ich möchte ja auch noch wohnen nebenbei. Die Zeiten des 
nächtelangen Programmierens und Recherchierens sind inzwischen vorbei. 
Und tagsüber muss ich ja arbeiten ;-). Ich lese aber gern mit.

[Wolle G. (wolleg)]

Knut B. schrieb:
> Ich sag mal so: Der Raum ist sehr träge und selbst wenn das Ventil
> ständig auf und zudreht, ist es möglich, die Temperatur bei kleiner 1
> Grad Abweichung konstant zu halten.
Da habe ich andere Anforderungen an den Regelkreis.
Da zeigt ja sogar ein stinknormaler mechanischer Thermostatkopf mit 
Dehnungskörper ein besseres Regelverhalten.

>Das sind Stellkegel, geregelt wird im Regler, nicht im Ventil.
Bleiben wir lieber bei Regelkegel.
Auch mein google findet keinen Stellkegel.

>So intensiv es meine Heizungsanlage erfordert.
Ich habe den Eindruck, dass viele Heizungsbauer und Betreiber so denken.
Sonst gäbe es wahrscheinlich nicht solche "Gartenwasserhähne heutiger 
Bauart" mit einem Ventilteller an Stelle eines Kegels.

[Jörg W. (dl8dtl) (Moderator)]

Knut B. schrieb:
> Günstigerweise ist AREF=Vcc, was bedeutet, dass bei leerer werdender
> Batterie der gemessene Strom ansteigt, der reale Strom durch den Motor
> aber geringer wird. Ob es genau umgekehr proportional ist und sich somit
> nahezu aufhebt, kann ich nicht sagen.

Ich habe mal an drei verschiedenen Ventilen gemessen. Die Werte sind 
jeweils das, was Measure_Motor_Current() in der Variablen MotorCurrent 
ausspuckt. Der erste Wert ist der "FreeRunningCurrent", der zweite ist 
während des Stellvorgangs (nicht gleich nach dem Berühren des Stößels, 
irgendwo mittendrin), der dritte ist, wenn die Autokalibrierung 
abschaltet.

Es sind mehrere Comet, aber alle am gleichen Heizkörper.

Batterie   Comet #1    Comet #2    Comet #3

NiMH #1    40:53:106   28:44:115   32:48:94
NiMH #2                            31:47:94
LR6 voll   39:51:104   29:40:105   30:48:97
           45:71:100
LR6 leer   41:52:105   30:43:114   30:48:98
                       29:45:114   30:48:99

Es fällt auf, dass der gemessene Maximalstrom tatsächlich fast 
unabhängig von der Spannungslage ist, aber extrem exemplarabhängig. Bis 
auf einen Fall sind sie mehr als doppelt so hoch wie der Strom bei der 
normalen Ventilbetätigung.

[Edit: Werte auf dezimal umgerechnet]

[Jörg W. (dl8dtl) (Moderator)]

Was wäre denn nun ein sinnvoller Algorithmus?

Adaptation() arbeitet ja offenbar so, dass der Motor bis zu einem 
Timeout (10 LCD frames je 64 Hz, also 156,25 ms, wenn ich das richtig 
sehe?) gegen den Anschlag gefahren wird. Wenn es dann keine weiteren 
Impulse vom Rotor gibt, wird abgeschaltet.

So lange will man beim normalen Schließen des Ventils auf 0 sicher nicht 
vollen Strom ziehen.

Eigentlich müsste es doch die sinnvollste Strategie sein, dass man 
versucht, den Punkt zu ermitteln, an dem der Strom nicht weiter steigt, 
oder?  Vielleicht ja noch mit der zusätzlichen Bedingung, dass er mehr 
als das Doppelte von FreeMotorCurrent sein muss. Oder als Bedingung 
nehmen, dass die Position (durch die Lichtschranke) vorher auf 0 gezählt 
worden ist?

[Hermann K. (r2d2)]

Gibt es eine Zusammenfassung wie diese Software Featuretechnisch zu den 
anderen Implementierungen steht? https://github.com/gnbl/sparmatic2011 
sieht z.B. wesentlich aufgeräumter aus (wurde ja auch nicht erst vor 
kurzem von ASM nach C konvertiert), hat aber schon lange keine Aktivität 
mehr gesehen.

[Martin B. (speerwerfer)]

Nabend,

ich hab mir als Bastelprojekt für 8 Euro einen Sparmatic Zero gekauft. 
Das Teil sieht aus wie dies von Conrad: 
https://asset.conrad.com/media10/isa/160267/c1/-/de/1091985_RB_00_FB/eurotronic-sparmatic-zero-heizkoerperthermostat-elektronisch-8-bis-28-c.jpg

Ich scheitere schon daran, das Gehäuse zu öffnen. Kann mir da jemand 
weiterhelfen? Unter dem Batteriedeckel sind zwei Klipse, die sich aber 
sehr schwer bewegen. Der Rest des Gehäuses bewegt sich keinen 
Millimeter. Ich will das Gehäuse nicht zerstören.

Martin

[Jörg W. (dl8dtl) (Moderator)]

Martin B. schrieb:
> Ich scheitere schon daran, das Gehäuse zu öffnen.

Du hast vermutlich ein zugeschweißtes, oder? (Es gab auch mal 
geschraubte.)

Mach die zugeschmolzenen Nippel vorsichtig ein bisschen warm und zieh 
sie dann auseinander. Die, die sich in den von unten zugänglichen 
Hohlräumen des Gehäusekörpers befinden, kann man leider nur (vorsichtig) 
abreißen.

[Martin B. (speerwerfer)]

So, das Teil ist auf. Da ist erstmal nix verschweißt. Ist alles 
geklippst. Sitzt halt ziemlich fest zusammen. Wenn man dann den Motor 
rausgenommen hat, sieht man unten die Platine liegen. Die ist dann 
tatsächlich mit 4 Schmelzpunkten am Gehäuse oberteil festgemacht. Wenn 
ich es nicht vergesse mache ich morgen mal Fotos davon

[Jörg W. (dl8dtl) (Moderator)]

Vorsichtig weiter entnehmen, ansonsten reißt man schnell die stehend 
eingelötete Platine von den Pads unten ab.

[Wolle G. (wolleg)]

Martin B. schrieb:
> ich hab mir als Bastelprojekt für 8 Euro einen Sparmatic Zero gekauft.

Welche Zielstellung verfolgst Du mit dem Bastelprojekt?
Bei Interesse könnte ich einige Ergebnisse und Erfahrungen aus meinem 
Beitrag wolle g. (wolleg)30.12.2018 17:43 hier mal reinstellen.

[MitLeser (Gast)]

Hallo, ich habe auch einen Eurotronic Comet mit dem geklipsten Gehäuse
(wie Conny G. 04.12.2012 17:11 IMG2352.jpg).
Ich habe, um mir alles anzuschauen und zu messen, die Platine von
den vier Schmelzpunkten gelöst, in dem ich einfach mit dem 
Elektronikseitenscheider das geschmolzene über der Platine abgeknipst
habe.
Ich weiss jetzt leider nicht wie ich die Platine wieder fest bekomme.
Ich dachte mit dem Motor drin wird genug Druck auf das Leitgummi
ausgeübt das der Thermostat wieder funzt -> Fehlanzeige!
Hat jemand eine Idee wie ich die Platine wieder fest bekomme ?

[Jörg W. (dl8dtl) (Moderator)]

MitLeser schrieb:
> Hat jemand eine Idee wie ich die Platine wieder fest bekomme ?

Naja, sinnvoller wäre es gewesen, dass mit Heißluft etwas warm zu machen 
und dann hochzuziehen … zu spät.

So wird wohl nur übrig bleiben, dass du die Platine anklebst. Das 
Gehäuse dürfte Polystyrol sein, das sollte sich gut kleben lassen.

[MitLeser (Gast)]

Hallo Jörg,
danke für die schnelle Antwort. Ja, Du hast recht, hätte ich besser 
machen können, aber meine Mittel hier zuhause sind beschränkt.
Deshalb, würde Heiskleber funtionieren? Oder was empfiehlst Du?

[Jörg W. (dl8dtl) (Moderator)]

MitLeser schrieb:
> Deshalb, würde Heiskleber funtionieren?

Heißkleber funktioniert ja praktisch überall. ;-)

> Oder was empfiehlst Du?

Ich würde wahrscheinlich erstmal gucken, ob man das mit so einem 
lösungsmittelbasierten Plastikkleber hinbekommt, denn der löst die 
Polystyrol-Pfosten ein bisschen an.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Da fängt man an und kann gleich wieder aufhören, weil wieder etwas 
dazwischen kommt. Was ich mir aber bisher erarbeitet habe, will ich hier 
hinterlegen, um nicht später einmal wieder ganz von vorn anfangen zu 
müssen.

Den ATmega 169PA über die ISP-Schnittstelle mit dem AVRISP mkII 
anzusprechen hat schonmal geklappt. Dafür habe ich alllerdings eine 
LiIon-Zelle an die Leiterbahnen der Batteriekontakte gelötet. Die FUSES 
und LOCK-BITS sind im jeweiligen Screenshot zu sehen. Die entsprechenden 
PADs auf der Platine sind ebenfalls als Foto hochgeladen. Das Gehäuse 
musste an den entsprechend markierten Stellen bearbeitet werden, um den 
10-Poligen Pfostenstecker lose anbringen zu können. Eine minimale Kante 
sollte jedoch erhalten bleiben, damit der Pfostenstecker nicht 
herausgezogen werden kann. Blöd ist, dass durch das Stecken und ziehen 
die Pinne machnmal mit wandern.

Außer dem TxD-Anschluß PE1 bzw. Pin 3( UART ), haben alle anderen Adern 
einen 330 Ohm Widerstand bekommen. Damit die Masseleitung ( blau ) nicht 
am Rad scheuert sind die Pinne gekürzt und die Ader ganz nah am Gehäuse 
verlötet. Am besten eignet sich Flachbandkabel. 0,14qmm ist noch etwas 
zu steif.

Weil die Platine mit verschweißten Plastikpinnen fest war, die ich 
weggeknippst habe, dachte mir das ich ein ca. 2mm dünnen Schaumstoff auf 
das Motorgehäuse klebe, was dann auf die Platine drückt, damit diese 
wiederum auf dass LCD-Leitgummi drückt.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Weil die Platine mit verschweißten Plastikpinnen fest war, die ich
> weggeknippst habe, dachte mir das ich ein ca. 2mm dünnen Schaumstoff auf
> das Motorgehäuse klebe, was dann auf die Platine drückt, damit diese
> wiederum auf dass LCD-Leitgummi drückt.
>
So, nun wollte ich den Thermostaten ( TS ) wieder zusammenbauen und 
einmal gucken, ob er auch noch funktioniert. Erste Problem war natürlich 
wirklich die Displayanzeige. Zu Anfang waren kurz ein paar Striche zu 
sehen und dann nichts mehr. Musste tatsächlich die Schaumstoffdicke 
erhöhen und bin auch auf die schmale Seite gegangen, weil man hier näher 
zum Leitgummi ist.
Man muss dabei darauf achten, dass das Zahnradfenster komplett frei 
bleibt.
Ein guter Indikator für die richtige Dicke ist, dass sich das Fenster 
nicht eindrücken lässt, wenn man auf dass Motorgehäuse drückt. Ein 
Plektrum mit 1.14mm Dicke war sehr hilfreich, weil ich öfters das 
Gehäuse öffnen musste um mit der Schaumstoffdicke herum zu 
experimentieren.

Es muss also nach dem einsetzen der Batterien, im Display eine 
Jahreszahl blinken ( 2010 ) und der Motor hat bei mir gedreht. Nach 
einstellen von Datum und Uhrzeit erscheint dann die Anzeige INST, was 
wohl für Installation steht.
Also den TS angebaut und auf OK gedrückt, danach erscheint ADAP für die 
Adaptionsfahrt und die LED leuchtet wenn aufgeheizt wird.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

weiß jemand zufällig was die Meldung FSLH zu bedeuten hat ?
Könnte Flash bedeuten, aber was fange ich damit an ?

In der Bedienungsanleitung steht nichts drinn und Tante G. weiß auch 
nichts.

Nachdem ich die Akkus entnommen habe und einfach wieder eingesteckt, war 
die Meldung weg und alles so wie es sein soll ( siehe vorheriges Posting 
).

Die LCD-Anzeige ist in Ordung, alle Buchstaben waren beim Einstellen 
eindeutig wie in der Bedienugsanleitung beschrieben.


Bernd_Stein