Fussbodenheizung mit PWM steuern

[Skusi]

@ jamesgo

Mal eben ne kurze Zweischenfrage:

Was sagt mir das Internal OverallHeatingSwitch_roomBased ?

Ich hab nix in der Commandref gefunden ?

[RainerS]

@R2D2_ In einem Einfamilienhaus kann ich das noch nachvollziehen. Der hydraulische
Abgleich ist i.o.
Da aber dem einem Bewohner eine höhere Temperatur dem anderen eine
niederige Temperatur lieber ist gibt es kein optimum für einen Mischerkreis an dem mehrere Wohnungen hängen.

Da hast Du natürlich Recht !  Aber bitte keine PWM in einem Effizienz-Einfamilienhaus.

[jamesgo]

Hallo Skusi,

Code Auswählen Erweitern


overallHeatingSwitch>[,<pulseMaxThreshold>[,<followUpTime>[,<regexp_on>]]]

Universal switch to controll eg. pumps or the heater itself. It will be set to "off" if no heating is required and otherwise "on".
pulseMaxThreshold defines a threshold which is applied to reading maxPulse of the PWM object to decide if heating is required. If (calculated maxPulse > threshold) then actor is set to "on", otherwise "off".

If pulseMaxThreshold is set to 0 (or is not defined) then the decision is based on roomsOn. If (roomsOn > 0) then actor is set to "on", otherwise "off".

followUpTime defines a number of seconds which is used to delay the status change from "on" to "off". This can be used to prevent a toggling switch.
regexp_on defines a regular expression to be applied to the state of the actor. Default is "on". If state matches the regular expression it is handled as "on", otherwise "off".

Es gibt also zwei Varianten den overallHeatingSwitch zu steuern:
- über die pulseMaxThreshold - einem Grenzwert des Heizbedarfs
- wenn mindestens ein Raum auf "on" steht

Wenn eine Threshold benutzt wird steht OverallHeatingSwitch_roomBased auf off ansonsten auf on.

Du wolltest auch noch etwas zu NoRoomsToStayOff/NoRoomsToStayOn und MaxSwitchOffPerCycle/MaxSwitchOnPerCycle wissen.

Folgende Definitionen hast du verwendet:

Code Auswählen Erweitern

FB_Heizung: 60 3600 400 0.85 3,3 3,3,0.25 FBH_Regler_Nebenraeume_Badarf,0,120
FBH_Regler_Wohnzimmer:60 3600 400 0.85 99,99 1,2,0.25 FBH_Regler_Wohnz_Badarf,0,240


Ich verwende z.B.

Code Auswählen Erweitern



define FB PWM 60 900 120 0.85 1,1 3,1,0.25 OverallHeatingSwitch,0.26,120

define <name> PWM [<interval>] [<cycletime>] [<minonofftime>] [<maxPulse>] [<maxSwitchOnPerCycle>,<maxSwitchOffPerCycle>] [<roomStayOn>,<roomStayOff>,<stayOnThreshold>] [<overallHeatingSwitch>[,<pulseMaxThreshold>[,<followUpTime>[,<h_regexp_on>]]]]


roomStayOn / stayOnThreshold:
D.h. wenn die 3 Räume mit dem größten Wärmebedarf mindestens einen durchschnittlichen Puls von 0.25 haben, dann bleiben diese 3 Räume auf "on" auch wenn durch die 0.85 gerade ein "off" notwendig wäre. Es wird also nie nur ein Raum auf "on" sein solange ein gewisser Wärmebedarf besteht.

roomStayOff
Anzahl der der Räume die maximal gleichzeitig "on" sind = Anzahl der Räume - roomStayOff
(11 Räume - roomStayOff(=1) -> maximal 10 auf "on")

Jetzt hatte ich das Problem, dass Esszimmer/Küche offen sind (folglich nur eine Temperatur gemessen werden kann) und das Wohnzimmer zwei Heizkreise hat. Die nun entstehenden Pulse kann man nun gegeneinander verschieben indem die Zeiten für das Ende der Nachtabsenkung geringfügig variieren (5-10 Minuten) oder der Faktor geringfügig abweicht (z.B. 1.0 und 0.98). In der Praxis hat es trotzdem dazu geführt dass die Pulse dazu tendierten gleichzeitig zu schalten.

Die Abhilfe: <maxSwitchOnPerCycle>,<maxSwitchOffPerCycle> (bei mir 1,1)
Die Räume schalten nacheinander (beim mir im Abstand von 60 sekunden) auf "on" (da pro Zyklus nur einer auf "on" schalten kann) und nacheinander auf "off". Schaltet ein Raum auf "off" kann gleichzeitig ein anderer auf "on" schalten. D.h. das Schalten von Räumen mit identischem Puls geschieht nicht mehr gleichzeitig sondern nacheinander. (bei 10 Heizkreisen dauert es also 10 Minuten bis morgens alle auf "on" sind)

Das führte dazu, dass die Heizung nicht auf 30% sondern ziemlich schnell auf 75% lief und die Spreizung VL/RL nur noch sehr klein war (<5). Die Veringerung der Durchflussmenge führte dazu dass die Rücklauftemperatur niedriger wurde, es an kälteren Tagen nicht richtig warm wurde.

Die 0.85 (maxPulse) führte dazu, dass Heizkreise auf "off" gezwungen wurden und die RL Temperatur niedriger wurde. Wird in vielen Räumen Wärme benötigt werden langsam alle auf "on" geschalten - im Gegenzug aber auch einige wieder auf "off".

Ich habe mit Pulslängen von 15 und 30 Minuten experimentiert und keinen wesentlichen Unterschied festgestellt. Wie es sich bei 60 Minuten verhält kann ich nicht sagen.

Habe ich dir die Parameter nun ein bisschen näher gebracht?

Grüße
Andy

[Skusi]

Hallo, jamesgo

erstmal vielen Dank für Deine Zeit und Geduld mir mir.

Mein Problem ist nicht das Verständniss, sondern eher das ich wieder mal als Perfektionist das Beste rausholen will. Meine Vision ist hat eine effiziente intelligente Steuerung die, wenn einmal richtig konfiguriert, alles selbständig regelt und den schmalen Grad zwischen Komfort (Ehefrau) und Energiekosten geht. Deshalb muß ich die Interne denkensweise Deines Modules komplett verstehen um die Parameter für meine Problem - Heizung optimal zu setzten.

Wenn eine Threshold benutzt wird steht OverallHeatingSwitch_roomBased auf off ansonsten auf on.

e

Sagt also nur was über die Art des define aus, nicht über eine interne Entscheidung. !?

Den Rest dazu hab ich wohl im commandref überlesen. ...sorry !

Die Räume schalten nacheinander (beim mir im Abstand von 60 sekunden) auf "on" (da pro Zyklus nur einer auf "on" schalten kann) und nacheinander auf "off"

Das bezieht sich also auf die Interval Zeit und nicht wie ich aus der commandref entnommen hätte auf die Cycletime.

Dann ist die Wortwahl "maxSwitchOnPerCycle,maxSwitchoffPerCycle" etwas irreführend. Aber egal, ich hab mir schon sowas gedacht. Ein schalten pro Stunde wäre auch nicht fein.

Warum hast Du 0.85 (maxPulse) gewählt ? Das soll doch nur vermeiden das ein Kreis lange auf 100% läuft und damit das einschalten des nächsten verhindert. Also würde doch auch ein MaxPulse von 95 funktionieren - oder. So nutze ich meine Pulszeit doch breiter aus.

Ich habe mit Pulslängen von 15 und 30 Minuten experimentiert und keinen wesentlichen Unterschied festgestellt. Wie es sich bei 60 Minuten verhält kann ich nicht sagen.

Ich hab nun auch mal auf 1800 umgestellt und studiere die Logs. Bis jetzt kann ich auch noch keinen großen Schlüssen ziehen. Problem ist auch immer das sich das Wtter gerade wieder so arg geändert hat. Das macht alles studieren sehr schwer. Kann sich diese Natur nicht mal an Fhem halten  ? Wer schreibt mal das Modul ? 

Jedenfalls bin ich begeistert von Deiner Arbeit. Leider hast Du mir damit ein Werkzeug in die Hand gegeben das mich viel Zeit kostet die ich nicht habe.....

Irgendwann hab ich es aber "Die Macht wird mit mir sein... immer"

[jamesgo]

Hallo Skusi,

kein Problem:

(1 - 0.85) * 900 sec = 135 sec --> ein bisschen größer als meine min on/off time
(1 - 0.95) * 900 sec = 45 sec  --> kleiner als meine min on/off time

Grüße
Andy

[Skusi]

Hallo,

Ich habe nun meine Pumpe + Kessel  über pulseMaxThreshold gesteuert.

Mir fällt auf das der maxPulse Wert immer sehr niedrig ist, obwohl ich einen Raum habe der ständig einen Pulse von 85 hat.
Im Moment z.B. habe ich einen Raum mit 85, einen mit 15 und einen mit 27 Puls, und die maxPulse steht bei 0.1908.

Mein Heating Switch ist off bei einem Threshold von 0.23 !?

Müßte der Kessel nicht freigegeben sein weil doch eine Raum schon 85 verlangt ?

Wie wird maxPulse berechnet ?

Außerdem verstehe ich nicht so ganz wie die roomsToStayOnList zustande kommt. Da stehe im Moment 2 Räume drin die Pulse 0 haben. Sollten da nicht dei Räume stehen die dem höchsten Puls haben ?

[jamesgo]

Hallo Skusi,

pulseMax geht von 0 bis 1. PWMPulse und energyusedp sind mit 100 multipliziert, damit sie im Tablet-UI verwendet werden können.

pulseMax ist das Maximum der Pulse, die an einem PWM hängen.

pulseSum die Summe für die Räume aus roomsToStayOnList. Die Anzahl entspricht roomsToStayOn.

MaxPulse kommt aus der Definition des PWM Objektes.

Hast du wirklich alle Räume am selben PWM Objekt?

Grüße
Andy

[jamesgo]

Hallo Andy,

es ist genau anders herum. ro.Kz ist PWMR. Die Blaue Kurve ist energyusedp des PMWR Moduls. Hier sieht man deutlich,
das Regelabweichung max ca. 0,5° beträgt.  Der Temp Anstieg entsteht dann im wesentlichen durc den Vorlauf Boost.

Die oberen beiden Charts HzSz sind PID20.

Wie beschrieben ist die Fussbodenheizung in einem Mehr Parteien Haus installiert.

Die Kessel und VorlaufSteuerung ist daher nicht zu beeinflussen.

Die VorlaufTemp wird durch eine zentrale Steuerung der Heizungsanlage in Abhängigkeit der
Aussentemp geregelt. Hier gibt es eine Nachtabsenkung, welche mit dem 1 Std. Temp Boost bendet
wird. Die Vorlauf Temp ist in der Wohnung nicht zu steuern.

Die Stellgröße ist in sec offen aufgetragen. Die Zykluszeit beträgt 12 min (720 sec). Dh. 5 Zyklen pro std.
Bei PID ist zunächst Ist 0,2° über Soll die Offen zeit geht von 150 sec auf 120 sec zurück. (120 sec minimum um auf/zu des Stellantriebs
zu kompensieren).
Dann Ist = Soll Offen steigt auf 230 sec  und dann auf über 300 sec. Danach durch  Wärmemengenboost
geht die offen Zeit bis auf 120 sec (zu) zurück. Die eingebrachte Wärmemenge reichte bis ca. 12h um die Temp
über soll zu halten. Der Stellantrieb ist solange zu. AB 12 Uhr gibt es wieder Heizbedarf und der Regler macht wieder auf.

Die Regelabweichung nach unten ist sehr klein ca. 0.1° (Die Messgenauigkeit ist auch nicht größer.) Nach oben ca.0.3°
bedingt durch die quasi Störgröße "erhöhte VL" um 7 uhr.

@R2D2_ In einem Einfamilienhaus kann ich das noch nachvollziehen. Der hydraulische
Abgleich ist i.o. Da aber dem einem Bewohner eine höhere Temperatur, dem anderen eine
niederige Temperatur lieber ist gibt es kein Optimum für einen Mischerkreis an dem mehrere Wohnungen hängen.
Der Heizungsservicetechniker stellt lieber eine zu hohe LieferWärmemenge (dh. VL Temp) ein.
Die Modulation der Wärmemenge pro Raum ist hier die einzige Lösung. Die Gesamt Wärmemenge durch
das Wohnungsstellventil einzustellen hilft auch nicht, da Nord- Südseite, Sonneneinstahlung, Schlafzimmer kühler als Wohnzimmer,
suboptimale Heizkreisaufteilung in der Wohnung, gegen die Regelung der Wärmemenge über die VL Temp sprechen.

Ich hoffe ich konnte die Situation etwas klarer beschreiben. Ich bin der Auffassung, das die Integration eines PID Algos. in das tolle
PWM Modul das ganze optimieren könnte.

Grüsse

Hallo My-FHEM,

kannst du bitte mal für den Raum den actorState plotten und die beiden Charts zusammen mit der Definition des PWM und PWMR Objekts zur Verfügung stellen?

Danke
Andy

[Skusi]

Ich glaube ich hab mich im letzten Post etwas mit den Readings vertan.

@jamesgo

Statt maxPulse meinte ich natürlich pulseMax !
Sorry , kann man ja uch schnell durcheinander kriegen.

pulseSum die Summe für die Räume aus roomsToStayOnList. Die Anzahl entspricht roomsToStayOn.

Ok, also nicht dei Summe aller anligenden Pulse !? Echt nur die der rommToStayOnList !?

Hast du wirklich alle Räume am selben PWM Objekt?

Ja, ich hab ja auch die passende roomsAktiv Anzahl. Hab es auch nochmal in allen PWMR geprüft.

Kann es mit den verbose Leveln was zutun haben. Ich hatte einige PWMR´s auf verbose 0 gestellt.

Was ich auch nicht begreife ist warum die PWM Pulse so zittern:

Code Auswählen Erweitern

2016-01-13_19:10:55 FBH_Schlafzimmer PWMPulse: 20
2016-01-13_19:11:13 FBH_Schlafzimmer PWMPulse: 31
2016-01-13_19:12:08 FBH_Schlafzimmer PWMPulse: 20
2016-01-13_19:13:30 FBH_Schlafzimmer PWMPulse: 31
2016-01-13_19:14:00 FBH_Schlafzimmer PWMPulse: 20
2016-01-13_19:15:08 FBH_Schlafzimmer PWMPulse: 31


die werden doch nur jede Minute neu berechnet !??


Ich verstehe es einfach nicht:

Zeitgleich im PWMR:
PWMPulse 47

Aber im PWM:
pulseMax 0.2712 (also doch 27 %)


---Skusi

[Skusi]

Jetzt hab ich mal gestern einen Raum nach dem Anderen auf das zweite PWM Modul das noch brach lag umgeswitcht.
Der pulseMax war auch dann Raum für Raum immer auf dem Level des höchsten PWM Pulse. Also hab ich letztendlich alle Räume übertragen und das  erste PWM Modul gelöscht. Auch danach sah der pulseMax immernoch plausibel aus.
Nun habe ich die def auf einen vernünftigen OverallHeatingSwitch_threshold gesändert und war guter Dinge das mein Kessel nun lastabhängig schaltet.
Zur überprüfung habe ich den pulseMax mitgelogged.

Nun komme ich nach Hause und muß feststellen das der pulseMax wider zittert wie blöd, und mein Kessel zeitweise zu häufig on und off schaltet.
Der aktuelle pulseMax ist auch wieder völlig daneben. Mein hungrigster Raum will 13 % PWM und der pulseMax steht bei 0.064

Eigentlich sollte die Kurve pulseMax doch recht ruhig verlaufen. Jeden Zyklus wird doch ein neuer PWM Pulse für jeden Raum berechnet. Da die Temperatur in den Räumen ja auch nicht springt, kann doch der neue Pulse auch nicht ewig weit vom vorigigen weg sein. Also sollte doch auch  der pulseMax entsprechend schlank ansteigen oder absinken, damit man da einen vernüftigen Schaltpunkt für den Kessel definieren kann.

Übrigen wäre es noch schön wenn es einen Art Totzone für den OverallHeatingSwitch_threshold gäbe.
Sonst wird mir der Kessel (wenn es denn mal sauber klappt) wegen jeder kleinen Änderung des pulseMax geschaltet.

Anbei mal eine kleinen Plot wo man den Verlauf des pulseMax sehen kann.

---Skusi

[My-FHEM]

@Andre

Hallo My-FHEM,

kannst du bitte mal für den Raum den actorState plotten und die beiden Charts zusammen mit der Definition des PWM und PWMR Objekts zur Verfügung stellen?

Danke
Andy

Kann erst kommende Woche diese Charts liefern. Wenn noch zusätzliche Infos gebraucht werden, bitte melden.

Grüße

[kojote006]

Hallo,

Ich habe bei mir Die Module versucht zu Testen.
Leider bleibt FHEM dann einfach stehen bzw. Friert ein.

Hier die letzte Zeile des Logfiles:

Code Auswählen Erweitern

Can't use string ("fh") as a HASH ref while "strict refs" in use at ./FHEM/98_XmlList.pm line 79.

Wenn ich in der FHEM cfg wieder die 2 Module deaktiviere und den Rpi Neustarte läuft es wieder.
Hier der Auszug der FHEM. Cfg

Code Auswählen Erweitern

############# PWM FBH_EG_Bad #####################
#define fh PWM 60 900 120 1 99,99 0,0,0
#attr fh room FB_Regler

#define PWM_Fbh_EG_Bad PWMR fh 1,0 EG_Bad_Temp_Climate:measured-temp 4fachRelais_Sw_03
#attr PWM_Fbh_EG_Bad room FB_Regler
#attr PWM_Fbh_EG_Bad autoCalcTemp 0
#attr PWM_Fbh_EG_Bad room FB_Regler
#attr PWM_Fbh_EG_Bad tempDay 23
#attr PWM_Fbh_EG_Bad tempEnergy 22.5
#attr PWM_Fbh_EG_Bad tempNight 22
#attr PWM_Fbh_EG_Bad tempRule1 Mo-Fr 4:00,d 10:30,e 14:30,d 18:00,n
#attr PWM_Fbh_EG_Bad tempRule2 Sa-So 5:00,d 20:00,n
#set PWM_Fbh_EG_Bad desired-temp 22.5

Ich hoffe mir kann da jemand helfen.
Gruß Holger

[Skusi]

Code Auswählen Erweitern

#define PWM_Fbh_EG_Bad PWMR fh 1,0 EG_Bad_Temp_Climate:measured-temp 4fachRela

Tausch mal das komma im Faktor gegen einen Punkt.

.... Skusi

[jamesgo]

scharfes Auge!

Das Komma hätte ich nicht gesehen.

Kannst du sagen was/wie die XML Liste abgerufen wird? Ich hatte mal das Problem, dass andFHEM (Android App) eine Abfrage generiert hat, die einen Absturz verursacht hat ... das sollte zwar behoben sein aber deine Fehlermeldung bezieht sich nur indirekt auf das Modul.

Ansonsten mal checken ob die letzte Version verwendet wurde und auch FHEM akutell ist.

Falls der Fehler bleibt, bitte das Logfile nach einem Restart von Anfang an posten.

Grüße
Andy

[My-FHEM]

Hallo Andy,

anbei die gewünschten Plots.

Grüße