Grundsatzfrage: Viele Einzelprogramme vs Master-Script

[anderl1969]

Hallo Forum,

ich bin gerade dabei, meine CCU-Programme aufzuräumen und zu überarbeiten und stehe dabei vor einer Grundsatz-Frage:

Ist es besser für jedes einzelne Gerät eines Gewerks (z.B. Heizungsthermostat) ein dediziertes Programm vorzuhalten, das konkret und fest "verdrahtet" nur dieses eine Gerät behandelt? Oder ist es besser, ein "übergreifendes" Programm zu implementieren, das auf alle Geräte eines Gewerks reagiert und in einem entsprechenden Script dann flexibel das auslösende Gerät dynamisch behandelt?

Als Beispiel mag mal das Auslesen der Ventilposition von Heizungsthermostaten und Speichern in einer entsprechenden Systemvariablen dienen.

Variante 1 - Viele Einzel-Programme - 1 je Thermostat

Das Script Programm ist auf den 1. Blick schön übersichtlich und man kann auch relativ einfach nachvollziehen was das Programm tut. Es gibt aber auch vieles, was mir an der Lösung nicht gefällt. So ist diese Variante mit sehr viel Klickaufwand verbunden (man muss das ja für jedes Thermostat erneut zusammen basteln).

Vorteile:

• Einfach zu verstehen und zu erstellen (so wie hier kommt man u.U. ohne HM-Script aus)
• Flexibel - da es für jedes Thermostat eine separates Programm gibt, können Sonderfälle individuell berücksichitgt werden. So ist in dem oben gezeigten Beispiel die Systemvariabel gar nicht dem Kanal des auslösenden Datenpunkts zugeordnet, sondern der virtuellen Heizungsgruppe!
• Wenig Vorbedingungen - es müssen keine Nomenklaturen oder ähnliches eingehalten werden
• Einfache De-/Aktivierung einzelner Geräte-Programme per Häckchen
• Einfacheres "Debugging" - Einzelner Trigger und Zeitstempel der letzten Ausführung.

Nachteile:

• Vielzahl von gleichen Programmen erschwert die Übersicht in der CCU-Programmübersicht
• Hoher Wartungsaufwand - bei einer grundlegenden Änderung der Logik muss das in x Programmen separat nachgezogen werden
• Hohe Fehleranfälligkeit - die Menge der an sich gleichen Programm erhöht die Chance auf einen Flüchtigkeitsfehler
• Schlechte Skalierbarkeit - kommt ein neues Thermostat hinzu, muss eine neues Programm angelegt werden

Variante 2 - Ein Programm für alles Thermostate

Dieses Script Programm für sich ist schon nicht mehr ganz schön wie bei Variante 1, da hier viel mehr Eingangsbedingungen geprüft werden müssen. In dem schnell von mir zusammengeklickten Beispiel sind's nur 3, aber je nach Installation kämen da noch viel mehr dazu - bei mir wären es aktuell 16 Thermostate. Außerdem sieht man im Dann-Teil nur, dass ein Script ausgeführt wird. Was das dann tatsächlich macht, sieht man auf den ersten Blick nicht.

Vorteile:

• Hohe Übersicht in der CCU-Programmübersicht
• Geringer Wartungsaufwand - 1 zentrale Anlaufstelle für grundlegende Änderung an der Logik
• Bessere Skalierbarkeit - kommt ein neues Thermostat hinzu, muss eine nur eine Eingangsbedingung im bestehenden Programm ergänzt werden

Nachteile:

• Definierte Prämissen erforderlich - Damit das Master-Script im Dann-Teile die richtige Systemvariable finden kann, der es die Ventilposition des auslösenden Datenpunkts zuordnen soll, müssen bestimmte Regeln definiert und eingehalten werden. Z.B. dass die entsprechende Systemvariable einem bestimmten Namensschema folgt und/oder dem selben Kanal wieder auslösende Datenpunkt zugeordnet ist.
• Das Master-Script erzeugt höhere Last - dynamische Ermittlung von Datenpunkten, Error-Handling, ...
• Aufwendigeres Debugging - bei mehreren Triggern ist unklar, wer das Programm ausgelöst hat bzw. es bedarf einer zusätzlichen Logging Funktion im Script.

Fazit
Momentan habe ich bei mir die meisten Aufgabenstellungen gemäß Variante 1 gelöst. Aus vielerlei (zugegeben: auch aus ästhetischen) Gründen favorisiere ich aber Variante 2.
Mich würde interessieren, ob es aus Eurer Sicht weitere Vor-/Nachteile für die jeweilige Variante gibt. Insbesondere eine Einschätzung was die Systemlast bei Variante 2 betrifft. Ist das vernachlässigbar oder kann das zum Showstopper werden.

gruß anderl

[NickHM]

Guten Abend

es hat beides Vor und nachteile, die Du schon gut aufgezählt hast.
Ob das Beispiel jetzt so gut geeignet ist ... ? Denn es werden nur SysVar befüllt, was für die CCU unkritisch ist. Es erfolgt keine Reaktion mit Funkverkehr.
Einzelne Programme können einfach per Haken mal deaktiviert werden.
Bei einzelnen Programmen sieht man am Zeitstempel wann sie gelaufen sind und es gibt nur einen Trigger.
Sind mehrere Trigger vorhanden ist unklar, wer das Programm ausgelöst hat bzw. es bedarf einer zusätzlichen Logging Funktion im Script.

Bei Programmen mit Aktionen die Funkpakete aussenden, ist das etwas anders. Zum Beispiel Setzen der Soll Temperatur oder Betriebsmodus.
Bei einem einzigen Masterprogramm wird das Programm gestartet und an alle Heizungen wird die größtenteils unveränderte Solltemperatur übertragen, nur weil sich in einem Zimmer etwas geändert hat. (nur ein Beispiel) Da muss man gut überlegen, wie nur der notwendige Funkverkehr generiert wird.

Es ist also eine Einzelfallentscheidung. Bei der Performance von CCU3 / Raspi würde ich auch kein Problem bei der Wartung vieler Einzelprogramme sehen. Auf der CCU2 nervt die (nicht)Geschwindigkeit da schon ganz schön

[d3h56r]

Ich habe bei mir „weder–noch“ im Einsatz. Ich bündelte meine Programme über Themenbereiche (z.B. Gartenbewässerung, Heizungssteuerung, Lichtsteuerung (raumweise), ...).

[anderl1969]

Bei Programmen mit Aktionen die Funkpakete aussenden, ist das etwas anders. Zum Beispiel Setzen der Soll Temperatur oder Betriebsmodus.
Bei einem einzigen Masterprogramm wird das Programm gestartet und an alle Heizungen wird die größtenteils unveränderte Solltemperatur übertragen, nur weil sich in einem Zimmer etwas geändert hat. (nur ein Beispiel)

Das ließe sich aber vermeiden. Das Master-Programm nach meiner Interpretation würde berücksichtigen, wer oder was der Auslöser war und entsprechend Deinem Beispiel nur für das betroffene Thermostat eine neue Soll-Temperatur übertragen.

Deine zusätzlichen Vorteile für Einzelprogramme sind valide und ich erlaube mir, sie in meinem Ursprungsposting zu ergänzen.

Ich habe bei mir „weder–noch“ im Einsatz. Ich bündelte meine Programme über Themenbereiche (z.B. Gartenbewässerung, Heizungssteuerung, Lichtsteuerung (raumweise), ...).

Das hört sich aber auch nach einem "Master-Skript" je Themenbereich an, oder was soll ich mir unter "bündeln" vorstellen?


gruß anderl

[d3h56r]

@anderl: weitestgehend korrekt.

[dtp]

Beides hat seine Berechtigung. So ist es z.B. kein großes Problem, eine Vielzahl von Sensoren bzw. Aktorzuständen mit einem Gewerk-Skript oder dergleichen auszulesen. Umgekehrt ist es aber oftmals nicht so geschickt, mehrere Aktoren, insb. Funk-Aktoren, per Skript anzusteuern. Da wäre dann im Skript eine Verzögerung hilfreich. Es gibt da zwar eine Lösung hier im Forum, die auf TCL basiert, aber die ist meines Wissens nach nicht so ganz ohne Risiko anzuwenden.

Leider gibt es bisher immer noch keine Build-In-Lösung für das verzögerte Ausführen von Befehlen innerhalb von WebUI-Skripten. Man könnte das vielleicht mit Dummy-Zählschleifen lösen, aber auch das ist nicht unbedingt elegant.

Besonders nervig an einer Vielzahl von WebUI-Programmen sind für mich Änderungen, die alle Programme betreffen. Da muss man dann immer besonders genau hinschauen, ob man auch überall das Richtige gemacht hat. Und wehe, man hat mal irgendwo einen Zustand oder Wert übersehen. Das lässt sich zwar weitestgehend mit der geschickten Verwendung von Systemveriablen umgehen, aber auch das ist nicht wirklich elegant.