Auf dieser Seite
Das Zeitmodul der CCU neigt dazu, nach einiger Zeit einfach stehenzubleiben. Programme, die vom Zeitmodul ausgelöst werden sollen, werden dann nicht mehr automatisch ausgeführt.
Bei einfachen Zeitplänen wie „tagsüber“ oder mit wenigen Schaltzeitpunkten täglich tritt das Problem nicht auf, aber im weiteren Verlauf brauche ich einen zuverlässigen Auslöser, der mein Programm in kurzen Abständen triggert. Daher programmiere ich hier einen Systemtakt, der alle 2,5 Minuten eine Systemvariable anstößt, die ihrerseits Programme starten kann.
Der Systemtakt dient, wie der Name schon sagt, als Taktgeber für verschiedene Aktivitäten auf meiner CCU. Ein Nebeneffekt ist, dass ich ihn etwas bequemer einzubinden finde als das Zeitmodul.
Benennung von Systemvariablen
Prinzipiell kann man Systemvariablen – so wie allen Objekten in der CCU – beliebige Namen geben, also z. B. auch Umlaute und Sonderzeichen verwenden. Ich empfehle jedoch, sich auf reguläre Buchstaben (a-z, A-Z) zu beschränken: Bei Umlauten und Sonderzeichen besteht die Gefahr, dass Systemvariablen in Scripten nicht überall gefunden werden.
Der einfachste Systemtakt
Als ersten Schritt kann man ein Gerät wie den Kombisensor, Raumthermostate, Temperaturfühler oder ähnliches verwenden, die von sich aus zyklisch ihren Status an die CCU senden.
Der Vorteil ist, dass man so ohne jede weitere Programmierung einen Systemtakt bekommt. Der Nachteil ist allerdings, dass der Systemtakt ausfällt, wenn das Gerät nicht mehr triggert – zum Beispiel bei leerer Batterie oder bei Funkstörungen.
Sinnvoll ist dieser Pseudo-Systemtakt daher nur dort, wo Programme nicht ausgeführt werden müssen, wenn keine Datenübertragung stattfindet. Ich lasse beispielsweise den Aktor für die Wärmeanforderung meiner Heizung über den Temperatursensor steuern, der die Vorlauftemperatur erfasst. Fällt der Temperatursensor aus, dann braucht meine Heizung auch nicht einzuschalten.
Andere Programme werden von diesem einfachen Systemtakt bei mir nicht mehr getriggert.
Programm: Systemtakt
Für den Systemtakt muss zunächst eine Systemvariable angelegt werden.
Der Wert der Variablen wird eigentlich nicht benötigt, daher setze ich hier nur „aktiv“ oder „inaktiv“ als Logikwert. Tatsächlich ist die Variable im Betrieb dauerhaft „aktiv“ und wird immer wieder getriggert.
Das Programm wartet 150 Sekunden und setzt dann den Systemtakt auf „aktiv“. Sobald der Systemtakt auf „aktiv“ gesetzt wird, triggert das Programm sich selbst, wartet wieder 150 Sekunden und … triggert sich erneut.
Wichtig ist, dass der Haken bei „Vor dem Ausführen alle laufenden Verzögerungen für diese Aktivitäten beenden“ nicht gesetzt ist. Wird der Haken gesetzt, kann es passieren, dass das Programm bei Auslösung die eigene Verzögerung von 150 Sekunden beendet und sich nicht wieder selbst startet.
Erstmalige Ausführung
Direkt nach dem Anlegen der Systemvariable ist diese auf „nicht aktiv“ gesetzt. Prüfen Sie darum unter „Status und Bedienung“ / „Programme“, ob für das Programm ein aktueller Zeitstempel angezeigt wird.
Falls nicht, starten Sie das Programm einmalig manuell – die Systemvariable wird gesetzt und das Programm läuft von da an automatisch.
Beim Start der CCU werden sämtliche Programme automatisch ausgeführt. Ist die Systemvariable beim Hochfahren der CCU „aktiv“, dann ist die Bedingung erfüllt und der Systemtakt läuft sofort los.
Beispiel: Gartenbeleuchtung
Das Programm für die Gartenbeleuchtung, das ich als Beispiel für die Vermeidung von Funkstörungen verwende, sieht mit Systemtakt so aus:
Das Zeitmodul in der Bedingung wurde durch den Systemtakt ersetzt. Das Programm läuft nun alle 150 Sekunden. Alle weiteren Bedingungen werden auf „nur prüfen“ gesetzt – öfter als im Systemtakt soll das Programm nicht laufen.
Damit die Beleuchtung nur nachts geschaltet wird, verwende ich ab jetzt die Tageszeit. Man könnte auch das Zeitmodul weiterverwenden und statt „zu Zeitpunkten auslösen“ ebenfalls „nur prüfen“ wählen.
Alternative: Duty Cycle
Der Duty Cycle ist ein etwas nerviger Wert, der die Funkaktivitäten der CCU überwacht: Wird die gesetzlich vorgeschriebene Begrenzung überschritten, hagelt es Servicemeldungen über Kommunikationsstörungen.
Eine Alternative zum Systemtakt könnte es daher sein, für „unwichtige“ Aufgaben die Aktualisierung des Duty Cycles zu verwenden, die ich hier beschrieben habe.
Das Programm zur Gartenbeleuchtung sähe dann zum Beispiel so aus:
Das Programm wird – neben einigen anderen Bedingungen – regelmäßig ausgeführt, wenn der Duty Cycle unterhalb von 50 % liegt. Durch die regelmäßige Aktualisierung der Systemvariablen gibt es hier einen weiteren Systemtakt, an den Aufgaben geknüpft werden können.
