Fussbodenheizung mit PWM steuern

[jamesgo]

maxOffTime ist erst mal unabhängig von der Temperatur und "CDN" bedeutet wenn "Cosy", "Day" oder "Night"

Also mach er auch Nachts alle 2 Stunden für 30 Minuten "on"

Du kannst aber noch ein Temperaturlimit anhängen (z.B. 1.3). Wenn es dann überschritten wird zieht maxOffTime nicht mehr.

Format is: <maximum time the room can be off>[,<list of temperatureSelectors which are D,N,C and E>][,<period for "on" state>][,<temperature limit>]

[BOFH]

ja aber die bedingung ist doch nicht erfüllt ?!

temperature limit: if "current temperature" is greater than "desired temperature" + "temperature limit" then maxOffTime is ignored (not evaluated).

[EDIT]
CDN schon klar.... die 0:51 Uhr hatte ich nur mal aus dem log gezogen ....
[/EDIT OFF]

[jamesgo]

keine Temperaturdifferenz = immer durchführen

[BOFH]

hmm stimmt, hatte vorher eine 0 drin und hatte die rausgeworfen ...
dann schreib ich die wieder dran  

Dachte das kam nun vielleicht auch vom Update.

Danke

[jamesgo]

mach vielleicht eine "0.1" ... dann kommt sie dir nicht so obsolete vor

[BOFH]

hihi.
Ja mach ich genau das !

Vielleicht kannst das noch in dem Modultext für die commandref hinzufügen, damit ich das auch in einem jahr noch weiß *g*

[Skusi]

Hallo,
meine FB Heizung läuft seit Jahren wirklich super üper PWM/PWMR. Das einzige was mich immer noch stört ist das die drei Heizkreise meines Wohnzimmers sehr oft gleichzeitig öffnen und dadurch eine unnötig hohe Lastspitze für meinen Heizkessel erzeugt wird (siehe Bild - Der Tiefpunkt= Lüften, Der Berg = Kamin an)

Ich habe schon leicht verschobene Parameter verwendet um die Pulse etwas aus einander zu bekommen. Funktioniert auch, aber nicht so wie ich es gerne hätte.

Nun kam ich eben auf die Idee ein zweites PWM anzulegen und die drei WZ Heizkreise über dieses IO Device laufen zu lassen. Der Vorteil soll sein das ich über min MaxSwitchOnPerCycle / MaxSwitchOffPerCycle die Pulse auseinander kriege.

Das mit dem overallHeatingSwitch der 2 PWM´s bekomme ich noch per DOIF auf meinen Kessel. Aber wo ich keine Idee habe ist der ist die Verschmelzung der pulseAvg readings zum anfordern des Kessels/Pumpe über den pulseAvg3 der gesamten Heizkreise.

Also wie kann ich den pulseAvg3 vom neuen PWM_WZ mit dem pulseAvg3 verrechnen um dann Bedarfsgerecht den overallHeatingSwitch  zu schalten.

Jemand ne Idee ?

[jamesgo]

Hallo Skusi,

/* text nochmal geändert */

das zweite PWM bringt dir m.E. mehr Probleme als Vorteile. Die Trennung von PWM und PWMR habe ich gemacht damit es eine übergeordnete Instanz gibt die alle Räume im Überblick hat und dann Entscheidungen übergreifend zu treffen. Zwei Kapitäne auf einem Boot hat sich im realen Leben auch nicht durchgesetzt.

MaxSwitchOnPerCycle verwendest du vermutlich schon, aber das entzerrt ja nur für einen Zyklus (also normalerweise 1 Minute).

Beschreib doch mal verbal was du dir vorstellst - vielleicht ergibt sich daraus eine schöne Erweiterung.

In deinem Beispiel schwebt dir vermutlich vor dass nacheinander geschalten wird (die Lücken sind ja groß genug). Dh. man könnte eine "Lastgruppe" definieren für die es ein "MaxOn" gibt. Im Nachhinein ist das anhand vom Chart sehr einfach zu entscheiden. Aber wie erkennt man im "jetzt" dass es nicht notwendig sein wird alle 3 die nächsten 6 Stunden auf "on" zu haben weil die Temperatur einfach nicht steigt?

Eine Alternative die mir noch einfällt wäre ein Delay innerhalb einer Lastgruppe. D.h. eine Verzögerung von sagen wir 15 Minuten beim Einschalten für alle Räume in dieser Gruppe. Dann würde es im schlimmsten Fall 30 Minuten dauern bis alles auf "on" geht.

Wenn ich mir den Chart nochmals anschaue ... wird das Schalten durch "maxOffTime" getriggert? Dort gibt es eine Logik die versucht möglichst viele Räume gleichzeitig auf "on" zu bringen. Evtl. würden dann eine alternative Regel schon helfen.

Wenn du selbst eine Logik "programmieren" willst wäre ein Ansatz z.B die 3 Heizkreise als einen Raum zu definieren und dann nur einen Dummy zu schalten. Deine Logik könnte dann abhängig von Uhrzeit/Aussentemperatur/Temperaturdifferenz/usw. entscheiden einen oder mehrere Heizkreise rollierend zu schalten.
Der Nachteil ist dass es nur noch eine Wunschtemperatur und ein Zeitprofil gibt.

Viele Grüße
Andy

[Skusi]

Hallo jamesgo,

das zweite PWM bringt dir m.E. mehr Probleme als Vorteile.

Meinst Du es könnte dadurch zu störenden Wechselwirkungen innerhalb Fhem kommen ?

MaxSwitchOnPerCycle verwendest du vermutlich schon, aber das entzerrt ja nur für einen Zyklus (also normalerweise 1 Minute).

MaxSwitchOffPerCycle =1 MaxSwitchOnPerCycle =2
10 Kreise insgesamt. Und mein Zyklus ist 600 sek lang und meine Cycletime bei 3600. Das hat sich über Jahre so bewährt. Meine Heizflächen sind extrem träge, da 2 Fliesenböden über der FB liegen.
Also nicht über die langen Pulse wundern. Läuft so ganz gut mit max 0,2 Grad Abweichung ohne Absenkungs - Zeiten.

Hier mal die defs:
   
600 1800 300 0.95 1,3 0,0,0.6 Waermebedarf_WZ,0.6,300,,180 (PWM_WZ)
   
FBH_Regler_WZ 1.7,0.11 TH_Wohnzimmer Ventil_Wohnz.Kamin Lueftung 2:1.5:0.02:0.5,10 (PWMR 3x Wohnzimmer)

Zwischnfrage: Der Faktor vorne (1.7) wird doch durch den Faktor 1.5 hinten ersetzt. oder ?

Mein Haupt Ziel war und ist, eine niedrige Kesselleistung und wenig Starts sowie lange Laufzeiten. maxOffTime ist für diese 3 WZ Kreise auch schon unterschiedlich eingestellt, weil ich auch diese Pulse nicht gleichzeitig haben wollte.
maxOffTime 3:30,C,0:30,1 maxOffTime 3:00,C,0:30,1 maxOffTime 2:30,C,0:30,1

Beschreib doch mal verbal was du dir vorstellst - vielleicht ergibt sich daraus eine schöne Erweiterung.

Ein Ansatz wäre wenn man die 3 Kreise (Ventile) in einem PWMR definieren könnte und dann den berechneten Pulse auf die Ventile aufteilen würde um diese dann nacheinander durch zu schalten. Ist aber auch nicht zu Ende gedacht. Was passiert bei 100% ?
Die Sache mit dem Delay gefällt mir auch gut. Was wäre denn wenn man das Delay Pulse abhängig macht ? Bei Pulse unter 30 kann man nacheinander schalten, darüber muss es Überschneidungen geben, aber eben nur so klein wie nötig. Bei Pulse 100 gehen dann eben alle Kreise gleichzeitig on.

Aber das kann ich alles schon über Deine Idee:

Wenn du selbst eine Logik "programmieren" willst wäre ein Ansatz z.B die 3 Heizkreise als einen Raum zu definieren und dann nur einen Dummy zu schalten. Deine Logik könnte dann abhängig von Uhrzeit/Aussentemperatur/Temperaturdifferenz/usw. entscheiden einen oder mehrere Heizkreise rollierend zu schalten.
Der Nachteil ist dass es nur noch eine Wunschtemperatur und ein Zeitprofil gibt.

selber realisieren. Nur eine desired-temp und Zeitprofil ist kein Problem. Läuft im Moment sowieso nicht anders. Es handelt sich um einen großen Raum.

Wenn ich mir den Chart nochmals anschaue ... wird das Schalten durch "maxOffTime" getriggert? Dort gibt es eine Logik die versucht möglichst viele Räume gleichzeitig auf "on" zu bringen. Evtl. würden dann eine alternative Regel schon helfen.

Die Logik musst Du näher erklären. Ich dachte der Zwangs on zählt nach dem letzten berechneten on los. Deshalb versuche ich ja die Pulse für jeden dieser 3 Kreise unterschiedlich zu halten, damit der Zwangs on nicht bei allen gleichzeitig kommt.

...to be weitergedacht...

[jamesgo]

Meinst Du es könnte dadurch zu störenden Wechselwirkungen innerhalb Fhem kommen ?

Ich habe auch 2 PMW laufen (EG: Fussbodenheizung, OG: Heizkörper). Das funktioniert. Ich triggere aber unterschiedliche Heizkreise welche unabhängig in der Heizung zu schalten sind. D.h. es kann passieren dass beide Kreise gleichzeitig an, gleichzeitig aus oder nacheinander an sind. Bei den Heizkörpern triggert ein kalter Raum die Heizung und bei den anderen regelt das Raumthermostat die Temperatur.

Das PWM trifft die Entscheidung was zu tun ist nachdem alle Räume berechnet sind. Alle Werte die übergreifend abhängig sind und die Entscheidung welcher Raum geschalten wir basiert darauf. Wenn du zwei PMW's hast findet diese Berechnung nacheinander statt (nicht zwingend ein paar Sekunden später). Die Werte werden evtl. als Reading bereitgestellt, sind aber nicht von aussen steuerbar. maxPulse, avgPulse ist dir schon aufgefallen und ich glaube dass nach und nach immer mehr Baustellen hochkommen werden.

Bei der Implementierung der maxOffTime war die Ausgangssituation mein Kachelofen, der das ganze Haus heizt. Dh. Wärmebedarf überall gleich null. Im Wohnbereich war es mollig warm und der Boden war kalt. Wohnbereich bedeutet 4 Heizkreise in einem fast offenen Raum (Küche, Essbereich und Wohnzimmer mit zwei Kreisen). Wenn ich die Heizkreise nacheinander schalten würde hätte ich jeweils so wenig Last auf der Heizung das sie ins Pulsen kommt. Deshalb versucht die maxOffTime möglichst alle Kreise gleichzeitig auf "on" zu bringen. Ich hab das in vorherigen posts zweimal im Detail beschrieben - aber es ist genau das Gegenteil von dem was du willst.

Wir haben also zwei Routinen:
- die Temperaturbasierte, die z.B. entscheidet die nächsten 6 Stunden durchzuheizen weil es einfach kalt ist
- maxOffTime

Wenn dein Beispielgraph also durch die falsche Strategie von maxOffTime so ist wie er ist, könnte man schon was machen. Z.B. ein Parameter der vorgibt dass nur 1 (oder 2) Räume durch maxOffTime geschalten werden dürfen.

[Skusi]

Ich habe nun zum Testen erstmal die Variante mit dem eigenen PWM nur für die 3 WZ Kreise umgesetzt.
Mit MaxSwitchOnPerCycle 1 sieht das schon ganz gut aus. Ich habe für diesen PWM dann noch die CYCLETIME von 3600 auf 1800 gesetzt sodass die Ventile schneller durchgeschaltet werden.

Im Plot sieht das schon vielversprechend aus.

Parallel habe ich mal ein DOIF gestrickt das die Ventilsteuerung auf Pulse / 3 übernimmt. Ist aber noch disabled.

Bei der Implementierung der maxOffTime war die Ausgangssituation mein Kachelofen, der das ganze Haus heizt. Dh. Wärmebedarf überall gleich null. Im Wohnbereich war es mollig warm und der Boden war kalt. Wohnbereich bedeutet 4 Heizkreise in einem fast offenen Raum (Küche, Essbereich und Wohnzimmer mit zwei Kreisen). Wenn ich die Heizkreise nacheinander schalten würde hätte ich jeweils so wenig Last auf der Heizung das sie ins Pulsen kommt. Deshalb versucht die maxOffTime möglichst alle Kreise gleichzeitig auf "on" zu bringen. Ich hab das in vorherigen posts zweimal im Detail beschrieben - aber es ist genau das Gegenteil von dem was du willst.

Du hast recht, das ist genau das Gegenteil von meinem Wunschverhalten. Der Ansatz ist ähnlich. Kamin im Wohnzimmer ist jeden Abend an, Pulse sinkt auf 0, FB Kalt und braucht in der Nacht hohe Kessellast wenn alle gleichzeitig auffahren.

Mein Kessen kann gottseidank bis ca 2,9 KW runter Modulieren. Dadurch taktet der nicht so schnell.

Wenn die Plots sich eingependelt haben, werde ich die hier zur Schau stellen.

[jamesgo]

bin gespannt wie das funktioniert.

Ich habe heute Nachmittag einen Parameter "maxOffTimeMode" bei PWM implementiert. Mögliche Werte sind "max,1,2,3".
"max" entspricht der aktuellen Logik (möglichst viele Räume im Status maxOffTime zusammenfassen).
Die Werte 1, 2 oder 3 geben an wieviele Räume durch maxOffTime gleichzeitig auf "on" geschalten werden dürfen.

Ich möchte noch ein bisschen testen und werde die Module vorab hier hochladen.

[jamesgo]

Hier die beiden Module zum testen.

Beim PWM gibt es nun zwei Attribute:

maxOffTimeCalculation [on|off] - bisher wurde mit "set ... maxOffTimeCalculation .." ein Reading erzeugt. Jetzt ist es ein Attribut mit einem internal c_maxOffTimeCalculation. (das set gibt es aber noch). Das Reading wird automatisch in ein Attribut umgewandelt. Aber bitte trotzdem kontrollieren ob das Attribut nach der ersten Kalkulation da ist.

maxOffTimeMode [max,1,2,3] - bisheriges Verhalten entspricht "max"; "1" bedeutet maxOffTime kann Gleichzeitig nur für einen Raum gelten. Die Werte "2" und "3" entsprechend. Der aktuelle Wert wird auch in c_maxOffTimeMode gespeichert (wobei "max" in 999 umgewandelt wird)

[Skusi]

So, der erste Tag mit dem eigenen PWM fürs Wohnzimmer war nicht so erfolgreich.
Irgendwie fing es nachts recht gut an mit dem abwechseln der Kreise, aber dann schein irgendwas aus dem Lot geraten zu sein.

Es wurde nur noch ein Kreis angefahren und nicht mehr ausgeschaltet. Die anderen kamen nicht zu Zuge. Ich hab da manuell etwas nachgeholfen (zwischen 12 in 1 Uhr), deswegen ist der Plot nicht zu genau zu nehmen. In meiner Mittagspause gucke ich dann immer von ferne rein was abgeht. Bis dahin war stundenlang nur der Essbereich auf, und alle Pulse bei über 1 !!! Obwohl doch der Max Pulse nur 0.95 sein soll.

Das Wohnzimmer ist dementsprechend nicht auf soll Temp gekommen.

Dann hab ich eben neu gestartet, und folgende Meldung im Log gefunden:

PERL WARNING: Use of uninitialized value in string ne at ./FHEM/93_PWMR.pm line 629, <$fh> line 2015.
2021.02.01 17:26:15 1: Error: >FBH_Regler_WZ< has no TYPE, but following keys: ><

Außerdem war das FBH_Regler_WZ Device dann nicht angelegt.
Im .cfg steht es aber drinn !?

Dann hab ich es nochmal angelegt un dnun experimetier ich mal mit kürzeneren Cycletimes und Intervalen

Irgenwie ist das alles sehr komisch und empfindlich. Ich hab ein bischen Angst mir alles zu zerschießen.

Wie kann ein pulseAvg3 0.97 sein, wenn alle 3 PWMR dieses Masters einen Pulse von 0.95 haben ?

Im Logfile:

Code Auswählen Erweitern

2021.02.01 18:11:53 3: PWM Define FBH_Regler_WZ
2021.02.01 18:11:58 3: PWM_Calculate FBH_Regler_WZ
2021.02.01 18:11:58 3: PWM_CalcRoom FBHK_Esszimmer: F9 stay on
2021.02.01 18:11:58 3: PWM_CalcRoom FBHK_Wohnz.Kamin: F2 new on
2021.02.01 18:11:58 3: PWM_CalcRoom FBHK_Wohnz.Terrasse: F1 stay on
2021.02.01 18:11:58 3: PWM_Calculate FBHK_Wohnz.Kamin: F98 switch on (pulse=1)
2021.02.01 18:11:58 3: PWM_Calculate FBHK_Wohnz.Kamin: F97 keep room off (pulse=1) (max=1)
2021.02.01 18:11:58 3: PWM_Calculate FBH_Regler_WZ done

Def:    (zum Testen)
30 900 30 0.95 1,3 0,2,0.6 Waermebedarf_WZ,0.6,300,,180

Ich bereue schon fast das ich das Angefasst habe...
Never change....

[jamesgo]

... und alle Pulse bei über 1 !!! Obwohl doch der Max Pulse nur 0.95 sein soll.

Räume die warten, bis sie dran sind, bekommen einen Bonus in jedem Zyklus ($roomsWaitOffset{$wkey} += 0.0001;). Dann kann der Puls sehr langsam höher werden.

PERL WARNING: Use of uninitialized value in string ne at ./FHEM/93_PWMR.pm line 629, <$fh> line 2015.
2021.02.01 17:26:15 1: Error: >FBH_Regler_WZ< has no TYPE, but following keys: ><

Außerdem war das FBH_Regler_WZ Device dann nicht angelegt.
Im .cfg steht es aber drinn !?

Code Auswählen Erweitern

Zeile 629 im PWMR ist folgendes
if ( $defs{$iodevname}->{TYPE} ne "PWM" ) {
    return "wrong type of $iodevname (not PWM)" if ($init_done == 1);
  }

Der Raum schaut nach ob der erste Parameter seiner Definition tatsächlich ein PWM ist.
Ich vermute dass in deinem fhem.cfg erst die PWMR's stehen (weil du sie ja schon lange hast) und das neue PWM erst dahinter. D.h. beim "define xxx PWMR xxxxx" gibt es das PWM noch nicht.

Da hilft die PWMR's löschen und neu anlegen (dann stehen sie hinten) oder fhem zu stoppen und die fhem.cfg zu editieren.