Duty-Cycle für zentrale Ansteuerung von Heizgruppen optimieren

[mittelhessen]

Ich habe insgesamt 12 angelernte Heizgruppen, jeweils bestehend aus einem Wandthermostat HM-TC-IT-WM-W-EU und einem Heizkörperthermostat HM-CC-RT-DN. Mit Hilfe eines Programms, möchte ich die Möglichkeit haben, alle Heizgruppen mit einem Knopfdruck in den Auto-, Manu- oder Boostmodus zu versetzen. Die Programme selbst, sind natürlich einfach und funktionieren wie gewüscht. Festgestellt habe ich jedoch, dass beispielsweise ein einfaches Umschalten aller Heizgruppen in den Auto-Modus und anschließendes Zurückschalten in den Manu-Modus den Duty-Cycle bereits um etwa 50 Prozentpunkte ansteigen lässt! Natürlich nutzt man dieses Programm eher selten und ich habe den Vorteil, dass sich der DC auf eine CCU und ein LGW aufteilt, trotzdem fände ich es sehr nett, wenn es irgendeine Möglichkeit der Optimierung gäbe.

Meine Idee wäre, vor dem ausführenden Teil des Programms, jeweils den aktuellen Zustand mit der Bedingung "nicht bei" "Auto-Modus" (bzw. "Manu-Modus" oder "Boost-Funktion") abzufragen. Nun frage ich aber, ob alleine diese Abfrage den gleichen DC verursachen würde oder ob durch die manuelle Ausführung des Programms die Bedingung sowieso nicht überprüft wird und nur der ausführende Teil durchlaufen wird.

Gibt es cleverere Ansätze, den DC für eine solche Funktion zu reduzieren bzw. ist es überhaupt normal, dass der DC bei einer nur zweimaligen Ansteuerung einer jeden Heizgruppe dermaßen hochschließt?

[Baxxy]

Naja, wenn du den aktiven Status abfragst (MANU / AUTO / BOOST) und deine Aktion nur ausführen lässt wenn der Status nicht dem aktuellen Status entspricht könnte das schonmal helfen.

Ob das DC-Technisch wirklich was bringt kann ich nicht beurteilen.
Aber letztlich ist doch jeder nicht wirklich erforderliche, und somit nicht gesendete "Funkbefehl", ein Guter.

Meine Heizungen laufen (solange unser Ferienhäuschen bewohnt ist) immer im AUTO-Modus. Sollte wirklich mal ein BOOST erforderlich sein so ist dieser am lokalen Wandthermostat auszulösen.

Wenn das Häuschen mal längere Zeit unbewohnt ist stelle ich die Gruppen auch auf "MANU" mit 6°C als Frostschutz. Ganz klassisch per WebUI-Programm. Dabei steigt der DC Richtung 20%, es sind aber auch nur 5 Gruppen bestehend aus HmIP-Geräten und es kommt ja nicht so oft vor.

ob durch die manuelle Ausführung des Programms die Bedingung sowieso nicht überprüft wird und nur der ausführende Teil durchlaufen wird.

Ein manuelles Ausführen des Programms führt immer zum 1.DANN, egal ob der Bedingungsblock ein "WAHR" ergab oder nicht.

Da frage ich mich doch gleich... wie führst du das Programm manuell aus? Über den "Start-Button" unter Status und Bedienung > Programme?
Oder über .ProgramExecute() per Script?

Ersteres... ACHTUNG SPOILER... ist bald Geschichte und letzteres sollte man nicht wirklich verwenden.

So und noch etwas Fachsimpelei...
Vielleicht wäre es sinnvoll Direktverknüpfungen mit virtuellen Tasten anzulegen, also jeweils eine virtuelle Taste (pro Modus) mit jedem Gerät einer Gruppe.

Mit etwas Einarbeitung reichen dann auch 1,5 Tasten, also Taste A_kurz = AUTO; Taste A_lang = MANU; Taste B_kurz_oder_lang = BOOST
Bringt das was? Gute Frage, kann ich nicht beantworten.

Grüße
Baxxy

[Xel66]

Meine Idee wäre, vor dem ausführenden Teil des Programms, jeweils den aktuellen Zustand mit der Bedingung "nicht bei" "Auto-Modus" (bzw. "Manu-Modus" oder "Boost-Funktion") abzufragen.

Und warum programmierst Du es nicht so. Es ist doch ein Leichtes, derartige Bedingungen im Programm zu hinterlegen. Und negierte Abfragen gehen nur mit der Raspberrymatic.

Nun frage ich aber, ob alleine diese Abfrage den gleichen DC verursachen würde oder ob durch die manuelle Ausführung des Programms die Bedingung sowieso nicht überprüft wird und nur der ausführende Teil durchlaufen wird.

Die Abfrage erzeugt keinen Duty Cycle, weil diese nur die in der CCU bekannten Werte prüft. Eine manuelle Programmausführung prüft keinerlei Bedingungen.

Gibt es cleverere Ansätze, den DC für eine solche Funktion zu reduzieren bzw. ist es überhaupt normal, dass der DC bei einer nur zweimaligen Ansteuerung einer jeden Heizgruppe dermaßen hochschließt?

Der cleverste Ansatz würde sein, solche globalen Umschaltungen auf das Nötigste zu reduzieren und ja, es ist normal, dass der DC so ansteigt. Schließlich findet eine umfangreiche Kommunikation der Geräte untereinander (Wandthermostat - Heizkörperthermostat innerhalb der Gruppe) und zur CCU statt, was zusätzlich zur normalen Kommandoverteilung noch Funkkollisionen und Mehrfachübertragungen verursacht. Und nein, die Verknüpfung mit einer virtuellen Taste spart zwar theoretisch etwas, aber nicht wirklich viel DC (habe diesbezügliche Tests durch). Mit einer Hardware-Taste eines Wandtasters könnte es weniger sein. Grund ist das ausgedehnte Kommunikationsbedürfnis der CCU und vermutlich, weil die Thermostate batteriebetriebene Aktoren sind (wake on radio). Trotzdem habe ich meine Heizungssteuerung darauf umgestellt. Eine komplette Umsteuerung mit Moduswechsel verursacht bei mir einen DC-Anstieg auf ca. 30% (13 Heizkörper, aber nur drei Wandthermostate - eine Vierer und zwei Zweier-Gruppen - die meisten Heizkörperthermostate im Singlebetrieb).

Solche massiven Umsteuerungen mache ich aber nur selten. Im Normalfall fahren die Thermostate ihr Profilprogramm und davon abweichende Nutzungen (Schichtplan, Feiertage, Urlaub etc.) werden durch einfaches Setzen der Solltemperaturen (ohne Moduswechsel) abgedeckt. Hierbei ist der Anstieg einstellig. Globale Befehle lasse ich nur raus, wenn ich wegen hoher Außentemperaturen oder längerer Abwesenheiten (>24h) alle Thermostate in den ECO-Zustand und ggf. wieder zurück in den Automatik-Modus versetze (und natürlich zu Beginn und Ende der Heizperiode). Allerdings nehmen bei mir auch nicht alle Thermostate am täglichen Auf und Ab teil. Ich habe drei nur temporär genutzte Räume im manuell ECO-Modus, dort wird nur selten der Automatikmodus gefahren. Meine erste Meldeschwelle (Push) für DC-Anstiege liegt bei 25%. Eine solche Meldung bekomme ich ab und zu mal. Insbesondere wenn zusätzlich auch noch die Keymatic angesteuert wird. Die ist wegen ihrer signierten Kommunikation ein massiver DC-Treiber. Liegt aber auch an meiner speziellen Art der Steuerung der Keymatic (bekommt vor dem eigentlichen Schließvorgang einen Kontrollbefehl mit dem aktuellen Status, um zwischenzeitliche manuelle Bedienungen - die aber so gut wie nie vorkommen - zu korrigieren).

Gruß Xel66

[mittelhessen]

Und warum programmierst Du es nicht so. Es ist doch ein Leichtes, derartige Bedingungen im Programm zu hinterlegen. Und negierte Abfragen gehen nur mit der Raspberrymatic.

Hab ich, allerdings funktioniert es nicht mit dem gewünschten Ergebnis. Raspberrymatic habe ich, also sind negierte Abfragen möglich. Nun scheitere ich allerdings an der Homematic-Programmlogik. Umgesetzt habe ich das wie im unteren Programmausschnitt dargestellt. Das ist natürlich falsch und führt nicht zum gewünschten Ergebnis, da nach der ersten erfüllten Bedingung ja nur der dazugehörige Programmteil abgearbeitet wird und das Programm danach fertig ist und gar nicht mehr zu den anderen Abfragen kommt. Nun habe ich leider allerdings auch keinen Ansatz, wie ich das Programm so aufbauen könnte, dass der gewünschte Programmablauf erreicht wird. Es soll ja der Status jeder Heizgruppe abgefragt werden und dann jeder dazugehörige Programmteil ausgeführt werden, sofern die Bedingung erfüllt ist.

[Baxxy]

Es soll ja der Status jeder Heizgruppe abgefragt werden und dann jeder dazugehörige Programmteil ausgeführt werden, sofern die Bedingung erfüllt ist.

Xel66 hatte da mal ein schönes Programmbeispiel gepostet, finde es aber nicht mehr.
Es ging um's EIN- (oder AUS-) Schalten von Beleuchtung und zwar nur wenn diese den gewünschten Status nicht hatten.
Das ließe sich auch gut für Dich adaptieren.

Für jeden Modus bräuchtest du ein Programm und eine zugehörige virtuelle Taste.
Beispielhaft sähe das dann so aus:

Das Programm "retriggert" sich von selbst (mit selbst zu bestimmenden Abständen) bis alle Bedingungsblöcke "unWAHR" sind.
Wichtig ist hier nur das im letzten DANN die virtuelle Taste nicht mehr gedrückt wird.

Grüße
Baxxy

[mittelhessen]

Da frage ich mich doch gleich... wie führst du das Programm manuell aus? Über den "Start-Button" unter Status und Bedienung > Programme?
Oder über .ProgramExecute() per Script?

Um noch rückwirkend Deine Frage zu beantworten: Ich führe es über einen Programmaufruf der mediola Neo Creator Fernbedienung aus. Dabei nehme ich an, dass dies einem Programmaufruf über den "Start-Button" gleichkommt und der erste Ausführungsteil aufgerufen wird ohne die erste Bedingung zu prüfen.

Ersteres... ACHTUNG SPOILER... ist bald Geschichte und letzteres sollte man nicht wirklich verwenden.

Das hatte ich am Rande schon mitbekommen und finde Idee sehr gut, weil es logischer ist.

Dein Progammbeispiel sieht gut aus und lässt sich auf meinen Anwendungsfall bestimmt anwenden. Einzig virtuelle Taster habe ich noch nie verwendet/konfiguriert. Wenn das die einzige Möglichkeit ist, das Vorhaben umzusetzen, probiere ich das gerne mal aus. Eleganter/schöner fände ich es ohne virtuelle Taster, aber das geht wohl nicht?

[Xel66]

Wenn das die einzige Möglichkeit ist, das Vorhaben umzusetzen, probiere ich das gerne mal aus. Eleganter/schöner fände ich es ohne virtuelle Taster, aber das geht wohl nicht?

Es ist die vom Hersteller für diese Aufgabenstellung vorgesehene Vorgehensweise, Programme MIT Prüfung der Bedingungen zu triggern. Es ist ja kaum etwas einfacher, als so eine virtuelle Taste, von denen es je nach Hardwareausstattung entweder 100 (50 HM, 50 HmIP) oder mit wired-Systemen noch jeweils 50 mehr gibt, entsprechend ihres Verwendungszweckes zu benennen, damit man weiß, dass dieser in Benutzung ist. Danach braucht man ihn nur noch als initialen Trigger im Programm im WENN und den SONST WENN zu hinterlegen und im jeweilig zugehörigen DANN erneut zu betätigen (außer im letzten SONST WENN). Ich persönlich halte das direkte Starten von Programmen (egal ob über Script oder eine App) eher als schlechten Programmierstil, weil man sich da mehr Probleme schafft als löst. Aber das ist eine persönliche Meinung.

Gruß Xel66

[Baxxy]

Um noch rückwirkend Deine Frage zu beantworten:

Ah ja, Danke. Wenn man weiß welche Funktion der "Mediola-Programm-Start-Button" nutzt ist das ja ok. Ich würde mir da mal ein Testprogramm zusammenklicken um Gewissheit zu haben. Interessant wird dann auch wie sich das mit der neunen RM-Funktion des "Programm-Start-Buttons" verhält.

Eleganter/schöner fände ich es ohne virtuelle Taster, aber das geht wohl nicht?

Geht nicht würde ich jetzt erstmal nicht sagen. Dazu müsstest du erstmal sagen was der eigentliche Auslöser (Trigger) für den jeweiligen Modus sein soll. Ich mag die virtuellen Tasten, gut das man 100 davon hat. Durch kurz/lang Abfrage hat man quasi 200 verschiedene Trigger.

Grüße
Baxxy

[mittelhessen]

Es ist ja kaum etwas einfacher, als so eine virtuelle Taste, von denen es je nach Hardwareausstattung entweder 100 (50 HM, 50 HmIP) oder mit wired-Systemen noch jeweils 50 mehr gibt, entsprechend ihres Verwendungszweckes zu benennen, damit man weiß, dass dieser in Benutzung ist.

... das habe ich mal so umgesetzt, allesdings läuft es noch nicht, siehe unten. Ist es eigentlich egal, ob man dafür die virtuellen HM- oder HmIP-Taster verwendet?

Wenn man weiß welche Funktion der "Mediola-Programm-Start-Button" nutzt ist das ja ok.

Ich würde sagen, das Programm wird über Mediola genauso ausgeführt, wie über den "Start"-Button des WebUI. Getestet habe ich das nicht, allerdings würde ich mich wundern, wenn das anders sein sollte.

Interessant wird dann auch wie sich das mit der neunen RM-Funktion des "Programm-Start-Buttons" verhält.

Da bin ich ebenfalls gespannt. Meine Programme die ich mit der Mediola starte, enthielten bisher allerdings keine Prüfung von Bedingungen, sondern nur einen ausführenden Teil. Wenn ich nun die Programme, die eine Prüfung von Bedingungen enthalten, über einen virtuellen Taster triggere, ist das Ganze ja elegant umschifft.

Baxxys Beispiel, habe ich wie im Screenshot dargestellt umgesetzt, allerdings tut das Programm nichts. Im letzten Ausführungsteil, rufe ich den kurzen Tastendruck natürlich nicht mehr auf, damit das Programm nicht in eine Schleife aufgerufen wird. Wenn der virtuelle HmIP-Taster "Heizung Alle Auto" kurz gedrückt wird, schaltet keine einzige Heizgruppe auf den Auto-Modus um. Irgendwas ist da noch faul...

[Xel66]

Und was passiert, wenn Du nicht die negierte Logik nutzt? Also die Prüfung auf "manueller Modus". Grundsätzlich ist es für diesen Zweck egal, welche virtuellen Tasten Du benutzt. Das ist nur relevant, wenn Du Aktoren direkt damit ansteuern wolltest. Da musst Du auf das korrekte Protokoll achten. Ich benutze aber bisher nur die virtuellen Tasten für klassisches Homematic, weil die IP-Tasten erst in späteren Firmwareversionen kamen (glaube mit dem Charly-Funkmodul), und die meisten meiner Programmierungen sind schon älter.

Ein solches selbst aufrufendes Programm mit einer virtuellen Taste läuft bei mir zur Lichtsteuerung recht häufig (ich lösche alle eingeschalteten Lichter im Haus damit). Das ist nur notwendig, weil einige Lampen mit recht langen Einschaltzeiten programmiert sind (um ein häufiges EIN/AUS zu verhindern). Beim Zubettgehen mache ich dann mit einer Taste am Bett alles aus. Die Automatik würde das zwar auch irgendwann machen, aber das ist einer der seltenen Handeingriffe.

Guß Xel66