Übrigens gibt es am nächsten Mittwoch bzw. Donnerstag (je nach Bundesland und Feiertag) bei Aldi-Nord wieder Thermostate: http://www.aldi-nord.de/aldi_ab_mittwoch_3110_48_5_1051_16826.html Gehe ich recht in der Annahme, daß es sich hierbei um eine Sparmatic-Variante handelt, deren Firmware ersetzt werden kann?
Meiner sieht genauso aus. Und bei diesem scheint es zu gehen. Ich habe es aber nicht probiert, habe keine Zeit. Gruss Robert
Rufus Τ. Firefly schrieb: > Gehe ich recht in der Annahme, daß es sich hierbei um eine > Sparmatic-Variante handelt, deren Firmware ersetzt werden kann? Ja, sieht gut aus :-)
Nur mal ein kurzer subjektiver Vergleich Thermy/Comet: Ehrlich gesagt gefällt mir die ALDI(Sued) Thermy-Variante nicht ganz so gut wie Comets (Praktiker). Die drei Tasten sind "nur" Plastik-Lippen. Sie haben kaum Druckpunkt und ich finde sie sehr schwamig. Bei den Comets sind das noch aufgelegte Plastik-Elemente mit schönem Druckpunkt.. Auch finde ich das Rädchen extrem schwammig, die Rasterungen werden fast schon nicht mehr getroffen. Bei den Comets war das gerade noch so ok. Wenn das offengelegte SMD-Bauteil unter dem Thermy-Schriftzug allerdings der Temperatur-Sensor ist, ist das wiederum nett. Dann wär der Sensor "halbwegs" rausgeführt. (Kann es sein, dass die Thermys die Uhrzeit bei entfernen der Baterien nicht abspeichert?) Gruss, Max.
Ahrgh, sorry, ich hab nur mit dem 2011-comet verglichen. Aber zumindest das mit den Tasten dürfte trotzdem zutreffen (Themry vs. Comet-2012), Rädchen schaut gleich aus. Gruss, Max
Hallo zusammen, ich habe mir Ende letzten Jahres auch ein THERMy bei Aldi gekauft. Der sollte zwar erstmal nur Reserve sein, aber als ich dieses bzw. die vielen Projekte (in Sachen Thermostat) gefunden habe bin ich hell auf begeistert. Zum Glück habe ich schon hin und wieder mit nem ATmega experementiert. Nur leider kenne ich mich mit diesem GIT dingen überhaupt nicht aus ... Knut, kannst Du nicht mal kurz schreiben wie ich da ne schöne Firmware für den kleinen THERMy raus bekomme? Danke & Gruß Michael R.
>ich habe mir gerade bein Lidl einen neuen Regler gekauft, der sah so aus >wie ein Comet V2, inndn drin ist aberdas anhängende. >Hat jemand weitere Informationen insbesonders die verwendete CPU?? >Einen Programmierstecker finde ich auch nicht. Falls es noch jemand interessiert, die CPU ist eine 8bit von Samsung. Ich habe leztes Jahr mal recherchiert, könnte bei Bedarf nachschauen, wie die "genaue" Bezeichnung war. andy
@Michael: GitHub ist lediglich ein Online-Speicheranbieter. Wenn Du auf die weiter oben verlinkte Adresse klickst (https://github.com/wjroes/OpenZero), öffnet sich eine Seite mit einem Ordner und einem Textfile. In dem Ordner befindet sich ein komplettes C-Projekt des holländischen Programmierkollegen. Darüber gibt es einen Button, auf dem ZIP steht. Damit kannst Du das Projekt herunterladen und auf Deine Platte packen. Dann lädst Dir das aktuelle ATMEL-STUDIO und öffnest dieses Projekt. Soweit ich weiß, ist das Projekt gut dokumentiert, aber noch nicht vollständig.
Recht schönen Dank Knut (gut das Du auch hier immer wieder mal reinsiehst)! Viel einfacher geht es ja schon bald garnicht mehr. Ich werde meinen Erfolg (so er sich dann einstellen sollte) hier posten! Gruß Michael
Alles klar, ich glaube Willem liest auch hin und wieder mal mit. Wenn ich in Zukunft ganz viel Zeit habe, werde ich mich auch noch mal ausgiebig mit den Teilen beschäftigen, nachdem mich die alten Zeros nicht so sehr überzeugt haben, so rein von den Möglichkeiten der Hardware...
... gestern (28.1.'13) gabs die wieder beim Aldi Süd - da sind bestimmt noch einige über ... Kosten: 14.95€
Hallo, ich habe folgendes problem, ich habe beim thermy den drehimpulsgeber durch einen atmega ersetzt. ich mochte die temperatur manuell per µC einstellen. ich habe bemerkt das der thermy ca. alle 20-30 sec. irgendwas macht und ein bis drei drehgeberimpulse nicht mitbekommt und dadurch nicht correct mitzählt. wenn ich jetzt ausgerechnet in dieser zeit die temperatur einstelle funzt das nicht correct und ich habe ein halbes oder ganzes °C zu wenig oder zu viel. hat sich da schonmal jemand mit befasst? Gruß... Hannes
Hannes K. schrieb: > Hallo, ich habe folgendes problem, ich habe beim thermy den > drehimpulsgeber durch einen atmega ersetzt. Aha. Hannes K. schrieb: > ich mochte die temperatur > manuell per µC einstellen. Hmm, das kann der interne Controller aber auch blendend leisten. Hannes K. schrieb: > ich habe bemerkt das der thermy ca. alle > 20-30 sec. irgendwas macht Der macht sogar noch öfter ´was. Ich würde sagen 1x pro Sekunde mindestens. Hannes K. schrieb: > und ein bis drei drehgeberimpulse nicht > mitbekommt und dadurch nicht correct mitzählt. Das kann nur passieren, wenn die von Dir generierten Pulse zu kurz sind oder sich nicht an den Gray-Code halten. Pulse kürzer als 10ms wird die Firmware als Preller verwerfen. Mach also die Pulse langsamer.
Hallo Knut, ich habe die Pulsdauer momentan bei 60ms stehen, der code läuft einwandfrei vor und rückwärts. Bei 10ms schnell und 200ms langsam wird es kriminell und Thermy zählt nicht mehr richtig. Mein Problem ist das Thermy ab und zu einen Puls nicht mitzählt und ich nicht immer sicher sein kann das die gewünschte Temperatur eingestellt wurde. Wenn ich irgendwie feststellen könnte wann genau Thermy keine Drehimpulsgeber eingaben zulässt könnte ich meine Temperatur davor oder danach einstellen. Es kommt ca. alle 20-30sec. dazu das man für ca. 100ms keine Eingabe machen kann. Grüße... Hannes
Hannes K. schrieb: > Bei 10ms schnell und 200ms langsam > wird es kriminell und Thermy zählt nicht mehr richtig. Bei zu schnell, ist verständlich, aber zu langsam kommt mir komisch vor. Es ist natürlich so, dass der 2. Puls für den 2. Kontakt nicht ewig nach dem ersten kommen darf. Wenn Du Deinen Generator aber symmetrisch aufgebaut hast (Puls 1 - 50% Zeit - Puls2 50% Zeit), dann könnte das schon sein, dass die Drehrad-Entprell-Routine das nicht mehr entziffern kann. Dies bezieht sich auf die Originalfirmware. Meiner eigenen Routine ist das wurscht, die kann nur zu schnelle Impulse nicht werten, bzw. verwirft diese als Prellen. Das kommt bei normaler Bedienung aber nicht vor. Was ich mir auch vorstellen kann ist, dass die Originalfirmware nach dem letzten Drehen eine Zeit lang wartet und dann in einen tieferen Schlafmodus fällt, der erst wieder durch das tippen auf Tasten oder das Drehen am Rad zum Aufwachen des Controllers führt. Dann verliert die Firmware einige Klicks, bevor der Controller wieder rennt.
Das mit dem aufwachen habe ich auch berücksichtigt. Wenn ich zb. eine dauerrutine ausführe kann man den Effekt gut beobachten. Ich lasse Thermy zb. ununterbrochen 10 grad hoch und wieder runterlaufen dann kommt es nach einer Zeit immer wieder zu diesen Aussetzern also das ein einziger Schritt ausgelassen wird. Das passiert so alle 20 bis 30 sec. Grüße... Hannes
Hm, dann wäre es vielleicht besser, die originale Firmware durch etwas Funktionierendes zu ersetzen. Kannst Du den Effekt auch an einem unmodifizierten Regler mittels des Drehrades nachweisen? Falls ja, ist in der Firmware ein Stück Code, welches den "normalen" Programmablauf blockiert. Da die Temperaturberechnung ziemlich zeitaufwändig ist, könnte diese die Aussetzer hervorrufen. Man kann diese Berechnung aber auch so programmieren, dass Zeitgeber und Interrupte lässig weiterlaufen und es zu keinem Verhungern von Takten kommt. Das kann ja dann auch bei der Lichtschranke passieren und dann werden Ventilpositionen "verpennt".
Ich kann dieses Effekt an einem unverändertem Thermy auch nachweisen, wenn man das Rad dreht, geht in einer bestimmten Geschwindigkeit die Temeratur um 0.5¬ hoch oder runter. Dreht man schneller, geht das nicht mehr regelmässig, bei reduzierter Drehgeschwindigkeit tritt dieser Effekt auch ein. Gruss Robert
Ich werde das Problem morgen näher untersuchen es ist aber definitiv so das bei gleichbleibender Tastgeschwindigkeit ca. alle halbe Minute die Eingabe nicht aktiv ist und wenn man diesen Moment durch Zufall erwischt geht einem ein Schritt verloren. Vielen Dank für die Anregungen werde mich morgen wieder melden. Einen Schönen Abend vorerst. Grüße... Hannes
Hallo, heute habe ich den Thermy immer einen Schritt hoch und wieder runter laufen lassen, kontinuierlich bei 20ms. Ich habe festgestellt das dabei die Temperatur in unregelmäßigen Abständen von 2-20sec. immer ein halbes grad hochwandert. Ich bin daher davon ausgegangen der nur das down stellen ab und zu einen Schritt nicht erfasst wenn der Thermy was zu tun hat. Ich habe darauf hin den Thermy kontinuierlich mit 96 Downschritten auf Aus laufen lassen(96 damit er sicher bis auf Aus läuft auch wenn einige Schritte nicht gezählt werden) und dann wieder mit 80 Schritten Up laufen lassen sodas er auf 27,5 Grad stehen bleibt. Das hat zu 100% funktioniert und es ging nicht ein einziger Schritt beim Up zählen verloren. Ich habe das mehrere hundert mal laufen lassen und es funktionierte einwandfrei. Fazit: Beim Downstellen nimmt Thermy nicht immer alle Schritte an aber dafür werden alle Schritte beim Upzählen einwandfrei gezählt. Ich kann Thermy nun mit 96 Downschritten sicher bis auf Aus stellen, auch wenn dabei bis 4 Schritte verschluckt werden also von voll An bis Aus. Anschließend steppe ich dann hoch auf meine gewünschte Temperatur. Funzt einwandfrei :-) Damit ist mein Problem gelöst. Grüße... Hannes
Hannes K. schrieb: > Damit ist mein Problem gelöst. Naja - es umgeht einen Fehler und führt für Dich zum gewünschten Ergebnis.
Hallo Forengemeinde, aufgrund des im Norden unseres Landes ziemlich miesen Wetters habe ich an der Firmware weitergeschrieben. Wer sie ausprobieren möchte, findet das komplette Projekt angehängt. Es ist in ASM erstellt und mit ATMEL-Studio 6.0 und 6.1 kompatibel. Features: - Echtzeit und Ist-Temperatur-Anzeige im Normalmodus - Ähnliche Menüführung wie in der Original-Firmware - Menüpunkte PROG, TEMP, ZEIT, ADAP vollständig implementiert - Fuzzy-Regelalgorithmus - max. 4 Warm/Kalt-Zyklen pro Tag + 1 Nachtabsenkung (3. Temperaturwert) - vernünftig entprellte Tasten - funktionierendes Drehrad ToDo: - Fenster-Offen-Erkennung - Batteriemessung - Urlaubsfunktion - Werksresetfunktion - Offset-Funktion - Bugfixes - Umsetzung von Erweiterungen (Funk, externe Fühler) - vernünftige Code-Kommentierung Da es eine Betaversion ist, sind Bug möglich und wahrscheinlich. Ich würde mich über Anregungen und Kritik freuen. TravelRec.
Noch vergessen: - Batterieentnahme-Erkennung - Speichern der 3 Einstelltemperaturen im EEPROM TravelRec. P.S. Benutzung der Firmware und Flashen des Controllers auf eigene Gefahr! Keine Haftung für etwaige Schäden durch nicht erwartungsgemäß funktionierende Heizungsregler!
Neue Programmversion: Hinzugefügt: - Batterie-Leer-Anzeige - abschalten des Reglers und speichern der Uhrzeit bei erschöpfter Batterie BugFix: - Bargraph wurde bei Tageswechsel nicht aktualisiert
Neue Programmversion V005: Hinzugefügt: -Auto/Manuell Modus: Im Auto-Modus werden die Timer abgefragt und die Einstelltemperaturen aktualisiert. Es wird ein Bargraph und die entsprechenden Symbole für das aktuelle Temperaturintervall angezeigt. Im Manuell-Modus werden die Timer nicht abgefragt. Die aktuelle Einstelltemperatur bleibt bis zur manuellen Änderung bestehen. Es werden kein Bargraph und keine Temperaturintervall-Symbole angezeigt. Änderung: - kleinere Bugfixes
Ich hatte gerade wieder eine Idee. Gibs noch pins für nen 2 fühler? Evtl sogar was für 2wire? Dann könnte man über 2 fühler den vor und rücklauf messen um damit auf die raumtemperatur zu schliessen. Möglich? Ich denke hier an meine fussbodenheizung ;) Gruss Jörg
Jörg Esser schrieb: > Ich hatte gerade wieder eine Idee. Gibs noch pins für nen 2 fühler? Evtl > sogar was für 2wire? Grundsätzlich hast Du 2 Möglichkeiten: 1. Am JTAG-Header laufen 4 analoge/digitale I/Os und Betriebsspannung auf. Diese könnte man mittels Widerstand und NTC oder mit 2 Widerständen für Soft-I2C und entsprechend langer Leitung auf einen 2. Fühler umrüsten. Nachteil: Gehäuse öffnen und danach wieder irgendwie verschließen. Die Schweißpunkte müssen entfernt und durch eine andere mechanische Fixierung ersetzt werden. Oder man muss kleben und kommt später nicht mehr ´ran. 2. Du nutzt die USB-Buchse. Dort stehen 3 digitale I/Os und Betriebsspannung zur Verfügung. Daran kann man einen digitalen Fühler oder einen kleinen Controller mit analogem Fühler anschließen. Kommunikation wahlweise über SPI (ohne /CS) oder I2C...
BTW: Im Praktiker-Onlineshop gibt es die Comet-Regler derweil für 12.99€ plus Versand. Falls noch jemand günstig sein Haus ausrüsten möchte, bevor der Frühling Ernst macht... ;-)
Programmupdate: Hinzugefügt: - automatische Kalkschutzfahrt Freitags 11:00 Uhr Änderung: - Interruptfrequenz Soundausgabe (Motor-Buzzer) angepasst - fehlerhafte I/O-Registernutzung beseitigt - kleinere Bugfixes
Programmupdate: Bugfix: - manuelle Temperatureinstellung im Automatikmodus wurde nach bereits 1 Minute von Timereinstellungen überschrieben - bei der Timerprogrammierung wurden teilweise falsche Symbole angezeigt
Programmupdate: Hinzugefügt: - Haus-/Mond-Symbole sind im Automatikmodus stetig eingeschaltet, wenn die betreffende Heizzeit läuft und die Einstelltemperatur der programmierten Temperatur entspricht. Die Symbole blinken, wenn die Einstelltemperatur manuell verändert wurde, das heißt, von der programmierten Temperatur abweicht. Sie sind wieder dauerhaft eingeschaltet, wenn die Einstelltemperatur auf den programmierten Wert zurückgedreht wurde oder eine neue Heizzeit erreicht ist. - kleinere Optimierungen
Noch ein Hinweis: Die aktuell verkauften Sparmatic-Comet enthalten außer dem Aufdruck "comet" auch anstelle des älteren ATMEGA169PV den neueren ATMEGA169PA. Der neuere Controller hat einige Bits in einigen I/O-Registern verändert (siehe Migration-Note AVR529). Dies merkt man beispielsweise daran, dass nach dem Auffahren nach Einlegen der Batterien die OK-Taste nicht funktioniert, um das Ventil zu adaptieren. Hier muss das Projekt auf den ATMEGA169PA als Device im ATMEL-Studio umgestellt und neu assembliert werden. Dadurch werden die betreffenden Bits an die richtige Stelle geschoben. Danach flasht man die neue *.hex. BTW: Ziemlich wenige Wortmeldungen hier...
Angehängte Dateien:
-
Thermy_v2_Aldi.gif
810 KB
Knut Ballhause schrieb: > Die aktuell verkauften Sparmatic-Comet enthalten außer dem Aufdruck > "comet" auch anstelle des älteren ATMEGA169PV den neueren ATMEGA169PA. Ja, der ist auch in meinem Gerät vom Aldi drin. Ich muss mich jetzt noch überwinden und mein mini-USB-Kabel zerschneiden um das Gerät programmieren zu können. Mein Gerät (die Platine) sieht so aus wie im Anhang. Es ist ein Gif-Bild, damit kann man die Leiterzüge gut verfolgen ohne dass man das Ding immer umdrehen muss. Das mit der Größe tut mir Leid, aber kleiner haben ich es nicht hinbekommen.
Hans Jelt schrieb: > Es ist ein Gif-Bild Blink blink.. ;-) Hans Jelt schrieb: > Mein Gerät (die Platine) sieht so aus wie im Anhang. Bislang waren ALDI Thermy und Comet 100% kompatibel, sollte mich wundern, wenn sich das geändert hätte.
Es gibt eine Anpassung meiner bisherigen Firmware zur Verwendung an Mischventilen. Dies ist eine Testversion. Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Knut Ballhause schrieb: > anbei der überarbeitete Plan. Im Grunde habe ich die Daten von Leopold > B. benutzt, überprüft und mit Werten versehen. Ausserdem habe ich > versucht, das Ganze modular und übersichtlich anzuordnen. Dies ist wirklich ein sehr übersichtlicher Plan und er passt zu meinem Thermy V2 (Variante mit losen Tasten im Gehäuse, und mit der dämlichen eingelöteten Reflexlichtschrankenplatine.) Inzwischen gibt es aber seit einigen Jahren auch den Thermy V3 (passt zu dem Bild in 'Sparmatic_Heizungsthermostate', mit den Plastik-Zungen-Tasten und der weißen Platine ) Dieser V3 hat einen leicht geänderten Schaltplan im Bereich PORTF und PORTE. Ich würde diesen Schaltplan gerne hier einstellen, am besten ausgehend von dem V2-Plan. Dazu wäre es ganz nett wenn ich das Original des V2 im eagle- oder kicad -Format hätte, ich will nur ungern nur das png-file manipulieren. Kann mir irgend jemand den Schaltplan des V2 in einem original-Format zur Verfügung stellen? Geht das eventuell hier im Forum als Datei? Vielen Dank
Bitteschön.
Sorry, aber ich kann die Daten nicht lesen, nutze Eagle 4.16.
Angehängte Dateien:
-
ThermyV3-sch.png
70 KB
Thomas Husterer schrieb: > Danke, ThermyV3-Version zurück. Hier ist ein png-Bild von der Schaltung.
Hi, habe gerade mit Freude die Threads zu den Sparmatic entdeckt, die Heizkörper zentral und per Funk zu regeln steht auf meiner Long Term Projektliste. Hat denn schon jemand einen Platinchenentwurfmund ein Funkprotokoll fertig? Wäre mir beim Quickscan dieser Diskussion nicht aufgefallen, nur einen ersten Entwurf gab es oben, der sah aber noch unfertig aus. Viele Grüße, Conny
Geht es hier noch weiter, noch jemand dran? Vg,, Conny
Conny G. schrieb: > Geht es hier noch weiter, noch jemand dran? Guckst Du: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Hallo, letzte Woche gab es hier beim Aldi "Thermies". Weil es hier schon so viele freundlicherweise offengelegte Projekte und Informationen gibt, habe ich einige gekauft um damit so ähnlich wie Jörg Esser eine Fussbodenheizung zu steuern. Mit der Originalfirmware kann ich das nicht machen, weil die Fenster-Offen-Erkennung dazwischenfunkt, von daher bin ich ganz froh das es das hier alles gibt. Leider tut's weder die Firmware von Knut ( diese Version: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" ) noch die von https://github.com/gnbl/sparmatic2011: Bei beiden klappt die Adaptierfahrt nicht, es gibt nur einen ganz kurzen Ruck. Bei der 'sparmatic2011'-Firmware scheint es daran zu liegen, dass das Signal von der Reflexlichtschranke nicht ankommt und das System meint, der Motor bewege sich nicht. Mit der 'sparmatic2011' funktionieren auch die Tasten nicht, mit Knuts Software gehen die Tasten. Das Innenleben entspricht soweit ich das sehen konnte der "Thermy V3" wie hier beschrieben, allerdings steht bei mir eine "13" neben den JTAG-Pads, keine "12" wie auf dem Foto hier. Hat jemand eine Idee was da los sein könnte ? Ich habe schon die entsprechenden Stellen im ThermyV3-Schaltplan mit meiner Platine verglichen, kann da aber keine Unterschiede sehen. Fotos könnte ich ggf. einstellen. Die Fuses habe ich für beide Firmwares nach Knuts Angaben gesetzt (FF-D1-62).
Mathias K. schrieb: > Hat jemand eine Idee was da los sein könnte ? Ja, da wird ein ATMEGA169PA drin sein. Die Firmwares sind für einen ATMEGA169P kompiliert und dieser hat andere Interruptflagpositionen. Grob gesagt. BTW: Es sind nur die Firmwares für den Comet kompatibel, nicht die für den 2011er Zero! Also nur die hex-Dateien aus DIESEM Thread!
:
Bearbeitet durch User
Mathias K. schrieb: > Das Innenleben entspricht soweit ich das sehen konnte der "Thermy V3" > wie hier beschrieben, allerdings steht bei mir eine "13" neben den > JTAG-Pads, keine "12" wie auf dem Foto hier. Hallo Mathias, ich kann deine Beobachtung bestätigen, das Innenleben ist augenscheinlich identisch und bei mir verhält sich die aktuelle Thermy-Version auch genau so wie der Vorgänger "V3". (Lediglich die V2 hat eine leicht veränderte Pin-Belegung) Gruss thus
Guten Abend, @Knuth: ich hatte die Datei "Sparmatic_Comet_M169PA.hex" mit der 50Grad-Regelbereichserweiterung verwendet, das war es glaube ich nicht. Mit einem Hexfile aus diesem Thread geht's leider auch nicht. Die Sparmatic2011-Firmware tut's wohl deshalb nicht, weil die Pullups von Port B nirgendwo eingeschaltet werden, was aber IMHO nach dem Schaltplan zum Tastenlesen nötig wäre. Die Reflexlichtschranke wird an PE1 gelesen, was auch nicht zum v3-Schaltplan passt. Ich werd versuchen das anzupassen. Vielen Dank für Eure Antworten! Gruss Mathias
Ach ja, die Thermys - jetzt sehe ich die Unterschiede in der Beschaltung auch - gut, das kann nicht gehen... Warum ändern die denn die Beschaltung...?! Der Widerstand für die Batterie-Entnahme-Erkennung ist auch von E0 nach E5 gewandert... Falls jemand aktuelle Sourcen haben will, bitte eine PN schicken. Da ich keinen ThermyV2 habe (mann sehen die Dinger hässlich aus, hatte heute einen in der Hand), will ich das Programm auch nicht unbedingt modifizieren. Vielleicht wird es irgendwann mal Defines dafür geben...
:
Bearbeitet durch User
Mathias K. schrieb: > Die Sparmatic2011-Firmware tut's wohl deshalb nicht, weil die Pullups > von Port B nirgendwo eingeschaltet werden, was aber IMHO nach dem > Schaltplan zum Tastenlesen nötig wäre. Die Reflexlichtschranke wird an > PE1 gelesen, was auch nicht zum v3-Schaltplan passt. Ich werd versuchen > das anzupassen. Welches Layout hast Du denn jetzt genau? Lichtschranke an PE1 oder an PE3? Ich bin verwirrt.
:
Bearbeitet durch User
Sparmatic2011 hat, glaube ich, noch keine richtige Regelung, ich habe seit damals nicht weiter daran gearbeitet. Bitte neue Informationen ins Wiki schreiben, da habe ich damals auch ein paar Stunden investiert..
Ich selbst schrieb: >> Die Sparmatic2011-Firmware tut's wohl deshalb nicht, weil die Pullups >> von Port B nirgendwo eingeschaltet werden, was aber IMHO nach dem >> Schaltplan zum Tastenlesen nötig wäre. Stimmt nicht, die Pullups sind an, habe ein #define übersehen, Asche über mein Haupt. Wenn ich im Interrupthandler PCINT1_vect den Aufruf "keyPeriodicScan();" hinzufüge, funktionieren die Tasten. @gnbl: Wenn ich etwas Stabiles habe oder die Lust verliere, schicke ich Dir einen Patch. Dass es noch keine richtige Regelung gibt ist mit der Fussbodenheizung kein Problem, die heizt auch 2-Punkt-geregelt akzeptabel. Im Gegensatz zu den Thermies brauchen die normalen Stell"motoren" aber Dauerstrom um die Ventile offen zu halten. Wenn man die Heizanlage in die Nachtabsenkung schickt, wollen die Ventile natürlich alle aufmachen weil die Raumthermostatschalter nichts von Nachtabsenkung wissen. Diese Stromverschwendung abzustellen ist mal mein erstes Ziel, dann evtl. auch die Pumpe (100W, angeblich geht in dieser Anlage keine andere) im Mischerkreis auszuschalten wenn alle Ventile zu sind. Ich stelle mir vor, in den Thermies den NTC durch den Fototransistor eines Optokopplers zu ersetzen und die Raumthermostaten die LED schalten zu lassen. (Optokoppler wegen der Einstreuungen, die Kabel zwischen Thermostat und Stellmotoren sind lang, nicht wirklich verdrillt und liegen überall parallel zum 230V-Netz. Auf einer unbenutzen Ader habe ich neulich hochohmig 78V gemessen. ) >> Die Reflexlichtschranke wird an >> PE1 gelesen, was auch nicht zum v3-Schaltplan passt. Ich werd versuchen >> das anzupassen. > > Welches Layout hast Du denn jetzt genau? Lichtschranke an PE1 oder an > PE3? Ich bin verwirrt. Bisher hat für mich der ThermyV3-Schaltplan (weiss lackierte Platine) gepasst. Ich glaube daher dass der Fototransistor an PE3 ist. Ich habe mir den Motoranschluss extern herausgeführt. Morgen abend werde ich mal testen welches Port-E-Bit wackelt, wenn ich den Motor per Netzteil fahren lasse. Ciao Mathias
Mathias K. schrieb: > dann evtl. auch die Pumpe (100W, angeblich geht in dieser > Anlage keine andere) im Mischerkreis auszuschalten wenn alle Ventile zu > sind. Das wurde uns auch gesagt. Seitdem wir entgegen dem Rat eine Grundfos Alpha2 eingebaut haben, ist der Stromverbrauch der Heizung um 70% gesunken und die Anlage läuft immer noch einwandfrei (und nachts auch schön ruhig). Hier hilft wohl nur der Rat eines echten Fachmanns oder einfach das Probieren. Mathias K. schrieb: > Ich stelle mir vor, in den Thermies den NTC durch den Fototransistor > eines Optokopplers zu ersetzen Musst Du nicht. Nimm einfach einen Pin und Masse der USB-Buchse. Ist viel einfacher und erfordert keinen Umbau im Gerät. Brauchst Du die Funktion dann mal nicht mehr, brauchst Du nur den Stecker zu ziehen.
Hallo gnbl, inzwischen funktioniert bei mir die Adaptierfahrt mit sparmatic2011 und Thermy V3 und ich hänge den versprochenen Patch an. Man muss auch ein paar Sachen am Makefile ändern, daher wird die Sache wohl nicht ohne weiteres für beide Hardwareversionen gehen. gnbl schrieb: > Bitte neue Informationen ins Wiki schreiben, da habe ich damals auch ein > paar Stunden investiert.. Dem was dort schon alles zu der V3-Hardware steht, habe ich im Moment nichts hinzuzufügen. Gruss Mathias
Hallo rmrf, ich kann nicht versprechen, dass ich den Patch irgendwann integriere, da ich momentan nichts mit den Thermys mache (obwohl zunehmend Bedarf bestuende..). Aber wenn ich wieder dran bin sehe ich es mir natuerlich an. Ansonsten steht es ja jedem frei den Patch anzuwenden oder das repository auf github zu klonen und dort den Patch einzubauen. In jedem Fall danke fuer den feed-back.
Moin, Kälter wirds, daher bastle ich auch an dem Thermy V3 herum. In den Zeichnungen ist für den NTC immer nur 100k@25°C erwähnt - kennt jemand der Thermy-Erfahrenen den Temperaturkoeffizienten? Danke sehr!
Moin, Ich habe mir die Frage mal versucht, selbst herzuleiten. Das ganze basiert auf einer Demo von Torsten F. (Beitrag "Re: Preisgünstiger Heizungsregler bei Praktiker"), der in BASCOM einige ADC-Werte und die korrespondierenden Temperaturen hinterlegt hat. Ich weiß nicht woher diese stammen, aber die Infos unten sind nur so gut wie diese Zahlen. Darin findet sich folgender Code:
1 | 'Config für Temperatursensor |
2 | Config Adc = Single , Prescaler = Auto , Reference = Avcc |
3 | Config Portf.2 = Output |
4 | Dim Ist_temperatur As Single |
5 | Dim Adc_temp(10) As Word |
6 | Adc_temp(1) = 757 '0°C |
7 | Adc_temp(2) = 703 '5°C |
8 | Adc_temp(3) = 645 '10°C |
9 | Adc_temp(4) = 585 '15°C |
10 | Adc_temp(5) = 525 '20°C |
11 | Adc_temp(6) = 465 '25°C |
12 | Adc_temp(7) = 409 '30°C |
13 | Adc_temp(8) = 356 '35°C |
14 | Adc_temp(9) = 308 '40°C |
15 | Adc_temp(10) = 266 '45°C |
Lt. Schaltbild für den Thermy V3 (https://www.mikrocontroller.net/articles/Datei:THERMYV3-sch.jpg) liegt der NTC in Reihe mit einem 120k-Festwiderstand, gespeist wird die Schaltung mit VCC. Da hinter dem NTC mittels AD-Wandler abgegriffen wird, müsste der AD-Wandler bei 25°C einen Wert von
messen. Der ADC des ATMega hat eine Aulösung von 10bit=1023 Stufen, daher passt der dort theoretisch zu messende Wert:
gut mit dem oben für 25°C angegebenen überein. Für die verschiedenen Temperaturen ergibt sich dadurch: T[°C] ADC[Stufen] R_NTC[kOhm] 0 757 341.5 5 703 263.63 10 645 204.76 15 585 160.27 20 525 126.51 25 465 100 30 409 79.93 35 356 64.05 40 308 51.69 45 266 42.17 Durch Regression lässt sich eine Zuordnungsvorschrift aufstellen: - genau, durch die B-Parameter-Gleichung nach (http://en.wikipedia.org/wiki/Thermistor#B_or_.CE.B2_parameter_equation). [<math]R=R_0e^{B(\frac{1}{T} - \frac{1}{T_0})}[/math] Mit R0=100k und T0=293.15K ergibt sich für B ein Wert von 4010 mit sehr gutem Fit (R-Square/Adj R-Square=0.9999). In die Gleichung muss die temperatur in K eingesetzt werden. Die wollen wir aber bestimmen, daher noch schnell umstellen:
- einfach: Für uC ist eine Exponentiation vielleicht nicht das Einfachste, daher kann das Verhältnis versuchsweise auch linear approximiert werden.
Es ergibt sich P1= -0.1448 °C/kOhm und p2 = 43.27°C. Der fit ist jedoch extrem ungenau, (R-square: 0.9036, Adjusted R-square: 0.8915), die maximale Abweichung zwischen Kurve und Messwerten beträgt über 7.8°C bei den untersten Werten. - Kompromiss: Ein Polynom 2. Ordnung
liefert: - p1 = 0.0005176 °C/kOhm^2 - p2 = -0.3345 °C/kOhm p3 = 55.24 °C mit R-square: 0.987 Adjusted R-square: 0.9833 Die maximale Abweichung ist nur noch 3°C bei 0°C. Eventuell ist das gerechtfertigt, da der Widerstand sowieso an der Heizung direkt sitzt... Ein Polynom 3. Ordnung:
liefert:
p1 = -2.469e-06 °C/kOhm^3
p2 = 0.001915 °C/kOhm^2
p3 = -0.5541 °C/kOhm
p4 = 64.05 °C/kOhm
R-square: 0.9981
Adjusted R-square: 0.9971, die Maximale Abweichung ist nur noch 1°C im
betrachteten Bereich.
Habe die Regression gerade noch mal mit ADC und Temperatur durchgeführt: - B-Parameter:
- A = 264.2
B = 4616, R-square: 1
Adjusted R-square: 1
Aber blöd umzustellen und für uC sowieso zu kompliziert...
- Da wir R_NTC/R_NTC+x in die Gleichung einfließen haben macht sich hier
nämlich ein lineares Modell sehr gut:
- linear:p1 = -0.08933 °C/step p2 = 67.33 °C T in °C, ADC=[0...1023] R-square: 0.998 Adjusted R-square: 0.9977 maximales Residuum im betrachteten Bereich von 1.5°C, was für die meisten Zwecke mehr als ausreichend sein sollte, und ist außerdem schön einfach.
N'abend. Hab mir nen ISP USB Stecker gefeilt und versuche meinen Cometen per ISP anzusprechen und komme da nicht weiter. ISP Programmer ist der hier im Forum ganz gut bewertete Mysmartusb light: http://shop.myavr.de/index.php?sp=article.sp.php&artID=200006 Er läuft im STK500v2 Modus und ich hab ihn auf 3V eingestellt. Das zugehörige Flashtool erkennt den Controller nicht und wenn ich manuell Atmega169 einstelle, kommt ein Timeout wenn ich versuche, den Flash auszulesen. Ich hab's dann mit AVRDUDE 6.0.1 probiert: avrdude.exe -P COM14 -c stk500 v2 -p m169 -vv Der bringt mir keine vernünftige Device-ID. Entweder 0x000000 oder 0xffffff. Den Takt mit -B 50 reduzieren hilft nix. Die 5 USB-Pins sind korrekt mit dem ISP-Adapter verbunden, das hab ich mehrfach überprüft und durchgemessen. Dabei habe ich Pin 2 -> SCK und Pin 4 -> MISO verbunden sowie GND und VCC nachgemessen um sicherzustellen, dass ich die USB-Pins nicht falschrum interpretiere. Und wenn Reset absichtlich nicht verbunden ist, dann meldet AVRDUDE "initialization failed" und bringt gar nicht erst die falsche Device-ID, deshalb gehe ich davon aus, dass ich das Reset-Pad richtig getroffen habe. Ich hab dann das ganze auch mit eingelegten Batterien versucht. Dort resettet sich der Comet jedes Mal, wenn man versucht, den Flash auszulesen. Aber klappen tut's trotzdem nicht und AVRDUDE . SCK und MISO tauschen hilft auch nicht. Hätte nicht gedacht, dass das so kompliziert ist.... :(
Nachtrag: mit nem original AVRISP MKII klappts auch nicht - kann Device ID im AVR Studio (6.1) nicht auslesen.... Target Voltage wird erkannt (2.5V) Mit AVRDUDE geht's auch nicht. Hab dann mal mit nen Logic Analyzer das Auslesen mitgeschnitten (Trigger auf Reset 1->0). Sieht für mich als µC-Anfänger erstmal unverdächtig aus: http://up.picr.de/16561262sw.png Wenn jemand nen Tipp hat nur her damit!
Andreas K. schrieb: > Target Voltage wird > erkannt (2.5V) Setze mal neue Batterien ein. Wenn die Spannung zu niedrig ist funktioniert das ganze nicht.
Moin, Bin gerade bei dem Motor angelangt, wenn ich einen der beiden Pins auf HIGH setze höre ich nur ein kurzes Klacken des Motors - ist das am Ende ein Schrittmotor? Wie genau funktioniert die Ansteuerung? Besten Dank!
Für einen uC-Anfänger hast du ja schon ein super Equipment - wenn auch ein Netzteil dazugehört, hänge am Besten testweise mal das dran - 3-5V sollten ein stabiles Ansprechen des uC gewährleisten
An den Batterien liegt es nicht, der Controller läuft ab 1.8V sauber. Da die Brown-Out-Fuse auch beim gekauften Cometen nicht gesetzt ist, gibt es auch da keine Probleme. Ich würde auf den RESET-Kontakt tippen. Den zu erwischen ist nicht ganz einfach. Das Bohrloch muss exakt über der Oberfläche des RESET-Pads gebohrt sein (1,6mm über der Blechkante der USB-Buchse). Ist es zu hoch, bekommt der Reset-Draht keinen Kontakt zum Pad, wurde zu tief gebohrt, ist mitunter das Pad verletzt und der RESET-Draht trifft anstatt auf Kupfer nur auf nacktes FR4. BTW: Der Reset-Draht mussetwa 2mm tiefer in den Cometen ragen, als der USB-Stecker lang ist. An der Spitze des Drahtes sollte man ein sehr flaches U biegen, damit der Draht nicht an der FR4-Kante hängen bleibt und auf das Pad gleiten kann. Der Draht selber muss etwas federn können. Das Bohrloch für den RESET draht sollte 1,5mm im Durchmesser sein. Für den Draht nimmt man am besten 0,5mm Rundmaterial, idealerweise Phosphorbronze oder Messingdraht. Thermos That's schrieb: > wenn ich einen der beiden Pins auf > HIGH setze höre ich nur ein kurzes Klacken des Motors - ist das am Ende > ein Schrittmotor? Das Klacken bedeutet, dass der Motor kurz an den Anschlag läuft und die Firmware den Motor dann abschaltet. Das ist kein Schrittmotor, sondern ein normaler Spielzeug-Gleichstrommotor, wie er auch in CD-Schubladen und billig-Cd-Playern als Spindelmotor verwendet wird. Die Ansteuerung geschieht über eine diskrete H-Brücke. Thermos That's schrieb: > wenn ich einen der beiden Pins auf > HIGH setze Direkt am Motor? Das solltest Du bleiben lassen, das kann Dir im ungünstigsten Fall die H-Brücke braten.
:
Bearbeitet durch User
Danke für die Antwort, das passt. In der einen Drehrichtung war der
Motor im Anschlag, in der anderen ging die Brücke irgendwarum nicht.
Nach bewährter fachmännischer Reparatur ("überall rumdrücken") klappte
das dann auch wieder, scheine mir irgendwo einen Wackelkontakt
eingehandelt zu haben.
Der Controller ist bereits geflasht, ich wechsele die Pegel also
softwareseitig.
Thermos That's schrieb: > scheine mir irgendwo einen Wackelkontakt > eingehandelt zu haben. Es geht immer nur, wenn 1 Zweig der H-Brücke angesteuert ist. Man sollte per Software unbedingt vermeiden (verriegeln!), dass beide Zweige zeitgleich angesteuert werden, sonst gibt´s Rauchzeichen. Falls doch ein Wackler, zuerst die H-Brücke und das Motorkabel auf ordentliche Lötung prüfen.
Danke für die vielen Tipps - hab mich mal weiter mit der Materie beschäftigt. Den Reset-Kontakt habe ich mit nem Stück Federblech kontaktiert und das Gehäuse ist soweit aufgebort, dass ich das Pad sehen kann. Ausserdem: 1.) Mit eingelegten Batterien unterbricht der Comet die Adaption, wenn ich per ISP drauf zugreife. 2.) In meinem Screenshot oben vom Logic Analyzer sieht man, dass sich was tut auf dem Reset-Port. Das Signal liegt auf HI und wird ab und zu vom Programmer auf LO gezogen. Die Spannung für HI kommt jedoch VOM µC, nehme ich an. Und wenn ich nämlich den Reset-Pin weglasse, tut sich wiegesagt gar nix, d.h. Adaption wird nicht unterbrochen und kein HI-Pegel vorhanden. Die Stromversorgung ist denke ich auch nicht schuld weil: 1.) Wenn ich den Mysmartusb nehme, dann versorgt dieser den µC mit 3V. 2.) Wenn ich ein Netzteil mit stabilisierten 3V anschließe anstelle der Batterien, dann hab ich laut AVRISP MKII keine 3V Target Spannung sondern 2.6-2.7V, also unwesentlich mehr als mit Batterie. Hab inzwischen rausgefunden, dass ich mit den Logic Analyzer auch SPI decodieren kann. Dort sieht man dann, dass der Programmer auf MOSI versucht, dem Cometen ne Device ID zu entlocken, aber auf MISO nix gescheites reinkommt (entweder 0x00 oder 0xFF). Dass das ISP-Interface vom µC kaputt ist schließe ich auch aus, weil der Progmatic Programmierstick funktioniert wenn ich ihn anschließe...
So, ich hab's hinbekommen - beide Programmer finden jetzt die Device ID
:D :D :D
Hatte den Cometen schlussendlich geöffnet, sämtliche Schaltpläne
studiert und die ISP-Pads durchgemessen / mit den USB-Pins verglichen.
Daraufhin hab ich festgestellt, dass SCK und MISO doch vertauscht
waren... Ich muss demnach die Belegung vom Thermy verwenden
(GND/SCK/MOSI/MISO/VCC). Das hatte ich zwar schonmal probiert, aber
dabei wahrscheinlich den Reset nicht richtig kontaktiert.
Jedenfalls sagt mir Atmel Studio, dass es ein Atmega169P bzw. PA ist,
0x1E9405 -> kann das stimmen? Hab den Cometen im Okt 2010 bei Conrad
gekauft und er hat die Beschriftung auf den Tasten.
Detected device
Device names ATmega169P, ATmega169PA
Device signature 0x1E9405
Datasheet information
ATmega169P
CPU AVR8
Flash size 16 Kbytes
EEPROM size 512 bytes
SRAM size 1 Kbytes
VCC range 1,8 - 5,5 V
Maximum speed N/A
avrdude sagt folgendes (mit dem Mysmartusb light):
Programmer Type : STK500V2
Description : Atmel STK500 Version 2.x firmware
Programmer Model: STK500
Hardware Version: 3
Firmware Version Master : 2.10
Topcard : Unknown
Vtarget : 0.0 V
SCK period : 17.4 us
Varef : 0.0 V
Oscillator : Off
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.03s
avrdude.exe: Device signature = 0x1e9405
avrdude.exe: safemode: lfuse reads as 62
avrdude.exe: safemode: hfuse reads as D9
avrdude.exe: safemode: efuse reads as FF
avrdude.exe: safemode: lfuse reads as 62
avrdude.exe: safemode: hfuse reads as D9
avrdude.exe: safemode: efuse reads as FF
avrdude.exe: safemode: Fuses OK (H:FF, E:D9, L:62)
avrdude.exe done. Thank you.
:
Bearbeitet durch User
Nach dem was ich bisher gelesen hatte, dachte ich dass der Comet und der Thermy in etwa baugleich sind. Eventuell hilft dir folgendes: https://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#Modelle zur Identifikation. Edit: Hier steht auch noch mal das was du auf eigene Faust rausfinden musstest, doof... https://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#Pinbelegung
:
Bearbeitet durch User
Die Belegung der USB-Buchse ist bei allen Zero/Comet/Thermy-Reglern gleich. Andreas K. schrieb: > Jedenfalls sagt mir Atmel Studio, dass es ein Atmega169P bzw. PA ist, > 0x1E9405 -> kann das stimmen? Hab den Cometen im Okt 2010 bei Conrad > gekauft und er hat die Beschriftung auf den Tasten. Dann ist es definitiv ein Mega169P(V). Du musst also den Code für diesen Controller assemblieren/kompilieren. Das Fiese am Mega169PA ist, dass er dieselbe Kennung hat, aber unterschiedliche Interruptregister und -bitpositionen. Daher läuft ein für den P gebautes Programm nicht auf dem PA und umgekehrt.
@Thermos: Die Wiki-Seite kenne ich ;) Dort hab ich auch die 3 verschiedenen Sschaltpläne her... Letztendlich hatte mich aber die Aussage verwirrt, dass beim Aldi Thermy MISO und SCK vertauscht sind, denn bei meinem Cometen sind sie wie sich herausstellte auch vertauscht... Mein Comet sieht so aus und ist mit 4 6er Torx-Schrauben verschraubt: http://www.elv-downloads.de/bilder/artikel/Produkte/9/957/95797/Internet/normalneu/95797_F02_GeComet.jpg Naja, wenigstens hab ich jetzt was über SPI und ISP gelernt und konnte mit meinem Logic Analyzer rumspielen :D @Knut: Was meinst Du mit 'Kennung'? Atmega169 oder die Device ID?
Device ID.
Andreas K. schrieb: > Mein Comet sieht so aus Genau wie meine, nur mit Schweißnippeln anstelle der Schrauben. Ich habe auch neue Comets mit dem Comet-Aufdruck und alte und 2011er Thermys, bei allen ist die USB-Buchse gleich beschaltet.
Angehängte Dateien:
Falls Euch mal interessiert wie ein Comet (Originalfirmware) vs. einem mechanischen Thermostat regelt: anbei eine Grafik. SZ = Schlafzimmer, dort sind 2 Cometen, die ab 21 Uhr auf 17 Grad minimum eingestellt sind, ab 6:30 Uhr (bis 21 Uhr) auf 23 Grad. WZ = Wohnzimmer, mechanische Thermostate auf konstanter Einstellung, keine Absenkung. Man sieht, dass die mechanischen Thermostate sehr grob regeln (das entspricht auch dem subjektiven Gefühl dazu) und gerne mal sehr weit nach oben schiessen und dann wieder stark abkühlen lassen, die Hysterese liegt also bei eher 3 Grad. Der Comet regelt sehr fein, tagsüber hielt er konstant die 22 Grad. Der Temperatursensor steht am anderen Ende des Raums, die Comet selber haben wahrscheinlich 23 Grad, gleich am Heizkörper. Die Spikes nach Mitternacht haben eher mit offener Türe des SZ zu tun, als ich ins Bett ging und so wärmere Luft von aussen einströmt.
Ich glaube, beim Posten der Grafik ist etwas durcheinandergeraten? Conny G. schrieb: > als ich ins Bett ging und so wärmere Luft von aussen einströmt. Wie meinst Du das denn? ;-)
Knut Ballhause schrieb: > Ich glaube, beim Posten der Grafik ist etwas durcheinandergeraten? Wieso, was stimmt nicht? >> als ich ins Bett ging und so wärmere Luft von aussen einströmt. > Wie meinst Du das denn? ;-) Standard: Tür zu, Temp nachts 19 Grad. Um 1 bin ich beim Zähne putzen, währenddessen ist die Tür offen und Luft mit 22 Grad aus dem Flur strömt ins Schlafzimmer. Jetzt klarer? :-)
Conny G. schrieb: > Wieso, was stimmt nicht? Für mich sehen beide Diagramme gleich schlecht aus. Die Temperatur sollte ohne externe Störungen maximal ein halbes Grad nach oben und unten vom Sollwert abweichen. Sollten kurzzeitige Störungen auftreten, solle man diese auch nur als kurze Störung im Diagramm sehen. Bei Dir sieht es so aus, als wenn ständig die Tür oder ein Fenster geöffnet und geschlossen wird. Oder die Sonne scheint durch die Fenster, zumindest tagsüber, wodurch der Idealverlauf gestört wird. Das mit der warmen Luft war nur Kopfkino, vergiss es.
Ich finde die Kurve vom SZ gar nicht so schlecht. Ich finde die Peaks allerdings auch irgendwie komisch und zu identisch - es sei denn du bist wirklich beide male um ca. 3:00 ins Bett gegangen. Eine Vermutung wäre, dass um 3:00 die Heizung (Nachtabsenkung) einschaltet und der Heizkörper "plötzlich" warm wird, obwohl der Regler auf einer Stellung war, bei der vorher nicht geheizt wurde. Er regelt also nachdem die Heiz-Anlage "aufwacht" und die Heizkörper befeuert wieder runter...
Phil, das ist ganz sicher das Offenstehen der Türe im Schlafzimmer, das habe ich jetzt mehrfach beobachtet. Und ich gehe tatsächlich immer eher 2-3 Uhr ins Bett. Eine Stunde sieht man dem Diagramm kaum, ist ja ein Zeitraum von 36h insgesamt. Im Wz hat Knut wahrscheinlich recht, da war Sonne mit im Spiel, gerade an dem Tag. Trotzdem sehe ich auch jetzt noch, dass die mechanischen Thermostate wesentlich gröber / langsamer regeln, Hysterese 2 Grad.
Conny G. schrieb: > Trotzdem sehe ich auch jetzt noch, dass die mechanischen > Thermostate wesentlich gröber / langsamer regeln, Hysterese 2 Grad. Und natürlich in direkter Abhängigkeit zum mechanischen Verhalten des Ventils. Das wird durch den elektronischen Regler weitgehend ausgeglichen. Allerdings sollte bei einer guten Regelschleife die Regelung irgendwann aufhören, wenn keine Störgröße eingreift. Und dieses Verhalten kann man im Diagramm leider gar nicht sehen. Weiterhin ist der Temperaturfühler im Ventilkopf immer suboptimal, da der Regler immer mehr oder weniger direkt vom Heizkörper angestrahlt wird und daher ein ständiges Auf- und Zuregeln stattfindet, zumal wenn die Vorlauftemperatur unnötig hoch ist. Abhilfe schaffen da nur abgesetzte Sensoren.
Knut Ballhause schrieb: > Und natürlich in direkter Abhängigkeit zum mechanischen Verhalten des > Ventils. Das wird durch den elektronischen Regler weitgehend > ausgeglichen. Allerdings sollte bei einer guten Regelschleife die > Regelung irgendwann aufhören, wenn keine Störgröße eingreift. Im zwar hübschen, aber schlecht gedämmten Altbau ist eine Störgröße das schnelle Auskühlen des Raums :-) Jetzt bei Minusgraden fällt im Schlafzimmer die Temperatur in 3h um 4 Grad, sieht man schön, wenn dort die Absenkung um 21 Uhr greift. Geht jetzt bei -5 Grad draussen doppelt so schnell wie vor 1-2 Wochen +5 Grad. Mache die Absenkung auch nicht aus Energiespargründen (im Altbau quatsch, weil muss ja morgens alles wieder hochheizen), sondern für besseres Schlafklima. Und bgzl. abgesetzter Temperatursensor: ja, das würde ich mir langfristig noch vorstellen, dazu brauche ich Funkverbindung vom Comet zu meiner Home Automation. :-)
Conny G. schrieb: > dazu brauche ich Funkverbindung vom Comet > zu meiner Home Automation. :-) Hat die HA schon Sensoren im Haus verteilt?
Knut Ballhause schrieb: > Conny G. schrieb: >> dazu brauche ich Funkverbindung vom Comet >> zu meiner Home Automation. :-) > > Hat die HA schon Sensoren im Haus verteilt? Gerade dabei: Beitrag "ATMega328 und ATTiny45 mit I2C verbinden" Im ersten Schritt habe ich meine uralten ELV-Sensoren eingebunden, im Nächsten werde ich Sensoren selber machen, die dann direkt mein H.A.-Protokoll (868 Mhz RFM12) verwenden.
Die Hardware für den Funk gibt es hier: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" An der Firmware arbeite ich noch. Kannst Du aber auch selber machen. Achtung: Reichweite mit den RFM70 auf innerhalb eines Raumes oder durch maximal eine Wand begrenzt!
Edit: Funk-Hardware Dateien angehängt. Vorheriger Link beinhaltete nur den Kabelsensor...
Cool, danke! Weshalb das RFM70? Wäre das mit RFM12 kompatibel (zu bekommen) oder würde es mit RFM12 auch funktionieren? Und Tray um die Cometen nicht öffnen zu müssen?
So, bin endlich dazu gekommen Knut's Firmware zu flashen... Funktioniert alles soweit, einzig das langsame Blinken beim Einstellen von Zahlenwerten irritiert etwas und Zeitanzeige brauch ich eigentlich auch nicht. Soll- und Istwert-Anzeige ist auf jeden Fall super. Fehlen tut mir eigentlich nur noch ne Kindersicherung ;) Ansonsten - Fuse-Bits konnte ich erst nach dem Flashen setzen - ist das normal? Ausserdem konnte ich nur mit den AVRISPmkII die Fuses setzen - der Mysmartusb light verweigert mit dem mitgelieferten Progtool (AVR-Dude basierend) sowohl das Auslesen als auch das Flashen der Fuses. Flash auslesen klappt jedoch. Mit Atmel-Studio läuft er gar nicht. Ich werde den Mysmartbla wohl zurückgeben und mir was ordentliches holen. Reichelt hat grad den Dragon für rund 40EUR im Angebot...
Conny G. schrieb: > Weshalb das RFM70? Weil klein und günstig und mit Platinenantenne. Conny G. schrieb: > Wäre das mit RFM12 kompatibel Nein. Conny G. schrieb: > würde es mit RFM12 auch funktionieren? Ja, wenn man den Tray umroutet und dem RFM12 eine passende Antenne spendiert. Conny G. schrieb: > Und Tray um die Cometen nicht öffnen zu müssen? Genau. Das Herumfrickeln mit den Schweißnippeln ist alles andere als schön. Andreas K. schrieb: > So, bin endlich dazu gekommen Knut's Firmware zu flashen... > > Funktioniert alles soweit, Gut ;-) Andreas K. schrieb: > einzig das langsame Blinken beim Einstellen > von Zahlenwerten irritiert etwas Schnelleres Blinken schafft das LCD nicht wirklich. Andreas K. schrieb: > Zeitanzeige brauch ich eigentlich > auch nicht. War als Gimmick gedacht, wenn man keine Armband- oder Wanduhr hat ;-) Andreas K. schrieb: > Soll- und Istwert-Anzeige ist auf jeden Fall super. > > Fehlen tut mir eigentlich nur noch ne Kindersicherung ;) Kindersicherung kommt. Die hilft dann auch bei großen Kindern, die andauernd meinen, am Drehrad drehen zu müssen ;-) Andreas K. schrieb: > Ansonsten - Fuse-Bits konnte ich erst nach dem Flashen setzen - ist das > normal? Nö, normal ist das nicht, aber das liegt daran, dass die originale Firmware alle Lockbits gesetzt hat und somit können die Fuses nicht verifiziert werden, was eine Fehlermeldung auslöst. Nach dem Chip-Erase (beim Programmieren) sind die Lockbits wieder gelöscht und somit der Lesezugriff auf die Fuses freigeschaltet. Andreas K. schrieb: > Ich werde > den Mysmartbla wohl zurückgeben und mir was ordentliches holen. Reichelt > hat grad den Dragon für rund 40EUR im Angebot... Der Dragon ist OK für den Preis. Allerdings hat der ein paar Macken. Der AVRISPmkII kann alle Controller flashen, außer im HV-Modus. Das ist wichtig, wenn man mit XMEGAs und neuen TPI-Tinys viel zu tun hat.
Ich freu mich, dass Du der Kindersicherung gegenüber nicht mehr so abgeneigt bist wie am Anfang :) Wegen dem Dragon - kannst Du dessen Macken etwas konkretisieren? Hab schon oft derartige Bemerkungen gelesen, aber das einzige wovon ich weiss ist, dass die In/Outs sowie Spannungswandler nicht so gut geschützt sind (ESD-anfällig, Überspannung) und dass man dagegen noch diverse Schutzmassnahmen vornehmen sollte. Aber von der Kompatibilität her kann er doch alles, was der AVRISPmkII kann plus die High-Voltage-Sachen und Debugging, oder?
Andreas K. schrieb: > Ich freu mich, dass Du der Kindersicherung gegenüber nicht mehr so > abgeneigt bist wie am Anfang :) Hmm, war ich das..? Andreas K. schrieb: > kannst Du dessen Macken etwas konkretisieren? Hab > schon oft derartige Bemerkungen gelesen, aber das einzige wovon ich > weiss ist, dass die In/Outs sowie Spannungswandler nicht so gut > geschützt sind (ESD-anfällig, Überspannung) und dass man dagegen noch > diverse Schutzmassnahmen vornehmen sollte. Das ist das Hauptproblem. Das andere ist, dass es beim PDI mit diversen XMEGAs Probleme gibt und bis heute nichts dagegen getan werden konnte. Andreas K. schrieb: > Aber von der Kompatibilität her kann er doch alles, was der AVRISPmkII > kann plus die High-Voltage-Sachen und Debugging, oder? Prinzipiell ja. Der MkII ist eigentlich für alles und der Drageon für das, was der MkII nicht kann. Ich habe beide Geräte und den Dragon eigentlich noch nie wirklich gebraucht. Debugging mach ich nicht, da ich in Assembler unterwegs bin.
Angehängte Dateien:
-
Comet_Reset_Pin.JPG
110 KB
Meine Bemerkung zur Kindersicherung nehme ich mit Asche auf meinem Haupt zurück - es war ein anderer User, der anfangs mal keinen Bedarf dafür geäußert hat... dumdidum. Nen neuen ISP-Programmer brauch ich jetzt zum Glück doch nicht. Hab den Mysmartusb light 100% zum Laufen bekommen - mit AVR-Dude geht alles - inkl. Fuses und mit Atmel Studio jetzt auch (musste erst per Tools/Add Target nen STK500 hinzufügen...) Ansonsten - Mit der Regelung bin ich echt zufrieden, was jedoch verwirrt ist: wenn Ist>Soll, z.B. 22 statt 19 Grad, dann scheint der Regler immer wieder mal zu versuchen, das Ventil zu schließen, auch wenn es schon auf Anschlag ist. (Es dreht ein paar Sekunden, nicht nur kurz.) Ich weiss dass die Reglung adaptiv ist und das ist auch gut so, mich wundert nur, dass er jetzt scheinbar sogar noch weiter zudreht, als die Originalfirmware und dabei der Motor gar nicht abzusterben scheint. Hab jetzt noch nen 2. Regler aufgebohrt - im wahrsten Sinne :o) - und geflasht - mal sehen, ob der sich genauso verhält... Im Anhang ist noch ein Foto, wo man hoffentlich sieht wie weit oben man den Bohrer ansetzen sollte ohne den Kontakt auf der Platine zu zerstören.
:
Bearbeitet durch User
Andreas K. schrieb: > Hab jetzt noch nen 2. Regler aufgebohrt - im wahrsten Sinne :o) Wow - was für ein Loch :-P! Eins mit 1.5mm und rund hätte auch gereicht (für einen RESET-Draht)... Aber Hauptsache es geht. Andreas K. schrieb: > Ansonsten - Mit der Regelung bin ich echt zufrieden, was jedoch verwirrt > ist: wenn Ist>Soll, z.B. 22 statt 19 Grad, dann scheint der Regler immer > wieder mal zu versuchen, das Ventil zu schließen, auch wenn es schon auf > Anschlag ist. (Es dreht ein paar Sekunden, nicht nur kurz.) Eigentlich schließt er nur so lange, bis entweder der Motor stehen bleibt, oder der Motorstrom einen kritischen Wert überschreitet. Wenn das passiert, wird die Ventil-Zu Marke gesetzt und von dort aus der Fahrweg nach außen berechnet, den er bei der Testfahrt gemessen hat. Diese Vorgehensweise verhindert, dass das Ventil bei Verlust von Getriebepulsen halboffen bleibt und der Heizkörper nicht kalt wird. Ich hoffe, Du hast die neueste Firmware drauf, die ich per e-Mail geschickt hatte? Die Funktion ist noch neu und bisher an 4 Heizkörpern erfolgreich getestet. Beobachte das Verhalten in Bezug auf die Regelung mal genauer. Andreas K. schrieb: > Ich weiss dass die Reglung adaptiv ist und das ist auch gut so, mich > wundert nur, dass er jetzt scheinbar sogar noch weiter zudreht, als die > Originalfirmware und dabei der Motor gar nicht abzusterben scheint. Der Motor geht in jedem Fall aus, wenn das Ventil nicht mehr nachgibt. Zuvor sollte aber die Strombegrenzung greifen. Nutzt Du Batterien oder Akkus? Ich nutze Akkus, vielleicht muss man bei Batterien noch etwas Feinschliff machen, da der Motor mit mehr Spannung natürlich stärker ist.
:
Bearbeitet durch User
Knut Ballhause schrieb: > Wow - was für ein Loch :-P! Eins mit 1.5mm und rund hätte auch gereicht > (für einen RESET-Draht)... Aber Hauptsache es geht. > Is kein Draht - is ein Stück Federblech ;) > Der Motor geht in jedem Fall aus, wenn das Ventil nicht mehr nachgibt. > Zuvor sollte aber die Strombegrenzung greifen. Nutzt Du Batterien oder > Akkus? Ich nutze Akkus, vielleicht muss man bei Batterien noch etwas > Feinschliff machen, da der Motor mit mehr Spannung natürlich stärker > ist. Hm... hab richtige Batterien und werd's weiter beobachten. Auf jeden Fall war das Ventil schon zu (man hört sonst das Rauschen des Wassers durch's Ventil) und der Regler hat ab und an versucht, weiterzudrehen - und das nicht in so kleinen Stückchen wie sonst, sondern durchaus mehrere Sekunden lang. Hatte auch das Gefühl, dass da schon irgendwas im Reglergehäuse auf Anschlag war, kenn jetzt den mechanischen Aufbau leider nicht, aber so als ob das Gewinde zuende ist.
Andreas K. schrieb: > Auf jeden Fall war das Ventil schon zu (man hört sonst das Rauschen des > Wassers durch's Ventil) und der Regler hat ab und an versucht, Dann ist der Druck zu hoch und/oder die Ventilvoreinstellung falsch. Ich hatte bis Ende 2012 eine Standardpumpe im Einsatz und beschissene Regelcharakteristik an den Heizkörperventilen, egal ob konventionell oder elektronisch. Nach Umstellung auf eine 5-Watt-Pumpe habe ich nicht nur Regler, die regeln, sondern auch nur 10KWh für den ganzen Winter gebraucht.
Andreas K. schrieb: > und das nicht in so kleinen Stückchen wie sonst, > sondern durchaus mehrere Sekunden lang. Hatte auch das Gefühl, dass da > schon irgendwas im Reglergehäuse auf Anschlag war, kenn jetzt den > mechanischen Aufbau leider nicht, aber so als ob das Gewinde zuende ist. Das kann durchaus sein. Vielleicht ist der Ventilweg einfach zu lang. Lege mal ein 20ct-Stück in den Adapter, so dass dieses zwischen Ventilstößel und Reglerstößel als Abstandhalter fungiert.
Angehängte Dateien:
-
IMG_2354.jpg
63 KB -
IMG_2352.jpg
99 KB -
IMG_2353.jpg
120 KB
Knut Ballhause schrieb: > Conny G. schrieb: >> Und Tray um die Cometen nicht öffnen zu müssen? > > Genau. Das Herumfrickeln mit den Schweißnippeln ist alles andere als > schön. Ich habe heute meine 2. Lieferung von Cometen erhalten und auch das Wohnzimmer ist nun mit diesen ausgestattet. Habe einen der weiteren geöffnet, bei mir haben die gar keine Schweissnippel, jedenfalls nicht das Gehäuse, nur die Platine? Fotos anbei. Dann wäre es ja gar nicht so schwierig das Funkmodul intern unterzubekommen?
Ach, mal wieder ein neuer Gehäuseentwurf mit Klammern statt Schrauben. Ja, hier könnte man ein Funkmodul unterbringen.
Wenn ich das recht sehe müsste ich gemäß http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate#THERMy_V3 nichtmal de Platine lösen, weil Lötpads für SPI vorne/oben sind, wo der "Batteriebügel" anfängt? Ansonsten scheint oberflächlich am weißen Stopplack geurteilt die Platine eher wie Thermy V3 zu sein? Hab ich dann Eurer Einschätzung nach die Portänderungen zu erwarten, die für den Thermy genannt wurden ( wenn ich die Zusammenhänge grade richtig habe)?
Diese Pads sind ja identisch mit dem "USB"-Port, dh ich könnte neue Firmware immer noch darüber, also "von außen", flashen?
Conny G. schrieb: > Diese Pads sind ja identisch mit dem "USB"-Port, dh ich könnte neue > Firmware immer noch darüber, also "von außen", flashen? Ja, solange Deine interne Elektronik nicht dagegenwirkt, also die Portpins in irgendeiner Art so belastet, dass die Programmierpulse nicht mehr durchkommen. Wie Dir vielleicht aufgefallen ist, kannst Du mit den 3 ISP-Pins allein kein Funkmodul ansteuern, weil Du mindestens noch /CS und die Interruptleitung brauchst. Daher musst Du Dich noch an den JTAG-Pads auf der anderen Seite bedienen.
:
Bearbeitet durch User
Conny G. schrieb: > Ansonsten scheint oberflächlich am weißen Stopplack geurteilt die > Platine eher wie Thermy V3 zu sein? > Hab ich dann Eurer Einschätzung nach die Portänderungen zu erwarten, die > für den Thermy genannt wurden ( wenn ich die Zusammenhänge grade richtig > habe)? Weiß jemand?
Neue Programmversionen hier: Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat" Nur für alten und neuen Comet-Regler und für 2011er und 2012er Thermy verwendbar.
Hi, habe ganz aufmerksam euren Thread verfolgt daraus entstand meine Frage. Und zwar gibt es doch bei jedem z.B. Drucker ein WLAN Modul welches sich im WLAN Netzwerk einbindet, wenn man auf "wireless" drückt. Auf einem Thermy Heizungsthermostat ist doch auch für ein "thermy Progammierstick" eine USB Buchse. Ist es möglich diese mit einer WLAN-Antenne zu verbinden und mit deiner (KNUT) Fireware diese dann mit PC etc. anzusteuern(AN/AUS). Ich bedanke mich herzlich für eine Antwort. Grüße Joh
joh90 schrieb: > Ist es möglich diese mit einer > WLAN-Antenne zu verbinden und mit deiner (KNUT) Fireware diese dann mit > PC etc. anzusteuern(AN/AUS). Sowas gibt es nicht, wäre aber auch nicht so wirklich sinnvoll. Über die SPI-Pins des ISP-Programmers und 3 weiterer Pins die man von drinnen nach draußen legen muss kann man ein nRF24L01+ Modul anschließen. Das Modul sendet zwar auch auf 2.4GHz, aber nutzt ein anderes Protokoll. Man braucht am PC dann auch noch ein nRF24L01+ Modul welches man dann über eine PC-Software anspricht und die Daten mit den anderen Modulen austauscht, so kann man neue Zeit- und Temperatureinstellungen einfach übertragen. Ich nutze diese Module zwar, hab aber noch keines an ein Heizungsthermostat angeschlossen.
Hallo, ich habe ein Problem: Auf meinen alten Meges-Eckventilen funktioniert der Sparmatic Comet nicht, weil er nicht genügend Kraft aufbringt um das Ventil zu schliessen. Ein Sparmatic Basic funktioniert hingegen sehr gut. Wenn ich den Comet testweise mit einem 5V Netzteil versorge, reicht die Kraft um das Ventil zu schliessen. Ich nehme mal an, das Problem ist hier die Strombegrenzung des Motors. Lässt sich evtl. eine Erhöhung der Strombegrenzung mit der Travelrec-Firmware erreichen? Am besten wäre es, wenn man das irgendwie als Parameter einstellen könnte. Oder ist ein HW-Mod die einzige Möglichkeit den Strom zu erhöhen?
Die Strommessung ist eine Sache, die verfügbare Kraft des Motors ist die andere. Wenn das Ventil zu schwergängig ist, bleibt der Motor einfach stehen. Da bringen volle Batterien vielleicht gerade noch genug Energie, aber wenn die Batterien etwas älter sind oder Akkus verwendet werden, reicht´s halt nicht. Bei meinen Heimeier- und Danfoss-Ventilen gab es bisher keine Probleme. Hardware- und Software-Mods bringen hier nichts.
Mit der Original-Firmware hatte ich bisher den Eindruck, dass nicht der Motor abgewürgt wird, sondern dass die Adaptierung deshalb nicht richtig erfolgt, weil die Stromschwelle, bei der abgeschalten wird, zu niedrig angesetzt ist. Jetzt hatte ich daran gedacht einfach den Shunt-Widerstand zu verkleinern mit dem der Strom gemessen wird. Nachdem ich aber nicht viel gutes über die Original-Firmware gelesen habe würde ich auch gerne deine Firmware nutzen. Deshalb die Frage: Verhält sich hier die Strombegrenzung anders als mit der Original-FW? Evtl. könnte ich mir den HW-Mod. dann ja sparen. Mit dem Sparmatic Basic bin ich eigentlich zufrieden. Der regelt schon seit jahren zuverlässig auf meinen schwergängigen Ventilen, fürs Schlafzimmer ist er aber etwas zu laut. Die Comets sind zwar leiser, scheinen sonst aber ein ziemlicher Rückschritt im Vergleich zum Basic zu sein. Das Gummiritzel musste ich beim Comet sogar schon festkleben, weil es immer von der Welle gezogen wurde.
Du kannst die FW gerne probieren, aber ich habe da so meine Zweifel. Für die Sourcen schicke bitte eine PN. Wann hast Du die Comets gekauft? Ich frage wegen des verbauten Controllers...
:
Bearbeitet durch User
Kann ich nicht mehr genau sagen, ich meine Ende 2011 oder Anfang 2012. Ich habe mal einen geöffnet. Der sichtbare Teil der Platine sieht exakt so aus, wie auf dem Bild zum "Comet ThermyV1.5" unter http://www.mikrocontroller.net/articles/Sparmatic_Heizungsthermostate . Die Beschriftung kann ich leider nicht lesen ohne das Ding weiter zu zerlegen. Zum Flashen hätte ich einen USB-ISP Adapter. Ich nehme mal an, den muss ich entsprechend dem Bild mit den 6 Pads links neben dem Drehgeber verbinden, richtig?
Richtig. Oder einen 5-Pin MiniB-USB-Stecker mit zusätzlichem Reset-Pin basteln... Wenn Du Dir wegen des verbauten Controllers nicht sicher bist, probiere einfach beide *.hex mal aus, wenn die Tasten nicht funktionieren, war´s die falsche... Beitrag "Re: Alternative Firmware für Sparmatic Zero Heizungsthermostat"
Ich benötige Heizkörperthermostate mit stark vereinfachter Funktionalität. Können sie mir dazu verhelfen? Mein Wunsch-Thermostat braucht nur zwei Temperaturen und einen Taster. Normalerweise arbeitet er mit der Spartemperatur - z.B. 16°C. Nach Druck auf den Taster schaltet er auf Heiztemperatur - z.B. 21°C. Nach einer Stunde schaltet er wieder automatisch zur Spartemperatur zurück. Ich wäre auch zufrieden, wenn der EUROtronic SPARmatic comet mit entsprechendem Programm arbeiten würde.
Hermann Wegmann schrieb: > Ich benötige Heizkörperthermostate mit stark vereinfachter > Funktionalität. Hermann Wegmann schrieb: > Mein Wunsch-Thermostat braucht nur zwei Temperaturen und einen Taster. > Normalerweise arbeitet er mit der Spartemperatur - z.B. 16°C. > Nach Druck auf den Taster schaltet er auf Heiztemperatur - z.B. 21°C. > Nach einer Stunde schaltet er wieder automatisch zur Spartemperatur > zurück. Ob stark vereinfacht oder nicht macht fast keinen Unterschied. Das eigentliche Programm misst die Temperatur, steuert über den Motor das Ventil, aktualisiert Uhr-Timer und zeigt etwas auf dem Display an. Hier stecken 80% des Programmieraufwandes. Wenn Du die vorhandenen ASM-Sources anpassen möchtest, dann PN an mich senden.
Angehängte Dateien:
-
20150214_151105.jpg
240 KB
Hier ein IOIO HT 2000 sieht stark wie ein Thermy V3 Board aus, nur mit neuer Motro Verbindung. Welche der zwei 3x2 Pads ist der ISP und wie ist dieser Belegt? Kann mir bitte jemand den neusten Source schicken?
Die oberen Pads sind die ISP-Pads. Untere Zeile davon in der Mitte ist Reset. Die anderen Pins liegen ebenfalls an der Mini-USB Buchse. Wegen der Sources habe ich ja Deine E-Mail...
Ist eigentlich das SPI Protokoll der Original Firmware bekannt? Oder muss man auf jeden Fall eine neue Firmware aufspielen um das Thermostat über die vorhandene USB Buchse programmieren zu können?
@ Tobias (Gast) Die vorhandene USB-Buchse + ein weiteres Pad ist doch direkt der ISP-Anschluss des Controllers.
Ja das ist mir bewusst ich meinte eher das Protokoll dass die PC bzw BT adapter benutzen um das Ding über die vorhandene Schnittstelle einzustellen, also Ziel Temperaturen für Tageszeiten usw. (nicht die Firmware flashen)
Das originale Protokoll ist mir nicht bekannt, da ich mir nie einen Programmieradapterstecker gekauft habe.
Hallo Leute, ich betreibe derzeit einen RPi als Thermostat. Bisher wird die Raumtemperatur über einen Heizlüfter konstant gehalten wengen starken Schwankungen in der Heiztemperatur. Ich würde den Heizkörper gerne mit einbinden und denke über eine Steuerung am Ventil nach. Ich möchte aber keine Regelung sondern eine Steuerung da ich die Temperatur am Heizkörper direkt über 2 Sensoren erfasse. Also: Steuerung des Ventils über Comet/Zero direkt ohne Regelung durch internen Temp-sensor und Rückmeldung der Ventilposition über Funk. Eine entsprechende Funktion konnte ich bisher in keiner der Firmwares entdecken. Gibt es hier schon etwas in dieser Richtung? Wenn nicht, hat jemand genug Kenntnis um Abzuschätzen ob das möglich ist?
Möglich wäre das in jedem Fall über die "USB"-Buchse. Im Programm ist dies noch nicht verankert, weil das noch niemand in's Spiel gebracht hat. Willst Du Daten übertragen oder nur 2 Pins für "Motor auf/zu" bedienen?
Hallo zusammen, super, dass sich jmd dieser Arbeit annimmt. Hatte bisher den Ansatz nur Motor und Getriebe zu verwenden und mit einem Arduino Nano oder so anzusteuern. Ich habe bereits ein 2,4Ghz Funknetz mit NRF24L01 Chips zu meinem Raspberry Pi. Könnte man diesen Funkchip an den Sparmatic Comet anbinden und dann darüber konfigurieren? Das wär hammer. Anbei gibt es bei Real online das Teil zur Zeit für 9,90 und ohne Versandkosten. Aber scheint wieder eine andere Version zu sein. Grüße
Dominik schrieb: > Hallo zusammen, > > super, dass sich jmd dieser Arbeit annimmt. > Hatte bisher den Ansatz nur Motor und Getriebe zu verwenden und mit > einem Arduino Nano oder so anzusteuern. Ich habe bereits ein 2,4Ghz > Funknetz mit NRF24L01 Chips zu meinem Raspberry Pi. > Könnte man diesen Funkchip an den Sparmatic Comet anbinden und dann > darüber konfigurieren? Das wär hammer. > > Anbei gibt es bei Real online das Teil zur Zeit für 9,90 und ohne > Versandkosten. Aber scheint wieder eine andere Version zu sein. > > Grüße Sorry. Also geht in die Richtung von thekk, nur ich habe schon konkret die Funkchips rumliegen.
Ja kannst den Mega169P der drin ist an dein NRF24L01 hängen. Musst nur selbst die FW anpassen oder neu schreiben. Kannst ja ma googeln ob es Board Settings für den Mega169P gibt das du den mit der Arduino IDE bespielen kannst.
Angehängte Dateien:
-
THERMYV3-sch.gif
170 KB
Hallo all, I have got the Thermy with White PCB disassembled. I am having trouble in understanding the current measurement for the motor and battery voltage measurement. In particular the circuit comprising of R18, R20, D3 and C9 is unclear to me. Is the pin PE5 used for power loss detection? If so, how is this done? Also why is there separate GND and 0V? I would appreciate if someone could clear these points to me. I have attached the schaltplan for the Thermy v3 which I believe is the latest. Thank you. Best regards.
Owais Fazal S. schrieb: > In particular the circuit comprising of R18, R20, D3 and C9 is unclear to > me. Current sensing for the valve motor. If the valve is fully closed, the current rises beyond a limit, and the software turns the driver circuitry off. This is used to auto-calibrate the valve position. > Is the pin PE5 used for power loss detection? Seems so. > If so, how is this > done? Without looking into the software, if you turn on the pullup of that pin, and the input reads back "high", the battery has obviously been removed. > Also why is there separate GND and 0V? So the controller itself can be powered off the electrolytic capacitor while the battery is absent.
Jörg, you are right with every point. @Owais: Sorry for not answering to your e-Mail these days. I´m a bit busy.
Hallo Jung, Thank you for your prompt response. I have measured the motor current and found out the stall current to be about 130mA whereas normal current draw of the motor when it is running is about 56mA. Can you please explain exactly how does the parallel arrangement of the resistor R18 and R20 help in measuring the current. I understand that the current measurement can be carried out using a shunt which I believe in this case is R18 2R2. On the software side the voltage drop on R18 can be measured using ADC and then current can be calculated using V/2R2. Please let me know if I understood this part correctly. Thank you.
Thermy gibts gerade bei Aldi Nord für 6€ in der Restekiste
Owais Fazal S. schrieb: > how does the parallel arrangement of the resistor R18 and R20 help in > measuring the current R18 is the shunt, R20 / C9 just form a lowpass filter (integrator).
@Jorg: Thank you for your response. If I understood correctly, normally c9 would present a large resistance due to DC current and voltage drop on R18 is measured as follows: Vin = ADCVal * Vref / 1024 And then current as: Imot = Vin / 2.2 Am I getting this right? @Knut: I realized you would be busy otherwise you respond quite fast ;) Thank you all.
Owais Fazal S. schrieb: > Am I getting this right? Basically yes. The R20/C9 lowpass just causes some additional delay, in the range of 1 MΩ · 100 nF = 100 ms.
@Jorg: Thanks for clearing that.
With the current measure it is not recommendet to wait for motor stall position - better switch the driver off, if the current reaches 100mA. This is enough to close all common valves. Higher forces may destroy the locking clamps. It is furthermore possible to detect the touch of the valve tip. This way you have the complete valve track as position values avaliable for calculation. Compared to the freewheeling current, the touch current is 10 or more percent higher.
:
Bearbeitet durch User
@Knut: Thank you for your suggestions. Is there a latest firmware for the Thermy shared on this forum? If so, I would be grateful if someone could share the link.
As I remember, I sent it to you, or am I wrong?
@Knut: Sorry, I have rechecked the conversation but there is no attachment. Can you please send it over again.
OK, will send you an e-mail tomorrow. Stay tuned...
@Knut: Thank you. I have tuned in ;)
Ahh - sorry, was out this week end. Try to send you the stuff today...
No problem, I am still tuned in :)
Hello, I have going through the alternative firmware for the Sparmatic Zero contributed by Matthias. What I can't seem to grasp is that how the PID output value is being translated into valve position. I understand that the control variables are all scaled by a factor of 256 as mentioned in the source code but since the output of the PID controller would be in deg/time-unit how is this translated to motor position exactly? Any help would be appreciated in this regard. Thank you. Regards.
Hi, I sent you another e-Mail. Owais Fazal S. schrieb: > I have going through the alternative firmware for the Sparmatic Zero > contributed by Matthias. Please be sure, that some things will not work on the Comet or Thermy, that are primary designed for the Zero. Different pinouts and a different display is used in each of the different device types.
Hello, @Knut: I have received the other e-mail. Thank you for the detailed clarification. Moreover, I understand that there are variations in the designs and some are not exactly pin compatible. I am just going through the control technique used here and then I will modify everything accordingly. Thanks for the heads up anyway :) Regards.
Guten Abend, Ich hab jetzt eine Zeit lang gelesen einiges Probiert, aber ich komm nicht weiter. Vielleicht liegt es einfach auch daran, dass ich bisher kaum was großes im Bereich AVR gemacht habe. Nun wollte ich einfach mal fragen gibt es im Moment ein fertiges "Paket"/"Projektmappe" oder eine funktionierende Version für den THERMy V3 mit den ATmega169PA. Ich brauche diese Custom Firmware einfach nur um über einem Bus mit dem Thermostat zu kommunizieren. Vielen vielen dank schon mal. Gruß Fabian
Was hast Du probiert und wo kommst Du nicht weiter? Welche Programmiersprache nutzt Du? Ich kann Dir ASM Sourcen schicken, wenn Du mir eine PN schickst. Dann kannst Du Dir die verschiedenen Module ansehen und bekommst vielleicht eine Ahnung von den internen Abläufen, um so die Firmware an den "Bus" anzupassen.
Guten Morgen, ich habe schon verschiedene Firmware's auf den THERMy v3 gespielt, aber bei jeder funktioniert etwas anderes nicht. Ich hab es mit: - OpenHR20_1.0 (Mit der Firmware funktioniert gar nichts.. Tasten, Motor ohne Funktion) - OpenZero (der Stellmotor spielt verrückt. Bei der ADAPT fahrt funktioniert er noch anschließend fährt er dauerhaft auf "zu" und stoppt nicht) - und mit Sparmatic_Comet_M169_ATM6_2013_03_29_V005c.rar (wie bei OpenHR20_1.0) probiert. Am liebsten wäre mir die Programmiersprache C. Ich will über einen CAN oder RS485 Bus (hab mich da noch nicht so festgelegt) die Soll Temperatur setzen. Danke Gruß Fabian
Hello, I have been going through the Sparmatic Zero firmware contributed by Matthias. I am having trouble in understanding the Programming part of the code in the files Programming.c if someone here has already gone through the code and could clear a few things regarding how the Program Data is maintained in the ProgramData array I would appreciate the help. Thank you. Owais.
Fabian W. schrieb: > - und mit Sparmatic_Comet_M169_ATM6_2013_03_29_V005c.rar (wie bei > OpenHR20_1.0) Du brauchst für den Thermy v3 eine entsprechende Firmware. Alle Versionen vor v006 sind nur für den Comet v2. Für den Thermy v3 und Comet v3 muss die Firmware für den Mega 169PA assembliert werden. https://www.mikrocontroller.net/attachment/244838/Sparmatic_V3_Thermostat_M169PA_ATM6.hex
Hi, da es bei Lidl gerade wieder Silvercrest Thermostate (Thermy V3?) im Angebot gibt, hab ich mir mal einen zugelegt und überlege ob ich nicht einen ESP8266 als MQTT Schnittstelle noch anbauen könnte. Laut dem Schaltplan der V3 wäre auch noch eine serielle Schnittstelle frei. Ich wollte fragen, ob jemand so freundlich wäre und mir den Sourcecode für den Thermy V3 zur Verfügung stellen könnte? Vielen Dank und viele Grüße.
Hallo Stefan, bist du fündig geworden? Ich habe mir auch iene paar Comet V3 zugelegt und würde die auch gerne zentral steuern ... MQTT und OpenHab stehen da ganz oben auf meiner Liste. Da gibt es auch ein Arduino Projekt dazu: https://forum.arduino.cc/index.php?topic=371928.0. Über den ESP8266 habe ich nur gelesen, dass er für einen Batteriebetrieb viel zu viel Strom zieht ;-( lG Gerhard
Hallo Gerhard, leider hab ich noch keinen Sourcecode für den Comet V3 :( MQTT und OpenHAB wäre auch meine bevorzugte Kombination... Ich schau mir das Arduino Projekt mal an. Das mit dem ESP8266 stimmt so nicht ganz.. Er verbraucht nur viel Energie wenn er permanent mit dem WLAN verbunden ist und rechnet. Im Deep-Sleep kann man ihn sehr lange mit einer Batterie betreiben. In meiner RoomNode betreibe ich einen ESP8266 mit einer 720mAh LiPo Akku der jede Minute aufwacht Raumdaten (Temperatur, Luftfeuchte, Fensterstellung, ...) erfasst diese im MQTT Broker ablegt und dann wieder schläft. Diese muss ich nur jedes Jahr einmal aufladen. Ich denke ein ähnlicher Betriebsmodus für die Thermostate wäre denkbar. Die Aktoren reagieren dann zwar nicht sofort sondern im worst case erst nach 1 Min. aber beispielsweise bei Z-Wave ist es auch so gelöst und es scheint niemand zu stören, zumal das Ansprechverhalten von Heizkörpern eh träge ist... Wenn du Interesse an einem entsprechenden Projekt hast können wir uns darüber gerne mal näher austauschen
Tobt euch aus - keine Garantie für nichts - kein weiterer Support - Assembler...
Knut B. schrieb: > Tobt euch aus - keine Garantie für nichts - kein weiterer Support - > Assembler... Vielen Dank, Knut. Ich finde es wäre höchste Zeit für eine Portierung nach C. Für mich und für viele andere ist das ein Blocker Erweiterungen zu machen, da die "Community" hinter Assembler halt ein Zehntel so gross ist wie die hinter C/C++. Ich wollte schon lange mal ein RFM-Modul dranhängen (habe inzwischen 6 der Regler im Einsatz), aber das Fehlen von Source in C hat mich immer dran gehindert. Der Zeitaufwand mich (wieder) mit Assembler zu beschäftigen ist einfach zu hoch, hab das vor 20 Jahren zuletzt gemacht.
Conny G. schrieb: > Ich finde es wäre höchste Zeit für eine Portierung nach C. Weiß ich doch, aber nicht für mich. Kümmert euch drum. Von ASM nach C ist ohnehin einfacher, als andersrum ;-). Hab aber keine Zeit, mich weiter der Sache anzunehmen. Meine Themostaten laufen, wie ich es brauche, mehr ist nicht...
Knut B. schrieb: > Von ASM nach C ist ohnehin einfacher, als andersrum ;-). Gut, dass du einen Smiley dahinter geschrieben hast. :) Die andere Richtung erledigt innerhalb von Sekunden ein Compiler … Ich hatte vor einiger Zeit mal vor, dein Assemblerprogramm wirklich zu verstehen, aber so viel Zeit hatte ich dann leider doch nicht.
Die andere Richtung erledigt innerhalb von Sekunden ein Compiler … Ja sicher, aber wenn Du C-Code in ein reines Assemblerprogramm wandeln willst, da Du nur Assembler kannst oder willst, dann krigste graue Haare ;-)!
OK, ein lesbares Assemblerprogramm ist natürlich was anderes als das, was ein Compiler gemeinhin rauswirft.
Jepp. Das kann man zwar deuten, aber ohne Marken und Kommentar ist es nur was für Maschinen oder Komplett-Cracks ;-).
Kommentare kannst du dir generieren lassen, bis hin zum kompletten Einbetten des C-Codes. Bringt aber nicht unbedingt viel, weil der Compiler durch die Optimierung auch schon mal im C-Code hin und her hüpft.
Zuerst einmal DANKE an Knut für den Code! Stefan M. schrieb: > Wenn du Interesse an einem entsprechenden Projekt hast können wir uns > darüber gerne mal näher austauschen Ja, würde ich gerne! Aber ich muss dich warnen: bei mir ist's mit programieren nicht weit her; ich bin eher der Code-Schnipsel Sammler und ein paar kleine Anpassungen schaffe ich dann auch selber;-) Wenn du auf Bais des ESP8266 schon einen stromsparenden RoomNode hast so könnte man den doch erweitern?!?
Ja die Idee es nach Arduino zu portieren hätte schon Charme. Der Verlinkte Eintrag auf arduino.cc scheint mir ein wenig sehr wirr und da du wohl auch noch keine Antwort auf die Frage nach den Sourcen bekommen hast, hab ich mal eine Hardware Portierung angefangen. Die erste Version mit der man den Code übersetzen und per avrispmkII auf den Regler spielen kann habe ich unter: https://github.com/geeks-r-us/arduino-cometv3.git als öffentliches Repo abgelegt. Einfach einen Checkout ins Arduino/Hardware Verzeichnis durchführen und die aktuelle Arduino Version sollte Comet als neue Hardware anzeigen. Ich habe die Pin Assigns einfach mal runter geschrieben die kann man aber noch anpassen wenn es anders mehr Sinn macht. Die Timer habe ich auch noch nicht zugewiesen... Der Plan wäre jetzt noch passende Bibliotheken für LCD, Encoder, Motor, etc. zu schreiben (ich hoffe ich verstehe da genug ASM um mir etwas aus den Sourcen von Knut abzuschauen) um dann die Steuerlogik möglichst einfach und flexibel halten zu können. Eine Brücke per SPI oder UART zum ESP um WLAN und MQTT anzusprechen ist dann wieder eine der leichteren Aufgaben :)
Ja, die neue Hardware sehe ich (OS X mit Arduino 1.6.11) > Der Plan wäre jetzt noch passende Bibliotheken für LCD, Encoder, Motor, > etc. zu schreiben (ich hoffe ich verstehe da genug ASM um mir etwas aus > den Sourcen von Knut abzuschauen) um dann die Steuerlogik möglichst > einfach und flexibel halten zu können. Vielleicht hilft das https://github.com/gnbl/sparmatic2011 als Quelle für die LCD Bibliothek?
Angehängte Dateien:
-
IMG_1781.jpg
220 KB -
IMG_1760.jpg
210 KB -
IMG_1768.jpg
210 KB -
IMG_1776.jpg
210 KB -
IMG_1778.jpg
230 KB -
IMG_1780.jpg
240 KB
Nur zur Info: Conrad u.a. verkaufen den "Sygonix HT100" bzw. "Sygonix HT100bt", letzterer mit integriertem BT4.0-Modul. Sygonix ist eine Conrad-Hausmarke. Beide Regler basieren auf dem Thermy(V3). Die Software von Knut läuf auf der Version ohne BT bei mir prächtig. Das Gehäuse ist ein bisschen größer und der Anschluss an das Ventil erfolgt mit Verschraubung (was ich persönlich besser finde als die blöde Klickrastung). Das Display ist etwas größer, was mir mit meinen alten Augen sehr entgegen kommt. Ich habe beide Regler mal aufgemacht und kurz durchgetestet. ISP und JTAG sind nur als Testpads vorhanden. Pads mit UART-Belegung sind vorhanden (an denen hängt bei der BT-Version ein CC2541-BT-Modul). Dann gibt es noch eine rote LED, die in der Original-FW immer dann leuchtet, wenn das Ventil voll geöffnet wird. Hauptsache, es blinkt irgendwas ... ;-). Ein bisschen klobig die Teile, aber mir gefallen sie besser als die Aldis. juju PS: Einen herzlichen Dank an Knut, der die (wohl) einzige bisher lauffähige FW hier eingestellt hat. Ein bisschen Assembler tut ja auch nicht weh.
Gibt es denn schon weitere Fortschritte? Stefan M. schrieb: > Die erste Version mit der man den Code übersetzen und per avrispmkII auf > den Regler spielen kann habe ich unter: > > https://github.com/geeks-r-us/arduino-cometv3.git > > als öffentliches Repo abgelegt. > > Einfach einen Checkout ins Arduino/Hardware Verzeichnis durchführen und > die aktuelle Arduino Version sollte Comet als neue Hardware anzeigen. Ich würde die Umsetzung für Arduino gerne unterstützen, programmieren ist kein Problem, allerdings Zeit... Ich kann die Beispiele in der Arduino IDE Übersetzten und bekomme im Display meines Thermy V3 auch etwas angezeigt. Die Übertragung mit USBasp geht aus der IDE leider (noch) nicht, musste ich von Hand mit avrdude machen. Gibt es weitere Leute, die daran Entwickeln, sodass man sich irgendwie abstimmen kann und und nicht Arbeiten doppelt macht? Gibt es schon Code, den man evtl. mit einfliessen lassen kann? Ein ganz grosses Dankeschön an Knut, der eine funktionierende Firmware aufgebaut hat und den Code hier zur Verfügung stellt. Leider funktioniert die Regelung bei mir mit der Firmware von Knut nicht, er versucht zwar zu regeln, öffnet aber das Ventil nicht weit genug, sodass kein Wasser fliesst. Ich vermute die Offen-Position wird nicht richtig erkannt.
Wenn das Ventil nicht weit genug öffnet, ist der Regler defekt oder von einer Version, zu der die Firmware nicht passt. Zwischen den verschiedenen Versionen, die im Laufe der Zeit auf den Markt kamen, gab es einige Umbelegungen von Pins, sowie einen Controllerwechsel. Das Erkennen des Ventilstößels ist beim Adaptieren verifizierbar anhand der beiden linken Bargraf-Segmente: das erste erscheint, wenn der Freilauf erkannt wurde und das zweite, wenn Kontakt zum Stößel besteht. Prüfe mal das Erscheinen der Segmente.
Hallo Ronny, ich freue mich über jede Hilfe :) Wie bei dir war es bei mir die letzten Wochen ein Zeitproblem neue Dinge zu committen. Ich hab mir aber für die nächsten Tage noch vorgenommen die Motoransteuerung fertig zu bekommen. Damit wären denke ich Hardware voll verwendbar und man kann sich Gedanken über die Funktionen und deren Umsetzung machen. Ich kann in die Arduino Konfiguration gerne noch den USBasp mit aufnehmen. Da ich aber keinen habe würde ich das Testen dir überlassen bzw. du kannst dich natürlich auch selbst daran versuchen. Eine grobe Beschreibung wie du die Konfiguration erweitern kannst findest du hier: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification Ich nehme das dann gerne auch mit ins Repo auf.
Jürgen H. schrieb: > Beide Regler basieren auf dem Thermy(V3). Es gibt hierzu mindestens einen Unterschied: Die Anschlüsse 2 und 3 (serielle Schnittstelle) sind bei der Version mit BT irgendwie verdrahtet, ich habe aber nicht herausfinden können, was da dran hängt. Gruss Robert
Stefan M. schrieb: > Damit wären denke ich Hardware > voll verwendbar und man kann sich Gedanken über die Funktionen und deren > Umsetzung machen. Ok, dann versuche ich mich mal am Menu, falls mir nicht doch noch etwas besseres einfällt (z.B. RTC). Knut B. schrieb: > Das Erkennen des Ventilstößels ist beim Adaptieren verifizierbar anhand > der beiden linken Bargraf-Segmente: das erste erscheint, wenn der > Freilauf erkannt wurde und das zweite, wenn Kontakt zum Stößel besteht. Danke für die Info, habe heute mal noch ein paar Dinge probiert. Die Segmente werden wie von dir beschrieben angezeigt. Allerdings hört man schon kurz nach Start der Adaptionsfahrt, das der Motor schon gegen das Ventil arbeitet, hier schaltet sich dann auch irgendwann das erste Segment ein. Wenn es schwer wird kommt dann das 2. Segment. Die Debug-Werte sind dann nach 2 Regelversuchen folgende (soll 40°, ist 21°): 24 FUZZ 66 POSI 66 VTOP 16 RWAY 384 VBAT Danach passiert nichts mehr. Das ist an einem Danfoss-Ventil. An der FBH im Bad ist am Rücklauf ein Heimeier, habe den NTC an ein Kabel gemacht und den Thermy dort ca. 2 Stunden laufen lassen. Hier funktionierte die Regelung, VTOP war hier 174. Der Stößel der Danfoss Ventile scheint bei "voll offen" ziemlich dicht am Regler zu liegen. Schraube ich den Klemmring des Thermys 1/2 Umdrehung locker, um den Abstand zu vergrößern, so bekomme ich VTOP 181. So funktionierte die Regelung dann auch mehrere Stunden, das kann man so aber nicht dauerhaft betreiben. Habe es auch mit einem 2. Thermy probiert, ein Problem mit der Hardware würde ich daher ausschliessen. Die Thermys wurden auch vor kurzen erst gekauft. Habe auch eins geöffnet, sieht aus wie hier auf den Bilden, weisse Platine.
OK, dann liegt es wohl tatsächlich am Ventil. Der Motor erreicht den Freilauf nicht, da er schon direkt nach dem Anlauf auf den Stößel drückt. Somit wird das Ventil später nicht voll geöffnet. Ich habe auch solche Dannfoss-Ventile, aber da klappt es noch. Der Motor muss etwa 1 Sekunde frei drehen können, so wie die Ventilerkennung jetzt programmiert ist. Im Betätiger des Reglers ist in der Mitte eine kleine Erhebung, vielleicht kannst Du diese wegschleifen. Dadurch müsstest Du genug Luft bekommen.
OK, danke, dann wäre das also klar. Die Idee mit dem abschleifen hatte ich auch schon. Im Moment sind aber alle wichtigen Heizkörper mit Thermys versehen und mit der original Firmware tun die erstmal was sie sollen. Nur würde ich sie gerne fernsteuern... Eine ganz andere Idee wäre, den NTC durch ein Digital-Poti zu ersetzen (z.B. X9C104) und dem Thermy so ferngesteuert über ein Mikrocontroller falsche Temperaturwerte vorzumachen. Dieser Weg wäre sicher einfacher als eine Firmware zu entwickeln die sich fernsteuern lässt. Allerdings wären dann auch die restlichen Funktionen, Display etc. nahezu nutzlos. Hatte schon jemand diese Idee?
Fernsteuern ginge über die USB-Buchse. Ich habe modifizierte Firmwares, die ein Dongle an der USB-Buchse auslesen, welches entweder einen externen NTC abfragt oder ein Funkmodul RFM70 enthält. Dies ist aber mangels WAF nie zur Perfektion getrieben worden aber vielleicht reicht es ja als Idee. Die USB-Buchse stellt immerhin 3 Controllerpins zur Verfügung (SPI), damit kann man schon was anfangen, zum Beispiel synchrone Interfaces oder einen kleinen ATTiny ansteuern...
Wie einige Beiträge bereits andeuten, ist dr Thermy auch mit BT erhältlich. Ich habe einige davon. Ich habe allerdings keine Erfahrung mit der Decodierung des Interfaces zwischen BT und Thermy. Ich werde erst in den nächsten Tagen meinen Logic analyzer starten. Grüsse Robert
Seit heute gibt es bei Lidl den Regler RT200BT mit Bluetooth, die den Thermys sehr ähnlich sehen und auch sind. Habe mir mal 2 gekauft und einen davon zerlegt. Das Display erscheint auf den ersten Blick kleiner als von den Thermys, ist aber gleich groß. Der Bluetooth Chip ist vom Typ DA14580, wenn ich die Leiterbahnen richtig verfolgt habe, ist der an RX TX (PE0 PE1) am 169PA angeschlossen. An den 4 Testpunkten im Batteriefach ist das ISP Interface mit folgender Belegung: Reset, MOSI, SCK, MISO. Zusammen mit den Batteriekontakten (+/-) lässt sich so der 169PA Programmieren ohne das Gehäuse zu öffnen. Die Beispiele aus dem Arduino Projekt funktionieren, Temperatur wird angezeigt und Tasten/Drehrad funktionieren. Die Firmware von Knut lässt sich zwar aufspielen, allerdings piept der Motor nur kurz und es wird OFF angezeigt und bleibt stehen. Vermutlich wird aus irgendeinem Grund ein zu niedriger Batteriestand festgestellt. Es fehlt auch irgendwie der große 100uF Kondensator? Den Bluetooth-Kontroller zu benutzen dürfte aber schwierig werden, Ich kann den Regler nur mit der EUROprog App finden, sonst nicht. Die Regler sind also versteckt, ohne weitere Infos kommt man da nicht ran. Man müsste dann also auch noch an die Firmware des DA14580.
In den Thermy BT-steuerbaren Geräten sind TI CC2541 als BT-Controller verbaut. Datenblatt ebenda verfügbar, Anschlussbelegung folgt gelegentlich.
Ja, versuch mal was du da heraus bekommen kannst. Ich könnte mir aber vorstellen, das die Sygonix HT100BT ebenfalls versteckte BT-Geräte sind und man auch an die Firmware des CC2541 ran muss. Gesteuert werden die ja auch mit der gleichen EUROprog APP. Oder kannst du den Regler außerhalb der APP als Bluetooth-Gerät sehen? Wie Stefan M. schon schrieb, wenn wir erstmal eine eigene Firmware auf Arduino Basis haben, wären solche Erweiterungen ja vergleichsweise einfach machbar. Ich bastle immer wenn es meine Zeit erlaubt am Menu für den Thermy herum, habe schon gute Fortschritte gemacht, evtl. gibt es demnächst mal ein kleines Demo.
Aus anderen Quellen verlautete bereits, dass die Firmware läuft, aber ohne BT.
:
Bearbeitet durch User
Den RT2000BT, der unter der Lidl-Hausmarke "Silvercrest" vertrieben wird, gibt es auch in einer anderen Hardwareversion, von mir gestern in Berlin gekauft (für 18 EUR). Hier werden zwei Platinen verwendet, die von Jürgen hier Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" schon gezeigte Platine mit einem CC2541 darauf (und der Beschriftung "RF-BLE-00-02"), und eine andere, neue Hauptplatine. Die sieht komplett anders aus als die von Ronny hier Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" gezeigte Variante und ist mit "CT_RF 02-00" beschriftet. Der Controller darauf ist der gewohnte Atmega169PA, er ist wie bei Ronny auch auf die Platinenoberseite gewandert. Zusätzliche Kontakte im Batteriefach gibt es keine. Bilder von der neuen Platine folgen, die Grundform ähnelt der hier gezeigten: Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat"
Knut B. schrieb: > Tobt euch aus - keine Garantie für nichts - kein weiterer Support - > Assembler... Wenn ich das Teil auf meine älteren Regler (vermutlich V2) flashe, sehe ich nur noch ein "OFF" nach dem Start, aus dem es nicht wieder herauskommt. Egal, ob ich nun dein Hexfile nehme oder es selbst für einen ATmega169A assemblieren lasse. Die frühere Firmware von dir funktionierte zumindest größtenteils (auch wenn sie den heutigen Tag für einen Freitag hält ;).
Hallo Jörg, gib mal bitte mehr infos, was genau Du worauf geflasht hast. Gerne auch per Mail, um den Thread nicht zu überfrachten. Meine Regler (V2 und V3) spielen alle ganz ordentlich. Wenn Du OFF angezeigt bekommst, passt die verwendete Firmware nicht zum Pinning des Controllers oder aber die Batterien sind leer, was ich aber nicht glaube. Edit: Ach, ich sehe schon, Du hast die V3 Firmware auf einen V2 Regler gespielt. Nee, das geht nicht, weil die anders angeschlossen sind und der Batterietest somit fehlschlägt. Weiterhin liegt die Lichtschranke auf anderen Pins. Du kannst ja mal die Pläne vergleichen und die Sachen selber ändern und den Batterietest erst mal 'rausnehmen. Ich weiß aber nicht wie das bei den alten Reglern mit der Motorstrommessung funktioniert, ich glaube, da war auch noch ein Unterschied. Wenn das Datum nicht zum Wochentag passt, dann ist wahrscheinlich das Jahr falsch eingestellt. Das kann passieren, wenn das EEPROM beim ersten Anlaufen der Firmware auf 0xFF steht und man das erste Mal das Jahr einstellt und die Begrenzung auf 100 noch nicht greift. Der Kalender funktioniert nur bis 2099.
:
Bearbeitet durch User
Knut B. schrieb: > Du hast die V3 Firmware auf einen V2 Regler gespielt. Nee, das geht > nicht, weil die anders angeschlossen sind und der Batterietest somit > fehlschlägt. OK, ist das in der Firmware irgendwie als .ifdef gelöst, oder sind deine Firmware-Sourcen für V2 und V3 in der Tat völlig separat? Edit: die Frage kann ich mir nach einem Vergleich deiner alten V2-Sourcen und der oben geposteten für den V3 selbst beantworten: die sind ziemlich unterschiedlich.
:
Bearbeitet durch Moderator
Jojo, das sind 2 unterschiedliche Epochen, bei V3 hatte ich die Menü-Steuerung noch überarbeitet, weil die alte ziemlich frickelig war. Die Motoransteuerung wurde um die Strommessung erweitert und die Pinumbelegung wurde eingepflegt. Dann hatte ich noch mit externen Modulen zur Fernsteuerung herumgespielt, aber das ist leider nie ganz fertig geworden... :-(
Dann melde ich mich auch mal wieder zu Wort. Nach einem ärgerlichen Hardwaredefekt über die Feiertage habe leider nicht so viel von dem Dingen geschafft, die ich mir vorgenommen habe :( Was ich noch geändert habe: Ich habe noch eine Hardware für den Zero+ hinzugefügt und die Input Bibliothek angepasst, so dass sie nun auf beiden Plattformen die vorhandene Hardware unterstützen. So ist es dann auch einfacher noch eine Variante mit Bluetooth zu unterstützen. Woran ich aber immer noch hänge ist die Motorsteuerung. Der Motor will sich einfach nicht bewegen. Ich habe den aktuellen Stand eingecheckt und ein minimales Beispiel für die Motorsteuerung dazu gepackt. Würde mal jemand drüber schauen / testen ob ich da einen Denkfehler drin habe oder ob ich nach einem Hardwareproblem suchen muss?
Ich werde es mir bei Gelegenheit mal ansehen, wird aber frühestens am Wochenende etwas. Um ein Hardwareproblem auszuschliessen könntest du ja mal Knuts Firmware flashen. Ich meine auch irgendwo gelesen zu haben, das man sich die Transistoren der H-Brücke zerstören kann, wenn man diese falsch ansteuert. Mit dem Menu bin ich leider auch noch nicht viel weiter gekommen. Anbei aber mal eine kleine Demo, sollte auf V3 Kompatiblen laufen. In MODE, FENS und OFFS lassen sich mit OK weitere Ebenen/Funktionen aufrufen. Das Menu hängt am Interrupt und basiert auf Tabellen, also keine komplizierten switch ... case. Den Quellcode gibt es natürlich auch noch, sobald ich weitergekommen bin.
Hi, sorry for writing in English, but I cannot speak German (used google translator to sort of understand last few posts). My question is simple: is there a way how to remotely communicate with RT2000 or RT2000BT? And I don't mean that euroProg application, I mean custom communication, with messages like "open the valve to xx %", "get current temperature", "get battery level" (well, that's almost everything I need). So either via 2.4GHz or 433/866 MHz, with battery life at least 6 months. Is there such solution? Thanks
We are working on such a solution, but due to lack of time it maybe need some months before we are getting it to work. At least for 433/866MHz or WLAN(ESP8266) it should be possible. But for the built in Bluetooth I'm sceptical, because of the BT device of the RT2000BT is "undiscoverable", so we have to change the firmware of that BT device too. But it would be great, if you can help out for programming.
I'd really like to help, but I am afraid I am noobie in this area. I can code, C is fine for me, but I am just starting "doing" into the hobby (for which we have great czech word 'bastleni' coming from German - basteln ;), I have my first few wemos d1 minis on the way and I'll be doing my first tests with it. The reason I am asking here is that here, in Czech Republic, they have the Silvercrest valves on sale starting next monday, for some 12 EUR, so I am considering buying few (3 pcs) and give them a try. The next less expensive solution for me is eQ-3 Max cube + valves which is about 150 EUR... But I got quite OT now. I will follow this topic and if I can help with anything, I'll try. Have a good day
Angehängte Dateien:
-
K1002692.jpg
230 KB -
K1002693.jpg
230 KB
Anbei die am 14. schon angekündigten Bilder der neuen "Thermy"-Variante, die es vor nunmehr zwei Wochen bei Lidl unter der Eigenmarke "Silvercrest" zu kaufen gab. Die aufgesteckte BT-Platine entspricht exakt der von Jürgen hier Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" gezeigten, daher verzichte ich auf weitere Bilder davon.
Stefan M. schrieb: > Der Motor will sich einfach nicht bewegen. Habe mir den Code nun mal angesehen, der Motor läuft bei mir. Der geänderte Code ist im Anhang. Habe mich bei der Ansteuerung der Pins an Knuts Code orientiert. Anbei auch noch ein lauffähiges Beispiel mit meinem Menu, im DBUG gibt es nun MOTO und man kann mit dem Rad den Motor steuern und mit OK wieder stoppen. Das verwendet jedoch anderen Code, es werden einfach die Pins je nach Zustand gesetzt. Testen bitte auf eigene Gefahr. Einen Interrupt über den Sense-Pin scheine ich jedoch nicht zu bekommen. Ich denke die Motorsteuerung könnte man noch weiter abstrahieren. Vielleicht mit einer Klasse "Valve", welche im Wesentlichen nur die Funktionen open() und close() kennt. Als Parameter dann nur einen Wert, um wieviel geöffnet/geschlossen werden soll. Wofür ist eigentlich der 1K Widerstand an PE5 des Thermy V3?
Danke für deinen Test Ronny. Ich hab deine FW mal aufgespielt - dein Menü sieht gut aus :) leider keine Reaktion im Motor Menüpunkt. Ich hab die Anpassungen übernommen aber leider das selbe... vermutlich hab ich die Brücke gegrillt.. werde mich mal auf die suche nach passendem Ersatz umschauen. Den Interrupt habe ich nochmal raus genommen um die Fehlerquellen zu suchen. Hier wollte ich auch noch etwas schöneres machen als die ISRs in der ino-Datei. Das wäre auch mein Plan gewesen der Motorklasse nur wenige public-Funktionen für die Positionierung zu geben. Das Problem ist noch, dass die Motorsteuerung evtl. ja asynchron zum Rest ausgeführt und überwacht werden sollte.
Hast du es mit Batterien probiert? Am ISP ohne Batterien geht es bei mir auch nicht und zum testen deiner Hardware könntest du mal die FW von Knut nehmen. Ich stelle mir die Motor bzw. Valve Klasse anders vor. Die Regelung muss ja einfach nur sagen, um wieviel das Ventil geöffnet bzw. geschlossen werden soll, also z.B. 10%, 20%, 50% oder nur 1% (evtl. normiert auf 255). Wenn der Motor also schon 50% offen ist und die Regelung sagt open(20) dann ergibt das 70%. Somit muss die Regelung nicht wissen, wie der Motor funktioniert, sie muss nicht mal wissen wie weit die Öffnung aktuell ist. Wenn es schon 100% sind und die Regelung fordert nochmals open(20), dann bleibt es eben bei 100%. Wenn es hier nicht zu starken Überschwingern kommt oder zu stark auf die Batterie geht, sollte das reichen. Evtl. könnte man sich somit sogar das Adaptieren sparen. Ein Problem im Code habe ich noch entdeckt: in motor.cpp sollte in stop() der komplette Term für MOTOR_DDR geklammert werden (wie darunter bei MOTOR_PORT). Stefan M. schrieb: > Das Problem ist noch, dass die Motorsteuerung evtl. ja > asynchron zum Rest ausgeführt und überwacht werden sollte. Darüber habe ich auch schon nachgedacht, hierfür sind Klassen eben nicht gut geeignet. Vielleicht versuche ich mal zu verstehen, wie Knut das gelöst hat.
Stefan M. schrieb: > Das Problem ist noch, > dass die Motorsteuerung evtl. ja asynchron zum Rest ausgeführt und > überwacht werden sollte. Das ist zwingend. Die Lichtschranke muss, solange der Motor dreht (auch nach dem Abschalten, da der Motor nachläuft) permanent überwacht werden, sonst gehen Zählpulse verloren. Ebenso muss der Strom überwacht werden, um das geschlossene Ventil festzustellen. Ronny schrieb: > Somit muss die Regelung nicht wissen, wie der Motor > funktioniert, sie muss nicht mal wissen wie weit die Öffnung aktuell > ist. Wenn es schon 100% sind und die Regelung fordert nochmals open(20), > dann bleibt es eben bei 100%. Wenn die Regelung nicht weiß, wie weit das Ventil offen ist, wird sie nicht vernünftig funktionieren. Es wird heftige Temperatur-Überschwinger geben und der Motor wird ständig lange Wege fahren, was die Batterien leer saugt und die Nerven des Zimmerbewohners strapaziert. Ich habe lange an der Regelung getüftelt und habe bei eingeschwungener Raumtemperatur kaum Regeleingriffe und wenn, dann nur ein paar kurze Dreher kleiner 1 Sekunde Laufzeit vielleicht 1x pro halbe Stunde.
Hallo zusammen, bin sehr erfreud auf diesen Thread gestossen zu sein. Finde es sehr bewundernswert wie Knut Ballhause seit Oktober 2009 am Ball bleibt und sich regelmäßig hier zu Wort meldet. Am besten gefällt mir, das er die Firmware in ATMEL AVR Assembler geschrieben hat, was der Hauptgrund dafür war, mich durch diesen Wust an Informationen durchzuarbeiten. Danke dafür. Da unter anderem bei den Heizkosten am meisten in Punkto Energiekosten eingespart werden kann, hatte ich überlegt die " mechanischen " Thermostatköpfe durch elekronische zu ersetzten, da man sagt das 1°C Raumtemperaturabsenkung ca. 6% Heizenergie einspart. Ob das in einem sechs Parteien Miethaus, das mit Fernwärme versorgt wird Sinn macht weiß ich nicht. Auf jeden Fall habe ich mir einen solchen von ELV ( ETH comfort200 ) ausgeliehen und beim durchlesen der Beschreibung feststellen müssen, das ich damit nicht wirklich was anfangen kann, da ich keine allgemeine Wochenarbeitszeit von Mo bis Fr zur immer gleichen Zeit am selben Wochentag habe. Es besteht jedoch schon ein Rhytmus. Deshalb war ich auf der Suche nach etwas selbstprogrammierbaren und bin hier hängen geblieben. Allerdings stelle ich mir das ziemlich schwierig vor einen Schichtrhytmus zu programmieren, der zur Zeit folgendermaßen aussieht, sich aber auch alle Jahre mal ändert. F = Früh ; M = Mittag ; N = Nacht; # = Frei. F;F;M;M;N;N;N; #;#; F;F;M;M;M;N;N; #;#;#; F;F;M;M;N;N; #;#;#; usw. Dazu meine erste Frage : " Wie stelle ich so etwas in Assembler an ? ". Ich habe gerade mal etwas mehr als AVR ASM-Grundlagen und würde daher gerne mal ein Programm sehen, das so etwas benutzt, also das einen Kalender programmiert hat. Wenn ich bisher alles richtig verstanden habe ist der Comet von EuroTronic, sowie der ALDI Thermy ( Version3 ) und der Conrad Sygonix HT100 von der Elektronik her baugleich und das verlinkte ASM-Programm von Knut Ballhause läuft auf allen dreien. Beitrag "Re: Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat" Da mir der von Conrad ( Sygnonix HT100 ) am besten gefällt, ich jedoch befürchte das sich die silberfarbenen Absetzungen ( Deckel sowie Einstellrad ) mit der Zeit abnutzen und dann schäbig aussehen, würde ich gerne von Jürgen Hamerski oder jemand anderem, der diesen Heizungsthermostat besitzt, wissen ob diese Absetzungen aus diesem silberfarbigen Material sind oder nur eine Lackfarbe, was praktisch meine zweite Frage bisher wäre. Bernd_Stein
:
Bearbeitet durch User
Bernd S. schrieb: > hatte ich überlegt die " mechanischen " > Thermostatköpfe durch elekronische zu ersetzten, da man sagt das 1°C > Raumtemperaturabsenkung ca. 6% Heizenergie einspart. Ob das in einem > sechs Parteien Miethaus, das mit Fernwärme versorgt wird Sinn macht weiß > ich nicht. Energie zu sparen ist immer sinnvoll, denn was nicht entnommen wird, muss an anderer Stelle nicht erzeugt werden. Wenn die Fernwärme aus Abwärme eines industriellen oder organischen Vorganges gewonnen wird, ist der Nutzen der Einsparung hingegen nicht gegeben.
Bernd S. schrieb: > da ich keine allgemeine > Wochenarbeitszeit von Mo bis Fr zur immer gleichen Zeit am selben > Wochentag habe. Es besteht jedoch schon ein Rhytmus. Das ist eine interessante Aufgabe. Ich würde das über verschiedene Blöcke programmieren. Die Zeiten für die einzelnen Schichten würde ich in Unterblöcken ablegen. Damit kann man sich dann Wochenmakros definieren, die sich auch gelegentlich schnell umbelegen lassen, wenn sich die Schichten vorhersehbar ändern. Aus den Wochenmakros wiederum könnte man ein Monatsmakro (nicht unbedingt kalendarisch, sondern genau 4 Wochen) erstellen. Durch die Verschachtelung der verschiedenen Ebenen kommt man mit dem recht begrenzten Display noch ganz gut zurecht. Die Makrodefinitionen würde ich in verschiedene Menüpunkte der Menügrundebene legen, so dass man die einzelnen Makro-Ebenen schnell erreichen und ändern kann, ohne die über- oder untergeordnete Ebene gleich mit zu verändern. So kann man einzelne Elemente tauschen (Kollege ist krank oder möchte die Schicht tauschen), ohne das ganze Gefüge durcheinanderzubringen.
Ich arbeite gerade an der Motorsteuerung, deshalb hier paar kurze Infos, auch um zu vermeiden, das jemand an der gleichen Stelle arbeitet. Ich bekomme nun den Interrupt von dem Reflexkoppler, kann die Impulse zählen, kann den Strom messen und habe auch schon einen einfachen Test, um beim Anschlag den Motor abzustellen.
Knut B. schrieb: > Wenn die Fernwärme aus Abwärme eines industriellen oder organischen > Vorganges gewonnen wird, ist der Nutzen der Einsparung hingegen nicht > gegeben. > Tja, das weiß ich leider nicht und ob ich wirklich Heizkosten in Zukunft sparen werde, weiß ich auch nicht, da ich die erste Heizperiode in dieser Wohnung verbringe. Knut B. schrieb: > Das ist eine interessante Aufgabe.... > Durch die Verschachtelung der verschiedenen Ebenen > kommt man mit dem recht begrenzten Display noch ganz gut zurecht. Die > Makrodefinitionen würde ich in verschiedene Menüpunkte der > Menügrundebene legen, so dass man die einzelnen Makro-Ebenen schnell > erreichen und ändern kann, ohne die über- oder untergeordnete Ebene > gleich mit zu verändern. So kann man einzelne Elemente tauschen (Kollege > ist krank oder möchte die Schicht tauschen), ohne das ganze Gefüge > durcheinanderzubringen.... > Also, mich hast du schon mal durcheinandergebracht ;-). Von Makros habe ich schon gelesen. Deine angesprochenen Ebenen verwirren mich dermaßen, das ich das für mich zur Zeit für eine unlösbare Aufgabe halte. Das einzige was ich in Bezug auf Kalender bzw. Rhythmus in AVR-ASM gefunden habe ist folgendes : Beitrag "Berechnung Wochentag, Kalenderwoche etc. in AVR-ASM!" Von dem ich allerdings gar nicht weiß, ob ich damit als Grundlage überhaupt was anfangen kann, um den oben angegebenen Schichtrhythmus realisieren zu können. Bernd_Stein
Das mit den Ebenen ist ganz einfach: 1. Ebene: Schicht Hier trägst Du die Heizzeiten ein, passend für die jeweilige Schicht Früh, Tag, Spät, Nacht 2. Ebene: Wochentag Hier gibst Du an, an welchem Wochentag Du welche Schicht hast. Dies geht natürlich nur, wenn die Woche einem bestimmten Muster folgt Alternative Ebene 2: Schichtmuster Du legst so viele Tage in Ebene 2 an, bis sich ein Turnus wiederholt oder eine Musterfolge abgeschlossen ist. Du brauchst so viele Felder, wie Du verschiedene Muster hast. 3. Ebene: Turnusabfolge Hier gibst Du die Reihenfolge der sich wiederholenden Muster an. Ein Datum musst Du bei der ganzen Geschichte gar nicht eingeben, weil Deine Arbeit sich mit hoher Wahrscheinlichkeit nicht an einem Datum, sondern an aufeinanderfolgenden Arbeits- unf Frei-Tagen orientiert.
Bin leider nicht sehr viel weitergekommen in den letzten Tagen. Anbei aber mal eine kleine Demo, habe darin auch mal schnell eine sehr primitive Regelung implementiert. Das taugt so natürlich nix und soll nur Zeigen, was bisher so geht. Wer es probieren will (natürlich auf eigene Gefahr), hier eine kurze Beschreibung der Menupunkte: ADAP - hier kann der Regler geöffnet und installiert werden. Nach drücken von OK wird das Ventil geschlossen und die Endposition wird erkannt. Der offene Ventilstössel wird allerdings noch nicht erkannt. TEMP - Hier kann die Zieltemperatur eingestellt werden REGL - Wenn dieser Menupunkt aktiv ist, läuft die Regelung und die Temperatur des NTC wird angezeigt und alle 30s aktualisiert. DBUG - Hier kann mit dem Drehrad der Motor gesteuert werden und die Impulse werden angezeigt. Den Quellcode gibt es später, ist noch zu experimentell. Bei Gelegenheit werde ich auch testen, ob es auch mit dem von mir gezeigten Lidl Regler RT200BT funktioniert.
Knut B. schrieb: > Das mit den Ebenen ist ganz einfach: > Ich danke dir erstmal für deinen Vorschlag. Leider begreife ich dies jedoch noch nicht, so das ich denke erstmal diesen Kurs durchzuarbeiten : http://www.weigu.lu/tutorials/avr_assembler/index.html In der Zeit hoffe ich, das es auch mal ein ASM-Programm zum Conrad Sygonix HT100BT ( Bluetooth-Modell ) geben wird oder ist DECT Hobbymäßig leichter zu programmieren ( Comet DECT )? https://www.youtube.com/watch?v=csXViC6H4Nw https://www.youtube.com/watch?v=O8TwVqa0og0 Bernd_Stein
Habe nun ein wenig Code aufgeräumt, hier nun also der Code für das Menu mit Beispielen. Den Code fürs LCD habe ich auch angepasst: Interrupt aktiviert und das Grad-Symbol hinzugefügt. Ob das mit dem Interrupt eine gute Idee so ist weiss ich nicht, können wir später entscheiden. @ Stefan M. Kannst du es bitte in dein Repository tun? Den Code für den Motor gibt es auch noch, sobald ich ihn aufgeräumt habe.
@ Ronny: Hab es ins Repository aufgenommen. Und habe auch die Transistoren für die Reparatur der H-Brücke hier liegen. Ich hoffe ich kann dann auch wieder zum Projekt beitragen.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.