Feedback/Unterstützung TRQ 21 - Stetigreglung mit HM-LC-Sw4-Ba-PCB

Begonnen von Gerrit74, 30 September 2016, 13:41:08

Vorheriges Thema - Nächstes Thema

Gerrit74

Moin.

Ich habe hier die Situation das sich der TRQ 21 zur Regelung unserer antiken Junkers-Therme verabschiedet hat. Nun, hat mir eh nicht gefallen das Ding.

Ich wollte jetzt keinen Ersatz beschaffen, sondern gleich eine eigene Lösung finden. Habe also man gemessen und recherchiert. Von der Theme werden an den TRQ 26V DC geliefert. In dem TRQ sitzt ein Fühler und dieser sorgt dafür das entweder 22,56 V(ist == soll) an die Therme zurückgeliefert werden, oder 1,4V (Vollast), oder 19V (ist hat soll gerade unterschritten) oder halt irgendwas zwischen 19V und 1,4, je nachdem wie groß die Abweichung zwischen ist und soll denn nun ist.

Meine Idee:
Ich benutze Sw4 um vier Zustände zu provozieren: Aus, Vollepulle, warm und wärmer, also 22,56V; 1,4V; ~19V; 12V.
Hierzu wollte ich mir eine Platine mit ein paar Widerständen bestücken die ich als Voltagedivider nutze, um diese Spannungen herzustellen. Die Voltagedivider werden dann über die vier Ausgänge des Sw4, je nach Situation, geschaltet/genutzt. Den Voltagedivider für die 19V würde ich mit einem Poti zur Feinjustierungrealisieren.
Um den Sw4 mit Energie zu versorgen, kommt ein weiterer Voltagedivider zum Einsatz. Für 30mA sollte das okay sein, oder?
Ansonsten verteile ich ein paar von den Funk-Stellantrieben im Haus, nutze die gemessenen Temperaturen etc. pp......

Was haltet Ihr davon?

LG
Gerrit

Beta-User

Hi Gerrit,

habe auch eine Junkers (aber vermutlich etwas neuer als Deine) und schlage mich auch mit der Frage rum, wie man das Ding (besser) eingebunden bekommt. Grundsätzlich kommt mir das vorgestellte Prinzip gangbar vor, so was ähnliches macht ja auch die im Wiki vorgestellte Ethersex-Lösung und das hier: https://forum.fhem.de/index.php/topic,47114.0.html (bevor ich für letzteres aber Werbung mache, möchte ich Tests haben, ob das von der elektrischen Seite verläßlich geht (25 V Potential für 5V-Elektronik...)).

Allerdings kommen mir 4-5 Widerstands-/Regelzustände eher wenig vor. Warum nicht die E6-Variante? Wegen des Rückkanals über HM oder Ängsten bzgl. Ausfallsicherheit?

Gruß,

Beta-USer
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gerrit74

Was meinst du mit e6-Variante? Ansonsten glaube ich das 4 Zustände schon mal doppelt so viele Zustände sind als viele andere Regler überhaupt haben ...

LG
Gerrit

Beta-User

Zitat von: Gerrit74 am 30 September 2016, 15:02:33
Was meinst du mit e6-Variante?
e6=gebräuchliche Abkürzung von Ethersex, jedenfalls wenn ich das meinerseits richtig verstanden habe ::).

Zitat von: Gerrit74 am 30 September 2016, 15:02:33
Ansonsten glaube ich das 4 Zustände schon mal doppelt so viele Zustände sind als viele andere Regler überhaupt haben ...
Stimmt zwar vermutlich 8), aber warum sich mit wenig zufrieden geben, wenn deutlich mehr (vollständige Stetigregelung) möglich ist (wenn auch mit etwas mehr Aufwand).
Meine Gedanken dahinter: Wenn Deine Therme modulieren kann (was wohl der Fall ist), kannst Du damit Spitzen glätten und evtl. Gas+Einschaltvorgänge sparen. Das macht v.a. dann Sinn, wenn Du deutlich weniger Heizbedarf hast als zu der Zeit, als die Therme installiert wurde (bei mir ausgelöst durch neue Fenster).
Das Grundproblem bleibt aber ähnlich: die Ermittlung, wieviel Bedarf überhaupt besteht.

Gruß,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gerrit74

Moin,

bin bereits vor ein paar Tagen über den Schaltplan mit der Stetigregelung gestolpert. Ich habe es allerding verworfen, da ich ja keine kontinuierliche Messung habe, sondern nur in Intervallen erfahre wie es um die Temperatur bestellt ist. Also würde es trotz A/D-Wandler nur zu Stufen führen und daher finde ich, das der Aufwand nicht im Verhältnis zum Ergebnis steht. Außerdem müsste ich mich in diverse neue Themengebiete einarbeiten, Bauteile besorgen etc. pp.
Aktuell habe ich aber bereits diesen 4-kanal-Switch ...

Was den Bedarf anbelangt: na den Bedarf ermittel ich doch über die Daten der Heizungsregler ... oder habe ich was nicht verstanden?

LG
Gerrit

Beta-User

Zitat von: Gerrit74 am 01 Oktober 2016, 11:21:50
...ja keine kontinuierliche Messung habe, sondern nur in Intervallen erfahre wie es um die Temperatur bestellt ist. Also würde es trotz A/D-Wandler nur zu Stufen führen...
m.E. sollte sich das entkoppeln lassen, also nach dem Muster: Temperatur des Vorlaufs oder Änderung des Heizbedarfs über der Zeit messen/feststellen und daraus den optimalen Einstellungswert des Widerstands/Spannungswerts ableiten (der dann -mindestens- bis zur nächsten Messung gilt). Du hättest halt mehr ("unendlich viele Zwischen-") Stufen und könntest im Idealfall die "Stufe" wählen, die den Heizbedarf gerade so decken kann (=kontinuierlicher Brennerbetrieb auf heizungstechnisch niedrigstmöglicher Stufe). (Achtung: evtl. "Notbetriebsmodus" definieren, wenn zu lange keine Info kommt, was gelten soll=FHEM ist nicht verfügbar).
Zitat von: Gerrit74 am 01 Oktober 2016, 11:21:50
Außerdem müsste ich mich in diverse neue Themengebiete einarbeiten, Bauteile besorgen etc. pp.
Aktuell habe ich aber bereits diesen 4-kanal-Switch ...
Ok, das ist verständlich und für einen schnelle Zwischenlösung finde ich das mit dem Switch ist auch eine gute Idee.

Zitat von: Gerrit74 am 01 Oktober 2016, 11:21:50
Was den Bedarf anbelangt: na den Bedarf ermittel ich doch über die Daten der Heizungsregler ... oder habe ich was nicht verstanden?
Klar, aber interessant ist ja, welche Info man daraus auf welchem Weg gewinnt (HCS, VALVES...?) und welche Schlußfolgerung man daraus zieht (=Heizstufe, "nur" "An" oder "Aus"). Nur An, Aus, Tag, Nacht und irgendwas dazwischen finde ich halt wenig, weil es faktisch zu einem häufigeren Ein- und Ausschalten führen wird als "erforderlich".
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gerrit74

Moin,

ZitatKlar, aber interessant ist ja, welche Info man daraus auf welchem Weg gewinnt (HCS, VALVES...?) und welche Schlußfolgerung man daraus zieht (=Heizstufe, "nur" "An" oder "Aus"). Nur An, Aus, Tag, Nacht und irgendwas dazwischen finde ich halt wenig, weil es faktisch zu einem häufigeren Ein- und Ausschalten führen wird als "erforderlich".

Also aktuell ist es ja so: die Heizung schaltet aus wenn IST == SOLL. Wenn IST < SOLL, geht die Heizung in den Modus einwenignachlegen. Ist IST deutlich kleiner als SOLL, gibt es ein wenig mehr Schub usw. usf.... Der Tag/Nach-Krempel ist ja nur Tag-SOLL != Nacht-SOLL, also i.d.R. Tag-SOLL - 3-4°C ... mehr nicht.

Ich habe aktuell noch keinen Grund gefunden, warum ich die Valve-Stellung überhaupt auswerten sollte. Eigentlich reicht mir doch der gemessene Temperatur-Wert(IST) und der programmierte SOLL-Wert. Da frage ich einfach für alle Regler ab und wenn mir einer vermeldet das es Diskrepanzen gibt, dann werfe ich die Heizung an ... fertig.

So fancy dinger wie Vorlauf messen ... keine Ahnung ob meine 30 Jahre alte Gas-Therme sowas macht. Was das Ding aber macht, es verbraucht nicht gerade wenig Strom für die Umwälzpumpe, da gibt es heute effizientere Pumpen. Daher hätte ich jetzt auch keine Lust auf möglichst lange Brenndauern und entsprechendes Pumpen.

Andererseit bin ich auch kein Fachmann auf dem Gebiet ... hmm

LG
Gerrit

Beta-User

Zitat von: Gerrit74 am 02 Oktober 2016, 10:05:34
Was das Ding aber macht, es verbraucht nicht gerade wenig Strom für die Umwälzpumpe, da gibt es heute effizientere Pumpen. Daher hätte ich jetzt auch keine Lust auf möglichst lange Brenndauern und entsprechendes Pumpen.
...das Problem kenne ich, das haben die 2003 (!) immer noch nicht (wesentlich) besser gemacht (60 Watt oder so...). Da man die in der Therme direkt verbaute Pumpe nicht einfach tauschen kann (Betriebserlaubnis!), aber zwischen 3 Stufen umschalten, nutze ich diese Option (ist aber tricky, die vom Servomotor anzusteuernden Positionen müssen genau stimmen, sonst geht das Ding aus!!! Daher eher nicht zur Nachahmung empfohlen!) Das manuell zu machen, also insbesondere in der Übergangszeit die Pumpe nur auf niedriger Stufe laufen zu lassen, war die Empfehlung meines Heizungsbauers; das ist aber auch nur bedingt empfehlenswert und führt - je nach Wetter - zu "anderen" Problemen, wenn alle Bewohner innerhalb einer kurzen Frist duschen, bei nur knapp 130l Speichervolumen  ;).

Zitat von: Gerrit74 am 02 Oktober 2016, 10:05:34
Also aktuell ist es ja so: die Heizung schaltet aus wenn IST == SOLL. Wenn IST < SOLL, geht die Heizung in den Modus einwenignachlegen. Ist IST deutlich kleiner als SOLL, gibt es ein wenig mehr Schub usw. usf....
OK, aber das ist ja das, was die Therme "sowieso" macht, oder beschreibst Du hier etwas anderes?

Zitat von: Gerrit74 am 02 Oktober 2016, 10:05:34
Ich habe aktuell noch keinen Grund gefunden, warum ich die Valve-Stellung überhaupt auswerten sollte. Eigentlich reicht mir doch der gemessene Temperatur-Wert(IST) und der programmierte SOLL-Wert. Da frage ich einfach für alle Regler ab und wenn mir einer vermeldet das es Diskrepanzen gibt, dann werfe ich die Heizung an ... fertig.
Danke, das wollte ich wissen. Irgendwie mußt Du ja in FHEM die Entscheidung zu treffen, ob die Heizung jetzt an oder aus sein soll. Das "digital" zu regeln macht m.E. Sinn, wenn Du den Rest von der Therme entscheiden läßt. An der Stelle möchte ich jetzt eigentlich ansetzen und dann über eine etwas weniger digitale Entscheidung über den tatsächliche Wäremebedarf direkt in die Vorlauftemperatur (Widerstand) und Wassermenge (Servo+Pumpe) eingreifen, weiß aber noch nicht, ob bzw. inwieweit das wirklich Sinn macht. Bei letzterem denke ich schon, das konnte ich an den Ausschlägen der diversen Temperaturkurven im letzten Winter gut nachvollziehen; ich habe HM-Thermostate in den meisten Zimmern und messe u.A. Vor- und Rücklauf- sowie Kesselausgangstemperatur.

Zitat von: Gerrit74 am 02 Oktober 2016, 10:05:34
So fancy dinger wie Vorlauf messen ... keine Ahnung ob meine 30 Jahre alte Gas-Therme sowas macht.
Derzeit komme ich an die von der Heizung selbst erfaßten Daten (noch) nicht direkt dran, sondern habe einige 1Wire-Sensoren an den entsprechenden Stellen plaziert; das ist nicht besonders "fancy", aber informativ ;).
Ich bin ziemlich sicher, dass sie mindestens die Temperatur am Wasseraustritt (Kessel) mißt, jedenfalls bei mir gibt es da ein Kabel und auch eine außentemperaturabhängige Steuerung funktioniert m.E. nur, wenn die Therme den Wäremoutput irgendwie kontrolliert; sonst wäre das mit der Modulation auch komplette Makulatur...
Hier würde meine "neue" Steuerung ansetzen, nämlich den typisiert vom Hersteller der Therme als Startwert aus einer Heizkurve entnommen Wert der Vorlauftemperatur aus dem bekannten Heizbedarf im Haus zu ermitteln. Oder beim Anheizen sogar erst mal geringfügig weniger zur Verfügung zu stellen, damit sich die Wärme möglichst gleichmäßig verteilt. Mal sehen, das ist vermutlich ziemlich tiral&error (daher die Frage, ob bzw. wie Du die Aufgabe gelöst hast bzw. lösen willst).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors