Heizkreispumpe nach Bedarf steuern

[bacanol]

Hallo Leute,

da ich nun schon einige Themen angegangen bin, würde ich gern nun etwas komplizierteren Stoff anfangen. Meine Idee, die Heizkreispumpe in Abhängigkeit von Raumanforderungen steuern. Wenn nun ein Raum meldet, dass er geheizt werden möchte, dann soll die Heizkreispumpe eingeschaltet werden. Kommt nun noch ein 2. Raum mit "Heiz-mich-wunsch" bleibt die Pumpe natürlich an. Nun ist beispielsweise der erste Raum auf Temperatur und schaltet sein Ventil zu. Es sollte geprüft werden, ob noch ein anderer Raum geheizt wird, so dass die Pumpe weiter läuft wenn ja. Raum 2 braucht noch ein wenig Wärme und prüft, wenn er seine Solltemperatur erreicht hat nun ebenfalls, ob noch ein weiterer Raum eine Anforderung hat. In diesem Beispiel nein, was dazu führt, dass die Heizkreispumpe abgeschaltet wird.

Ist das Szenario denkbar? Wenn ja, wie gehe ich am sinnvollsten vor? Ich habe überlegt, dass es am besten mit einer generischen if-then-else oder switch funktion gehen könnte. Allerdings fehlt mich etwas die Inspiration dazu... Als gegeben könnte man ja einfach sagen, dass jeder Raum, der eine Anforderung feststellt erstmal die Pumpe einschaltet (auch wenn vielleicht schon ein anderer oder mehrere andere Räume dieses durch eine Anforderung vorher getan haben). On bleibt ja dann On. Jedoch für den Off Fall müsste halt geprüft werden, ob nicht vielleicht noch ein anderer Raum eine aktive Anforderung hat, um diesem nicht die Pumpe zu "klauen".

Was meint Ihr?!

Viele Grüße

bacanol

[cwagner]

Schau Dir doch mal das Modul HCS an, mit dem habe ich so eine von dem Bedarf von 7 verschiedenen Räumen abhängige Pumpensteuerung seit einem halben Jahr im Einsatz.

Herzliche Grüße
Christian

[Damian]

Das kannst du auch über structure regeln:

Falls du mit on/off-Aktoren hantierst z. B. für 230V-Stellantriebe (das hast du nicht genau spezifiziert).

Dann machst du:

define alle_raeume structure CUL_HM Raum1 Raum2 ...

attr alle_raeume clientstate_behavior relativeKnown

attr alle_raeume clientstate_priority on off

attr alle_raeume event-on-Change-reading state

define Trigger notify alle_raeume:o.* set Pumpe %

Hier wird auch nur geschaltet, wenn der Zustand sich wirklich ändert, doppelte on, on gibt es nicht.

Gruß

Damian

[bacanol]

Hallo!

Vielen Dank für die Antworten, das hört sich wikrlich gut an! Ich habe in der Tat On/Off Schalter für die Einzelraumsteuerung. Ich werde das am Wochenende mal probieren und meine Erfahrungen hier teilen!

Viele Grüße

bacanol

[bacanol]

Das kannst du auch über structure regeln:

Falls du mit on/off-Aktoren hantierst z. B. für 230V-Stellantriebe (das hast du nicht genau spezifiziert).

Dann machst du:

define alle_raeume structure CUL_HM Raum1 Raum2 ...

attr alle_raeume clientstate_behavior relativeKnown

attr alle_raeume clientstate_priority on off

attr alle_raeume event-on-Change-reading state

define Trigger notify alle_raeume:o.* set Pumpe %

Hier wird auch nur geschaltet, wenn der Zustand sich wirklich ändert, doppelte on, on gibt es nicht.

Gruß

Damian

Hi Damian,

ich habe das nun so umgesetzt und irgendwie funktioniert das nicht 100% zuverlässig. Mal schaltet er, mal nicht. Ich habe zum Testen mal eine E-Mail senden lassen bei jedem Schaltvorgang und habe teilweise eine oder zwei oder drei oder noch mehr E-Mails bekommen, bei einem Schaltvorgang. Wie kann ich das am besten Debuggen?

Viele Grüße

Nico

[Damian]

Hallo Nico,

für die Analyse musst du genaue Info´s posten, am besten mit list <deine structure> und List <deine Schalter> ausgeben.
Dann über Event Monitor die Schaltvorgänge ausgeben.

Dann kann man weiter schauen.

Gruß

Damian

[bacanol]

Alles klaro, hier kommt die Structure:

Code Auswählen Erweitern

Internals:
   ATTR       CUL_HM
   DEF        CUL_HM az_Fussbodenheizung bo_Fussbodenheizung bu_Fussbodenheizung ko_Fussbodenheizung ku_Fussbodenheizung kz_Fussbodenheizung sz_Fussbodenheizung wr_Fussbodenheizung
   NAME       alle_Fussbodenheizung
   NR         191
   NTFY_ORDER 50-alle_Fussbodenheizung
   STATE      on
   TYPE       structure
   CHANGED:
     on
   Content:
     az_Fussbodenheizung 1
     bo_Fussbodenheizung 1
     bu_Fussbodenheizung 1
     ko_Fussbodenheizung 1
     ku_Fussbodenheizung 1
     kz_Fussbodenheizung 1
     sz_Fussbodenheizung 1
     wr_Fussbodenheizung 1
   Readings:
     2013-10-31 21:21:06   LastDevice      wr_Fussbodenheizung
     2013-10-31 21:21:06   LastDevice_Abs  wr_Fussbodenheizung
     2013-10-31 21:21:06   state           on
Attributes:
   clientstate_behavior relativeKnown
   clientstate_priority on off
   devStateIcon on:general_an off:general_aus
   event-on-change-reading state
   group      Fussbodenheizung
   icon       sani_earth_source_heat_pump
   room       Heizungsraum
   verbose    1

und hier das Notify

Code Auswählen Erweitern

Internals:
   DEF        alle_Fussbodenheizung:o.* set hr_Pumpe_Heizung %
   NAME       hr_Notify_Heizung
   NR         192
   NTFY_ORDER 50-hr_Notify_Heizung
   REGEXP     alle_Fussbodenheizung:o.*
   STATE      active
   TYPE       notify
Attributes:
   room       Heizungsraum
   verbose    1

Leider sehe ich Event Monitor nichts konkretes, allerdings scheint irgendwas zig mal zu schalten für einen kurzen Moment.

Irgendwelche Ideen?

Nico

[Damian]

Leider sehe ich Event Monitor nichts konkretes, allerdings scheint irgendwas zig mal zu schalten für einen kurzen Momen
Nico

Du kannst erst mal nur einen Aktor z. B. az_Fussbodenheizung in der structure definieren und dein notify disablen oder löschen. Dann az_Fussbodenheizung on, off schalten und schauen, ob structure den Zustand übernimmt, wenn das klappt dann zwei Aktoren angeben und schauen was passiert, wenn man die Aktoren on, off schaltet. Wenn structure die richtigen Zustände übernimmt (alle Aktoren off -> structure off, ein Aktor on -> structure on), dann würde ich erst mit dem notify als nächstes experimentieren.

Gruß

Damian