Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Support Thread für VALVES

Begonnen von Beta-User, 25 Januar 2023, 21:05:08

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: jkriegl am 27 Oktober 2024, 11:15:04Wenn ich mich richtig erinnere, muss die Summe der Gewichte gleich der Anzahl der Geräte sein. Kann momentan leider nicht nachschauen.
Das war meiner Erinnerung nach früher mal so.

Da mir das nicht einleuchtend vorkam, wenn man das mit "ignore-high/low" (bzw. "prio")-Attributen kombiniert, hatte ich versucht, es rechnerisch im Code abzubilden, dass immer ein "Effektivgewicht" aller (ggf. mehrfach) berücksichtigten Thermostate von "1/1" rauskommt. Bin nur nicht mehr sicher, dass das korrekt rechnet. Das list von F_Klee gibt mir immer noch zu denken... (Also bitte melden, falls jemand da Verbesserungsvorschläge hat).
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

Prof. Dr. Peter Henning

Ich fahre seit etlichen Jahren einen anderen Ansatz. Jeder Thermostat hat bei mir ein userReading "powerpart", das berechnet wird aus der Ventilstellung, der (effektiven) Heizkörperbreite und der Anzahl der Lamellen. "Effektiv" deshalb, weil ich in vier Räumen komplett abweichende Heizkörpergeometrien habe. Man könnte die Angaben der (effektiven) Breite und der Lamellenzahl auch durch eine einzige Kennung ersetzen, und so einzelne Heizkörper priorisieren.

Der gesamte Heizbedarf ist deshalb eine dimensionslose Größe als Summe aller dieser powerpart-Werte, die man beliebig skalieren kann.

Zum VALVES-Modul ist zu sagen, dass die doppelte Normierung (der Gewichte und des Endergebnisses) ziemlich sinnlos ist. Es reicht, das Endergebnis auf den gewünschten Skalenbereich abzubilden.

Mit dem hydraulischen Abgleich hat das nicht wirklich etwas zu tun. Denn der soll ja nicht den gesamten Heizbedarf nach den Bedarfen der Einzel-Heizkörper steuern. Sondern, ganz im Gegenteil, die Bedarfe der Einzel-Heizkörper aneinander anpassen. Damit nicht der HK im Dachgeschoss kalt bleibt, wenn man im Wohnzimmer die Heizung aufdreht.

Ich habe schon 2016 in den "SmartHome Hacks" erhebliche Zweifel an dem Konzept des hydraulischen Abgleichs angemeldet - und zwar aus allgemeinen physikalischen Grundsätzen heraus. Es macht nämlich gar keinen Sinn, alle Heizkörper gleich zu versorgen. Manche werden das nie benötigen, weil die lokale Regelung den "nackten" Bedarf überschreibt. Es macht daher viel mehr Sinn, bei elektronischen Heizungsreglern mit dem Temperaturoffset zu spielen. Und den ggf. lokal an den Bedarf anzupassen.

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 13 November 2024, 17:54:10Ich fahre seit etlichen Jahren einen anderen Ansatz. Jeder Thermostat hat bei mir ein userReading "powerpart", das berechnet wird aus der Ventilstellung, der (effektiven) Heizkörperbreite und der Anzahl der Lamellen. "Effektiv" deshalb, weil ich in vier Räumen komplett abweichende Heizkörpergeometrien habe. Man könnte die Angaben der (effektiven) Breite und der Lamellenzahl auch durch eine einzige Kennung ersetzen, und so einzelne Heizkörper priorisieren.
Ist denn dein "powerpart" in irgendeiner Form nicht linear? Falls es linear ist, dürfte das im Endeffekt auf dasselbe rauslaufen wie ein "weighting" in VALVES. (Ob man Priorisierungen etc. braucht, die halt da waren, darüber kann man vermutlich lange diskutieren. Da die im code drin waren, werde ich nicht anfangen, das in Frage zu stellen. Wer es nutzen will: go ahead).

Zitat von: Prof. Dr. Peter Henning am 13 November 2024, 17:54:10Zum VALVES-Modul ist zu sagen, dass die doppelte Normierung (der Gewichte und des Endergebnisses) ziemlich sinnlos ist. Es reicht, das Endergebnis auf den gewünschten Skalenbereich abzubilden.
"sinnlos" bedeutet "mathematisch falsch" oder "eigentlich nicht mehr notwendig"?
Nach meinen bisherigen Erfahrungen gibt das "normierte" Ergebnis eigentlich einen ganz brauchbaren Indikator, aber letztlich muss man das Endergebnis imo eigentlich immer irgendwie (weiter) interpretieren, weil letztlich die einzelnen Ventilstellungen ja auch u.a. von der (vom den thermostaten angenommenen) Vorlauftemperaturen und deren Differenz zur Solltemperatur abhängen. So ein Haushalt mit seiner Heizung etc. ist halt insgesamt ein mehr oder weniger träges, aber dynamisches Temperatur-Gesamtsystem.

Zitat von: Prof. Dr. Peter Henning am 13 November 2024, 17:54:10Mit dem hydraulischen Abgleich hat das nicht wirklich etwas zu tun.
Bisher war in diesem Thread oder bei VALVES auch der hydraulische Abgleich kein wirkliches Thema. Meine Erfahrungen in der eigenen Hütte: Es macht Sinn, sich mit der Versorgungssituation einzelner Heizkörper zu beschäftigen, um "hydraulische Kurzschlüsse" zu vermeiden, jedenfalls, wenn man die Heizung teilautonom entscheiden lassen will, wie viel Wärme sie ins System schubsen darf. Wenn die aus den falschen Gründen glaubt, der Heizbedarf sei gedeckt, ist das ein Problem.
Über alles andere zu dem Thema kann man vermutlich wirklich streiten. Aber bitte nicht hier.
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

Prof. Dr. Peter Henning

Du missverstehst mich - ich meine damit keineswegs, dass das Ergebnis anders ist. Sondern nur der Ansatz. Ja, der ist linear, basiert aber nicht auf einem irgendwie zu erratenden Gewichtsfaktor, sondern der Größe des Heizkörpers. Ich halte es für denkbar, dass mit meinem Ansatz ziemlich dasselbe herauskommt, wie mit dem VALVES-Modul

Doppelte Normierung: Sinnlos heißt nicht "falsch" - sondern es ist einfach eine doppelte Rechnung.

Der hydraulische Abgleich wurde in einem der Posts unten erwähnt, aber eben im falschen Kontext.

@F_Klee: Nein, Heizungsexperte bin ich nicht - nur ausgewiesener Thermodynamiker. Und schüttele über solche Dinge wie den hydraulischen Abgleich einfach nur den Kopf. Das ist nämlich eine reine Gelddrucklizenz für Heizungsbauer, er kostet in der Regel genauso viel, wie die Förderung durch den Bund beträgt.

Für diejenigen, die an dieser Aussage zweifeln: Es ist für den Durchfluss durch einen Heizkörper vollkommen unerheblich, ob ich diesen Fluss am Eingangsventil=Thermostat oder durch ein Rücklaufventil begrenze. Das bedeutet, dass man mit einem System aus gescheit eingestellten elektronischen Thermostaten jeden hydraulischen Abgleich der Rücklaufventile ersetzen kann. Noch einfacher ausgedrückt: Stellt man fest, dass ein Heizkörper/Raum zu warm oder zu kalt wird => Offset in den Thermostaten setzen.

Und warum das für VALVES durchaus relevant sein könnte: Es ist nicht nur das Endergebnis relevant. Sondern man könnte durchaus auch den berechneten Wärmebedarf der einzelnen Heizkörper auf Ausreißer überprüfen, ggf. noch mit der gemessenen Raumtemperatur im Tandem.

Witzig fände ich eine Anzeige in Tabellenform: Für jeden Heizkörper/Raum die über den Tag integrierte Wärmemenge und die Durchschnittstemperatur. Oder noch komfortabler: Das Ganze stundenweise aufgeschlüsselt. Das wäre eine Hilfe beim Erkennen von Wärmelecks, hydraulischen Kurzschlüssen und ähnlichem. Mal sehen, vielleicht finde ich Zeit, das als Codeschnipsel zu implementieren.

LG

pah

Beta-User

@pah - Vielleicht eine allgemeine Anmerkung: Es war und ist mir weiter ziemlich unklar, warum das Thema (sinnvolle) "Heizungssteuerung" in FHEM allgemein und speziell im Wiki gefühlt unglaublich stiefmütterlich behandelt wird (abgesehen von "Heizung aus bei offenen Fenstern" und "ein bißchen weekprofile" (das imo leider kaum ein user richtig versteht) ). Kann sein, dass sich das Großthema in deinen Büchern besser aufbereitet findet, aber im Prinzip erschien mir VALVES so ziemlich der einzige Ansatz, dazu irgendeine "normierte" (Teil-) Basis für irgendwelche Automatismen bereitzustellen, und von daher finden sich auch in dem alten Thread ein paar allgemeine Dinge wie das mit dem Abgleich.

Gerne können wir VALVES (oder sonst was) gerne weiter ausbauen, wie gesagt, finde ich das (Gesamtthema) eigentlich zu wichtig, um es so stiefmütterlich zu behandeln.

Dazu würde dann gerne auch ein Abschnitt gehören, wie man mit "weighting" (oä./etc.) sinnvoll umgeht. Bei mit entspricht das übrigens auch im wesentlichen der Wärmeleistung der einzelnen HK (-Gruppen).
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