Duty-Cycle für zentrale Ansteuerung von Heizgruppen optimieren

[mittelhessen]

Und was passiert, wenn Du nicht die negierte Logik nutzt? Also die Prüfung auf "manueller Modus".

Die Prüfung auf den "Manu-Modus" ist ja nicht hinreichend, da es ja auch noch den "Boost-Modus" gibt.

[Xel66]

Auch wenn das vielleicht ähnlich klingt, bin ich mir nicht sicher, ob dieses ein separater (dritter) Betriebsmodus ist oder eine separate Funktion. Bei meinen aus klassischen Geräten bestehenden Heizungsgruppen wird dieser "Modus" auch als "Boost-Funktion" bezeichnet und wird an den Kanal 1 adressiert, wie auch die Modus-Umschaltung und die Solltemperaturvorwahl usw.

Letztendlich ist dieses nur eine temporäre Übersteuerung der aktivierten Solltemperatur und/oder Ventilstellung. Nach Ablauf der Boostdauer wird ja die vorherige Solltemepratur und Betriebsmodus wieder eingestellt. Daher glaube ich eher, dass der Betriebsmodus nicht verlassen wird. Die Blaufärbung des aktiven Modus im WebUI geht weg. Ob diesese auf Datenpunktebene auch passiert, müsste man überprüfen. Aber mangels IP-Hardware kann ich das nicht und Klassik-Parameter sind nicht unbedingt auf IP übertragbar. Auch das Setzen des Automatikmodus und das daraus folgende Einstellen der für den aktuellen Zeitraum programmierten Solltemperatur ist keine probate Überprüfungsmöglichkeit, denn man kann genau diese Funktion auch nutzen, wenn ein Anwender die Solltemperatur hochgedreht hat. Durch das Setzen des Automatikmodus (ohne Solltemperaturwahl) wird wieder die Solltemperatur auf den programmierten Wert angeglichen, ohne dass sich der Betriebsmodus geändert hätte.

Ich nutze diese Boost-Funktion nicht, weil ich sie in Systemen mit angepasster Heizkurve für überflüssig halte. Meine Thermostate gehen bei Änderung der Solltemperatur von ECO auf Comfort selbsttätig von 0 auf 100% Öffnungsgrad und mehr könnte ein Boost-Modus auch nicht, denn aufer als auf geht nicht. Und da Systeme mit angepasster Vorlauftemperatur (wie sie in den meisten modernen Häusern mit Außentemperaturführung verbaut sei sollten) über zu wenig Vorlauftemperaturüberschuss verfügen, damit eine solche Funktion eine schnellere Aufheizung ermöglichen könnte, ist diese Funktion m.E. dort auch relativ sinnfrei.

Aber wer sie nutzen will und sich gut dabei fühlt, kann sie gern benutzen. In Systemen mit viel zu hoher Vorlauftemperatur (meist Gemeinschaftsheizanlagen in größeren Objekten) kann diese Funktion durchaus für einen höheren Aufheizgradienten sorgen, da nur diese über den notwendigen Energieüberschuss verfügen. Aber eben nur da. Dort stellen sich nach Erreichen der Solltemperatur auch Öffnungsgrade zwischen "geschlossen" und einstelligen Prozentgrößen ein (ein relativ sicheres Indiz für zu hohe Vorlauftemperatur).

Gruß Xel66

[Baxxy]

Ich gucke mir das später nochmal an. Mein Testszenario basierte ja auf SysVars, mal schauen wo es da mit echten Gruppen hakt.

Die Prüfung auf den "Manu-Modus" ist ja nicht hinreichend, da es ja auch noch den "Boost-Modus" gibt.

Das sollte doch ganz klassisch mit ODER gehen.

Code: Alles auswählen

WENN
Tastendruck Auto-Modus
UND
[Manu-Modus 
ODER 
Boost-Modus]

[Baxxy]

wie im Screenshot dargestellt umgesetzt, allerdings tut das Programm nichts.

Hmm.
Ich mache solche Sachen immer Step by Step. In diesem Fall den ersten Block fertigstellen und testen, dann den nächsten hinzufügen usw.
In jedes DANN noch eine Kontrollinstanz einfügen (SysVar, Auslösescript) ist auch hilfreich.
Mir fällt auch auf das du die "Intervalle" äußerst kurz gewählt hast. 1.Gruppe auf AUTO --> 1s später die nächste. Ok, die Intervalle werden länger...
Aber warum? Gib doch einfach jeder Gruppe erstmal 10s Zeit die Aktion zu verarbeiten und sich zurückzumelden. Runtergehen kann man immer noch.

Ich habe 3 Testgruppen angelegt (2x IP; 1x HM) die aber nicht voll ausgebaut sind. Alle bestehen zumindest aus Wandthermostat und eine IP-Gruppe beinhaltet noch SWDO und PSM. Dazu 2 Programme, 1x für MANU / 1x für AUTO.

Lange Rede kurzer Sinn... läuft!

[mittelhessen]

Und was passiert, wenn Du nicht die negierte Logik nutzt?

Leider kein Unterschied. Also daran sollte es (alleine) nicht liegen.

Aber mangels IP-Hardware kann ich das nicht und Klassik-Parameter sind nicht unbedingt auf IP übertragbar.

Für die Heizungssteuerung nutze ich ebenfalls HM und kein HmIP. Das hatte ich vergessen zu erwähnen, allerdings sollte dies ja eigentlich auch keine Rolle spielen. Meine Heizgruppen bestehen jeweils aus einem Heizkörperthermostat HM-CC-RT-DN und einem Wandthermostat HM-TC-IT-WM-W-EU.

Ich nutze diese Boost-Funktion nicht, weil ich sie in Systemen mit angepasster Heizkurve für überflüssig halte. Meine Thermostate gehen bei Änderung der Solltemperatur von ECO auf Comfort selbsttätig von 0 auf 100% Öffnungsgrad und mehr könnte ein Boost-Modus auch nicht, denn aufer als auf geht nicht. Und da Systeme mit angepasster Vorlauftemperatur (wie sie in den meisten modernen Häusern mit Außentemperaturführung verbaut sei sollten) über zu wenig Vorlauftemperaturüberschuss verfügen, damit eine solche Funktion eine schnellere Aufheizung ermöglichen könnte, ist diese Funktion m.E. dort auch relativ sinnfrei.

Das Programm müsste von seiner eigentlichen Funktion her doch trotzdem funktionieren?! Inhaltlich gebe ich Dir natürlich Recht, dass der praktische Nutzen der Boost-Funktion kaum vorhanden ist. Die Heizkurve ist insofern abgeglichen, als dass die dazugehörige Raumtemperatur, Neigung und das Niveau abgeglichen wurden und soweit reduziert sind, dass die Vorlauftemperatur gerade reicht, um die Räume in akzeptabler Zeit auf Temperatur zu bringen. Mit der ausgeschalteten Adaptiven Regelung (mit Standardwerten) der Heizkörperthermostate, erreiche ich eine zusammen mit den Wandthermostaten eine sehr akzeptable Regelgüte. Bei variabler Vorlauftemperatur, kommt für mich irgendeine undurchsichtige, adaptive Regelung der Thermostate sowieso nicht in Frage. Unabhängig davon fällt mir aber schon auf, dass der Ventilöffnungsgrad davon abhängig ist, um welche Differenz die Ist-Tempertur von der Soll-Temperatur abweicht. Letztendlich ist es aber tatsächlich eher ein gutes Gefühl, wenn man weiß, dass das Ventil zum schnellen Aufheizen des Bades mal für 10 Minuten auf 100 % steht und sich dann wieder entsprechend der Soll-Temperatur einregelt.

Ich mache solche Sachen immer Step by Step.

Das habe ich nun auch mal gemacht. Leider ohne Erfolg, siehe unten.

Mir fällt auch auf das du die "Intervalle" äußerst kurz gewählt hast. 1.Gruppe auf AUTO --> 1s später die nächste. Ok, die Intervalle werden länger...
Aber warum? Gib doch einfach jeder Gruppe erstmal 10s Zeit die Aktion zu verarbeiten und sich zurückzumelden. Runtergehen kann man immer noch.

Die Idee war, das Programm bis zum Ablauf einer Sekunde nicht erneut aufzurufen, um ihm Zeit zum Ablaufen zu geben (obwohl das ja eigentlich in einem Bruchteil davon durchgelaufen sein müsste). Gleichzeitig steuere ich damit ja nicht mehr als eine Heizgruppe pro Sekunde an, was auch der Kollisionswahrscheinlichkeit zugute kommen dürfte. Auch die testweise Erweiterung auf die von Dir vorgeschlagenen 10 s hat das Programm nicht zum Laufen gebracht. Bei meinen 12 Heizgruppen bräuchte der Ablauf aber im Worst-Case meinem Verständnis nach 2 Minuten um alle Heizgruppen umzuschalten. Das käme nicht in Frage, da ich an der Visualisierung auch eine zeitnahe Rückmeldung dargestellt bekommen möchte.

Hier das Programm mit oder-Verknüpfung und nur zwei Heizgruppen, was immer noch nicht läuft. (Der virtuelle Taster heisst nun "Heizung Alle Auto 1", da ich testhalber einen HM- anstelle eines HmIP-Tasters verwendet habe.)

[Xel66]

Das Programm müsste von seiner eigentlichen Funktion her doch trotzdem funktionieren?!

Ja, denn genau so ein Programm läuft bei mir zum manuellen abendlichen Lich-Löschen, um nicht auf die programmierten Timer warten zu müssen.

Die Idee war, das Programm bis zum Ablauf einer Sekunde nicht erneut aufzurufen, um ihm Zeit zum Ablaufen zu geben (obwohl das ja eigentlich in einem Bruchteil davon durchgelaufen sein müsste). Gleichzeitig steuere ich damit ja nicht mehr als eine Heizgruppe pro Sekunde an, was auch der Kollisionswahrscheinlichkeit zugute kommen dürfte.

Nicht unbedingt. Sowie eine Gruppe umgesteuert wird, fängt die CCU damit an, diese Informatione an alle Gruppenmitglieder zu verteilen. Und damit hängst Du an der Geschwindigkeit und möglichen Kollisionen, an der Zeit und Reihenfolge, mit der die Geräte Ihre Rückmeldungen absetzen. Und da wird in diesem Moment recht viel hin- und hergefunkt. Daher auch die Empfehlung, es mit größeren Zeitabständen zu probieren.

Gruß Xel66

[mittelhessen]

Daher auch die Empfehlung, es mit größeren Zeitabständen zu probieren.

Hallo Xel66, das habe ich probiert und zwar mit 10 Sekunden, so wie von Baxxy empfohlen. Leider ohne Erfolg! Inzwischen habe ich das Programm ja sogar auf nur noch zwei Heizgruppen gekürzt und es läuft immer noch nicht. Es findet einfach keine Umschaltung des Modus der Heizgruppen statt. Da scheint etwas Anderes im Argen zu liegen.

[Xel66]

Da scheint etwas Anderes im Argen zu liegen.

Geht denn eine grundsätzliche Umsteuerung per Programm? Damit meine ich virtuelle Taste --> Moduswechsel. Man muss ja nicht gleich mit kaskadierten Programmläufen arbeiten, sondern erst mal die grundsätzliche Steuerungsfähigkeit feststellen. Wenn schon das nicht geht, dann gehen auch keine automatischen Programmläufe. Ich habe das für meinen Fall mit einer Direktverknüpfung mit einer virtuellen Taste gelöst und kann so mehrere Steuerungsaufgaben durch Betätigen verschiedener Tasten erledigen. Allerdings geht danach ein richtiges Funkfeuer los und teibt meinen sonst einstelligen Duty Cycle auf größer 25%. Ich steuere allerdings die Thermostate direkt an und nicht die Gruppen, weil bei der Gruppensteuerung ab und zu mal ein Thermostat vergessen wurde. Ich habe auch nur vier Gruppen in den häufig benutzten Räumen. Die anderen Thermostate (Bad, Gästezimmer, Keller, Flur etc.) laufen autark.

Gruß Xel66

[mittelhessen]

Kurzer Zwischenstand: Die Ursache habe ich gefunden. Ich hatte die jeweligen Programme nicht auf "aktiv". Das habe ich gemacht, weil diese Programme (sofern ich mich richtig erinnere) sonst beim Reboot der CCU einmalig aufgerufen werden und mir in diesem Fall also (z. B. nach einem Stromausfall) ein undefinierter Zustand entstehen könnte. Alle anderen Programme (ohne Bedingungsabfrage), die inaktiv sind, funktioneren bei einem manuellen Programmaufruf problemlos. Hier allerdings wird das Programm ja durch den virtuellen Taster getriggert und ich vermute, dass es deshalb zwingend "aktiv" sein muss.

(Ob die Programme nun wie gewünscht ablaufen, muss ich noch testen und berichte nach.)

[Baxxy]

Meine Zentrale hat bei einem Systemstart noch nie eine Taste selbstständig gedrückt.

(aber wenigstens kann ich jetzt aufhören mir Gedanken zu machen warum das bei dir nicht geht... )

Grüße
Baxxy