39_VALVES - kleines Helferlein um Positionen von Heizungsthermostate auszuwerten

Begonnen von epsrw1, 18 Juni 2014, 05:05:00

Vorheriges Thema - Nächstes Thema

Beta-User

OK, Danke erst mal für die Interessensbekundungen!

Das mit dem "virtuellen Leitraum" scheint ja doch nicht komplett uninteressant zu sein ;D ...

Dass das grade wetterbedingt nicht mehr allzu hoch im Kurs steht, liegt "in der Natur der Sache", aber vermutlich werden die Temperaturen irgendwann auch wieder so frostig wie das Klima zu größeren Gas-Lieferanten, und das Interesse am Erkennen des eigenen Spar-Potentials dürfte tendenziell sogar größer sein wie bisher...

Wie dem auch sei, eine gepackagte Version ist grade im Test und kommt dann bei Gelegenheit auch hier als Angebot, und wenn jemand noch was vermißt an dem Modul, wäre jetzt auch die Gelegenheit, das einzukippen ;) .

Ansonsten hatten wir sein Ende Februar ca. 500 Neuanmeldungen im Forum, von daher glaube ich nicht unbedingt, dass das allgemeine Interesse erlahmt ist (es wundert mich eher, dass es so viele sind, weil doch zu fast allem "alles geschrieben" ist...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 07 Juli 2022, 12:37:29
eine gepackagte Version ist grade im Test und kommt dann bei Gelegenheit auch hier als Angebot, und wenn jemand noch was vermißt an dem Modul, wäre jetzt auch die Gelegenheit, das einzukippen ;) .
Da heute zum einen der erste leichte Morgennebel hier rumgewabert ist und meine Junkers jetzt via CAN->ESP32->MQTT Daten liefert und auch gesteuert werden kann (https://www.mikrocontroller.net/topic/81265 bzw. https://github.com/Neuroquila-n8fall/JunkersControl (mit  geringfügigen Tweaks)), greife ich den Ball mal wieder auf und liefere erst mal die angekündigte package-Version. (Soweit ich mich entsinne: keine funktionalen Änderungen zu meinem letzten Stand).

Wird vermutlich etwas dauern, bis mir klar ist, wie man das am effektivsten zusammenpuzzelt, aber bei einem "Heizkörper-only"-beheizten Gebäude dürfte nach den Berichten von Dave G. im Mikrocontroller-Forum die Variante mit dem "Leitraum" das Mittel der Wahl sein. VALVES rückt daher in meiner persönlichen Prioritätenliste ziemlich nach vorne ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Maui

Jetzt wo die Temperaturen fallen (und die Gaspreise steigen) will ich mich auch mal mit valves bzw. Dem virt. Leitraum beschäftigen.
Allerdings bin ich mir nicht sicher, ob es in meinem Fall nicht sinnvoller wäre ein wenig vorher anzusetzen.
Ich regele nämlich all meine Thermostate mit PID20 und schubse die Ventile nur frühestens alle 15 Min (1% Regel, Verhindern von "Ventil-Zappeln").
Kann ich valves vielleicht einfach so benutzen, dass es statt ventil-devices pid20-devices nutzt und mit deren actuationCalc-reading ein virt. Leitraum erstellt wird?
Wie ändert ihr/du eigentlich die Vorlauf-Temp? Verstellst du Neigung und Niveau oder kommst du direkt an die Vorlauf-Temp?

Edit: hab valves mal eingespielt und zum Test 2 pids auf die Liste gesetzt.
Zur sauberen Berechnung eines gewichteten Mittels müsste ich wohl jetzt noch mit userReadings das actuationCalc reading wie actuation in den Bereich zwischen 0 und 100 begrenzen.

Beta-User

Zitat von: Maui am 16 September 2022, 14:11:25
Kann ich valves vielleicht einfach so benutzen, dass es statt ventil-devices pid20-devices nutzt und mit deren actuationCalc-reading ein virt. Leitraum erstellt wird?
[...]
Edit: hab valves mal eingespielt und zum Test 2 pids auf die Liste gesetzt.
Zur sauberen Berechnung eines gewichteten Mittels müsste ich wohl jetzt noch mit userReadings das actuationCalc reading wie actuation in den Bereich zwischen 0 und 100 begrenzen.
Kenne PID20 bisher nicht, aber den Trick mit dem "passenden Reading per TYPE" scheinst du ja gefunden zu haben. Der Wertebereich dürfte eigentlich sogar gleichgültig sein, solange alle Beteiligten Devices denselbe Range benutzen. Die Korrektur auf "0-100" für Gewichtungen sollte auch mit anderen Wertebereichen klarkommen, das dient nur dazu, das Ergebnis passend zu skalieren.

Zitat von: Maui am 16 September 2022, 14:11:25
Wie ändert ihr/du eigentlich die Vorlauf-Temp? Verstellst du Neigung und Niveau oder kommst du direkt an die Vorlauf-Temp?
Im Moment produktiv noch gar nicht (Dave baut grade die firmware nochmal grundlegend um), aber wenn dann hoffentlich demnächst alles klappt, habe ich vollen Zugriff auf die VLT, mit der Wahl, einfach die Heizkurve anders einzustellen, oder eben noch zusätzlich eine dynamische Adaption zu machen anhand der Ventil-Öffnung (der ESP macht also z.B. etwas wärmer als per Heizkurve zu erwarten, wenn die Ventile insgesamt mehr geöffnet sind als Durchschnitt). Leider klappt bei mir grade der Zugriff auf den CAN-Bus nicht mehr, ich vermute, die ESP-GPIO teilweise abgeschossen zu haben...
Dazu dann die Möglichkeit, die WW-Bereitung per weekprofile/WeekdayTimer zu steuern, Brennersperren zu setzen pi pa po 8) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Maui

Ich nutze trotzdem lieber begrenzte readings mit range (0-100) weil sonst zb ein geöffnetes Fenster eine errechnete Ventilstellung auf -500 bedeutet und somit den Mittelwert unnötig verkleinert.

Vorlauf direkt setzen scheint nicht zu gehen bei Viessmann zumindest krieg ich es grad nicht hin.
Müsste ich dann wohl über Niveau und Neigung gehen. Macht das Gerechne nur leider komplizierter.

An WW-Bereitung arbeite ich bei mir auch schon fleissig, bin aber an sich weg von Zeiten hin zu manuellem Anstossen per fhem also Temp WW-Speicher < x = WW-Bereitung und den Rest der Zeit Abschaltbetrieb.
Nur jetzt im Winter geht das leider nicht so, da Heizen immer WW inkludiert und man die nicht getrennt ansteuern kann.
In der Heiz Zeit mache ich jetzt schon was ähnliches beim Heizen, nämlich ein Wechsel auf nur WW wenn die Temp in den Räumen fast erreicht ist. Viessmann ist sehr gross im modulieren was dann sonst in dem Bereich zu ständigen unnötigen Brennerstarts führt.
Aber ich will den thread hier auch nicht sprengen mit OT.

Ich drück dir die Daumen dass du bald wieder Zugriff auf die Heizung hast und werde mir valves mal genauer angucken und gucken wie ich das mir dann genau bastel mit dem Leitraum.

enno

Moin zusammen,

ich habe mir jetzt die Version von Beta-User installiert und alle meine HM-Heizungsventile eingeben. Die Gewichtung habe ich erst mal aus meiner bisherigen Lösung mit userReadings aus Ventilstellung und Faktor aus Raumgrösse, Heizkörpergrösse und "Erfahrung" übernommen. Ich werde beobachten, wenn die Heizung wieder gebraucht wird, ob das passt. Als nächstes klöppel ich die bisherige Steuerung der Buderus Gasheizung so weit es über die KM200 geht um. Für diese Anpassung finde ich gerade auch die OT Beiträge hier ganz hilfreich :)

Gas Verbrauch für Heisswasser habe ich dank FHEM, Bewegungsmelder, DWD und KM200 schon auf ein Minimum reduziert, ohne dass meine kritischen Mitbewohner sich beschweren. Ziel ist es sparen, ohne den Komfort zu reduzieren. Mal sehen, ob das beim Heizen auch so gut klappt. Dieses Modul wird mit Sicherheit ein wichtiger Baustein dafür.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

Maui

Nabend,

Ich hab mich bei der Veränderung der Vorlauf-Temp. Jetzt erst einmal bewusst für die Neigung entscheiden, um eine Abhängigkeit der Außentemperatur mit drin zu haben. Also grössere Änderungen bei niedrigeren Temperaturen. Ob das klug war, werde ich dann im Winter sehen.
Das setzen mache ich einfach per doif in 10% Schritten.
Jetzt muss ich nur noch irgendwann die Heizung anwerfen und dann fleissig die Parameter anpassen im Betrieb

Beta-User

 :) Dann mal wilkommen beim Experimentieren.
Habe mir vermutlich die CAN-Boards abgeschossen, muss jetzt erst mal auf Ersatz warten...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sweetie-pie

Hallo,

auf Grund der aktuellen energiepolitischen Lage habe ich mich endlich mal mit den Möglichkeiten meiner Therme (Brötje WBS14F) auseinandergesetzt. Dort habe ich die benutzerdefinierten Eingänge so parametriert, dass ich Trinkwarmwasser- und Heizkreis-Bedarfsanforderung von fhem aus per Tasmota-Relays schalten kann.

Jetzt stellt sich die Frage: Was mache ich damit?

TWW ist eigentlich fast erledigt: Das läuft über Zeitpläne, Anwesenheitsstatus und manuelle Anforderung.

Für die Heizungen scheint das VALVES-Modul ein guter Ansatz. Ich habe 7 FHTs wo ich ja direkt auf die Ventilstellung zugreifen kann. So weit so gut.

Zusätzlich habe ich dann noch 4 Räume in denen ich Fußbodenheizung (FBH) habe. Dort regelt fhem seit Jahren die Temperatur. Es gibt jeweils einen Fühler der die Raumtemperatur misst, diese ist die Führungsgröße für ein PID20-Modul. Direkt unter/auf dem Estrich habe weitere Temperaturfühler welche die Bodentemperatur messen. Mit THRESHOLD und den Bodenfühlern steuere ich recht einfach die Bodentemperatur über An und Aus der Ventile. Der Vorgabewert für THRESHOLD kommt dabei von dem PID20-Modul in Temperaturbereich von 18 bis 28 Grad.

Jetzt die große Frage: Kann ich irgendwie mit VALVES sinnvoll die unterschiedlichen Systeme (FHT & FBH) zusammenführen?
Ich möchte mit VALVES und NOTIFY dann bei einem bestimmten Schwellwert die Bedarfsanforderung an der Therme schalten.
Ich könnte jetzt auf die Ventile gehen (zusätzliches Userreading actuator mit off=0%, on=100%), dass scheint mir aber eher ungeeignet.

Bleibt noch der PID20-Regler, aber irgendwie weiß ich auch nicht so recht wo ich hier ansetzen soll und:
Wie bringe ich VALVES unterschiedliche Wertebereiche zwischen FHT und FBH bei.

Oder ich nehme zwei VALVES und baue die beide in einem Dummy oder-Verknüpft zusammen?

Stehe da etwas auf dem Schlauch und freu mich über hilfreiche Kommentare.

Gruß
  sweetie-pie


Maui

 Also grundsätzlich würde ich die FBH niedriger wichten aufgrund der Trägheit. Und das dann vermutlich alles zusammen in 1 Valves packen. Zb alle nicht-FBH mit Faktor 2 wichten (oder halt auch nach Raum-Wichtung für dich) und die FBH dann eben mit 1.
Und wegen den PID20, da habe ich mir ein userReading gebaut welches nur zwischen 0 und 100 kann und auf actuationCalc geht.
Das Ergebnis aus valves werte ich dann in einem DOIF mit 10min Pause zwischen den commands aus ( Trägheit Heizung) und drehe je nach aktuellem bedarf Heizkurve bzw. Steigung runter bzw. Sogar ganz auf WW-Modus.
Subjektiv betrachtet fahre ich damit bisher sehr gut wobei ich auch weniger heize als sonst und somit natürlich nicht so richtig aussagefähig bin.

RaspiCOC

Hallo zusammen, ich denke mal, dass ich mich gern aus Benutzersicht in diesen Thread einklinken will.

Kurz zu meinem Anwendungsszenario:
- Alle Räume sind mit HM-CC-RT-DN ausgestattet. Ich kenne also die Ventilstellungen, die sich aus der vorgegebenen Wunschtemperatur für den jeweiligen Raum ergeben
- Ich kenne die Aussentemperatur und sie steht FHEM zur Verfügung. Daraus könnte ich unter Berücksichtigung der Gegebenheiten des Hauses eine Heizkurve / Vorlauf ableiten.
- Die Heizkreispumpe soll nur dann angehen, wenn überhaupt Leistung von den Heizkörpern abgefordert wird. Also eine Ventilstellung > x% von einem oder mehreren Ventilen
- Jetzt baue ich gerade die Heizungsanlage neu. Ein Holzscheitvergaser wird zukünftig den einen Pufferspeicher speisen. Eine Gastherme soll nur dann einspringen, wenn der Holzscheitvergaser aus ist und die Puffertemperatur unter einen Sollwert fällt.
- Wenn der Holzvergaser läuft, dann läuft er. Also muss ich den Vorlauf durch einen Mischer bedarfsgerecht steuern.

Ich denke, Module wie VALVES oder STELLMOTOR können hier gut zusammenarbeiten. Allerdings ist keines der Module offiziell eingecheckt, was mich natürlich bei dieser kritischen Anwendung beunruhigt.

Also, ich habe ein Rieseninteresse an einem solchen Modul, das idealer Weise die entsprechenden Trigger für HK-Pumpe an/aus oder MischerTemp +/- liefern kann.

Beta-User

Vorab mal freut es mich, dass sich doch einige gefunden haben, die das Thema interessiert.

Zitat von: RaspiCOC am 24 Oktober 2022, 12:44:15
Ich denke, Module wie VALVES oder STELLMOTOR können hier gut zusammenarbeiten. Allerdings ist keines der Module offiziell eingecheckt, was mich natürlich bei dieser kritischen Anwendung beunruhigt.

Also, ich habe ein Rieseninteresse an einem solchen Modul, das idealer Weise die entsprechenden Trigger für HK-Pumpe an/aus oder MischerTemp +/- liefern kann.
Na ja, zum einen liegen die Module ja schon eine ganze Zeit hier im Forum bereit und werden von daher voraussichtlich nicht so einfach von der Bildfläche verschwinden, zum anderen hatte ich zum Thema VALVES ja schon angekündigt, dass ich am überlegen bin, ggf. die Pflege offiziell zu übernehmen und das dann - je nachdem - entweder in contrib oder als reguläres Modul mit einzuchecken.

Da ich grade auch am überlegen bin, meine Sommerbasteleien "aufzubohren" und sowohl PV wie auch Solarthermie auf's Dach zu knallen (letzteres dann mit Heizungswasser-Speicher, denke grade so an 800l), wollte ich mir "STELLMOTOR" auch mal ansehen. Bis vorhin war mir auch nicht klar, dass das aus derselben Feder stammt und denselben Status hat. Allerdings kann es auch sein, dass ich den Teil auf eine MCU auslagere oder einfach einen Rollladenaktor dafür verwende...
(Und bzgl. der dahinterstehenden OT-Frage schon klar: PV ist universeller als Thermie, man kann alternativ über einen Durchlauferhitzer nachdenken, ist effektiver und billiger... Der Punkt ist: die fragliche Fläche ist wegen Teilverschattung und dem Zuschnitt nicht wirklich gut für PV geeignet, und das muss sich auch nicht in 10 Jahren gerechnet haben).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RaspiCOC

Ich bin ehrlich gesagt etwas überrascht, dass dieses Themenfeld bisher nur in der Codeschnipsel-Ecke unterwegs ist. Gern beteilige ich mich mit Ideen und Diskussionen. Hinsichtlich Entwicklung muss ich aber zurücktreten - kann ich schlichtweg nicht.

Vom Gefühl her glaube ich, dass wir hier an der kompliziertesten Ecke der Heizungstechnik unterwegs sind. Es gibt hier so viele Parameter zu berücksichtigen. Ich glaube auch, dass es am Markt keine Out-of-the-Box-Lösung gibt. Auch glaube ich, dass - soweit ich die beiden Modue verstanden habe - VALVES und STELLMOTOR zusammengehören.

OT: Ein 800 Liter Puffer kann schnell knapp werden, wenn es komfortabel sein soll.

Schon mal so ein paar weitere Punkte, die mir so einfallen:

  • Die aktuelle Puffertemperatur am Ausgang Heizungsvorlauf entspricht der maximalen erreichbaren Vorlauftemperatur in diesem Augenblick. D.h. diese muss gemessen werden und FHEM sollte sie kennen.
  • Dann haben wir noch die tatsächlichen Vorlauftemperaturen vor und hinter dem Mischer. Wenn ich es richtig verstehe, dann kann ich mit dem Mischer immer nur Rücklaufwasser in den Vorlauf einmischen, um die Temperatur herabzusetzen. D.h. ich kann nicht einfach sagen, drehe den Mischer auf 80% und ich habe die gewünschte Vorlauftemperatur. Die kann ich m.E. nur durch das Mischungsverhältnis und die vorhandenen Temperaturen vor und hinter dem Mischer schätze / errechnen.
  • Wenn die Heizkreispumpe aus ist, dann sollten sich die Temperaturen vor und hinter dem Mischer angleichen. Auf alle Fälle will ich dann ja keine Regelung des Mischers haben. Wir jetzt aber die Heizkreispumpe angeschaltet, dann muss sich der Mischer wieder an den Sollwert rantasten. Hier frage ich mich, wie schnell ein NTC auf die Temperaturänderung reagiert. Also würden zu schnelle Steuerungsschritte zu einem sinnlosen Herumschwingen des Stellmotors führen. Geht die HK-Pumpe an, dann will ich so schnell wie möglich die angestrebte Vorlauftemperatur bekommen. Die liegt mir aber nicht vor dem Mischer sondern beim Auslass des Puffers vor. Jetzt könnte ich aus der Pufferausgangstemperatur und der aktuellen Temperatur des Rücklaufs ein Mischungsverhältnis errechnen und den Schrittmotor in die halbwegs richtige Richtung fahren.
  • Ich könnte auch die Stellungen der Ventile mit einfliessen lassen. Geht ein Ventil auf 100%, also das klassische Guten Morgen Szenario, dann könnte ich die Vorlauftemperatur ja sogar noch etwas höher gehen lassen.
  • Dann treibt mich auch noch um, wie man die Heizkennlinie darstellen könnte. Was kenne ich? Aussentemperatur und den energetischen Zustand des Hauses. Also die Frage ob eher steil oder flach kann man sicherlich beantworten. Also könnte man eine Kennlinie vordefinieren. Aber muss die tatsächlich in der Granularität einer mathematischen Funktion vorliegen, oder reicht es nicht einfach 5 Kelvin Schritte zu nehmen, um auch hier viele, viele Stellvorgänge und die sich daraus sicherlich ergebenden Neukalibierungen zu reduzieren?
  • Wie oft muss ich denn eigentlich neu kalibrieren? Während des Tags drehe ich den Motor in x-Sekundenschritten auf und zu. Damit müsste man ja eigentlich hinkommen. Irgendwann addieren sich aber Fehler durch die Latenzen zusammen (das hat das Modul Stellmotor ja schon drauf - was aber mit einem kleinen Nachlauf des Motors?
  • Und zu guter Letzt haben wir es mit mehreren Devices zu tun. Wir haben HK-Pumpe und wir haben vermutlich 2 Devices für Mischer-auf und Mischer-zu (wobei Mischer-auf und Mischer-zu niemals gleichzeitig aktiv sein dürfen, oder?)

All das kann man sicherlich mit notifies, doifs etc zusammenbauen. Aber, ich denke das wäre zu aufwändig und Fehler finden dürfte grausam werden.






Beta-User

Zitat von: RaspiCOC am 24 Oktober 2022, 16:51:21
Ich bin ehrlich gesagt etwas überrascht, dass dieses Themenfeld bisher nur in der Codeschnipsel-Ecke unterwegs ist. Gern beteilige ich mich mit Ideen und Diskussionen. Hinsichtlich Entwicklung muss ich aber zurücktreten - kann ich schlichtweg nicht.
Na ja, VALVES ist kein Hexenwerk, und vermutlich STELLMOTOR auch nicht. "Kann ich nicht" dachte ich auch mal...
Das Schwierigste ist meistens, erst mal festzulegen, WAS genau passieren soll.

Zitat
Vom Gefühl her glaube ich, dass wir hier an der kompliziertesten Ecke der Heizungstechnik unterwegs sind. Es gibt hier so viele Parameter zu berücksichtigen. Ich glaube auch, dass es am Markt keine Out-of-the-Box-Lösung gibt. Auch glaube ich, dass - soweit ich die beiden Modue verstanden habe - VALVES und STELLMOTOR zusammengehören.
Ich dachte früher auch mal, dass es die "komplizierteste Ecke" sei, habe da aber in der jüngeren Vergangenheit jetzt ein paar "aha"-Erlebnisse gehabt. Vielleicht eine kurze Zusammenfassung meiner aktuellen Gedankenwelt:
- VALVES kann als Indikator dienen, wie groß der aktuelle Wärmebedarf ist
- Ihm fehlt (derzeit jedenfalls noch) jegliche Tendenzaussage (als sowas wie "schnell steigend", "gleichbleibend", "fallend")
- Ein optimiertes Heizungssystem sollte möglichst gleichmäßig laufen, also "schnell sehr heißes Wasser" zu verteilen ist mAn. nicht der richtige Ansatz. Besser ist es, immer gerade soviel Wärme ins System zu geben, wie tatsächlich gebaucht wird => die Ventile sollten sich möglichst wenig bewegen und (nach der "Ersterwärmung") den Tag über irgendwo im Mittelfeld des Einstellbereichs "festgetackert" sein
- Dazu ist die Möglichkeit sinnvoll, die Vorlauftemperatur regeln zu können, und zwar möglichst eben immer "knapp über Minimum". Dazu genügen relativ wenige Parameter, jedenfalls wenn ich den Code von Dave G. für den Junkers-ESP richtig verstanden habe (dazu gibt es eine gute Seite, die den relativ einfachen Verlauf einer Beispiel-Linie zeigt - https://github.com/Neuroquila-n8fall/JunkersControl#heating-parameters).
- Hilfreich ist STELLMOTOR dann, wenn man einen Mischer braucht, um aus "sehr heißem Wasser" dann eben passend temperiertes Wasser zu machen. Ohne Speicher wäre das auch ohne STELLMOTOR gegangen - nur über die Modulationsfunktion der Gastherme, wobei dann in unserem Fall eigentlich der ESP dann die Umrechnung von VALVES-Infos in (relative) Änderungen der Vorlauftemperatur vornehmen sollte (Dave hat das zwischenzeitlich ähnlich gemacht und eine Mittelwertbildung vorgenommen, soweit ich das verstanden habe, jetzt auch mit der Vorgabe, dass die Ventile optimalerweise so um die 30% offen sein sollen).
ZitatOT: Ein 800 Liter Puffer kann schnell knapp werden, wenn es komfortabel sein soll.
Nach einem kurzen Telefonat mit dem voraussichtlichen Leiferanten für den Röhrenkollektor habe ich den jetzt auf 400l verkleinert, und selbst das ist die Obergrenze dessen, was mir bei der vorhandenen Kollektorfläche iVm. der Leitungslänge empfohlen wurde...

Zitat
Schon mal so ein paar weitere Punkte, die mir so einfallen:

       
  • Die aktuelle Puffertemperatur am Ausgang Heizungsvorlauf entspricht der maximalen erreichbaren Vorlauftemperatur in diesem Augenblick. D.h. diese muss gemessen werden und FHEM sollte sie kennen.
  • Dann haben wir noch die tatsächlichen Vorlauftemperaturen vor und hinter dem Mischer. Wenn ich es richtig verstehe, dann kann ich mit dem Mischer immer nur Rücklaufwasser in den Vorlauf einmischen, um die Temperatur herabzusetzen. D.h. ich kann nicht einfach sagen, drehe den Mischer auf 80% und ich habe die gewünschte Vorlauftemperatur. Die kann ich m.E. nur durch das Mischungsverhältnis und die vorhandenen Temperaturen vor und hinter dem Mischer schätze / errechnen.
Klar muss man einige Temperaturen erfassen und dann darauf reagieren. Allerdings sollte man m.E. von allzu hektischen Eingriffen Abstand nehmen, sondern praktisch immer erst abwarten, ob eine ergriffene Maßnahme wirkt (und wenn ja wie). Ergo würde ich z.B. in der Regel mit dem letzten Mischerwert starten, wenn die Zirkulationspumpe wieder anläuft (falls man die überhaupt "am Tag" ausmacht).
Dann warten, was am Rücklauf zurückkommt, und wie schnell ggf. auch die Thermostate reagieren - wobei das bei den Homematics ja _Minimum_ 2,5 Minuten sind, bis da was gemeldet wird!

Zitat

       
  • Wenn die Heizkreispumpe aus ist, dann sollten sich die Temperaturen vor und hinter dem Mischer angleichen. Auf alle Fälle will ich dann ja keine Regelung des Mischers haben. Wir jetzt aber die Heizkreispumpe angeschaltet, dann muss
Wie gesagt: lieber etwas warten und ggf. dann auch die Messpunkte so setzen, dass klarer identifizierbar ist, was was ist (Puffertemp im/am Puffer), Vorlauf ein Stück weg vom Mischer, Rücklauf auch etwas vor dem Eingang in den Puffer etc..

ZitatAll das kann man sicherlich mit notifies, doifs etc zusammenbauen. Aber, ich denke das wäre zu aufwändig und Fehler finden dürfte grausam werden.
Weiß noch nicht, ob sich das alles so weit standardisiert runterbrechen läßt, dass man auf eine individuelle Programmierung wirklich verzichten kann und wo es ggf. auch sinnvoll ist, (teil-) autonome Systeme (ähnlich dem Junkers-ESP) vorzusehen und lediglich die zu parametrieren und mit aktuellen Daten zu versorgen.

Prinzipiell scheint es mir so, dass man grade vor dem Hintergrund der immer weiter sich aufdröselnden Möglichkeiten gut daran tut, sich auszutauschen, sonst macht man nämlich am Ende evtl. das Falsche!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Maui

Zitat von: Beta-User am 24 Oktober 2022, 17:31:04

- Ein optimiertes Heizungssystem sollte möglichst gleichmäßig laufen, also "schnell sehr heißes Wasser" zu verteilen ist mAn. nicht der richtige Ansatz. Besser ist es, immer gerade soviel Wärme ins System zu geben, wie tatsächlich gebaucht wird => die Ventile sollten sich möglichst wenig bewegen und (nach der "Ersterwärmung") den Tag über irgendwo im Mittelfeld des Einstellbereichs "festgetackert" sein
- Dazu ist die Möglichkeit sinnvoll, die Vorlauftemperatur regeln zu können, und zwar möglichst eben immer "knapp über Minimum". Dazu genügen relativ wenige Parameter, jedenfalls wenn ich den Code von Dave G. für den Junkers-ESP richtig verstanden habe (dazu gibt es eine gute Seite, die den relativ einfachen Verlauf einer Beispiel-Linie zeigt - https://github.com/Neuroquila-n8fall/JunkersControl#heating-parameters).
Von der Physik her würde ich dir da sofort Recht geben, aaaber
-da kommen dann ja auch noch Störgrössen hinzu wie geöffnete Fenster zum Lüften
-oder "dumme" Thermen welche aufgrund des geringen Energiebedarfs anfangen zu takten und somit (zumindest wohl bei mir) dadurch eher mehr Gas verbraten durch häufiges Anspringen.
Ich versuche daher eher wie beim Auto zu "segeln" also bei geringem Wärmebedarf die Therme zum Abstellen zu zwingen.

Das ganze Thema ist halt leider auch immer super individuell und kaum in Gänze auf einen Nenner zu bringen.
Ich bin offen für Austausch und freue mich auf Input oder auch wie du sagst einfach ein Austausch, um die eigenen Fehler festzustellen.
Die Frage ist, ob der Thread hier der richtige Ort dafür ist  :)