Zur Abwechslung … Wärmebedarf

Da sind wir wieder: Christian macht eine Seite zum Wärmebedarf für eine Heizungssteuerung. Es ist, als hätte es diese und diese Seite nie gegeben.

Wenn ich meine Hobbys aufzählen sollte, dann würde ich vermutlich die HomeMatic erwähnen und dann die Heizungssteuerung noch mal extra. Ich könnte mich herausreden, dass ich ja schließlich auch immer wieder mal ein-, aus- oder umziehe und dann eben eine neue Steuerung für eine neue Umgebung programmieren muss. Außerdem gibt es ja immer mal wieder neue Geräte, die anders anzusprechen sind als die alten.

Aber machen wir uns nichts vor: Ich fummele einfach gern an der Heizungssteuerung rum. So, jetzt ist es raus. Auf zur Selbsthilfegruppe.

Na gut, vorher nur noch eine klitzekleine Seite zur Wärmebedarfsermittlung. Ein letztes Mal. Ich kann jederzeit aufhören.

Hybrid

Wie oben beschrieben, geht es diesmal um eine „hybride Umgebung“. In diesem Fall bedeutet „hybrid“ die Mischung aus Raumthermostaten von HomeMatic und HomeMatic IP. Konkret habe ich aus der Zweitwohnung einige HM-CC-RT-DN übrig, für das neue Haus habe ich großteils HmIP-eTRV-C und HmIP-eTRV-C-2 angeschafft. Während erstere selbst an offensichtlich defekten Heizungsventilen klaglos ihren Dienst verrichtet haben, zeichnen sich letztere durch wiederholte Ausfälle aus, aber nun sind sie halt mal da.

Ein vereinzelter HM-CC-TC verrichtet noch seinen Dienst im Wäschekeller, aber der ist nicht in die Heizung eingebunden, sondern dient vor allem der Feuchtigkeitsmessung für den Entfeuchter. Dazu hatte ich ja auch schon mal was auf meinen Seiten.

Die Datenpunkt-Challenge

eQ-3 hatte die gute Idee, bei der Einführung der HomeMatic-IP-Thermostate andere Datenpunkte zu verwenden als bei den HomeMatic-Geräten. Geschickterweise haben sie sich dabei nicht einfach komplett neue Namen ausgedacht, sondern teilweise bestehende Bezeichnungen mit anderen Bedeutungen und Wertebereichen weiterverwendet. Vielleicht Kreislaufwirtschaft oder sowas.

Beispiel: VALVE_STATE hat beim alten HM-CC-RT-DN den Ventilöffnungsgrad zwischen 0 und 100 ausgegeben, beim neuen HmIP-eTRV-C ist es der Betriebszustand zwischen 0 und 7 – wobei „4“ der normale Betriebszustand ist, nicht etwa „0“ wie beim FAULT_REPORTING, das es beim alten Antrieb gab, beim neuen aber nicht.

Und das ist nur der Ventilantrieb … Zum Glück geht es hier nicht um die unterschiedliche Philosophie mit Wochenprogrammen, Boostmodus und ähnlichem. Ich will ja auch noch Themen für die nächste Heizungsseite haben.

Autotrigger

Wenn eQ-3 sich eine neue Philosophie ausdenken kann, dann kann ich das auch: Anders als bei den bisherigen Programmen wird meine Heizung jetzt nicht mehr durch Updates der Heizkörperthermostate getriggert, sondern ich habe einen sehr schnellen Autotrigger eingerichtet. Dieser läuft alle zehn Sekunden und stößt alles an, was für die Heizungssteuerung nötig ist – von der Berechnung der Wärmebedarfe unserer zwei Heizkreise bis zum Schalten von Pumpen und dem Heizungskessel. Die CCU-3 ist schnell genug, um die entsprechenden Scripte entsprechend oft abzuarbeiten.

Der Autotrigger besteht zunächst natürlich aus der Systemvariable Heizung Autotrigger, die sich immer wieder selbst auslöst. Ein einfacher Logikwert reicht, die Wertbezeichnung ist eigentlich egal.

Zugehörig ist das WebUI-Programm wie auf der Seite zum Systemtakt beschrieben.

Das Prinzip ist exakt das gleiche wie beim Systemtakt, nur sehr viel schneller: Die Systemvariable wird mit zehn Sekunden Verzögerung auf wahr gesetzt und löst damit immer wieder das Programm aus, das sie nach zehn Sekunden auf wahr setzt.

Entsprechend der Logik von WebUI-Programmen startet das Programm mit dem Neustart der CCU (weil die Variable ja immer wahr ist) und läuft dann für immer.

Gewerke

Nach der neuen Philosopie gebe ich nicht mein knappes Dutzend Thermostate im WebUI-Programm an, sondern nehme einfach alle, die zur Bedarfsermittllung herangezogen werden sollen, in das Gewerk Heizung HK1 auf.

Insbesondere bei einem Austausch erleichtert das die Einrichtung immens: Für die HomeMatic-IP-Geräte gibt es keine Möglichkeit, sie über die WebUI einfach zu ersetzen, wie es bei HomeMatic-Geräten der Fall ist. Also muss man das neue Gerät komplett neu einrichten und dann das alte löschen. Über Gewerke und Räume kann ich neue Geräte einfach hinzufügen und sie werden in den Programmen automatisch berücksichtigt.

Auch zusätzliche Geräte lassen sich dadurch schnell und einfach integrieren, ohne an alle Programme denken zu müssen. Man sollte meinen, die Wahrscheinlichkeit ist gering, dass neue Heizkörper hinzukommen, aber wir sind mit der Sanierung ja noch nicht durch und wenn man schon neue Tapeten macht …

Aber das Prinzip gilt natürlich für alles. Eine neue Lampe, die dann ganz von selbst in die Raumbeleuchtung integriert wird, oder mal ein neuer Fensterkontakt kommt ja schon hin und wieder dazu.

Im Bild zu sehen ist die Heizung im oberen Bad: Der alte HomeMatic-Thermostat ist separat am Handtuchheizkörper, HomeMatic-IP-Wandthermostat und Kompaktthermostat bilden eine Heizungsgruppe für die Fußbodenheizung mit RTL-Ventil. Eine gemeinsame Gruppe zwischen HomeMatic und HomeMatic IP ist nicht möglich, wäre hier aber auch nur begrenzt sinnvoll: Die Fußbodenheizung sorgt durchgehend für eine Grundtemperatur; wenn wir das Bad nutzen oder nach dem Lüften schnell nachgeheizt wird, geht der Heizkörperthermostat kurz auf.

In der rechten Spalte erkennt man die Gewerke: Alle sind im Gewerk Heizung, aber nur die beiden Geräte mit Ventilantrieb sind auch im Gewerk Heizung HK1 und werden von der Bedarfsermittlung erfasst.

Außerdem gibt es noch das Gewerk Heizung Thermostate – das sind bei mir alle Geräte oder Gruppen, an denen tatsächlich die Temperatur eingestellt wird. Die Einzelgeräte der Gruppe sind nicht drin, weil sie ja über die Gruppe gesteuert werden.

Das WebUI-Programm

Die eigentliche Bedarfsermittlung erfolgt natürlich in einem separaten Programm. Als erstes aber auch hier die passende Systemvariable, in der der Wert zur weiteren Bearbeitung gespeichert wird.

Am Namen Heizung HK1 Bedarf kann man schon erkennen, dass wir mittlerweile zwei Heizkreise haben. Der erste hängt direkt am Kessel und versorgt alle Heizkörper und die Fußbodenheizung mit RTL-Ventil im Bad.

Der Wertebereich ist weitgehend egal und kann wie hier auf den vorgegebenen Daten belassen werden.

Das eigentliche Programm deutet ebenfalls darauf hin, dass nach der Bedarfsermittlung noch was kommt.

Anhand des Autotriggers werden alle zehn Sekunden die Scripte ausgeführt, die den Heizkreis 1 steuern. Das ist zunächst die Bedarfsermittlung, die auf dieser Seite behandelt wird. Danach wird dann geprüft, ob Pumpe oder Brenner angefordert werden, und am Ende wird noch die Pumpe für den Heizkreis 1 geschaltet. Da der Brenner auch für Heizkreis 2 zuständig ist, gibt es dafür nochmal ein separates Programm.

Alle Scripte werden mit Verzögerung ausgeführt, um die Last gleichmäßig zu verteilen und damit Schaltvorgänge die Zentrale möglichst wenig belasten.:

Trigger	Programme werden gestartet
Sekunde 1	Bedarfsermittlung HK1
Sekunde 2	Anforderung für HK1 ermitteln
Sekunde 3	Pumpe für HK1 ein- oder ausschalten
Sekunde 5	Bedarfsermittlung HK2
Sekunde 6	Anforderung für HK2 ermitteln
Sekunde 7	Pumpe für HK2 ein- oder ausschalten
Sekunde 8	Brenner für HK1 und HK2 ein- oder ausschalten

Ich habe also noch Luft für zwei Scripte, bevor die zehn Sekunden rum sind.

Script zur Ermittlung des Wärmebedarfs

Das Script zur Bedarfsermittlung ist dann schon fast wieder bekannt.

gesamtes Script markieren / kopieren

string s_channel;
object o_channel;

real r_bedarf = 0.0;
real r_level;

foreach (s_channel, dom.GetObject ("Heizung HK1").EnumUsedIDs()) {
  o_channel = dom.GetObject (s_channel);
  if (o_channel.HssType() == "HEATING_CLIMATECONTROL_TRANSCEIVER") {
    if (o_channel.DPByHssDP ("VALVE_STATE").Value() == 4) {
      r_level = o_channel.DPByHssDP ("LEVEL").Value();
      r_bedarf = r_bedarf + r_level;
    }
  }
  if (o_channel.HssType() == "CLIMATECONTROL_RT_TRANSCEIVER") {
    if (o_channel.DPByHssDP ("FAULT_REPORTING").Value() == 0) {
      r_level = o_channel.DPByHssDP ("VALVE_STATE").Value().ToFloat() / 100.0;
      r_bedarf = r_bedarf + r_level;
    }
  }
}

r_bedarf = r_bedarf * 100.0 / 3.0;

object o_bedarf = dom.GetObject ("Heizung HK1 Bedarf");

if (o_bedarf.Value() != r_bedarf) {
  o_bedarf.State (r_bedarf);
}

Im oberen Teil geht die CCU der Reihe nach alle Geräte in der Gruppe Heizung HK1 durch. Wenn sie dabei auf einen neuen Heizkörperthermostat triftt – erkennbar am HssType HEATING_CLIMATECONROL_TRANSCEIVER  – wird zunächst geprüft, ob der Antrieb sich im fehlerfreien Zustand befindet. VALVE_STATE = 4 besagt, dass der Antrieb kalibriert ist. Ist dies der Fall, wird der Öffnungsgrad zum Gesamtbedarf r_bedarf addiert.

Bei HssType CLIMATECONTROL_RT_TRANSCEIVER handelt es sich um den alten HomeMatic-Raumthermostat. Auch hier wird zunächst geprüft, ob kein Fehler vorliegt und dann der Öffnungsgrand zu r_bedarf addiert. Da der Wert hier von 0 bis 100 geht und nicht wie bei den neuen Thermostaten von 0 bis 1, wird der Wert durch 100 geteilt.

Zwischendurch passe ich den Wert noch auf meine Umgebung an: Die Systemvariable hätte ich dann schon gerne von 0 bis 100 (oder weiter, bei mehr Thermostaten). Allerdings teile ich die Gesamtsumme nochmal durch 3, weil ich zu hohe Werte auch wieder nicht brauche.

Am Ende wird die Systemvariable gesetzt, wenn der Wert sich geändert hat.

Läuft? Läuft!

Sobald das Programm gespeichert wurde, führt es brav die nötigen Berechnungen durch und setzt die Systemvariable: Wenn wir im Bad den Boost einschalten und der Thermostat auf 80% Öffnungsgrad aufdreht, erhöht sich der Wärmebedarf um knapp 27 Punkte. Ist es warm, werden die Ventile geschlossen und der Wärmebedarf geht runter.

Wenn der Heizkörper im Windfang gegen die undichte Tür anheizt und auf 100% öffnet, geht der Wärmebedarf um 33 Punkte nach oben – wenn ich den Thermostat dann aus dem Gewerk Heizung HK1 rausnehme, kehrt wieder Normalität ein.

Die Reaktionszeit ist dabei relativ schnell. Im Gegensatz zu den uralten Wandthermostaten erfolgt die Aktualisierung nicht erst nach 3-6 Minuten, sondern sehr zeitnah nach Änderungen. Darauf kann dann auch der Rest der Heizungssteuerung reagieren und bei Bedarf schnell die Pumpe ein- und wieder ausschalten.