Hallo zusammen,
in Vorbereitung auf die Inbetriebnahme nächsten Winter (dann soll das Haus fertig werden), habe ich einen Multi-PID-Heizungsregler als Wiregate-Plugin entwickelt.
Name: "Heizungsregler.pl"
Features:
* Beliebig viele Räume, in diesen beliebig viele Heizkreisläufe.
* Sensoren (pro Heizkreislauf oder pro Raum): Vorlauf, Rücklauf, Estrich, Luft. Auch mehrere Sensoren in jeder Kategorie möglich, über die dann gemittelt wird.
* Falls die Vorlauftemperatur über eine KNX-GA steuerbar ist, kann der Regler auch dieses tun.
* Vorteil einer PID-Regelung gegenüber PI ist (grundsätzlich), dass der D-Anteil "vorausschauend" ist, und zwar um die sog. "Vorhaltezeit". Das sollte (in der Theorie) Überschwinger vermeiden und den Regler etwas aggressiver machen, außerdem hat es Vorteile bei sehr trägen Heizungsformen (PT2-Regelstrecke, z.B. Fussbodenheizung). Ansonsten ist es wie ein PI-Regler.
* Die Parameter (Proportionalbereich, Vorhaltezeit, Nachstellzeit, Wind-up-Begrenzung im Integralanteil) sind pro Raum einzeln festlegbar
* Stellt man in einem Raum die Solltemperatur auf den speziellen Wert von -1 Grad, so beginnt ein Optimierungszyklus: die Heizung dreht maximal auf (besser mit kaltem Zimmer starten) und analysiert die daraus folgende Temperaturkurve ("Sprungantwort") des Raumes. Daraus werden die "optimalen" obigen Parameter ermittelt (hier war einiges Experimentieren nötig, aber jetzt isses glaub ich ok). Am Ende des Optimierungszyklus springt die Solltemperatur auf die letzte gewählte "normale" Solltemperatur zurück, die optimierten Werte für diesen Raum werden für alle Zukunft in das Konfigurationsfile zurückgeschrieben (stehen also auch nach einem Reset genau so zur Verfügung), und der Regler wechselt in den Regelmodus.
* Als echter "Multi"-Regler kann das Plugin natürlich in einem Raum regeln, in einem anderen optimieren und in einem dritten ausgeschaltet sein.
Entwicklungsstand:
* BETA-Stadium (oder ALPHA, wie man es sehen will).
* Da ich erstens noch kein Haus habe und zweitens nicht für jeden Testlauf Gas verheizen und tagelang warten wollte, habe ich eine Simulationsumgebung programmiert - ein Perl-Skript, das dem Plugin die Umgebung des wiregated-Daemons vorgaukelt sowie eine simulierte Uhr im Zeitraffer.
* Die Simulation umfasst auch einen einfachen "KNX-Bus" vor (also knx_write/knx_read sowie $plugin_subscribe funktionieren). Daher läuft der gleiche Code des Plugins in der Simulation wie auch auf dem Wiregate - nur dass in der Simulation auf einer schnellen Linux-Maschine drei Tage auf zwei Minuten verkürzt werden. (Übrigens läuft auch ChrisMs Multi-RTR.pl in der Simulation ohne jede Anpassung).
* Zwischendurch werden Fenster geöffnet (und dies über KNX auf dem Bus gemeldet), dann wird ein Kamin angeschaltet und heizt zu, der User verändert die Solltemperatur (KNX-Busmeldung), usw.
* Die physikalischen Eigenschaften des zu heizenden Zimmers (Wasser heizt Estrich, Estrich heizt Raum, Raum kühlt nach außen ab) werden durch Runge-Kutta-Schritte der entsprechenden (einfachen) Differentialgleichungen simuliert.
* Selbstverständlich funktioniert die Heizungsregelung in der Simulation prima - sonst würde ich hier nichts posten. Auch sind Vorteile der PID- vs PI-Regelung klar erkennbar, und selbstverständlich auch Vorteile der automatischen Optimierung über Sprungantwortanalyse.
* Grafische Darstellungen (RRDs) sind im Regler noch nicht "drin". Auch fehlt ein Feature, das verschiedene Heizkreisläufe im gleichen Raum so regelt, dass der Fussboden gleichmäßig warm ist (aktuell werden alle Ventile eines Raumes gleich angesteuert).
Der nächste Schritt wäre das Ausprobieren in einem realen Haus. Nur ist die Heizungsperiode vorbei :-(
Frage: ist jemand, der aktuell den Wiregate zur Heizungssteuerung einsetzt, möglichst viele Temperaturfühler hat (Vor/Rücklauf, Estrich...) und vielleicht sogar eine Wärmepumpe mit über KNX einstellbarer Vorlauftemp., und der um diese Jahreszeit noch heizt, bereit, einen Test des neuen Plugins unter Echtbedingungen zu machen? Als "Vorgeschmack" kopiere ich unten mal das Konfigurationsfile ein (nicht über "eibshort" wundern, das ist nur meine Art, nackte GA-Adressen zu vermeiden, ich nutze einfach die GA-Namen über ein spezielles Lookup-Hash).
Viele Grüße,
Fry
in Vorbereitung auf die Inbetriebnahme nächsten Winter (dann soll das Haus fertig werden), habe ich einen Multi-PID-Heizungsregler als Wiregate-Plugin entwickelt.
Name: "Heizungsregler.pl"
Features:
* Beliebig viele Räume, in diesen beliebig viele Heizkreisläufe.
* Sensoren (pro Heizkreislauf oder pro Raum): Vorlauf, Rücklauf, Estrich, Luft. Auch mehrere Sensoren in jeder Kategorie möglich, über die dann gemittelt wird.
* Falls die Vorlauftemperatur über eine KNX-GA steuerbar ist, kann der Regler auch dieses tun.
* Vorteil einer PID-Regelung gegenüber PI ist (grundsätzlich), dass der D-Anteil "vorausschauend" ist, und zwar um die sog. "Vorhaltezeit". Das sollte (in der Theorie) Überschwinger vermeiden und den Regler etwas aggressiver machen, außerdem hat es Vorteile bei sehr trägen Heizungsformen (PT2-Regelstrecke, z.B. Fussbodenheizung). Ansonsten ist es wie ein PI-Regler.
* Die Parameter (Proportionalbereich, Vorhaltezeit, Nachstellzeit, Wind-up-Begrenzung im Integralanteil) sind pro Raum einzeln festlegbar
* Stellt man in einem Raum die Solltemperatur auf den speziellen Wert von -1 Grad, so beginnt ein Optimierungszyklus: die Heizung dreht maximal auf (besser mit kaltem Zimmer starten) und analysiert die daraus folgende Temperaturkurve ("Sprungantwort") des Raumes. Daraus werden die "optimalen" obigen Parameter ermittelt (hier war einiges Experimentieren nötig, aber jetzt isses glaub ich ok). Am Ende des Optimierungszyklus springt die Solltemperatur auf die letzte gewählte "normale" Solltemperatur zurück, die optimierten Werte für diesen Raum werden für alle Zukunft in das Konfigurationsfile zurückgeschrieben (stehen also auch nach einem Reset genau so zur Verfügung), und der Regler wechselt in den Regelmodus.
* Als echter "Multi"-Regler kann das Plugin natürlich in einem Raum regeln, in einem anderen optimieren und in einem dritten ausgeschaltet sein.
Entwicklungsstand:
* BETA-Stadium (oder ALPHA, wie man es sehen will).
* Da ich erstens noch kein Haus habe und zweitens nicht für jeden Testlauf Gas verheizen und tagelang warten wollte, habe ich eine Simulationsumgebung programmiert - ein Perl-Skript, das dem Plugin die Umgebung des wiregated-Daemons vorgaukelt sowie eine simulierte Uhr im Zeitraffer.
* Die Simulation umfasst auch einen einfachen "KNX-Bus" vor (also knx_write/knx_read sowie $plugin_subscribe funktionieren). Daher läuft der gleiche Code des Plugins in der Simulation wie auch auf dem Wiregate - nur dass in der Simulation auf einer schnellen Linux-Maschine drei Tage auf zwei Minuten verkürzt werden. (Übrigens läuft auch ChrisMs Multi-RTR.pl in der Simulation ohne jede Anpassung).
* Zwischendurch werden Fenster geöffnet (und dies über KNX auf dem Bus gemeldet), dann wird ein Kamin angeschaltet und heizt zu, der User verändert die Solltemperatur (KNX-Busmeldung), usw.
* Die physikalischen Eigenschaften des zu heizenden Zimmers (Wasser heizt Estrich, Estrich heizt Raum, Raum kühlt nach außen ab) werden durch Runge-Kutta-Schritte der entsprechenden (einfachen) Differentialgleichungen simuliert.
* Selbstverständlich funktioniert die Heizungsregelung in der Simulation prima - sonst würde ich hier nichts posten. Auch sind Vorteile der PID- vs PI-Regelung klar erkennbar, und selbstverständlich auch Vorteile der automatischen Optimierung über Sprungantwortanalyse.
* Grafische Darstellungen (RRDs) sind im Regler noch nicht "drin". Auch fehlt ein Feature, das verschiedene Heizkreisläufe im gleichen Raum so regelt, dass der Fussboden gleichmäßig warm ist (aktuell werden alle Ventile eines Raumes gleich angesteuert).
Der nächste Schritt wäre das Ausprobieren in einem realen Haus. Nur ist die Heizungsperiode vorbei :-(
Frage: ist jemand, der aktuell den Wiregate zur Heizungssteuerung einsetzt, möglichst viele Temperaturfühler hat (Vor/Rücklauf, Estrich...) und vielleicht sogar eine Wärmepumpe mit über KNX einstellbarer Vorlauftemp., und der um diese Jahreszeit noch heizt, bereit, einen Test des neuen Plugins unter Echtbedingungen zu machen? Als "Vorgeschmack" kopiere ich unten mal das Konfigurationsfile ein (nicht über "eibshort" wundern, das ist nur meine Art, nackte GA-Adressen zu vermeiden, ich nutze einfach die GA-Namen über ein spezielles Lookup-Hash).
Viele Grüße,
Fry
Code:
#!/usr/bin/perl
#
# Konfiguration ##########################################
#
# Raeume, Messfuehler und Heizkreislaeufe definieren
# Jeder Raum hat einen eigenen Regler. Die Bezeichnungen der Raeume sind
# beliebig, sie duerfen aber keinen Underscore ("_") enthalten.
#
# Ueber mehrere Sensoren eines Raumes inklusive aller seiner Heizkreislaeufe
# wird gemittelt (egal wie oft eine GA in der Struktur auftaucht, sie wird
# nur einfach gewichtet).
# Falls kein Sensor im Raum definiert ist oder antwortet, wird der Haussensor
# genommen.
#
# Falls inflow und outflow weder im Raum noch zentral im Haus definiert
# oder verfuegbar sind, wird der global definierte fixe Spread angenommen.
# (Spread = Vorlauf- minus Ruecklauftemperatur = inflow-outflow). Fehlt auch
# dieser, so faellt die Regelung aus, sobald der Spread mit den vorhandenen
# Werten nicht ermittelt werden kann.
#
# Eine komplette, minimale Konfiguration fuer zwei Zimmer sieht daher aus:
#
#%house=(
# cycle=>60,
# spread=>20,
# Zimmer1=>{control=>'1/2/4', sensor=>'1/2/3'},
# Zimmer2=>{control=>'1/2/14', sensor=>'1/2/13'},
# );
#
# Hierbei gibt es genau eine Wunschtemperatur und einen Messfuehler pro Raum.
# Der Spread ist dabei fix mit 20K angenommen.
%house=(
# Taktung des Reglers, Anzahl Sekunden zwischen Regleraufrufen
# Es macht durchaus Sinn, den Regler haeufiger laufen zu lassen als die
# Sensoren ausgelesen werden. Das sollte zu einem ruhigeren Regler fuehren.
cycle => 60,
# Anzahl der Datenpunkte fuer Trendberechnung
mindata => 15,
# Falls die Heizung ueber eine einstellbare Vorlauftemperatur verfuegt,
# so kann hier eine GA fuer die Wunsch-Vorlauftemperatur festgelegt werden,
# sowie eine maximale Vorlauftemperatur. Vorsicht! Bitte nur benutzen, wenn
# die tatsaechliche Vorlauftemperatur auch gemessen werden kann!
inflow_control => '1/2/3', # GA zum Setzen der Soll-Vorlauftemperatur
inflow_max => 40, # maximale Soll-Vorlauftemperatur
# Der Spread, oder die Spreizung, ist die Differenz zwischen Vorlauftemperatur
# und Ruecklauftemperatur. Falls entsprechende Messfuehler entweder nicht
# konfiguriert oder nicht auslesbar sind, wird der hausuebergreifende Wert
# genommen, der hier steht. Falls in einem solchen Fall auch hausueber-
# greifend kein Wert konfiguriert ist steht, faellt die Heizung aus.
# Faustregel: Thermentemperatur minus Raumtemperatur
# inflow => '1/2/3', # hausweite Vorlauftemp, falls nicht raumweise messbar
# outflow => '1/2/3', # hausweite Ruecklauftemp, falls nicht raumweise messbar
spread => 20, # hausweite Spreizung, falls alle Stricke reissen
# Die Gruppenadressen fuer
# sensor (Ist-Temperatur im Raum),
# window (Fensterkontakte, dpt-Typ 1, Wert 1 bedeutet offen)
# floor (Estrichtemperatur),
# inflow (Vorlauftemperatur) und
# outflow (Ruecklauftemperatur)
# koennen jeweils auf Raum- und/oder Heizkreislaufebene definiert
# sein und koennen einzelne GAs oder Listen von GAs sein. Wenn alle diese
# Messfuehler fehlen, so werden die hausweiten Sensoren oben genommen.
# Falls die auch fehlen, wird der fixe Spread weiter oben genommen.
# Wenn der auch noch fehlt, arbeitet der Regler nicht.
WZ => {
control => $eibshort{TS_WZ}{ga}, # GA zum Setzen der Solltemperatur
# Raumtemperaturfuehler (Liste oder nur einer)
# sensor => ['1/2/3','1/2/3','1/2/3'],
sensor => $eibshort{TL_WZ_Sofa}{ga},
# Vorlauftemperatur, kann auch pro Kreislauf definiert sein
inflow => $eibshort{TO_Zentralvorlauf}{ga},
# Fensterkontaktabfrage
window => [$eibshort{KF_WZ_West_L}{ga}, $eibshort{KF_WZ_West_R}{ga}],
# Heizkreislaeufe, aktuell werden alle gleich gesteuert
# (Ausgleich fuer gleiche Estrichtemp. noch nicht implementiert)
circ => {
WZ_Nord => {
actuator => $eibshort{VS_WZ_Mitte}{ga}, # Stellventil
floor => $eibshort{TE_WZ_Mitte}{ga}, # Estrichfuehler
# outflow => '1/2/3', # Ruecklauf
},
# WZ_Mitte => {
# actuator => '1/2/3', # Stellventil
# outflow => '1/2/3', # Ruecklauf
# },
# WZ_Sued => {
# actuator => '1/2/3', # Stellventil
# outflow => '1/2/3', # Ruecklauf
# },
},
},
);
)
Kommentar