Knut B. schrieb: > Conny G. schrieb: >> Ich finde es wäre höchste Zeit für eine Portierung nach C. > > Weiß ich doch, aber nicht für mich. Kümmert euch drum. Von ASM nach C > ist ohnehin einfacher, als andersrum ;-). OK, einfach ist relativ. :-) Ich hab's jetzt mal getan. Das ist Knuts alte (unfertige) Firmware für den V2 / Comet (davon habe ich ein paar), übersetzt in C. Im Moment ist bis auf ein paar Deklarationen alles in einer C-Datei, damit lässt es sich einfacher hin und her suchen. Es handelt sich dabei um eine ziemliche 1:1-Umsetzung von Knuts Assemblerquelle, wesentliche Motivation war/ist, den Code zu verstehen. Alle Variablen sind so wie bei Knut benannt, alle Funktionen auch, nur die führenden Unterstriche weggelassen, die bei ihm für interne Marken stehen. Auch die Kommentare sind weitgehend die aus dem Assemblerprogramm. Die einzige bewusste Ergänzung, die ich vorgesehen habe ist, Datum und Uhrzeit beim Start auszunullen, wenn aus dem EEPROM 0xFF gelesen worden ist. Der Start mit dem Jahr 2255 (von dem nur 2055 angezeigt wird) und um 255:255 Uhr war mir dann doch zu nervig. :-) Knuts Code hat keine Copyright/Verbreitungsfestlegung, auf Nachfrage meinte er, ich soll es als Public Domain auszeichnen. Das habe ich darum dann auch mit meiner C-Umsetzung so getan.
Jörg W. schrieb: > Ich hab's jetzt mal getan. Jörg, das ist eine Heldentat, vielen Dank! Das öffnet die Tür für viele nicht-ASMler auch mal was dran zu machen.
:
Bearbeitet durch User
Super Jörg! Jetzt noch für den V3, da ist alles wieder ganz anders ;-).
Knut B. schrieb: > Jetzt noch für den V3 Da halte ich's genauso wie du: wenn ich mal V3 habe, wird mich das interessieren, aber vorerst nicht. ;-)
Wenn sich jetzt noch jemand findet, der es als Github repository o.ä. hosted, dann kann die Community sich um solche Dinge kümmern :-)
Kann ich bei bedarf gerne machen. Würdet ihr dann noch ein passendes Readme.md mit Disclamer etc. schreiben?
So, hier nun der Motorcode, benötigt meine Änderungen von Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" @Stefan, kannst du es bitte in dein Github tun? An dem Motorcode gibt es sicher noch einiges zu tun, z.B. wird die Ventil-offen Position noch nicht ermittelt (evtl. ist das auch gar nicht nötig). In den Beispielen ist eine einfache Regelung implementiert, die ist wirklich sehr simpel, regelt bei mir aber schon auf etwa +/-0.5 Grad die Raumtemperatur. So langsam wird das ganze brauchbar. Ich mache mich dann als nächstes mal an den Code für die RTC. Wir sollten auch eine Klasse für die ganzen Daten (Datum, Uhrzeit, Programm, Offset usw.) einführen, damit wir global auf alles zugreifen können und so die Steuerung über WLAN/BT/Funk flexibel wird. Als Name fände ich "Storage" ganz gut. Evtl. macht es auch Sinn für das "Programm" eine eigen Klasse zu machen, so wären dann Sonderwünsche die hier formuliert wurden einfacher umsetzbar (z.B. 10 Tage statt 7 Tage Rhythmus). Zur Steuerung über WLAN habe ich zum ESP8266 kürzlich gelesen, das man kein DHCP verwenden soll, damit reduziert sich die Verbindungszeit von 3-4s auf <200ms. Habs probiert, stimmt tatsächlich. Inklusive einem HTTP-Request komme ich so auf etwa 1s Gesamtlaufzeit. Ein Test mit einem 2200mAh LiPo Akku und alle 6s einen HTTP-Request (die restliche Zeit DeepSleep) brachte eine Laufzeit von 3.5 Tagen. Wenn man also den HTTP Request alle 10-15 Minuten macht, ist eine Heizperiode locker drin. @Jörg Wunsch Vielen Dank und großen Respekt vor der Arbeit! Obwohl Knuts ASM-Code auch sehr gut verständlich ist, versteht man es so doch noch einiges besser.
Aha, der Akku hält eine Heizperiode, solange die Heizung nicht geregelt werden muß? :)
@ batman Und wie soll uns dein Beitrag jetzt weiterhelfen? Kannst du uns beim Programmieren aushelfen? Und rechnen kannst du doch sicher? Du kannst davon ausgehen, das ich bei meinen Überlegungen die Regelung mit einbezogen habe. Wenn man von meinem kleinen Test ausgeht (der es nicht ganz trifft, da noch ein LDO und ein Temperatursensor am ESP hing), dann kommt man bei 10 Min Intervall auf ca. 350 Tage, bei 15 Minuten ca. 525 Tage. Eine Heizperiode dauert ca. 220 Tage und wenn ich nicht irre, sind die Thermys mit einer Batterielaufzeit von ca. 3 Jahren angegeben. Und wenn man jetzt noch ein wenig optimiert (persistente HTTP-Verbindungen, MQTT oder irgendetwas mit UDP), dann sehe ich da kein Problem.
Conny G. schrieb: >> Ich hab's jetzt mal getan. > > Jörg, das ist eine Heldentat, vielen Dank! Hier noch ein Update. Ich habe noch einige kleine mehr oder minder schwere Bugs in der Umsetzung gefunden und repariert. Ich bin der Meinung, dass der C-Code jetzt erstmal genauso gut funktioniert, wie Knuts Assemblerversion. Einzige weitere Änderung gegenüber der Assemblerversion ist, dass ich MenuFunc wegfallen lassen habe und die Funktionszeiger mit in MenuTable integriert habe. Für mich selbst werde ich nun zusehen, daraus etwas zu zimmern, was „mehr C-like“ ist, bspw. PutString("ADAP") statt der einzelnen Ausgabe von jeweils vier Zeichen. Auch ist noch genug Platz im Flash, als dass man sich die formatierte Ausgabe einfach mit sprintf() organisieren kann, statt jedesmal irgendwelche Verrenkungen zur Umrechnung der Zahl, Unterdrückung von Vornullen etc. zu machen. Falls jemanden hier noch die V2 (Comet) interessiert, kann ich ja das Ergebnis meiner weiteren Arbeit hin und wieder posten.
Jörg W. schrieb: > Falls jemanden hier noch die V2 (Comet) interessiert, kann ich ja das > Ergebnis meiner weiteren Arbeit hin und wieder posten. Mach ich dann mal hier als Referenz für alle, die das interessieren möge. Ich habe aufbauend auf dem nach C umgeschriebenen Code von Knut Ballhause nun meine eigene Firmware weiterentwickelt. Hier eine Übersicht der Änderungen: . Beim Programmieren der Ende-Zeit eines Timers wird die Anfangs-Zeit als Vorgabe benutzt (statt 00:00); während der Programmierung blinkt „STRT“ bzw. „ENDE“ im Wechsel mit der Zeit . Menüs für die Temperatureinstellung implementiert („zu Hause“, „außer Haus“, „Nacht“) . Temperaturoffset implementiert (in 0,5-K-Schritten) . Automatik-Modus implementiert: ist er aktiv, wird die jeweilige Solltemperatur durch das Profil vorgegeben; bis zur nächsten Umschaltung kann diese dann manuell modifiziert werden . Programmier- und Temperaturdaten werden im EEPROM gesichert . Wochenend-Programmiermodus („T6-7“, analog zu den anderen Blockmodi) . Beim Batteriewechsel wird der Ventilzustand (Position und TopValue) im EEPROM gespeichert; wird dieser Zustand beim Start vorgefunden, dann erfolgt kein zwangsweiser Adaptionslauf . „RES“ macht nun einen Reset aller EEPROM-Daten . Aufrufreihenfolge beim Abspeichern von Datum und Uhrzeit korrigiert (war in der weiter oben geposteten Variante falsch herum, sodass diese Daten beim Batteriewechsel nicht gespeichert worden sind) . Urlaubs-Funktion implementiert: sie benutzt den normalen Automatikmodus, aber während der „im Haus“-Zeiten wird die „außer Haus“-Temperatur als Vorgabe genommen; Vorgabe einer Nachttemperatur bleibt jedoch wie sonst . Bedienungsanleitung geschrieben Die Firmware war gerade noch rechtzeitig vor dem Ende der Heizperiode fertig, sodass sie nun noch ein paar Tage lang getestet werden konnte. Was noch benötigt wird, aber jetzt mangels Testmöglichkeit fehlt: ein automatischer Aufruf der Adaptionsroutine, wenn sich das Ventil nicht mehr richtig schließt. Dafür brauche ich aber zuerst noch ein paar Ideen und Nutzungsdaten (wie oft öffnet/schließt Ventil, bis man merkt, dass es nicht mehr vollständig schließt?). Der Zustand ist aber allemal um Welten besser als mit der originalen Firmware.
Jörg W. schrieb: > Was noch benötigt wird, aber jetzt mangels Testmöglichkeit fehlt: ein > automatischer Aufruf der Adaptionsroutine, wenn sich das Ventil nicht > mehr richtig schließt. Die alten Zeros konnten den Strom des Motors noch nicht messen. Daher habe ich sie einfach immer bis zum Abwürgen des Motors drehen lassen. Das hat dann dazu geführt, dass sie ab und an aus der Verankerung sprangen und dann unter dem (heißen) Heizkörper lagen. Nicht zuletzt deswegen habe ich mich über die neuere Hardware mit der Strommessung gefreut. Ansatz: wenn Dein Programm merkt, dass die Temperatur trotz des vermeintlich erreichten 0-Punkts des Ventils zu hoch ist, drehe einfach 10 Ticks weiter in Richtung "Zu". Dies machst Du aber nur dann, wenn die Temperaturerhöhung über Nacht besteht, um Sonneneinstrahlung als Ursache auszuschließen. Ist der Regelbereich dann wieder in Ordnung, setze den neuen Wert als 0-Punkt.
Knut B. schrieb: > Die alten Zeros konnten den Strom des Motors noch nicht messen. Daher > habe ich sie einfach immer bis zum Abwürgen des Motors drehen lassen. Meinst du, es wäre sinnvoll, die Adaptation-Routine so auszubauen, dass sie auch für den Endanschlag den Strom misst? Für „free running“ und „valve touched“ hast du es ja schon drin gehabt. Was würde man als Kriterium nehmen, >20 % Steigerung des Werts? > Ansatz: wenn Dein Programm merkt, dass die Temperatur trotz des > vermeintlich erreichten 0-Punkts des Ventils zu hoch ist, drehe einfach > 10 Ticks weiter in Richtung "Zu". Das klingt sinnvoll. Werde ich einbauen, wird aber vermutlich erst in der nächsten Heizperiode sich richtig testen lassen. Im Moment gibt's da kaum noch Ventilbewegungen.
Jörg W. schrieb: > Meinst du, es wäre sinnvoll, die Adaptation-Routine so auszubauen, > dass sie auch für den Endanschlag den Strom misst? Für „free running“ > und „valve touched“ hast du es ja schon drin gehabt. Ja nee, geht doch nicht, weil die Hardware den Strom nicht messen kann. Hier wird lediglich die Drehzahl geprüft. Der Motor dreht halt schneller, wenn er frei läuft und langsamer, wenn er den Ventilstift niederdrückt. Da dies relative Werte sind, kann man diese nicht direkt dazu benutzen, um festzustellen, ob das Ventil schon geschlossen ist, oder nicht. Zumal der Motor in der Nähe des unteren Druckpunktes beim Anlaufen kaum noch Fahrt aufnimmt, da die Reibung schon so hoch ist. Da ist die Strommessung bei den V2 und V3-Geräten viel genauer und reproduzierbar. Edit: ach so, Du hast ja V2 Geräte - da musst Du mal gucken, ob die Strommessung geht. Die Werte verändern sich etwas, wenn die Batterie nachlässt, aber das ist dadurch, das VCC gleichzeitig die Referenzspannung für den ADC ist, ganz gut kompensiert :-)
:
Bearbeitet durch User
Knut B. schrieb: > Die Werte verändern sich etwas, wenn die Batterie nachlässt, Daher würde ich ja den Wert relativ zur normalen Ventilbetätigung benutzen. Der dürfte ja dann bei nachlassender Batterie auch bereits geringer sein. OK, mal sehen, das wird für die nächste Heizperiode übrig bleiben. Vielleicht hänge ich mir dann auch schon mal einen Funkmodul dran und sende die Debug-Info live nach draußen. Dann kann man die Vorgeschichte auch besser aufzeichnen, was so passiert ist, bis mal irgendwann das Ventil dann nicht mehr richtig schließt.
Jörg W. schrieb: > Vielleicht hänge ich mir dann auch schon mal einen Funkmodul dran > und sende die Debug-Info live nach draußen. > Dann wäre es schön, wenn du ein von den Chip's verbauen würdest der hier bereits eingebaut ist : Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Bernd_Stein
Bernd S. schrieb: > Dann wäre es schön, wenn du ein von den Chip's verbauen würdest der hier > bereits eingebaut ist : Sorry. Ich habe einige ATmega128RFA1 herumliegen und plane daher, diese irgendwie zusammen mit der µracoli-Bibliothek zu benutzen. Ich habe ohnehin schon etwas Infrastruktur für diese Teile da, um bspw. die Außentemperatur zu messen, da muss ich das Netzwerk eigentlich nur aufbohren dafür.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Sorry. Ich habe einige ATmega128RFA1 herumliegen und plane daher, > diese irgendwie zusammen mit der µracoli-Bibliothek zu benutzen. > Danke für die schnelle und unmissverständliche Antwort. Da brauche ich nicht weiter zu hoffen. Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen geantwortet haben, wahrscheinlich interessiert sie dieser Thread gar nicht mehr oder sie haben vergessen das *Häkchen bei Thread beobachten* zu setzen. Bernd_Stein
Bernd S. schrieb: > Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen > geantwortet haben Ich vermute, dass die RFMxx-Funkmodule bei den meisten hier das ist, was sie am ehesten für sowas benutzen würden.
Jörg W. schrieb: > Bernd S. schrieb: >> Schade, das die Anderen hier nicht auf meine vorhergehenden Fragen >> geantwortet haben > > Ich vermute, dass die RFMxx-Funkmodule bei den meisten hier das ist, > was sie am ehesten für sowas benutzen würden. Ja, Rfm69. Wie ist denn die Reichweite des ATmega128RFA1? Eher wie Bluetooth, ein paar Meter und meist nicht mehr durch die nächste Wand?
:
Bearbeitet durch User
Conny G. schrieb: > Wie ist denn die Reichweite des ATmega128RFA1? Hängt von den Antennenstandorten ab. Freifeld haben wir schon mehr als 500 m erreicht, allerdings mit einem ordentlichen Dipol dran, nicht nur Stummel oder PCB-Mäander. Im Moment habe ich die „Basisstation“ im Arbeitszimmer neben meinem Server oben auf einem Schrank, sodass die Antenne relativ freie Rundumsicht hat. Von da hört sie normalerweise noch die auf dem Balkon (drei Wände dazwischen) am Boden liegende Pumpensteuerung des Gießsystems für die Balkonpflanzen. Wenn aber jemand dort die Kiste mit der Elektronik ein bisschen ungeschickt mit den Füßen in die Ecke baldovert, reißt die Verbindung schon auch mal ab. Eventuell überlege ich mir auch noch was mit sleeping routers, d. h. geroutet wird nur, wenn sie zyklisch aufwachen. Dann könnte ich jeden Knoten als Router benutzen. Dafür brauche ich aber eine halbwegs genaue Zeit (32-kHz-Quarz), im Moment wachen die im Netz befindlichen Sensoren nur „nach Nase“ (Watchdogoszillator) auf, da die Basisstation ja immer auf Empfang ist. p.s.: Die derzeitigen Sensoren haben nur einfache Antennen, teils ein Stummel (λ/4 ohne richtige Groundplane), teils ein Dipol direkt auf dem PCB.
:
Bearbeitet durch Moderator
Das ist ja ziemlich ordentliche Reichweite für die Angaben im Datenblatt. Hätte ich bei 2.4Ghz da gar nicht erwartet!
Die haben dank des Spreizgewinns (250 kbit/s bei 2 MHz Bandbreite) eine recht gute Empfängerempfindlichkeit. Das macht sich bezahlt.
Nachdem keine Antwort bezüglich der silberfarbenen Absetzungen kam - hier nun die Antwort. Leider sind diese Teile lackiert. Jetzt was anderes. Wenn die Platine ausgehebelt wird, daran denken, das an der dafür günstigen Stelle ein Bauteil sitzt. Wahrscheinlich der Temperaturfühler. Am Layout bzw. an einigen Lötpads zum HT100, also ohne Blue Tooth ( BT ) gab es Veränderungen. Ich habe das ganze nicht genau untersucht, lediglich die auffälligen Sachen markiert. Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Bernd_Stein
:
Bearbeitet durch User
Da bei meinen Thermostaten der ATmega169PA verbaut ist, wollte ich wissen wo die gravierensten Unterschiede zum PV Typ sind. Ich würde sagen in den Power-Modes. Ultra-Low-Power Consumption ( picoPower devices ) Active Mode : 1MHz, 1,8V : 215µA -> PA : 330µA -> PV 32kHz, 1,8V including oscillator : 8µA -> PA 10µA -> PV Im Power-Save-Mode ermöglicht nur der PA-Typ eine Stromreduktion von 750nA bei 1,8V. Dachte auch im Speed Grade hätte sich was getan, da dort nur 1,8V - 5,5V 0-16 MHz stand, aber das ist nur ein Marketing-Trick. Auch hier ist bei genauerem Studium festzustellen, das es auch hier eine Rampe für den SOA ( Save Operating Area ) gibt. Beim PV-Typ stand dies wenigstens klar zu erkennen : 1,8V - 5,5V 0-4 MHz 2,7V - 5,5V 0-8 MHz Ok, der PA-Typ geht bis 16 Mhz, was natürlich beim PV-Typ nicht gegeben war. Bernd_Stein
:
Bearbeitet durch User
Zwischen dem PV und dem PA Typ gibt es Unterschiede bei einigen I0-Registern und deren Bitzuordnung. Bitte mal die Migration Notes konsultieren.
Bernd S. schrieb: > aber das ist nur ein Marketing-Trick. Nö, nicht ganz: vor den A-Typen gab es jeweils eine Variante, die für low-speed low-voltage definiert war und eine, die für high-speed 5 V only vorgesehen war. Mit dem "die shrink" der A-Versionen haben sie diese Unterscheidung nicht mehr benötigt, der komplette Bereich wird jetzt in einem Bauelement abgedeckt. Ansonsten ist der A-Typ einfach der Nachfolger. Sehr wahrscheinlich konnten sie diesen 1:1 statt des Vorgängers da einsetzen.
Knut B. schrieb: > Bitte mal die Migration Notes > konsultieren. > Das ist ja so eine Sache. Ich würde sagen die AVR506 und AVR529 sind da die Referenz. Aber dort steht für mich nicht erkennbar der Unterschied zwischen PV und PA. Überhaupt ist es für mich ein Rätselraten was die mit den Suffix meinen. PicoPower-Typen => P ? LowVoltage-Typen => V ? Wofür steht dann das A ? Man findet darüber keine eindeutigen Angaben. Bernd_Stein
Der Atmega169-V war die Low Voltage Variante des alten Atmega169. Dann kam die -P Variante. Diese ist für 1.8-5.5V mit niedrigem Stromverbrauch (Pico Power). Die -A Variante kam noch später und die kam dann mit dem oben erwähnten Die-Shrink inklusive Pico Power. Mit der -A Variante kam beim 169 auch das Verändern einiger Register, weshalb die Firmware für die V2-Regler dann auch nicht mehr auf den V3-Reglern lief. Die Interrupt-Bits für externe Interrupte liegen woanders. Und die Namen etlicher Register und Bits wurden an die der neueren Atmega-Serie angepasst, damit alle Datenblätter und Bibliotheken auf die gleichen Definitionen passten.
SiverCrest Heizkörperthermostat von Lidl mit USB, aber ohne Bluetooth. Auf der Platine ist "COMET" aufgedruckt. Welcher Schaltplan käme dieser Version am nächsten? Stromaufnahme des Stellmotors bei 2,5V: 30mA im Leerlauf 180mA bei Anschlag
:
Bearbeitet durch User
Bernhard S. schrieb: > Welcher Schaltplan käme dieser Version am nächsten? Weiß nicht.. Aber das sieht genauso aus, wie der Thermy von Aldi von vor 1 1/2 Jahren. -------- Und nein! Das ist kein USB! Auch wenn es wie USB aussieht, ist da doch eher SPI drin.
Da kommt ein USB-Programmierstick dran (muß käuflich erworben werden) - aus dem Internet Programm herunterladen (Web-Addy für Stick-Bestellung/Programm steht auf der Verpackung), installieren, gewünschte Programmierung am PC vornehmen und dann auf den Stick schieben (fasst glaube ich 6 oder 7 verschiedene Programmierungen). An Thermostat anstecken und die gewünschte Programmierung 'rüberziehen' - der Thermostat zeigt P1 - P6 (oder 7) im Display an - gewünschte Einstellung auswählen und mit OK bestätigen (IIRC). Der Stick enthält einen kleinen Akku oder einen Super-Cap, welcher sich am Computer über den USB-Anschluß aufläd - der Stick behält die auf ihm gespeicherten Einstellungen nur für eine recht begrenzte Zeit. Aber man hat sie ja noch auf dem Computer gespeichert und kann sie ja so wieder 'reaktivieren'...
Bernhard S. schrieb: > SiverCrest Heizkörperthermostat von Lidl mit USB, aber ohne Bluetooth. > Hallo Bernhard, endlich tut sich hier mal wieder was. Freue mich das noch ein Assemblerprogrammierer nun dabei ist. Gucke mir öfters deine Programme an. Danke, das du dir immer so viel Mühe gibst, das Andere es verstehen können und nachbauen. Mache leider immer was anderes, so das meine bisherigen ASM-Erfahrungen und das Wissen immer mehr "verblassen". Ich habe ja folgendes Problem mit den programmierbaren Thermostaten : Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" In deinen bisherigen Programmen habe ich leider nichts ähnliches gefunden, um dort mal abzukupfern ;-) Bernd_Stein
Hallo Bernd,
>...Freue mich das noch ein Assemblerprogrammierer nun dabei ist.
Ein Assemblerprogramm für den THERMOtronic ist momentan in Arbeit.
Werd's demnächtst hier veröffentlichen.
Noch kann es nicht viel, nur das LCD lässt sich erst vernünftig
ansteuern z.B. Bargraph und die Ziffern...
Bernhard
Bernhard S. schrieb: > Ein Assemblerprogramm für den THERMOtronic ist momentan in Arbeit. > Werd's demnächtst hier veröffentlichen. > Schön, was hast du denn genau vor ? Ist bei deinem wirklich der verbaut ? Habe ich aus einem anderen Thread von dir. > Eine Lösungsvariante für den ATmega136 (Heikörperregler THERMOtronic) > Bernd_Stein
Eine Variante für den THEROtronic, natürlich in Assembler: Beitrag "Heizkörperregler THERMOtronic ATmega169 Assembler"
@Ronny Sehr gute Zuarbeit :-) Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Anbei die Anschlussbelegung des SilverCrest Bluetooth Smart
Ein Assemblerbeispiel für den Heizkörperregler SilverCrest Bluetooth ATmega169 in Assembler Beitrag "Heizkörperregler SilverCrest Bluetooth ATmega169 Assembler"
Achtung Laienfrage: Der Resetpin am "Thermy" / "Sparmatic Comet" ist nicht zufällig für einen kompletten Softwarereset nutzbar? Ich habe das Problem, dass ich Programmzeiten eingeben kann, sie aber nicht gespeichert werden. Ich kann ihn zwar per Menü Punkt RES zurücksetzen, das hift aber nicht. er setzt sich immer wieder auf 7 Uhr bis 22 Uhr zurück....
Mattes schrieb: > Der Resetpin am "Thermy" / "Sparmatic Comet" ist nicht zufällig für > einen kompletten Softwarereset nutzbar? Software-Reset hat ein AVR nicht. Man könnte es über einen Watchdog-Reset emulieren, aber da du dann sowieso in die Firmware eingfreifen müsstest, kannst du auch gleich stattdessen den Bug suchen.
Jörg W. schrieb: > Mach ich dann mal hier als Referenz für alle, die das interessieren > möge. Hallo, ich hoffe, ich hab's jetzt nicht übersehen, aber gibt's den Source schon wo auf github? Ich versuche mich gerade daran ein MRF24J40MA Modul zu integrieren und würde dafür gerne forken.. Falls nicht, Jörg: darf ich deinen Code auf meinem github hosten und darauf aufbauen?
Lukas R. schrieb: > Hallo, ich hoffe, ich hab's jetzt nicht übersehen, aber gibt's den > Source schon wo auf github? Nö, hatte ich keinen Bedarf dafür gesehen. Wenn du denkst, dass das wirklich lohnt, kann ich ihn aber da hochladen. Einen Github-Account habe ich, allerdings sträubt sich Git immer ein bisschen, wenn ich das benutzen will. :-) > Falls nicht, Jörg: darf ich deinen Code auf meinem github hosten und > darauf aufbauen? Ist doch Public Domain, da Knut Ballhause seinen Assemblercode (den ich letztlich nach C übersetzt habe) ebenfalls Public Domain gemacht hat.
Jörg W. schrieb: > Wenn du denkst, dass das wirklich lohnt, kann ich ihn aber da > hochladen. Einen Github-Account habe ich, allerdings sträubt sich > Git immer ein bisschen, wenn ich das benutzen will. :-) Also ich persönlich finde, es zahlt sich immer aus, schon allein wegen der Möglichkeit zusammenzuarbeiten und der history, aber ich mach das beruflich, also bin ich vielleicht etwas vorbelastet :) - Du kannst bei github ja das Web-Interface zum Hochladen verwenden, dafür ist wenig bis gar kein git-Wissen nötig. Wenns dir trotzdem zu mühselig ist, dann würde ich deinen (unveränderten) Code in einem Repository bei mir hosten, und meine Änderungen dann in einem fork machen, dann bleibt state komplett erhalten. Bzgl. Public Domain - das hab ich wohl gesehen, aber fragen wollte ich trotzdem :)
Mahlzeit! Nachdem wir in ein neues Heim umgezogen sind wo die Halterung für meine Cometen (v2, M169P) deutlich besser passt als im alten, habe ich die Regler mal wieder ausgegraben und wollte mal schauen, was es so neues gibt. Jörg hat sich ja viel Mühe gegeben mit der C-Portierung -> gleich mal aufgespielt. Leider ist es mir damit nicht gelungen die Schaltzeiten zu programmieren weil die OK-Taste irgendwie ganz und gar nicht entprellt ist (es schnippt viel zu schnell zum nächsten Punkt bzw. überspringt ein paar Zwischenpunkte) ... ...also wieder Knut's Firmware draufgespielt (mein Stand ist beta006 vom 04.02.2014 20:25:24) und keine Probleme. Bin ich der einzige mit diesem Problem bzw. hab ich was übersehen? Und: @Lukas: wo liegt Dein git-repo?
:
Bearbeitet durch User
Hmm, Probleme mit der OK-Taste habe ich nicht. Wenn du magst, kannst du ja mal meinen C-Code und Knuts Assemblercode an dieser Stelle vergleichen. Es ist ja nicht immer ganz einfach, die exakten Intentionen und Algorithmen von vielen Dutzend Seiten Assemblercode zu erfassen und dann tatsächlich in einer anderen Sprache wiederzugeben, insofern ist es gut möglich, dass ich mich da irgendwo mal geirrt habe.
Hm.... ich weiss ja nicht ob in Knut's Assemblervariante eine Tastenentprellung wirklich implementiert war, vorgesehen war sie auf jeden Fall und im C-Code gibt es eine entsprechende Variable "ButtonDebounce" welche wiederrum jedoch nirgendwo genutzt wird....
Andreas K. schrieb: > im C-Code gibt es eine entsprechende Variable "ButtonDebounce" welche > wiederrum jedoch nirgendwo genutzt wird Gerade nachgesehen. Im Assemblercode gibt's die auch, aber außer in einer Debugroutine wird sie nicht benutzt. Hatte sie damals nur stur aus dem Assemblercode in den C-Code kopiert (wie vieles andere auch). Ansonsten sollte der C-Code an dieser Stelle (ReadButtons) in der Tat eine 1:1-Umsetzung des Assemblercodes sein (dort in User.asm).
Hm... dann müsste ich das mal noch eingehender untersuchen, vielleicht EEPROM-Reset machen... Aber aktuell sind die Regler für mich leider nicht benutzbar (bzw. waren sie das noch nie) da sie schon nach 1..2 Tagen nicht mehr richtig schließen (Danfoss). Leider bin ich berufs- und familienbedingt mental schon zu sehr ausgelastet um hier selber Hand anzulegen... Deshalb: kennt jemand ein vergleichbares, käuflich erwerbbares System wo die Regelung wirklich zuverlässig funktioniert, d.h. insbesondere kein Überheizen durch verlorengegangene Ventil-Adaption? Ich hätte auch noch ne Idee für die automatische Erkennung ob neu adaptiert werden muss: bei Erreichen der Null-Position sollte ja der Motorstrom ansteigen. Mann könnte sich beim Adaptieren bzw. bei jeder Fahrt auf Nullstellung merken wie hoch der Motorstrom maximal war und wenn der deutlich geringer ist als beim letzten mal -> noch etwas weiter drehen bzw. neu adaptieren...
Andreas K. schrieb: > Ich hätte auch noch ne Idee für die automatische Erkennung ob neu > adaptiert werden muss: bei Erreichen der Null-Position sollte ja der > Motorstrom ansteigen. Müsste ich mal gucken. Hier ist das so nach ca. 'ner Woche, dass man mal wieder adaptieren muss.
Wenn man es clever anstellt, muss man zwischendurch gar nicht adaptieren. Einmaliges Einmessen beim Batterien einlegen reicht. Die Strommessung kann dafür herangezogen werden. Die alten Geräte vor 2012 konnten das noch nicht aber alle neueren Derivate können das. Leider bin ich nie dazu gekommen, meine Routinen daraufhin anzupassen, aber da alles soweit bei mir läuft, sehe ich nicht wirklich die Notwendigkeit, obgleich man einige Dinge in der Motorsteuerung sicher noch optimieren kann.
Knut B. schrieb: > Die Strommessung kann dafür herangezogen werden. Du meinst, wenn man weiß, dass man auf 0 schließt, stellt man sicher, dass der Strom wieder seinen ursprünglich gemessenen Wert erreicht? Wenn die Batterien nachlassen, wird man aber den ursprünglichen Strom gar nicht mehr erreichen können. Gut, dann müsste man wohl den später ermittelten Wert bis zum Batteriewechsel als neuen eintragen. Vielleicht habe ich nochmal Nerv, mir das anzusehen.
Man sollte den Strom relativ zum Öffnen-Strom messen und einen entsprechenden Schwellwert eintragen. Da die Referenzspannung für den ADC von der Batteriespannung abgeleitet wird, wird sich der gemessene Strom beim Schließen bei fallender Batteriespannung nur unwesentlich ändern. Sollte man durch Probieren verifizieren können.
Ich habe das Repository jetzt mal komplett auf Github geschoben: https://github.com/dl8dtl/sparmatic Ich habe mein altes Mercurial-Repo dahin migriert, sodass man auch meine damaligen lokalen Commits sieht. ;-) Habe vor paar Tagen einen Versuch implementiert, für das leidige Problem der nicht ganz schließenden Ventile einen Workaround einzubauen: wenn die Temperaturtendenz auf "steigend" im Zustand "heiß" oder "darüber" ist und das Ventil bereits (vermeintlich) auf 0 steht, dann wird ggf. versucht, die aktuelle Position leicht nach oben zu korrigieren, sodass weitere Schritte in Richtung schließen möglich werden. Damit soll ein ggf. erfolgter Schrittverlust des Schrittmotors kompensiert werden. Die Korrektur ist an ein paar Bedingungen geknüpft (nur im Winter; es muss innerhalb des letzten Tags eine Öffnung des Ventils gegeben haben; direkt nach einem Adaptieren wird eine Weile gewartet, da das Ventil ja gerade voll geöffnet war). Als nächstes würde ich noch eine Justiermöglichkeit für den Uhrentakt einbauen. Knut hatte da einen festen Fehlerwert eingebaut, der von dem meiner Quarze deutlich abweicht, sodass die Uhren auf Dauer einiges falsch gehen. Ich werde wahrscheinlich seinen Korrekturalgorithmus belassen, aber den Korrekturwert einstellbar machen.
Hallo Jörg, mein Tipp für das Schließen des Ventils: Ziehe die Strommessung heran und betrachte das Ventil als geschlossen, wenn ein bestimmter Motorstrom beim Zufahren erreicht ist. Diesen Strom kannst Du einstellbar machen, so dass schwegängige Ventile von normalgängigen unterschieden werden können. Wenn die Stromschwelle erreicht ist und der Motor dann abgeschaltet hat, setze auch den Schrittzähler auf 0, dann passen die Werte für das Öffnen immer wieder.
Meinst du, dass man dies bei jedem Stellen des Ventils bis auf 0 machen sollte?
Also für mich läuft das alles auf eine Art adaptive Adaptierung heraus :-D Die Adaptierung basiert ja auch auf Messung des Motorstromes... Aber könnte man nicht einfach jedes Mal wenn es auf 0 drehen soll das ganze als Adaption ausführen? ...oder wenn das zu viel Batterie verbraucht: nur bei jedem x-ten Mal adaptieren?
Wenn das Ventil zugedreht werden muss, dann muss es auch zu sein, sprich: Es muss die notwendige Kraft dazu aufgewendet werden. Dies kann über den Strom gelöst werden. Die Kraft sollte aber gut dosiert werden, sonst ist das Ventil nicht zu oder die Halterung reißt ab. Hier ist ein bisschen Empirie gefragt. Die Zählpulse, wie lang der Ventilweg ist, braucht man m.E. nur, wenn das Ventil geöffnet wird oder wenn man kleine Wege in Richtung "zu" fährt. Wenn die Regelung ausgibt, dass das Ventil komplett zu soll, dann misst man den Strom und weiß somit, wie weit man noch leiern darf. Und es wird nie wieder ein halbgeschlossenes Ventil geben. Da es von der Kraft her keinen Unterschied macht, ob man einen zuvor ermittelten Zähler bis auf 0 dreht oder gegen den Stromschwellwert fährt, werden die Batterien auch nicht schneller leer. Eine überschwingende Regelung beispielsweise verbraucht viel mehr im Verhältnis dazu.
Der Argumentation kann ich folgen … man müsste mal Messreihen machen, wie viel Strom fließt unter unterschiedlichen Umständen (normales Schließen mit voller/leerer Batterie, Anschlag erreicht volle/leere Batterie). Wenn's blöd kommt, muss man außer der Strommessung auch die Batteriespannung noch einbeziehen, um ein sicheres Kriterium zu haben.
:
Bearbeitet durch Moderator
Günstigerweise ist AREF=Vcc, was bedeutet, dass bei leerer werdender Batterie der gemessene Strom ansteigt, der reale Strom durch den Motor aber geringer wird. Ob es genau umgekehr proportional ist und sich somit nahezu aufhebt, kann ich nicht sagen. Die Batteriespannung kann ja einfach gemessen werden und wenn nötig, korrigiert man den gemessenen Strom etwas. Fakt ist, dass der Motor bei ziemlich leerer Batterie beim Zufahren auch zum Stillstand kommen kann, weil einfach der Saft nicht mehr ausreicht, um die Rotation gegen den störrischen Ventilstößel aufrecht zu erhalten. Das sind aber Extremwerte, die man recht leicht mit einem Labornetzteil nachstellen kann. Kritisch sind hier eher die verschiedenen Ventile, die von butterweich bis hakelig und vergriest daherkommen. Wir haben auf Arbeit auch ein paar "digitale" Ventile bei denen 1/10mm Ventilweg über auf und zu entscheidet. Das ist für die Regelung eine Herausforderung, insbesondere bei 80°C Vorlauftemperatur...
:
Bearbeitet durch User
Hallo, ich habe heute bei Aldi zufällig vier Comet Thermostate erworben nachdem ich vorher durch euren Thread und der Möglichkeit einer alternativen Firmware sensibilisiert war. Leider scheinen diese Thermostate keinen ATmega 169Px Controller sondern einen Cypress MB95F374L zu haben. Ein Micro USB für SPI ist wohl vorhanden. Hat evtl. schon jemand (Programmier-) Erfahrung damit? Lars
Das ist natürlich Grütze und es steht leider nicht außen dran. Nee, mit Cypress hab ich´s nicht so... Hat bestimmt 2Cent fuffzich weniger in der Herstellung gekostet, als mit ATMEL Chip...
Danke für´s Posten, dann macht ein Anderer nicht auch noch den Fehler, das Ding zu kaufen.
Knut B. schrieb: > Wir haben auf Arbeit auch ein paar "digitale" Ventile bei > denen 1/10mm Ventilweg über auf und zu entscheidet. Das ist offensichtlich "Stand der heutigen" Technik. Stichwort: Ventilkennlinie. Irgendwo hier im Forum hatte ich mich schon mal über das Zusammenspiel Ventilkennlinie/Heizkörperkennlinie ausgelassen. Kannst Du mir verraten, wie ihr das Problem gelöst habt. Als einen besseren Weg würde ich sehen, wenn jemand Heizkörperventilhersteller davon überzeugen könnte, Heizkörperventile mit gleichprozentiger Ventilkennlinie herzustellen.
Naja, neue Ventile funktionieren meistens erst mal eine Weile sehr gut, bis Kalk und Dreck das Ding unbrauchbar machen und die Dichtungen hart wie Stein sind. Wir haben einfach den Durchfluss des Heizkörpers im Rücklauf gedrosselt und schon verhält sich die Kiste kooperativ.
Knut B. schrieb: > Wir haben einfach den Durchfluss des Heizkörpers im > Rücklauf gedrosselt und schon verhält sich die Kiste kooperativ. Und ich hatte gehofft, dass es eine Lösung mit digitaler Technik gibt, um eine Regelung zu ermöglichen. An der Rücklaufverschraubung zu drehen entspricht nur eine Art -hydraulischer Abgleich- und verschlechtert das Regelverhalten, da die Ventilautorität sinkt.
Entscheident ist, ob die Heizung nachher funktioniert. Man kann naturlich die Regelung auch anpassen, dass nur minimale Ventilwege gefahren werden aber das müsste man dann auf jedes Ventil anpassen.
Knut B. schrieb: > Man kann > naturlich die Regelung auch anpassen, dass nur minimale Ventilwege > gefahren werden aber das müsste man dann auf jedes Ventil anpassen. Ich weiß nicht, ob Du dich schon intensiver mit Ventilkennlinien, Ventilautorität, kvs-Wert usw. intensiver beschäftigt hast. Wenn es wieder Ventile mit Regelkegel geben würde, dann wäre die Nutzung eines digitalen PI(D)-Reglers nahezu problemlos möglich. Z. Zt. teste ich gerade, ob evtl. doch auch mit den "Gartenwasserhähnen heutiger Bauart" eine gute Regelung möglich ist, wobei ich allerdings ein andere Marke (equiva) verwende und davon nur Motor mit Getriebe.
:
Bearbeitet durch User
wolle g. schrieb: > Ich weiß nicht, ob Du dich schon intensiver mit Ventilkennlinien, > Ventilautorität, kvs-Wert usw. intensiver beschäftigt hast. So intensiv es meine Heizungsanlage erfordert. Nicht wissenschaftlich. wolle g. schrieb: > Wenn es wieder Ventile mit Regelkegel geben würde, Das sind Stellkegel, geregelt wird im Regler, nicht im Ventil. wolle g. schrieb: > Z. Zt. teste ich gerade, ob evtl. doch auch mit den "Gartenwasserhähnen > heutiger Bauart" eine gute Regelung möglich ist Ich sag mal so: Der Raum ist sehr träge und selbst wenn das Ventil ständig auf und zudreht, ist es möglich, die Temperatur bei kleiner 1 Grad Abweichung konstant zu halten. Ich will den Aufwand nicht zu hoch treiben, ich möchte ja auch noch wohnen nebenbei. Die Zeiten des nächtelangen Programmierens und Recherchierens sind inzwischen vorbei. Und tagsüber muss ich ja arbeiten ;-). Ich lese aber gern mit.
:
Bearbeitet durch User
Knut B. schrieb: > Ich sag mal so: Der Raum ist sehr träge und selbst wenn das Ventil > ständig auf und zudreht, ist es möglich, die Temperatur bei kleiner 1 > Grad Abweichung konstant zu halten. Da habe ich andere Anforderungen an den Regelkreis. Da zeigt ja sogar ein stinknormaler mechanischer Thermostatkopf mit Dehnungskörper ein besseres Regelverhalten. >Das sind Stellkegel, geregelt wird im Regler, nicht im Ventil. Bleiben wir lieber bei Regelkegel. Auch mein google findet keinen Stellkegel. >So intensiv es meine Heizungsanlage erfordert. Ich habe den Eindruck, dass viele Heizungsbauer und Betreiber so denken. Sonst gäbe es wahrscheinlich nicht solche "Gartenwasserhähne heutiger Bauart" mit einem Ventilteller an Stelle eines Kegels.
:
Bearbeitet durch User
Knut B. schrieb: > Günstigerweise ist AREF=Vcc, was bedeutet, dass bei leerer werdender > Batterie der gemessene Strom ansteigt, der reale Strom durch den Motor > aber geringer wird. Ob es genau umgekehr proportional ist und sich somit > nahezu aufhebt, kann ich nicht sagen. Ich habe mal an drei verschiedenen Ventilen gemessen. Die Werte sind jeweils das, was Measure_Motor_Current() in der Variablen MotorCurrent ausspuckt. Der erste Wert ist der "FreeRunningCurrent", der zweite ist während des Stellvorgangs (nicht gleich nach dem Berühren des Stößels, irgendwo mittendrin), der dritte ist, wenn die Autokalibrierung abschaltet. Es sind mehrere Comet, aber alle am gleichen Heizkörper.
1 | Batterie Comet #1 Comet #2 Comet #3 |
2 | |
3 | NiMH #1 40:53:106 28:44:115 32:48:94 |
4 | NiMH #2 31:47:94 |
5 | LR6 voll 39:51:104 29:40:105 30:48:97 |
6 | 45:71:100 |
7 | LR6 leer 41:52:105 30:43:114 30:48:98 |
8 | 29:45:114 30:48:99 |
Es fällt auf, dass der gemessene Maximalstrom tatsächlich fast unabhängig von der Spannungslage ist, aber extrem exemplarabhängig. Bis auf einen Fall sind sie mehr als doppelt so hoch wie der Strom bei der normalen Ventilbetätigung. [Edit: Werte auf dezimal umgerechnet]
:
Bearbeitet durch Moderator
Was wäre denn nun ein sinnvoller Algorithmus? Adaptation() arbeitet ja offenbar so, dass der Motor bis zu einem Timeout (10 LCD frames je 64 Hz, also 156,25 ms, wenn ich das richtig sehe?) gegen den Anschlag gefahren wird. Wenn es dann keine weiteren Impulse vom Rotor gibt, wird abgeschaltet. So lange will man beim normalen Schließen des Ventils auf 0 sicher nicht vollen Strom ziehen. Eigentlich müsste es doch die sinnvollste Strategie sein, dass man versucht, den Punkt zu ermitteln, an dem der Strom nicht weiter steigt, oder? Vielleicht ja noch mit der zusätzlichen Bedingung, dass er mehr als das Doppelte von FreeMotorCurrent sein muss. Oder als Bedingung nehmen, dass die Position (durch die Lichtschranke) vorher auf 0 gezählt worden ist?
Gibt es eine Zusammenfassung wie diese Software Featuretechnisch zu den anderen Implementierungen steht? https://github.com/gnbl/sparmatic2011 sieht z.B. wesentlich aufgeräumter aus (wurde ja auch nicht erst vor kurzem von ASM nach C konvertiert), hat aber schon lange keine Aktivität mehr gesehen.
Nabend, ich hab mir als Bastelprojekt für 8 Euro einen Sparmatic Zero gekauft. Das Teil sieht aus wie dies von Conrad: https://asset.conrad.com/media10/isa/160267/c1/-/de/1091985_RB_00_FB/eurotronic-sparmatic-zero-heizkoerperthermostat-elektronisch-8-bis-28-c.jpg Ich scheitere schon daran, das Gehäuse zu öffnen. Kann mir da jemand weiterhelfen? Unter dem Batteriedeckel sind zwei Klipse, die sich aber sehr schwer bewegen. Der Rest des Gehäuses bewegt sich keinen Millimeter. Ich will das Gehäuse nicht zerstören. Martin
Martin B. schrieb: > Ich scheitere schon daran, das Gehäuse zu öffnen. Du hast vermutlich ein zugeschweißtes, oder? (Es gab auch mal geschraubte.) Mach die zugeschmolzenen Nippel vorsichtig ein bisschen warm und zieh sie dann auseinander. Die, die sich in den von unten zugänglichen Hohlräumen des Gehäusekörpers befinden, kann man leider nur (vorsichtig) abreißen.
So, das Teil ist auf. Da ist erstmal nix verschweißt. Ist alles geklippst. Sitzt halt ziemlich fest zusammen. Wenn man dann den Motor rausgenommen hat, sieht man unten die Platine liegen. Die ist dann tatsächlich mit 4 Schmelzpunkten am Gehäuse oberteil festgemacht. Wenn ich es nicht vergesse mache ich morgen mal Fotos davon
Vorsichtig weiter entnehmen, ansonsten reißt man schnell die stehend eingelötete Platine von den Pads unten ab.
Martin B. schrieb: > ich hab mir als Bastelprojekt für 8 Euro einen Sparmatic Zero gekauft. Welche Zielstellung verfolgst Du mit dem Bastelprojekt? Bei Interesse könnte ich einige Ergebnisse und Erfahrungen aus meinem Beitrag wolle g. (wolleg)30.12.2018 17:43 hier mal reinstellen.
Hallo, ich habe auch einen Eurotronic Comet mit dem geklipsten Gehäuse (wie Conny G. 04.12.2012 17:11 IMG2352.jpg). Ich habe, um mir alles anzuschauen und zu messen, die Platine von den vier Schmelzpunkten gelöst, in dem ich einfach mit dem Elektronikseitenscheider das geschmolzene über der Platine abgeknipst habe. Ich weiss jetzt leider nicht wie ich die Platine wieder fest bekomme. Ich dachte mit dem Motor drin wird genug Druck auf das Leitgummi ausgeübt das der Thermostat wieder funzt -> Fehlanzeige! Hat jemand eine Idee wie ich die Platine wieder fest bekomme ?
MitLeser schrieb: > Hat jemand eine Idee wie ich die Platine wieder fest bekomme ? Naja, sinnvoller wäre es gewesen, dass mit Heißluft etwas warm zu machen und dann hochzuziehen … zu spät. So wird wohl nur übrig bleiben, dass du die Platine anklebst. Das Gehäuse dürfte Polystyrol sein, das sollte sich gut kleben lassen.
Hallo Jörg, danke für die schnelle Antwort. Ja, Du hast recht, hätte ich besser machen können, aber meine Mittel hier zuhause sind beschränkt. Deshalb, würde Heiskleber funtionieren? Oder was empfiehlst Du?
MitLeser schrieb: > Deshalb, würde Heiskleber funtionieren? Heißkleber funktioniert ja praktisch überall. ;-) > Oder was empfiehlst Du? Ich würde wahrscheinlich erstmal gucken, ob man das mit so einem lösungsmittelbasierten Plastikkleber hinbekommt, denn der löst die Polystyrol-Pfosten ein bisschen an.
Da fängt man an und kann gleich wieder aufhören, weil wieder etwas dazwischen kommt. Was ich mir aber bisher erarbeitet habe, will ich hier hinterlegen, um nicht später einmal wieder ganz von vorn anfangen zu müssen. Den ATmega 169PA über die ISP-Schnittstelle mit dem AVRISP mkII anzusprechen hat schonmal geklappt. Dafür habe ich alllerdings eine LiIon-Zelle an die Leiterbahnen der Batteriekontakte gelötet. Die FUSES und LOCK-BITS sind im jeweiligen Screenshot zu sehen. Die entsprechenden PADs auf der Platine sind ebenfalls als Foto hochgeladen. Das Gehäuse musste an den entsprechend markierten Stellen bearbeitet werden, um den 10-Poligen Pfostenstecker lose anbringen zu können. Eine minimale Kante sollte jedoch erhalten bleiben, damit der Pfostenstecker nicht herausgezogen werden kann. Blöd ist, dass durch das Stecken und ziehen die Pinne machnmal mit wandern. Außer dem TxD-Anschluß PE1 bzw. Pin 3( UART ), haben alle anderen Adern einen 330 Ohm Widerstand bekommen. Damit die Masseleitung ( blau ) nicht am Rad scheuert sind die Pinne gekürzt und die Ader ganz nah am Gehäuse verlötet. Am besten eignet sich Flachbandkabel. 0,14qmm ist noch etwas zu steif. Weil die Platine mit verschweißten Plastikpinnen fest war, die ich weggeknippst habe, dachte mir das ich ein ca. 2mm dünnen Schaumstoff auf das Motorgehäuse klebe, was dann auf die Platine drückt, damit diese wiederum auf dass LCD-Leitgummi drückt. Bernd_Stein
Bernd S. schrieb: > Weil die Platine mit verschweißten Plastikpinnen fest war, die ich > weggeknippst habe, dachte mir das ich ein ca. 2mm dünnen Schaumstoff auf > das Motorgehäuse klebe, was dann auf die Platine drückt, damit diese > wiederum auf dass LCD-Leitgummi drückt. > So, nun wollte ich den Thermostaten ( TS ) wieder zusammenbauen und einmal gucken, ob er auch noch funktioniert. Erste Problem war natürlich wirklich die Displayanzeige. Zu Anfang waren kurz ein paar Striche zu sehen und dann nichts mehr. Musste tatsächlich die Schaumstoffdicke erhöhen und bin auch auf die schmale Seite gegangen, weil man hier näher zum Leitgummi ist. Man muss dabei darauf achten, dass das Zahnradfenster komplett frei bleibt. Ein guter Indikator für die richtige Dicke ist, dass sich das Fenster nicht eindrücken lässt, wenn man auf dass Motorgehäuse drückt. Ein Plektrum mit 1.14mm Dicke war sehr hilfreich, weil ich öfters das Gehäuse öffnen musste um mit der Schaumstoffdicke herum zu experimentieren. Es muss also nach dem einsetzen der Batterien, im Display eine Jahreszahl blinken ( 2010 ) und der Motor hat bei mir gedreht. Nach einstellen von Datum und Uhrzeit erscheint dann die Anzeige INST, was wohl für Installation steht. Also den TS angebaut und auf OK gedrückt, danach erscheint ADAP für die Adaptionsfahrt und die LED leuchtet wenn aufgeheizt wird. Bernd_Stein
:
Bearbeitet durch User
Hallo zusammen, weiß jemand zufällig was die Meldung FSLH zu bedeuten hat ? Könnte Flash bedeuten, aber was fange ich damit an ? In der Bedienungsanleitung steht nichts drinn und Tante G. weiß auch nichts. Nachdem ich die Akkus entnommen habe und einfach wieder eingesteckt, war die Meldung weg und alles so wie es sein soll ( siehe vorheriges Posting ). Die LCD-Anzeige ist in Ordung, alle Buchstaben waren beim Einstellen eindeutig wie in der Bedienugsanleitung beschrieben. Bernd_Stein
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.